Hallo zusammen, die Fragen der Unterschiede zwischen Xilinx ISim und ModelSim scheint wohl immer wieder aufzutauchen: Siehe: Beitrag "Xilinx ISim brauchbar/fehlerfrei?" Wie ist der aktuelle Stand Dinge? Ist der Funktions-Unterschied in der Praxis noch so gravierend? Viele Grüße, Andre
Andre schrieb: > Ist der Funktions-Unterschied in der > Praxis noch so gravierend? Der ist eigentlich so gravierend, dass sich die Frage fuer jemanden der beides benutzt hat nicht stellt. ;-)
Da ist was dran, wobei es gar nicht so sehr die Unterschiede sind, sondern der Umstand dass ISIM schon irgendwie limitiert ist und man damit manche Sachen eben gar nicht machen kann. Gleichwohl werfe ich für kleine Module nicht unbedingt eine ModelSIM-Simu bei sondern lege eine ISIM an. ISIM hat durchaus Vorteile, wenn man schnell etwas aus der Umgebung starten will - allerdings verdudelt er sich, wenn man gleichzeitig am design synthetisieren will, während man an einer anderen Stelle simuliert. Das geht dann nur mit zweimal Vivado und gfs einer Kopie des Designs.
ISim ist praktisch weil es halt direkt in Vivado integriert ist und für die einfachen ersten FPGA Gehversuche sehr einfach "accesible" ist. Sobald man über ein 500-100 LOC Design und Testbench hinaus geht wird es sehr umständlich. Für kleine Bringup Tests verwende ich es auch gerne, sobald aber ein Test halbwegs kontinuerlich weiterentwickelt und weitergetestet werden soll ist es einfach in jeglicher Hinsicht umständlich. Alle OpenSource Tools schlagen es dann in Handling und Geschwindigkeit.
Hi, danke für die Antworten. Verstehe ich das richtig? Man entwickelt RTL-Block für RTL-Block separat im ModelSim. Somit lassen sich Simulationen bzw. Testbenches auf den einzelnen RTL-Blöcken implementieren. Im Vivado fügt man dann die getesteten RTL-Blöcke zum Gesamtsystem zusammen und benutzt das ISIM aus Performance-Gründen nur, wenn es nötig ist. Gruß, Andre
Andre schrieb: > Man entwickelt RTL-Block für RTL-Block separat im ModelSim. Ja, wobei ich im Editor entwickle und den Simulator zur Prüfung meiner Idee nutze. > Somit lassen sich Simulationen bzw. Testbenches auf den einzelnen > RTL-Blöcken implementieren. Ja. > Im Vivado fügt man dann die getesteten RTL-Blöcke zum Gesamtsystem > zusammen Bei mir gibt es noch eine Gesamtsystemtestbench um zu sehen, ob alle Module miteinander spielen. Zur Fehlersuche im Modul wird dann wieder die Modultestbench verwendet. > und benutzt das ISIM aus Performance-Gründen nur, wenn es nötig > ist. Ja, das kann man so machen. Duke
Andre schrieb: > Im Vivado fügt man dann die getesteten RTL-Blöcke zum Gesamtsystem > zusammen und benutzt das ISIM aus Performance-Gründen nur, wenn es nötig > ist. Oder weil man zu geizig fuer eine Simulator Lizenz war. In der Regel hast du das Problem mit Mixed Language Designs. GHDL z.B. hat die Perfoamnce, aber kein Verilog Support. Doof wenn IPs (z.B. von Xilinx) nur als Verilog verfuegbar sind. Mittlerweile gibt es auch genug kostenlose Modelsim Varianten am Markt die Mixed Language koennen (z.B. von Intel), leider sind die aber in der Performance beschnitten. :-(
Duke Scarring schrieb: >> Im Vivado fügt man dann die getesteten RTL-Blöcke zum Gesamtsystem >> zusammen > Bei mir gibt es noch eine Gesamtsystemtestbench um zu sehen, ob alle > Module miteinander spielen. > Zur Fehlersuche im Modul wird dann wieder die Modultestbench verwendet. Tobias B. schrieb: > Perfoamnce Doof wenn IPs (z.B. von Xilinx) > nur als Verilog verfuegbar sind. Das leuchtet ein. Wenn das Gesamtsystem/Design z. B. einen Zynq Core oder andere Xilinx IPs enthält, ist die Simulationsstrategie dann die gleiche?
Andre schrieb: > Das leuchtet ein. > Wenn das Gesamtsystem/Design z. B. einen Zynq Core oder andere Xilinx > IPs enthält, ist die Simulationsstrategie dann die gleiche? Das kann man pauschal nicht beantworten. Vom Zynq hast du z.B. ein BFM damit kannst du problemlos deine Schnittstellen testen, jedoch nur schwer Integrationstests im Zusamenspiel mit dem Zynq. Was du auch immer bedenken musst: Was willst du mit der Simualtion erreichen? Design Verifikation oder Debugging parallel zur Entwicklung?
Andre schrieb: > Wenn das Gesamtsystem/Design z. B. einen Zynq Core oder andere Xilinx > IPs enthält, ist die Simulationsstrategie dann die gleiche? Bei der einen Entwicklung, die momentan mit Zynq läuft, bin ich da ziemlich angefressen. Bei bisherigen Softcore-System habe ich den Test einfach in C programmiert, compiliert und inklusive Softcore mitsimuliert. Beim Zynq muß man alles zweimal schreiben und per BFM die Zugriffsmuster abbilden. Duke
Duke Scarring schrieb: > Bei der einen Entwicklung, die momentan mit Zynq läuft, bin ich da > ziemlich angefressen. Bei bisherigen Softcore-System habe ich den Test > einfach in C programmiert, compiliert und inklusive Softcore > mitsimuliert. Dafuer hast du halt einen deutlich leistungssaerkeren ARM Core. Im Zweifel musst du bei ARM ein Simulationsmodell besorgen. Oder doch die Teststrategie ueberdenken.
Tobias B. schrieb: > Im > Zweifel musst du bei ARM ein Simulationsmodell besorgen. Wie sieht sowas aus? Wenn man einen ARM-Core lizenziert hat, hat man die *.v und somit alles zyklen-exakt, aber wie simulierbar das dann noch ist, ist fraglich. Sonst habe ich nur ein Simulator-Front-End von Cadence für den genau den Zweck gesehen. Hätte einen halben Jahreslohn verschlungen. Wir haben damals (einige Jahre her) einen virtuellen Bus an den qemu-Emulator rangebaut und über VPI den Simulator angesteuert. Leider hat sich der Kunde gegen Opensource gesträubt. Inzwischen sollte es da was geben.
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.