In meinem Kundendesign liegen mehrere Vorbelegungen für Settings in
Blockrams eines FPGAs, welche vom Anwender überschrieben werden können
(und auch werden). Die Settings liegen als file vor, die von einer
RAM-Karte geladen werden.
Im Zuge eines partiellen Resets sollen nun die Werkseinstellungen die
als MIF file fest eingestellt sind, wieder geladen werden. Gibt es eine
Möglichkeit, das in Software zu tun, ohne den FPGA neu zu laden? Die
Schwierigkeit besteht darin, dass der FPGA mehrer solcher RAMs hat und
nur jeweils ein bestimmtes zurückgestellt werden soll. Die RAM enthalten
Steuercodes, die zum Dekodieren dienen und als Rückfalloption gebraucht
werden. Sie sind aber "confidential" und IP des Herstellers ( und nicht
des Nutzers) und sollen daher nicht als file vorliegen.
Ich würde es gerne vermeiden, alle Settings nochmals im FPGa zu
speichern. Diese sind leider nicht generisch und können nicht per SW
erzeugt werden, sondern kommen aus MATLAB und würden eine Menge Logik
belegen. Genau genommen bräuchte man nochmal soviele BRAM, aus denen die
Nutzer-RAMs geladen werden.
Und: Es sind so viele dass man sie nicht als ROM in fabric machen kann
ohne den FPGA zu sprengen.
Welche Moeglichkeiten du da hast, ist stark FPGA abhaengig. Um welchen
FPGA Hersteller und Familie geht es denn?
Bei Xilinx FPGAs koenntest du das mit partial Reconfiguration, bzw.
Dynamic Function eXchange loesen:
https://www.xilinx.com/products/design-tools/vivado/implementation/dynamic-function-exchange.html#overview
Das ganze ist glaube ich mittlerweile sogar kostenlos.
Einen einzelnen BRAM wird man damit aber wohl nicht gezielt
ueberschreiben koennen. Evtl. sollte man ueberlegen ob man den Reset
nutzen kann um das BRAM umzuladen, mit dem selben Mechanismus wie eben
die Daten vom User ueberschrieben werden.
Ein Artix wird verwendet und ich nutze die bequeme Funktion, die RAMs
mit einem MIF zu beladen und die FFs per Init. Das ist sozusagen Design
Strategie, damit resourcen zu sparen und etwas IP im FPGA zu verstecken,
ohne es evident werden zu lassen. Die Anfangszustände der FFs sind auch
von Relevanz.
Tobias B. schrieb:> Evtl. sollte man ueberlegen ob man den Reset> nutzen kann um das BRAM umzuladen, mit dem selben Mechanismus wie eben> die Daten vom User ueberschrieben werden.
Das geht eben nicht. Der User entwickelt seine eigenen Daten und lädt
sie dann per Prozessor-Pipe (AXI) hoch. Die Daten sind dem User bekannt
und werden im RAM hinterlegt. "Unsere" Daten kennt er aber nicht und
soll er auch nicht kennen. Ich sehe keine Möglichkeit die irgendwoher zu
bekommen, ausser aus dem FPGA selber und dann kostet es FFs oder BRAMs.
Bei FFs habe ich die Möglichkeit, alles auf 0 zu resetten und die FFs
umzudrehen, indem ein Inverter dahinter hängt. Damit ist der resette
Wert ausserhalb so, wie ich es brauche. Ins FF wird dann durch die
gleichen Inverter geschrieben, sodass das Benutzerfile passen
gespeichert wird.
Bei BRAMs sehe ich das nicht, wie ich das machen soll, ohne ein
Kombinatorikgrab zu erzeugen.
Momentan bin ich beim Laden eines Bitstroms aus RAMs mit Kompression.
Wenn das nicht reicht, muss alles aufgebrochen werden und alle Daten
verschlüsselt eingeschrieben werden. Dann kann der Kunde die Primärdaten
haben. Leider haben die Designer, die das erstmal gebaut hatten, das
nicht vorgesehen und die Platinen sind so wie sie sind eben da und im
Feld.
Markus W. schrieb:> Ein Artix wird verwendet und ich nutze die bequeme Funktion, die RAMs> mit einem MIF zu beladen und die FFs per Init.
Die Artix koennen DFX, allerdings nicht die kleinsten (12T und 25T).
Markus W. schrieb:> "Unsere" Daten kennt er aber nicht und> soll er auch nicht kennen. Ich sehe keine Möglichkeit die irgendwoher zu> bekommen, ausser aus dem FPGA selber und dann kostet es FFs oder BRAMs.
Du kannst die Daten noch verschluesseln. Wenn der Schluessel in Logik
gebettet wird, dann ist es auch nicht ganz so trivial den aus dem
Bitsream zu extrahieren. Die Ultima Ratio ist das allerdings nicht, aber
das ganze hat leider eh den Status: Broken by Design. :-(
Theoretisch, und falls du noch Ressourcen hast, dann koenntest noch die
Daten aus einem BRAM den du als ROM verwendest nachladen beim Reset. Hat
dann natuerlich die Schwachstelle, dass die Daten relativ leicht aus dem
Bitstream extrahiert werden koennen. Der Vorschlag ist eher ergaenzender
Natur.
Wenn schon security by obscurity, gibt's noch zwei Moeglichkeiten:
1) Factory-Default im SPI-Flash o.ae. ablegen und nach Bedarf laden
2) Multi-Boot-Feature nutzen, wenn das Geraet 1-2 s ausfallen darf
Ersten Ansatz kann man entweder 'verschluesselt' ablegen und die geheime
Sequenz irgendwo in LUT-Logik verstecken oder gleich einen LFSR-Twister
einsetzen.
Entweder ist dann noch ein BRAM-Port frei (writeonly) oder es muss halt
doch noch ein Bus-Muxer ran. Sollte nicht so weh tun...
Ansonsten bliebe fuer (2) 'Golden Boot-Option' mit der eingebauten
AES-Nudelei, da muesste man dann fuers Auslesen der Keys die Spezis
bemuehen.
Martin S. schrieb:> Ansonsten bliebe fuer (2) 'Golden Boot-Option' mit der eingebauten> AES-Nudelei, da muesste man dann fuers Auslesen der Keys die Spezis> bemuehen.
Bei den Boards die schon im Feld sind, benoetigt man dann allerdings
nochmal physischen Zugriff um die eFUSEs zu setzen.
Die BRAM Daten selbst zu verschluesseln, scheint daher erstmal die
erfolgversprechendste Option zu sein. Und der Aufwand ist auch
ueberschaubar und allzu schuetzenswert koennen die Daten nicht sein,
sonst waere das ganze Design schon darauf ausgelegt gewesen.
Tobias B. schrieb:> allzu schuetzenswert koennen die Daten nicht sein,> sonst waere das ganze Design schon darauf ausgelegt gewesen.
schön wärs! Wie wir aus der Praxis wissen, kommt es öfters als
regelmäßig vor, dass einem im Nachhinein noch einfällt, etwas Hinzufügen
zu wollen (oder zu müssen).
Kriegt man die Daten gfs per JTAG irgendwie aus den Zellen, wo das INIT
gespeichert wird, in die RAMs? Oder steckt das komplett im Stream und
wird geladen?
Der BRAM ist ja ein vollständiger SRAM mit MUX/DEC Anschluss, d.h. man
kommt an die Zellen nur sequenziell dran. Ich nehme an, deren INIT Wert
wird nach dem Laden des FPGA zusätztlich in die RAMs
hineingeschrieben?
Diesen Prozess müsste man doch initiieren können, meine ich. (?)
