Hallo Leute, mir ist etwas merkwürdiges bei der Post-PAR-Simulation aufgefallen. Der Sineout Ausgang ist erst ca. 7ns nach der steigenden CLOCK Flanke stabil. Fehlt da etwa eine Constraint? Von OFFSET OUT/IN habe ich schon gehört. Später soll der Takt für denn DDS Core aber von einer DCM kommen und dann funktioniert diese Constraint nicht, falls ich es richtig verstanden habe. Was nun? Mfg, Kurt
Angehängte Dateien:
-
rtl.png
3,3 KB -
timing.png
190 KB
Was passiert denn in DDS_CORE? Ist das eine RAM-Tabelle? Wann erwartest du denn die Daten? Sollten die Daten nicht mit der zweiten Taktflanke gültig sein?
1 | CLK ___|---|___|---|___|---|___|---| |
2 | FTW <Adresse > |
3 | SIN <Daten > |
So sollte es doch sein ... aber ein paar zusätzliche Informationen deinerseits könnten nicht schaden.
Ok. Hier das Datenblatt vom DDS-Core. Er ist für den Streamingbetrieb konfiguriert. Abgesehen davon wird das Frequenztuningword FTW (PINC_IN) konstant von der Testbench vorgegeben.
Also ich habe mir jetzt fix das Timing angschaut. Laut Blockschaltbild werden die Daten einerseits gepuffert (Phase Accu) und dann per BlockRAM an den Ausgang gelegt. Also 1 Takt plus x ns Latenz. Der BlockRAM ist definitiv nicht synchron. Von daher erscheinen die Daten auch nicht mit der steigenden Taktflanke, sondern sind "irgendwann" gültig. Die Zugriffszeit ist allerdings definiert und somit kannst du dir die Latenz bis zum gültigen Signal entsprechend der Taktfrequenz ausrechnen. Ich hoffe, ich erzähle gerade keinen Unsinn :D
Was im DDS-Core los ist ist doch eigentlich egal. Ich habe (ein wahrscheinlich asynchrones) Signal TMP welches ich auf die steigende CLOCK Flanke synchronisiert auf SINEOUT ausgeben will. Wieso ändert sich SINEOUT noch 7ns nach der Flanke obwol das FF den Wert längst fest gespeichert haben müsste.
Ah, das habe ich ja komplett übersehen ... ich hatte das mit SINE verwechselt. Dieses Verhalten kann ich mir leider auch nicht auf Anhieb erklären. Wie schaut denn der zeitliche Verlauf zwischen den Signalen SINE und SINEOUT aus?
Ist doch ganz klar, die Post PAR Simulation bildet die Wirklichkeit mit den Ausgangsverzögerungen besser ab. In der Verhaltenssimulation erscheint das natürlich zur Flanke, in der Realität brauchts aber einige Zeit vom Register zum Pin. DU kannst das letzte Register ja mal in den IOB packen lassen, dann sollte es etwas schneller gehen, aber je nach Chip sind 7ns durchaus normal. Wenn du den CLK auch ausgeben willst/musst, dann am besten mit einem ODDR Register, dann hat er annähernd die gleiche Verzögerung wie die Daten.
@Kurt Wenn du die IO-s schnell schalten willst solltest du die IO-Timings deines Bausteins kennen, im Falle eines Xilinx-FPGAs hier am Beispiel des spartan-3 im "ds099.pdf" auf Seite 67 (Kapitel IO-timing): http://www.xilinx.com/support/documentation/data_sheets/ds099.pdf Zitat: "When reading from OFF, the time from the active transition on the Global Clock pin to data appearing at the Output pin. The DCM is not in use." Dann steht in Tabelle das bei einem 12mA lvcmos25 FAST Ausgang der die "clock-to-output" time je nach Typ 3.9..5.0 nanosekunden betragen kann. Bei anderen Treiberstärken muss man dann die Zahlen von Tabelle 46 addieren. In deinem UCF-File fehlt die Angabe "DRIVE=" und "SLEW=", dann nimmt der ISE (v10) 12mA und "SLEW=SLOW" als default., was nach Tabelle 46 zusätzlich einen Delay von ca 3. nanosec. bedeuten kann. Die Bedingungen für welche diese Zeiten gelten, sind dann auf den folgenden Seiten erklärt. Den delay kannst du nur durch stärkere Ausgänge veringern. Am schnellsten schalten LVCMOS(xx) IOS dann bei 24mA SLEW=Fast. Und dann aber auch noch die "Simultaneously Switching Output Guidelines" beachten (Seite 79ff). Zugegeben alles eine trockene Lektüre.
Mir wird langsam klar das mein Problem eigentlich garkeins ist. Ich kann nicht erwarten dass die Ausgänge sofort nach der internen steigenden Flanke einen stabilen Zustand annehmen. Es muss nur dafür gesorgt werden dass sie stabil sind bevor ich meinen Clock ausgebe. Da muss ich morgen nochmal drüber nachdenken. ;-)
Da sieht man was passiert wenn man nur mit Altera rumspielt :) Das SINEOUT ein IOB ist und nicht irgendein interenes Signal hab ich komplett übersehen. Das erklärt natürlich so einiges und die richtigen Antworten kamen ja bereits. And dieser Stelle unterscheiden sich die Schematics doch etwas mehr voneinander. Sorry für die unqualifizierten Einträge meinerseits :)
Naja, ganz im ersten posting stand ja schon "Post PAR Simulation", das erklärt die halbwegs realen Verzögerungszeiten. Du musst halt bei der Ausgabe nur dafür sorgen, dass der Takt phasengleich mit dem Signal gegeben wird, dann übernimmt der externe Baustein die Daten mit der nächsten Flanke.
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.