Wie bringt man der ISE bei, reproduzierbar zu synthetisieren? Ich habe ein design auf dem Spartan 6, das die ISE so ziemlich an den Anschlag zu bringen scheint. Es ist zugegeben taktmäßig kompliziert mit mehreren Domains, Fifos und Taktübergängen aber eigentlich zielführend aufgebaut. Ich beobachte mehr und mehr, dass die ISE sich einen abwürgt, es zu erzeugen, wobei er das Timing mal trifft und mal nicht. Momentan habe ich den Effekt, dass die erste Synthese mit frischem Projekt klappt, die Wiederholung nicht. Es ist kein inkrementales Compilieren eingestellt, trotzdem scheint er auf irgendwas zuzugreifen. Was auch seltsam ist: Manchmal ist es nötig, die Platzierung von CLockBuffern zu contrainen, manchmal nicht. Teilweise ist es auch kontraproduktiv. Selbst, wenn ich ihm das vorgebe, was er zuvor selber herausgefunden hat, geht es schief und es kommt die bekannte "dedicated route"- Meldung. Ähnliches beobachte ich bei keep constraints auf Signalen, die nach der Optimierung nachweislich noch so existieren, also nicht verschwunden sind. Das Design kann mit keeps nicht gebaut werden.
Platzierst du neben Spezialelementen (Buffer, BRAMs, etc) auch noch was anderes? Ich habe bei meinen Designs festgestellt, dass es in den meisten Fällen hilft, grosse Module (Toplevel, etc.) zumindest grob zu platzieren. Durchaus mit Überlappung und 30-40% mehr Raum als eigentlich nötig. Mit den Vorgaben war das Ergebnis deutlich reproduzierbarer. Ein paar "Blindgänger" gabs zwar immer noch, aber weniger als ohne das. Exakte Platzierung dagegen hat das wieder schlechter gemacht.
Nein, nur die buffer habe ich festgelegt, weil ich gemerkt habe, dass das was bringt. PLLs sind lose aber alle in gezielten Banken verwendet. Es sind 3 Ecken von denen ich reinkomme und 3 Daten/Takt-Regionen. Der FPGA ist ansonsten zu 20% gefüllt. RAMs und MULs zur Hälfte. Mich wundert am Meisten, daß er mal timed und mal nicht und das beim selben Design ohne vorherige Änderungen. Nur Projekt neu angelegt. Beim Vivado habe ich gesehen, dass er im persönlichen Verzeichnis aus C eine Reihe temporärer Dateien anlegt, und zwar für reports und check points. Wenn man die löscht, geht es auch immer mal besser. Gibt es so einen Bereich auch bei ISE?
Ja, auch ISE legt Zeug an, was es beim nächsten Durchlauf nutzt. "Cleanup Project files" hilft bei ISE schon mindestens seit Version 6 wahre Wunder.
Du kannst in ISE den smartxplorer nutzen. Dort kann man einen seed vorgeben, so dass die Ergebnisse reproduzierbar werden.
> Der FPGA ist ansonsten zu 20% gefüllt.
Dann hat ISE viel zuviel Platz, um Unsinn anzustellen ;) Gib mal ein
paar Bereiche vor...
Mich würde interessieren, warum die Ergebnisse nicht reproduzierbar sind und woher das kommt. "Cleanup" mache ich ja. Ist trotzdem noch abweichend. Was könnte man noch wo weglöschen, um Xilinx in einen Urzustand zu versetzen?
Wird irgendwo ein Timestamp mit einsynthetisiert? Sonst sollte bei identischen Einstellungen und identischen Quelldateien auch das Bitfile identisch sein (abgesehen vom Erstellzeitpunkt). Duke
Gib mal die placer cost table vor: http://www.xilinx.com/support/documentation/sw_manuals/xilinx13_4/devref.pdf S. 95 par -t
>"Cleanup" mache ich ja
Es kann hilfreich sein, dass komplette Syntheseverzeichnis zu löschen
und nur die Projektdatei zu behalten.
Ich mach da immer ein svn cleanup, falls mal was hängt, aber ISE ist schon ne Weile her. Mit Vivado hat man andere Probleme. Ich glaube trotz Clean Project Files bleibt eine Datei vom PAR noch immer drin, die muss man händisch löschen.
Jürgen S. schrieb: > Es kann hilfreich sein, dass komplette Syntheseverzeichnis zu löschen > und nur die Projektdatei zu behalten. Beim Anlegen von Projekten kann man ein abweichendes Build-Verzeichnis angeben. Dieses kann man dann komplett löschen. Einzig Smartexplorer hat einen kleinen Bug: Der Smartexplorer erwartet eine Konfigurationsdatei im Build-Verzeichnis, die IDE legt sie aber ins Projektverzeichnis (fällt normalerweise nicht auf, da defaultmäßig Projektverzeichnis = build-Verzeichnis: welch ein Unsinn). Ein komplettes Design festlegen ist, wie bereits beobachtet, wirkungslos. Bei mir hat oft geholfen:
1 | - Clockbuffer und PLL/DCM/... festsetzen |
2 | - Clockregions nutzen für die jeweiligen Taktnetzte (dürfen sich durchaus überlappen) |
3 | - Module diesen Clockregions zuweisen |
Ansonsten hilft auf Dauer nur Timing-Report analysieren: was knallt, wo knallt es, warum. Wie ist das Verhältnis zwischen Logikdelay (komplexe Logik) und Netdelay(lange oder indirekte Wege). Dann im Design ändern (Source oder Constraint). Oft sehe ich:
1 | - Taktübergänge abgeleiteter Takte sind unnötig scharf, geht hier evtl. MAXDELAY, TIG, ... |
2 | - Einstellungsregister haben PERIOD-Constraint, können oft aber TIG sein |
3 | - gibt es Multi-Cycle, die ISE nicht kennt? |
4 | - Können Pipelineregister hinzugefügt werden? Achtung wenn ein CE benötigt wird, könnte das ein Snake-Path sein/werden, der schlimmer wird. |
5 | - Verwenden etliche Module ein (1) Reset? Dieser zieht meist das Design zusammen, daher lokal in den Modulen duplizieren und die Kopie verwenden. (Thema Fanout) |
6 | - Sind Module via Streaming verbunden? Evtl. ein Fifo als Entkopplung dazwischen setzen. |
grüße
>Können Pipelineregister hinzugefügt werden? Achtung wenn ein CE benötigt >wird, könnte das ein Snake-Path sein/werden, der schlimmer wird. Das verstehe ich nicht. Könntest Du das bitte verdeutlichen? >Clock Regions Habe Ich noch nie verwendet. Muss ich mich mla schlau machen.
Markus W. schrieb: > Snake-Path Die Datenpfade zu pipelinen ist oft kein Problem. Jedoch müssen diese oft zu anderen Signale synchron sein bzw. müssen auch mal warten. Diese dafür notwendigen Seuersignale (meist ce, readenable, ready/valid, auch reset) sind oft nicht so einfach zu pipelinen und ziehen sich (meist sogar mit Kombinatorik) durch mehrere Module (Schlangenpfad-mäßig). Diese einzelnen Signale mit einem meist scharfen PERIOD-Constraint ziehen dann die Module zusammen. Irgendwann können die Module nicht mehr weiter zusammenrücken und es kommt zu timing Problemen.
Was hier als 'Snake Path' bezeichnet wird, ist einfach ein langer kombinatorischer Pfad, der die Kontrolllogik betrifft. Ich denke, dass Markus W. schlichtweg mangels tiefgehendem Einblick (sorry ich will nichts unterstellen) das Design überconstraint hat. Zumindest "kompliziert mit mehreren Domains, Fifos und Taktübergängen" deutet darauf hin. Denn FIFOs zwischen 2 asynchronen Takten sind in der Regel nie ein Problem, es sei denn man vergisst die Ausnahmen zwischen den Taktdomänen. Beispiel in SDC: 'create_clock clk1 -period 6.0' und 'create_clock clk2 -period 7.0' Auf dem Clock-Domain Crossing errechnet das Tool dann eine nötige Setupzeit von 1 ns, die man tatsächlich gar nicht braucht. Die Liste von daniel__m ist schon mal ein guter Ansatzpunkt. Ich würde auch sagen: Mal testweise false_paths zwischen allen Clocks setzen und nochmals testen.
Ja, das ist seltsam beim Xilinx. Ich habe auch gerade wieder so ein Ding: Einmal zu früh den timing report aufgemacht und er hängt sich auf. Danach kann man löschen, wo und was man will, er kann den Report nicht mehr parsen. Ich habe den kompletten Syntheseordner neu angelegt und trotzdem kann er immer wieder das file nicht mehr öffnen, auch wenn er es neu erzegut hat. Ich habe das jeweils neue mit alten verglichen, ob es kaputt sein könnte. Nichts. Kein Grund auszumachen. Projekt musste neu angelegt werden! Habe daher immer eins im Archiv, das ich in einem neuen Ordner ausrollen kann. Wo der Restmüll von Xilinx liegt, habe ich auch noch nicht rausgefunden. Auch das Löschen von tempfile und dem persönlichen APl Ordner hilft nicht.
Sym schrieb: > Was hier als 'Snake Path' bezeichnet wird, ist einfach ein langer > kombinatorischer Pfad, der die Kontrolllogik betrifft. ok danke, aber sowas habe ich nicht. Es gibt auch scheinens kein Problem bei den "intra clock paths" wie es bei Vivado heissen würde. > Ich denke, dass Markus W. schlichtweg mangels tiefgehendem Einblick > (sorry ich will nichts unterstellen) das Design überconstraint hat. Die Constraits kommen eigentlich von Xilinx und den grundsätzlichen Period-Timings. Ich denke, dass ich eher entspannen muss. Grundsätzlich ist mir klar, was ich tun muss: >FiFos nie ein Problem Da kommen ignores von den FiFos selber, wie ich im Wizzard erkenne. Das müsste passen. >es sei denn man vergisst die Ausnahmen zwischen den Taktdomänen. Ich habe versucht die Domänen zu entspannen, aber viele Befehle versagen und werden ignoriert. Wie müsste ich das anstellen? Welche Namen sind relevant? Laut Xilinx guides sind es immer die PINs, wobei er selber alles daraus abteitet. Angeblich. > Beispiel in SDC: 'create_clock clk1 -period 6.0' und 'create_clock clk2 > -period 7.0' > Auf dem Clock-Domain Crossing errechnet das Tool dann eine nötige > Setupzeit von 1 ns Das sieht nach Vivado aus . Dort klappt ja der Wizzard sehr gut und schlägt entspannenden Constraints vor. Wie sieht es bei ISE aus? Wie entspanne ich den generierten Takt nach einen BUFG / BUFGMUX? Als Beispiel dieses Design mit 3 Takten, bei dem der Ausgangstakt umgeschaltet wurde. Beitrag "Schaltungsbau und Constraining bei Taktwechsel"
Markus W. schrieb: >>FiFos nie ein Problem > Da kommen ignores von den FiFos selber, wie ich im Wizzard erkenne. Das > müsste passen. Ich korrigiere: Es sind jetzt doch auch die Fifos. Er meldet irgendwelche Fitprobleme in den Tiefen des FIFOs an kryptischen Signalen, dabei kann da eigentlich nichts passieren. Ich gehe mit einem Takt rein und hole mit dem anderen ab. Weil nur maximal jeden vierten Takt was geschrieben wird, hat der Leseprozess immer genug Zeit und läuft nie über. wie teile ich dem ISE mit, dass es die Takte ignorieren soll? Die Schwierig besteht darin, dass der abholende Prozess mit dem geschalteten Takt läuft den er nicht genau kennt und im Wizzard auch nicht anbietet.
Schau mal im pg057 (Xilinx FIFO Generator Product Guide) und suche dort nach der Überschrift Setup and Hold Time Violations. Im pg057 der Version 9.2 stehen noch die constraints für ISE drin, in der Version 12 nicht mehr.
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.