Zeiteinschränkungen für weitergeleitete generierte zentral abgetastete Takte

Problembeschreibung

Ich versuche, den "richtigen" Weg herauszufinden, um (im .xdc-Format - dies ist in Vivado) einen weitergeleiteten quellensynchronen Takt zu beschränken, der (durch Division) aus dem Systemtakt generiert und am Empfangsmodul zentriert abgetastet wird. Die Situation ist wie folgt:

Wir haben einen ADC, an den unser FPGA Daten sendet. Die Schnittstelle zum ADC ist quellensynchron: Wir leiten einen Takt mit den Daten weiter. Es wird auch in der Mitte abgetastet, indem wir die Daten (am FPGA) an der fallenden Flanke des weitergeleiteten Takts generieren und die Daten an der steigenden Flanke des weitergeleiteten Takts erfassen. Um die Komplexität zu erhöhen, wird dieser weitergeleitete Takt durch Teilen des Systemtakts erzeugt. Wir möchten in der Lage sein, die Ausgangsverzögerung dieser weitergeleiteten Takte/Daten einzustellen, damit wir die Setup- und Haltezeiten des ADC angeben können. Das Problem ist, dass wir uns nicht sicher sind, wie wir die Multicycle-Einschränkungen angeben sollen, damit Vivado den richtigen Launch- und Capture-Edge ermittelt.

Im wirklichen Leben wird unsere weitergeleitete Uhr nur durch zwei von der Systemuhr geteilt, aber wir wollen wissen, wie das im allgemeinsten Fall geht, und deshalb setzen wir die Teilungsrate beispielhaft auf acht.

Visualisierung

Wellenform mit clk, generiertem (/8) Takt und Daten. Daten werden an der fallenden Flanke des generierten Takts gestartet und an der steigenden Flanke des generierten Takts erfasst:

Wellenform mit clk, generiertem (/8) Takt und Daten. Daten werden an der fallenden Flanke des generierten Takts gestartet und an der steigenden Flanke des generierten Takts erfasst.

Das große Problem besteht darin, die richtigen Multicycle-Einschränkungen herauszufinden. Es scheint keine intuitive Möglichkeit zu geben, festzulegen, dass Daten an der fallenden Flanke des generierten Takts gestartet und durch die steigende Flanke erfasst werden. Das Hauptproblem besteht darin, dass die Daten tatsächlich von der Systemuhr generiert werden – ein FSM (das die generierte Uhr erstellt) stellt sicher, dass neue Daten nur an Kanten gestartet werden, an denen die generierte Uhr fällt. Die "Launch Clock" ist also die Systemuhr, während die "Capture Clock" SCKO ist.

Unten ist eine Zeichnung des Systems; SDO und SCKO sind Ausgänge des FPGA:

Eine Zeichnung des Systems: SDO und SCKO sind Ausgänge des FPGA.

Lösungsversuche

Die Frage nach dem Multicycling konnten wir bezüglich des Setups recht einfach lösen; in diesem Fall setzen wir:

set_multicycle_path 4 -setup -from [get_clocks sys_clk] -to [get_clocks SCKO] -start

Das ist sinnvoll – unsere Erfassungskante ist 4 Zyklen von unserer Startkante entfernt, also verschieben wir die Setup-Zeit nach vorne und halten Zyklen. Diese 4 Zyklen beziehen sich auf die Systemuhr, also stellen wir sicher, dass wir das -start-Flag verwenden, damit der Setup-Multiplikator in Bezug auf die Startuhr steht.

Die Frage ist: Was sollen wir für den Hold-Radweg tun und warum?

Forschung

Zur Recherche können wir Vivados UG903: Using Constraints konsultieren . Von besonderem Nutzen ist der Abschnitt über Multicycle-Pfade – insbesondere der Abschnitt „Multicycles Between FAST-to-SLOW Clocks“ auf Seite 117. Aber das sagt uns nur, wie wir mit einem erweiterten Datenpfad umgehen sollen – wir verstehen nicht, wie wir das auf unseren anwenden sollen Projekt, wo wir sicherstellen müssen, dass Vivado weiß, dass Daten nur auf der fallenden Flanke von SCKO gestartet werden (was NICHT die Uhr ist, die sie generiert - sys_clk generiert sie, sondern nur bestimmte steigende Flanken von sys_clk).

Wir haben versucht, verschiedene Hold-Multiplikatoren zu durchlaufen, sind uns aber nicht sicher, wie das richtig geht. Für unser Beispiel „Teile durch 2“ haben wir festgestellt, dass das Setzen eines Haltemultiplikators von 1 funktionieren würde – der Pfadbericht schien etwas anzuzeigen, von dem wir uns selbst überzeugen konnten, dass es die richtige Antwort war (nämlich, es startete die „Quellenuhr“ eine Periode später die "Startuhr" - dies würde dem Startpfad entsprechen, der an der abfallenden Flanke des weitergeleiteten Takts beginnt, und dem Erfassungspfad, der an der steigenden Flanke des weitergeleiteten Takts beginnt.

Wir haben uns auch mehrere Parameter für unseren generierten Takt, die Ausgangsverzögerung und die festgelegten Multicycle-Pfadbeschränkungen angesehen. Wir haben uns das „-clock_fall“-Flag angesehen, aber dies teilt dem Tool mit, dass wir es auf der fallenden Flanke erfassen möchten (wenn wir ihm eigentlich sagen müssen, dass es auf der fallenden Flanke starten soll, aber von einer anderen Uhr). Wir haben uns auch „-rise“ und „-fall“ angesehen, konnten aber nicht wirklich herausfinden, was diese bewirken oder welche Wirkung sie haben.

Frage

Kurz gesagt: Was ist die richtige Multi-Zyklus-Einschränkung, die hier eingefügt werden sollte, und warum?

Die Lösung für das Teilen durch acht unterscheidet sich vollständig von der Lösung für das Teilen durch zwei, da die Überquerung der Taktdomäne für das Teilen durch acht viel einfacher ist. Für die Division durch zwei würde ich einfach einen Doppeltakt-FIFO verwenden und beim Start eine schnelle Kalibrierung durchführen, um die Phase des Abtasttakts in die Mitte zu verschieben.

Antworten (1)

Wir möchten in der Lage sein, die Ausgangsverzögerung dieser weitergeleiteten Takte/Daten einzustellen, damit wir die Setup- und Haltezeiten des ADC angeben können.

Aus der obigen Erklärung, Sie müssen eine Verzögerung auf den Daten- und Taktleitungen erzeugen, habe ich zwei Lösungen für dieses Problem.

1) mit Input Delay Resources (IDELAY) oder ODELAY https://www.xilinx.com/support/documentation/user_guides/ug471_7Series_SelectIO.pdf

Im Hochgeschwindigkeitsdesign werden einige Verzögerungen in der Leiterplatte mit Verzögerungspuffern kompensiert (diese haben einige Registerkarten mit Verzögerungen).

2) Die zweite Lösung ist die Synchronisierung des FPGA-Takts mit der Rückkopplung des ADC-Takts (erzeugt in PLL). Ich denke, es ist nicht einfach und hilfreich für Ihren Fall!

Bearbeitet:

Ich denke, in FPGA sollten Sie zuerst überlegen, welche Schaltung Sie benötigen , und dann den Compiler anweisen, diese zu generieren. Der Xilinx sagte: "Logischer Pfad, der mehr als einen Taktzyklus benötigt, damit sich die Daten am Endpunkt stabilisieren. Wenn die Steuerschaltung des Start- und Endpunkts des Pfads dies zulässt, empfiehlt Xilinx die Verwendung des Multicycle-Pfads".

In Ihrem Beispiel, in dem Sie zwei Signale von der FPGA-Seite zum ADC haben (Sie sagen nicht, dass ein geringer Stromverbrauch erforderlich ist, der Mehrzyklus hilft diesem Ziel), sagte Xilinx "zu stabilisierende Daten", da dies Metastabilität erzeugen kann. Mit Takt- und Datenpin vom FPGA zum ADC hat die Verzögerung zwischen Taktflanke und stabilen Daten zwei Fälle, der erste größer als ein Zyklus des Takts oder weniger als, für den letzteren Fall ist IDELAY in Ordnung, aber wenn Sie größer als einen Zyklus haben Verzögerung (wo Sie darüber besorgt sein könnten) Sie kompensieren Ihre Verzögerung, indem Sie ein Datum im letzten Taktzyklus oder zwei Takte oder höher einstellen, dann kompensieren Sie die Untertaktverzögerung mit (IDELAY).

Ich denke, Ihr Fall benötigt "set_multicycle_path" nicht . Wenn Sie einen geringen Stromverbrauch wünschen, können Sie sich Gedanken über "Multicycles in Single Clock Domain" machen . Wenn Sie einen Pin haben, der ein Signal von der ADC-Seite empfängt, wenn der ADC nicht weniger als einen Taktzyklus stabil ist, sollten Sie aus Gründen der Metastabilität "Multicycles in Single Clock Domain" ausprobieren .

Wenn Ihr Problem nicht die Verzögerung ist, kann ein Diagramm des Systems und der Signalrichtung zum besseren Verständnis des Problems hilfreich sein.
Das ist nicht wirklich das Problem, sorry. Mein Problem liegt darin, welchen .xdc-Befehl ich schreiben sollte, um ihn richtig einzuschränken, nicht in der Struktur des Systems selbst. Ich werde dem ursprünglichen Beitrag ein Diagramm des Systems hinzufügen.
@YSl, darf ich Sie fragen, warum Sie diese Einschränkung anwenden? (Ich denke zum Beispiel ein Low-Power-Design und eine Verbesserung der Sicherheit). Worauf warten Sie? (in Circuit) jetzt denke ich, dass Halt nicht wichtig ist,
@YSl Warum fügen Sie keinen Eingangspin von ADC hinzu, der sich auf set_multicycle_path bezieht, nicht auf den Ausgangspin, auf den Sie nur Daten senden! Wenn Sie mir sagen, was Sie zur ursprünglichen Schaltung hinzufügen möchten, kann ich das Timing erklären.
Wir schließen diese Einschränkung ein, weil wir sicherstellen möchten, dass unser Ausgangspfad die Setup- und Haltezeiten (mit Trace-Verzögerungen) des ADC erfüllt. Ich bin mir nicht sicher, was Sie mit dem Eingangspin des ADC meinen - die einzige Relevanz, die für die FPGA-Einschränkungen relevant ist, ist die Angabe der Ausgangsverzögerungszahlen. Wir möchten verstehen, wie Multicycle-Einschränkungen im Allgemeinen besser ausgeführt werden können, weshalb diese Frage nach einem -divide_by 8-Pfad fragt, anstatt nach dem echten -divide_by 2-Pfad, den wir haben.
Zeiteinschränkungen für weitergeleitete generierte zentral abgetastete Takte
AntwortenHierDatenschutz-Bestimmungen1y, 0v