[CALU] Re: Quartus nachschub
- From: Günther Wimpassinger <e0525147@xxxxxxxxxxxxxxxxxxxx>
- To: calu-ss2010-tuwien@xxxxxxxxxxxxx
- Date: Mon, 3 May 2010 19:16:27 +0200
Zitat von Elshuber Martin <e9825286@xxxxxxxxxxxxxxxxxxxx>:
Fragen:
1) Testbenches: ich hab massive probleme Testbenches laufen zu
lassen, immer wenn ich die RTL sim starte, meckert das model sim
etwas von wegen ich wende das package, die entity oä nichst.
Die lösung die files handisch zu kompilieren ist auf die Dauer auch
etwas mühsam. Hat jemand von euch Erfahurng?
Für eine Testbench verwende ich mehr oder weniger komplexe ".do"
Skripts. Habe dafür templates angelegt. Dabei ist das
"sim/mod_template" als Grundlage zum Testen einzelner Module gedacht
und "sim/tc_template" als Grundlage das Design als ganzes zu testen.
Dabei sollte man wie folgt vorgehen.
Modul-Test
-) Modul-Entity anlegen (z.B. "src/mymodule/mymodule_ent.vhd")
-) Modul-Architecture implementieren (t.B. "src/mymodule/mymodule_arch.vhd")
-) Das "sim/mod_template" nach "sim/mymodule" kopieren
-) Das File "sim/mymodule/mod_beh.do" entsprechend anpassen
--) Pfad der Testbench anpassen
"set TC_PATH mymodule"
--) Sourcedatein zum kompilieren hinzufügen (packages, entities, archs)
"vcom -work work ......"
-) Das File "sim/mymodule/mod_tb.vhd" nach seinen wünschen gestalten
und Testdaten eingeben.
-) Das File "sim/mymodule/mod_beh_conf.vhd" auf die richtige Entity stellen
-) Ins Verzeichnis "work" gehen und "vsim" (ModelSim) starten.
-) "do ../sim/mymodule/mod_beh.do" eingeben und <ENTER> drücken
Wenn ich nichts vergessen habe und ihr keine Fehler in den Sources
habt, dann werden alle Dateien kompiliert und die Simulation gestartet.
Allgemeint:
Der Befehl "vsim" im ".do"-File startet die Simulation.
"view wave" zeigt das Waveform-Fenster
"add wave" fügt Signale zum Waveform-Fenster hinzu (siehe btn_debounce)
"run -all" läuft die komplette Testbench durch (bis zum assert)
Wenn man will, kann man das auch löschen/ändern (bsp "run 150 us"
simuliere 150 Microsekunden)
Design-Test:
Die Vorgehensweise ist ähnlich wie beim Modul-Test:
-) Kopieren von "sim/tc_template" nach "sim/mymodule"
-) ".do" Files anpassen
--) "tc_beh.do" ist Verhaltenssimulation
--) "tc_post.do" ist Post-Layout Simulation
---) Hier sollte im Normalfall keine Änderung notwendig sein, und wenn
dann nur Aufgrund der testbench selbst
---) Für die Postlayout Simulation muss das PLL-Projekt vorher
mit Quartus kompiliert werden. Dabei ist das .do-Skript
so ausgelegt, dass es die Quartus-Timing information in
einem Unterverzeichnis erwartet, in dem Model-Sim ausgeführt
wird. Um das besser zu verstehen ein Mini-Workflow
in einer shell:
$> cd pisp/work
$> rm -rf *
$> cp ../quartus/pisp_pll.* .
$> quartus pisp_pll # im TILAB startquartus
# auf den "Play"-Button drücken und Quartus beenden
# jetzt gibt es ein Verz. "work/simulation" für Model-Sim
$> vsim
in vsim-shell:
do ../sim/testxx/tc_post.do #
-) Die "..._conf.vhd" Files müsse nicht geändert werden
-) Die Datei "tc_tb.vhd" anpassen (wird für behav und post-layout verwendet)
-) auch hier mit "do ../sim/....do" das entsprechende Skript ausführen
--) ACHTUNG: Post-Layout geht mit den freien Versionen nicht (im TILAB schon)
Sonstiges: Beide Templates funktionieren selbst auch. Einfach "do
../sim/mod_template/mod_beh.do" eintippen :).
2) Es gibt sicher eine elegantere lösung für folgendes problem;
type preds is array (15 downto 1) of boolean;
type preds16 is array (15 downto 0) of boolean;
v.preds ist ein pred16
d.preds ist ein preds
das ding ist nicht wirklich toll:
v.preds(15 downto 1):=( 15 => d.preds(15),
14 => d.preds(14),
13 => d.preds(13),
12 => d.preds(12),
11 => d.preds(11),
10 => d.preds(10),
9 => d.preds( 9),
8 => d.preds( 8),
7 => d.preds( 7),
6 => d.preds( 6),
5 => d.preds( 5),
4 => d.preds( 4),
3 => d.preds( 3),
2 => d.preds( 2),
1 => d.preds( 1));
wie gehts einfacher?
ADA-like (i muss NICHT extra definiert werden)
for i in d.preds'range loop
v.preds(i):=d.preds(i);
end loop;
VHDL ist sehr streng was die Typen betrifft. Da ich deinen Code bei mir
(noch) nicht kompilieren kann, hab ich das nicht ausprobiert.
Ich habe keine Ahnung wie gut oder schelcht es ist, die generischen
Typen zu verwenden (siehe Antwort von Wolfgang). In der Art und Weise,
wie du sie benutzt habe ich das noch nicht gesehen, bin aber auch nicht
wirklch erfahren.
Üblicherweise werden Bereiche oft so definiert:
-- in Packages
const DATA_WIDTH : natural := 32;
const PRED_WIDTH : natural := 16;
-- in Records/Ports/Signaldefintions
signal data : std_logic_vector(DATA_WIDTH-1 downto 0);
signal preds : std_logic_vector(PRED_WIDTH-1 downto 0);
Bei Signalen die aus einem Modul rausgehen oder in ein Modul reinkommen
habe ich es bis jetzt selten gesehen, dass man dafür (abgesehen von den
Records) eigene Typen definiert. Aber genaueres kann wohl nur Wolfgang
(oder Jakob Lechner) dazu sagen.
lg
Günther
Other related posts:
