Hallo zusammen Ich kämpfe im Augenblick etwas mit dem ILA (integrated logic analyzer) in der Vivado Toolchain. Dabei brennen zwei Fragen: - Von Quartus SignalTapII bin ich es gewohnt, Waveforms (z.B. mit reproduzierten Debug-Cases) abzuspeichern, damit ich später offline wieder darin browsen oder die Waveform als Use-Case benutzen kann um zu dokumentieren, was abgeht. Wie handhabt Ihr das beim ILA? - Wie stelle ich enumerierte FSMs auch im ILA als enumeriert dar (siehe mstFsm_cur im Beispiel)? Merci!
Angehängte Dateien:
-
EnumExample.png
4,6 KB
- Zum speichern/öffnen fehlt leider schon lange der GUI-Button. Es gibt aber TCL-Befehle:
1 | write_hw_ila_data <Filename> |
Wobei hierbei Filename mit .zip enden sollte - dann speichert Vivado alle Infos ab. Zum öffnen:
1 | display_hw_ila_data [read_hw_ila_data <Filename>] |
- Zum Theme FSMs / Enums ist mir bisher leider nichts bekannt. Grüße
P. K. schrieb: > - Wie stelle ich enumerierte FSMs auch im ILA als enumeriert dar (siehe > mstFsm_cur im Beispiel)? Ich meine mich zu erinner, dass das bei der 2015.4 neu hinzugekommen ist. Schau mal in die Release Notes.
Christian R. schrieb: > Schau mal in die Release Notes. Hab's gefunden. Im Kontextmenu des entsprechenden Signals gibt es den Punkt "Show as Enumeration". Nur ist leider dieser Punkt nicht selektierbar, d.h. Vivado hat nicht mitbekommen, dass dies in VHDL ein enumerierter Typ war. Die entsprechende Auswahl beim Debug-Setup habe ich noch nicht gefunden. Ich bleibe dran.
:
Bearbeitet durch User
Christian R. schrieb: > Schau mal in die Release Notes. Hab's gefunden (p.111-119/213 im ug908) und ausprobiert. Das Feature ist geradezu armselig. Von Hand (GUI oder tcl) muss ich einem fixen(Hex-)Wert meine gewünschten Enumerated-Type-Properties zufügen. Was ich erwarten würde ist, dass mein VHDL-Typ, in diesem Fall
1 | type firFsm_type is (RESET, PARAMCLR, PARAM, SYNC, DATA); |
vom Tool nach Wunsch direkt erkannt wird und automatisch als Enumerated Type dargestellt werden kann. Immerhin weiss ja das Synthese-Tool, welche Codierung es für die FSM verwendet hat (und der User kennt diese nicht a priori). In dem Sinne: Frage geklärt, wenn auch unbefriedigend.
Wird vielleicht noch verbessert, momentan scheinen die viel am Hardware Manager, Ila usw. zu schrauben...
Wie ist der stand mit Chipscoe bzw. ILA? Ist die Funktion beim Webpack enthalten oder geht das nur mit einer zu zahlenden Lizenz.
P. K. schrieb: > Unbekannt ;) schrieb: >> Es gibt aber TCL-Befehle > Funktioniert tipp-topp, merci! Mach Dir einen button, der das tcl antriggert. Das kann Vivado ja nunmehr.
P. K. schrieb: > Immerhin weiss ja das Synthese-Tool, > welche Codierung es für die FSM verwendet hat Das ist wirklich zuviel verlangt! Woher soll denn die eine Komponente wissen, was die andere getan hat? So etwas ging bei Xilinx noch nie! Die bekommen es ja noch nicht mal hin, zu zählen!!! Wenn man mit Set Debug irgendwelche Cores bearbeitet, dann verschwinden Signale, es werden unvollständige Beschreibungen erzeugt, die nicht synthetisierbar sind. Das Vivado-Chipscope leidet unter denselben Macken, wie der ISE-Vorgänger. Höchstwahrscheinlich von denselben Typen programmiert worden!
Markus F. schrieb: > Das Vivado-Chipscope leidet unter denselben Macken, wie der > ISE-Vorgänger. Höchstwahrscheinlich von denselben Typen programmiert > worden! So ist es. Nimm Altera.
Markus F. schrieb: > Die bekommen es ja noch nicht mal hin, zu zählen!!! Wenn man mit Set > Debug irgendwelche Cores bearbeitet, dann verschwinden Signale, es > werden unvollständige Beschreibungen erzeugt, die nicht synthetisierbar > sind. Jep, es ist zum Haaröl seichen! Weltbester FPGA-Pongo schrieb im Beitrag #4553156: > So ist es. Nimm Altera. Würde ich noch so gerne! Das Dumme ist nur die Arria 10 (20nm) haben offensichtlich einen so katastrophalen Yield, dass die Rollouts permanent geschoben werden. Trotzdem muss ich jetzt ein Board machen. Xilinx ist mit den UltraScale (20nm) draussen, UltraScale+ (16nm FinFet) beginnt bereits mit dem Ramp-Up. Jetzt habe ich also die Wahl zwischen einer gut funktionierenden, schnellen Toolchain (Altera) und FPGAs, welche lieferbar sind (Xilinx).
P. K. schrieb: > Jetzt habe ich also die Wahl zwischen einer gut funktionierenden, > schnellen Toolchain (Altera) und FPGAs, welche lieferbar sind (Xilinx). Ja, das ist halt wie überall: Die Summe der Schei*** ist konstant. Bei Xilinx ist schon immer das Problem, dass die Software in Indien von Leuten zusammen gekloppt wird, die überhaupt gar keine Ahnung von Hardware geschweigedenn von FPGAs haben.
Christian R. schrieb: > Bei Xilinx ist schon immer das Problem, dass die Software in Indien von > Leuten zusammen gekloppt wird, auch Inder können zählen. Wenn man Software sauber definiert, die Anfoderungen festlegt udn eine Testspec erlässt, dann arbeiten Inder, Chinesen und Deutsche gleich gut. Unterlässt man das, dann hat man eben einen Saustall. Das Problem liegt eindeutig beim Softwaremanagement der Firma Xilinx und einer schlampigen Projektleitung. Solche bugs kann man sich nur bei einem eigenen tool erlauben und dies auch nur bei entsprechender Marktposition. In sucherheitskritischen Bereichen fiele eine solche Software rasch durch und die Firma auf die Schnautze!
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.