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. (?)
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.