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.
:
Bearbeitet durch Moderator
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...
:
Bearbeitet durch Moderator
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
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.