Überlappende Takt- und Datenflanken in Designs mit mehreren Zustandsmaschinen

Ich habe eine allgemeine Frage zu Logikdesigns für mehrere Zustandsmaschinen. Stellen Sie sich ein System vor, das mehrere endliche Zustandsautomaten mit einem einzigen Takt und Flip-Flops mit steigender Flanke hat. Diese Maschinen teilen einige ihrer Eingabe- und Ausgabedaten. Die Ausgaben einiger Maschinen können also die Eingaben anderer Maschinen sein.

Meine Frage ist, da alle Maschinen den gleichen Takt und die gleiche steigende Flanke verwenden, würde es nicht zu einer Verwirrung an den steigenden Flanken kommen, wo sich auch die Eingangsdaten ändern?

Zur Erläuterung in Zahlen: Diese Abbildung unten zeigt ein praktisches Daten- und Taktzeitdiagramm. (Unteres Signal ist Takt, oberes Signal sind Eingangsdaten) Es gibt keine Änderung des Eingangssignals an der steigenden Flanke des Takts.

Geben Sie hier die Bildbeschreibung ein

Aber hier haben die Eingangsdaten eine fallende Flanke an der steigenden Flanke des Takts. Problematisch erscheint mir folgendes:

Geben Sie hier die Bildbeschreibung ein

Und die Sache ist die, dass in einem Multiple-State-Machine-System mit einem einzelnen Takt jeder Übergang eines Bits im gesamten Design zur gleichen Zeit stattfindet. Wenn ich mir also keine Methode ausdenke, überlappen sich die Kanten von Daten und Takt immer. Ich möchte wissen, ob es Methoden gibt, dies zu vermeiden (wie das Verschieben der Taktphase für jede Maschine usw.). Oder ist das vielleicht überhaupt kein Problem und ich übersehe hier etwas? Wenn ja, würde ich auch wissen wollen, warum ich falsch denke.

Sie haben eine Zustandsmaschine, in der Taktübergänge Zustandsänderungen verursachen. Sie haben ungetaktete Eingänge, die in die Zustandsmaschine eingespeist werden. Das ist schlecht. Eine einfache Lösung besteht darin, Flip-Flops mit negativem Takt hinzuzufügen, um Eingänge zu puffern, die in Ihre Zustandsmaschine eingespeist werden. Datenübergänge bei negativen Takten, Zustände bei positiven.

Antworten (2)

In der Praxis, wo ein einzelner Takt richtig um das Design herum verteilt ist, kann davon ausgegangen werden, dass die Ausgangssignale nach dem Takt ankommen, der sie erzeugt hat. Der Takt muss den tatsächlichen Übergang eines Flop-Ausgangs bewirken, und dann muss sich das Signal durch mehrere Logikebenen ausbreiten, bevor es den nächsten Flop erreicht. Diese Verzögerungen sind viel größer als die kleinen Fehler in der Taktzeitgebung.

Sie sagen also im Grunde, da jede Datenausgabe das Ergebnis derselben Taktflanke ist, wird es immer eine Verzögerung bei den Daten geben, oder? Ich habe tatsächlich einige Simulationen in Xilinx mit Verilog durchgeführt und das Problem erlebt, das ich in meiner Frage erwähnt habe. Vielleicht ist das passiert, weil meine Simulation ohne Hinzufügen von Verzögerungen erstellt wurde und die Simulation alle Gates ideal mit 0 Verzögerung behandelt hat?
Eine korrekte 0-Verzögerung vom Takt bis zur Dateneingabe zum nächsten Flop tritt nie auf. Früher habe ich ASICs entworfen, und es wird viel Zeit und Mühe darauf verwendet, alle Uhren gleichzeitig umzustellen und sicherzustellen, dass zwischen den Flip-Flops eine ausreichende Verzögerung besteht. Wenn Sie dies in einem FPGA oder ähnlichem tun, bin ich sicher, dass dies erledigt wurde und Sie sich darüber keine Sorgen machen sollten.
@packt Falls Sie sich fragen, ob der Prozess, um sicherzustellen, dass dies der Fall ist, als statische Timing-Analyse bezeichnet wird. Alle FPGA-Designabläufe verfügen über einen Editor für Timing-Beschränkungen, der dem Autorouting-Tool mitteilt, was es erreichen muss, und über ein Timing-Analysetool, um zu überprüfen, ob keine Setup-Verletzungen vorliegen (Taktflanke kommt vor Daten).
OP, wo @RoyC sagt, dass für FPGAs "darum gesorgt wurde", dass die Flip-Flops in einem FPGA so ausgelegt sind, dass sie eine "Null-Haltezeit" haben (Sie können dies googeln, um weitere Informationen zu erhalten). .
Vielen Dank, Jungs, war sich nicht sicher, welchen FPGA-Fluss Synopsys verwendet, um dies für uns zu erledigen.
Ich simuliere tatsächlich ein Design, das ich später als kleines Projekt entwerfen werde. Es wird also nicht auf FPGA konstruiert, aber ich glaube trotzdem, dass ich den Punkt verstehe. Meine Verilog-Codes hatten keine Verzögerung, daher kamen die Kanten in der Simulation genau aufeinander. Das führte zu einigen unerwarteten Ergebnissen. Aber das Hinzufügen sogar einer sehr kleinen Verzögerung bei den Ausgängen, die die echten Gates korrekter darstellt, löste das Problem. Danke euch allen.

Für die zyklusbasierte Simulation gehen wir davon aus, dass die Taktflanke überall im Design gleichzeitig auftritt. Beim ASIC-Design (einschließlich der Leute, die die von mir verwendeten FPGAs entwerfen) wird viel Arbeit darauf verwendet, diesem Ideal nahe zu kommen.

Wenn Sie sich Simulationswellenformen ansehen, denken Sie daran, dass alle Signale, die so aussehen, als würden sie gleichzeitig mit den Taktänderungen auftreten, sich tatsächlich (mindestens) etwas später ändern. Zumindest sollten sie. Tatsächlich hat Verilog Probleme mit Rennbedingungen , die Probleme in der Simulation verursachen können. Und ich hatte Simulationsprobleme in VHDL, wenn ich eine Uhr gatterte, eine Uhr von einer anderen ableite oder eine Uhr einem Array oder Datensatz zuordnete.

Beim Synthetisieren eines Designs in FPGA oder ASIC tritt die Taktflanke im gesamten Design nicht gleichzeitig auf. Wenn sich eine Änderung in der Leitung, die ein Flip-Flop antreibt, zu früh nach der Uhr ändert, nennen wir dies eine "Haltezeitverletzung". Diese Verstöße werden in der statischen Timing-Analyse angezeigt, die Teil Ihres Place-and-Route-Tool-Flows sein sollte. Nach meiner FPGA-Erfahrung sind Haltezeitverletzungen sehr selten. Die wenigen, die ich gesehen habe, stammen von Fehlern bei der Angabe der Taktbeschränkungen.

Normalerweise liegt das Problem am anderen Ende. In Ihrer Simulation scheinen sich alle von Ihrer Uhr gesteuerten Flip-Flops sofort zu ändern, und ihre Ergebnisse sind sofort für jede Logik verfügbar, die sie benötigt. In echter Hardware gibt es eine gewisse Verzögerung zwischen der Taktflanke und dem Flip-Flop-Ausgang ("Clock-to-Q"-Zeit), und es gibt aufgrund von eine gewisse Verzögerung zwischen dem Flip-Flop-Ausgang und dem nächsten Flip-Flop-Eingang Verzögerungen beim Routing und Logikgatter. Wenn diese Verzögerungen zu groß werden, sehen Sie in Ihrem Timing-Bericht eine „Einrichtzeitverletzung“. Das Beheben von Setup-and-Hold-Verstößen wird als „Timing Closure“ bezeichnet.

Überlappende Takt- und Datenflanken in Designs mit mehreren Zustandsmaschinen
AntwortenHierDatenschutz-Bestimmungen1y, 0v