Forum: FPGA, VHDL & Co. Programmierung von FPGAs


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 Lisa Löwenschwanz (Gast)


Bewertung
-12 lesenswert
nicht lesenswert
Hi Leute,

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

von Duke Scarring (Gast)


Bewertung
5 lesenswert
nicht lesenswert
Ich finde VHDL als Hochsprache ganz passabel.

von also echt (Gast)


Bewertung
1 lesenswert
nicht lesenswert
wirst du gezwungen? wenn nicht, lass es doch einfach bleiben und 
verschone dieses Forum...

von ui (Gast)


Bewertung
2 lesenswert
nicht lesenswert
Lisa Löwenschwanz schrieb:
> Muss das so kompliziert
> sein kann man die Dinger nicht mit irgend einer Hochsprache
> programmieren?

Ja

Beitrag #5084401 wurde von einem Moderator gelöscht.
von S. R. (svenska)


Bewertung
-1 lesenswert
nicht lesenswert
Dann nimm Verilog.

von Bitwurschtler (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Björn L. schrieb im Beitrag #5084401:
> Ihr seit mir Experten. VHDL geht gar nicht viel zu
> unübersichtlich. Da
> bleib ich doch besser bei Assembler und DSPs.

Dann schau dir mal ABEL an, das wird aber nur noch wenig unterstützt, 
viel zu übersichtlich.

https://en.wikipedia.org/wiki/Advanced_Boolean_Expression_Language#/media/File:ABEL_HDL_example_SN74162.png

von torwin (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Natürlich kann man:),
nimm doch einfach SystemC.
https://de.wikipedia.org/wiki/SystemC

von Dussel (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Da das ja schon offensichtlich eine Trollfrage ist: Kann man bei FPGA 
von programmieren sprechen? :D

von Bitwurschtler (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Dussel schrieb:
> Da das ja schon offensichtlich eine Trollfrage ist: Kann man bei FPGA
> von programmieren sprechen? :D

Trolle ja!

von Falk B. (falk)


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

von Chefkritiker (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Dussel schrieb:
> Da das ja schon offensichtlich eine Trollfrage ist: Kann man bei FPGA
> von programmieren sprechen? :D

Da sie das Wort "feldprogrammierbar" im Namen haben, sicher. Warum 
nicht?

von Lothar M. (lkmiller) (Moderator) Benutzerseite


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

von Edi M. (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Heissluftbalone "schweben", wie jeder weiß und die Ballonfizzis nennen 
es "fahren", weil sie sich für wichtig halten und zu der Sorte gehören, 
die glauben, sie wären was Besseres und werden für schlauer gehalten, 
wenn sie sich eine eigenen Terminologie zulegen.

Da solcherlei Treiben aber schon durch die Machenschaften der Jäger und 
ihrer Spezialsprache in der Bevölkerung lächerlich geworden ist und 
nicht mehr zieht, muss man davon abraten.

Ohne Gefühlsduselei kann man bei elektronischen Bausteinen, die eine 
Einstellmöglichkeit besitzen, problemlos von PROGRAMMIEREN reden. Da 
FPGAs eine Reihe von Freiheitsgraden haben, werden sie ganz sicher und 
mit grösstmöglicher Inbrunst von mir programmier!

von Pat A. (patamat)


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

Dann "programmiere" auch weiterhin FPGA(s).

von Gustl B. (-gb-)


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

: Bearbeitet durch User
von Besucher (Gast)


Bewertung
2 lesenswert
nicht lesenswert
Lisa Löwenschwanz schrieb:
> 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

Kann man die Dinger auch irgendwie anders programmieren als in einer 
Hochsprache? xD
Im Ernst - VHDL, Verilog oder SystemC* finde ich schon ziemlich 
hochsprachig. Was soll denn danach noch folgen? Eine JVM, oder gar ein 
ganzes OS in HW? Hmm, es gibt ja durchaus auch FPGAs die einen 
PowerPC-Core oder sowas integriert haben, aber wirklich durchgesetzt 
haben die sich nicht. Macht ja auch nur bedingt Sinn. FPGAs und CPUs 
sind halt zwei unterschiedliche Dinge, haben ihre ganz einen 
Aufgabenbereiche, und sind eben auch unterschiedlich anzusteuern. Je 
mehr man sich an eine bequeme Hochsprache annähern möchte desto weniger 
Sinn macht es einen FPGA zu verbauen. Muss man halt abwägen. Aber der 
Lohn für die Mühe ist dann eben auch die Freisetzung ungeahnter 
Resourcen. :)


* SystemC habe ich damals an der Uni gelernt. Ist auch ganz interessant, 
obgleich es in der Industrie eigentlich gar keine Bedeutung hat. Wer 
dennoch mal reinschnuppern möchte kann in diesem "Kurs" einen Eindruck 
davon bekommen:
https://www.youtube.com/watch?v=NCFxBGLB5xs&list=PLcvQHr8v8MQLj9tCYyOw44X1PLisEsX-J

von Gustl B. (-gb-)


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

: Bearbeitet durch User
von Jio (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Komplexität entsteht weil der Mensch seine Fähigkeiten immer weiter 
entwickelt.
Vieles wird mit der Zeit durch Verbesserung und bessere Konzepte 
einfacher. Aber es wird immer komplizierte und schwierige Tätigkeiten 
geben, weil es immer Menschen geben wird die nicht nur das tun was 
einfach ist.
Und mit der Zeit werden schwierige Aufgaben irgendwann einfacher.

Vielleicht braucht der eine oder andere auch ein gewissen Respekt und 
Einsicht. Viele Werke und Tätigkeiten sind das Ergebnis disziplinierter 
Bemühungen und einer langen Lernphase.
Entweder man ist bereit die notwendige Zeit und Energie zu investieren 
oder man sucht sich etwas anderes.

von Borislav B. (boris_b)


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

von Lothar M. (lkmiller) (Moderator) Benutzerseite


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

von Thorsten S. (thosch)


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

von Andre (Gast)


Bewertung
0 lesenswert
nicht lesenswert
also echt schrieb:
> wirst du gezwungen? wenn nicht, lass es doch einfach bleiben und
> verschone dieses Forum...

Solche Kommentare sollten dieses Forum verschonen!

von Weltbester FPGA-Pongo (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Hört das eigentlich nie auf, das Wort "Programmieren" ständig nur den 
Hochsprachen zuzuordnen? Ich antworte auf solches Gemetzel inzwischen 
nur noch mit einer Phrase:

"FPGA" = field PROGRAMMABLE gate array. Frrtig!

Bedeutet das Wort "programmable" im Deutschen "Konfigurierbar"?

Die Amerikaner und Engländer sprechen auch von "Programming", wenn sie 
von der Erstellung der Software (Verilog) fürs FPGA reden. Die 
Niederländer tun das auch und auch von der Franzosen und Italienern höre 
Ich nichts anderes.

Warum sollte das in Deutschland nicht so heissen?

Dass VHDL, formell "Description" beinhaltet, widerspricht dem nicht. Ein 
Simulink-Model ist auch eine Beschreibung und dennoch wird das Simulink 
durch diese Software "programmiert". Mitunter wird dann daraus dann ein 
FPGA programmiert.

von Edi M. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Besucher schrieb:
> ann man die Dinger auch irgendwie anders programmieren als in einer
> Hochsprache? xD

Ja, du kannst mit dem FPGA-Editor nach wie vor Verbindungen ziehen, eine 
Netzliste vorgeben und Gleichungen verwenden, wenn Du magst.

von Jan B. (do9jhb)


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

von Edi M. (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
So ist es. Auch deshalb wird ein FPGA programmiert. Fertig!

Ich habe das überigens auch schon im Kollegenkreis mehrfach besprochen: 
Kein Mensch regt sich darüber auf, von Programmieren zu reden. Scheint 
nur ein Problem für abstrakt denkende Heinis.

von Markus F. (mfro)


Bewertung
1 lesenswert
nicht lesenswert
"Ach, Sie sind Programmierer?"

"Nö, ich bin nur Beschreiber."

von Lothar M. (lkmiller) (Moderator) Benutzerseite


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

: Bearbeitet durch Moderator
von Duke Scarring (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Ja, ich suche bei den 'programmable resistor' auch immer nach dem 
JTAG-Anschluss:
https://www.ebay.com/sch/items/?_nkw=programmable+resistor

von Lothar M. (lkmiller) (Moderator) Benutzerseite


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

von Strubi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Jan B. schrieb:
> 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.

Ist aber auf dem MyHDL-Level nicht gross anders als eine 'Beschreibung' 
der HW wie in VHDL/Verilog. Nur viel weniger schwerfällig und im 
Testbenching/Modelling an vorderster Front und man kann auf höheren 
Leveln viel elegantere und robuste HLS machen.

Wenn ich ganz spitzfindig tun will, abgesehen von diversen Threads hier 
zum Thema "Was ist der Unterschied von Programmiersprache zu 
Beschreibungssprache" (VHDL ist eine Programmiersprache, aufgepasst):
Wenn man erst mal ein digitales Design anschmeisst, muss man sich 
(Design!) um eine brauchbare formale Beschreibung kümmern, d.h. das 
Subset der Programmiersprache nutzen, was sinnvoll in Hardware umsetzbar 
ist.
Der Schritt, bestehenden Logikelementen per Design Seele einzuhauchen 
wäre wiederum ein Programmieren. Also wenn ich mittels einer 
Turing-vollständigen Sprache beschreibe, was existierende 
Vielzweck-Primitiven tun sollen, ist es rein technisch gesehen 
'Programmieren'.
Wenn ich das Ding in einen ASIC giessen will, ist es aber wieder ein 
pures Design. Und damit ist VHDL explizit keine wirkliche 
Beschreibungssprache, da ein Designregeln-Schema auf der HDL-Ebene fehlt 
(wie in IP-XACT) oder nur schwierig umsetzbar ist. Der Coder (ich sag 
jetzt mal nicht Programmierer) muss einiges Wissen erwerben, welches 
Konstrukt vom Tool in was umgesetzt wird.
Erinnert irgendwie an den Welle-Teilchen-Dualismus, wo sich vor Jahren 
zwei (gleich gute) Physikerlager auf die Köppe gegeben haben.
Vielleicht wäre es konsequenter gewesen, man hätte das 'D' in VHDL mit 
Design bezeichnet.

von Edi M. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Das ist ein interessanter Interpretationsansatz. Nicht unbedingt einer, 
dem ich zu 100% folgen kann, aber einer der zweifelsfrei zu respektieren 
ist.

Turing, wer war das noch gleich?

von Dussel (Gast)


Bewertung
4 lesenswert
nicht lesenswert
Meister E. schrieb:
> Ich habe das überigens auch schon im Kollegenkreis mehrfach besprochen:
> Kein Mensch regt sich darüber auf, von Programmieren zu reden. Scheint
> nur ein Problem für abstrakt denkende Heinis.
Ich habe auch schon bei der Arbeit mit anderen FPGA-Entwicklern 
gesprochen und da war auch meistens (oder immer) von programmieren die 
Rede. Das ist wie die Schraubenzieher-Schraubendreher-Diskussion. Wer 
Ahnung hat, weiß, dass es beide Begriffe gibt und benutzt den ihm 
lieberen, andere versuchen sich halt durch das Kennen des 'richtigen' 
Begriffs zu profilieren.

Im Anfängerumfeld hat meiner Meinung nach Lothar aber Recht. Bei 
Anfängern kann es schon sinnvoll sein, ihnen klarzumachen, dass es kein 
sequentielles Programm erstellt wird.

von Dussel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Das letzte 'es' gehört da natürlich nicht hin.

von Ordner (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Meister E. schrieb:
> So ist es. Auch deshalb wird ein FPGA programmiert. Fertig!
>
> Ich habe das überigens auch schon im Kollegenkreis mehrfach besprochen:
> Kein Mensch regt sich darüber auf, von Programmieren zu reden. Scheint
> nur ein Problem für abstrakt denkende Heinis.

Naja,
wer ein Fahrzeug führen kann, kann noch kein Flugzeug führen, obwohl 
beides *"führer" sind.

Und deshalb kann ein Computer-Programmierer auch nicht notwendigerweise 
ein FPGA programmieren.
Das kann man nicht oft genug betonen indem darauf hinweist das ein 
Flugzeug-führer fliegt und der Wagen-führer fährt.

Nicht das ein Mantafahrer glaubt, Pedal ist Pedal und Steuerhorn ist 
auch nur ein halbes Lenkrad und fliegen kommt vom "schnell fahren" , 
denn abheben tut die Kiste von ganz alleine wenn der Speed stimmt ...

von Versoffener FPGA-Programmierer-Philosoph (Gast)


Bewertung
-3 lesenswert
nicht lesenswert
Auf FPGAs läuft doch in der Regel sogar in C programmierter Code. Ein 
FPGA kann alles Mögliche sein:

- dummer Pegelwandler
- Prozessor (mit C-Programmierten Programmen)
- hochkomplexer DSP
- bester Freund
- ...

Eigentlich gibt es doch nur Hardware, denn die Software ist einfach nur 
eine Abstraktionsebene - ein Konzept. Real ist nur die stumpfe Materie 
und deren Anordnung und der Fluss der Energie.

von WS (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Wenn man euch so liest, muss man sich fragen, ob ihr je irgendwas Reales 
programmiert habt.
Unter normale Leuten im Job, wird so eine Diskussion gar nicht geführt.

Wenn man so spitzfindig wäre, müsste man wohl auch behaupten, dass es 
keine Mittagspause gibt, weil die nicht mitten am Tag ist und das 
10-Uhr-Frühstück keines ist, weil 10.00 nicht mehr "früh" ist.

Beitrag #5114898 wurde von einem Moderator gelöscht.
von Markus W. (elektrowagi78) Benutzerseite


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

von Mirko (Gast)


Bewertung
4 lesenswert
nicht lesenswert

von Gustl B. (-gb-)


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

: Bearbeitet durch User
von Duke Scarring (Gast)


Bewertung
2 lesenswert
nicht lesenswert
Eine CPU ist auch nur eine FSM :-)

von Selbi (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
Duke Scarring schrieb:
> Eine CPU ist auch nur eine FSM :-)

Ein CPU betreibt eine FSM, ist aber keine.
Beim FPGA ist die Schaltung, die die FSM abarbeitet, eine CPU - das 
macht Sinn.

von Marc H. (marchorby)


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

Was macht dann ein Zugführer?

von Ordner (Gast)


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

Der marschiert an der Spitze seines Zuges.

von Lothar M. (lkmiller) (Moderator) Benutzerseite


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

: Bearbeitet durch Moderator
von Markus W. (elektrowagi78) Benutzerseite


Bewertung
-1 lesenswert
nicht lesenswert
Gustl B. schrieb:
> Ist das nicht sogar egal?

Ich finde das nicht egal, weil erzeugter Code wirklich hardwarenah die 
gewünschte Funktion mit einer optimierten Schaltung abbildet, während 
ein CORE die Tätigkeiten nur virtuell mit einer normierten Hwardware 
nachstellt.

Das eine ist eine Schaltung, das andere tut so, als wäre es eine 
Schaltung.

von Gustl B. (-gb-)


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

von Jürgen S. (engineer) Benutzerseite


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

von S. R. (svenska)


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

von Edi M. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
An einem Softcore haben aber schon viele dran gearbeitet und Fehler 
rausgeworfen und dasselbe gilt für Echtzeitsysteme die draufinstalliert 
werden. Die sind Tausendfach getestet und ziemlich gut gesichert.

von S. R. (svenska)


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

von Edi M. (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
S. R. schrieb:
> Das gilt aber auch für eine entsprechend gewartete Programmbibliothek.

Du hast einen kompletten von Tausenden Entwicklern eingesetzen und 
getesteten Softcore mit einem Echtzeitsystem in der Programmbibiliothek?

Du verstehst schon, was Ich Dir sagen will? ;-=

Was man kaufen kann, kann man selber kaum billiger und besser machen und 
SoftCore muss man nicht mal kaufen ... auch das Linux gibt es umsonst ..

von S. R. (svenska)


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

von Edi M. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
S. R. schrieb:
> dass ein Mikrocontroller in Hardware
> besser getestet ist als ein Softcore,

Das ist sicher der Fall. Ich allerdings verglich einen Softcore mit ein 
bischen C-Code mit der Alternative, alles in VHDL zu machen. Nur um ein 
Beispiel zu bringen, wo wenig selber machen muss und auf Getestetes 
zurückgreifen kann. Das ist - so nebenbei bemerkt - bei uns DAS 
Argument, das in jedem zweiten Projekt kommt, warum wir einen fertigen 
Core einsetzen, auch wenn der eigentlich Kanonen auf Spatzen ist. Wir 
haben dann nur sehr wenig Software zu prüfen, zu pflegen und dem Kunden 
an Funktion nachzuweisen.

von C. A. Rotwang (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
S. R. schrieb:
> 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,
Nein, die Hardwaree-Hersteller liefern auch nach Jahren noch Erratas zu 
ihren prozessoren. Der intel-FDIV - Bug wurde in Massenproduktion 
ausgeliefert.
Und einen Softcore kann man nach Bugentdeckung fixen, bei µC ist das 
eher selten der Fall.
Und im FPGA kann man ggf Inspektions und Korrekturlogik um 
Bugs/potentielle Backdoors herumbauen.


> und dass eine Backdoor in einem
> Softcore wesentlich leichter zu verstecken ist.

Häh? für nen Softcore kriegste Source/RTL-Simulation - code; damit kann 
man analysieren was das tun tut. Bei Hardware, kriegste vielleicht nen 
schaltplan/Gatterliste analysier den mal nach backdoors!?

Oder man aktiviert die HardwareBackdoor beim Laserabgleich oder durch 
gezielte Alterung/Elektronenmigration, oder oder. In Hardware ist eine 
backdoor leichter versteckbar als in einem Soft-Core.

von S. R. (svenska)


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

von Martin S. (strubi)


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

von S. R. (svenska)


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

von Markus F. (mfro)


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

von Edi M. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Martin S. schrieb:
> Deswegen: NIE
> ein ARM in sicherheitskritischen Umgebungen.
AHA! Allerdings muss man irgendwelche Hänger sowieso annehmen und 
Systeme redundant bauen.

von chris (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Sicherheit hat mehrer Bedeutungen:

1. funktionale Sicherheit ( Maschinensicherheit z.B. der Ausfall der 
elektronischen Lenkung eines Autos )
2. Datensicherheit ( Trojaner usw ).

Redundanz wird üblicherweise nur bei '1.' angewendet.

von Strubi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Markus F. schrieb:
> 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

Geht wohl eher Richtung SystemVerilog und XML-Schweinereien...
Auf jeden Fall haben sie nette Money-Tools um mehr Testszenarien in 
endlicher Zeit (co-)Simulieren zu können. Aber bei der Komplexität 
rutscht schon mal was durch.

chris schrieb:
> 1. funktionale Sicherheit ( Maschinensicherheit z.B. der Ausfall der
> elektronischen Lenkung eines Autos )
> 2. Datensicherheit ( Trojaner usw ).

Wenn du eine 'IoT'-Industrieanlage nicht per Buffer-Overflow/Paket-Flood 
o.ä. sabotieren können sollst, gibt's da keinen Unterschied mehr zw. 1 
und 2..

von Pandur S. (jetztnicht)


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

von chris (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Obwohl das jetzt eigentlich nicht das Thema ist gibt es sehr wohl 
Hardware-Angriffe:
https://en.wikipedia.org/wiki/Row_hammer

von Hochwald (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Falk B. schrieb:
> @ 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.

Da ist er wieder - der Frauenhasser.

von Bitwurschtler (Gast)


Bewertung
2 lesenswert
nicht lesenswert
chris schrieb:
> Obwohl das jetzt eigentlich nicht das Thema ist gibt es sehr wohl
> Hardware-Angriffe:
> https://en.wikipedia.org/wiki/Row_hammer

... und hier wurde bereits vor zwei Jahren  abgefrühstückt:
Beitrag "Rowhammer-Attacke"

von S. R. (svenska)


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

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

von Jürgen S. (engineer) Benutzerseite


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

von Retro N. (retronerd)


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

von Edi M. (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
Retro N. schrieb:
> Es kontrolliert die Fahrkarten.
> Wer den Zug fährt heisst nämlich Lokführer.

und "Zugführer" hiess bei uns immer der, der die Soldaten angeführt hat.

von Retro N. (retronerd)


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

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.
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.