GHDL Problem

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

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.

>> 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.

> 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.

> 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.

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.

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.

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.

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.