Moin,
ich habe ein Design in Xilinx Vivado, das bei 125 MHz knapp das Timing
verfehlt (WNS = -0.173 ns, TNS = -4.768 ns). Es gibt laut Reports in
einem Bereich Probleme mit Routing Congestion, und ich bin mir recht
sicher, dass diese das Timing verschlechtert. Die meisten der Pfade, die
das Timing nicht erfüllen, sind im Bereich mit Routing Congestion.
Nun gibt es allerhand darüber zu lesen, wie man Area Constraints
festlegt, wann man das tun sollte, etc. pp., aber mir fehlt dennoch ein
bisschen der Anhaltspunkt, wie man das praktisch umsetzt. Gibt es
irgendwo praktische Beispiele oder kann jemand erläutern, wie man das
angeht?
greg schrieb:> Nun gibt es allerhand darüber zu lesen, wie man Area Constraints> festlegt
Wenn ein Design auf einem aktuellen FPGA 125 MHz nicht schafft, dann
sollte man sich zuerst das Design ansehen. Die statische Timinganalyse
zeigt den kritischen Pfad, von dort aus findet man dann meist schnell
die zu umständlich beschriebene Stelle. Man sieht auch, ob das
Verhältnis Durchlaufzeit/Routingzeit noch akzeptabel ist.
Am Design gibt's tatsächlich noch einiges, was ich in Zukunft
überarbeiten und refactoren werde, aber nicht im Moment. Es handelt sich
um ein NoC mit selbst entwickelten Routern, zahlreichen
MicroBlaze-Kernen und etwas Peripherie.
Ich habe generell das Gefühl, Place & Route ist überfordert. Das Timing
verhält sich sehr instabil, schon kleine Änderungen an unkritischen
Teilen können das Timing massiv verändern und das Placement auf dem FPGA
komplett über den Haufen werfen. Teilweise gibt's dann sogar Probleme
mit Timing innerhalb der MicroBlaze-Kerne.
Aber auch mit einfachen MicroBlaze-Designs ohne NoC bekam ich da nicht
viel mehr als 150 MHz raus, von daher ist das mit dem Timing nicht so
dramatisch. Ich verwende einen Artix-7, der ist nicht unbedingt auf
hohen Takt optimiert.
greg schrieb:> Es handelt sich um ein NoC mit selbst entwickelten Routern, zahlreichen> MicroBlaze-Kernen und etwas Peripherie.
Okokok, da könnte doch noch ein wenig Handarbeit beim Placement
helfen...
greg schrieb:> Aber auch mit einfachen MicroBlaze-Designs ohne NoC bekam ich da nicht> viel mehr als 150 MHz raus, von daher ist das mit dem Timing nicht so> dramatisch. Ich verwende einen Artix-7, der ist nicht unbedingt auf> hohen Takt optimiert.
Speedgrade?
Wenns nur ganz knapp ist, nimm evtl. einfach eine Nummer schneller falls
möglich.
(zumindest mal ausprobieren obs damit funktionieren würde)
greg schrieb:> Aber auch mit einfachen MicroBlaze-Designs ohne NoC bekam ich da nicht> viel mehr als 150 MHz raus, von daher ist das mit dem Timing nicht so> dramatisch. Ich verwende einen Artix-7, der ist nicht unbedingt auf> hohen Takt optimiert.
Nach
http://www.xilinx.com/support/documentation/sw_manuals/xilinx14_2/pg048-microblaze-mcs.pdf
S. 7
sollte ein uB auf Artix-7 -3 mit 225 MHz laufen, also 75 MHz mehr als du
nennst - das klingt bedenklich. Mglw. ist da ein grober Schnitzer in der
Tool-Opts oder das Taktnetzwwerk ist suboptimal aufgebaut (viel skew).
MfG,
greg schrieb:> Moin,> Nun gibt es allerhand darüber zu lesen, wie man Area Constraints> festlegt, wann man das tun sollte, etc. pp., aber mir fehlt dennoch ein> bisschen der Anhaltspunkt, wie man das praktisch umsetzt. Gibt es> irgendwo praktische Beispiele oder kann jemand erläutern, wie man das> angeht?
Neue Designs lasse ich mit geringen Optimierungslevel übersetzen. Wenn
das timing nicht mehr passt, suche ich mit dem timing analyzer nach dem
kritischen Pfad. Dann setze ich die optimierungs hoch, oft passt dann
das timing. Jetzt schau ich per fpgaeditor wie der kritische Pfad
geroutet/gemappt wurde.
Das nagele ich dann per Area/mapping o.ä. constraint fest und setzte
wieder zurück auf leicht Optimierung. Wenn jetzt das timing erfüllt ist
, ist der Job erledigt.
MfG,
Naja, für einen µB kommt das sicherlich hin. Aber er hat ja "zahlreiche"
und dann kommt das Routing schnell an seine Grenzen. Die benötigten
Routing-Ressourcen sind dann im Verhältnis zur verwendeten Logik/FFs so
hoch, dass der Router z.T. lange Wege in Kauf nehmen muss und dann wirds
lansam.
Fpga Kuechle schrieb:> sollte ein uB auf Artix-7 -3 mit 225 MHz laufen, also 75 MHz mehr als du> nennst - das klingt bedenklich. Mglw. ist da ein grober Schnitzer in der> Tool-Opts oder das Taktnetzwwerk ist suboptimal aufgebaut (viel skew).
Das Dokument kenne ich. Erstens habe ich den Speed Grade -2. Zweitens
ist es nicht vergleichbar mit meinem Fall: ich verwende nicht das
Microblaze MCS mit dem "size optimized" MicroBlaze mit
Minimalstkonfiguration, sondern einen "performance optimized" MicroBlaze
mit einer sehr umfangreichen Konfiguration mit Multiplizierer,
Barrel-Shifter, FPU, usw. Wenn ich den Kram rausschmeiße, geht's auch
schneller.
Es sind im übrigen im Moment acht MicroBlazes, aber es sollen noch
deutlich mehr werden. :)
Fpga Kuechle schrieb:> Das nagele ich dann per Area/mapping o.ä. constraint fest und setzte> wieder zurück auf leicht Optimierung. Wenn jetzt das timing erfüllt ist> , ist der Job erledigt.
Hm, einfach die kritischen Pfade per Constrain woanders lang ziehen? Mal
gucken, ich probier das einfach mal.
Ein paar Optimierungen an meinem NoC-Router habe ich jetzt aber auch
gemacht, schauen wir mal.
greg schrieb:> Fpga Kuechle schrieb:>> sollte ein uB auf Artix-7 -3 mit 225 MHz laufen, also 75 MHz mehr als du>> nennst - das klingt bedenklich. Mglw. ist da ein grober Schnitzer in der>> Tool-Opts oder das Taktnetzwwerk ist suboptimal aufgebaut (viel skew).>> Das Dokument kenne ich. Erstens habe ich den Speed Grade -2. Zweitens
Das ist endlich mal ne konkrete Info. Wichtig ist ebenfalls:
-Anzahl logic level also wie komplex ist die Kombinatorik. Mit den 6 er
LUT
sollte alles was nur 6 Eingänge in einem Logic-level abgehandelt sein.
-Verhältnis route delay zu logic delay - das zeigt an ob deine Logik zu
komplex oder das routing zu "verknotet" ist. Im Fall zu komplexer Logic
muss der VHDL-code umgeschrieben werden, eventuell kann man bei den
mapping Optionen noch was gewinnen (MUX7 aktiviert?). Ist dagegen das
routing der "Zeitfresser" dann kann mit. Schau mal bei Xilinx unter
"timing closure" bspw.
http://www.xilinx.com/support/documentation/sw_manuals/xilinx13_3/ug612.pdf> Fpga Kuechle schrieb:>> Das nagele ich dann per Area/mapping o.ä. constraint fest und setzte>> wieder zurück auf leicht Optimierung. Wenn jetzt das timing erfüllt ist>> , ist der Job erledigt.>> Hm, einfach die kritischen Pfade per Constrain woanders lang ziehen? Mal> gucken, ich probier das einfach mal.>
Nicht (nur) die Pfade ziehen sondern die Resourcen die mit dem Pfad
verbunden werden per area constraint festgenagelt. Ich hatt da mal den
Fall das ohne Area constraint der BUFGMUX am falschen Ende ausgewählt
wurde.
Festnageln der Pfade (routing) heisst bei xilinx "directed routing" (ISE
Fpgaeditor Menü: tools)
Fpga Kuechle schrieb:> -Anzahl logic level also wie komplex ist die Kombinatorik. Mit den 6 er> LUT> sollte alles was nur 6 Eingänge in einem Logic-level abgehandelt sein.
Klar, da achte ich drauf bzw. das versuche ich gerade noch etwas zu
optimieren.
> -Verhältnis route delay zu logic delay - das zeigt an ob deine Logik zu> komplex oder das routing zu "verknotet" ist.
Naja, scheint definitiv das Routing zu sein. Auf den kritischen Pfaden
sind 80-95% des Delays auf Routing zurückzuführen, laut Timing Report
von Vivado.
> Im Fall zu komplexer Logic> muss der VHDL-code umgeschrieben werden, eventuell kann man bei den> mapping Optionen noch was gewinnen (MUX7 aktiviert?). Ist dagegen das> routing der "Zeitfresser" dann kann mit. Schau mal bei Xilinx unter> "timing closure" bspw.
Was muss man da für MUX7 konkret aktivieren? Sollte die Synthese solche
Primitiven nicht von selbst nutzen, wenn das sinnvoll ist?
greg schrieb:> Sollte die Synthese solche Primitiven nicht von selbst nutzen,> wenn das sinnvoll ist?
X ist da sehr konservativ. Neue oder verbesserte Sachen gibt's meist nur
als Opt-In auf explizite Anweisung. Da hilft dann üblicherweise eine
neue Softwareversion nichts, denn Default ist "wie gestern"...
greg schrieb:> Fpga Kuechle schrieb:>> Im Fall zu komplexer Logic>> muss der VHDL-code umgeschrieben werden, eventuell kann man bei den>> mapping Optionen noch was gewinnen (MUX7 aktiviert?). Ist dagegen das>> routing der "Zeitfresser" dann kann mit. Schau mal bei Xilinx unter>> "timing closure" bspw.>> Was muss man da für MUX7 konkret aktivieren? Sollte die Synthese solche> Primitiven nicht von selbst nutzen, wenn das sinnvoll ist?
Also beim XST ist es mux_style der die MUXF oder MUXCY beim mappen auf
die archtektur mit verwendet. Es könnte aber sein das das beim Virtex 7
nicht mehr so ist.
http://www.xilinx.com/support/documentation/sw_manuals/xilinx13_1/devref.pdf
S. 340
Dann ist mir gerad beim mapper lut combining aufgefallen der default auf
OFF steht: S. 344
Generell sollte man alle default Einstellungen von synthese/map/par mal
durchschauen, ob da nicht was zu aktivieren geht und damit spielen.
Xilinx hat da mal ein tool verteilt das "über nacht" ne menge Optionen
variert und synthetisiert. Da kann es auch widersprüchliche Ergebnisse
geben bspw. das auf area optimiert schneller ist als auf speed optimiert
(xplorer resp smartxplorer
http://www.xilinx.com/support/documentation/sw_manuals/xilinx11/ise_c_using_smart_xplorer.htm
Richtige reihenfolge der IF's bei FF Beschreibung kann auch helfen die
logic level zu verringern:
http://www.xilinx.com/support/documentation/white_papers/wp275.pdf
MfG,
Also so langsam wird es verrückt: ich hab nun das Design meines
NoC-Routers vereinfacht und kritische Pfade optimiert. Wenn ich den
Router alleine synthetisiere, kommt da auch etwas deutlich besseres
raus: geringerer Ressourcenverbrauch in LUTs (ca. 10% weniger) und
Registern (5% weniger), höherer Takt erreichbar, usw.
Im NoC-Verband ist das Resultat bei 125 MHz nun aber deutlich
schlechter, das Placement ist dann total daneben... teilweise gibt's
jetzt plötzlich sogar Timing-Probleme innerhalb der Microblaze-Kerne.
Place and Route scheint mir insgesamt sehr "instabil" zu sein, schon
kleine Änderungen am RTL-Code, die sich eigentlich nicht auf das globale
Timing auswirken sollten, können große Änderungen am Placement, Routing
und damit auch Timing verursachen. Und das ohne besonders ungewöhnliche
Einstellungen für die Implementation. Ist diese Instabilität ein Symptom
für eine bestimmte Art von zu großer Komplexität?
greg schrieb:> Ist diese Instabilität ein Symptom> für eine bestimmte Art von zu großer Komplexität?
Sowas hatten wir immer, wenn das FPGA recht voll wurde...so ab 70%
belegter Slices etwa. Jedenfalls bei ISE und bis zur 6er Serie. Wie voll
ist denn dein FPGA?
Christian R. schrieb:> greg schrieb:>> Ist diese Instabilität ein Symptom>> für eine bestimmte Art von zu großer Komplexität?>> Sowas hatten wir immer, wenn das FPGA recht voll wurde...so ab 70%> belegter Slices etwa. Jedenfalls bei ISE und bis zur 6er Serie. Wie voll> ist denn dein FPGA?
Der FPGA ist überhaupt nicht voll. Rund 20% der LUTs und FFs werden
genutzt.
greg schrieb:> Am Design gibt's tatsächlich noch einiges, was ich in Zukunft> überarbeiten und refactoren werde, aber nicht im Moment
Ich empfehle, vorab eher einige FFs mehr zu platzieren um ein
enstpanntes timing zu haben, im schlimmsten Fall sogar auf Kosten von
wait states bei SOC-Systemen, einfach um schneller entwickeln und
synthetisieren zu können.
Hallo,
meiner Erfahrung nach bringt es wenig die Constraints an den
Fehlerstellen strenger zu machen. Dadurch treten die Fehler an anderen
Stellen auf. Das hast du jetzt auch gelernt. Du musst es PAR erlauben
die zeitkrititschen Teile weiter zusammen zu ziehen. Das wiil es selber,
da es Ziel des Algrithmus ist. Darum ist es besser PAR auf
zeitunkritischen Pfaden mehr Zeit zu geben. Dazu bieten sich die
Leitungen zu den Pins an. PAR lässt standardmäßig für die Laufzeit
zwischen Reg und OBUF eine Taktperiode zu. Jetzt musst du prüfen, an
welchen Stellen das wirklich nicht notwendig ist. Klassiker sind da
LEDs, Debugpins und SPI. Dasselbe gilt für Eingangssignale. Dann gibt es
noch den constraint muticycle, damit sagst du PAR, dass ein Signal vom
Registersausgang zum nächsten Registereingang mehr als einen Takt hat.
Das entspannt auch.
Viel Erfolg
Tom
