VHDL: Signal um beliebige Takte verzögern

[Till F. (Gast)]

Hey,

ich möchte ein Signal um mehrere Takte verzögern. Meine Vorgehen ist 
folgendes:

delayme : process (clk)
if clk'event and clk = '1' then
  signal_d3 <= signal_d2;
  signal_d2 <= signal_d1;
  signal_d0 <= signal;
end if;

Ich bin bei der Fehlersuche hier im Forum auf einen anderen Thread 
gestoßen, wo das genauso gemacht wird und anscheinend kein Problem gibt: 
Beitrag "VHDL: Signal um beliebige Takte verzögern"

Bei mir werden bei der Synthese aber irgendwie die zwischen signal und 
signal_d3 liegenden Stufen wegoptimiert: das Ganze wird auf einem FPGA 
implementiert, und der Xilinx FPGA-Editor zeigt mir im fertigen Design 
an, dass "signal" lediglich über ein Synchronisierungselement mit 
"signal_d3" verbunden ist. Tatsächlich hat das Signal auch nur 1 Takt 
Verzögerung, wenn man den FPGA konfiguriert. Es gibt sogar keinen 
Unterschied, wenn ich den Prozess abändere:

delayme : process (clk)
if clk'event and clk = '1' then
  signal_d3 <= signal;
end if;

Kann hier jemand einen Gedankenfehler sehen, oder weiß sonstwie Rat? Ich 
kann mir nicht recht vorstellen, dass eine derartige Optimierung, welche 
ja das Verhalten beeinflusst, wirklich stattfindet.

[Maik H. (littlechip)]

Till F. schrieb:

>

> delayme : process (clk)
> if clk'event and clk = '1' then
>   signal_d3 <= signal_d2;
>   signal_d2 <= signal_d1;
>   signal_d0 <= signal;
> end if;
>

Guck dir das noch mal ganz genau an...

[Till F. (Gast)]

Wenn du meinst, dass der Syntax nicht stimmt (begin, end process, ... 
fehlt), dann ist das nicht das Problem, steht in meinem original-VHDL 
natürlich drin (kanns ja auch synthetisieren). Hab hier nur schnell das 
Prinzip rein getippt, weil der Originalquelltext bischen verwirrender 
ist:

transfer_control : process (clk, rst)
  ...
begin

  if rst = '1' then
    ...
  elsif clk'event and clk = '1' then
    ...  
    for i in 0 to n-1 loop
      wr_en_from_ctrl(i) <= wr_en_from_ctrl_delay2(i);
      wr_en_from_ctrl_delay2(i) <= wr_en_from_ctrl_delay1(i);
      wr_en_from_ctrl_delay1(i) <= wr_en_from_ctrl_delay0(i);
      wr_en_from_ctrl_delay0(i) <= A and B and C;
    end loop;
    ...
  end if;

end process;

Wenn du glaubst, dass mit dieser Verkettung das Signal immer innerhalb 
eines Taktes von signal->signal_d1->...->signal_d3 wandert ist das ja 
nicht richtig: Signale ändern ja erst ganz am Ende vom Prozess ihren 
Wert und somit gibt es die nächeste Änderung erst beim nächsten 
clk'event.

Ich sehe nun auf jeden Fall auch nach einem zweiten Blick kein Problem, 
wäre schön, wenn du genauer sagst was falsch ist, wenn es wirklich so 
offensichtlich ist :D

[Till F. (Gast)]

Achso, und falls du meintest, dass ich "signal_d1 <= signal_d0" auch 
vergessen habe liegts genauso daran, dass es im Beispiel nur ums Prinzip 
ging :D

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

> weil der Originalquelltext bischen verwirrender ist: ...
Der ist nicht verwirrender, sondern komplett anders.

>>> Signale ändern ja erst ganz am Ende vom Prozess ihren Wert
Fast richtig. Signale übernehmen den zuletzt zugewiesenen Wert am Ende 
von Prozessen oder beim nächsten wait.
Und weil immmer noch nicht der gesamte Quelltext (nicht mal die 
Signaldefinitionen) zu sehen ist, bleibt nur Schulterzucken...

> Ich sehe nun auf jeden Fall auch nach einem zweiten Blick kein Problem,
Ich auch nicht, aber ich weiß, dass Synthesetools mit bestimmten 
Beschreibungen nichts anfangen können. Eine recht einfache ist z.B.
   a <= b after 10 ns;
Das wird schon auch synthetisiert, nur eben ohne die Verzögerung. Und 
deine for-Schleife sieht recht grenzwertig aus. Was bekommst du für 
Meldungen/Warnungen bei der Synthese? Stolpert der Synthesizer irgendwo?

[Till F. (Gast)]

> Der ist nicht verwirrender, sondern komplett anders.
> Und deine for-Schleife sieht recht grenzwertig aus.
Naja - Zweck der For-Schleife erklärt sich mit dem Typ von 
wr_en_from_ctrl:

type mytype is array ( n-1 downto 0 ) of std_logic_vector ( m-1 downto 0 );

wobei m, n Parameter sind. Ich denke nicht, dass das wirklich anders ist 
als das was ich mit meiner zugegeben fehlerhaften und somit schlechten 
Vereinfachung sagen wollte.

> a <= b after 10 ns;
> Das wird schon auch synthetisiert, nur eben ohne die Verzögerung.
Mir ist schon klar, dass es bestimmte Dinge gibt, die nicht 
synthetisiert werden können :)

> Was bekommst du für
> Meldungen/Warnungen bei der Synthese? Stolpert der Synthesizer irgendwo?
Natürlich einige die nichts mit der Sache zu tun haben (instantiating 
black box module, ...) aber auch ein paar Sachen bezüglich den obigen 
Signalen. Jedoch nur für einen Teil davon: nämlich für die, welche zu 
Testzwecken auf logic0 liegen. Hier ist es ja völlig richtig, dass diese 
während der Synthese verschwinden.

Mir ist klar, dass mir auf dieser Ebene niemand ohne mehr Sourcecode und 
Reports weiterhelfen kann. Aber das ist einfach zu viel für so ein Forum 
(außer es ist jemandem richtig langweilig). Hatte gehofft, dass ich 
hier auf ein weniger spezifisches Problem gestoßen bin. Wenn mein 
Vorgehen zum Verzögern der Signale prinzipiell richtig ist, ist meine 
Frage eigentlich beantwortet... und eigentlich müsste es kann klappen 
grummel

Leider jetzt schon arg spät in Syd, muss ich halt morgen weitersuchen :(

[Kai (Gast)]

Hallo Till,

hast Du an das ELSE in der IF Anweisung gedacht?

Ohne das ELSE kann es durch das Synthese Tool auch schnell mal zu einem 
ungewollten Latch kommen.

Gruß Kai

[Jan M. (mueschel)]

Till, zeig doch mal bitte die Meldungen / die Gatteransicht aus der du 
schließt, dass da optimiert wird. In deinem letzten Codebeispiel steht 
da <= A and B and C - das ist aber in jedem Schleifendurchlauf das selbe 
- gewollt?

Kai: Das ist nur in kombinatorischen Prozessen nötig, nicht aber in 
getakteten.

[Till F. (Gast)]

> zeig doch mal bitte die Meldungen / die Gatteransicht aus der du
> schließt, dass da optimiert wird.

Ich schließe das ja aus dem placed & routetet Design, wie ich es im 
FPGA-Editor betrachten kann. Ich habe mal einen Screenshot gemacht, wo 
man sieht, dass zwischen /wr_en_from_ctrl_delay0(0)(0)/ und 
/wr_en_from_ctrl_delay2(0)(0)/ lediglich 1 Flipflop liegt, ansonsten 
verlaufen die Signale ohne weiter Synchronisationsstufen. Wie gesagt 
sieht das Ergebnis im FPGA-Editor sogar genauso aus, wenn ich die beiden 
Zeilen

wr_en_from_ctrl_delay2(i) <= wr_en_from_ctrl_delay1(i);
wr_en_from_ctrl_delay1(i) <= wr_en_from_ctrl_delay0(i);

durch diese ersetze:

wr_en_from_ctrl_delay2(i) <= wr_en_from_ctrl_delay0(i);

Ansonsten: Ich bin jetzt auch alle Warnungen bezueglich dieser Signale 
los geworden, indem ich alles, was ich zum Testen mal mit konstanten 
Werten versehen habe mit den eigentlich vorgesehenen Registern verbunden 
habe. Im Synthesis-Report finde ich jetzt sogar:

Found 16-bit register for signal <wr_en_from_ctrl_delay0>.
Found 16-bit register for signal <wr_en_from_ctrl_delay1>.
Found 16-bit register for signal <wr_en_from_ctrl_delay2>.

Aber von "wr_en_from_ctrl_delay1" ist halt nirgendwo etwas zu finden! 
Mir ist klar, dass sich die Namen der Signale veraendern koennen, aber 
da ich ja wr_en_from_ctrl__delay0 und wr_en_from_ctrl__delay2 finde und 
nichts dazwischen liegt, scheint es mir schon so zu sein, dass 
wr_en_from_ctrl_delay1 einfach nicht existiert!

[Jan M. (mueschel)]

Du bist also in einem Xilinx FPGA zuhause? Und die 
wr_en_from_ctrl_delay* werden nicht mit dem reset zurueckgesetzt?

Dann hat ISE die Kette von Flipflops durch ein Schieberegister ersetzt - 
das muesste eigentlich im Report auch auftauchen, such mal nach "shift 
register".

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

> Dann hat ISE die Kette von Flipflops durch ein Schieberegister ersetzt -
Etwas exakter: durch ein Schieberegister, das in einer LUT realisiert 
worden sein könnte. Aber das deckt sich nicht mit der Mesuung am 
implementierten Design:
>>>>>> Tatsächlich hat das Signal auch nur 1 Takt
>>>>>> Verzögerung, wenn man den FPGA konfiguriert.

> Ich schließe das ja aus dem placed & routetet Design
Mir ist es noch nie passiert, dass FFs so offensichtlich wegoptimiert 
wurden. Da steckt doch irgendwas im Busch...