Hallo,
ich habe mal eine Frage zu einem FIFO, den ich mit COREGEN von Xilinx
generiert habe.
Als Input habe ich ein 16 Bit Bus mit einer Clock von 100MHz.
Der Output ist ein 64 Bit großer Datenbus und wird ausgelesen mit der
Taktdomain 280MHz.
Nun ergeben sich bekannter Weise Timing errors aufgrund des Cross
Clocking Domains im FIFO:
User schrieb:> Als Input habe ich ein 16 Bit Bus mit einer Clock von 100MHz.
Die Datenrate beträgt also 1.6 GBit/s.
> Der Output ist ein 64 Bit großer Datenbus und wird ausgelesen mit der> Taktdomain 280MHz.
Hier ergibt sich 17.9 GBit/s als Datenrate, also reichlich das
zehnfache.
Überträgst Du nur einzelen Datenworte oder ganze Blöcke?
Für einzelne Datenworte könntest Du in der 100 MHz Domäne eine
Signalleitung toggeln, wenn ein neues Datum eintrifft. Diese Leitung
wird in der 260 MHz Domäne einsynchronisiert und ausgewertet.
Duke
Duke Scarring schrieb:> User schrieb:>> Als Input habe ich ein 16 Bit Bus mit einer Clock von 100MHz.> Die Datenrate beträgt also 1.6 GBit/s.>>> Der Output ist ein 64 Bit großer Datenbus und wird ausgelesen mit der>> Taktdomain 280MHz.> Hier ergibt sich 17.9 GBit/s als Datenrate, also reichlich das> zehnfache.
Die Bruttodatenraten sind schon richtig.
Aber netto lese ich x-fach langsamer aus.
Wenn ich den Timing Fehler in Planahead untersuche ist das der Ausgang
vom RAM (FIFO) zum FF (das mal 64Bit). Da ich diese zwischengepufferten
Daten in den FF erst nach x Takten vom 280MHz abhole will ich das Timing
hier ignorieren. Oder?!
Duke Scarring schrieb:> Überträgst Du nur einzelen Datenworte oder ganze Blöcke?
Das FIFO soll später als Pipelining für die Crossing Clock Domain vom
100 auf 280MHz dienen. Die Datenblöcke werden in ein DDR2 Ram vorher
abgelegt und auf Befehl über den hier genannten FIFO zur 280MHz Domain
übertragen/umgesetzt. Letztendlich wird in der 280MHz Domain ein Camera
Link Interface realisiert.
User schrieb:> Aber was bedeuten diese Fehler, das will ich verstehen. Darf ich diese> einfach ignorieren???
Sehr gute Einstellung, auf keinen Fall ignorieren!
Der zweite Teil zeigt ein Timing Problem auf einem intra-Clock Pfad
(Source und Destination Clock sind dieselben). Sprich dein P&R bekommst
kein Routing hin, bei dem die Timings eingehalten werden.
Ich wuerde folgende Strategie empfehlen:
1.) Nutze den SmartXplorer und lass mal ein paar Runs mit
unterschiedlichen Placer Cost Tables durchlaufen. Jeder Run erzeugt ein
neues Mappping und vielleicht findet P&R dann ein besseres Routing.
2.) Wenn 1.) nicht hilft, kannst du (falls noch nicht geschehen) dein
Fifo umkonfigurieren und es mit Output Register verwenden. Damit erhoeht
sich zwar deine Output Latenz um ein Clock Cycle, jedoch schafft der P&R
damit deutlich einfacher das Timing. Das wuerde auch ziemlich dem
entsprechen was dein zweiter Report berichtet, da er das Routing
zwischen dem BRAM Element und dem naechsten FF nicht einhalten kann.
Vielleicht koenntets du noch angeben um welchen FPGA Typ es geht. Dann
kann man ein bisschen besser einordnen ob die 280 MHz machbar sind.
Tobias B. schrieb:> 1.) Nutze den SmartXplorer und lass mal ein paar Runs mit> unterschiedlichen Placer Cost Tables durchlaufen. Jeder Run erzeugt ein> neues Mappping und vielleicht findet P&R dann ein besseres Routing.
Wo finde und wie verwende ich bitte den SmartXplorer? Hab das nie
benutzt.
Tobias B. schrieb:> 2.) Wenn 1.) nicht hilft, kannst du (falls noch nicht geschehen) dein> Fifo umkonfigurieren und es mit Output Register verwenden. Damit erhoeht> sich zwar deine Output Latenz um ein Clock Cycle, jedoch schafft der P&R> damit deutlich einfacher das Timing.
Ich benutze das FiFo mit der Option First-Word-Fall-Through, heißt am
Außgang des FiFos liegen schomal die Daten bereit.
Tobias B. schrieb:> Das wuerde auch ziemlich dem> entsprechen was dein zweiter Report berichtet, da er das Routing> zwischen dem BRAM Element und dem naechsten FF nicht einhalten kann.
Im Bild 1 und 2 sieht man Ausschnitte aus dem Floorplaner (Timing
Analyze) zum Path mit einem Timing Error.
Letztendlich ist es ein Timing Fehler vom RAM (FIFO) zum ersten FF
innerhalb der FIFO Instanz. Dieses Signal wird dann durchgeschliffen und
gelangt in einer anderen Instanz in ein LUT6 (siehe Bild 3).
Der Timing Fehler passiert quasi am FDRE (*/dout_i_2), aber durch meine
Hardwarebeschreibung in u_CL_ELLISA lese ich das Signal x Takte (durch
ein Clock Enable Signal) später in FD (i_PIXELDATA_2) ein.
Daher spielt hier ein Timing Fehler keine Rolle, da das Signal genug
Zeit hatte die Setup Time am LUT einzuhalten, sodass die Timing Errors
ignoriert werden können. Richtig?
Hoffe das ich es verständlich erklärt habe :-)
Tobias B. schrieb:> Vielleicht koenntets du noch angeben um welchen FPGA Typ es geht. Dann> kann man ein bisschen besser einordnen ob die 280 MHz machbar sind.
Es ist ein Virtex 5, soweit ich gesehen habe gehen die BRAMs und FF bis
450MHz bei Speed Grade -1. Noch am Rande, habe die 280MHz auf 350MHz
(ich böser) erhöht weil ich sowohl eine IP-Core für 280MHz und 350MHz
Camera Link Schnittstelle brauche. Teste quasi beide durch.
User schrieb:> Tobias B. schrieb:>> 1.) Nutze den SmartXplorer und lass mal ein paar Runs mit>> unterschiedlichen Placer Cost Tables durchlaufen. Jeder Run erzeugt ein>> neues Mappping und vielleicht findet P&R dann ein besseres Routing.>> Wo finde und wie verwende ich bitte den SmartXplorer? Hab das nie> benutzt.
Die Anleitung ist ein bisschen alt (ISE 11) sollte aber im Grunde
taugen:
https://www.xilinx.com/support/documentation/sw_manuals/xilinx11/ise_c_using_smart_xplorer.htm
ISt wirklich narrensicher zu bedienen, einfach mal ein bisschen
rumspielen.
User schrieb:> Tobias B. schrieb:>> 2.) Wenn 1.) nicht hilft, kannst du (falls noch nicht geschehen) dein>> Fifo umkonfigurieren und es mit Output Register verwenden. Damit erhoeht>> sich zwar deine Output Latenz um ein Clock Cycle, jedoch schafft der P&R>> damit deutlich einfacher das Timing.>> Ich benutze das FiFo mit der Option First-Word-Fall-Through, heißt am> Außgang des FiFos liegen schomal die Daten bereit.
Ok, das koennte das Problem erklaeren. Du kannst ja mal spasseshalber
FWFT deaktivieren und einen neuen Run starten. Duerfte das Timing wohl
positiv beeinflussen.
User schrieb:> Tobias B. schrieb:>> Das wuerde auch ziemlich dem>> entsprechen was dein zweiter Report berichtet, da er das Routing>> zwischen dem BRAM Element und dem naechsten FF nicht einhalten kann.>> Im Bild 1 und 2 sieht man Ausschnitte aus dem Floorplaner (Timing> Analyze) zum Path mit einem Timing Error.> Letztendlich ist es ein Timing Fehler vom RAM (FIFO) zum ersten FF> innerhalb der FIFO Instanz. Dieses Signal wird dann durchgeschliffen und> gelangt in einer anderen Instanz in ein LUT6 (siehe Bild 3).> Der Timing Fehler passiert quasi am FDRE (*/dout_i_2), aber durch meine> Hardwarebeschreibung in u_CL_ELLISA lese ich das Signal x Takte (durch> ein Clock Enable Signal) später in FD (i_PIXELDATA_2) ein.> Daher spielt hier ein Timing Fehler keine Rolle, da das Signal genug> Zeit hatte die Setup Time am LUT einzuhalten, sodass die Timing Errors> ignoriert werden können. Richtig?> Hoffe das ich es verständlich erklärt habe :-)
Das ist korrekt analysiert. Lies dir mal in UG190 das Kapitel "Block
RAM" durch:
https://www.xilinx.com/support/documentation/user_guides/ug190.pdf
Ich darf zitieren:
"The output data path has an optional internal pipeline register. Using
the register mode is strongly recommended. This allows a higher clock
rate, however, it adds a clock cycle latency of one."
Sprich das Pipelining geht schon innerhalb der BRAM Instanz los. Falls
deine nachfolgende Logik das ab kann, bzw. du das entsprechend umgebaut
bekommst, wuerde ich das auf jedenfall empfehlen. Immerhin ist dein Bus
64 bit breit und wird mit 280+ MHz getaktet. Das ist kein
Zuckerschlecken.
Wenn das wirklich keine Rolle spielen soll (dazu muesste man mal den
Code noch sehen, dann kann ich mir besser vorstellen was passiert), dann
ist das Stichwort: Multi-Cycle-Path genau das was du suchst.
Tobias B. schrieb:> Die Anleitung ist ein bisschen alt (ISE 11) sollte aber im Grunde> taugen:>> https://www.xilinx.com/support/documentation/sw_manuals/xilinx11/ise_c_using_smart_xplorer.htm>> ISt wirklich narrensicher zu bedienen, einfach mal ein bisschen> rumspielen.
Danke, super tool, habs gleich mal ausprobiert.
Tobias B. schrieb:> Sprich das Pipelining geht schon innerhalb der BRAM Instanz los. Falls> deine nachfolgende Logik das ab kann, bzw. du das entsprechend umgebaut> bekommst, wuerde ich das auf jedenfall empfehlen. Immerhin ist dein Bus> 64 bit breit und wird mit 280+ MHz getaktet. Das ist kein> Zuckerschlecken.
Ich habe mal fürs Pipelining die Option "Use Embedded Registers in BRAM
or FIFO (when possible)" aktiviert (mit FWFT Methode Latency = 0!) beim
Fifo Generator in Coregen, der hat das FF in der FIFO instanz weg
genommen (siehe Bild 2 in vorherigem post) und hat den FF in meiner
Instanz direkt mit dem FIFO Output verbunden bzw. das LUT (inkl. Clock
Enable Signal) ist noch vorm FF gesetzt (siehe Bild 4). Die Timing
Errors sind selbst bei 350MHz Taktdomain weg!
Tobias B. schrieb:> Wenn das wirklich keine Rolle spielen soll (dazu muesste man mal den> Code noch sehen, dann kann ich mir besser vorstellen was passiert), dann> ist das Stichwort: Multi-Cycle-Path genau das was du suchst.
An Multi-Cycle habe ich auch schon gedacht, hab das an anderen Stellen
schon drin, was die Timing Analyse entspannt.
Ist es aber sinnvoll an einem FIFO output ein Multi-Cycle Contraints
anzulegen?
Wenn ich jetzt an meine i_PIXELDATA_* (siehe Bild 4) ein multicycle
setzen will um das Timing weiter zu entspannen, obwohl keine timing
errors mehr da sind, würde das hier reichen:
User schrieb:> Danke, super tool, habs gleich mal ausprobiert.
Gerne, der SmartXplorer ist vor allem bei grossen Designs unverzichtbar,
bei dem der FPGA so voll wird, dass es fuers P&R schwer wird geeignete
Routings zu finden. Muss man dann teilweise ueber Nacht oder sogar ein
paar Tage laufen lssen, lohnt sich dann aber (vor allem bei einem
Mehrkern Rechner). Wichtig ist nur, dass man genuegend RAM hat. :-)
User schrieb:> Ich habe mal fürs Pipelining die Option "Use Embedded Registers in BRAM> or FIFO (when possible)" aktiviert (mit FWFT Methode Latency = 0!) beim> Fifo Generator in Coregen, der hat das FF in der FIFO instanz weg> genommen (siehe Bild 2 in vorherigem post) und hat den FF in meiner> Instanz direkt mit dem FIFO Output verbunden bzw. das LUT (inkl. Clock> Enable Signal) ist noch vorm FF gesetzt (siehe Bild 4). Die Timing> Errors sind selbst bei 350MHz Taktdomain weg!
Genau das war das erhoffte Ergebnis. Statt dem relativ weitem Routing
weg vom BRAM Ausgang zu den ersten CLB FFs, werden nun FFs im BRAM
verwendet direkt nach dem RAM Latch. Das ist Timing-technisch einfach
optimaler, man muss halt mit dem zusaetzlichen Cycle Latenz
zurechtkommen. Aber offensichtlich macht der FIFO Generator das alles
fuer dich. Ich nehme hauptsaechlich direkt die FIFO Macros daher fehlt
es mir an Erfahrung mit dem FIFO Generator.
User schrieb:> An Multi-Cycle habe ich auch schon gedacht, hab das an anderen Stellen> schon drin, was die Timing Analyse entspannt.> Ist es aber sinnvoll an einem FIFO output ein Multi-Cycle Contraints> anzulegen?
Generell wuerde ich nein sagen, im Gegenteil, das kann/wird im
Allgemeinen in die Hose gehen. Stell dir vor du laesst den Read Enable
fuer 2 Cycles hintereinander high, weil du eben 2 Datenwoerter aus dem
FIFO anfordern willst. Dann darf fuer das erste Wort auf keinen Fall
eine Multicycle Bedingung gelten um erfolgreich im ersten FF zu landen.
Als Faustregel kannst du nehmen: Signale die quasi-statisch sind, koenen
gefahrlos mit einem Multicycle belegt werden. Quasi-statisch bedeutet in
dem Kontext, dass sie sich nur selten aendern. Je seltener, desto
statischer, desto laenger der Multicycle und eifnacher das Timing. FIFO
Outputs gehoeren in der Regel nicht dazu, da sich die Signale mit jedem
Takt aendern koennen und damit maximale Dynamik aufweist.
User schrieb:> Ich danke dir sehr.>> Du hast mir echt weitergeholfen>> Vielen Dank auch an alle die sich Zeit genommen haben.
Gern geschehen. Hoffentlich bleibt das auch in Zukunft so, trotz der
heutigen EU Paralamentsabstimmung. :-(
Thread beobachten
Seitenaufteilung abschalten