Testbench / PROCEDURE

OP #3928224
Lesenswert?

Hallo allerseits,

mal wieder bei der Umsetzung eines Verilog DDR2-Modells in VHDL.

Da hab' ich mir selbst ein Bein gestellt. Im Verilog-Modell waren 
mehrere tasks, die ich als PROCEDURE "übersetzt" habe, ohne dabei zu 
realisieren, daß diese Tasks Signale aus dem Toplevel der Testbench 
setzen müssen.

Das geht natürlich nur, wenn die PROCEDURE innerhalb eines PROCESS 
definiert ist.

So funktioniert's dann auch:
1
init_proc : PROCESS
2
   PROCEDURE init IS
3
   BEGIN
4
      ...
5
   END init;
6
BEGIN
7
   WAIT UNTIL rising_edge(clk);
8

9
   IF r /= '0' THEN
10
      init;
11
      r <= '0';
12
   END IF;
13
END PROCESS;

Das scheint auch so zu funktionieren. Bloß: "schön" ist anders - anstatt 
einfach die Prozedur aufzurufen, muß ich nun an "r" wackeln, zusätzlich 
das Ding kopieren, wenn ich's in mehreren Prozessen brauche. Irgendwie 
nicht so, wie ich mir das gedacht habe.

Gibt's 'ne "schönere" Möglichkeit?

Danke!
OP #3928346
Lesenswert?

Lothar Miller schrieb:
> Markus F. schrieb:
>> daß diese Tasks Signale aus dem Toplevel der Testbench setzen müssen.
> Wie ist das gemeint? Und warum sollte das eine Procedure nicht können?

Da war ich wohl ein bißchen zu knapp mit meiner Fragestellung, sorry. Es 
handelt sich um ein - ursprünglich von Micron in Verilog geschriebenes - 
DDR2-Modell, das ich gerne als VHDL in meine Testbench einhängen würde. 
So hätt' ich's gern gehabt:
1
-- stark verkürzt
2

3
ENTITY ddr2 IS
4
   ...
5
END ENTITY ddr2;
6

7
ARCHITECTURE Behaviour OF ddr2 IS
8
   SIGNAL s1  : INTEGER;
9
   SIGNAL s2  : INTEGER;
10

11
   PROCEDURE init IS
12
   BEGIN
13
      s1 <= 0;      -- setzt Signale der ARCHITECTURE
14
      s2 <= 0;
15
   END init;
16
BEGIN
17
   init;
18

19
   -- "Rest" des DDR2-Modells
20
   ...
21
END Behaviour;

Quartus frißt das klaglos, aber ModelSim meckert:

# Error: ... : Cannot drive signal "s1" from procedure "init".

und besteht darauf, daß PROCEDUREs, die externe Signale setzen, 
innerhalb eines PROCESS definiert und aufgerufen werden - dann tut's 
(gefällt mir aber aus den o.g. Gründen nicht).
Gast #3928376
Lesenswert?

Das mit Signalen und Prozeduren ist komplizierter als
in den meissten Büchern beschrieben.

Dein Problem hängt damit zusammen, dass in einer Prozedur
bzw. in den Subprozeduren potenziell Signal-Attribute beim
Zugriff verwendet werden können, Xilinx' ISE bzw. ISIM
ignoriert das (XSIM dagegen nicht!), ModelSIM hält sich an
die VHDL-Specs (QuartusII akzeptiert es auch, Diamond
ebenfalls?).

Du kannst das Problem glaube ich umgehen, indem du
in einer Prozedur nur auf Signale zugreifst, die in
der Prozedurausrufliste stehen. Bei dir also nicht auf
S1 bzw. S2 zugreifen oder dein INIT in
INIT(signal S1 : inout std_logic; ...) ...
änderst, Aufruf dann entsprechend.
OP #3928394
Lesenswert?

Sigi schrieb:
> Bei dir also nicht auf
> S1 bzw. S2 zugreifen oder dein INIT in
> INIT(signal S1 : inout std_logic; ...) ...
> änderst, Aufruf dann entsprechend.

Danke.

Das Problem hab' ich (u.A. dank Google-Nachhilfe) schon verstanden, 
bloß:

schöner wird's davon leider auch nicht ;). Ich muß entweder alle 
Signale, die gesetzt werden sollen (das sind an die 100) in die 
Parameterliste packen oder das Ding (mit den damit verbundenen 
Einschränkungen) in einem Prozeß definieren und dort aufrufen.

Meine Frage war, ob's nicht vielleicht doch einen Trick gibt, den ich 
noch nicht probiert bzw. gefunden habe ;).

Die Reset-Task des Modells (die genauso aussieht) war insofern kein 
Problem, als daß die nur an einer Stelle gebraucht wird (da ist das mit 
dem Prozeß kein Ding), "init" wird aber mehrfach aufgerufen und dafür 
such' ich eine "schöne" Lösung.

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren