|
Anzeige
|
XILINX ISE erzeugt jedesmal ein anderes Bitfiles
Gast
#2445743
Hallo, wenn ich den gleichen VHDL-Sourcecode mehrfach synthetisiere, erzeugt die XILINX ISE jedesmal ein anderes Bitfile. Kann man in den Properties irgendwie festlegen, daß immer ein identisches Bitfile erzeugt wird? Danke, Dosmo Nein, das liegt in der Natur der Sache bzw. an der Arbeitsweise von Map und PAR. Nach der Synthese kommt noch das gleiche raus, aber schon nach dem Mappen hast du jedes Mal ein anderes Ergebnis. Nach dem Place and Route erst recht. Wozu ist das wichtig? Außerdem steht im Bitfiel das Erstelldatum, 1:1 wirds sowieso nie.
Gast
#2445917
Dosmo schrieb: > jedesmal ein anderes Bitfile. Mit welcher ISE-Version arbeitest Du? M.E. kommt bei den aktuellen Versionen (ab 10? ab 11?) bei gleichem Input auch der gleiche Output raus. Duke Duke Scarring schrieb: > bei gleichem Input auch der gleiche Output raus. Naja, abgesehen eben von der eingetragenen Zeit (ISE 13.2)... Hm, kann man paushal nicht sagen. Ich hab auch Designs, die erzeugen jedes mal ein anderes Bit-File trotz gleicher Settings und frischem Auschecken aus dem SVN. Version 13.3
Gast
#2446775
Christian R. schrieb: > Nein, das liegt in der Natur der Sache bzw. an der Arbeitsweise von Map > und PAR. Warum denn? Das kann ich mir gar nicht erklären. Ist da etwa ein Zufallsgenerator drin? ;-) Das mit der Uhrzeit ist ja okay, aber der Rest sollte doch immer gleich sein... Ich meine, mal gelesen zu haben, dass die Optimierung nach Maxima-/Minima Suche funktioniert, und der sich auch mal in einem lokalen Maximum/Minimum verrennen kann. Kann aber leider die Quelle nicht mehr finden. Bei nicht allzu vollen Designs kommt schon allermeistens das gleiche raus, aber ich hab hier Spartan 6 Designs mit über 70% Füllgrad, da krieg ich selten eine 1:1 Kopie (Datum/Uhzeit außer Acht gelassen). Was ist, wenn man den par-seed per -t immer auf denselben Wert setzt? Dann sollte eigentlich immer dasselbe rauskommen.
Gast
#2451378
Danke für die Antworten. Ich hab ISE 13.2.
Gast
#2456782
Wenn man nen Autorouter für ne Komplexe Leiterkarte benutzt kommt (warscheinlich) auch nicht jedesmal das gleiche raus. Kann ja mal jemand testen, dann sieht man auch warum.
Gast
#2456789
Bei mir kommt auch jedes mal was anderes raus. Das liegt aber daran, das ich einen 'date'-String mit einsynthetisiere, den ich von extern auslesen kann. Duke
Gast
#2456888
Also mal langsam: Die Xilinx-Synthese inkl. der Folgeschritte ist dem Prinzip nach voll deterministisch. Es ist nur so, dass Ergebnisse vorheriger Läufe mitberücksichtigt werden können. Das hängt von den Einstellungen und der Strategie ab. Was auch zum Tragen kommt ist das Resynthestisuieren der Cores, das er sporadisch vorzunehmen scheint. Dabei scheint relevant zu sein, ob man den CoreGen von sich aus öffnet und über die Coreverwaltung etwas ändert oder einfach einen vorhandenen core anklickt. Grund: Manchmal bekommen die einzelnen Xilinx Tools ganz offensichtlich nicht mit, wenn sich was geändert hat oder sie kriegen es zu spät mit. Ich habe z.B. öfters den Fall, dass ein Lauf wegen einem Signal im ChipsScope meckert, weil ich was umverdrahtet habe und er es einfach nicht bauen will. Schliesst man das Projekt und öffnet es neu, klappt es dann plötzlich. Er scheint an einem internen flag zu hängen. Bei der Nutzung vom System Generator habe ich ähnliche Effekte gehabt. Startet man eine Synthese direkt im Anschluss an einen Neubau oder eine Änderung kommt was anderes heraus. Oft genug ging es garnicht. Solche internen Probleme sind es sicherlich, die u.a. dafür sorgen, dass Ergebnisse variieren, neben geänderten Syntheseeinstellungen natürlich. Es könnte natürlich sein, dass der HDL-Advisor irgendwas ändert oder man solche Spielchen wie "write timing constraints" aktiv. Wenn das Tool "eingeschwungen" ist, sind die files identisch. noname schrieb: > Wenn das Tool "eingeschwungen" ist, sind die files identisch. Beobachten das noch andere? Ich habe derzeit dass Problem, dass mir ISE immer mal wieder ein "schlechtes" Bitfile macht. Ich erkenne es, an Timing problemen bei der Ausgabe. Scheint eine Art von Tagesform zu sein und mit der aktuellen Version zusammenzuhängen. Blindgänger hatte ich viele bei einem DDR-Interface. War aber weg, nachdem ich die "Löcher" in meinen Timingsspecs gefunden hatte. Seitdem ist jeder Schuss ein Treffer. Nicht immer sind die Tools schuld ;)
Gast
#2786958
Georg A. schrieb: > War aber weg, > nachdem ich die "Löcher" in meinen Timingsspecs gefunden hatte. Kann ich bestätigen. Ich hatte auch anfangs vergessen, bestimmte Timings (Setup- und Hold-Zeiten eines externen Bausteins) zu definieren und dann kamen so 50% "geht" und 50% "geht nicht" bei heraus. Seit die Timings korrekt angegeben sind, kommt 100% "geht" bei heraus. Dosmo schrieb: > Hallo, > > wenn ich den gleichen VHDL-Sourcecode mehrfach synthetisiere, erzeugt > die XILINX ISE jedesmal ein anderes Bitfile. > Kann man in den Properties irgendwie festlegen, daß immer ein > identisches Bitfile erzeugt wird? > > Danke, > > Dosmo Das bitfile selbst ist deshalb unterschiedlich, weil ein Zeitstempel darin vorkommt. Das Ergebnis selbst ist, zumindest in meinen Fällen, schon identisch. http://www.fpga-faq.com/FAQ_Pages/0026_Tell_me_about_bit_files.htm
Gast
#2788520
Klaus Falser schrieb: > Das bitfile selbst ist deshalb unterschiedlich, weil ein Zeitstempel > darin vorkommt. > Das Ergebnis selbst ist, zumindest in meinen Fällen, schon identisch. Wer Muße hat, kann auch mal das angehängte TCL-Skript ausprobieren. Duke Man kann sich bei bitgen auch ein bin File generieren lassen, das kann man dann ganz leicht vergleichen.
Gast
#2788712
Klaus Falser schrieb: > Das bitfile selbst ist deshalb unterschiedlich, weil ein Zeitstempel > darin vorkommt. Ich wage mal zu behaupten, daß jeder, der WinMerge bedienen kann, über diesen Punkt hinaus ist... ;)
Gast
#2788999
Die Rede ist hier nicht vom Zeitstempel oder dem USEr code, sondern Fehlfunktionen und verschiedenen Grössen! Ich habe es öfters, dass die Syntheseergebnisse unterschiedlich sind. Entweder verrennt er sich irgendwo, oder er hat wieder intuitiv was umgestellt. Ich habe es schon geschafft, nach 2maligem restart der Implementierung ohne sonstige Änderungen abweichende Ergebnisse im Timing und der Resources zu bekommen. Ich habe den HDL-Advisor und den SmartGuide im Verdacht! Die nutzen gfs vorherige Ergebnisse und starten daher jedesmal mit unterschiedlichen Randbedingungen.
Gast
#2789036
noname schrieb: > Ich habe den HDL-Advisor und den SmartGuide im Verdacht! > > Die nutzen gfs vorherige Ergebnisse und starten daher jedesmal mit > unterschiedlichen Randbedingungen. Den HDL-Advisor kenn ich nicht. Bei SmartGuide steht in der Dokumentation, das bisherige Syntheseergebnisse genutzt werden, um die nächste Synthese zu 'verbessern'. Da braucht man sich natürlich nicht über verschiedene Bitfiles zu wundern... Duke noname schrieb: > Ich habe es öfters, dass die Syntheseergebnisse unterschiedlich sind. > Entweder verrennt er sich irgendwo, oder er hat wieder intuitiv was > umgestellt. Das kommt vor, wenn man kein clean vorher macht und dicht an der Kotzgrenze bei Timing und/oder Füllgrad ist. Bei locker gefülltem FPGA und noch Luft beim Timing erzeugt der schon (eigentlich) immer das gleiche. (Klassisches) Place and Route nutzt den "Simulated Annealing" Algorithmus. Dieser basiert auf einen zufällig gewählten Startwert (hier cost table). Dem Par-tool kann dieser Startwert vorgegeben werden. Das sollte die Ursache für geänderten bitfile bei gleichen sourcen sein. Hält man diesen startwert gleich, sollte auch das desing gleich bleiben. Siehe: http://www.xilinx.com/support/documentation/sw_manuals/xilinx11/pp_db_place_and_route_properties.htm und: http://www.xilinx.com/products/design-tools/vivado/implementation/place-and-route/index.htm MfG, > Dem Par-tool kann dieser Startwert vorgegeben werden. Mit -t. > Das sollte die Ursache für geänderten bitfile bei gleichen sourcen sein. Aber von selbst passiert das auch nicht... Georg A. schrieb: >> Dem Par-tool kann dieser Startwert vorgegeben werden. > > Mit -t. > >> Das sollte die Ursache für geänderten bitfile bei gleichen sourcen sein. > > Aber von selbst passiert das auch nicht... Lt Doku wird dieser Startwert bei einem Durchgang automatisch um eins erhöht (also von selbst): "... subsequent attempt is assigned an incremental value based on the placement initialization value ..." Man könnte es so lesen das wenn das timing nicht erreicht wird im nächsten Versuch mit anderen Startwerten geroutet wird. Das könnte dann bedeuten das bei Designs mit passenden timing alles gleich bleibt. MfG,
Gast
#2791714
Welcome to the real world :-) Den beschriebenen Effekt hatte ich auch beim Compilieren/Linken : Die Dateien werden einfach der Reihenfolge der Einträge (also NICHT in der Reihenfolge in der man sie im Explorer angezeigt bekommt!) in die LIB aufgenommen. Das entstehende Programm ist funktional völlig identisch, aber binär verschieden. Ein SW-Update des Compiler-Herstellers hat das Problem dann behoben. Auch nett: ASCET 4.0 war damals in Smalltalk implementiert. Die Garbage-Collection hat dann gelegentlich aufgeräumt und dabei die Reihenfolge der Objekte im Speicher umsortiert. Diese aber hat auch den generierten Code beinflusst: Mal war der Code beim zweiten Makelauf identisch, mal nicht. Ich wünsche dir viel Glück bei der Suche nach einer Lösung, kann manchmal lang dauern bis es klappt
Gast
#2792957
DIe Lösung liegt auf der Hand: KEIN XILINX KEIN WINDOWS KEIN MICROSOFT je mehr man von diesen Grundregeln auser 8 lässt, desto mehr ärger hat mann Frank Fridolin Tinitus schrieb: > laberlaberlabersülzlaber... Das bringt dem Thread keinerlei Informationsgewinn. Du hättest wenigstens noch schreiben können, wie man diese potenziellen Problemquellen deiner Meinung nach umgehen könnte...
Gast
#2820210
Ich habe etwas Seltsames: eines meiner Designs wurde in den vergangenen Tagen jedesmal in den constraints getroffen und ich habe heute nur noch einige Parameter geändert. Wieder wird das Design getroffen. Der letzte Schritt war die Anpassung der internen firmware Nummer, die in einem Register steht. Nun klemmt es. Einziger Schritt: "clear all project settings". Die Syntheserandbedingungen "speed, retiming" und die hundert anderen blieben unverändert. Ich habe die auch überprüft! WIE GIBT ES DAS? Ich kann mir das nur so erklären, dass er sporadisch anders arbeitet, oder aber, was auch sein kann, die positiven Meldungen zuvor waren falsch und basierten auf einem alten report oder alten Annahmen. Allerdings wurden die reports jedesmal sichbar gelöscht und neu erstellt, als ich die Implementierung startete. So langsam werde ich noch blöde mit dem Xilinx-mist! Wenn die Firmware Nummer nicht im BRAM steht sondern hart codiert ist, ist es ja durchaus normal, das etwas völlig anderes rauskommt. Schließlich ändert das ja die Verdrahtung. Allerdings ist dann offenbar dein Design extrem voll oder extrem nah am kritischen Timing, mit so einem Design weiter zu arbeiten bringt nur Stress. Das musst du dann irgendwo entspannen. Sonst kriegst du ja graue Haare.
Gast
#2823897
Nein, das kann es nicht sein. Die Nummer wird lediglich als Wert in einem statischen Vektor ausgewertet, der keinen Einfluss auf das Timing haben kann und das design ist auch keineswegs voll. Ich habe weniger, als 20% derzeit und die Timings werden mit ausreichendem slack erzielt - WENN sie denn getroffen werden. Dies ist aus unerfindlichen Gründen jedoch manchmal nicht der Fall. Es tritt allerdings sporadisch auf und hat mit dem o.g. direkt nichts zu tun - auch andere Änderungen führen dazu, dass das Timing nicht mehr passt. Bei weiteren Änderungen, = Hinzuaddieren von Funktionen, geht es dann urplötzlich wieder, bzw. wenn man das Projekt cleared. Irgendwie scheint er sich mit alten Zwischenergebnissen zu verrennen! Manchmal mapped er auch ellenlang umeinander, bis was rauskommt. Smartguide ist schonmal nicht der Grund, falls das jemand vermutet. Da leuchtet es mir ein, dass er da irgendwann gegen die Wand laufen kann, aber das ist jeweils "off". Achso, na ich lass fast alles über die Command Line bauen, nur zum Aufsetzen des Projektes oder hinzufügen/ändern von Cores benutze ich die IDE noch. Vor dem Build lösche ich dann alle erzeugten Files und hab somit immer einen frischen Durchlauf. Dann bekommt man auch reproduzierbare Ergebnisse. Ich glaube in der ISE reicht es, wenn man die *_guide.ncd löscht, dann fängt der Map/PAR von vorne an.
Gast
#2824090
Die guide sollte er doch eigentlich nur benutzen, wenn besagter SmartGuide aktiviert ist. (?) Gute Frage. die _guide löschen hilft aber schon mindestens seit Version 9.x wenn der sich mal verrannt hat. Antwort schreibenBitte melde dich an, um einen Beitrag zu schreiben. |
Anzeige
|
