Forum: FPGA, VHDL & Co. Vorbelegung für Block-RAMs wiederladen


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 Markus W. (elektrowagi78) Benutzerseite


Lesenswert?

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.

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


Lesenswert?

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.

von Markus W. (elektrowagi78) Benutzerseite


Lesenswert?

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.

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


Lesenswert?

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.

von Jonas B. (jibi)


Lesenswert?

Nein.

von Martin S. (strubi)


Lesenswert?

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.

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


Lesenswert?

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.

von Markus W. (elektrowagi78) Benutzerseite


Lesenswert?

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

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]
  • [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.

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