Forum: FPGA, VHDL & Co. Probleme bei der Umsetzung von constraints


von Peder (Gast)


Lesenswert?

Hallo Forum! Ich verwende Vivado, um das Timing eines FPGA an einen DSP 
anzupassen. Der DSP arbeitet flankengesteuert und schickt Daten mit 
100MHz bei dem steigenden Takt total synchron. Der FPGA hat eine PLL mit 
100MHz auf 100MHz und noch einige Weitere. Übernommen wird mit dem Takt 
aus dem PLL. Mit diesem Takt läuft die gesamte DSP-Seite.

Ich habe die constraints einmal auf "source" und einmal auf "system" 
probiert und komme mit beiden Methoden auf dieselben Vorgaben im XDC:

set_input_delay -clock [get_clocks CLK_100] -min -add_delay 4.000 
[get_ports
set_input_delay -clock [get_clocks CLK_100] -max -add_delay 6.000 
[get_ports

Meines Erachtens habe Ich damit die SPEC korrekt umgesetzt. (?)

Leider kriegt Vivado das timing nicht hin. Gemeckert wird ausschließlich 
bei den IOs. Konkret wird der Bezug des Eingangstaktes (nicht der aus 
der PLL) zu den IO-Daten bemängelt. Ich gehe davon aus, dass das 
trotzdem formell korrekt ist und einfach der PLL-Takt gemeint ist. (?)

Wie stelle Ich das nun ein?

Ich habe bei der ISE immer den Takt solange verstellt, bis Ich einen 
guten Bezug hinbekommen hatte, also so, dass der Takt aus der PLL immer 
schön auf der Mitte der Daten lag, also inmitten des Auges. ISE hatte 
dazu immer einen timing report, der dann die Zeiten so angab, dass die 
einen etwas zu kurz und die anderen zu lang waren. Dann konnte an das 
budget ablesen und es  zentrieren. Meistens hat es gereicht, die PLL auf 
15° genau einzustellen.

Das gelingt hier nicht! Egal, wie Ich es einstelle und schiebe, es 
entsteht immer eine Violation. Sie wird einfach nicht kleiner.

Der Chip ist ein Artix von Xilinx.

von Duke Scarring (Gast)


Lesenswert?

Statt den Takt zu schieben, kannst Du auch die Daten schieben (IDELAY).
Aber ohne belastbare Aussage aus dem Timingreport ist das genauso 
stochern im Nebel.

Duke

von bitwurschtler (Gast)


Lesenswert?

Peder schrieb:
> Das gelingt hier nicht! Egal, wie Ich es einstelle und schiebe, es
> entsteht immer eine Violation. Sie wird einfach nicht kleiner.


Schau dir mal mit FPGA_editor das Routing an. Mglw. ist das ungünstig 
beschrieben, das nicht die IO-FF genutzt werden, sondern das erst über 
ein paar LUT's ins FPGA-Innere geht.

von Peder (Gast)


Lesenswert?

Also, die IO-Delay sind viel zu gering, um das was zu machen und eine 
IO-FFs wird natürlich verwendet. Ist auch gescheckt.

Um es nochmal zu präzisieren, liegt der slack

Bei -60 Grad 7ns
Bei -30 Grad 2ns
Bei   0 Grad 3ns
Bei  30 Grad 12ns

Ich treffe die Null nicht.

Zudem verstehe nicht, warum Ich mehr slack haben kann, als die Periode 
lang ist. Eigentlich sollte der doch auf die andere Flanke gehen, oder?

Macht der was flasch, oder denke Ich was falsch?

von Markus F. (mfro)


Lesenswert?

Ich weiss nicht, wie Vivado das handhabt, aber bei Quartus müsste man in 
deinem Fall (den ich hoffentlich richtig verstehe) die DSP-Clock in den 
Constraints als virtual clock definieren und die Delays darauf anwenden.

von Klakx (Gast)


Lesenswert?

mit positiv und negativ hast du eine Fallunterscheidung. Das könnte 
hilfreich sein.

https://www.xilinx.com/support/answers/59893.html

Würde mich interessieren, ob du es damit lösen konntest. Explizit auch 
welches Beispiel.

Bitte 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
Noch kein Account? Hier anmelden.