Wer benutzt ebenfalls Vivado und simuliert viel? Kann es sein, dass der V Simulator noch so einige Krankheiten hat? Ich entdecke mehr und mehr Diskrepanzen zwischen VSimulator und ISIM Ergebinssen. Eigentlich bin ich auf den VSIM umgestiegen, wegen der besseren Funktionen, aber ,,,
Die sind doch beide praktisch unbrauchbar. Und grottenlangsam. Der VSim hat noch nicht mal alles kompiliert, da ist selbst ModelSim PE schon fertig mit simulieren. Gruselig ist die Bedienung ja sowieso. Wenigstens kann der VSim angeblich Analogdarstellung.
Christian R. schrieb: > Wenigstens kann der VSim angeblich Analogdarstellung. Hast Du Dir die mal angesehen? Ich muss mich immer mehr zurückhalten, was mögliche Äusserungen über die Qualität von Xilinx-Software angeht. Wenn ich mir ISIM und ChipScope ansehe und die Darstellungsmöglichkeiten begutachte, komme ich regelmässig zu dem Schluss, dass das von Praktikanten oder Studenten programmiert worden sein muss. Da gibt es selbst aus der Open-Source-Eck massig Projekte von Einzelkämpfern, die weitaus klügere und bedienerfreundliche GUIs offerieren. Es ist für mich umso unverständlicher, dass da wenig passiert, als dass in Foren solche Mängel regelmässig immer wieder erörtert wurden. Auch ich selbst habe 2007 anlässlich einer diesbezüglichen sehr umfangreichen Diskussion mit einem Mentor-Support-Mann etliche Vorschläge zur Verbesserung der grafischen Analogdarstellung in ModelSIM gemacht (die nach USA weitergeleitet wurden und teilweise auch später im Produkt auftauchten). Ähnliche Tipps gingen in leicht veränderter Form zeitgleich auch an Xilinx und zwar mit Hinweis auf ISIM und Chipscope, wo es zwar eine Analogdarstellug gibt, diese aber grausig ist. Konkret bezüglich ISIM hatte ich auf die Optionen von MODELSIM verwiesen, das damals ja noch mit der freien Webversion von Xilinx bereitgestellt wurde. Von dort lies man mich wissen, dass die Vorschläge interessant seien und geprüft werden. 7 Jahre später konnte ISIM in der letzten Version immer noch kein Analog. Mehr muss ich wohl nicht sagen.
Jürgen Schuhmacher schrieb: > Hast Du Dir die mal angesehen? Nö, mit dem Schrott kann ich generell nicht arbeiten, deswegen schrieb ich ja "angeblich". Die Bedienung ist gruselig, das Backend totaler Murks (wer erzeugt schon eine Exe für die Simulation???) und die Features sind auch kaum vorhanden. Ich verwende ausschließlich ModelSim. Mit Vivado ist es nicht besser geworden. Ich hab jetzt gekämpft, den neuen ChipScope da drin in Betrieb zu nehmen, man kriegt da schon Wutanfälle. Erst mal das target öffnen ist schon schlimm, da musste ich erst ma die Admins holen dass die in der Firewall alles für die beiden Server freigeben. Schlimm, aber der ILA 2.x geht leider nicht mehr ohne Vivado. Was denken die sich nur dabei? Leider bin ich auf die verschlüsselten MGT Cores usw. angewiesen, sonst könnte ich auch GHDL+GTKWave nehmen.
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
Das Problem beim ghdl ist IMO eher zur Laufzeit. Es hilft mir nichts, wenn das = in STD_LOGIC meckert, auf ein U zu treffen, wenn ich nicht weiss, welches der unzähligen = in meinem Code das ist... Ansonsten ist ghdl schon schön, gerade mit dem printf-Ersatz kann man da auch ohne Waveform-Viewer reine Algorithmen sehr schön und schnell in der Konsole debuggen.
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/
Falls jemand Wünsche oder Verbesserungsvorschläge hat, kann man das auf GitHub mit anderen diskutieren: https://github.com/tgingold/ghdl/issues Eine aktuelle Dokumentation ist hier zu finden: http://ghdl.readthedocs.org/en/latest/index.html
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. GHDL wird nur für die Simulation genutzt und nicht zum kompilieren/synthetisieren. Oder was meinst du?
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
Mit dem Altera Simulator kann man die einschlägigen Libs und Dateien auch für die Post-ISE-Zeit simulieren. Das müsste mit GHDL eigentlich auch gehen, weil die inzwischen verwendete Kryptik nur auf die synthetisierbaren Strukturen angewandt wird. Es gibt nur manchmal Ärger mit den Bezügen zu Libraries.
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.
Das dürfte etwa dieselben Gründe haben, warum Microsoft seine Browser-Scriptsprache "JScript" verstümmelt hat, oder einen "\" anstatt einen "/" im Pfadnamen benutzt. Standards sind 90% Politik des Mächtigen, und da die HDL-Branche so ziemlich zum Schwerfälligsten gehört, hält es sich sicher auch noch eine Weile. Beim Xilinx-VHDL dürfte der noch vorherrschende Grund sein, die User an ihre zusammengeschluderten Tools und Library-Hacks zu ketten. Funktioniert offenbar bei vielen Kunden noch bestens.
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?
Sigi schrieb: > Ist vlt. SDC markentechnisch geschützt? Das glaube ich eher weniger, denn Altera hat mit Einführung des TimeQuest-Analzers (vor gefühlt 10 Jahren) auch auf SDC umgestellt und nennt die intern auch so.
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"
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.