Programmierung von FPGAs

Dann nimm Verilog.

@ Lisa Löwenschwanz (Gast)

>mache gerade meine ersten Schritte mit FPGA. Muss das so kompliziert
>sein kann man die Dinger nicht mit irgend einer Hochsprache
>programmieren?
>Bitte um Antwort

Such dir ein anderes Mädchenspielzeug und toll dich.

Dussel schrieb:
> Da das ja schon offensichtlich eine Trollfrage ist:
> Kann man bei FPGA von programmieren sprechen? :D
Sicher kann man. Man kann auch bei Heißluftballonen von "fliegen" 
sprechen. Die Allermeisten würden zustimmen.

Björn und Lisa: bitte nur 1 Namen pro Thread.
Steht so in den Nutzungsbedingungen

Sprachliche Feinheiten, Differenzierungen und exakte Ausdrucksweise sind 
wohl nicht dein Freund?

Dann "programmiere" auch weiterhin FPGA(s).

Mein Beispiel ist ja die Waschmaschine. So eine ganz alte noch ohne 
Software drinnen. Die hat auch Waschprogramme die dann abgearbeitet 
werden. Da drehen sich langsam irgendwelche Rädchen. Und ganz am Anfang 
stellt man ein paar Schalter ein ind legt dann fest was danach passiert, 
man nennt das Programmieren.

Man muss das aber unterscheiden vom Programmieren im Sinne von Software 
schreiben. Ene HDL schreiben ist kein Programmieren, es ist eben das 
Beschreiben von Hardware, wenn man das Ergebnis davon aber ins FPGA 
schiebt dann programmiert man es im Sinne von festlegen was das danach 
tut.

Eigentlich ist aber natürlich auch ein FPGA ein ASIC. Wobei die 
Anwendung hier eben die Flexibilität ist. Einmal gefertigt verändert 
sich der Aufbau im FPGA nichtmehr, egal mit welcher Konfiguration, es 
verhält sich nur anders. Man beschreibt so zwar mit einer HDL Hardware, 
aber die wird nicht als Hardware gebaut oder erzeugt, sondern nur auf 
die schon im FPGA vorhandene Hardware abgebildet.

Besucher schrieb:
> Hmm, es gibt ja durchaus auch FPGAs die einen
> PowerPC-Core oder sowas integriert haben, aber wirklich durchgesetzt
> haben die sich nicht.

Doch klar, bei Altera/Intel die ganzen SoC Chips und bei Xilinx die Zynq 
Reihe.

Und naja, wenn man die Hradware beschreibt programmiert man eben nicht. 
Ausser man bezeichnet das schreiben von Code schon als Programmieren. 
Man kann in einer HDL einzelne Gatter beschreiben, aber eben auch 
abstraktere Dinge die die Software dann selber aus einfacheren Bauteinen 
zusammensetzt. Hochsprachen überlassen das dann nur der Software die 
passende Hardware zu beschreiben.

Klar geht das. Mit MATLAB Simulink und dem DSP Builder Blockset z.B.
Damit lässt sich das FPGA-Programm schön grafisch modellieren.

Borislav B. schrieb:
> Damit lässt sich das FPGA-Programm schön *grafisch modellieren*
Hier gehts es aber darum, FPGAs zu programmieren. Und das geht mit 
VHDL erst, wenn aufgrund steigender Nachfrage der Nachfolger VHPL(*) 
freigegeben und genormt ist. Und auch Verilog muss erst mal den Schritt 
aus der HDL Ecke in die HPL(*) Liga schaffen.

(*) HPL = Hardware Programming Language

klar kann man ein FPGA programmieren:
Man konfiguriert sich einen Controller Core da hinein (z.B. NIOS bei 
Altera/Intel oder MicroBlaze bei Xilinx).
Dann lässt sich das sogar in gewöhnlichem ANSI-C programmieren! ;-)

Es gäbe auch noch MyHDL (http://www.myhdl.org/start/overview.html), 
damit soll man FPGAs mit Hilfe von Python "programmieren" können... Wie 
ich es verstanden habe definiert man mit der Python lib ein bestimmtes 
Verhalten und das Tool wandelt es dann in VHDL oder Verilog um.

"Ach, Sie sind Programmierer?"

"Nö, ich bin nur Beschreiber."

Meister E. schrieb:
> Auch deshalb wird ein FPGA programmiert.
Jawoll. Mit VHPL!

Ich habe übrigens kein Problem damit, ein FPGA zu "programmieren". Das 
Problem haben die, die meinen, ein FPGA genauso und mit der selben 
Denkweise wie einen Mikrocontroller "programmieren" zu können. Ist ja 
auch das selbe Wort, dann muss es auch die selbe Vorgehensweise sein. 
Logisch.

Markus F. schrieb:
> "Ach, Sie sind Programmierer?"
> "Nö, ich bin nur Beschreiber."
Ich bin Hardwareentwickler und setze auch FPGA ein.

Markus W. schrieb:
> Versoffener FPGA-Programmierer-Philosoph schrieb im Beitrag #5114808:
>> Auf FPGAs läuft doch in der Regel sogar in C programmierter Code.
> Meinst Du jetzt echten C in einem Core oder umgesetzten C in Form von
> VHDL aus Simulink?

Ist das nicht sogar egal?

Wenn ich im FPGA nur Dinge verwende die nicht von einem Speicherinhalt 
abhängen, dann wäre da ein Unterschied, aber wie ist was wenn man z. B. 
eine FSM einbaut, dann verwendet man schon Speicher. Sprich das FPGA 
verhält sich unterschiedlich je nachdem was in einem Speicher steht. Bei 
einer CPU im FPGA mit Programm liegt das Programm auch in einem Speicher 
und das FPGA macht was anderes je nachdem was da gerade im Speicher 
steht.

Ich meine, wenn man Dir zwei Konfigurationsdateien gibt, eine mit CPU 
und Programm drinnen, die andere ohne, kannst du dann sagen welche 
welche ist? Die konfigurieren beide das FPGA und das verhält sich 
entsprechend, auch mit CPU und Programm, das ist am Ende auch Hardware, 
die Bits vom Programm sind genauso im FPGA gelandet wie die Bits einer 
FSM und bestimmen das Verhalten.

Vielleicht sollte man Im FPGA unterscheiden und sagen hier, der Teil mit 
den LUTs, das ist konfigurierbar (natürlich auch ASIC, aber macht dass 
es sich anfühlt als sei es kein ASIC), aber das BRAM, die DSP Slices, 
... das ist eben feste Hardware wie man sie auch in einer CPU finden 
könnte.

Ordner schrieb:
> Flugzeug-führer fliegt und der Wagen-führer fährt.

Was macht dann ein Zugführer?

Selbi schrieb:
> Ein CPU betreibt eine FSM, ist aber keine.
Fast jede CPU besteht aus FSM(**). Und letztlich werden diese CPU-FSM 
zusammen mit dem Programmcode eine noch komplexere FSM.

(**) Sie ist halt einfach nur ein wenig komplexer, als das was der 
Erstsemestler zu machen bekommt, aber sieh dir einfach mal die 
Beschreibung einer realen CPU an: da gibt eine FSM der anderen die Hand 
(Prefetch, Pipelining, Memory-Controller, dazu Timer und die gesamte 
sonstige Peripherie).

(**) Bestenfalls simple Single-Cycle-CPUs kommen mit einem 
Register-Alu-Satz aus und erhalten den kompletten Ablauf (und somit ihre 
FSM-Funktionalität) aus dem Programmspeicher.

Marc H. schrieb:
> Was macht dann ein Zugführer?
Er zieht...
Und ein Ballonfahrer? Was macht der?

Wie gesagt: ob ich ein FPGA mit VHDL programmiere oder mit VHDL eine 
Schaltung für ein FPGA beschreibe ist eigentlich reine Nomenklatur und 
hat bestenfalls was mit der zugrunde liegenden Denkweise zu tun. Die aus 
der µC-Softwaretechnik kommenden "Hardware-Programmierer" stellen (sich) 
dann ab und zu seltsame Fragen.

Hm, also für mich ist das alles keine Schaltung. Das FPGA ist 
unveränderbarer Baustein. Das verält sich einfach anders je nach 
Konfiguration, ändert aber nicht seinen internen Aufbau.

Wenn man jetzt sagt, ja der Bitstream ist eine Schaltung, OK, wenn in 
diesem Bitstream eine CPU enthalten ist, dann ist das auch eine 
Schaltung. Wenn im Bitstream auch noch ASM für die CPU enthalten ist, 
tja ... da läut zwar dann ein Programm, aber das ist doch auch feste im 
FPGA?!

Solange sich das Programm selber nicht zur Laufzeit verändert kann man 
das doch immer auch mit FSM beschreiben und es bleibt deterministisch 
was es macht, wie eine Mechanik. Ob da jetzt im BRAM irgendein Bild 
liegt das über VGA ausgegeben wird oder om da Code für eine CPU drinnen 
ist sollte doch egal sein, das ist feste im FPGA nach der Konfiguration 
und solange sich der Code selber nicht ändert kann man das als Hardware 
betrachten.

Oder man betrachtet alles als Software und nur das nackte FPGA selbst 
als Hardware das sich dann durch Software irgendwie verhält. Wenn da ein 
Bit in einer LUT gesetzt ist dann steht das eben genauso da wie ein Bit 
in einem Register einer CPU. Das verändert Verhalten, ist aber keine 
Hardware. Oder zählt man sie elektrischen Zustände als Hardware? Ich 
finde das alles nicht so trennscharf und eher philosophisch.

Technisch gesehen, ist das richtig. Alles, was veränderlich ist, ist 
eine Software. Es macht allerdings von der Sicherheitsbetrachtung schon 
einen Unterschied, ob Teile davon fixiert und getestet sind, wie es bei 
einem Core der Fall ist, oder ob dieselbe Funktion komplett frei 
programmiert wurde.

In dem Zusammenhang ist es interessant, dass bestimmte Funktionen in 
klassischem VHDL in Form von geschalteten LUTs erheblich kleiner sind 
und damit weniger Angriffsfläche gegen Störungen der Programmierung 
durch Strahlung oder EMV bieten (so das relevant ist) und bei anderen es 
auch durchaus anders herum ist: Da belegt eine zyklische Software 
zusammen mit der Soft-Core-CPU in Summe viel weniger Speicherfläche, die 
geschützt werden muss, als die ausgerollte Hardware. Diese ist damit 
zunächst vulnerabler, es sei denn, man nutzt die Masse an zeitlicher 
Geschwindigkeitsreserve zur Mehrfachrechung und Redundanz.

Wieder ein anderes Thema sind die funktionellen Fehler einer Software, 
weil nicht gut genug nachgedacht wurde und Fälle übersehen wurden 
und/oder weil ein Multitaskingsystem verwendet wird. Und auch da gilt: 
Je mehr selber gemacht wurde, desto anfälliger ist es meistens.

Die Fragestellung "sicher" oder "nicht sicher" lässt sich also nicht so 
direkt mit der Frage "Software" "Hardware" verknüpfen.

Jürgen S. schrieb:
> Und auch da gilt:
> Je mehr selber gemacht wurde, desto anfälliger ist es meistens.

Und das, was man nicht selber gemacht hat, hat jemand anders selber 
gemacht - und dem muss man dann vertrauen. Das ist der Knackpunkt bei 
"Sicherheit".

E. M. schrieb:
> Die sind Tausendfach getestet und ziemlich gut gesichert.

Nur dann, wenn du auch einen tausendfach getesteten und ziemlich gut 
gesicherten IP-Core nimmst und selbst keine Fehler beim Einbauen machst.

Das gilt aber auch für eine entsprechend gewartete Programmbibliothek.

E. M. schrieb:
> Du verstehst schon, was Ich Dir sagen will? ;-=

Nein. Ich gehe schlicht davon aus, dass ein Mikrocontroller in Hardware 
besser getestet ist als ein Softcore, und dass eine Backdoor in einem 
Softcore wesentlich leichter zu verstecken ist.

Mir ging es um die Aussage von Jürgen, dass das Hauptproblem meist im 
selbst gewarteten Code steckt. Nur ist der Code, den ich irgendwo 
einkaufe, von jemand anderem "selbst gewartet", also ist die Aussage nur 
bedingt sinnvoll (von Schadensersatzansprüchen - also dem Schwarzen 
Peter - mal abgesehen).

E. M. schrieb:
> Ich allerdings verglich einen Softcore mit ein
> bischen C-Code mit der Alternative, alles in VHDL zu machen.

Dann stimmt das. Trotzdem musst du allem, was du nicht selbst gemacht 
hast, schlicht vertrauen.

C. A. Rotwang schrieb:
> Der intel-FDIV - Bug wurde in Massenproduktion ausgeliefert.

Der ist jetzt über 20 Jahre her und betrifft eine Klasse von 
Prozessoren, von denen zumindest ich in diesem Zusammenhang nicht 
ausgehe. Bei "Softcore im FPGA" denke ich an einen kleinen 8- oder 
32-Bitter ohne große Features und vergleiche mit entsprechenden 
Hardcores...

> Nein, die Hardwaree-Hersteller liefern auch nach Jahren noch Erratas zu
> ihren prozessoren.

...und da ist an den CPU-Cores eher selten was faul. Die Peripherie 
(oder bestimmte Interaktionen mit selbiger) sind etwas anderes, gebe ich 
dir recht.

> Und einen Softcore kann man nach Bugentdeckung fixen, bei µC ist das
> eher selten der Fall.

Kann man - tut man es auch? Bei einem µC wird eher der Compiler gefixt, 
aber das führt hier zu weit. :-)

> Und im FPGA kann man ggf Inspektions und Korrekturlogik um
> Bugs/potentielle Backdoors herumbauen.

Macht das wer? Vom Militär mal abgesehen, meine ich.

C. A. Rotwang schrieb:
> Häh? für nen Softcore kriegste Source/RTL-Simulation - code; damit kann
> man analysieren was das tun tut.

Das funktioniert weder bei C-Code noch bei VHDL-Code, wenn du mich 
fragst. Allerdings gebe ich dir recht, dass man Backdoors in Hardware 
noch besser verstecken kann, insofern spielt das in beiden Fällen keine 
Rolle.

Moin,

ist zwar am Ursprungs-Thema vorbei, aber lest euch doch mal so ein paar 
aktuelle Erkenntnisse zum Prozessor-HW-Fuzzing durch und probiert es 
aus. Erschreckend, wie der eine oder andere aktuelle Intel mal 
stehenbleibt.
Bei ARM ist das eine ähnliche Katastrophe, da kann man aber m.W. nicht 
mal eben mit Microcode (wie bei Intel) noch herumpatchen. Deswegen: NIE 
ein ARM in sicherheitskritischen Umgebungen.

S. R. schrieb:
> Das funktioniert weder bei C-Code noch bei VHDL-Code, wenn du mich
> fragst

Wieso soll das nicht funktionieren? Ich tippe hier täglich "make run" 
:-)

C. A. Rotwang schrieb:
> In Hardware ist eine
> backdoor leichter versteckbar als in einem Soft-Core.

Das hängt wohl im Einzelfall davon ab, was sich hinter einer grösseren 
Komplexität verstecken lässt. Bei einer gut etablierten DSP-Architektur 
liegt das Bootrom "offen rum", somit sich die Hintertürchen zum 
vercryptenen Bootloading mal eben so öffnen lassen. Hätten sie's in HW 
versteckt, müsste man erst den ganzen Silicon-Zoo unterm Mikroskop in ne 
Netzliste umwandeln.

Martin S. schrieb:
> Wieso soll das nicht funktionieren?
> Ich tippe hier täglich "make run" :-)

Ich bezog mich auf "Backdoors per Blick auf den Quelltext erkennen", hab 
das aber nicht ausformuliert. ;-)

C. A. Rotwang schrieb:
> Nein, die Hardwaree-Hersteller liefern auch nach Jahren noch Erratas zu
> ihren prozessoren. Der intel-FDIV - Bug wurde in Massenproduktion
> ausgeliefert.

Warum sollte da auch irgendwas anders sein?

Die µC-Hersteller beschreiben ihre Käfer auch nicht wesentlich anders 
als unsereins (eben auch mit einer HDL, vielleicht oder wahrscheinlich 
sogar mit VHDL). Vielleicht haben sie an der ein oder anderen Stelle 
besseres Equipment, vielleicht auch nicht. Vielleicht haben sie bessere 
Entwickler, vielleicht auch nicht (oder halt nur Dienstags bis 
Freitags).

Letztendlich ist es eine Frage des Vertrauens: wem vertraut man mehr, 
sich selbst (bzw. den eigenen Leuten) oder einem (großen oder kleinen) 
Hersteller.

Früher hieß es mal "nobody ever got fired for buying IBM". Der Spruch 
funktioniert heute (auch) mit Microsoft oder Intel. Obwohl die auch 
nicht weniger Murks machen als sonstwer.

Backdoor in Hardware ? Eher nicht. Hin und wieder geistern 
abenteuerliche Stories durch die Medien, wie "FPGA einer Drohne im Flug 
gehackt" ... die deswegen nicht wahrer werden.

Sapperlot W. schrieb:
> Backdoor in Hardware ? Eher nicht.

Weil? Nur, weil du nen Strohmann aufstellst, wird Ursprungsbehauptung 
nicht falscher.

Die Fragestellung nach der Machbarkeit und Auswirkung solcher 
Bitattacken stellt sich eigentlich nicht wirklich, weil in solchen 
Systemen die Speicherzugriffe ohnehin als unsicher gelten müssen und 
über entsprechende Mechanismen geschützt werden. Da macht es dann keinen 
Unterschied, ob Bits wegen Übertragungsproblemen, Fertigungsfehler, 
Strahlung oder einem schlechten Speicherriegel falsch sind.

Marc H. schrieb:
> Ordner schrieb:
>> Flugzeug-führer fliegt und der Wagen-führer fährt.
>
> Was macht dann ein Zugführer?

Es kontrolliert die Fahrkarten.
Wer den Zug fährt heisst nämlich Lokführer.

Ordner schrieb:
> "Zugführer" hiess bei uns immer der, der die Soldaten angeführt hat.

Du bist zu spät: Beitrag "Re: Programmierung von FPGAs"