Ich möchte mehrere unterschiedliche Versionen von BIT files für FPGAs erstellen, die einer konkreten Hardware zugeordnet werden sollen. Die jüngst entwickelten Versionen der FPGA-firmware sind in der Lage, die HW zu erkennen und sich anzupassen, weshalb zum update nicht mehr jeweils neu compiliert werden müsste. Es reicht, die neue SW draufzuladen. Das dumme ist aber, dass die Kundenhardware so gestrickt ist, dass sie nur eine bestimmte FPGA-Version annimmt, um ein falsches Laden zu verhindern. Leider kann man die Software, die das prüft und das FPGA belädt nicht so einfach ändern, weil die in einem anderen geschützten Systemteil sitzt und auch wiederum in jedem System anders gelöst ist. Das bedeutet, ich muss ein und dasselbe FPGA-Projekt für alle HW-Typen neu übersetzen lassen, wenn ich etwas ändere und unterschiedliche Bitfiles ausliefern. Ich würde das gerne umgehen und nur 1 Bitfile nach einer Änderung machen und dann daraus alle benötigten Versionen durch umbenennen der Einträge manuell erzeugen. Ich habe daher probiert, diese einfach im BIT mit einem HEX Editor anzupassen und neu gespeichert. Relevant sind dabei der Projektname, der USER CODE und die Vivadonummer: Vorher: ðððð a (fmc80test;UserID=AVCD0006;Version=2018.3 b Nachher: ðððð a (fmc60test;UserID=AVCD0002;Version=2018.1 b Ergebnis: Einige so umbenannte files funktionieren und andere nicht. Frage: Gibt es in dem BIT file noch eine Art Checksumme über alle Bytes, die verhindert, dass der FPGA das file lädt und ausführt? Was könnte sonst der Grund sein, dass es nicht geht? Die Zeichenmenge beachte ich strikt, d.h. das file wird nicht kürzer.
Ja, diese Prüfsumme gibt es. In einer Bitstream-Datei sind außer der nackten Konfiguration der Logikzellen auch noch Kommandos für die Lademaschine enthalten, die z. B. auch die Auswahl verschiedener Konfigurationen erlaubt. Damit ließe sich sogar die Auswahl anhand der FPGA-Typen realisieren.
Das wird nicht klappen, wenn du im Design selber die Werte hast. Einzig über die UserAccess ginge das halbwegs einfach. Aber bei der Synthese und spätestens wird bei jedem Mal was sehr verschiedenes erzeugt, das ist ja eine Anzahl von Schaltstellen die sagen welche "Leitungen" intern wie verbunden sind. Wenn du jetzt ein fest verdrahtetes a auf b änderst, ist keinesfalls sicher dass die restlichen Bits noch auf der selben Leitungskreuzung liegen. Das ist sogar extrem unwahrscheinlich.
Christian R. schrieb: > Aber bei der Synthese > und spätestens wird bei jedem Mal was sehr verschiedenes erzeugt, Das ist nicht die Absicht. Das Bit-File bleibt ansonsten dasselbe. Es geht nur um die Textänderungen. Dass das BIT funktionionell zu mehreren HW passt, ist durch das VHDL sichergestellt, das HW erkennen und sich passend verhalten kann. Z.B. kann es erkennen, welcher Prozessor drauf ist und sein IF einstellen. Das war vorher nicht der Fall. Ich würde bei einer Synthese auch nur den USER Code ändern und es gfs mit einer alten Version übersetzen, damit der Vivadoeintrag ein 2018 hat (wird bei einigen SW dummerweise mitgecheckt).
Dann ist doch wie oben von Christian beschrieben das User Access Field genau das richtige? https://www.xilinx.com/support/documentation/application_notes/xapp1232-bitstream-id-with-usr_access.pdf
Tobias B. schrieb: > Dann ist doch wie oben von Christian beschrieben das User Access > Field genau das richtige? Aus zwei Gründen leider nicht: 1) Die FPGA-firmware im Feld macht von diesem Zugriff nicht / nicht alleine Gebraucht und kann nicht modifiziert werden, weil dort auch die Microcontroller-Firmware mitmischt. 2) Es wird noch mehr geprüft, ausser nur dem USER Code. Ich muss aus Sicht der unterschiedlichen HW- und SW-Versionen im Feld unterschiedliche Files liefern. Die Frage ist nur, ob man dazu Synthesen machen muss, nur um ein BIT zu haben, das exakt das gleiche tut, aber in den Einträgen ein altes Vivado und ein anderes Datum hat, oder ob man das faken kann, bzw wenn man es faked, warum es in einigen Fällen nicht geht. Dies alles ist wie gesagt, ein Behelf, um den normalen Weg abzukürzen, nämlich mit einer neuen FPGA-firmeware auch einen neuen loader und Ansteuersoftware in C für die Controller und anderen Komponenten mitzuliefern. Das ist leider ein Rattenschwanz. Ein Beispiel: In einem Medizingerät werden mehrere FPGAs an unterschiedlichen Stellen von ARM-Prozessoren geladen, die den Code aus einem Flash holen. Andere spielen nur einmal was ins Flash und der FPGA holt es sich selber. Ändert man nur das FPGA manuell, also den Flaschbausteininhalt, ist man fertig. Nach der kompletten Version müsste diese Microcontroller-Software auch aktualisiert werden und das Laden von allen FPGAs getestet werden. Da es eine neue UC-SW ist muss sie auch neu bewertet und qualifiziert werden, was dauert. Obendrein kann man die uc-SW nicht einfach im Flash austauschen, sondern muss sie ausrollen, d.h. eine PC-Software liefern, die auf den Anlagen-PCs installiert wird, und das gesamte System updatet. Auch diese SW muss qualifiziert und bewertet und getestet werden. Es entsteht ein gewaltiger Aufwand.
M. W. schrieb: > Ich muss aus Sicht der unterschiedlichen HW- und SW-Versionen im Feld > unterschiedliche Files liefern. Die Frage ist nur, ob man dazu Synthesen > machen muss, nur um ein BIT zu haben, das exakt das gleiche tut, aber in > den Einträgen ein altes Vivado und ein anderes Datum hat, oder ob man > das faken kann, bzw wenn man es faked, warum es in einigen Fällen nicht > geht. Leider hat es bei mir noch nicht wirklich Klick gemacht. Kannst du vielleicht mal versuchen zu erlaeutern, woran die UserAccess Methode scheitern wuerde? In diesem Bereich kannst du wirklich reinschreiben was du willst und musst nur den Generate Bitstream Prozess neustarten (es ist kein neuer Synthese und P&R Lauf noetig).
M. W. schrieb: > Frage: Gibt es in dem BIT file noch eine Art Checksumme über alle Bytes, > die verhindert, dass der FPGA das file lädt und ausführt? Ja gibt es. Die kann man auch manuell berechnen, zumindest ging das früher mal. xapp138 war das damals für den Virtex, da steht ein CRC-Polynom dabei. Inzwischen gibts vielleicht was aktuelleres, auf die Schnelle habe ich ug470 gefunden aber da steht nur drin, dass es die CRC gibt, allerdings kein Polynom.
Solange die Versionskennung nicht im BRAM steht, kann ma da eh nix machen, da sie ansonsten eine aktivierte Routing Ressource oder eine initialisierte LUT irgendwo auf dem FPGA, was sich ziemlich sicher auch bei jedem Durchlauf der Synthese ändert. Wenn man das im BRAM hat, geht es recht einfach, früher hieß das data2mem, bei Vivado gibt's auch sowas...
VHDL hotline schrieb im Beitrag #6075548: > Ja gibt es. Die kann man auch manuell berechnen, zumindest ging das > früher mal. xapp138 war das damals für den Virtex, da steht ein > CRC-Polynom dabei. Danke, das schaue ich mal. Tobias B. schrieb: > woran die UserAccess Methode > scheitern wuerde? Weil sie erst implementiert werden müsste, um dann zu funktionieren oder nicht zu funktionieren. Sie ist aber so nicht implementiert. Und der Zugriff auf diesen USER CODE ist nicht die einzige Prüfung. Daher ist das am falschen Ende gedacht. Die vorhandene FPGA-FW ist ja schon vorhanden und die Abhängigkeiten müssten erst beseitigt werden. Was du vorschlägst, kommt einem redesign aller FW-Versionen gleich, da kann man es auch gleich lassen.
M. W. schrieb: > Weil sie erst implementiert werden müsste, um dann zu funktionieren oder > nicht zu funktionieren. > > Sie ist aber so nicht implementiert. Und der Zugriff auf diesen USER > CODE ist nicht die einzige Prüfung. Daher ist das am falschen Ende > gedacht. > > Die vorhandene FPGA-FW ist ja schon vorhanden und die Abhängigkeiten > müssten erst beseitigt werden. > > Was du vorschlägst, kommt einem redesign aller FW-Versionen gleich, da > kann man es auch gleich lassen Ok, versteh. Dann hast du allerdings ein deutlich groesseres Problem und zwar passt dein Entwicklungsprozess nicht zu eurem System. Selbst wenn du jetzt hingehst und nur entsprechende Bits im Bitfile aenderst, wie verifizierst du, dass es kein Impact auf den Rest des Systems hat? Sollte das System wirklich fuer Medizin sein, dann kommt auch noch das Problem mit der Zulassung. (Wahrscheinlich reicht hier eine vereinfachte Aenderungszulassung, aber ohne geht es halt nicht.) Falls das System noch eine Jahre laufen soll, wuerde ich erstmal eine Kosten/Nutzen Rechnung aufmachen und schauen ob eine ordentliche Implementierung nicht vielleicht sinnvoller ist. Ebenso wuerde ich mal schauen ob der Prozess zum das entsprechende Requirements Engineering Probleme aufweist. Aus technischer Sicht sehen deine KArten relativ schlecht aus. Ich wuerde mal saemtliches Material zum Thema "Xilinx Bitfile Reverse Engineering" durchackern.
Tobias B. schrieb: > Dann hast du allerdings ein deutlich groesseres Problem und > zwar passt dein Entwicklungsprozess nicht zu eurem System. Sagen wir mal: Der verspätet ins Projekt gerufene selbständige Entwickler ist nicht in der Lage, die Versäumnisse aus 10 Jahren Planung optimal zu beseitigen. Die Gerätchen haben ja ihre Historie. Manche Sachen kann man eben nicht voraussehen. Damals waren die FPGAs klein und die FW auf die Geräte einzeln optimiert. Nun kommt man dahin, dass man mit weniger FW-Versionen arbeiten will. Tobias B. schrieb: > Sollte das System wirklich fuer Medizin sein, dann kommt auch noch das > Problem mit der Zulassung. Du hast es erfasst! Ein FPGA-update gilt als ein HW-update und es muss nur diese Komponenten getestet werden. Eine FPGA-FW für gleich mehrere Geräte. Muss man auch die Einspielsoftware ändern, die auf einer anderen Komponente sitzt, dann zieht das sehr viel nach sich. Ich MUSS also die Änderungen auf das FPGA beschränken und darf nichts als Anforderung nach oben weitergeben. Macht aber nichts: Dann erzeuge ich eben die notwendigen Versionen per Hand. Tut ja mehr oder weniger von selber. Thema kann geschlossen werden.
Markus W. schrieb: > Macht aber nichts: Dann erzeuge ich eben die notwendigen Versionen per > Hand. Tut ja mehr oder weniger von selber. > > Thema kann geschlossen werden. Ok, das ist dann wohl oder uebel das kleinste Uebel. :-( Immerhin steigert es die Vorfreude auf das naechste Projekt auf der gruenen Wiese. ;-)
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.