Prozess-Timing auf FPGA

Ich bin neu bei fpgas und es gibt einige zeitliche Feinheiten, die ich nicht sicher verstehe: Wenn alle meine synchronen Prozesse an derselben Flanke ausgelöst werden, bedeutet dies, dass meine Eingaben an einer steigenden Flanke und an meiner erfasst werden Ausgänge ändern sich an .. der gleichen Flanke? die nächste steigende Flanke?

Wenn ich zwei Module habe, bei denen der Ausgang eines Moduls in die Eingänge des nächsten fließt, kann es vorkommen, dass sich die Eingänge meines Moduls (die Ausgänge eines vorherigen Moduls) gleichzeitig mit der Erfassung ändern.

Die Markierung bei 205 ns zeigt, wovon ich spreche, wobei op und data_write meine Eingaben sind. In diesem Testfall scheint alles "nur zu funktionieren", aber in der Simulation ist nicht klar, was wann genau erfasst wird. Wird data_write = "0001 ..." bei 205 ns oder (205 ns + 1 Taktzyklus) erfasst? Gibt es eine Möglichkeit, detailliertere Wellenformen in ISim zu erhalten, die Setup- und Haltezeiten anzeigen?

Vielen Dank.

Es gibt immer eine gewisse Laufzeitverzögerung durch das Flip-Flop. Es wird oft als "Clock-to-Q" -Verzögerung bezeichnet.

Das bedeutet, dass Ihre Eingaben an der Kante erfasst werden und sich Ihre Ausgaben an derselben Kante ändern, jedoch nur wenige Nanosekunden später. Diese Verzögerung von wenigen Nanosekunden reicht aus (wenn Ihre Flip-Flops wie in den meisten FPGAs mit einer Haltezeit von Null ausgelegt sind), damit die Änderungen keine nachgeschalteten Flip-Flops bis zur nächsten Taktflanke beeinflussen.

In der Funktions- oder RTL-Simulation (was wahrscheinlich der Fall ist, um Ihr Ergebnis zu erzielen) wird die Verzögerung nicht als dauerhafte Nanosekunde simuliert. In VHDL ist es ein einzelner Delta-Zyklus der Simulatoruhr, was technisch gesehen überhaupt keine Zeit ist. Dies macht es unmöglich, die Verzögerung in der Simulatorausgabe zu sehen. Für die als ideal simulierten Flip-Flops reicht es jedoch aus, dass die Ausgangsänderungen keine Auswirkungen auf nachgeschaltete Flip-Flops haben.

Wenn Sie eine Post-Place-and-Route-Simulation durchführen, sollten geeignete Verzögerungen berücksichtigt werden können, damit Sie diese Effekte auf Kosten eines erhöhten Simulationsaufwands klar erkennen können.

Bei der gewünschten Taktflanke (steigend oder fallend) erscheint der Eingang an D am Ausgang Q. Dies dauert eine begrenzte Zeit (Verzögerung von Takt zu Q) und unter der Annahme, dass keine Zeitverletzungen vorliegen, durchläuft D jeweils nur einen FF (dh wenn ein anderer FF-Eingang mit Q verbunden ist, übergibt der zweite FF den FF1 Q-Wert, bevor er sich ändert.

Um Timings in Ihre Simulation aufzunehmen, müssen Sie Ihr Design synthetisieren, platzieren und routen und dann eine Post-Place- und Routensimulation ausführen. Dies beinhaltet alle kombinatorischen Verzögerungen von Takt zu Q usw. Die HDL-Simulation hat keine dieser Zeitabläufe, daher ist sie nur zum Testen des Grundbetriebs nützlich, nicht für Zeitlimits. Sie erhalten außerdem einen Timing-Bericht, in dem Sie die Geschwindigkeitsbegrenzungen einer bestimmten Taktdomäne angeben, Sie über Timing-Verstöße informieren und die Timing-Lücke für verschiedene Pfade anzeigen können. Mithilfe dieser Informationen können Sie herausfinden, wo Änderungen vorgenommen werden müssen, oder Regeln hinzufügen, um der Software mitzuteilen, dass der Verstoß kein Problem darstellt (z. B. für Mehrzykluspfade oder Kreuztaktpfade).

Dies ist als Ergänzung zu den vorherigen Antworten gedacht, von denen ich glaube, dass Sie auf die Idee kommen.

Diese Dinge können in der Tat am Anfang etwas schwierig sein, wenn RTL-Simulationen entworfen werden, da es schwierig ist zu erkennen, was die Ursache und die Wirkung in idealen / funktionalen / RTL-Simulationen ist (= keine Ausbreitungsverzögerungen).

Mit dem richtigen Simulator, die Delta - Verzögerungen können tatsächlich sichtbar gemacht werden. ISim tut es nicht, aber in ei ModelSim können Sie die Delta-Erweiterung um die Taktflanken aktivieren . Unten sehen Sie einen Beispiel-Screenshot von einer fehlerhaften IP eines Drittanbieters, die ich behoben habe.

cist das Taktsignal, und die +1usw. sind die als Zeit visualisierten Delta-Zyklen.

Wenn ein Entwurf simuliert wird, bei dem sowohl die Simulation als auch der Entwurf wirklich ideal und synchron sind , ohne dass Verzögerungen simuliert werden, können Sie im Prinzip alle Signaländerungen an einer bestimmten Taktflanke als etwas nach dieser Taktflanke auftretend betrachten. In Ihrem Beispiel wird daher bei 205 ns data_write= 0000...erfasst. Einige andere Logik in der ersten Einheit ändert , das Signal data_writean 0001...auf der gleichen Flanke, und das Signal erscheint auf data_writeleicht nach der Taktflanke. Dies "kurz danach" wäre ein oder mehrere Simulationsdeltas in einer idealen Simulation (Ihr Beispiel) (nicht sichtbar in ISim, aber z. B. in ModelSim mit Delta-Erweiterung) oder einige ps / ns später in der realen Welt.

Nebenbei bemerkt: Eine wichtige Sache beim RTL-Design ist es, sicherzustellen, dass die Eingänge immer an der Taktflanke abgetastet werden - selbst ein Delta-Zyklus später ist zu spät. Die Eingabe ist möglicherweise ein Delta später nicht mehr gültig. Oder mit anderen Worten: "Leg dich nicht mit dem Taktpfad an".