Ich verwende ein Design mit 3 Takten, die alle aus demselben OSC stammen. Konkret werden aus 100MHz input sowohl 25MHz, 75MHz und auch 150 MHz erzeugt. Bei der Vergabe der Setup-hold Constraints mit Xilinx ISE erkennt das tool aber nicht, dass einige inputs mit der 75er domain und andere mit der 25er abgetastet werden und schlägt als Bezugstakt die 100MHz - und damit 10ns - als setup/hold vor. Praktisch liegen die Daten aussen passend an, um korrekt verarbeitet werden zu können, daher ist es nicht nötigt, sie mit 10ns zu fixieren. Wie stellt man das ein? Reicht es, 40ns für die 25er Bereiche auf den Systemtakt (100 MHz) zu beziehen, oder muss ich die aus der DCM generierte CLK bneutzen? Diese wird nicht angeboten - muss ich das per Hand tun?
Wenn du per DCM neue Takte erzeugst und diese verwendest, dann werden nach Angabe des Basistaktes die abgeleiteten Takte automatisch richtig constrained. Und sogar die Taktübergänge zwischen den "ungeraden" Takten...
Es macht aber - wie ich gerade sehe - einen Unterschied, ob ich die 40ns oder 10ns eintrage. Bei 10ns ist das design nicht routbar, weil er es zeitmässig seltsamerweise nicht packt! (Und dies, obwohl ich genug zusärltiche Register gepipelined für input und outputs hingefügt habe, damit er sie funktionell in die IO-Zellen schaffen kann, was laut MAP report auch der Fall ist).
Paul schrieb: > Bei 10ns ist das design nicht routbar Dann sieh dir mal die "statische Timinganalyse" an. dort siehst du den begrenzenden Pfad und kannst dir mal ansehen, was da los ist...
Ok, ich habe einen extrem langen Pfad, der noch nicht gepiped ist. Es geht mir aber eigentlich um die IOs. Dort muss ich ja ungeachtet irgendwelcher Timing festlegen, wann der dortige Takt mit Daten rechnen kann. Was mich wundert, ist, dass es nicht auf den jeweiligen Takt bezogen werden soll, der dort anliegt. Was ist z.B. wenn ich mir mit einer DCM einige Takte generiere, von denen einer etwas verschoben ist? Dann macht der BEzug auf den speisenden Takt, also den Oszillator quasi auch phasentechnisch keinen Sinn.
Paul schrieb: > Was mich wundert, ist, dass es nicht auf den jeweiligen Takt bezogen > > werden soll, der dort anliegt. Was ist z.B. wenn ich mir mit einer DCM > > einige Takte generiere, von denen einer etwas verschoben ist? Soweit ich weiss, findet er das automatisch. Problematisch ist es mit externen Takten, die keinen Bezug zum Oszillator haben.
R. K. schrieb: > Problematisch ist es mit > externen Takten, die keinen Bezug zum Oszillator haben. Aka. asynchrone Signale. Da kann man gar keine sinnvollen Setup/Hold Zeiten angeben...
Ich meinte jetzt mehr den Bezug der Signale untereinander. Z.B. ein Datenbus und sein Takt. Da habe ich gerade wieder ein Problem, dass er selbst entspannte timings nicht frisst! Beitrag "Xilinx Constraint Problem mit externem Takt"
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.