Ich habe ein Problem mit Xi constraints: Das Design kann nicht korrekt geroutet werden - irgendwo hängt er sich auf. Ich habe das hier schon mal bezüglich der Outputs angesprochen: Beitrag "Re: Spartan3 - DDR / DCM - Timing-Constraint-Probleme" Mir ist nicht klar auf welchen Takt ich mich jeweils beziehen muss, damit XI versteht, was ich will. In meinem Design habe ich inputmässig 2 Fälle: Ich synchronsiere u.a. Schalterstellungen ein und habe diese in FFs registriert. Takt ist der Systemtakt im FPGA "Takt1" , der über einen DCM kommt. (QUARZ -> DCM -> TAKT1 , TAKT2 , TAKT3) Praktisch sind "QUARZ" = 50MHz -> 20ns und TAKT1 = 150 MHz -> ~6ns Wie muss das constraint beschaffen sein: TIMEGRP "switches" OFFSET = IN 6.6 ns BEFORE "TAKT1" RISING oder die Bezugnahme auf den Eingangstakt TIMEGRP "switches" OFFSET = IN 20 ns BEFORE "QUARZ" RISING bzw TIMEGRP "switches" OFFSET = IN 6,6 ns BEFORE "QUARZ" RISING? Mir geht es einmal darum diese Schalterstellungen zeitlich zu entspannen, zum anderen darum, andere wichtige Signale genau zu spezifizieren. Dies wäre dann Fall2: Ich habe einen Datenbus mit seinem Clock, die nicht abgetastet werden, sondern die Register werden mit dem Takt geschrieben. EXT_DATA (15 downto 0) -> FF-Dateneingang EXT_CLOCK (125 MHz) -> FF-Takteingang Wie constraine ich das? Ich habe eine timegroup für die Daten und benutze den EXT_CLOCK als Bezug. TIMEGRP "Data_INs" OFFSET = IN 4 ns BEFORE "EXT_CLOCK " RISING (Mitte des Bits, da 8ns Timespec). Das wird auch gefressen, aber seither habe ich die Probleme oben. Ich habe auch TIGs gesetzt, kriege aber immer mehr Timing-Fehler.
R. K. schrieb: > Mir geht es einmal darum diese Schalterstellungen zeitlich zu > entspannen, wozu? R. K. schrieb: > TIMEGRP "switches" OFFSET = IN 20 ns BEFORE "QUARZ" RISING bzw > TIMEGRP "switches" OFFSET = IN 6,6 ns BEFORE "QUARZ" RISING? Soweit mir bekannt, müssen die Angaben immer auf den jeweiligen Tlt bezogen sein. Da der Quarz-Takt, also der Eingang der PLL benutzt wird, müssten die SPECs auch hinsichtlich des Offsets so beschaffen sein, also Vesion 1 stimmen. Ich lasse mich aber gern vom Gegenteil überzeugen.
Für Eingäng, die sowieso eingetaktet werden (wie zum Beispiel die erwähnten Schalter) gibt es ein TIG (timing ignore) Constraint. Das entspannt die Sache extrem... ;-)
Robert K. schrieb: > Wie müsste das aussehen? Siehe dort Abschnitt "Timing Ignore": http://www.xilinx.com/support/answers/2449.htm
Robert K. schrieb: > und ich brauche dann kein constraint mehr? Das TIG ist das constraint :-) Ansonsten versucht die Software ständig, die Taktflanken zu berechnen und die Zeiten dazwischen einzuhalten.
Ich habe ein ähnliches Problem mit zwei verschiedenen Eingangstakten, wobei der eine seine Daten mit der fallenden Flanke sendet. Damit kommen diese Daten bei mir dann mittenzentriert an. Beide Takte nehmen somit (ohne PLL) ihre Daten in Register rein, daher verstehe ich das hier nicht: Lothar Miller schrieb: > Für Eingäng, die sowieso eingetaktet werden (wie zum Beispiel die > erwähnten Schalter) gibt es ein TIG (timing ignore) Constraint. Das > entspannt die Sache extrem... ;-) Angenommen, ich habe die Daten mit ihren eigenen Takten drin, dann sind sie intern ja nun synchron. Wozu brauche ich dann das TIG? Wie sollte das "entspannend" wirken? Das constraint gibt ihm doch vor, dass er die Daten in der valid-Zeit verarbeiten muss und Dank der Nutzung von IO-FFs sollte er das dann auch schaffen. Das constraint müsste dann lediglich geprüft werden. Oder nicht? Jetzt zur Frage: Wie wäre es, wenn die Daten gemultiplext werden sollen? Der ein Takt sendet auf 33MHz, der andere auf 48MHz. Beide Datenströme werden mit 100 MHz gesampelt und analysiert. Dann brauch ich ein TIG zwischen beiden Eingangstaken und dem Sampletakt. Wie formuliere ich da? Der Sampletakt kommt aus einer PLL mit eigenem Quarz und hat mit den Eingangstakten keinen Bezug.
CZM schrieb: > Der ein Takt sendet auf 33MHz, der andere auf 48MHz. Beide Datenströme > werden mit 100 MHz gesampelt und analysiert. Dann brauch ich ein TIG > zwischen beiden Eingangstaken und dem Sampletakt. Wenn Du die Eingangstakte absampelst, sind es keine Takte mehr, sondern nur noch ganz normale Signale. Alternativ führst Du Deine Datenströme auf asynchrone FIFOs. Da wird mit externem Takt geschrieben und mit dem internen Takt gelesen. Und schon ist die Welt wieder synchron. Duke
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.