Zeitbeschränkungen

Ich muss 24-Bit-Daten auf einem DAC mit 25 MHz abtasten. Die Daten stammen aus einem Design, das ich auf FPGA implementiert habe. In jedem Taktzyklus gibt das FPGA 24-Bit-Daten aus, die der DAC im nächsten Zyklus abtasten muss. Ich habe ein Bild des Designs beigefügt, das ich mache. Wie kann ich die zeitlichen Beschränkungen für mein Design auf FPGA definieren? Ich habe Taktbeschränkungen für 100 MHz und 25 MHz in meinem Design auf FPGA festgelegt. Das Problem ist nun, dass sowohl der FPGA- als auch der DAC-Chip in unbekannter Entfernung auf dem Virtex-4-Evaluierungsboard sitzen. Wie kann also sichergestellt werden, dass das Timing dort eingehalten wird, wenn die Routing-Verzögerung auf dem Pfad unbekannt ist? Was sollten die Eingangs-/Ausgangsverzögerungseinschränkungen sein?

Geben Sie hier die Bildbeschreibung ein

Es ist viel besser, das Schnittstellendesign vollständig quellensynchron zu gestalten, das heißt, Sie takten Ihren Benutzerlogikausgang mit 50 MHz und behandeln den Takt genau wie eine Datenleitung, sodass sich alle Daten und der Takt mit dem gleichen bekannten Timing ändern. Auf diese Weise spielt die Entfernung zum DAC keine Rolle, alle Daten und der Takt werden um den gleichen Betrag verzögert. 25 MHz bis 24 Bit Genauigkeit? Viel Glück!
@Neil_UK Wie machen wir es tatsächlich quellensynchron auf dem FPGA-Board? Erfolgt dies über HDL-Codierung oder über werkzeugspezifische Optionen in vivado/quartus?
Schreiben Sie HDL, um Ihre Uhr und Ihre Daten zu steuern, behandeln Sie die Uhr wie eine Datenleitung, sodass sich alle Daten und die Uhr mit demselben bekannten Timing ändern, sodass ein Register mit Daten und einem zusätzlichen Bit aktualisiert wird, das die Uhr ist.
@Neil_UK Okay. Und wir müssen diese neue Uhr als "erzeugte Uhr" einschränken, richtig?
Nehmen Sie Ihre externe Uhr mit 4-facher Geschwindigkeit und verwenden Sie sie, um das Ausgangsregister zu takten. Ich gehe davon aus, dass Sie registrierte E / A verwenden werden. Alle N+1 Zeilen von N Daten und 1 Datentakt erhalten die gleiche Behandlung. Das Signal zum data_clock-Bit in den I/O-Latch wird 100M/4 sein, dies kann auch als CE verwendet werden, was auch immer die Daten in den I/O-Latch verschiebt, bereit, an den DAC ausgegeben zu werden.
Oh ja ... auf diese Weise ist die Möglichkeit einer Setup-Verletzung und einer Halteverletzung unwahrscheinlich, da Daten- und Taktleitungen eine ähnliche Routenverzögerung aufweisen würden.
Nun, man entwirft Dinge nicht, damit Timing-Verletzungen unwahrscheinlich sind, man entwirft Dinge, damit Timing-Verletzungen nicht passieren. Es spielt keine Rolle, welche Kabellänge zum DAC führt oder wie sich die FPGA-Temperatur ändert, der Takt und die Daten kommen dort mit minimalem Line-to-Line-Versatz an. Sie wählen eine data_clock-Phase und eine neue Datenausgabe-CE-Phase, um den data_clock-Übergang am DAC in der Mitte des gültigen Datenfensters am DAC zu positionieren . Die Verwendung von quellensynchronen Daten bedeutet, dass dies mit der Phaseneinstellung an den FPGA-Ausgangsanschlüssen identisch ist.

Antworten (1)

Bei 25 MHz sind Platinenverzögerungen wahrscheinlich weitgehend irrelevant (es ist die Art von Sache, über die Sie sich bei Speichertakten mit mehreren hundert MHz Sorgen machen).

Als erstes würde ich sicherstellen, dass die Ausgabe der Benutzerlogik von diesem 25-MHz-Takt registriert wird, um sicherzustellen, dass Sie an diesem Punkt das Timing definiert haben, und dann Einschränkungen für die Daten relativ zum 25-MHz-Starttakt definieren, indem Sie den DAC untersuchen Datenblatt für die Setup-and-Hold-Timings können Sie es sich leisten, hier etwas konservativ zu sein, da alles so langsam läuft.

Hm! Ja. Ich denke, da hast du einen Punkt. Mit 40 ns Zeitdauer ist es ziemlich langsam.
Ungefähr 9 Zoll pro ns, das ist etwas Brett!