Nach dem Tip von T.M. habe ich einfach mal versucht GHDL und GTKWave zum Laufen zu bekommen. Leider gibt es ja kein freies ModelSim für Linux! Nun habe ich mich mal von Thomas Seite orientiert: http://editthis.info/freefpga/Simulation jedoch folgende Schritt funktioniert nicht: ghdl -m -g --workdir=libs/work --warn-default-binding --warn-binding --warn-library --warn-body --warn-specs --warn-unused ${TB_DESIGN} /usr/lib/ghdl/bin/ghdl: command '-m' required an unit name die Dokumentation von ghdl ist ja unter aller Sau. Wofür steht -m bzw. welche Optionen gibt es dafuer? badhorst@123: /tmp/led/sim$ ghdl -v GHDL 0.24 (20060625) [Sokcho edition] Compiled with GNAT Version: 4.1.220060630prerelease (Debian GCC back-end code generator Written by Tristan Gingold. Copyright (C) 2003, 2004, 2005, 2006 Tristan Gingold. GHDL is free software, covered by the GNU General Public License. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Hallo,
wenn du für ${TB_DESIGN} deinen konkreten Namen der Top-Entity benutzt
müsste es eigentlich funktionieren. Ich hab es mit der 0.25'er Version
benutzt.
Das erinnert mich daran, die Seite mal zu aktualisieren, Einiges in den Makefiles ist doch noch recht rundimentär und umständlich...
Probiers mal mit folgendem Makefile (Anhang). Bei mir läuft es ganz gut damit. Rick
@T.M
${TB_Design} habe ich für eine von meinen Dateien geändert. Unter
ModelSim bekomme ich es auch simuliert.
Es ist eigentlich nur folgende Zeile, die ärger macht:
ghdl -m -g --workdir=libs/work --warn-default-binding --warn-binding
--warn-library --warn-body --warn-specs --warn-unused ${TB_DESIGN}
Wofür steht dieses ghdl -m -g??
ghdl --help
ist nicht so wirklich aussagekräftig:
usage: /usr/lib/ghdl/bin/ghdl COMMAND [OPTIONS] ...
[...]
-m [OPTS] UNIT [ARCH] Make UNIT
IVI ist nur nen graphischer Frontend für Icarus und GHDL soweit ich weiss. Zu der Option m: http://ghdl.free.fr/ghdl/Make-command.html#Make-command "...The purpose of this command is to be able to compile a design without prior knowledge of file order. In the VHDL model, some units must be analyzed before others (e.g. an entity before its architecture). It might be a nightmare to analyze a full design of several files, if you don't have the ordered list of file. This command computes an analysis order..." Die Hilfe ( http://ghdl.free.fr/ghdl/index.html ) ist sowieso ganz nützlich, man sieht, die Doku ist nicht so schlecht, wie du meinst ;-)
Hat jemand schon mal eine post-fit Simulation unter Linux auf diese Weise gemacht? Die simprim-Bilbliothek lässt sich zwar importieren, benutzt aber selbst wiederum vital2000 die ich nirgendswo finde. Bis zum vhd und sdf File erzeugen bin ich schon gekommen, importieren klappt auch aber beim ghdl -m wird abgebrochen, da vital2000 nicht gefunden wird (in simprim_SMODEL_mti.vhd). Gruß Jörg
> benutzt aber selbst wiederum vital2000 die ich nirgendswo finde. Bis zum > vhd und sdf File erzeugen bin ich schon gekommen, importieren klappt > auch aber beim ghdl -m wird abgebrochen, da vital2000 nicht gefunden Hat jemand schon die Erfolge bei der post fit simulation ? Tools: ghdl und Xilinx Ich habe es noch nicht heraus, wie ich das sdf File und die simprim verarbeite. Nützliche Hinweise willkommen. Leider ist ghdl für die Spezialfälle schlecht dokumentiert. ghdl -i *.vhd ghdl -i --work=simprim /opt/Xilinx/13.1/ISE_DS/ISE/vhdl/src/simprims/*.vhd ghdl -i --work=simprim /opt/Xilinx/13.1/ISE_DS/ISE/vhdl/src/simprims/primitive/mti/*.vhd ghdl -i --work=simprim /opt/Xilinx/13.1/ISE_DS/ISE/vhdl/src/simprims/primitive/other/*.vhd ghdl -m -g -Psimprim -Wa,--32 -Wl,-m32 --warn-no-vital-generic --ieee=synopsys -fexplicit --sdf=/.=lm_cpu_map.sdf tb_lm_cpu ghdl: unknown option '--sdf=/.=lm_cpu_map.sdf' for command '-m' make: *** [all] Error 1
>> Leider gibt es ja kein freies ModelSim für Linux! altera hat eine Modelsim Altera Starter Edition für linux http://www.altera.com/products/software/quartus-ii/modelsim/qts-modelsim-index.html
Den Modelsim habe ich mir schon die Tage als Alternative herunter gezogen. Funktionale Simulation bekomme ich schon hin. Hat jemand schon postfit Simulation mit Xilinx libs mit der Altera Modelsim geschafft? Die GHDL Lösung würde mich trotzdem auch noch brennend interessieren.
René D. schrieb: > Hat jemand schon postfit Simulation mit Xilinx libs mit der Altera > Modelsim geschafft? Wofür brauchst Du überhaupt eine postfit (bzw. posttranslate) Simulation? Duke
>> Hat jemand schon postfit Simulation mit Xilinx libs mit der Altera >> Modelsim geschafft? > Wofür brauchst Du überhaupt eine postfit (bzw. posttranslate) > Simulation? Bei mir unterscheidet sich die Funktionale Simulation mit dem was in der Hardware passiert. ich habe das Problem in einem Softcore Assembler Variante A: -lade Konstante in Register A -hole aus Memory(latch) in Register B -Springe wenn Register A und B ungleich läuft in der Simulation und auf dem FPGA Assembler Variante A: -hole aus Memory(latch) in Register B -lade Konstante in Register A -Springe wenn Register A und B ungleich läuft in der Simulation aber nicht auf dem FPGA Die Sache muss ich jetzt nachgehen, da beide Varianten laufen müssen. Um den Hebel an der richtigen Stelle und sicher anzusetzen, wollte ich mit den Verzögerungszeiten es mal simulieren.
René D. schrieb: > Um > den Hebel an der richtigen Stelle und sicher anzusetzen, wollte ich mit > den Verzögerungszeiten es mal simulieren. Hm, und wie stellst du dir das vor? Bei einer Timing-Simulation nach dem Routen siehst du auch erst mal nur das Design von außen als Black-Box. Innerhalb des FPGA gibt es dann keine Strukturen mehr, wie du sie beschrieben hast, auch keine Signal-Namen. Da siehst du nur noch LUTs, BRAMs usw. Da einen Fehler zu finden ist nahezu ausgeschlossen. Sowas kann man höchstens mal machen, wenn man an den I/Os ein problem hat, was man mit Constraints nicht festzurren kann.
Christian R. schrieb: > René D. schrieb: >> Um >> den Hebel an der richtigen Stelle und sicher anzusetzen, wollte ich mit >> den Verzögerungszeiten es mal simulieren. > > Hm, und wie stellst du dir das vor? Das weiss ich auch noch nicht. Es gibt ein Signal Branch was mir den Sprung anzeigt und die Statmaschine steuert. Da wäre wichtig was auf dem Signal abgeht. Ob die State Maschine falsch ist oder das Signal selbst nicht korrekt ist.
Christian R. schrieb: > René D. schrieb: >> Um >> den Hebel an der richtigen Stelle und sicher anzusetzen, wollte ich mit >> den Verzögerungszeiten es mal simulieren. > > Hm, und wie stellst du dir das vor? Das weiss ich auch noch nicht. Es gibt ein Signal Branch was mir den Sprung anzeigt und die Statmaschine steuert. Da wäre wichtig was auf dem Signal abgeht. Ob die State Maschine falsch ist oder das Signal selbst nicht korrekt ist.
Angehängte Dateien:
-
wave.png
140 KB
> Da einen Fehler zu finden ist nahezu ausgeschlossen. Sowas kann man > höchstens mal machen, wenn man an den I/Os ein problem hat, was man mit Ich habe es zumindest bis zur postsynthese Simulation geschafft. Da brauche ich die SDF Files noch nicht. Mit etwas Geschick habe ich schon was im Signalspiel gefunden. So habe ich den Programmcounter gefunden und weiss, dass mein Programm richtig abgearbeitet wird. Das ist schon mal viel wert. Das aktuelle Problem an meinem Uart fehlt in der ASCII Folge $#N$ das N. Bei der Suche ist mir aufgefallen, dass der Schreibimpuls fehlt. Den eigentlichen Fehler habe ich noch nicht gefunden. Jetzt weiss ich jedoch wo ich suchen muss.
Noch zur Erklärung oben ist die funktionale Simulation und unten die Simulation nach der Synthese.
Hi Rene, > > Assembler Variante A: > -hole aus Memory(latch) in Register B > -lade Konstante in Register A > > -Springe wenn Register A und B ungleich > > > läuft in der Simulation aber nicht auf dem FPGA verstehe ich das richtig, dass sich die beiden Fälle nur in der Reihenfolge der Assembler-Kommandos unterscheiden? Hast Du mal den Clock testweise verlangsamt? Meistens habe ich solche fiesen Sachen nur dann gesehen, wenn ich: - 'Verbotene' non-synchrone Logik benutzt habe - Clock-Skew-Warnings missachtet habe also kurz, irgendwelche Sachen, die Laufzeitunterschiede nicht sauber berücksichtigen (-> Glitches, die gewisse conditions triggern). Bei einer mehrstufigen Pipeline kann man sich u.U. damit gut ins Knie schiessen.. Gruss, - Strubi
> verstehe ich das richtig, dass sich die beiden Fälle nur in der > Reihenfolge der Assembler-Kommandos unterscheiden? Ja, das hast du richtig verstanden > Hast Du mal den Clock testweise verlangsamt? Meistens habe ich solche > fiesen Sachen nur dann gesehen, wenn ich: Nein das habe ich nicht. Das bringt mir auch nicht viel. > > - 'Verbotene' non-synchrone Logik benutzt habe > - Clock-Skew-Warnings missachtet habe Die Logik ist synchron aufgebaut. Die Warnungen muss ich nochmal durchgehen ob da so etwas dabei war. > also kurz, irgendwelche Sachen, die Laufzeitunterschiede nicht sauber > berücksichtigen (-> Glitches, die gewisse conditions triggern). > Bei einer mehrstufigen Pipeline kann man sich u.U. damit gut ins Knie > schiessen.. So was habe ich eigentlich nicht dabei. Da ist ein doofer Bug. Ich habe auch kein CHipscope um die internen Signal in Hardware zu "fischen". Das ist erst dumm.
ChipScope ist bei sowas auch nur bedingt einsetzbar. Klar, man kann viel sehen, allerdings verändert jede ChipScope Instanziierung das komplette Design, und gerade bei solch blöden Fehlern, die wahrscheinlich irgendwo durch blödes Routing/Timing entstehen, kann man mit ChipScope auch viel Augenwischerei betreiben. Ansonsten nehm ich dann schon auch gerne...
> durch blödes Routing/Timing entstehen, kann man mit ChipScope auch viel > Augenwischerei betreiben. Ansonsten nehm ich dann schon auch gerne... Bitte sprechen Sie im vollständigen Satz.
René D. schrieb: > Ich habe > auch kein CHipscope um die internen Signal in Hardware zu "fischen". Hier [1] gibt es ein Chipscope 'lite'. Scheint zwar nicht mehr gepflegt zu werden, ist aber recht brauchbar. Duke [1] http://www.sump.org/projects/analyzer/
Duke Scarring schrieb: > René D. schrieb: >> Ich habe >> auch kein CHipscope um die internen Signal in Hardware zu "fischen". > Hier [1] gibt es ein Chipscope 'lite'. Scheint zwar nicht mehr gepflegt > zu werden, ist aber recht brauchbar. > > Duke > > [1] http://www.sump.org/projects/analyzer/ Mein aktueller Ansatz ist dergleiche. Die Daten über das Ethernet versenden. Alles statische Pakete. Informationen aus dem Organismus. Das werde ich mir mal rein ziehen. Das sieht gut aus. Gefällt mir. Sogar eine GUI. Leider habe ich gerade keinen UART mehr ON-Board. Zwei Leitungen werden sich finden.
Christian R. schrieb: > ChipScope ist bei sowas auch nur bedingt einsetzbar. Klar, man kann viel > sehen, allerdings verändert jede ChipScope Instanziierung das komplette > Design, und gerade bei solch blöden Fehlern, die wahrscheinlich irgendwo > durch blödes Routing/Timing entstehen, kann man mit ChipScope auch viel > Augenwischerei betreiben. Ansonsten nehm ich dann schon auch gerne... Ja, das firmiert hier (bei mir und Kollegen) als 'Quantenmechanik'. Wennde hinguckst, tut's, sonst nicht. Womit ich bei komplexeren Sachen gute Erfahrungen gemacht habe: Gleich nen JTAG TAP mit reinbauen. Das ist perfekt für coverage (abdeckung so hoffentlich aller test cases), 'nen FT2232 JTAG hat zudem fast jeder rumliegen. Damit kreist man allerdings die Probleme nur relativ schnell ein, Timing-Böcke sind leider jenseits. René D. schrieb: >> Hast Du mal den Clock testweise verlangsamt? Meistens habe ich solche >> fiesen Sachen nur dann gesehen, wenn ich: > Nein das habe ich nicht. Das bringt mir auch nicht viel. Wieso? Du wüsstest dann wenigstens, obs eine Timing-Sache (Clock Skew o.ae.) ist. Allerdings sollten dich die Tools dazu deutlich mit Warnungen bescheren. Ansich sollte auch asynchrone Logik (z.B. für nen komplexeren state-machine encoder) davon erfasst werden. Was ich allerdings auch schon geschafft habe: Signal in der sensititivy-List vergessen, Simulation tat, FPGA natürlich nicht (meistens ist es ja dann andersrum). Also komplett falsch gedacht... Viel Erfolg, - Strubi
René D. schrieb: > Ansonsten nehm ich dann schon auch gerne... > >> Bitte sprechen Sie im vollständigen Satz. Argh. Das sollte heißen: "Ansonsten nehm ich den schon auch gerne..."
>>> Hast Du mal den Clock testweise verlangsamt? Meistens habe ich solche >>> fiesen Sachen nur dann gesehen, wenn ich: >> Nein das habe ich nicht. Das bringt mir auch nicht viel. > > Wieso? Du wüsstest dann wenigstens, obs eine Timing-Sache (Clock Skew > o.ae.) ist. Allerdings sollten dich die Tools dazu deutlich mit > Warnungen bescheren. Das Fitting tool sagt ich kann 130MHz die Sache betreiben und Das Board läuft aber mit 27MHz. Sofern habe ich den Clock schon langsamer. Timing Warungen habe ich keine.
Wie oben schon mal angefragt: Vlt. eine unvollstaendige sensitivity Liste? Daraus resultierend ein Latch?
berndl schrieb: > Wie oben schon mal angefragt: Vlt. eine unvollstaendige sensitivity > Liste? Daraus resultierend ein Latch? Meist läuft es in der Hardware, doch für den Simulator sind die sensitiv Listen ganz wichtig. Doch hier ist es anders herum im Simulator läuft es aber nicht in der Hardware. Die Sensitivlisten habe ich schon überprüft. Duke zu SUMP Leider bekomme ich das java programm nicht zum Laufen. ;-< Caused by: java.lang.ClassNotFoundException: org.sump.analyzer.Loader at java.net.URLClassLoader$1.run(URLClassLoader.java:217) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:205) at java.lang.ClassLoader.loadClass(ClassLoader.java:321) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:294) at java.lang.ClassLoader.loadClass(ClassLoader.java:266) Could not find the main class: org.sump.analyzer.Loader. Program will exit.
Wo hast Du denn SUMP her? Es gibt da ein Fork, der evtl. neuer ist: http://dangerousprototypes.com/docs/Open_Bench_Logic_Sniffer#Logic_Analyzer_Software Du betreibst das also 'ohne Hardware', hast also die SUMP VHDL sourcen direkt im FPGA an Dein Design gehängt? Coole Idee eigentlich! Grüße Dave
Dave Webb schrieb: > Wo hast Du denn SUMP her? Da wo Duke den Link hingebeamt hat. [1] http://www.sump.org/projects/analyzer/ Es gibt da ein Fork, der evtl. neuer ist: > > http://dangerousprototypes.com/docs/Open_Bench_Logic_Sniffer#Logic_Analyzer_Software Das muss ich mir mal anschauen. Das würde auch erklären, warum auf der Homepage es keine Neuerungen gibt. Ja Ich habe Sump auf meinem Rechner gestartet und erwartet, dass ein Fenster sich öffnet. Den VHDL code habe ich noch nicht mit meinem Code zusammengeführt. Du meinst, es geht nur ein Fenster auf, wenn der FPGA antwortet?
nnde hinguckst, tut's, sonst nicht. > > Womit ich bei komplexeren Sachen gute Erfahrungen gemacht habe: Gleich > nen JTAG TAP mit reinbauen. Das ist perfekt für coverage (abdeckung so > hoffentlich aller test cases), 'nen FT2232 JTAG hat zudem fast jeder > rumliegen. Damit kreist man allerdings die Probleme nur relativ schnell > ein, Timing-Böcke sind leider jenseits. Hast du zu der Variante ein paar weiterführende Infos? Wie geht es hinter dem Tap im FPGA weiter? Das klingt nach einer interessanten Lösung.
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.