Quartus II => Modelsim - Library Problem

[Andi (loopy83)]

Hallo zusammen,
 
ich bin gerade dabei, ein Quartus II Projekt nach Modelsim zu 
überführen, um es dort entsprechend simulieren zu können.
Dabei habe ich Probleme mit einem PLL IP und den Libraries.
 
Ich habe schon folgendes versucht:
1. Ich habe die Quellen solo im Modelsim kompiliert und habe die 
Libraries verlinkt.

vlib work
vmap /pfad/stratixii
vmap /pfad/altera_mf
vcom pll.vhd
vcom restliche_quellen.vhd
vcom testbench.vhd
…

Die Libraries habe ich mit Hilfe des Simulation Library Compilers im 
Quartus erzeugt. Nun erkennt er zwar die PLL.vhd und simuliert auch 
deren Inhalt, aber die dort aufgerufenen Komponenten (altpll), die sich 
in der Lib altera_mf befinden, werden nicht mit berücksichtigt. Dadurch 
habe ich keinen Ausgangstakt und die restliche Logik somit auch nicht. 
Weniger gut, wenn die Inhalte der Libs also scheinbar nicht eingebunden 
werden.
 
2. Danach habe ich mit Hilfe des EDA Netlist Writers im Quartus eine 
Netlist-file erzeugt (.vho), in dem im Prinzip die gleichen Libs 
verwendet werden. Aber auch hier komme ich nicht weiter, da es dann in 
irgendeiner vhd Datei von Altera (stratixii_atoms.vhd) Probleme gibt. 
Das Kernproblem mit den Libs bleibt aber leider das gleiche, weil mir 
die Verschaltung der Quellen nur Quartus abnimmt.
 
Kann mir jemand den korrekten Design Flow erklären, wie ich mein 
Quartus-Projekt korrekt mit allen Libs zum Modelsim übertragen, um dann 
dort eine funktionale und eine timing-Analyse starten kann?
 
Diverse Beiträge auf der Altera Seite sind an den entscheidenden Stellen 
lückenhaft.
z.B. hier: 
http://quartushelp.altera.com/11.1/mergedProjects/eda/simulation/modelsim/eda_pro_msimfull_compile.htm
Informationsgehalt nahe Null.
 
Vielen Dank!
Andreas

[berndl (Gast)]

hilft dir das
http://www.altera.com/support/examples/tcl/tcl-modelsim.html
vlt. weiter?

[Andi (loopy83)]

Hallo und vielen Dank,

das tcl script macht ja im Prinzip nichts anderes  als der Library 
Compiler im Quartus. Das kann ich nun zwar komfortabler mit im do-File 
erledigen, aber näher bin ich meiner Lösung immer noch nicht. Die PLL 
will nicht.

Habe jetzt sogar den areset Pin weggelassen, um wirklich alle Fehler 
auszuschließen.

Jetzt gibt es nur noch clk, out und locked und der Clock-Ausgang bleibt 
auf 'Z'. 25MHz clk liegt auch am Eingang an. Also was soll man da falsch 
machen. Bleibt ja fast nur die Library Geschichte...
so sieht aktuell mein do-File aus:

quit -sim
 
cd /pfad
 
vlib altera_mf
vmap altera_mf altera_mf
vcom -work altera_mf -2002 -explicit /asic/app/altera/quartusII_10.0_lnx/quartus/eda/sim_lib/altera_mf_components.vhd
vcom -work altera_mf -2002 -explicit /asic/app/altera/quartusII_10.0_lnx/quartus/eda/sim_lib/altera_mf.vhd
 
vlib stratixii
vmap stratixii stratixii
vcom -work stratixii -2002 -explicit /asic/app/altera/quartusII_10.0_lnx/quartus/eda/sim_lib/stratixii_atoms.vhd
vcom -work stratixii -2002 -explicit /asic/app/altera/quartusII_10.0_lnx/quartus/eda/sim_lib/stratixii_components.vhd
 
vlib lpm
vmap lpm lpm
vcom -work lpm -2002 -explicit /asic/app/altera/quartusII_10.0_lnx/quartus/eda/sim_lib/220pack.vhd
vcom -work lpm -2002 -explicit /asic/app/altera/quartusII_10.0_lnx/quartus/eda/sim_lib/220model.vhd
               
vlib sgate
vmap sgate sgate
vcom -work sgate -2002 -explicit /asic/app/altera/quartusII_10.0_lnx/quartus/eda/sim_lib/sgate_pack.vhd
vcom -work sgate -2002 -explicit /asic/app/altera/quartusII_10.0_lnx/quartus/eda/sim_lib/sgate.vhd
 
vlib work
 
vcom PLL.vhd
vcom quellen.vhd
vcom testbench.vhd
 
vsim -gui sim_dut
 
add wave *

Hat jemand dazu noch Hinweise?

Vielen Dank!
Andreas

[Duke Scarring (Gast)]

Andreas B. schrieb:
> vmap /pfad/stratixii
> vmap /pfad/altera_mf
Will vmap nicht zwei Argumente haben?

$ vmap -h
Usage: vmap [-help] [-modelsimini <ini_filepath>] 
[-c] [-del] [<logical_name>] [<path>]

Wie lautet die genaue Fehlermeldung?

Duke

[Andi (loopy83)]

Hallo,

ja dort hatte ich Ausversehen das work mit weggeschnitten. In dem 
do-File meines letzten Posts sollte alles wieder stimmen.

Ich bekomme gar keine Fehlermeldung. Lediglich eine Warnung beim 
kompilieren der Stratixii_atoms.vhd.

Die PLL spuckt einfach nur keinen Takt aus... hätte nicht gedacht, dass 
sowas so lange aufhalten kann :-/

Vielen Dank!
Andreas

[dl4mea (Gast)]

Hi,

warum nicht einfach die Takte, die aus der PLL rauskommen, manuell in 
der Testbench erzeugen?

Probier mal die PLL-Komponenten mit dem Wizard einer älteren 
Quartus-Version zu erzeugen. Ich hab sowas ähnliches beim ALTSHIFT_TAPS 
als Schieberegister, wenn ich das mit dem Quartus 11.1-Wizard erzeuge, 
dann kommt an den Taps nichts raus, das gleiche nur mit dem Wizard von 
10.0 geladen und wieder gespeichert funktioniert. Habe aber die Sourcen 
noch nicht verglichen.

Ciao, Günter (dl4mea)

[berndl (Gast)]

dl4mea schrieb:
> warum nicht einfach die Takte, die aus der PLL rauskommen, manuell in
> der Testbench erzeugen?

noe, keine gute Idee weil du dann deinen Design jedesmal aendern musst. 
Ich hatte/habe hier mit GHDL auch ein Problem mit einer DLL vom Xilinx 
Spartan3. Ich habe dann einen Wrapper drum gebaut und schalte fuer die 
Simulation eine 'hand-made' PLL/DLL zu (ist nur jeweils eine Zeile 
auskommentieren). Damit kann ich dann leben. Aber mit diesem Drama lebe 
ich jetzt schon seit ca. 3 Jahren recht gut... Ist halt nur eine Zeile 
die sich zwischen Implementierung und Simulation unterscheidet, das 
krieg' ich noch gebacken...

[Duke Scarring (Gast)]

Andreas B. schrieb:
> Lediglich eine Warnung beim
> kompilieren der Stratixii_atoms.vhd.
Wie lautet die?
Ansonsten sieht Dein .do-File ganz gut aus.

Achte auf die "not bound"-Warnungen. In meiner modelsim.ini hab ich die 
zum Fehler hochgestuft:

[msg_system]
; Component instance $$$ : $$$" is not bound.
error=3473

berndl schrieb:
> Ich habe dann einen Wrapper drum gebaut und schalte fuer die
> Simulation eine 'hand-made' PLL/DLL zu (ist nur jeweils eine Zeile
> auskommentieren).
Dafür kann man auch einen generic von der Testbench aus durchreichen...

Duke

[berndl (Gast)]

Duke Scarring schrieb:
> Dafür kann man auch einen generic von der Testbench aus durchreichen...

Jepp, das ist dann auch mittlerweile meine Version 2 :o)

[Andi (loopy83)]

Hallo zusammen,
 
Vielen Dank für die Hinweise.
 
Die stratixii_atoms.vhd meldet folgenden Fehler, ist also auf jeden Fall 
verbunden.

# ** Warning: [6] /asic/app/altera/quartusII_10.0_lnx/quartus/eda/sim_lib/stratixii_atoms.vhd(14686): (vcom-1288) VITAL timing generic "tpd_datainglitch_dataout" port specification "datainglitch" does not denote a port.

 
Ich habe gerade die PLL nochmal in einer anderen Version erstellen 
lassen und nochmal alles durchlaufen.
Bisher habe ich mit der 10.0 gearbeitet und habe es nun mit der 11.1 
wiederholt. Genau das gleiche Verhalten.
Takt liegt an, Libs sind scheinbar alle ordentlich da, Taktausgang 
bleibt auf ‚X‘ und locked bleibt beharrlich auf 0.
 
Den PLL-Ausgang einfach im Testbench mit simulieren halte ich für keine 
gute Idee. Immerhin wollte ich nach der functional-Simulation auch noch 
das Timing untersuchen. Wollte schon gerne den Code, wie ich ihn 
simuliere, 1zu1 auch implementieren.
 
Kann doch aber nicht wahr sein, dass ich mich an einer PLL tagelang 
aufhalten muss… das ist echt sehr ärgerlich.
 
Vielen Dank!
Andreas

[Duke Scarring (Gast)]

Andreas B. schrieb:
> Takt liegt an, Libs sind scheinbar alle ordentlich da, Taktausgang
> bleibt auf ‚X‘ und locked bleibt beharrlich auf 0.
Vielleicht hilft Dir das weiter:
http://www.altera.co.uk/support/kdb/solutions/rd04112011_852.html

Duke

[Andi (loopy83)]

Ich habe gerade nochmal den Versuch mit dem EDA Netlist Writer 
unternommen.
Meine do-Datei sieht wie folgt aus:

quit -sim
cd /pfad/
 
vlib altera
vmap altera altera
vcom -work altera -2002 -explicit /asic/app/altera/quartusII_11.1_lnx/quartus/eda/sim_lib/altera_primitives_components.vhd
vcom -work altera -2002 -explicit /asic/app/altera/quartusII_11.1_lnx/quartus/eda/sim_lib/altera_primitives.vhd
vlib altera_mf
vmap altera_mf altera_mf
vcom -work altera_mf -2002 -explicit /asic/app/altera/quartusII_11.1_lnx/quartus/eda/sim_lib/altera_mf_components.vhd
vcom -work altera_mf -2002 -explicit /asic/app/altera/quartusII_11.1_lnx/quartus/eda/sim_lib/altera_mf.vhd
vlib stratixii
vmap stratixii stratixii
vcom -work stratixii -2002 -explicit /asic/app/altera/quartusII_11.1_lnx/quartus/eda/sim_lib/stratixii_atoms.vhd
vcom -work stratixii -2002 -explicit /asic/app/altera/quartusII_11.1_lnx/quartus/eda/sim_lib/stratixii_components.vhd
vlib lpm
vmap lpm lpm
vcom -work lpm -2002 -explicit /asic/app/altera/quartusII_11.1_lnx/quartus/eda/sim_lib/220pack.vhd
vcom -work lpm -2002 -explicit /asic/app/altera/quartusII_11.1_lnx/quartus/eda/sim_lib/220model.vhd
vlib sgate
vmap sgate sgate
vcom -work sgate -2002 -explicit /asic/app/altera/quartusII_11.1_lnx/quartus/eda/sim_lib/sgate_pack.vhd
vcom -work sgate -2002 -explicit /asic/app/altera/quartusII_11.1_lnx/quartus/eda/sim_lib/sgate.vhd
 
vlib work
vcom  netlist.vho
vcom testbench.vhd
vsim -gui sim_dut
add wave *

 
Nach dem kompilieren der Libs und dem run –all Befehl, kommt dann nach 
60ns diese Fehlermeldung.

# ** Note: StratixII PLL is enabled
#    Time: 0 ns  Iteration: 1  Instance: /sim_dut/DUT/\I0_pll333|altpll_component|pll\
# ** Fatal: (SIGFPE) Floating point exception.
#    Time: 60 ns  Iteration: 8  Process: /sim_dut/DUT/\I0_pll333|altpll_component|pll\/SCHEDULE File: /asic/app/altera/quartusII_10.0_lnx/quartus/eda/sim_lib/stratixii_atoms.vhd
# Fatal error in Process SCHEDULE at /app/altera/quartusII_10.0_lnx/quartus/eda/sim_lib/stratixii_atoms.vhd line 7494
#

Leider weiss ich damit nichts so recht anzufangen. Nur wieder betrifft 
es die stratixii_atoms.vhd, aber an anderer Stelle als die Warnung.
 
Kann mir jemand sagen, wie ich diese Meldungen zu interpretieren habe?
 
Vielen Dank!
Andreas

[Andi (loopy83)]

Ich habe die Lösung gefunden.
Scheinbar muss man bei der Simulation einer PLL den Maßstab auf ps 
stellen.

Bei vsim -t ns kommt er zu keinem Ergebnis bzw. bringt eine 
Fehlermeldung.
Bei vsim -t ps läuft alles.

Und da soll noch jemand sofort drauf kommen :-(

[D. I. (Gast)]

Andreas B. schrieb:
> Bei vsim -t ns kommt er zu keinem Ergebnis bzw. bringt eine
> Fehlermeldung.
> Bei vsim -t ps läuft alles.
>
> Und da soll noch jemand sofort drauf kommen :-(

Oh ja das sind bei manchen Cores beliebte Fehler. Die muss man einmal 
erfahren haben und sich notieren, dass so etwas bei einer Simulation die 
Fehlerquelle sein könnte