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?
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
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.
>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.
