Forum: FPGA, VHDL & Co. Vivado Version im BIT file checken und ändern - Checksumproblem?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von M. W. (elektrowagi78) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Christian R. (supachris)


Bewertung
0 lesenswert
nicht lesenswert
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.

von M. W. (elektrowagi78) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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).

von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
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

von M. W. (elektrowagi78) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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).

von VHDL hotline (Gast)


Bewertung
2 lesenswert
nicht lesenswert
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.

von Christian R. (supachris)


Bewertung
0 lesenswert
nicht lesenswert
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...

von M. W. (elektrowagi78) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von M. W. (elektrowagi78) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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. ;-)

von Tobias N. (technick2)


Bewertung
0 lesenswert
nicht lesenswert

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.