-
Thread
VHDL Sync. schreiben. async. lesen
wie das Synthesetool mit Sensitivlisten bzw. wait-for's umgeht? Dazu hab ich bisher noch nichts konkretes gefunden.
in the sensitivity list" bedeutet hierbei nicht, dass der Synthesizer nur die Signale in der Sensitivliste beachtet, sondern, dass er die Sensitivliste einfach ignoriert.
-
Thread
VHDL falling edge bewirkt rising edge
Simultionsergebnis das > Hardwareergebnis vorstellen kann?(wenn man kein Oszi hat) Wenn die Sensitivliste der beteiligten Prozesse richtig beschrieben ist, dann sieht das normalerweise GLEICH aus. Einen Schritt zurück: Das Problem hier ist eigentlich eine unvollständige Sensitivliste! Denn
process; [/vhdl] BTW: Ich verwende zur konsequenten Verhinderung von unvollständigen Sensitivlisten gern die Prozessschreibweise /ohne/ Sensitivliste: http://www.lothar-miller.de/s9y/archives/16-Takt-im-Prozess.html Dann passiert das oben Beschriebene /garantiert/ nicht.
-
Thread
Latches vermeiden?
----------------------------------------- Die Sensitivliste an sich ist NUR und AUSSCHLIESSLICH für die Simulation relevant! ----------------------------------------- Ohne Sensitivliste und ohne Event wird der Process nicht compiliert. Es kommt ein
synthetisiert und korrekt simuliert: [vhdl] process begin -- überhaupt keine Sensitivliste wait until rising_edge(clk); -- aber dafür ein wait toggle <= not toggle; end process; [/vhdl] peter schrieb im Beitrag #3647776: > Ohne Sensitivliste und ohne Event wird der
-
Thread
Sensitivity List
keine Sensitivliste wait on (a,b); -- aber ein wait z <= a and b; end process; [/vhdl] Siehe die hier: https://www.mikrocontroller.net/topic/143625#1339919 https://www.mikrocontroller.net/topic/298047
nicht in Gefahr. Schon, wenn die Regel "Jeder Prozess mit (all)!" gilt. Denn ein Prozess mit Sensitivliste /und/ wait geht nun mal nicht...
-
Thread
Verschiedene Schreibweisen bei "process"
der andere Fall: Der Compiler nimmt von sich aus /nicht/ automatisch fehlende Signale in die Sensitivliste mit auf...
... Richtig. In der Defaulteinstellung wird für die Simulation alles hergenommen, was in der Sensitivliste steht.
-
Thread
Erfahrung mit SPI Slave und Spartan 6 FPGA?
Ahja, ok. könntest du mir das eventuell kurz erklären wieso nicht? Ich > ging davon aus in der Sensitivliste die Signale stehen auf die auch > reagiert werden soll? Die Sensitivliste sagt dem /Simulator/, wann er den Prozess neu berechnen muss. Und er muss in deinem Fall den Prozess nur berechnen,
Ahja, ok. könntest du mir das eventuell kurz erklären wieso nicht? Ich >> ging davon aus in der Sensitivliste die Signale stehen auf die auch >> reagiert werden soll? > Die Sensitivliste sagt dem /Simulator/, wann er den Prozess neu > berechnen muss. Und er muss in deinem Fall den Prozess nur berechnen
-
Thread
Prozess ohne Sensitivitätsliste
wäre es aber auch logisch gewesen, wenn der nie ausgeführt > worden wäre Jeder Prozess ohne Sensitivliste wird zu Beginn der Simulation gestartet. Das kann man leicht am "üblichen" Ablauf eines Testbench-Prozesses sehen, der ja auch ohne Sensitivliste ausgeführt ist und dann gleich mal losläuft, bis
d <= a after 2 ns; e <= b and c: end process; [/vhdl] Und so werden Prozesse mit Sensitivliste bei der Simulation erstmal gestartet, um sofort danach wegen der Sensitivliste wieder angehalten zu werden. "Von aussen" gesehen haben sie sich nicht mal den Bruchteil einer Femtosekunde bewegt
-
Thread
Flankenerkennung in VHDL
machst oder als umständlich ansiehst. Wenn du es ganz geschickt machst, dann ist da gar keine Sensitivliste im Prozess: http://www.lothar-miller.de/s9y/archives/16-Takt-im-Prozess.html Damit gibts natürlich nur getaktete Prozesse. Kombinatorik wird dann aber auch ohne Sensitivliste mit nebenläufigen
Die Sensitivliste heisst bei mir meist ...(all). Das ist einigermassen überschaubar ;).
-
Thread
Ampelschaltung mit Coolrunner2
if slow_clk == '1' then... usw. Ich habe auch noch nicht verstanden was diese Prozesse mit Sensitivliste sollen. Klar funktioniert das und ist im Standard definiert aber mit wait until, ist es meiner Meinung nach wesendlich sauberer, da nichts vergessen werden kann (Sensitivliste) und dann nur im
lesbar ist. Okay ich korrigiere meine Aussage ... Bei getakteten Prozessen verwende ich keine Sensitivlisten. Das nur das clk in der Sensitivliste stehen muss, habe ich verstanden ... Danke
-
Thread
STD_LOGIC_VECTOR Änderung erfassen
VHDL 2008 erlaubt "all" in der Sensitivliste. Und ich sehe keinerlei Grund, da (in 2022) noch irgendwas anderes hinzuschreiben.
prozess aktiv werden. Wie ich schon schrieb im Beitrag #6972041: > dem Synthesizer ist die Sensitivliste egal Oder anders: die Sensitivliste ist nur für die Simulation relevant. Dein Ansatz funktioniert also nur im Simulator. Wenn das reicht, dann nur zu. New C. schrieb im Beitrag #6977833:
-
Thread
Umstieg Xilinx auf Altera/Intel -> kein wait for, wie testbench?
dafür ist die da). Der Simulator erzeugt für nebenläufige Anweisungen sowieso seine "interne" Sensitivliste. Deshalb ist zwischen den beiden Varianten abgesehen von der schlechteren Übersichtlichkeit und der potentiellen Verwirrung, wann denn beim Prozess mit dem "after" die Sensitivliste jetzt "triggert
sinvoll, denn ein entsprechender funktionsgleicher Prozess müsste ja auch alle Signale in der Sensitivliste haben. > Ohne eine ausdrückliche Einschränkung derselben durch den Designer Eine Einschränkung der Sensitivliste durch den Designer ist bestenfalls für eine Testbench "sinnvoll". Und genau
-
Thread
asynchrone Anweisungen
ein Signal in der Sensitivliste ändert. Man merkt schnell: Deadlock!
> würde, aber ohne rising_edge(clk) bzw. clk'event? Und was "würde" in diesem Fall in der Sensitivliste stehen? Wenn es nicht "pwm" ist, dann ist die Sensitivliste falsch und die Simulation auch. An der erzeugten Hardware ändert sich nichts: ein rückgekoppelter Inverter...
-
Thread
Finite-State-Machine stürzt ab
über welches wir ja noch vor kurzem in einem anderen Thread gesprochen hatten. > In dieser Sensitivliste steht also viel zuviel Zeug. Das ist zwar "nur" ein Schönheitsfehler, zeigt aber ein leichtes Unverständnis auf. Genau genommen waren in den Sensitivlisten bis vor Kurzem nur die Clock-Signale
dass du siehst, was da rein gehört und was nicht. Vorneweg: nur die Simulation braucht die Sensitivliste! Und dann müssen in der Sensitivliste alle die Signale sein, die eine Neuberechnung des Prozesses nötig machen. In einem komplett synchronen Prozess ist das nur der Takt, denn nur wenn sich der
-
Thread
VHDL: Sinn der Sensitivity List
Und danach für /result/ nochmal. Das wird er aber nicht, weil diese beiden Signale in der Sensitivliste fehlen. Klarer Fall von unvollständiger Sensitivliste. Und schon wieder verhält sich die simulation anders als die Realität... Bei einem kombinatorischen Prozess gehört jedes Signal, das eine
falsch und passt nicht zur real implementierten Schaltung... Denn dem Synthesizer ist die Sensitivliste schnuppe. Der gibt eine passende Info zu einem fehlenden Signal aus, und weiter gehts.
-
Thread
Initialisierung LCD-Display
= 53999 then current_state <= next_state after 20ns; -- kombinatorisch, aber nicht in Sensitivliste end if; end process; [/vhdl] Sowas lässt sich nicht synthetisieren: [vhdl] current_state <= next_state after 20ns; -- kombinatorisch [/vhdl] Denn es gibt keine einstellbaren
also alles raus aus der Sensitivlist und clk rein, dann wirds was mit dem Display, verstehe ich das dann so richtig? Und als Abfrage mach ich das " if rising_edge (clk) then -- dann die states
-
Thread
VHDL Grundlagenverständnis
lenkt ab. Denn der eigentliche Trick beim Prozess mit dem Signal /test/ ist die unvollständige Sensitivliste: es fehlt das Signal /test/. Also ist zwar der Prozess syntaktisch richtig, aber die Sensitivliste falsch. Und dadurch können sich seltsame Effekte ergeben. Siehe den http://www.mikrocontroller.net
innerhalb eines Processes ein Signal verwendest welches außerhalb angelegt wurde und nicht in der Sensitivliste steht so darf es nur links von einer Zuweisung stehen im Process. Wenn es rechts einer Zuweisung steht muss es in der Sensitivliste erscheinen ansonsten gibt es eine Fehlermeldung beim compilieren
-
Thread
Zähler Signale wollen nicht loslaufen/sich nicht zu 0 setzen lassen gar nichts.
In diese Sensitivliste gehört nur clk: [vhdl] FSM : process(Z, CLK, InputText, Key, AddRoundKey_Output, SubBytes_Output, Shiftrow_Input, ExpandKey_buf, Cycles, MixCloumn_output, ExpandKey_OutPut) begin FolgeZ
das alle Signale die auf der rechten Seite zum Zuweisen stehen auch da > reingehören. In die Sensitivliste gehören alle Signale, die eine /Neuberechnung/ des Prozesses im /Simulator/ nötig machen. Dem /Synthesizer/ ist die Sensitivliste schnurzegal, bestenfalls meldet er noch mit einer Info/Warning:
-
Thread
cachemodul, Simulation ok, aber auch bereit für die Synthese?
: Ist hier den sicher, dass der Reset im Simulator ausgelöst wird? Müsste hier nicht eine Sensitivliste mit dem Resetsignal sein (clock natürlich nicht)?
> Ist hier den sicher, dass der Reset im Simulator ausgelöst wird? Müsste > hier nicht eine Sensitivliste mit dem Resetsignal sein (clock natürlich > nicht)? Ein Prozess, der ein wait-Statement enthält, kann/darf keine Sensitivliste haben.
-
Thread
Sensitivitätsliste in VHDL Code
[vhdl] process (hier, ist, die, sensitivliste) begin .... end process; [/vhdl] BTW: die Verwendung von Variablen stimmt mich sehr nachdenklich...
a und b zu x /in/ diesem bisher unbekannten Prozess gemacht wird, dann müssen a und b in der Sensitivliste stehen. Wenn diese Concatenation /ausserhalb/ des Prozesses gemacht wird, dann muss x in der Sensitivliste stehen. > Mein Gedankengang: Es bringt nichts, wenn du dir Gedanken machst, die uns
-
Thread
[isim] Probleme mit Testbench
Wenn die Sensitivlisten falsch sind, dann ist die Simulation falsch. so einfach ist das. Hier ist zuviel drin: ANFORDERUNG_HAUPTS: process(CLK, HS1_S, HS2_S, FN_S) ANFORDERUNG_NEBENS: process(CLK, NS1_S, NS2_S, FH_S
[/vhdl] Zusammengefasst sind 2 grundlegende Fehler in deinem Code: 1. die unvollständige Sensitivliste 2. der nicht initialisierte Zähler
-
Thread
FSM funktioniert nicht wie ich will
dir der Synthesizer aber auch... Über die Sensitivliste kannst du lediglich das Verhalten der Simulation steuern. Der Synthesizer kümmert sich nicht um die Sensitivliste. Er wird deshalb die Signale "next_state" und "FRAME_PART1v2" schlicht ignorieren
schreibt einen synchronen Prozess, wo neben dem Takt schlimmstenfalls nur noch ein Reset in der Sensitivliste steht. Aber man fasst nicht die Kombinatorik und die Register einer 2-Prozess-Beschreibung *hintereinander* im selben Prozess zusammen.
-
Thread
VHDL Grundlagen : zwei Prozess Methode
Records als "Signalsammlung" um im kombinatorischen Prozess sicher alle nötigen Signale in der Sensitivliste zu haben. Und um sie "einfach" an die lokale Variable übergeben zu können, damit dann ab dort mit VHDL wie mit einer prozeduralen Programmiersprache "programmieren" zu können. Wie gesagt: Gaisler
bekannten VHDL-Standard entsprechend... > Also dient sie auch dort nur der Simulation? Die Sensitivliste ist /ausschließlich/ für die Simulation. Der Synthesizer "nimmt" sich seine Signale und gibt eine Info aus, dass die Simulation nicht mehr zum Syntheseergebnis passt.
-
Thread
Der Process soll sich selber ausschalten
Danke für die Antworten. Handshake werde ich noch ausprobieren. Die Sensitivliste ist noch veraltet, ich habe vorher dort was anderes geschrieben. Den Unterschied zwischen Variablen und Signale ist mir noch nicht ganz klar, oder besser gesagt, wieso so viele gegen variablen
akademisch ist. Du musst dir eines klar machen: die Simulation arbeitet /ausschließlich/ mit der Sensitivliste, der Synthese ist die Sensitivliste /schnurzegal/. Letztendlich darf dich aber nur die Synthese interessieren, denn nur mit der Synthese kannst du ein Design in Hardware umsetzen. Du musst also
-
Thread
inferring latches - was ist hier die Ursache?
Ob der Reset aktiv ist wird > ja sowieso nochmal abgefragt. Das Weglassen des Resets in der Sensitivliste macht implizit aus einem asynchronen Reset einen synchronen Reset. Und spätestens dann darf natürlich keine Warnung mehr kommen...
Lothar M. schrieb im Beitrag #7404638: > Das Weglassen des Resets in der Sensitivliste macht implizit aus einem > asynchronen Reset einen synchronen Reset. Warum ist das so? Weil dann ein Register entsteht? Ist aber meine ich eine etwas diffuse Methode, latches zu vermeiden,
-
Thread
VHDL: umständlicher Code?
es ja dann beides, technisch in Ordnung und übersichtlich aussehend. > Noch eine Silbe zur Sensitivliste: > process(clk, reset, shiftreg) is ... > shiftreg ist hier unnötig, weil die Neuberechung des Prozesses nur bei > einer Änderung von clk oder reset nötig ist. An irgendeiner Stelle hatte
geschrieben habe. Weiß aber nicht mehr ganz den Zusammenhang. > Noch eine weitere Silbe zur Sensitivliste: > diese Liste interessiert nur den Simulator. OK.
-
Thread
Process wird kontinuierlich durchloffen - Altium LiveDesign Board
vhdl] Process(usignal) BEGIN if(test = '1') then if (reset='0') then [/vhdl] Diese Sensitivliste ist unvollständig --> die Simulation passt nicht zur Realität... :-o > Nach einigem Stöbern habe ich auch herausgefunden, dass die Sensitive > list bei der Synthese nicht relevant ist. (
> Diese Sensitivliste ist unvollständig --> die Simulation passt nicht zur > Realität... :-o Das ist mir klar, ich hatten den Reset auch zunächst in der sensitive list, habe dann ein wenig rumgespielt (deswegen
-
Thread
VHDL Verbindung nur wenn "enabled"
sieht grundsätzlich erstmal gültig aus ... hat aber auf den zweiten Blick den Fehler, dass die Sensitivliste nicht vollständig ist: ausgang1 und ausgang2 fehlen darin. Mit einer nebenläufigen Schreibweise kann sowas gar nicht passieren.
schreiben: > Welche Vorteile hat das gegenüber einem Prozess? Du hast sicher keine falsche Sensitivliste. Du sparst 8 Zeilen Code ein und gewinnst Übersichtlichkeit. Mir reicht das als Vorteile.
-
Thread
Outputsignal bleibt gleich
when 3 => d0 <= lfsr(2) xnor lfsr(1); -- lfsr fehlt in der Sensitivliste, denn eine Änderung when 4 => d0 <= lfsr(3) xnor lfsr(2); -- von lfsr müsste eine Neuberechnung des Prozesses anstoßen ... when others => null; end case
Lothar M. schrieb im Beitrag #4971091: > Ich hol mal den Prozess mit der unvollständigen Sensitivliste extra raus > und kürze ihn etwas ein Deshalb hatte ich mir angwohnt, (nahezu) *alles* als getakteten Prozess zu schreiben ... Dann muss ich mir auch keine Gedanken um die Sensitivity-Liste
-
Thread
VHDL Entprellung-Fehler
Wenn schon /nur/ der Takt im Prozess verwendet wird, dann schreibe auch nur den Takt in die Sensitivliste. Dieses (all) ist ziemlich die blödsinnigste Erweiterung, die es gibt.
. Und einen synchronen Prozess schreibe ich sowieso ohne Sensitivliste: http://www.lothar-miller.de/s9y/archives/16-Takt-im-Prozess.html
-
Thread
VGA-Signal -Übertragungsprobleme.
beide zusammen! Und dann noch der http://www.mikrocontroller.net/topic/161722 Flasche Sensitivliste: [vhdl] test : process (clk) -- clk wird nicht gebraucht begin if taster= '1' then -- taster fehlt in der sensitivliste ledtest1<='0'; else ledtest1<='1'; end if; end process test; [/vhdl] Unvollständige Sensitivlisten: [vhdl] HCounter : process (clk) begin if reset = '0' then -- reset fehlt in der Sensitivliste! Hcount <= (others=> '0'); ledtest2<='1'; elsif (clk'event and clk
-
Thread
Integer vergleichen
Es sei denn, Du wolltest, daß es nicht läuft ;). Ein Prozeß ohne wait-Statement und ohne Sensitivliste macht seltsame Dinge ...
. Oder kurz: eine falsche Sensitivliste hat eine falsche Simulation als Ergebnis. robert schrieb im Beitrag #5048735: > ich habe nur sehr wenig erfahrung in vhdl Das war bei jedem mal so. > und versuche durch diese > anwendung
-
Thread
verschiedene Teile von std_Ulogic_vector aus mehreren Processen zuweisen
Meldungen/Warnungen/Info genau das gleiche wie bei std_logic. Die Synthese ignoriert ja auch die Sensitivlist. Ist nur ne Vermutung aber könnte das ein relevanter Punkt bei diesem speziellem Beispiel sein? Ein Signal das in einem Prozess bedingungslos zugewiesen wird würde ich persönlich nicht in die Sensitivlist
nichts, wenn ich schreibe .... Seeehr merkwürdig das Ganze! Ich bleibe bei der Meinung das die Sensitivlist ungeschickt ist. Grüße Erik
-
Thread
Was sind Prozesse und was meint man mit "sequenziell"
Sensitivity Liste > ( = alle oder nur ein Teil der Eingänge) Wobei genau genommen schon diese Sensitivliste eine Sonderform eines "allgemeinen" Prozesses herleitet: die Sensitivliste ist nur ein "vorweggenommenes" /wait on/. Jeder Prozess mit Sensitivliste könnte auch mit einem /wait on/ Statement statt der Sensitivliste geschrieben werden. Hier ein kleines Beispiel: [vhdl] process (s1,s2,s3,s4,s5) begin : end process; [/vhdl] Das ist gleichbedeutend mit: [vhdl] process begin wait
-
Thread
sensitivity list
eingetragen wird? Ver§&%/$mt! Blöder copy&paste Fehler. Ist korrigiert... ;-) Kleiner Tipp: die Sensitivliste ist /nur und ausschließlich/ für die Simulation interessant. Die Synthese gibt bestenfalls eine Warnung oder gar nur eine Info aus, wenn die nicht stimmt...
Ich würde das "sollen" aus dem Text streichen. Dann passt es. Denn die Sensitivliste kann nichts steuern, sondern muss ein korrektes Abbild des Prozesses sein. Sonst kommt wieder einer auf die Idee mit der /unvollständigen/ Sensitivliste, wo nur die Signale drinstehen, die was
-
Thread
Sinn der Sensitivity List?
noch recht kostbar war. Und ausserdem war damit der Prozess schon halb dokumentiert: In der Sensitivliste stehen alle signale, die eine Änderung eines Wertes bewirken können. In VHDL2008 gibt es auch das Schlüsselwort /all/ [vhdl] process (all) begin : end process; [/vhdl]
Beispiel einer trickreichen Nutzung einer > snesitivity list geben, Ich kenne unvollständige Sensitivlisten eigentlich auch nur als Quelle von Problemen: http://www.mikrocontroller.net/topic/117630#1057329 http://www.mikrocontroller.net/topic/146640#1366176
-
Thread
fragen zu fsm, verilog modulen und probleme.
auf einem cpld natuerlich etwas problematisch 2) eine frage zur current state logic. in der sensitivliste sollten dort ja immer alle signale enthalten sein die zur entscheidung des current state noetig sind. momentan habe ich nur clock in der sensitivliste es funktioniert ist das soweit ok ? 3)
verwende lieber die 1-Prozess-Schreibweise ;-) > eine frage zur current state logic. in der sensitivliste sollten dort > ja immer alle signale enthalten sein die zur entscheidung des current > state noetig sind. momentan habe ich nur clock in der sensitivliste es > funktioniert > ist das soweit
-
Thread
Frage zu VHDL Programm
Zwei-Prozess-Schreibweise starten ;-) > deswegen wird einmal Prozess 2 ausgeführt. Jeder Prozess mit Sensitivliste wird beim Start einmal komplett ausgeführt. Jeder Prozess ohne Sensitivliste wird beim Start bis zum ersten /wait/ ausgeführt.
undefined bei einem State ist, deswegen wird einmal >Prozess 2 ausgeführt. >Jeder Prozess mit Sensitivliste wird beim Start einmal komplett >ausgeführt. Ok, diese Information hat mir gefehlt, danke ;)
-
Thread
Ursache für Latches und wie vermeiden?
erzeugt und auf dessen Änderung im FPGA reagiert wird. Ein Tipp: diese mit (all) abgekürzte Sensitivliste ist was, das Anfänger nicht verwenden sollten. Denn es verleitet dazu, sich keine Gedanken zum Design zu machen. Schreibe in die Sensitivliste mal nur die Signale, von denen du meinst, dass sie
nebenläufig (concurrent), was Kombinatorik ist. Dann steht in jedem Prozess nur der clk im der Sensitivliste, oder besser noch: du hast gar keine Sensitivliste und verwendest stattdessen ein wait until rising_edge(clk); im Prozess: http://www.lothar-miller.de/s9y/archives/16-Takt-im-Prozess.html Aber
-
Thread
Nicht-Spezifische Latch-Warnung
signale die sich ändern müssen in die Sensitivity list, sonst wirds ein > latch. Falsch. In die Sensitivliste müssen alle die Signale, die eine /Änderung/ eines andere Wertes bewirken. Dann berechnet der /Simulator/ bei einer Änderung des Wertes in der Sensitivliste die Ergebnisse des Prozesses neu.
Synthese (die oben die Warnung erzeugt) schert sich einen feuchten Kehrricht um eine unvollständige Sensitivliste. Sie erweitert diese Leiste einfach eigenständig. Mit der Sensitivliste kann also das Verhalten des FPGAs in keiner Weise gesteuert werden.
-
Thread
Verilog-Simulation ergibt merkwürdiges Ergebnis
/. Was ist das Gegenteil von /intuitiv/? Logisch: ... ;-) Ich finde Verilog mit seinen Sensitivlisten so sehr tuitiv, denn mit der Zeile: >>> always @(posedge RESET or posedge CLOCK) begin wird ein asynchroner high-aktiver Reset und ein auf die steigende Flanke sensitiver Takt beschrieben. Nur
trotzdem tuitiv... Warum werden dann bei Verilog nicht wie bei VHDL üblich nur die Signale in die Sensitivliste aufgenommen und die Flankenabhängigkeit im Quelltext aufgeführt? Ich könnte doch auch so schreiben: [vhdl] always @(RESET or CLOCK) begin if (RESET) begin *** pegelsensitiv :
-
Thread
VHDL - Takt für verschiedene CPU-Komponenten verzögern
Beitrag #5420718: > Lothar M. schrieb: >> Mein Tipp: mach es wie der Rest der Welt. In die Sensitivliste eines >> getakteten Prozesses kommt nur der Takt (und nötigenfalls bestens noch >> der asynchrone Reset). > > Okay, ich dachte, da muss alles rein, auf das im folgenden Prozess > lesend
Prozess können sich Resultate nur mit einer Taktänderung ergeben. Dem Synthesizer ist die Sensitivliste vollkommen schnuppe! Er erweitert fehlende Signale oder er ignoriert sie wie er es braucht. Und meldet dann bestenfalls, dass die Simulation nicht mehr zur Realität passt.
-
Thread
vhdl Fragen zum Code
von Befehlen. Der Prozess wird vom Simulator neu berechnet, wenn sich eines der Signale in der Sensitivliste ändert (der Synthesizer schert sich dagegen nicht um die Sensitivliste). Ist die Sensitivliste nicht vollständig, passt die Simulation nicht zur Realität. Das passiert gern mal bei der Verwendung
process JobListSeparator; [/vhdl] Ist nur 1 einziges "wait" im code, kann der Prozess auch mit Sensitivliste geschrieben werden: [vhdl] JobListSeparator : process (CommandList) -- auf irgendeine Änderung in der CommandList warten begin CommandAdress <= CommandList(31 downto 16); CommandValue
-
Thread
korrekte Signal Zuweisung in Vhdl
#6586450: > drittens ist clk und rst gar nicht definiert. Es ist eigentlich andersrum: die Sensitivliste ist falsch. Dort muss passend zum Code i1 rein. Viele Anfänger meinen, dass man mit der Sensitivliste irgend etwas "steuern" könnte. Dabei ist es schlicht so, dass man erst den Code schreibt, und dann schaut, welche Signale davon in die Sensitivliste gehören. Dussel schrieb im Beitrag #6586450: > zweitens müssten in clk und i1 im gleichen Deltazyklus eine Flanke > haben, damit das ausgewertet wird (geht das eigentlich?) Das interessiert
-
Thread
Ist das Verhalten so OK?
wait". Und dann die "Ausnahme" zum Verwirren von Anfängern: der Anfang eines Prozesses *mit Sensitivliste* ist ein implizierter "wait on". [vhdl] process (a,b,c) begin : end process; -- entspricht process begin wait on a,b,c; : end process; [/vhdl] Und weil nach
*counter* in die Sensitivliste aufnehmen, dann wäre bei 15 Schluss.
-
Thread
VHDL CODE ASYNCHRONER RESET-EINGANG?
Wichtig zu wissen: Die Sensitivliste benötigt ausschließlich der Simulator! D.h. der Prozess wird in der Simulation gestartet, wenn sich ein Eintrag der Sensitivliste ändert. Hier wird ein asynchroner Reset simuliert und synthetisiert
[/vhdl] Hier verhalten sich Simulation und generierte Hardware unterschiedlich! Denn die Sensitivliste ist unvollständig, es wird aber weiterhin ein asynchroner Reset synthetisiert. [vhdl] process (clk) -- process for register function begin if reset='0' then q <= (others => '0'
-
Thread
Anfängerfrage zu Schieberegistern bzw. FFs
'; end if; end process; [/vhdl] Dazu gibt es zwei Warnungen, dass a und b in der Sensitivliste fehlen. > Warum ist das in der Simulation anders? Die Simulation verlässt sich blind auf die Sensitivliste. Nur dann, wenn sich eines der Signale in der Liste /ändert/, wird der Prozess neu
Ganze irgendwas mit dem clk zu tun hätte: c wird nur berechnet, wenn sich der clk ändert. Fazit: Sensitivliste falsch ==> Simulation falsch :-( Was passiert z.B. wenn sowas in der Liste stehen würde (ein klassischer Typo): [vhdl] process (c,b) begin ... [/vhdl] > Ist denn das bei CPLD-Designs
-
Thread
FPGA Diode ansteuern
Signal r eine kombinatorische Schleife gemacht. Die Simulation passt nicht zur Hardware, weil die Sensitivliste falsch ist: r fehlt. http://www.lothar-miller.de/s9y/categories/36-Kombinatorische-Schleife Thomas K. schrieb im Beitrag #4230343: > Und was gehört dann alles in die Sensitivitätsliste für
für den Simulator eine Neuberechnung des Prozesses nötig macht. Nur der Simulator verwendet die Sensitivliste. Thomas K. schrieb im Beitrag #4230343: > oder ob zuerst der Prozess für den clk sequentiell abläuft und dann erst > die Folgezustandsberechnung sequentiell abläuft. Prozesse "laufen" nicht
-
Thread
ständig Fehlermeldung bei Verilog Code
nicht erlaubt statt rst, ss zu nehmen?? Es geht hier nicht um die Buchstaben ss oder rst. Die Sensitivliste (heißt das in Verilog auch so?) muss zum Code passen. Zeig mir ein beliebiges Beispiel im Netz, wo es so gemacht wird, wie du es tust. Oder andersrum: warum ist bei den meisten synchronen Beschreibungen nur der Takt und der Reset in der Sensitivliste? Ganz einfach: weil sich nur solche Beschreibungen auf die Flipflops im FPGA abbilden lassen. Diese Flipflops haben einen Reset- und einen Takteingang. Und wenn du den ss in die Sensitivliste
-
Thread
Gaisler-Religion?
Sensitivitätslisten, etc. pp. All das schaffst du ganz problemlos auch mit der Gaisler-Methode (von der Sensitivliste evtl. mal abgesehen, wobei da dann ja einfach auf alles reagiert wird, das bietet VHDL2008 auch so). Nur, weil /du/ die Fehler vorher schon gemacht hast, sind sie dir bekannt und du gehst ihnen
In VHDL2008 (auch schon ein paar Jahre her) gibt es das Keyword ALL für die Sensitivliste. Das ist dann, wie Gaisler es auch macht: alle Signale in einen Record packen und den in der Sensitivliste angeben. Wenn sich dann irgendein Signal ändert, dann wird jeder Prozess neu berechnet
-
Thread
4bit ladberer Zähler mit Anfangs- und Endwert.
> process(clk) > begin > value_jetzt <= zahl_anfang > if clk = '1' then 1. Die Sensitivliste ist nicht vollständig : zahl_anfang fehlt. Oder andersrum: wo hast du gesehen, dass in einem Prozess vor dem Takt eine Zuweisung kommt? 2. Das ist ein Latch, weil nirgends ein Takt vorkommt.
Beitrag #5355144: > Ich benutze immer den Simulator zu testen Lustigerweise wird das Dank der Sensitivliste im Simulator sogar wie gewünscht funktionieren. Aber der Synthesizer schert sich einen feuchten Kehrricht um diese Liste und wird da eine kombinatorische Schleife anmosern. Siehe dazu das da