|
Anzeige
|
Xilinx ISIM vs ModelSim
Gast
#7073940
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
Gast
#7074172
Eigentlich weder noch. Wenn dann Questasim. 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.
Gast
#7074525
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.
Gast
#7075807
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
Gast
#7075998
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. :-(
Gast
#7078147
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?
Gast
#7081303
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.
Gast
#7082467
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. Antwort schreiben |
Anzeige
|
