Hey,
ich möchte ein Signal um mehrere Takte verzögern. Meine Vorgehen ist
folgendes:
1
delayme:process(clk)
2
ifclk'eventandclk='1'then
3
signal_d3<=signal_d2;
4
signal_d2<=signal_d1;
5
signal_d0<=signal;
6
endif;
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:
1
delayme:process(clk)
2
ifclk'eventandclk='1'then
3
signal_d3<=signal;
4
endif;
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.
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:
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
> 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?
> 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:
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 :(
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
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.
> 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
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!
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".
> 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...