Fpga I. schrieb:
erst einmal innerhalb von einer Vivado Version auf verschiedenen
Plattformen das selbe Bitstream File erzeugen können.
Wenn alles gleich und konstant ist und man wirklich von Null startet, passiert das in aller Regel auch. Es ist allerdings auch dann nicht 100% gesichert. Besonders bei der Implementierung kann es zu Unterschieden kommen, wie sowohl von Xilinx selber, als auch durch Distri-FAEs bestätigt wurde. Das Problem kam bei einem Kunden hoch, der diesen Reproduktionsanspruch hatte und wo diesbezüglich intensiv nachgefragt und geforscht wurde. Auch durch Tests lässt und liess sich das bestätigen. Spätestens bei einem anderen Rechner kann das auftreten. Die Gründe liegen unter anderem in der unterschiedlichen Fertigstellung von Cores, deren DCPs sowie dem Multithreading.
Die Hauptursache an sich ist der Versuch von Vivado, Rechen- und Implementierungszeit zu sparen. Daher können bei jedem einzelnen Rückgriff auf vorgefertige Zwischenlösungen neue Randbedingungen ins Design kommen, welche das Routing-Ergebnis beeinflussen, selbst dann, wenn dieselben Strategien appliziert werden. Im Prinzip ist es Dasselbe, wie bei einem PCB-Layout, wenn man an anderer Stelle anfängt, oder einen vorgefertigten Block einsetzt. Die geroutete Schaltung kann praktisch Dasselbe zieht aber geometrisch etwas anders aus. Wenn dann unterschiedliche Blocks = Core-Ergebnisse infolge unterschiedlicher Prozessor-Last oder Multithreading zu anderen Zeiten fertig werden, hat man den ersten denkbaren Einfluss der Rechenpower.
Hinzu kommt noch, daß Vivado inzwischen machine learning einsetzt. Wo und wie das wirkt, wird sowohl von Xilinx selber, als auch den FAEs nur oberflächlich kommuniziert. Man kann davon ausgehen, dass sich das tool irgendwo irgendwelche Dinge merkt, oder zumindest probiert, es sich zu merken. Sofern das alles im Projektverzeichnis bleibt, müsste sich dieser Aspekt durch vollständiges Löschen eliminieren lassen. Bei besagten Test wurde das Projekt komplett gelöscht und jeweils per Script neu aufgesetzt. Dennoch gab es Unterschiede, zumindest bei unterschiedlichen Rechnern - obwohl die ML-Versionen gerade erst frisch rausgekommen.
Der Punkt ist daher aus meiner Sicht offen. Es bleibt in jedem Fall der Aspekt der Ausführungzeit und eine mögliche Rücksichtnahme der Software auf die jeweils verstrichene Zeit bei der Implementierung:
Soweit ich das überschaue, hat die Prozessorlast auf schon einer CPU (unter Ausschluss des Multithreadings) zumindest dann noch einen möglichen Einfluss, wenn bei der Implementierung durch die Optimierungsansätze jeweils an unterschiedlichen Stellen probiert wird, ausreichend timing budget zu schaffen. Das ist bei praktisch allen solchen Optimierungen der Fall, sei es bei Schaltungssimulation, FEM oder geometrischen Optimierungen durch Annealing-Verfahren:
Man geht von Block zu Block und optimiert die Struktur Stück für Stück und schafft etwas budget, bevor man zum nächsten hüpft. Das ist effektiver, als immer nur ein Element zu rücken und dann wieder global in das System zu schauen. Dabei gibt es ein Hauptkriterium: Die zuletzt gewonnene Güte im Bezug auf die dafür benötigte Zeit. Da solche Optimierungen in eine Sättigung laufen, springt man logischerweise bei einem beginnenden Abflachen lieber in die nächste Zelle, statt sich weiter in der ersten abzurackern.
Um die Strategien, wie man abschätzen kann, ab wann man springt, neu sucht, die zu optimierende Zelle schätzt und wie lang man wo investiert, ranken sich Doktorarbeiten.
An der Stelle wird die Prozessorlast definitiv zu anderen Zeitpunkten führen, an denen ausgesprungen wird. Sobald nämlich die Software mit einer lokalen Optimierung zufrieden ist, z.B. man rutscht eine Kombinatorik ein FF nach vorn oder hinten und schätzt das budgt, könnte sie weiterlaufen oder eben auch nicht. Wenn da die Synthesezeit eine Rolle spielt (und das tut sie!) dann könnte im Einzelfall ein Hüpfen bei einem etwas schlechten Zwischenschritt erfolgen.
Was man in solchen Systemen auch tut, ist ein lokaler Mehrafachansatz: D.h. man wirft eine Aufgabe 2 oder mehrmals mit leicht veränderten Kriterien in eine pipeline und misst die Ergebnisse, wobei man sich das Beste schnappt und per Funktion wieder hochreicht. Solche Dinge laufen als Iteration oder auch Rekursion. Spätestens hierbei spielen Vorgaben von Ausführungszeiten eine Rolle, wenn z.B. nicht 4 sondern nur 3 Ansätze verfolgt werden.
Inwieweit Xilinx sowas nutzt oder Ähnliches wirkt, kann ich nicht sagen. Ich habe aber solche Systeme schon entworfen. Ein wesentlicher Ansatz dabei sind oftmals zufällig gewählte Startwerte für Gewichtungen, mit denen die "Wichtigkeit" eines Aspekts in die Entscheidung einfließt. So wie bei neuronalen Netzen braucht es immer eine Art Gütefunktion, die eine endliche Zahl von Parametern hat und die mit minimal unterschiedlichen Werten belegt werden, um zu varieren.
Auch diese Startwerte - sogeannte seed values - können eine Rolle spielen, wenn sie z.B. aus Zufallsgeneratoren gewonnen werden, die irgendwie von der Rechnerzeit- oder dem aktuellen Rechnerzustand abhängen. Gerade in früheren Zeiten war das sehr modern, das zu nutzen. Heute geht man eher zu deterministischen Werten über die reproduzierbare Scheinzufallswerte liefern, die gezielte Wertebereiche abdecken, d.h. die Variationsansätze sind willkürlicher.
In jedem Fall begründet das schon einmal, warum unterschiedliche Versionen zu anderen Ergebnissen führen, weil sich nämlich die Strategien bei Synthese und Implementierung mit jeder Vivado-Version ändern dürften, d.h es gibt andere Voreinstellungen für die Gewichtungen.
Ungeachtet der Gründe halte ich die gesamte Frage für untergordnet.
Es gibt aus meiner Sicht keinen Vorteil, wenn man ein Design nochmals identisch implementieren kann, weil das praktisch nicht nötigt ist, es sei denn man verschlampt das BIT-File und muss weitere boards programmieren.
Ansonsten sind neue Bitfiles immer das Ergebnis des Hinzügens einer Funktion und da bei sicherheitskritischen Anwendungen jedes Exemplar eines PCBs getestet werden muss und die dafür nötigen Funktionen enthalten sein müssen, ist es Wurscht. Man darf nicht vergessen, dass jeder Synthesereport nur ein virtuelles Ergebnis liefert, was das budget angeht und jeder einzelne FPGA und jedes PCB anders reagiert und eben Fehler enthalten kann.
D.h. da liegt der Hund begraben.
xilinx_synthesis_test.jpg
(69 KB)
