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!
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.
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
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.
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!
