|
|
Forum: FPGA, VHDL & Co. Frage zu elsifHallo, ich habe eine kurze Frage zu der elsif-Bedingung und zwar in diesem Fall:
Da es hier in meinem Programm zu Problemen kommt vermute ich, dass wenn beispielsweise Bed2 und Bed3 erfüllt sind diese parallel ausgeführt werden. Ist das so richtig? Vielen Dank Herb Herbert schrieb: > Da es hier in meinem Programm Du machst VHDL und beschreibst Hardware. Damit ist dein Code kein Programm, sondern eine Logikbeschreibung! > zu Problemen kommt vermute ich, dass wenn > beispielsweise Bed2 und Bed3 erfüllt sind diese parallel ausgeführt > werden. Ist das so richtig? Nein das ist nicht richtig. Dein Konstrukt stellt eine Hierarchie dar, d.h. Bedingung 1 hat die höchste Priorität, während Bedingung 4 die niedrigste hat. Sind Bedingung 2 und 3 erfüllt, wird lediglich Bedingung 2 als erfüllt gesehen. Nein ich bekomme keine Fehlermeldung. Beim Untersuchen des Prozesses im Chipscope wird mir allerdings ein Ergebnis geliefert, dass nur durch die Erfüllung zweier Bedingungen erhalten werden kann. In der Simulation stimmen die Ergebnisse auf der Xilinx Hardware nicht. Herbert schrieb: > In der Simulation stimmen die Ergebnisse auf der Xilinx Hardware nicht. Wieviele Takte hat Dein Design? Sind alle Signale ordentlich einsynchronisiert? Stimmen die Sensitivitätslisten? Duke Duke Scarring schrieb: > Sind alle Signale ordentlich einsynchronisiert? Alle Signale werden in meinem Design mit der positiven Taktflanke synchronisiert. Ist es sinnvoll die Signale um wenige ns zu verzögern wie es in den fertigen Xilinx-Blöcken der Fall ist? Duke Scarring schrieb: > Stimmen die Sensitivitätslisten? Alle meine Prozesse sind nur vom CLK abhängig deshalb würde ich behaupten, dass die Sensitivitätslisten nur mit CLK stimmen. Vielleicht postest du einfach mal deinen Code, bevor hier spekuliert werden muss, was daran falsch sein könnte Herbert schrieb: > In der Simulation stimmen die Ergebnisse auf der Xilinx Hardware nicht. In der Simulation auf der Hardware? Ja was denn nun? Simulation, oder Hardware? Olga schrieb: > In der Simulation auf der Hardware? Ja was denn nun? Simulation, oder > Hardware? Wahrscheinlich Post-Layout-Simulation, oder wie das heißt. Also das, wo die Gatterlaufzeiten mitsimuliert werden. Herbert schrieb: > Beim Untersuchen des Prozesses im Chipscope wird mir allerdings ein > Ergebnis geliefert, dass nur durch die Erfüllung zweier Bedingungen > erhalten werden kann. Vermutlich ein asynchroner Eingang in einer FSM. Siehe das da: http://www.lothar-miller.de/s9y/archives/64-State-Machine-mit-asynchronem-Eingang.html Man könnte mehr sagen, wenn man mehr von der Beschreibung sähe... Herbert schrieb: > Alle Signale werden in meinem Design mit der positiven Taktflanke > synchronisiert. Sind alle deine externen Signale synchron zum Takt, oder hast du da solche Sachen wie Taster, Schalter oder irgendwelche Sensoren dran? > Ist es sinnvoll die Signale um wenige ns zu verzögern > wie es in den fertigen Xilinx-Blöcken der Fall ist? Hört sich irgendwie nach "Murks" oder "falsch verstanden" an... Herbert schrieb: > In der Simulation stimmen die Ergebnisse auf der Xilinx Hardware nicht. Fehlt da ein Komma nach "Ergebnisse"? Oder stimmen auch in der Simulation die Ergebnisse nicht, wenn du eine Xilinx-Hardware verwendest? :
Bearbeitet durch Moderator
Herbert schrieb: > Da es hier in meinem Programm zu Problemen kommt vermute ich, dass wenn > beispielsweise Bed2 und Bed3 erfüllt sind diese parallel ausgeführt > werden. Steht dieses Konstrukt in einem kombinatorischen process könnte es sein das für Bed2 die Werte gesetzt werden das Bedi3 erfüllt ist und somit im nächsten Durchlauf als true agearbeitet wird. Das ist dann nicht wirklich parallel, kann aber im getakten Chipscope so ausschauen als ob es gleichzeitig ausgeführt wird. MfG, Hallo Herbert, Herbert schrieb: > ... > ... > ... > ... Darfst Du und kannst Du ein wenig mehr erzählen, was Du an der Stelle der "..." machst? Ist es eine reine kombinatorische Logik, die mit der verschachtelten if Anweisung beschrieben wird? Fpga K. schrieb: > könnte es sein > das für Bed2 die Werte gesetzt werden das Bedi3 erfüllt ist Verstehe ich nicht. Ich freue mich über Präzisierung. Gruß Matz Matz K. schrieb: > Fpga K. schrieb: >> könnte es sein >> das für Bed2 die Werte gesetzt werden das Bedi3 erfüllt ist > Verstehe ich nicht. Ich freue mich über Präzisierung.
MfG, Zum Glück kann so etwas hier nicht passieren, weil/wenn nur synchrone Prozesse beteiligt sind. Denn Herbert schrieb: > Alle meine Prozesse sind nur vom CLK abhängig deshalb würde ich > behaupten, dass die Sensitivitätslisten nur mit CLK stimmen. Lothar M. schrieb: > Zum Glück kann so etwas hier nicht passieren, weil/wenn nur synchrone > Prozesse beteiligt sind. > Denn Herbert schrieb: >> Alle meine Prozesse sind nur vom CLK abhängig deshalb würde ich >> behaupten, dass die Sensitivitätslisten nur mit CLK stimmen. Ah, OK. Wenn man die verdrehte Argumentationskette, Grammatikgehaspele und den Konjunktiv auf die Aussage reduziert: "Alle Prozesse haben eine sensitivity list mit dem einzigen Element Clk (Takt im FPGA)" dann passt die These "kombinatorische Prozesse" natürlich nicht. Vollständiger Code als Anhang würde solche Fehlvermutungen verhindern. Da der noch nicht vorliegt wird das Problem wohl in einer Lösung oder in der Kapitualtion geendet sein. MfG, Fpga K. schrieb: > Da der noch nicht vorliegt wird das Problem wohl in einer Lösung oder in > der Kapitualtion geendet sein. Oder es ist noch in Arbeit. So ein asynchroner Eingang kann ganz hübsche Nebeneffekte haben... ;-) Lothar M. schrieb: > Fpga K. schrieb: >> Da der noch nicht vorliegt wird das Problem wohl in einer Lösung oder in >> der Kapitualtion geendet sein. > Oder es ist noch in Arbeit. So ein asynchroner Eingang kann ganz hübsche > Nebeneffekte haben... ;-) Arbeit macht Geräusche - ja, ich sehe das Posten von Code als "Geräusch" an. Da es aber um Herbert (Gast) still geworden ist gehe ich eher von "solved/aborted" aus als von "on progress". ;-) MfG, Matz K. schrieb: > when others => null;-) Nicht ganz, das würde zu einem case-Statement passen. In dem Fall wäre "else" das Zauberwort (oder Default-Zuweisungen für alle Signale vor dem if-Statement, um keine ungewollten Latches zu bauen). Ist sowieso alles ein Blick in die Kristallkugel, bei der Informationslage.
Angehängte Dateien:
Fpga K. schrieb: > Da es aber um Herbert (Gast) still geworden ist gehe ich eher von > "solved/aborted" aus als von "on progress". ;-) Das Problem ist "solved". Ich habe den unsauberen elsif-Block durch eine einfachere Abfrage lösen können. Warum das aber in der Simulation (ja entschuldigt, ich habe ein Komma vergessen) funktioniert hat und auf der Hardware nicht mehr, konnte ich mir nicht erklären. Den Code zu posten halte ich für weniger sinnvoll, da das nur unnötige Verwirrung stiftet. Fpga K. schrieb: > "Alle Prozesse haben eine sensitivity list mit dem einzigen Element Clk > (Takt im FPGA)" Genau so ist es. Lothar M. schrieb: >> Ist es sinnvoll die Signale um wenige ns zu verzögern >> wie es in den fertigen Xilinx-Blöcken der Fall ist? > Hört sich irgendwie nach "Murks" oder "falsch verstanden" an... Da muss ich nochmal einhaken, weil mich das wirklich interessiert. Dazu das Bild im Anhang. Ich nehme an, dass der Block A näher an der Clk-Quelle sitzt als Block B. Somit erhält der Clk an B eine zusätzliche Verzögerung, durch den örtlichen Abstand. Gibt A nun seine Daten an B aus (an der steigenden Taktflanke) liegen an B bereits die neuen Daten (1) an. Da der Takt allerdings verzögert ist, liest B fälschlicherweise die neuen Daten (1) ein anstatt der 0. Wenn die Ausgabe von A verzögert wäre (wie in den vorgefertigten XILINX-Blöcken), würde die 0 eingelesen werden. Habe ich da jetzt was ganz falsch verstanden? :D > Habe ich da jetzt was ganz falsch verstanden? :D Du hast damit verstanden, warum die Clock-Netzwerke in FPGAs (und alles was dazugehört ala PLL/DLL/DCM, BUFG, ...) so kompliziert sind. Die sorgen genau dafür, dass der Takt an allen angeschlossenen Flipflops exakt gleichzeitig ankommt, unabhängig von der Anzahl der FFs, ihrem Ort, der Temperatur oder sonstwas. Nur damit funktioniert synchrones Design. Georg A. schrieb: > dass der Takt an allen angeschlossenen Flipflops > exakt gleichzeitig ankommt Naja, ganz exakt ist es ja dann doch nicht, und das heisst dann "clock skew" (Du findest diese Info in der STA = Static Timing Analysis). Damit Du da nicht reinrasselst müssen Setup- und Hold-Zeiten eingehalten werden, und das wiederum ist Aufgabe der Synthese & des Optimierers. Ob diese Zeiten alle eingehalten werden sagt Dir ebenfalls die STA (falls die Anforderungen = "Timing Constraints" sauber definiert wurden). Herbert schrieb: > Da der Takt allerdings verzögert ist, liest B fälschlicherweise die > neuen Daten (1) ein anstatt der 0. Eine solche "race condition" zu verhindern, das ist die Aufgabe der FPGA-Designer. Du kannst dich darauf verlassen, dass das nicht passiert, solange du das Design nicht "übertaktest". Das hier beschriebene Problem hat aber grundlegend nichts mit asynchronen Eingängen zu tun, weil es sich ja nur innerhalb des FPGAs abspielt. Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.
|
|
Thread beobachten
Seitenaufteilung abschalten