Kampf gegen den Vivado Simulator

Ich hatte mit dem Vivado-Simulator auch verschiedene Probleme. Der 
Gipfel war dann eine Fehlermeldung die sinngemäß sagte: "Interner 
Fehler, ich gebe auf. Keine Ahnung was los ist, bitte den Support 
kontaktieren". Und das war bei einem ziemlich einfachen Design! Den 
Support habe ich nicht kontaktiert, sondern gleich auf Modelsim (Questa) 
gewechselt.

TL;DR ich kann vom Xilinx-Simulator nur abraten.

Wenn du einen einfachen, aber gut funktionierenden Simulator willst, 
guck dir mal das Open-Source-Projekt ghdl an. Mit gtkwave zusammen ist 
das eine recht leistungsstarke Kombination. Unzufrieden bin ich mit den 
Fehlermeldungen von ghdl bei Problemen mit dem Code, aber ansonsten lief 
bei mir immer alles korrekt. Das ist schonmal Klassen besser als Xilinx' 
Simulationsversuche. :o

greg schrieb:
> Unzufrieden bin ich mit den
> Fehlermeldungen von ghdl bei Problemen mit dem Code, aber ansonsten lief
> bei mir immer alles korrekt.
Meine Erfahrung sind da genau andersherum: Der ghdl sagt einem nicht 
nur die Zeilennummer, sondern sogar die Spalte in der er einen Fehler 
findet.

Duke

Ja, das Verhalten zur Laufzeit ist das Problem!

Bspw. hatte ich es schon öfters, dass ghdl sich schlicht mit "boundary 
check failed" beendete, ohne weitere Info. Da muss man dann entweder 
manuell suchen, oder einen Debugger wie gdb rausholen; beides sehr 
unschön und unkomfortabel.

In anderen Fällen gab es aber auch vom Compiler irreführende 
Fehlermeldungen, die nichts mit dem Problem zu tun hatten. Mir fällt 
aber nicht mehr konkret ein, unter welchen Bedingungen das passiert ist.

Schön wäre auch eine genauere Angabe, wie und wo asserts zustandekommen 
(backtrace o.ä.). Ich hatte z.B. einen Haufen "metavalue"-asserts bei 
to_integer, aber ghdl konnte mir nicht sagen, wo mein Code das 
verursacht hat.

Trotzdem bleibt ghdl ein sehr schönes Tool.

greg schrieb:
> Trotzdem bleibt ghdl ein sehr schönes Tool.
Wenn man das mal richtig angehen würden, also mit einigen echten 
HW-Spezialisten liesse sich aus GHDL sicher eine Menge machen. Ich wäre 
da durchaus dabei. So langsam regen mich ISIM, Chipscope etc nämlich 
auch. Besonders zu ChipScope habe ich ein sehr gespaltenes Verhältnis. 
Schon vor Längerem habe ich im Xilinx Forum dazu einige Kritikpunkte 
angebracht und Alternativen diskutiert, allerdings tauchten sofort 
einige Xilinx fans auf und lobten dieses "professionelle Tool".

Im Moment gibt es sehr viel Aktivität im ghdl_updates-Projekt [1], 
vielleicht kannst du dort ja deine Vorschläge oder gar Code einbringen. 
Ich bin leider gerade mit anderen Projekten beschäftigt und nutze ghdl 
momentan nicht.

[1] http://sourceforge.net/p/ghdl-updates/

wie sieht es denn aus mit den Libraries?  Ich habe - besonders bei 
Xilinx - das Problem, dass ich diverse Sachen nicht vernünftig 
compiliert bekam. Besonders die verkrüppelten VHDLs machen mir Sorgen.

Markus F. schrieb:
> wie sieht es denn aus mit den Libraries?  Ich habe - besonders bei
> Xilinx - das Problem, dass ich diverse Sachen nicht vernünftig
> compiliert bekam. Besonders die verkrüppelten VHDLs machen mir Sorgen.

Das Problem ist leider, dass Xilinx entweder gezielt gegen den 
VHDL-Standard verstösst (GHDL ist da sehr konform und streng) oder 
manche der obfuscated Sachen zu lange Zeichenketten generieren. Das 
Problem lässt sich entweder durch einen Patch oder durch De-Obfuscation 
lösen. Ich habe allerdings schon länger keine verkrüppelten VHDLs mehr 
genutzt und portable Cores eingesetzt, drum kenne ich den aktuellen 
Status nicht, bei GHDL tut sich aber laufend was.
Ansonsten lassen sich aber die Unisim-Sachen/xilinxcore von 2013 alle 
simulieren, man muss nur die --ieee=synopsys-Option aktivieren. Bei 
näherem Interesse kann ich ein Makefile zuschicken.

Grüsse,

- Strubi

Strubi schrieb:
> Das Problem ist leider, dass Xilinx entweder gezielt gegen den
> VHDL-Standard verstösst

Hat einer eine Idee, warum diese Krüppelfirma immer wieder versucht 
einen eigenen Standard zu setzen? Warum nimmt man z.B. nicht die 
SDC-files, mit denen die halbe Welt arbeitet, sondern XDC, die eine 
abweichende Syntax und offenbar vereinzelt eine abweichende 
Interpretation bedingt.

Thomas der Vivadohasser schrieb:
> Warum nimmt man z.B. nicht die
> SDC-files, mit denen die halbe Welt arbeitet, sondern XDC
Ist vlt. SDC markentechnisch geschützt?

Ich beziehe mich auf dieses Post:
Beitrag "Re: Kampf gegen den Vivado Simulator"

Wurden inzwischen Vorschläge dieser Art umgesetzt?
D.H. bringt es was, dort Vorschläge zu machen?

Mit den Vorschlägen meinst du sicher die Fortentwicklung von GHDL, nehme 
ich an. Ich persönlich setze da echt meine Hoffnungen rein, weil ich 
mich gerne von der Xilix-Thematik lösen würde.

Ich bin nicht so sehr tief im VHDL-Thema drin, von daher brauche ich ein 
Entwicklungssystem, dass nicht zu sehr auf einen Hersteller 
zugeschnitten ist. Die Effekte, die die tollchain macht, sind bisweilen 
schon enorm und zeitfressend.

Momentan ärgere ich mich wieder mit Simulink rum. Eine Suche ergab, dass 
die Probleme, die man so hat, seit Jahren dieselben sind und sich kaum 
was ändert:

Beitrag "Re: FPGAs grafisch programmieren - eine Analyse"