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).
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. ;-)
