yC Programmierung vs. FPGA Programmierung

Anfänger 91 schrieb:
> Liege ich richtig, wenn man yController mit einer Hochsprache
> programmiert (bspw. C++) und FPGAs mit einer
> "Hardwarebeschleunigungssprache"?

uC (beachte Schreibweise) werden normalerweise in einer Hochsprache (C, 
C++, Basic, Forth, ...) programmiert die dann in Assembler (ja auch 
damit kann man programmieren) üebrsetzt wird und dan dem uC eingehaucht 
(programmiert, geflasht) wird.

Programmierbare Bausteile (CPLD, PALs, FPGAs, ASICs, ..) werden in einer 
Hadrwarebeschreibunsgsprache (beachte "beschreibung" nicht 
"beschleunigung") beschrieben, diese dann kompiliert und dann 
eingehaucht.

Normalerweise erzeugst du mit einer Hardwarebeschreibungssprache eine 
Schaltung, mit einer Programmiersprache ein Programm. Beide können aber 
zu einem großen Maß Dein Produkt umsetzten. Beispiel ist eine einfache 
Uhr. Die kann aus HW , also den Zählern, bestehen. Im Programm eines uC 
zählst du aber einfach Variablen hoch oder lässt einen Timer (das ist 
auch HW) zählen.

Programmeirbare Logik würde ich im ISO-Schichtenmodell in Layer 1 bis 3 
ansiedeln, uC in Schicht 2 bis 7.

rgds

Hochsprache?
Assembler tuts meist auch....

"Hardwarebeschleunigungssprache"?
Von sowas habe ich noch nie gehört.....



Vielleicht erst mal etwas lesen:
http://de.wikipedia.org/wiki/Field_Programmable_Gate_Array
http://de.wikipedia.org/wiki/Mikrocontroller

Hi,
ich versuche es mal kinderfreundlich zu beschreiben: ;-)

Theoretisch kannst du Programme für ALLE Bausteine in der gleichen 
Programmier-Sprache schreiben, wie C oder andere, du brauchst nur den 
entsprechenden Compiler(Assembler) der dir den Code auf die 
Hardware-Ebene umsetzt. Ob es Sinn macht, eher nicht, da die Sprache 
auch für den Einsatzzweck geeignet sein muss!!! (Goto und 
Funktionsaufrufe machen bei einem CPLD keinen Sinn)

>Und was ist letzteres nun genau?
Eigentlich ist es ein Verdrahtungsplan deines Chips.

Schau dir mal die CPLD, PALs und GALs an, das sind Bausteine deren 
Hardware wie ein Steckbrett aufgebaut ist.
Sie bieten dir, mit verschiedenen 'Blaupausen', an die einzelnen 
Zellen(Ein- u. Ausgänge) zu verdrahten.

1

E1 => Input

2

E2 => Input

3

A1 => Output

4

5

A1 = E1 & E2

Hier kannst du zu jedem Zeitpunkt sagen, wie die Signale stehen, egal 
wie viele weiter Verdrahtungen du noch in den Bausteinen hast.(Dies wird 
ständig ausgeführt)

Bei den uC ist das anders, die Zustände werden nur dann geändert, wenn 
der Programmcounter an der Stelle mit der entsprechenden 'Programmzeile' 
ist.

1

mov A, E1 ; lese E1

2

and E2    ; UND E2

3

mov A1, A ; schreibe Ergebnis nach A1

hier liegt der Unterschied, in der Ausführung und das muss bei der 
Programmentwicklung berücksichtige werden.

Es gab (oder gibt noch) MC mit eingebauten CPLDs, damit konnte man sich 
neue Schnittstellen(TWI, SPI, ADC usw) oder weitere 
Schnittstellen(weitere Timer) erstellen. Mit denen konnte ich damals den 
Unterschied sehr gut lernen.

Rufus Τ. Firefly schrieb:
> Das ist drollig.
>
> Weder "u" noch "y", sondern µ. Auf deutschen PC-Tastaturen mit AltGr+M
> erreichbar.

Danke - das µ kannte ich, auch das µF aber dass der so einfach auf der 
Tastatur geht noch nicht.

rgds

rtfm schrieb im Beitrag #4082583:
> Operationsverstärker --> Transistor --> yController --> Arduino --> FPGA

Beiträge wie dieser ärgern mich.

ich gehe - als anständiger Mensch - erst mal davon aus, daß hier nicht 
getrollt wird, sondern jemand tatsächlich ein Anliegen hat und deshalb 
auch ernstgemeinten Rat verdient hat.


Also:

Anfänger 91 schrieb:
> Ich stehe gerade nämlich auf dem Schlauch und würde gerne erfahren wo
> denn der praktische Unterschied in der Programmierung von
> Mikrocontrollern und in der Programmierung von FPGAs liegt?

OK, FPGA und µC sind beides Chips, zumeist aus Silizium und mit 
digitaler Logik versehen.

Es gibt aber einen grundsätzlichen Unterschied:

Das, was man beim µC als Programmieren versteht, ist das Aufschreiben 
von Befehlsfolgen, die der µC im Prinzip nacheinander ausführt. Also 
Befehl lesen, dekodieren, ausführen. Dann den nächsten Befehl.. So ein 
µC versteht kein Pascal, kein C, kein Assembler - sondern NUR 
Maschinencode. Also ist zum Übersetzen der genannten Programmiersprachen 
(ja, Assembler ist AUCH NUR eine Programmiersprache) ein 
Übersetzungsprogramm nötig. Nennt man Compiler oder Assembler, 
wenngleich auch letzteres gelegentlich mißverstanden wird.

Das was man beim Programmieren eines FPGA's (ja , man kann das auch so 
nennen) tut, besteht darin, zu beschreiben, wie die auf dem Chip 
vorhandenen Elemente (Gatter, Flipflops und solch Geprassel..) 
miteinander zusammengeschaltet werden sollen, um damit eine solche 
Schaltung zu ergeben, die man haben will.

Ganz klar: Auf dem FPGA geht es hauptsächlich parallel zu und das ist 
der Unterschied zum µC, wo es hauprsächlich sequentiell zugeht.

Klaro?

W.S.

Anfänger 91 schrieb:

> Ich stehe gerade nämlich auf dem Schlauch und würde gerne erfahren wo
> denn der praktische Unterschied in der Programmierung von
> Mikrocontrollern und in der Programmierung von FPGAs liegt?

Vergiß den Vergleich, das verwirrt nur. Microcontrollerprogrammierung in 
Hochsprache und das Erstellen eines FPGA-Designs in VHDL/Verilog habe 
bis auf die textuelle Eingabe nichts gemeinsam.

Bei FPGA-designs geht es letzlich um Datenflüße (Blockdiagramme) wie bei 
Labview und nicht um Programmabläufe wie bei C oder gar 
Objektorientierung wie bei C++. Wenn überhaupt dann kann man vielleicht 
eine RTL (register-transfer-level) Beschreibung in VHDL noch mit 
(RISC)-Assembler oder microcode-architektur vergleichen,
aber das ist eher akademischer Natur und Du fragtest nach praktischen 
Unterschieden.

MfG,

Vielen Dank für eure bisherigen Beiträge und vielen Dank für die sehr 
verständliche Formulierung!

Ich fasse zusammen, dass ein µC (danke für den Tastatur Hinweis ;) ) 
sequentiell arbeitet, die Programmierung hauptsächlich in einer 
Hochsprache wie C++ erfolgt, diese von einem Compiler übersetzt und auf 
den Chip geladen werden.
Ein FPGA ist schaltungsgesteuert und arbeitet Befehle parallel ab.

Was mich noch verwirrt ist der Anwendungsbereich. Es heißt immer, 
theoretisch kann man für alle Anwendungen sowohl einen µC als auch einen 
FPGA nehmen. In der Industrie muss es doch klare Unterschiede geben, 
wann ich mich für was entscheide. Spielen da Kosten bspw. einen Grund? 
Der Vorteil von der Schnelligkeit bei FPGAs ist mir noch nicht bewusst, 
zumindest anwendungsbezogen. Heutzutage sind doch unzählige µCs auf dem 
Markt in verschiedenster Wortbreite und mit unterschiedlich hoher 
Taktrate. Bei welcher Anwendung würde ich bspw. als erste Wahl sofort 
einen FPGA zur Hand nehmen?


Michael Köhler schrieb:
> Meiner Meinung nach sind FPGAs komplexer zu programmieren als µCs, dafür
> aber sind FPGAs flexibler zu programmieren als µCs.

Meintest du mit komplexer "komplizierter"? Wenn ich mir als Laie bspw. 
LabView anschaue, bei der mit einer grafischen Oberfläche die 
Logikfunktionen "gemalt" werden, die der FPGA umsetzt und dann einen 
komplexen C++ Quellcode als Vergleich, dann empfinde ich das klassische 
Programmieren als komplizierter.

Anfänger 91 schrieb:
> Was mich noch verwirrt ist der Anwendungsbereich. Es heißt immer,
> theoretisch kann man für alle Anwendungen sowohl einen µC als auch einen
> FPGA nehmen. In der Industrie muss es doch klare Unterschiede geben,
> wann ich mich für was entscheide. Spielen da Kosten bspw. einen Grund?

Definitiv.
1. Ein FPGA kostet viel Geld (erst ab 20€ für Kleinstmodelle bis hin zu 
25k€ bei Highend).
2. Ein FPGA kommt nie alleine. Die Konfiguration muss man einem FPGA 
immer irgendwie einspielen. Bei jedem PowerUp. Dazu braucht man externen 
Flash, EEPROM, irgend einen nicht flüchtigen Speicher. Es gibt welche 
mit integriertem Speicher, kosten entsprechend gleich das Doppelte.

> Der Vorteil von der Schnelligkeit bei FPGAs ist mir noch nicht bewusst,
> zumindest anwendungsbezogen. Heutzutage sind doch unzählige µCs auf dem
> Markt in verschiedenster Wortbreite und mit unterschiedlich hoher
> Taktrate. Bei welcher Anwendung würde ich bspw. als erste Wahl sofort
> einen FPGA zur Hand nehmen?

Überall wo hohe Datenraten oder Geschwindigkeiten erforderlich sind. Ich 
nehme mal Mikrocontroller mal beim Wort und sage einen High End 
Controller wie einen STM32F4 bei 168 MHz. Mehr als 8 MB/s an Daten 
schaufelst du da trotz DMA und größten Kopfständen nicht durch. Von 
Verarbeitung / Bearbeitung ganz zu schweigen, nur kopieren. 100 MBit 
Ethernet bekommst du mit einem solchen Geschoss von Mikrocontroller 
nicht ausgelastet.

So jetzt sage ich mal ich habe ein Oszilloskop und möchte eine 
Bandbreite von 100 MHz haben. Das bedeutet, ich brauche einen ADC der 
mit mindestens 200 MHz = 200 MSPS abtastet. Datenaufkommen 200 MSPS a 8 
Bt = 200 MB/s. Dann muss ich diese Daten puffern, verarbeiten, 
interpretieren und darstellen. Oder HDMI 1.3: 18 Gigabit pro Sekunde = 
2,25 GB/s !!!

> Ein FPGA ist schaltungsgesteuert und arbeitet Befehle parallel ab.
Ein FPGA ist eine Schaltung von LUTs und FlipFlops, es werden KEINE 
Befehle abgearbeitet. Man könnte aber aus den FlipFlops und den LUTs 
irgendetwas CPU ähliches verdrahten, was Befehle abarbeitet.

Peter schrieb:
> Definitiv. 1. Ein FPGA kostet viel Geld (erst ab 20€ für Kleinstmodelle
> bis hin zu 25k€ bei Highend).

Actel ProASIC3?

FPGA und Prozessoren kann man nicht sio einfach vergleichen, da sie sich 
auf ganz unterschiedlichen Ebenen bewegen.

Ein FPGA erlaubt es Dir, innerhalb des FPGAs eine Schaltung (Hardware) 
zu "bauen". Du hast dort kein Programm, das abgearbeitet wird, sondern 
Du hast tatsächlich eine Schaltung (echte Hardware). Du kannst Dir ein 
FPGA stark vereinfacht wie eine gigantische Menge an Schaltern 
vorstellen, mit denen eine gigantische Menge an kleinen 
Hardware-Einheiten zusammengeschaltet werden: Die Stellung der Schalter 
bestimmt die Funktion der Schaltung.

Ein Prozessor ist hingegen eine sehr spezielle, festverdrahtete 
Schaltung auf der man ein flexibles Programm (Software) ablaufen lassen 
kann. Anders als beim FPGA wird bei einem Prozessor niemals die 
Schaltung (Hardware) geändert. Da die Schaltung fest steht, kann man den 
Chip optimal gestalten und damit sehr hohe Taktraten und Packungsdichten 
erreichen.

Da ein Prozessor aus einer festgelegten Hardware besteht, kann man einen 
Prozessor mit einem (geeigneten) FPGA realisieren. D.h. man legt die 
Schaltung im FPGA so fest, dass sich daraus der Prozessor ergibt. 
Alternativ hätte man den Prozessor auch aus einzelnen Transistoren löten 
können.

Ok jetzt mal eine "brainfuck" Frage :)
Wenn sich aus einem FPGA ein Prozessor realisieren lassen kann, wieso 
kann ich dann im Nachhinein kein Programm darauf laufen lassen?

Anfänger 91 schrieb:
> Ok jetzt mal eine "brainfuck" Frage :)
> Wenn sich aus einem FPGA ein Prozessor realisieren lassen kann, wieso
> kann ich dann im Nachhinein kein Programm darauf laufen lassen?

Kannst Du doch!
Dir muß nur klar sein, dass das Programm im Prozessor läuft, den Du im 
FPGA beschrieben hast.

> Wenn sich aus einem FPGA ein Prozessor realisieren lassen kann, wieso
> kann ich dann im Nachhinein kein Programm darauf laufen lassen?
Kann man schon, aber den programmiert man dann in Assembler oder C usw.
Mit VHDL beschreibt man wie der Prozessor Funktionieren bzw. gebaut 
werden soll.

Danke! So langsam sehe ich Licht am Ende des Tunnels :)

Es ist leider etwas verwirrend, dass man von "programmierbarer Logik" 
spricht.

"Programmieren" bezeichnet bei PAL, CPLD und FPGA den Vorgang, bei dem 
die Schaltungsbeschreibung in den Baustein hinein getan wird (im Sinne 
von "ein EPROM programmieren"). Programmierbare Logik bezeichnet 
Hardware, die nicht fest verdrahtet ist, sondern sich flexibel 
umkonfigurieren läßt. Bei FPGAs spicht wird daher der 
"Programmier"-Vorgang korrekterweise als "Konfiguration" bezeichnet.

Dies ist aber nicht mit einem "Programm" im Sinne von sequentiell 
abgearbeiteter Software zu verwechseln, wie es auf dem PC läuft (im 
Sinne von "ein BASIC-Program programmieren").