Hallo,
zwei Fragen zum Verständnis der Verilog Sensitivitätslisten (falls man
diese in Verilog auch so nennt.)
1. In VHDL sind Sensitivitätslisten ja "nur" für die Simulation
relevant. In Verilog schreibt man so etwas
1
always@(posedgeclkornegedgereset)
2
if(!reset)
3
...
4
else
5
...
, d.h. hier bezieht ja auch die Synthese ihre Information über den
rising_edge(clk )aus der Sensitivitätsliste, richtig?
2. In oben genanntem Codebeispiel ist mir das Verhalten von reset nicht
ganz klar. Wenn wirklich nur bei einem negedge von reset (d.h.
flankensensitiv) reagiert werden würde und das reset bereits initial 0
ist, wäre die Anweisung danach quasi ein synchrones reset, da der "if
(!reset)" -Teil erst bei einem posedge clk ausgeführt werden würde. Das
gäbe Probleme z.B. bei clk gating.
Mir ist klar, dass ich das einfach z.B. bei ISE ausprobieren kann und
schauen, wie das FF angeschlossen wird. Das wäre dann allerdings erstmal
nur für ISE gültig. Mir geht es darum, wie dieses Konstrukt unabhängig
von Synthese-/Simulationstools generell definiert ist.
Gibt es dazu begründete Meinungen?
Ja, ich habe schon einge Verilog-Designs beschrieben und das als
low-aktiven asynchronen Reset benutzt. Meine Frage ist mehr, warum dann
da trotzdem "negedge" steht.
VHDL hotline schrieb im Beitrag #3972853:
> Ja, ich habe schon einge Verilog-Designs beschrieben und das als> low-aktiven asynchronen Reset benutzt. Meine Frage ist mehr, warum dann> da trotzdem "negedge" steht.
Weil die andere Flanke des Resets irrelevant ist, der Zustamd eines D-FF
ändert sich da ja nicht und muss also nicht neu berechnet werden.
Dass es ein Level-Reset ist, sieht man am IF Statement. Das ist bei VHDL
auch nicht anderes.
Wenn man versteht, dass die Sensitivliste in Verilog eigentlich ein Wait
for Statement ist, kann man sich eine equivalente Beschreibung auch in
VHDL ausdenken. Geht auch im Simulator, aber der Synthesizer erkennt
nicht mehr dass es auf ein D-FF abbildbar ist. Synplify Pro baut dann
ein eigentlich im D-FF vorhandenens Clockgate nochmal davor. Zeigt dass
alternative Beschreibungen die nicht dem Standardcodingstyle entsprechen
gefährlich sind.
Lattice User schrieb:> Weil die andere Flanke des Resets irrelevant ist, der Zustamd eines D-FF> ändert sich da ja nicht und muss also nicht neu berechnet werden.>
Eigentlich sollte beim reset überhaupt keine Flanke relevant sein,
sondern der Pegel.
> Dass es ein Level-Reset ist, sieht man am IF Statement. Das ist bei VHDL> auch nicht anderes.>
Nur dass in Verilog augenscheinlich erst eine Flanke des reset abgefragt
wird (negedge), statt zum Beispiel zu schreiben always@(posedge clk or
reset).
> Wenn man versteht, dass die Sensitivliste in Verilog eigentlich ein Wait> for Statement ist, kann man sich eine equivalente Beschreibung auch in> VHDL ausdenken.
Wenn es ein wait statement ist, wäre meine Auffassung, dass auf die
negative Flanke des reset gewartet wird. Und wenn es die nicht gibt weil
ich in der Simulation oder in echter Hardware den reset bereits initial
0 gesetzt habe (= keine Flanke) und ein Takt noch nicht verfügbar ist?
VHDL hotline schrieb im Beitrag #3972968:
>> Eigentlich sollte beim reset überhaupt keine Flanke relevant sein,> sondern der Pegel.
Du hast den Sinn von Sensitivity Listen in der Simulation nicht
verstanden. Der Prozess wird neu berechnet bei Änderungen der
aufgeführten Signalen, auch auch in VHDL.
Im Unterschied zu VHDL erlaubt Verilog noch eine etwas spezifischere
Definition der Änderung in der Form posedge oder negedge. Das ist alles!
Und beim asynchronen Reset ist nur die Änderung zum Aktiv, und der Level
des Resets bei einer Clockflanke entscheidend! In VHDL wird beim
normalen Codingstyle der Prozess bei anderen Flanke des Resets
überflüssergweise berechnet. Der Performanceverlust ist aber
vernachlässigbar.
Lattice User schrieb:> Du hast den Sinn von Sensitivity Listen in der Simulation nicht> verstanden. Der Prozess wird neu berechnet bei Änderungen der> aufgeführten Signalen, auch auch in VHDL.>
Mir ist schon klar, wozu eine Sensitivitätsliste in der Simulation da
ist. Meine Feststellung im ersten Post war ja aber schon, dass bei
Verilog die Sensitivitätsliste offensichtlich auch für die Synthese
benutzt wird, denn die Information über die Flanken"richtung" für clk
taucht sonst nirgends auf.
> Im Unterschied zu VHDL erlaubt Verilog noch eine etwas spezifischere> Definition der Änderung in der Form posedge oder negedge. Das ist alles!>> Und beim asynchronen Reset ist nur die Änderung zum Aktiv, und der Level> des Resets bei einer Clockflanke entscheidend!
Dann ist die Definition von "Änderung zum Aktiv" hier entscheidend. Auf
die Gefahr hin, mich zu wiederholen: Wenn mein reset initial 0 ist (Sim
oder HW), hat es nie eine Änderung von 1(inaktiv) -> 0(aktiv) gegeben.
Wenn gerade dieser Teil des Designs noch keinen Takt hat (clk gating),
wird auch der Level des Resets bei einer Taktflanke nicht ausgewertet.
Also würde kein (initialer) Reset stattfinden. Angeschlossene Module, an
welchen schon ein aktiver Takt anliegt, müssten undefinierte Werte von
dem Modul bekommen.
> In VHDL wird beim> normalen Codingstyle der Prozess bei anderen Flanke des Resets> überflüssergweise berechnet. Der Performanceverlust ist aber> vernachlässigbar.
Lothar Miller schrieb:>> Eigentlich sollte beim reset überhaupt keine Flanke relevant sein,>> sondern der Pegel.> Hatten wir schon im Beitrag "Re: Frage zur Lernkurve VHDL vs. Verilog"
Genau um die "Unlogiken" bzw. impliziten Annahmen in Verilog geht es.
Sind diese irgendwo festgelegt oder könnte das je nach
Synthesetool/Simulationstool anders sein (wenn nicht nach dem Prinzip
"wir machen es so wie alle es machen" vorgegangen würde)? Wenn ich
selbst einen Simulator/Synthesetool für Verilog schreiben wöllte, woran
halte ich mich dann?
VHDL hotline schrieb im Beitrag #3973071:
> Lattice User schrieb:>> Du hast den Sinn von Sensitivity Listen in der Simulation nicht>> verstanden. Der Prozess wird neu berechnet bei Änderungen der>> aufgeführten Signalen, auch auch in VHDL.>>>> Mir ist schon klar, wozu eine Sensitivitätsliste in der Simulation da> ist. Meine Feststellung im ersten Post war ja aber schon, dass bei> Verilog die Sensitivitätsliste offensichtlich auch für die Synthese> benutzt wird, denn die Information über die Flanken"richtung" für clk> taucht sonst nirgends auf.
Und das ist in VHDL genau so. Der Codingstyle für FF mit asynchronem
Reset benötigt da ebenfalls eine Sensitivityliste um vom Synthesizer
verstanden zu werden.
>> Dann ist die Definition von "Änderung zum Aktiv" hier entscheidend. Auf> die Gefahr hin, mich zu wiederholen: Wenn mein reset initial 0 ist (Sim> oder HW), hat es nie eine Änderung von 1(inaktiv) -> 0(aktiv) gegeben.> Wenn gerade dieser Teil des Designs noch keinen Takt hat (clk gating),> wird auch der Level des Resets bei einer Taktflanke nicht ausgewertet.> Also würde kein (initialer) Reset stattfinden. Angeschlossene Module, an> welchen schon ein aktiver Takt anliegt, müssten undefinierte Werte von> dem Modul bekommen.>
Der Simulator fängt bei allen Signalen mit undefined an! Die initiale
Zuweisung ist das erste Event!
Lattice User schrieb:> Der Codingstyle für FF mit asynchronem Reset benötigt da ebenfalls eine> Sensitivityliste um vom Synthesizer verstanden zu werden.
Kleine Korrektur: der Simulator braucht die Liste. Dem Synthesizer
reicht auch eine unvollständige oder falsche Liste...
Aber vor allem: in VHDL erkenne ich den getakteten Teil und damit das
Flipflop auf Anhieb. Und der Reset ist genauso erkennbar nicht
flankengesteuert.
Lattice User schrieb:> Der Simulator fängt bei allen Signalen mit undefined an!
Er fängt beim "linkesten" Wert der Aufzählung an. Beim std_logic_vector
ist das 'U', was korrekt 'uninitialized' bedeutet. Ein 'undefined' z.B.
von einer Buskollision wird im weiteren Testverlauf mit einem 'X'
dargestellt... :-)
Lothar Miller schrieb:> Lattice User schrieb:>> Der Codingstyle für FF mit asynchronem Reset benötigt da ebenfalls eine>> Sensitivityliste um vom Synthesizer verstanden zu werden.> Kleine Korrektur: der Simulator braucht die Liste. Dem Synthesizer> reicht auch eine unvollständige oder falsche Liste...
Wäre ich mir nicht so sicher, in Verilog ist das in den Codingstyles
klar vorgegeben.
>> Aber vor allem: in VHDL erkenne ich den getakteten Teil und damit das> Flipflop auf Anhieb. Und der Reset ist genauso erkennbar /nicht/> flankengesteuert.
Das ist in Verilog genauso.
In VHDL musst du schauen welches der beiden Signale im Block als Clock
bzw Reset verwendet wird, in Verilog musst du nach dem Reset schauen,
sollte gleiche das erste Statement im Block hergeben. Der
Sensitivityliste siehst du es ein beiden Fällen nicht an.
posedge in Verilog ist übrigens nicht das gleiche wie rising_edge in
VHDL. Übrigens auch nicht das gleiche wie clk.EVENT AND clk = '1'!
>> Lattice User schrieb:>> Der Simulator fängt bei allen Signalen mit undefined an!> Er fängt beim "linkesten" Wert der Aufzählung an. Beim std_logic_vector> ist das 'U', was korrekt 'uninitialized' bedeutet. Ein 'undefined' z.B.> von einer Buskollision wird im weiteren Testverlauf mit einem 'X'> dargestellt... :-)
Bei Verilog gibt es diese Unterscheidung nicht.
Hallo VHDL hotline,
Du hast eine interessante Diskussion losgetreten, zu der ich auch gerne
etwas beitragen möchte. Simulation und Synthese sind nunmal zwei
Verwendungen des gleichen Quelltexts. Und während ein Simulator
haargenau das ausführen kann, was da steht, sind die Möglichkeiten eines
Schaltungsgenerators bzw. der erzeugten Gatterschaltung limitiert. Das
von dir genannte Konstrukt wird in ein Flipflop mit asynchronem Reset
abgebildet, wenn die Zieltechnologie über so ein Element verfügt. Falls
nicht, dann geht ein Schaltungsgenerator auch mal her und schaltet einem
Flipflop ein Und-Gatter nach, das über den async Reset und ein zweites
Flipflop angesteuert wird. Kein Witz, hab ich schon mal gesehen. Aber
solange ein Flipflop mit async Reset in der Zieltechnologie existiert,
wird das verwendet, wenn die Pegelabfrage und die Flankenbedingung
zueinander passen, was in deinem Beispiel der Fall ist. Die
Spitzfindigkeit mit den "keine Flanke bei t=0" kann sich ein
Schaltungsgenerator nicht leisten.
Grüße,
Harald
hi kurze Frage an Lattice User:
Was ist denn der Unterschied zwischen rising_edge und posedge??
Ich würde das gerne wissen weil ich eigentlich immer mit posedge
arbeite.
Danke
Trundle Trollkönig schrieb:> hi kurze Frage an Lattice User:>> Was ist denn der Unterschied zwischen rising_edge und posedge??> Ich würde das gerne wissen weil ich eigentlich immer mit posedge> arbeite.>
Eine kleine Klarstellung: raising_edge gibt es in Verilog nicht.
VHDL hotline schrieb im Beitrag #3990620:
> rising_edge detektiert nur 0->1.>> posedge detektiert 0->1, x->1, z->1. Angeblich auch 0->x und 0->z.
Wieso angeblich, es ist so definiert!
IEEE Std 1364-2001 : 9.7.2
A negedge shall be detected on the transition from 1 to x, z, or 0,
and from x or z to 0
A posedge shall be detected on the transition from 0 to x, z, or 1,
and from x or z to 1
Thread beobachten
Seitenaufteilung abschalten