Frage zu TB: Kann 'procedure' rekursiv aufgerufen werden?

[berndl (Gast)]

Hallo ihr VHDL-Goetter :o)

ich habe in einem Simulationspackage eine procedure, die mir den an das 
FPGA angeschlossenen Mikrocontroller spielt:

--
-- Write data to the FPGA via the EMIF interface
--
procedure uc_wr_proc (signal nCS : out std_logic_vector (3 downto 0);
                      signal nWR : out std_logic;
                      signal DQM : out std_logic_vector (1 downto 0);
                      signal BADD : out std_logic_vector (1 downto 0);
                      signal ADDR : out std_logic_vector (16 downto 0);
                      signal DATA : out std_logic_vector (15 downto 0);
                      variable addr_in : in std_logic_vector (15 downto 0);
                      variable data_in : in std_logic_vector (31 downto 0)
                     ) is
   begin
      -- und so weiter und so fort...

Funktioniert prima. Jetzt moechte ich die zu simulierende HW auf eine 
alte Plattform zurueck portieren. Da gibt es aber nur 128 Adressen fuer 
ADDR. Also wuerde ich 'bank-switching' in der 'alten' uC-SW 
implementieren um mehrere 128x32bit Werte im FPGA beschreiben zu 
koennen.
Warum ich das will: Das hehre Ziel ist, dass die ca. 100 Besitzer der 
alten HW dieselbe fuer den neuen Design nicht wegschmeissen muessen 
(Kosten ca. 1kEUR pro Kiste).

Um jetzt nicht die eigentliche TB aendern zu muessen, koennte ich:
Als erstes in der procedure uc_wr_proc auf die passende Bank umschalten. 
Um das nicht in einer extra procedure machen zu muessen, wuerde ich 
gerne als ersten Funktionsblock in o.g. procedure einen Aufruf ala:

procedure uc_wr_proc (signal nCS : out std_logic_vector (3 downto 0);
                      signal nWR : out std_logic;
                      signal DQM : out std_logic_vector (1 downto 0);
                      signal BADD : out std_logic_vector (1 downto 0);
                      signal ADDR : out std_logic_vector (16 downto 0);
                      signal DATA : out std_logic_vector (15 downto 0);
                      variable addr_in : in std_logic_vector (15 downto 0);
                      variable data_in : in std_logic_vector (31 downto 0)
                     ) is
   begin
      if current_bank /= new_bank then  -- Pseudocode!
         uc_wr_proc (........, spezifische_addr_in, neue_bank); -- Ein bestimmtes Register in der HW beschreiben um die Bank umzuschalten
      end if;
      .....

platzieren, also die procedure 'uc_wr_proc' rekursiv aufrufen. Frage: 
Geht das in VHDL? Hat da jemand Erfahrung/nen Tipp?

[berndl (Gast)]

hmm, ich hab' jetzt mal eine Nacht darueber geschlafen und jetzt 
folgendes probiert:

procedure uc_wr_proc (signal nCS : out std_logic_vector (3 downto 0);
                      signal nWR : out std_logic;
                      signal DQM : out std_logic_vector (1 downto 0);
                      signal BADD : out std_logic_vector (1 downto 0);
                      signal ADDR : out std_logic_vector (16 downto 0);
                      signal DATA : out std_logic_vector (15 downto 0);
                      variable addr_in : in std_logic_vector (15 downto 0);
                      variable data_in : in std_logic_vector (31 downto 0)
                     ) is
   variable tmp_addr_in : std_logic_vector (15 downto 0) := x"007F";
   variable tmp_data_in : std_logic_vector (31 downto 0) := x"0000_0001";
   begin
      uc_wr_proc (nCS, nWR, DQM, BADD, ADDR, DATA, tmp_addr_in, tmp_data_in);
      -- und so weiter...

Funzt mit 'ghdl' aber leider nicht, Fehlermeldung ist (zur Laufzeit, 
also ghdl -r ...):

./tb_hugo:error: invalid memory access (dangling accesses or stack size too small)

Also scheint der rekursive Aufruf nicht so/so einfach zu 
funktionieren...

Naja, mal weiter basteln und probieren...

[Reinhard Kern (Gast)]

Hallo,

meines Wissens gibt es keine rekursive Hardware, für n Aufrufe müssten 
die Gatter usw. auch n-mal vorhanden sein, und ausserdem ist n nicht 
irgendwie begrenzt, aber unendliche Hardware gibt es auch nicht. Ein 
Stacküberlauf ist also auch nicht verwunderlich.

Einen gewissen Sinn könnte das nur machen als Logikblock, dessen Ausgang 
mit einem externen Takt immer wieder auf den Eingang rückgeführt wird, 
aber das müsste ja initialisiert werden und überhaupt dürfte das die 
Möglichkeiten automatischer Synthese überfordern.

Rekursivität ist ein völlig überschätztes Konzept und eigentlich nur in 
der Theorie von Vorteil, in der praktischen Ausführung sind allgemein 
Schleifen oder ein anderer Ersatz weit effektiver, auch in der Software.

Gruss Reinhard

[berndl (Gast)]

Reinhard Kern schrieb:
> meines Wissens gibt es keine rekursive Hardware

TB, also nur fuer Simulation gedacht!

Ich hab's jetzt mal etwas erweitert:

procedure uc_wr_proc (signal nCS : out std_logic_vector (3 downto 0);
                      signal nWR : out std_logic;
                      signal DQM : out std_logic_vector (1 downto 0);
                      signal BADD : out std_logic_vector (1 downto 0);
                      signal ADDR : out std_logic_vector (16 downto 0);
                      signal DATA : out std_logic_vector (15 downto 0);
                      variable addr_in : in std_logic_vector (15 downto 0);
                      variable data_in : in std_logic_vector (31 downto 0)
                     ) is
   variable tmp_addr_in : std_logic_vector (15 downto 0) := x"007F";
   variable tmp_data_in : std_logic_vector (31 downto 0) := x"0000_0001";
   begin
      uc_wr_temp (nCS, nWR, DQM, BADD, ADDR, DATA, tmp_addr_in, tmp_data_in);
      uc_wr_temp (nCS, nWR, DQM, BADD, ADDR, DATA, addr_in, data_in);
   end procedure;

Die procedure 'uc_wr_temp' ist die ehemalige 'uc_wr_proc'. Funzt auch 
nicht, bin aber noch am analysieren, was da schief geht. Dass der erste 
Ansatz (rekursiv) aufrufen schief ging, das kann ich mir mittlerweile 
erklaeren. Warum's jetzt noch haengt, muss ich halt mal weiter suchen...

[berndl (Gast)]

argh, ich habe die Simulation zu schnell abgebrochen...

Die obige Loesung funktioniert natuerlich wunderbar (also mit den 2x 
'uc_wr_temp' Aufrufen). Also vergessen wir die urspruengliche Frage am 
besten...

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Reinhard Kern schrieb:
> meines Wissens gibt es keine rekursive Hardware, für n Aufrufe müssten
> die Gatter usw. auch n-mal vorhanden sein, und ausserdem ist n nicht
> irgendwie begrenzt,
Doch, genau das ist der Trick an rekursiven Prozeduren: sie müssen 
irgendwann fertig werden. Am besten vor der Stack zuende ist.

> aber unendliche Hardware gibt es auch nicht.
Wenn eine Prozedur zur Synthesezeit eine begrenzte und definierte 
Stacktiefe benötigt, dann sollte sogar das Umsetzen in Hardware gehen. 
Das ist dann ja nichts anderes als eine Schleife bekannter Länge.

Muss ich bei Gelegenheit mal ausprobieren, ob die Synthesizer schon so 
weit sind... ;-)

[Marcus H. (mharnisch)]

Lothar Miller schrieb:
> Muss ich bei Gelegenheit mal ausprobieren, ob die Synthesizer schon so
> weit sind... ;-)

Also Synopsys DC ist schon seit mindestens 15 Jahren so weit. Siehe auch 
die beliebte rekursive ld() Implementierung, welche dank dieser 
Eigenschaft die einzige ist, die auch in Deklarationen eingesetzt werden 
kann.

Seit mindestens zehn Jahren sind Syntheseprogramme in der Lage, Logik 
automatisch von Iteration nach Rekursion zu transformieren. Man muss 
sich daher nicht mehr das Hirn verknoten, wenn man eine "rekursive 
Implementierung" haben moechte.

--
Marcus

[netseal (Gast)]

Rekursionen können Probleme sehr vereinfachen.
Wenn man für jeden rekursiven Aufruf eine weitere Scheleife 
verschachteln muss, so ist das gelinde gesagt "Mist"!

[SuperWilly (Gast)]

Nettes Beispiel für Rekursion in der Synthese:
http://www.alse-fr.com/archive/Factorial.pdf

[berndl (Gast)]

Hi zusammen,

also so wie hier: Beitrag "Re: Frage zu TB: Kann 'procedure' rekursiv aufgerufen werden?" 
beschrieben funktioniert das (also einen Wrapper um die eigentliche 
procedure). Nur will ich ja nicht jedesmal erst die 'bank' umschalten, 
sondern nur bei Bedarf, also wenn neue 'bank' ungleich alter 'bank', 
dann soll der zusaetzliche Schreibzugriff stattfinden.

Ich habe jetzt mal im vhdl-package ein Signal

signal last_addr_in : std_logic_vector (15 downto 0) := (others => '0');

 definiert.
Wenn ich jetzt in meiner procedure 'last_addr_in' mit 'addr_in' 
vergleichen wuerde, dann koennte ich den Schreibzugriff selektiv, also 
nur wenn noetig, machen.
Sieht jetzt so aus:

  procedure uc_wr_proc (signal nCS : out std_logic_vector (3 downto 0);
                    signal nWR : out std_logic;
                         signal DQM : out std_logic_vector (1 downto 0);
                         signal BADD : out std_logic_vector (1 downto 0);
                 signal ADDR : out std_logic_vector (16 downto 0);
                 signal DATA : out std_logic_vector (15 downto 0);
                 variable addr_in : in std_logic_vector (15 downto 0);
                 variable data_in : in std_logic_vector (31 downto 0)
                ) is
      variable tmp_addr_in : std_logic_vector (15 downto 0) := x"007F";
      variable tmp_data_in : std_logic_vector (31 downto 0) := x"0400_100B";
  begin
      if addr_in (15 downto 7) = b"0000_0000_0" then
         tmp_data_in := (others => '0');
         uc_wr_temp (nCS, nWR, DQM, BADD, ADDR, DATA, tmp_addr_in, tmp_data_in);
      else
         tmp_data_in := (0 => '1', others => '0');
         uc_wr_temp (nCS, nWR, DQM, BADD, ADDR, DATA, tmp_addr_in, tmp_data_in);
      end if;
      last_addr_in <= addr_in;   -- HIER DER KNACKPUNKT!
      uc_wr_temp (nCS, nWR, DQM, BADD, ADDR, DATA, addr_in, data_in);
  end procedure;

Also am Ende der procedure merke ich mir die letzte Adresse, das koennte 
ich dann (wenn es funktionieren wuerde) im 'if' mit einbeziehen (also ob 
ich den 'uc_wr_temp()' machen muss oder nicht.

Jetzt kriege ich leider in GHDL folgende Fehlermeldung:

ghdl -m --workdir=work -P/......./unisim --ieee=synopsys -fexplicit tb_top_hugo
../tb_top_hugo_sim_pkg.vhd:255:7: signal "last_addr_in" is not a variable to be assigned

Das ist die Zeile

      last_addr_in <= addr_in;

Nun zu der eigentlichen Frage: Kann ich sowas wie ein 'globales' Signal 
im Package definieren und in einer procedure verwenden? (Anstelle 
'global' waere auch ein 'static' (fuer C-Programmierer) moeglich)...

Hat da jemand 'nen Tipp fuer mich?

[berndl (Gast)]

so, nach gefuehlt ein paar hundert Aenderungen in der TB funktioniert 
das ganze jetzt so:

procedure uc_wr_proc (signal nCS : out std_logic_vector (3 downto 0);
   signal nWR : out std_logic;
   signal DQM : out std_logic_vector (1 downto 0);
   signal BADD : out std_logic_vector (1 downto 0);
   signal ADDR : out std_logic_vector (16 downto 0);
   signal DATA : out std_logic_vector (15 downto 0);
   variable last_addr_in : inout std_logic_vector (15 downto 0); -- NEU!
   variable addr_in : in std_logic_vector (15 downto 0);
   variable data_in : in std_logic_vector (31 downto 0)
  ) is
   variable tmp_addr_in : std_logic_vector (15 downto 0) := x"007F";
   variable tmp_data_in : std_logic_vector (31 downto 0);
begin
   if addr_in (15 downto 7) /= last_addr_in (15 downto 7) then
      if addr_in (15 downto 7) = b"0000_0000_0" then
         tmp_data_in := (others => '0');
         uc_wr_temp (nCS, nWR, DQM, BADD, ADDR, DATA, tmp_addr_in, tmp_data_in);
      else
         tmp_data_in := (0 => '1', others => '0');
         uc_wr_temp (nCS, nWR, DQM, BADD, ADDR, DATA, tmp_addr_in, tmp_data_in);
      end if;
   end if;
   uc_wr_temp (nCS, nWR, DQM, BADD, ADDR, DATA, addr_in, data_in);
   last_addr_in := addr_in;
end procedure;

Also ich habe in meinem Stimuli-Prozess der TB eine variable 'last_addr' 
eingefuegt, dann in jedem (auch indirekten) Aufruf der procedure 
'uc_wr_proc' diesen Parameter als inout hinzugefuegt.
'last_addr' wird in der procedure gesetzt, ich muss also nicht noch in 
der TB da irgendwelche weiteren statements einbauen. Naja, so funzt es 
auf jeden Fall...

Funzt zwar, aber mit einer 'globalen' Variablen waere es weniger 
Tipperei gewesen... Also wenn da jemand (fuer zukuenftige Sachen) einen 
Tipp haette...

[berndl (Gast)]

PS: Danke an alle die bisher hier gepostet haben. Hat mir beim konkreten 
Problem zwar nicht 'ueber den Jordan' geholfen, aber da waren einige 
interessante Anmerkungen dabei. Also merci!