www.mikrocontroller.net

Forum: FPGA, VHDL & Co. FPGA contra Mikrocontroller


Autor: Mikest (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
ich habe mich jetzt einige Zeit mit FPGA befasst und einiges mit VHDL
getestet. Was ich allerdings noch nicht so genau durchschaut habe, ist
der Unterschied zwischen einem FPGA und einem Mikrocontroller. (nicht
in der Programmierung, sondern in der Anwendung)
Ich kann ja für beide (FPGA und MC) ein Programm schreiben, welches die
gleiche Funktionalität bietet.
Z.B. wenn ich einen 16-bit A/d-Wandler je nach Schalterstellung auf
einen von 8 D/A-Wandler legen will (und die anderen 7 solange im Wert
halte) und gleichzeitig die Werte auf einem LCD-Display anzeigen will,
dann kann ich das mit FPGA und MC realisieren......
Ist der eigentliche Unterschied, daß der FPGA schnelle komplexe
logische Verküpfungen realisieren kann, für die der MC/CPU zu langsam
ist, allerdings wenn die Geschwindigkeit kein entscheidender Faktor
ist, beides gleichwertig eingesetzt werden kann?

Gruß
Micha

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich würde grundsätzlich alles was in einem Controller geht in einem
Controller machen. Wenn die Geschwindigkeit oder besondere Funktionen
nicht entscheidendend sind, dann wird das FPGA immer den kürzeren
ziehen (Kosten, Stromverbrauch, Platzbedarf, Entwicklungsaufwand).

Autor: Daniel R. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Prinzipiell kann man für alle Aufgaben beides verwenden, außer es kommt
auf Geschwindigkeit usw. an. Dann FPGA.
Aber es gibt auch Dinge, die nicht zu einem FPGA passen(z.B.HD44780 LCD
ansteuern) und es gibt Dinge, die nicht zu einem uC passen(z.B.128Bit
Multiplikationen usw.).

Das Entscheinende ist immer die entsprechende Situation.


Daniel

Autor: Feadi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>...die nicht zu einem FPGA
>passen(z.B.HD44780 LCD ansteuern)...

Sicher?

Schonmal das gelesen?
http://de.wikipedia.org/wiki/Automat_%28Informatik%29

Mit einer Statemachine ist es sehr einfach ein Display anzusteuern.

>...die nicht zu einem uC
>passen(z.B.128Bit Multiplikationen...

http://de.wikipedia.org/wiki/Dualsystem#Schriftlic...
Damit kann auch ein µC 128bit Multiplikationen machen. (Achtung: nicht
sooo überaus schnell)

Feadi

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich glaube "passen" steht hier eher für "angemessen sein".

Autor: T.M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Für den HD44780 hab ich auch mal nen VHDL-Design gemacht. Waren 3 durch
Steuersignale verbundene Statemachines.
Jeweils eine für Initialisierung, Zeilenwechsel und Zeichen schreiben.
Das Aufwendigere war dann eher, aus einem Vektor von Bits den
dazugehörigen ASCII-Code für den Displaycontroller zu erstellen.
Insgesamt is da aber ni viel dran.
Aber als einzige Aufgabe wäre dafür ein FPGA natürlich Verschwendung.

Autor: FPGAküchle (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
FPGA/CPLD sind halt gut für schnelle und breite Interface, halt
Gluelogic. 100 I/O PIns wirds an einem Mikrocontroller nicht geben.
Oder Echtzeit(Video/DSP) Anwendungen, eben wo es auf parallele
Abarbeitung abkommt. Bitmanupulationen in einen Stream (CRC,krypto)
sind auch eher für programmierbare Logic. Mikcocontroller und CPU egnen
sich eher für lange (viel verzweigte) Steuerungsaufgaben wo minimale
Latenz nicht erforderlich ist.

Autor: peter dannegger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Ich kann ja für beide (FPGA und MC) ein Programm schreiben, welches
die gleiche Funktionalität bietet."


Aber nur rein theoretisch !

Mit MCs kann man wesentlich komplexere Programme realisieren.

Z.B. ist eine Uhr mit DCF77-Synchronisation für jeden MC ein Klacks und
paßt bequem in einen ATTiny12 (8-Pinner).
Das gleiche mit FPGAs braucht dagegen schon einen Monster-FPGA mit
vielen tausend Gattern.

FPGAs sind nur sinnvoll, wo es auf die Geschwindigkeit (>10MHz) angommt
und die Aufgaben relativ einfach gestrickt sind (Multiplexer, Register,
Zähler, Dekoder usw.).


Man kann natürlich in einen FPGA einen MC-Core reinbraten, also von
hinten durch die Brust ins Auge.


Peter

Autor: FPGAküchle (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
#Z.B. ist eine Uhr mit DCF77-Synchronisation für jeden MC ein Klacks
#und
#paßt bequem in einen ATTiny12 (8-Pinner).
#Das gleiche mit FPGAs braucht dagegen schon einen Monster-FPGA mit
#vielen tausend Gattern.

Das stimmt so nicht. Früher wurde sowas diskret als 74TTL-Grab gebaut,
das passt locker in den kleinsten FPGA (ohne uc-Core).

Autor: peter dannegger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stimmt, war ein blödes Beispiel, ist ja nur ein großes Schieberegister
und ein paar Zähler.

Aber zumindest ist der kleinste FPGA teurer und größer (kein
8-Pinner).
Gibt es überhaupt FPGAs im DIP ?


Was mich an FPGAs am meisten stört, ist, daß man immer noch nen extra
Konfiguration-EEPROM dranpappen muß und beim Einschalten erst daraus
geladen werden muß, was schon einige Sekunden dauern kann.
Deshalb nehme ich für schnelle Sachen nur CPLDs.


Peter

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
FPGAs und Mikrocontroller haben eigentlich ganz andere Einsatzzwecke
gedacht.
Prozessoren können mit wenig Hardware sehr lange Programme sequentiell
abarbeiten.
Bei einem FPGA dagegen ist die Verarbeitung fast vollständig parallel.
Dadurch sind auch bei niedrigem Takt viele Operationen gleichzeitig
möglich. Beim FPGA muss aber auch für jede Operation ein Stück Hardware
synthetisiert werden. Ein längeres C Programm wird man also in kein FPGA
bekommen, weil da vorher einfach die Gatter ausgehen. Es sei denn, man
baut einen Prozessor im FPGA nach.
Ein im FPGA implementierter Prozessor dürfte allerdings gegenüber einem
für gleichen Preis gekauften Controller meistens langsamer sein, und
weniger Peripherie haben. Dafür kann man sich aber selbst die
Peripheriekomponenten mit auf den Chip designen, die man braucht,
beispielsweise ein Interface für irgendein exotisches Bussystem, oder
irgendwelche Encoder/Decoder, die aus schneller paralleler Logik
bestehen.

Autor: xXx (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Matthias:

Kleines Beispiel:

Ich kaufe einen Controller und takte den mit sagen wir 16 MHz, weil er
nicht mehr kann. Dann nehme ich diese Controller IP (zufällig
Open-Souce;-)), schreibe die in einen FPGA und takte das ganze dann mit
z.B. 100 MHz. Was ist dann schneller?

Autor: xXx (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nachtrag:

Peripherie kann ich auch alles in einem FPGA unterbringen. Sogar die,
welche an einem µC extern angebracht werden muss.

Autor: FPGAküchle (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mikrocontroller werden wg. Preis und Stronverbrauch nicht durch FPGA
ersetzt (vielleicht durch CPLD, aber da steht noch der preis entgegen).
Aber Systeme aus Mikrocontroller und FPGA werden immer mehr
durch FPGA alleine ersetzt. Meistens ist auf dem FPGA noch Platz neben
der eigentlichen (Coprozessor-) Funktion für den uC. Also spart man
sich den zweiten Chip:
- das gesamtdesign (Board) wird kleiner und schneller)
- der Stromverbrauch dürfte Konstant bleiben.
- weniger fehler auf dem board möglich (leiterzüge zw. FPGA und uC
entfallen)
- Kein Xtra quartz für uC nötig
- Synchronisation zw. uC und FPGA entfällt (höherer Durchsatz)

FPGA's gibt es zwar nicht als DIP, ich habe aber schon Dip-Module
gesehen (Platiene mit FPGA+FPGA-Support) mit DIP anschlüssen.

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
xXx:
Natürlich das FPGA. Aber gibt es das im Gegensatz zum Controller in
SO8? :)
Du hast auch ein extrembeispiel gewählt, und ich habe bewusst von einem
gleichen Preis geschrieben.
Nimm mal den Vergleich bei etwa gleich großen und gleich teuren ICs:
Beispielsweise einen der hier geläufigen Arm7 vs. einen Spartan3(E):

Bei der Taktfrequenz könnte man das FPGA vielleicht etwas schneller
bekommen, 100Mhz halte ich bei brauchbarem Design mit ner Menge
Pipelining für realistisch. Den Core kriegt man auch sicher in die
Anzahl der Logikzellen rein. Aber dann noch die gesamte Peripherie mit
verschiedensten Schnittstellenarten, die so ein uC bietet? Ich behaupte
mal da gehen vorher sicher die Logikzellen aus. Du schreibst ja man
kriegt die Peripherie mit drauf, und ich sage dazu: Man hat eben den
Vorteil, dass man genau die Peripherie draufkriegt, die man auch
braucht. Aber sicher nicht viel mehr.
Ram bietet das FPGA auch nicht umbedingt mehr, ich zähle hier ca.
24kbyte in Blockram bei meinem Spartan3E. Von integriertem Flash mal
ganz zu schweigen.

Ob dann ein Spartan3 oder ein Arm7 Controller besser geeignet ist,
hängt eben ganz davon ab, was man machen will.
Ich arbeite hier mit einem Spartan3E, es geht um einen transceiver für
ein vollsynchrones Bussystem bei ca. 50Mbit. Das ist einfach mit einem
µC nicht realisierbar. Genausowenig ist digitale Signalverareitung bei
> 100Mhz mit einem µC möglich, der Spartan schafft das aber durch seine
vielen Hardwaremultiplizierer.
Aber für andere Aufgaben ist auch sicherlich ein µC die sinnvollere
Alternative.

Autor: Martin Maisch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also, ich würde nicht sagen, dass die Preis/Leistung bei einem
Mikrocontroller umbedingt besser ist. Wenn man sich z.B. auf
http://www.asics.ws/ den "Pic Clone Core" bei den freien Cores
anschaut, der bei 80 Mhz die gleiche Performance wie ein 320Mhz Pic
bringt und dann sieht, dass dies mit einem Spartan 2 möglich ist, der
nicht so teuer sein sollte, dannn glaub ich kaum, dass da ein Pic das
bessere Preis/Leitungs Verhältnis hat. Wenn man bedenkt, dass nur 30%
der Chipfläche benötigt werden, hat man ja noch ordentlich
Spielraum....

Gruß Martin

Autor: Jens (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und wenn man aber mit der Leistung eines normalen PIC zufrieden ist und
dann mal den Preis mit dem eines FPGA's vergleicht... Von der
einfacheren Anwendung (z.B. kein externer Speicher notwendig) mal
abgesehen. Es gibt viele Dinge wo in naechster Zeit FPGAs Controller
ersetzen, aber es gibt halt auch viele Situationen wo ein Controller
einfach besser passt.

Autor: Martin Maisch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vor allem, wenn man bedenkt, dass z.B. ein Spartan3 mit 200k Gates, in
den dieser Core locker passen sollte schon für 15€ zu haben ist und ein
Pic, der vielleicht 1/32 der Performance bringt bei 3 bis 4€ liegt!

Gruß Martin

Autor: Jens (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kann ich die Quelle fuer einen Spartan 3 mit 200k-Gates fuer 15 Euro
erfahren?

Autor: Martin Maisch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sorry, da war ich zu schnell! Hab im Online Shop von Xilinx geschaut,
aber das sind ja Dollar Preise. Aber viel teurer dürfte der hier ja
eigentlich auch nicht sein, oder?

Gruß Martin

Autor: FPGAküchle (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
#Vor allem, wenn man bedenkt, dass z.B. ein Spartan3 mit 200k Gates, in
#den dieser Core locker passen sollte schon für 15€ zu haben ist und
ein
#Pic, der vielleicht 1/32 der Performance bringt bei 3 bis 4€ liegt!

Hm, Du musst aber (Mindestens) noch die Kosten fürs EEPROM und die
anspruchsvoller Stromversorgung sowie die höheren Platienenkosten auf
den FPGA-Preis draufschlagen.

Allerdings kannst du jede Menge debuglogik dazubauen, also PIC auf FPGA
ist eher mit einen PIC Emulator/Debugger zu vergleichen. Auch nicht zu
verachten.

Autor: Martin Maisch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, aber die Performance des FPGA ist um einiges hoher und umsonst
bekommt man die Platine für den PIC auch nicht. AUßerdem kann man bei
einem FPGA noch andere Dinge mit "einimplementieren", was bei einem
PIC auch wieder mit kosten verbunden wäre...
Die Möglichkeit den Pic an seine Bedürfnisse anzupassen oder neue
Befehle hinzuzufügen sollte man denke ich auch nicht unterschärtzen.

Das FPGA System wäre deutlich teurer, da führt kein Weg dran vorbei,
aber Preis/Leitung glaube ich, dass der FPGA deutlich überlegen ist,
aber vielleicht täusch ich mich auch!

Gruß Martin

Autor: Jens (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn es wirklich auf viel Rechen-/Verarbeitungsleistung ankommt ist ein
FPGA im Vorteil weil man ihn nunmal an die speziellen Anforderungen
anpassen kann. Der Controller ist ein guenstiger Kompromiss, der in
Standardsituationen oder auch wenn eine hoehere Abstraktion notwendig
ist besser abschneidet. Als Beispiel faellt mir da spontan ein IP-Stack
ein, sowas gibts sogar fuer 8-Bit Controller. Die Implementierung in
einen FPGA waere da ungleich aufwaendiger.

Autor: Xenu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Vor allem, wenn man bedenkt, dass z.B. ein Spartan3 mit 200k Gates, >in
den dieser Core locker passen sollte schon für 15€ zu haben ist >und ein
Pic, der vielleicht 1/32 der Performance bringt bei 3 bis 4€ >liegt!

Was Du nicht bedenkst ist, dass der PIC-Kern von dem Du hier sprichst
einen PIC 16C57 nachbildet, und der ist total veraltet und kann fast
nichts. Du musst FPGAs mit den Controllern vergleichen, die heute
Stand der Technik sind.

Wenn ich mir heute eine 8-Bit-Controller für 2-4 Euro kaufe, dann mit
Sicherheit nicht einen 16C57, sondern z.B. einen ATMega8.
Der hat z.B. einen AD-Wandler, sowas gibt es bei FPGAs nicht
integriert. Selbst wenn Du nur den digitalen Teil nachbilden willst,
wirst Du wesentlich mehr Resourcen verbrauchen als mit dem windigen
PIC-Kern.

Und den Stromverbrauch eines FPGA solltest Du Dir auch noch mal
ansehen...

Autor: MasterBlaster (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Auweia, jetzt gibts Krieg. Da könnten die FPGAler im Vorteil
sein, so ein BG560 METAL BGA mit 42 x 42 mm schlägt ganz
schön ein ;-)))

Autor: FPGAküchle (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
#Wenn ich mir heute eine 8-Bit-Controller für 2-4 Euro kaufe, dann mit
#Sicherheit nicht einen 16C57, sondern z.B. einen ATMega8.
#Der hat z.B. einen AD-Wandler, sowas gibt es bei FPGAs nicht
#integriert. Selbst wenn Du nur den digitalen Teil nachbilden willst,
#wirst Du wesentlich mehr Resourcen verbrauchen als mit dem windigen
#PIC-Kern.

Picoblaze:   (8bit core)                  96 slices
Microblaze: (32bit Core) 1318 LUTS   (ca 660 Slices)
Spartan3-200: (kleiner LowCostFPGA) ca. 1800 Slices

Selbst moderne uC-Cores passen locker in die kleinen FPGA's der
LowCost Serie. Und laufen dort mit 100 MHz. Das einzige Probleme ist
der programmspeicher, den sollte man extern halten.

Autor: peter dannegger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich bleibe dabei, wenns vom Timing her ausreicht (und das tut es zu
99,99%), dann nehme ich natürlich nen MC, keine Frage. Ansonsten nehme
ich noch nen CPLD dazu für die eiligen Sachen.


Es ist außerdem ein riesen Unterschied, ob ich nen MC in 10min auf ner
Rasterkarte zusammengestöpselt habe oder ob ich erst eine richtige
Platine fertigen und mit so einem TQFP-Monster bestücken lassen muß.


Es entwickelt sich einfach viel einfacher und schneller mit nem MC.


Peter

Autor: hans dieter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ok, speicher extern halten, dann kannste in deinen fpga noch schön einen
chache einbauen, damit das ding auch die leistung schafft, die der
mikrocontroller hätte.

ACHSO: man sollte bei Prozessor/Technologie-vergleichen immer die selbe
Basis-Frequenz verwenden. WEnn ich meinen alten P2 mit den richtigen
Microcodes ausstatte und den mit 15GHz laufen lassen könnte, dann würde
der auch schneller sein als ein jetziger P4 oder Sempron oder wie der
scheiss jetzt heisst...

Autor: Xenu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Picoblaze:   (8bit core)                  96 slices
>Microblaze: (32bit Core) 1318 LUTS   (ca 660 Slices)
>Spartan3-200: (kleiner LowCostFPGA) ca. 1800 Slices
>
>Selbst moderne uC-Cores passen locker in die kleinen FPGA's der
>LowCost Serie. Und laufen dort mit 100 MHz. Das einzige Probleme ist
>der programmspeicher, den sollte man extern halten.

Nicht das wir uns hier falsch verstehen: Ich habe weder was gegen FPGAs
noch gegen Mikrocontrollerkerne, ganz im Gegenteil.

Aber die Behauptung, das ein FPGA, der rein als µC eingesetzt wird,
ein besseres Preis/Leistungsverhältnis besitzt als ein "richtiger"
µC, ist schlicht und ergreifend falsch - leider.

Wenn dem so wäre, warum benutzen dann Handyhersteller ARM-Prozessoren
und keinen Microblaze? FPGAs sind in den Handytürmen, nicht in den
Handys.

Das FPGAs für den Konsumartikelmarkt interessant sind, höre ich immer
nur aus Werbeankündigungen der Hersteller.

Autor: FPGAküchle (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
#Das FPGAs für den Konsumartikelmarkt interessant sind, höre ich immer
#nur aus Werbeankündigungen der Hersteller.

Also für mobile geräte fressen FPGA's zuviel strom, in
anspruchsvollen
Konsumgeräten in mittleren Stückzahlen (100k) im Nichtakkubetrieb
findet man immer öfters FPGA's. Z.B. Autoradios mit Navis.

Xilinx hat von 98 bis Mai/05 mehr als 100 Mio Spartan-FPGA's
vertickert. Die stecken bestimmt nicht nur in den Basestations und
Diplomarbeiten.

Aber bis die Milliardenzahlen von uC's erreicht werden, wirds noch ne
Weile dauern.

Autor: hans dieter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Aber bis die Milliardenzahlen von uC's erreicht werden, wirds noch ne
>Weile dauern.

Dann muss der Stromverbrauch aber trastisch sinken, oder kannst du mir
einen fpga mit einem durchschnittlichen stromverbrauch von unter 1 mA
(im uneingeschränkten Betrieb in der Anwendung) zeigen?
Durch extreme Stromsparmassnamen gibt es sogar welche, die nur ein paar
µA brauchen - die laufen dann ca. 5 Jahre mit einer Lithium Zelle
... Dass die dann aber keine CRCs und MD5s am laufenden Band berechnen
versteht sich...

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich denke in Zukunft wird das Zielgebiet für FPGAs und Microcontroller
immer näher zusammen rücken. Sicherlich hat jeder seine klassischen
Gebiete, wo er einfach Vorteile hat. Aber immer häufiger wird man sich
fragen müssen, nimm ich jetzt ein Microcontroller oder doch lieber ein
FPGA.

Schaut euch doch zum Beispiel mal den Spartan 3E und Spartan 3L an, ich
denke, der Trend geht ganz eindeutig in diese Richtung.

Gruß
Michael

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@FPGAküchle:
Ein "moderner MC" besteht ja nicht nur aus einem Core. Wir setzen
hier z.B. den M32192 von Renesas ein. Der hat 1MByte Flash und 176KByte
RAM. Der kleinste Spartan3 mit >= 176KByte RAM ist der Spartan3-4000 ...

Autor: axel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also ich arbeite auch gern mit den FPGA´s. Die Vorteile eines µC liegen
in meinen ganz einfach in der einfachen Anwendung (Gehäuseform etc),
und der A/D Wandler ist auch nicht zu verachten. Ausserdem ist ein µC
in sachen Spannungsversorgung nicht so zimperlich wie ein FPGA.
Hinzu kommt jedoch, das der Umstieg von µC - Softwareprogrammierung zur
Hardwarepriogrammierung sehr viel Umdenken voraussetzt. Das ist bestimmt
eine Hürde die auch viele scheuen. Hobbybastler werden bestimmt nicht so
schnell von der FPGA-Technik zu überzeugen sein. Ich dneke das beide
ihre volle daseinsberechtigung haben und auch in Zukunft haben werden.
Da musste ich jetzt auch mal meinen Senf zu abgeben.
Übrigens, die Cebit haben die FPGA´s auch noch nicht richtig erobert...
leider.

Autor: FPGAküchle (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
#Ein "moderner MC" besteht ja nicht nur aus einem Core. Wir setzen
#hier z.B. den M32192 von Renesas ein. Der hat 1MByte Flash und
176KByte
#RAM. Der kleinste Spartan3 mit >= 176KByte RAM ist der Spartan3-4000
...

Ju kenn ich die SH-Boliden, eigentlich ist mikrocontroller eine glatte
Untertreibung.
Wenn ich recht überlege, war es meistens ein SH3/4 (jetzt
Renesas)-Controller an den ich einen FPGA anzuschliessen hatte.

Recht betrachtet würde die Luft für Controller enger wenn die FPGA's
ordentlich
RAM mitbringen würden. Warum eigentlich nicht, der FPGA ist ja
technologisch gesehen SRAM?!. Aber uC-Cores auf FPGA ist ne recht neue
Geschichte
(5Jahre vielleicht) und der RAM auf den FPGA's ist eben für TeleKom
designed
(Fifos, Zwischenspeicher für ein DatenFrame,Registerbank,...).

Am EEPROM arbeitet Xilinx wohl, soll wohl ein Xtra EEPROM/Flash-Die mit
unters Gehäuse kommen.

Aber das Hauptproblem ist wohl die Spezialisierung der Angestellten. So
ein
uC FPGA würde einen Hard-und Software Spezialisten verlangen. Oder
produktive Kommunikation zw. Hard- und Softwerkern. Also schwört der
Informatiker auf pflegeleichte Software aud dem uController und der
E-Techniker auf optimierte Anwendugsspezifische Hardware.

Autor: Markus K. (markus-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Wenn ich recht überlege, war es meistens ein SH3/4 (jetzt
> Renesas)-Controller an den ich einen FPGA anzuschliessen hatte.

Ein FPGA ist auf unserer Schaltung auch drauf. Da wäre es natürlich
naheliegend gewesen, den MC wegzuwerfen und stattdessen einen größeren
FPGA zu nehmen. Aber das geht nicht. Nicht nur wegen des RAMs, sondern
auch wegen der CAN-Controller. Man darf wohl die CAN-Controller nicht
im FPGA haben (mangelnde Zertifizierung oder so).

> Aber das Hauptproblem ist wohl die Spezialisierung der Angestellten.

Die meisten Leute können VHDL eher so am Rande. Aber das ist wohl eher
eine Frage von Angebot und Nachfrage. Bei uns werden auch die
Mikrocontroller weitgehend von Elektronikern programmiert.

Autor: FPGAküchle (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
#Aber das geht nicht. Nicht nur wegen des RAMs, sondern
#auch wegen der CAN-Controller. Man darf wohl die CAN-Controller nicht
#im FPGA haben (mangelnde Zertifizierung oder so).

Oh das ist mir neu, wobei ich an Zertifizierung nicht glauben mag. Ein
Bekannter hat mal einen CAN-Controller geschrieben und ihn dann mit
einer Testbench von B*sch überprüft. Ob das nur eine
Verifikations-Testbench oder eine Quakifizierungstestbench war ist mir
nicht bekannt. Auch Xilinx hat einen CAN-IP im Angebot oder gabst nicht
irgendwo (Altera?) einen HardCore-CAN?

Aber vielleicht liegt das Problem eher an der Zuverlässigkeit. Im
Automobil gibts ja Bereiche die nie ausfallen dürfen, CAN ist wohl ein
Teil davon. Und ein FPGA mit z.B. seiner langen Boot-phase (Laden des
Konfigurationsbitstreams) wiederspricht vielleicht diesem Konzept.
Fällt dieser aus liegt vielleicht der gesamte CAN lahm. Dunkel
enrinnere ich mich an einen anderen Controller dessen Nichtentschwinden
in den FPGA mit seiner Aufgabe als CAN Gateway begründet wurde. Wobei
ich da noch an den PHY-layer dachte, also etwas was wegen der Pegel
nicht in den FPGA passt.

Also hätten wir vielleicht noch zwei Argumente für Mikrocontroller,
deren höhere Zuverlässigkeit und schnelle Startup-Zeiten.

Autor: axel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Im bezug auf die Startzeit: Gibt es da nicht schon FPGA´s die den Flash
inklusive haben? Dann müsste die Bootzeit doch auch erheblich reduziert
werden. Oder bin ich da falsch informiert?

Autor: FPGAküchle (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hm, was du meinst sind Flash basierte CPLD/FPGA:

Also bei Xilinx und Altera sinds SRAM basierende FPGA, also beim
Konfigurieren werden SRAM's Zellen beschrieben die dann "Weichen"
(Muxer) stellen, sodas das Routing der geforderten Funktion entspricht.
Die log. Verknüpfungen werden durch LookUp Tables realisiert, die
ebenfalls aus SRAM-Zellen bestehen.

Bei den Flash basierenden gibt es diese SRAM-Zellen nicht, es sind
Flash-Zellen. Damit geht der Inhalt (die Konfiguration) nicht verloren)
und nach PowerUp kanns gleich losgehen.

Allerdings ist Flash eine andere Fertigungstechnologie. Flashzellen
sind größer und langsamer als SRAM (was aber auch daranliegt das die
Fab's zuerst für SRAM/SDRAM modernisiert werden) und Flash basierende
FPGA's damit langsam (geschätzt 10 MHz) sind und wenig ressourcen
(geschatzt 10 - 50k Gatter) haben. Und sind teuer (da wenig gefragt und
hergestellt).

SRAM basierende FPGA's mit Konfigurations Flash im selben Gehäuse
lösen das Problem nicht prinzipiell, da immer noch nach dem PowerUp die
SRAM-Zellen beschrieben werden müssen.

Daneben gibt es noch die AntiFuse FPGA's (Actel?) die ebenfalls
nichtflüchtig sind.

Autor: FPGAküchle (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nachtrag:
Hab ich mich grad mal bei Lattice semiconductor über den aktuellen
Stand von Flash basierenden FPGA's schlau gemacht. Da hat sich wohl
viel getan hinsichtlich Gatteranzahl und Taktrate, die vorher genannten
10 MHz/50k Gatter stimmen wohl nicht mehr.

Autor: dnb (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ FPGAküchle
ich habe wegen CAN mal eben nachgeschaut was Altera so im Online
IP-MegaStore hat:

C_CAN -- Bosch
   -- http://www.altera.com/products/ip/iup/can/m-bos-c_can.html
CAN -- CAST, Inc
   -- http://www.cast-inc.com/cores/can/cast_can-a.pdf
CAN 2.0 Network Controller -- Mentor Graphics
   -- http://www.altera.com/products/ip/iup/can/m-men-mcan.html
NIOS_CAN -- IFI
   -- http://www.altera.com/products/ip/iup/can/m-ifi-ni...
NIOSII Advanced CAN -- IFI
   -- http://www.altera.com/products/ip/iup/can/m-ifi-can20b.html

Autor: T.M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Aber wieso sollte ich denn einen FPGA nehmen, in den ich erstens einen
Prozessor und zweitens noch den CAN Knoten implementieren muss, wenn es
MC gibt, die schon beides integriert haben?
Ausserdem muss man beachten, bei einem FPGA fällt doppelte
Entwicklungsarbeit an: VHDL Code und der integrierte Prozessor muss
dann auch noch programmiert werden. Bei einem MC ist 'nur' letzteres
von Nöten.
Ausserdem sind MCs seit Jahrzehnten eine eingespielte Technik mit der
sich bedeutend mehr Leute auskennen. Wenn ich mir überlege, wie oft man
bei Entwicklung mit FPGAs in die Trickkiste greifen muss, weil gerade
das, was man braucht noch nicht gemacht wurde, oder die Ressourcen
nicht nachvollziehbar oder zu teuer sind....

Für hochvolumige Geräte, die wie der Markt es verlangt, möglichst
spottbillig sein sollen, ist ein MC denke ich meist die erste Wahl.
Zumal Xilinx zB. bei einigen FPGAs sowieso Lieferschwierigkeiten hat.
Bei MCs hat man die unweit größere Auswahl, bei FPGAs kann man sich
zwischen einer Handvoll Herstellern entscheiden...

Achso: Ich arbeite trotzdem gerne mit FPGAs :-)

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da hast du sicherlich recht, die Entwicklung mit einem Microcontroller
ist um einiges einfacher (und damit billiger). aber wenn man dann mal
ein FPGA Design hat, ist es hin zum ASIC auch nciht mehr weit (wenn
denn
sehr große Stückzahlen angestrebt werden)

Autor: FPGAküchle (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
#Aber wieso sollte ich denn einen FPGA nehmen, in den ich erstens einen
#Prozessor und zweitens noch den CAN Knoten implementieren muss, wenn
es
#MC gibt, die schon beides integriert haben?

IMHO sprechen folgende Gründe für eine solche Vorgehensweise:
-Platz (ein Chip statt zwei)
-schnellere Interface zur CPU (Chip intern statt auf dem board)
-Performancereserve, wenn die Rechenleistung des Mikrocontrollers am
Limit ist, kann im FPGA aufgebohrt werden
-Baukastensystem, die CANschnittstelle kann gegen eine andere
ausgetauscht werden
-reserve für Protokollupdates (Standards entwickeln sich, beim
Änderungen im Schnittstellenprotokoll muesste der uC wg. neuen
Interface (z.B CAN) gewechselt werden, hier wird der IP_core des FPGA
gewechselt -> keine neubestückung.
-freie Gestaltung von Hardware debuginteface, z.B. Interruptwächter
(wird die Quelle aktiv lässt der FPGA eine LED blinken)
  -uC-Core bietet den Debugkomfort eines Emulators.
-Hunderte Pins für spätere Schnittstellenerweiterungen
-Speicherbereicherweiterungen (also 256 Kb externen Arbeitsspeicher
statt 128 kB durch simple Änderung am uC-Core möglich

Also eine sehr hohe Integrationsdichte,Skalierbarkeit auf verschiedene
(Hardware-)Umgebungen und verbesserte Zukunftssicherheit sprechen für
den Einsatz von FPGA's statt uC. Falls man aber Produkte entwickelt
die zu einem Stichtag fertig sind, die geforderte Performance sicher
erreichbar und konzeptionel abgesichert ist und zukünftige
Erweiterungen durch (Komplett-) Neu-entwicklung realisierbar sind, dann
ist ein FPGA wenig attraktiv.

FPGA-Designs sind halt sehr flexibel, also das sogenannte elektronische
Langloch. Weiss ich nicht wo die Schraube hinkommt, fräse ich ein
Langloch, ist das Konzept noch am reifen wenn die Hardware schon
gefertigt wird oder soll möglichst viel ohne Umarbeiten weiterverwendet
werden ist FPGA ein Lösung.

Autor: FPGAküchle (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
#bei FPGAs kann man sich
#zwischen einer Handvoll Herstellern entscheiden...

Ist aber eine sehr kleine Hand, die muss nur Altera und Xilinx halten.
Es gibt zwar
noch Lattice, Actel und Cypress aber die spielen in D keine Rolle.

Die Auswahl wird noch kleiner, wenn man den Mehraufwand zum Umschreiben
des Codes für FPGA's verschiedener Hersteller betrachtet. Man verwendet
oft Silizummakros die der andere Hersteller nicht hat oder stimmt sein
Design z.B. auf die Größe der Internen Speicherblöcke ab. Dazu kommt
die Lernkurve um mit den Herstellertools optimal arbeiten zu können.
Und second Source gibt es für FPGA's nicht (manchmal nicht mal einen
zweiten Distri). Bei uC kann ich ja noch auf den 8051-Clone eines
anderen Hersteller wechseln (oder ist das unrealistisch?). C-Source
wird meist portabler geschrieben als VHDL.

Autor: T.M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die oben genannten Vorteile sehe ich ja alle ein, nur ist eben oft der
Preis das Totschlagargument.
FPGA: Kosten für FPGA, CAN-IP, Entwicklung der VHDL & C-Sources
MC:   Kosten für MC, Entwicklung der C-Sourcen
Wenn ein MC die Arbeit verrichten kann dann wird dieser genommen. Und
bei vielen Anwendungen wird auch kein Update gebraucht (zB Sensoren im
Auto mit CAN, um dabei zu bleiben).

Das mit Handvoll sollte eher an einer Hand abzählbar heissen ;-)
Also ich arbeite mit Xilinx, Altera hört man auch ab und an. In der
Hochschule wurde mit Lattice CPLDs gearbeitet....aber das wars am Ende
schon. Die Firmen haben halt so nen großen Technologievorsprung, dass
da auch kaum noch weitere auf den Zug aufspringen werden (können) in
nächster Zeit.

Aber FPGAs fetzen schon. Das oben genannte Preisargument wird sich auch
immer mehr zu Gunsten dieser verschieben, nur im Moment sehe ich das
noch nicht...

Autor: Markus K. (markus-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei der Wahl MC oder FPGA wird die Wahl wohl eher auf den MC fallen,
weil er für die gleiche CPU-Leistung weniger Transistoren braucht und
damit billiger ist.

Ich sehe die FPGAs eigentlich auch eher als Alternative zu den DSPs.

Autor: TobiFlex (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ich fände es sehr schade, wenn ich nur eine Technologie nutzen dürfte.
Die Frage XXX contra YYY stellt sich für mich nicht. Im Gegenteil: Ich
kombiniere sie sogar recht gern :-) Hier ein Beispiel wie sich drei
Technologien vertragen und sogar miteinander spielen:
1. old Style CPU: Z80,
2. MCU: ATMega 162,
3. FPGA EP1K50.
Ich habe mich ja inzwischen dem Retrocomputing verschrieben und dafür
ist das Board eine ideale Plattform.
Der ATMEGA konfiguriert den FPGA und erledigt alle FAT-Zugriffe des
FPGAs auf die SD-Karte. Der Z80 wurde in vielen Homecomputern der
80iger eingesetzt(Amstrad CPCs, Spectrum, ...). Der FPGA übernimmt
Aufgaben wie Bildschirm- und Speichercontroller, Sounderzeugung,
Tastatur, RS232 und was man sonst noch so braucht.
OK inzwischen ist beim Nachfolgeprojekt der Z80 auch in den FPGA
gewandert - aber das nur am Rande.
Also nutzt die Technologien wie sie euch gefallen und vergesst das
Entweder-Oder -Denken.
Viele Grüße
TobiFlex

Autor: FPGAküchle (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
#Bei der Wahl MC oder FPGA wird die Wahl wohl eher auf den MC fallen,
#weil er für die gleiche CPU-Leistung weniger Transistoren braucht und
#damit billiger ist.

Also der Preisvorteil wg. weniger Silizium kommt IMHO nur bei den
Kleinst-uC zum Tragen:
Man rechnet ca 10*Transistorenanzahl für die selbe Funktion im FPGA
gegenüber Full-Custom -IC wie uc. Der Kostenanteil fürs Silizium
schwindet aber mit steigender Pinanzahl, der preis fürs Gehäuse
dominiert. So zahlt man für einen spartan3-200 im 100er gehäuse 15 $,
für das selbe Silizium im 200er 25$. Und die selbe leistung ist auch
relativ.uC werden in "alten" Fabs gefertigt, deren Invest schon lange
abgeschrieben ist, also 400/200 nm Prozesse gegenüber 130/90 nm Prozesse
für FPGA's. Deshalb kommen die kleinen uC auch nicht über 10-20 MHz
Taktung hinaus, während selbst bei den kleinen FPGA's 70-100 MHz
üblich sind.

Aber für eine Waschmaschiene reichen 8bit bei 8 MHz.
Analysiert man die anschliessenden Leistungsbereiche wie 16bit 20-80
MHz
entschwindet der Stückpreisvorteil. Das ist der klassiche DSP-Bereich
und der wird tatsächlich heftig von den FPGA-Herstellern attakiert.

Nur die ganze Diskussion geht um reine uC-Systeme. Bei größeren
Produkten mit etlichen Prozessoren wie im Entertaintment-Bereich siehts
anders aus. Wenn da eh ein FPGA drauf ist wird der früher oder später
den uC schlucken. Das ist billiger, da FPGA's meist größer als
benötigt sind. Die Schrittweite geht bei Spartan3 200-400-1000-1500.
Braucht mal als ca 600K gates muss es ein 1000er sein und es bleibt
platz für mehrere uC-cores.

Autor: FPGAküchle (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
#Die oben genannten Vorteile sehe ich ja alle ein, nur ist eben oft der
#Preis das Totschlagargument.
#FPGA: Kosten für FPGA, CAN-IP, Entwicklung der VHDL & C-Sources
#MC:   Kosten für MC, Entwicklung der C-Sourcen

Präziser: Nicht der (Stück-)Preis ist der Totschlag sondern die
Entwicklungskosten.

Also Produkte wo die Entwicklungskosten 50%(?) des verkaufspreises
ausmachen,werden wohl bei uC's bleiben. Also nicht in dem Bereich wo
der Markt den Preis bestimmt sondern dort  wo der Preis den Markt
dominiert.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Deshalb kommen die kleinen uC auch nicht über 10-20 MHz
Taktung hinaus, während selbst bei den kleinen FPGA's 70-100 MHz
üblich sind."


Ich kann es nicht mehr hören, wie hier ständig auf der Taktfrequenz
rumgeritten wird !

Es ist doch völlig wurscht, wie hoch die ist, sie muß nur ausreichend
sein.


Ich erzähle hier wohl ein absolutes Geheimnis, daß 80% meiner AVRs mit
1MHz takten, obwohl sie 16MHz könnten.
Und trotzdem sind sie warscheinlich noch 90% der Zeit idle.


Ehe hier einer abfällig die Nase über "nur 20MHz" rümpft, sollte er
erstmal gefälligst die Anforderungen besser überlegen.
Dann wird er nähmlich sein blaues Wunder erleben, wie wenig oft schon
ausreicht.


Ich gebe natürlich zu, daß bei gar keiner oder saumäßiger
Programmplanung spielend auch eine 3GHz CPU zum Kollaps gebracht werden
kann.
Ein kleines bischen Gehirnschmalz läßt sich eben nicht durch pure
Rechenpower ersetzen, auch wenn das heutzutage leider oft so suggeriert
wird.


Peter

Autor: Mathias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ peter:

mit der taktfrequenz gebe ich dir völlig recht. ich selbst benötige
auch nur hohe taktfrequenzen bei software pwm oder recht komplizierten
rechenaufgaben!

Autor: Markus K. (markus-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Peter:
> Ich kann es nicht mehr hören, wie hier ständig auf der Taktfrequenz
> rumgeritten wird !

Für eine Applikation, für die ein AVR mit 100kHz ausreicht, wird man
wohl kaum einen FPGA verwenden.

Ich gebe Dir völlig recht, wenn Du behauptest, dass viele Anfänger mit
den Resourcen ihres MCs nicht umgehen können, aber es gibt ja nicht nur
Anfänger. Wir haben z.B. einen Renesas M32192 mit 160MHz und einen
Spartan 3e-250 im Einsatz und beide sind am Anschlag. Und da wir große
Stückzahlen erwarten, wird/wurde da ziemlich an der Algorithmik
rumgefeilt.

Markus

Autor: FPGAküchle (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
#Ehe hier einer abfällig die Nase über "nur 20MHz" rümpft, sollte er
#erstmal gefälligst die Anforderungen besser überlegen.
#Dann wird er nähmlich sein blaues Wunder erleben, wie wenig oft schon
#ausreicht.

IMHO rümpft hier keine die Nase über wenig MHz.Für ein bißchen
tastaturabfrage
und alphanum. Display aktuallisieren wie bei eine Quarzuhr braucht man
keinen FPGA. Für VGA+size Displays, DVD abspielen oder CCD sensor
auslesen schon.
MP3 sowieso, also alles was unter digital livestyle zählt. Und das ist
nun mal die preislich die Masse. Vielleicht auch Stückzahlmäßig. In
meinem haushalt dürften nur die beiden Uhren mit Low_end uC auskommen.
OK vielleicht nhoch die Waschmaschiene (falls das keine schaltuhr
getriebene Steuerung ist. Ach ja die personenwaage vielleicht noch.
Aber Digikam, Diskman,Handy,Monitor,DSL-Büchse, HiFi Anlage und PC
sowieso brauchen mehr als 1 MHz.

Autor: Florian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei FPGA gehts ja wohl um echte harte echtzeit und man verwendet sie
wenn kleine nicht so komplexe aufgaben übernehmen sollen.
gruß
 Florian

Autor: Florian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
z.b. ABS (differenz zwischen Radumdrehungen und Geschwindigkeit zu
gross) Ich könnte mir vorstellen, dass man die Raddrehzahl per zähler
ermittelt der per Taktung gestoppt wird.Dann wird der Wert in ein
Register gelegt und und mit dem vorhergehenden verglichen. Ist die
Differenz zu groß wird über ein Ventil Druck aus dem System abgelassen.
Das ist wahrscheinlich nichts was ein Controller nicht könnte, aber das
schreit doch nach einer Logik.

Autor: Markus K. (markus-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Florian:
Kleine Controller sind aber billiger als kleine FPGAs.

Man nimmt FPGAs nicht nur zum Pin wackeln. Bei uns kommen die Daten mit
60MHz vom A/D-Wandler, der darf sie dann erstmal aufaddieren. Alleine
schon mit diesen 60 Millionen Additionen/s kann man viele
Mikrocontroller vollständig auslasten. Für den FPGA ist das aber kein
Problem und das kostet auch nicht so viele Resourcen. Deswegen darf er
die Daten noch etwas filtern bis er sie zum MC gibt.

Man kann damit aber auch richtig komplexe Sachen machen, wie z.B.
MPEG-Encoder oder eine Grafikkarte.

Markus

Autor: Jens (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was oll diese Diskussion eigentlich bringen? Der eine sieht die uC bald
aussterben weil doch die FPGA's so ziemlich alles besser koennen und
der andere sagt 'jedes da wo es am besten passt'. Ich neige auch eher
zu letzterer Variante weil es nunmal eher selten ist das ich Leistung am
Anschlag brauche und die Zeit zwischen Problem und Loesung ist nunmal
auch ein wichtiges Kriterium. Die Frage waere also zunaechst erstmal
'Was sind verbreitete Anwendungen und was sind die Anforderungen an
das Produkt UND die Entwicklung?'. Auch wenn es langsam die gaengige
Denke zu sein scheint, nicht immer zaehlt 'so viel Leistung/MHz wie
moeglich fuer so wenig Geld wie moeglich'.

Jens

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute!

@Peter Dannegger
#Ich gebe natürlich zu, daß bei gar keiner oder saumäßiger
#Programmplanung spielend auch eine 3GHz CPU zum Kollaps gebracht
#werden kann.
#Ein kleines bischen Gehirnschmalz läßt sich eben nicht durch pure
#Rechenpower ersetzen, auch wenn das heutzutage leider oft so
#suggeriert wird.

Richtig!
Das beste Beispiel hierfür liefert Microsoft.

Gruß, Martin

PS: Tschuldigung, ich dachte ich muss die ganze Runde mal einbisschen
auflockern.

Autor: Falk S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>>C-Source wird meist portabler geschrieben als VHDL.

also mein Eindruck lag da eher umgekehrt. Wenn eine Hardware im Laufe
der Weiterentwicklungen an ihre Grenzen stöst scheint mir die Migration
von einem FPGA zum nächst größeren einfacher als C-Code auf einen
anderen Microcontroller zu portieren. Ich habe VHDL Code von einem CPLD
auf einen erheblich größeren FPGA portiert und mußte lediglich die Pins
neu zuordnen. Die Optimierung an die zu Grund liegende Logik wird doch
heutzutage in großem Umfang durch die Entwicklungsumgebung übernommen.

Zur Eignung FPGA vs MCU:

Ein FPGA ist mir immer dann sympatisch, wenn viele verschiedene
Aufgaben in Echtzeit realisiert werden müssen. Bei einem
Microcontroller kann man mit Interrupts zwar ne Menge machen, aber ab
einer bestimmten Anzahl von IRs verliehrt man dann leicht den
Überblick. Auf einem FPGA/CPLD kann ich parallele Blöcke anlegen und
muß mir um Wechselwirkungen weitaus weniger Gedanken machen.
Garantierte Antwortzeiten lassen sich somit viel leichter bestimmen.

Gleichzeitiges Ändern von eine großen Anzahl von Ausgangssignalen bzw.
gleichzeitiges Lesen von vielen Eingangssignalen ist zudem bei
Microcontrollern an die Bit-breite der CPU gekoppelt, oder man braucht
noch zusätzliche externe Logik.

Gruß
Falk

Autor: Mario - www.itlinux.de (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ob ein FPGA besser ist oder ein µC kann doch pauschal nicht beantwortet
werden. Es kommt auf die Problemstellung an! Wer Preise und
Taktfrequenzen versucht miteinander zu vergleichen, hat zwar
ideologische Unterschiede ausgemacht - aber noch lange keine
technologischen!

Wie Matthias schon richtig erwähnte, arbeiten µC sequentiell - FPGAs
hingegen - abhängig von ihrer Programmierung - ECHT parallel.
Hinzukommen Eigenschaften wie das Pipelining zur Erhöhung der
Taktfrequenz (die der Entwickler der Schaltung festlegt).

Punkt Entwicklung: Wer heutzutage glaubt, ohne Entwurfswerkzeuge
anspruchsvolle Projekte zu lösen und dabei möglichst effiziente
Codeerstellung zu realisieren, der braucht sich nicht darüber äußern,
wie unschlagbar günstig ein µC gegenüber FPGA ist. Mittels IP
(Intelligent Property) muss niemand einen Bluetooth- Controller oder
einen CAN- Controller selber programmieren - warum das Rad jedes Mal
neu erfinden? Natürlich sind µC für diverse Aufgaben das Non-Plus-Ultra
- es wird niemand ernsthaft auf die Idee kommen, statt eines 2Euro-
Controllers die Kaffeemaschine mit einem FPGA auszurüsten. Es ist in
umfangreichen Projekten zu erkennen, dass die Entwicklungskosten mit
FPGAs deutlich geringer sind als mit µC.

Autor: Hagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich sehe grundsätzlich gesehen garkeinen Unterschied zwischen FPGAs und
ASICs. Das was sie aus unserer Sicht erstmal unterscheidet ist die Art
und Weise wie sie programmiert werden müssen (also nicht die HW Seite
der programmierung sondern die theoretische Basis wie wir sie
programmieren müssen).

Es ist durchaus vorstellbar das:

1.) FPGAs in Massenproduktion preiswerter als ASICs sein könnten
2.) FPGAs in Weiterentwicklung auch FLASH enthalten könnten und im
Stromverbrauch so gut wie ASICs.
3.) FPGAs auch vorgefertigte analoge Elemnte enthalten könnten
4.) ASCIs mit entsprechenden IPs auch so schnell wie FPGAs sein
könnten, siehe DSPs.

Aber das was sie immer unterscheiden wird ist die Programmierung, bzw.
das Denkkonzept während wir die Software erstellen. FPGAs sind dabei
wesentlich mehr an der informationstheoretischen Mathematik orientiert
(Boolsche Algebra zb.), und ASICs werden eher aus einem
ingeneurtechnisch mechanischen Aspekt heraus programmiert.

Eine FPGA Software stellt also immer im gewissen Sinne ein Formel dar,
also so wie eine mathematische Formel der boolschen Algebra.
Die Software eines ASICs ist dagegen eher ein mechanisches Konstrukt,
ein Ablaufplan.

Das erklärt auch warum heutige Programmierer auf ASICs eher logische
Ablaufpläne programmieren, mechanisch starre Konstrukte. Die Fähigkeit
der heutigen Programierer die gleichen Probleme in formale Konstrukte
umzuformulieren ist dabei eher schlecht. Die meisten Programmierer
heutzutage tuen sich schon mit den State Machines schwer, und wenn sie
dann noch hochparallel sind wie in FPGAs ist das formale Verständins
dieser Programmierer an einer Grenze angekommen.

Ich meine also aus eigenen Erfahrungen heraus das die Programmierung
sich zwischen FPGAs und ASICs am meisten unterscheidet.

Gruß Hagen

Autor: T.M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein Asic ist doch aber pro forma schneller als ein FPGA. Oder meinst du
mit Asic Microcontroller? In meinem Verständnis ist ein Asic wie es der
Name schon sagt, ein festverdrahteter Schaltkreis, der auf einen
speziellen Kundenwunsch abgestimmt ist. Und der wird wie ein FPGA
"programmiert" wenn es denn ein digitaler ist.

Autor: Hagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, die Mikrokontroller die du meinst gehören zur Gruppe der ASIC. Sie
sind festverdrahtet. Der Hersteller produziert diesen auf
"Kundenwunsch", auch logisch, denn Intel zb. produziert sein CPUs ja
auch auf "Kundenwunsch". Es ist sogar so das diese ASIC erstmal per
IP Cores auf einem FPGA programmiert werden. Dann testet man sie und
dann kann man die IP Cores auf Grund das sie nur Boolsche Algebra
darstellen 1 zu 1 in logische Gatter mappen. Daraus wird dann die Maske
für die feste Verdrahtung erzeugt.

Ein FPGA kann jede Form der digitalen Logik erzeugen, ergo kann ein
FPGA auch eine ASIC MCU reproduzieren. Es existiert also logisch
funktional gesehen kein Unterschied zwischen beiden.

Aber die Art & Weise wie man diese Teile programieren muß unterscheidet
sich eben. Und das ist ja im grunde auch der Sinn der Übung. Ein ASIC
soll für den Programmierer schon viele Funktionsgruppen hardcoded
übernehmen.

Technisch gesehen kann ein ASIC immer schneller sein als ein FPGA. Das
liegt aber nur daran das die Entwickler eines ASICs die Laufzeiten
innerhalb des Chips besser optimieren können als auf einem FPGA. Dieser
muß immer universell und flexibel bleiben, und das bedeutet auch das die
interne Busorganisation, die Gatterlaufzeiten in einem gewissen Maße
physikalisch begrenzt wird. Diese Grenze wird in einem ASIC kleiner
sein, eben weil man die Gatter physikalisch frei auf dem Siliziumträger
aufbringen kann und somit näher an die physikalischen Grenzen
herankommt. Das führt dann dazu das in einem ASIC die Laufzeiten der
Signale kürzer sein können.

Gruß Hagen

Autor: Marco S. (masterof)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
abo

Autor: T.M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Intel's Prozessoren sind keine Asics im Definitionssinn. Da sie in
Massen für viele Verschiedene Anwender gefertigt werden. Ein Asic wird
von einer Firma für einen Auftraggeber gefertigt. Asics sind meist
nicht frei im Handel, da sie nur für den einen Kunden bestimmt sind.
Stichworrte, die mir da einfallen, wären zB. 'structured asic' (grad
gross im Gespräch) oder die herkömmlichen gate arrays.
Wie gesagt, ich verstehe was völlig anderes unter dem Begriff als du.
Dass ein Asic eine CPU integriert haben kann ist klar, nur ist ein
reiner MC kein Asic in dem Sinne.
Am Ende ist das auch egal. Ist mehr so ne Definitionsfrage...

Autor: FPGAküchle (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
#T.M

#Ein Asic ist doch aber pro forma schneller als ein FPGA.

Nein, ASIC ist nicht intel (grob gesagt). ASIC kann sein:
 -FullCustom: Das silizum ist komplett "handgestrickt" und optimiert
 -semi Costum - GateArray: Im silizum werden Standard-Gates
implementiert, für die verschiedenen Kunden werden dann nur noch Die
 Verdrahtungen (metal-layer) anepasst. Also FPGA-Struktur wo die
Verbindungen nicht programmiert sondern gebrannt werden.

Für die Geschwindigkeit ist grösstenteil die verwendete Technologie
(Maschienen im reinstraum) entscheident. Das was die Hersteller mit
30 nm, 90 nm etc beschreiben. ASIC's werden in gut beherrschten
Prozessen gefertigt, die mit größeren (und somit langsameren)
Strukturen arbeiten. Beispielsweise AMI 2001 mit 800-400nm wo die
FPGA's schon bei 130 nm standen.

Um bei AMI zu bleiben, ein teil deren geschäftes war es aus einem
FPGA-Design ein ASIC zu machen.
Bei Virtex 2 (ca 250 MHz) war es wohl nicht mehr zu schaffen, die ASIC
Technology zu langsam. Da hätte man wohl das Silizum als FullCustom neu
machen müssen und selbst dann ist die Frage ob 400 nm Silizum schnell
genug ist.

Die Situation war vor 2000 eine andere als ASIC's und FPGA's quasi in
der selben Fab gemacht worden. Seit ca 2000 werden aber FPGA's auf der
neuesetn technology gebaut. Grund dafür die Ähnlichkeit von FPGA und
SDRAM. Beide sind schön regelmäßig also wenige Problem,die millionfach
gleich auftauchen. Chips dagegen, bei denen jede Ecke handgefeilt ist,
machen zehntausende Probleme, wobei manche nur an einer Stelle im
Silizium auftauchen. Also kann man einer brandneue technologie die
Kinderkrankheiten austreiben und FPGA's fertigen. Beherrscht man dies
(nach 3-5 Jahren) kann man die technologie weiter optimieren um auch
die fertigungstechnisch anspruchsvolleren ASIC's zu fertigen.

Somit ist ein ASIC nicht zwangsläufig schneller als ein FPGA, da
ASIC's meist auf älteren Mschienen gefrtigt wird.

PC-CPU's zählen dabei nicht zu ASIC's (für Kunden mit
mittleren/kleinen Stückzahlen gefertigt) sondern zu den
Standardprodukten im Massenmarkt.

Mikrocontroller (ATMEL,PIC) werden meist auf alten/sehr alten
maschienen gefertigt. Das ist billig, aber bei ca 20 MHz ist schluss.

Autor: T.M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, dass Asics oft auf älteren Prozessen laufen in der Herstellung hab
ich auch schon gehört. FPGAs müssen schon alleine, um den
Integrationsvorsprung von Asics einzuholen, meist auf der neuesten
Technologie gerfertigt werden. Bei Xilinx wohl gerade auf 65nm. Man
benötigt ja auch unweit mehr Transistoren für die selbe Logikfunktion
aols bei Asics. Dass dadurch sich die Geschwindigkeit mittlerweile
umgekehrt hat, ist mir neu. Aber ich kann auch nur aus "Erfahrung"
vom Lesen diverser Artikel in der Fachpresse sprechen. Da ist 1. Grund
für Asics deren geringer Preis bei (sehr) hohen Stückzahlen. Und 2. oft
noch die erreichtbare Taktrate. Klar ist dabei aber auch, dass ein Asic
dafür oft handoptimiert werden muss, was sich aber oft wohl nicht lohnt
aus Zeitgründen. Wenn es um eine schnelle Time-2-Market geht, sind FPGAs
natürlich nicht zu schlagen. Oder eben ein Microcontroller, wenn er denn
die Leistungsanforderungen erfüllt, und sich das Problem gut in SW
abbilden lässt.

Autor: FPGAküchle (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
#ja auch unweit mehr Transistoren für die selbe Logikfunktion
#aols bei Asics.

2000 habe ich was von Faktor 10 gesehen, das dürfte auchheute noch
stimmen.


#Dass dadurch sich die Geschwindigkeit mittlerweile
#umgekehrt hat, ist mir neu

Die Info bezieht sich auf AMI, anderswo wird es wohl ähnlich sein.
Also 20 - 100 MHz kein problem für ASIC, 250 MHz schon. Mal bei den
ASIC-Technolgien Beschreibungen der ASIC Fabs (z.B Atmel,ZMD, OKI)
schauen was heute der Stand ist.

Autor: T.M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei der einen Firma war ich mal ne Weile. Hab aber leider keine
genaueren Infos. Hatten in der Zeit auf 8'' geupgradet und letztens
sollte wohl auch die Strukturbreite verringert werden. Zumindestens
wurden Testfelder gefertigt, die ich mit durchgemessen habe. Da dort
aber sowieso eh grösstenteils mixed-signal entwickelt, werden da wohl
nicht die höchsten Ansprüche an die Taktrate gestellt werden, nehm ich
mal an...

Autor: FPGAküchle (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Habs gerade mal bei Atmel gecheckt, die würden auch 250MHz+ schaffen,
mit einer 180(?) nm Technologie:

http://www.atmel.com/dyn/products/devices.asp?family_id=626

Autor: Daniel R. (daniel_r)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Das was die Hersteller mit 30 nm, 90 nm etc beschreiben.

Seit wann gibts denn schon 30 nm?????
Das kleinste mit bekannte ist 65 nm und das ist meines Wissens erst im
Kommen...

Autor: FPGAküchle (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
#Seit wann gibts denn schon 30 nm?????
#Das kleinste mit bekannte ist 65 nm und das ist meines Wissens erst
#im
#Kommen...

Zahlenbeispiel. Im Test sind wohl 45 nm und das nächst kleinere (32 nm)
soll 2009 produktionsreif sein:

http://www.heise.de/newsticker/meldung/68808

Autor: Falk S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie sieht es denn nun mit der Portabilität C- vs. VHDL Code aus?

Falls letzterer nicht manuell auf den entsprechenden FPGA/CPLD
optimiert wird, sondern eine Verhaltensbeschreibung vorliegt
(Behavioral) ist doch die Portabilität von VHDL Code besser als bei
C-code. Letzterer enthält doch  stets maschinenspezifische Konstrukte
(z.B. Special Function Register) und das Zeitverhalten ist stark vom
Befehlssatz der jeweiligen CPU abhängig. Oder habe ich da was
übersehen?

Autor: Daniel R. (daniel_r)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stimmt vollkommen.
Man muss nur die Pinnamen ändern, synthetisieren und fertig...

Daniel

Autor: Leopold (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Hagen:

Du schreibst:
-------------
"Aber das was sie immer unterscheiden wird ist die Programmierung,
bzw.
das Denkkonzept während wir die Software erstellen. FPGAs sind dabei
wesentlich mehr an der informationstheoretischen Mathematik orientiert
(Boolsche Algebra zb.), und ASICs werden eher aus einem
ingeneurtechnisch mechanischen Aspekt heraus programmiert.

Eine FPGA Software stellt also immer im gewissen Sinne ein Formel dar,
also so wie eine mathematische Formel der boolschen Algebra.
Die Software eines ASICs ist dagegen eher ein mechanisches Konstrukt,
ein Ablaufplan."


Wie kommt denn die Formel in FPGA's zustande? Und warum ist das denn
so? Schon mal überlegt, wie man auf ASICS Pfade parallelisieren kann?


Ich habe bislang immer das Niveau hier im Forum geschätzt!
Also begebt euch bitte nicht auf die "MHz-Geschwindigkeitsmanie"-
Ebene.

Selbstverständlich ist der Unterschied zwischen FPGAs und ASICs
gravierend! Wenn Bedarf besteht erkläre ich den, bitte aber vorher
mal selber rechergieren.

Bis die Tage.

Autor: Jonathan Steinbuch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein FPGA ist doch hier(und überall anders) ein aus einem SRAM-Gitter
bestehender Chip, der die Flipflops des SRAM-Gitters zum vorgeben des
Weges durch ein Gattersystem verwendet wird. Er ist dadurch völlig
dynamisch programmierbar, allerdings auch langsamer und
Stromhungriger.

Was mich wundert ist, dass hier nie auf die Möglichkeit eingegangen
wird, einen FPGA dynamisch durch die verwendenden Anwendungen zu
programmieren. So könnte das was heute, Erweiterungskarten,
Grafikbeschleunigerkarten(ATI/nVidea...), oder gar
Physikbeschleunigerkarten(ageia PhysX) übernehmen, dynamisch in einen
standardisierten (wie die x86-Norm bei CPU's) FPGA(zusätzlich zur CPU)
geladen werden, und dann egal wie der Programmierer seine
Grafik/Physik/...Algorithmen plant diese optimal unterstützt werden.
Ich wünschte diese Freiheiten bei der Programmierung von Spielen oder
anderen performancekritischen Anwendungen gäbe es schon heute...

gruß jostone

Autor: T.M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dynamische Rekonfiguration (denke, dass du das meinst) wird ja schon
gemacht. Das dumme ist nur, dass halt die Nachteile (extrem lange
Programmierzeit, feingranularer Aufbau, nur spaltenweise
konfigurierbar) sehr hohe Rekonfigurationskosten ergeben. Im Moment nur
nutzbar wenn der Algorithmus auf dem FPGA nicht sehr schnell (ms
Bereich) gewechselt werden soll. Mit dem Virtex-4 sind da einige
Verbesserungen gekommen, die das Ganze fast schon sinnvoll erscheinen
lassen, da kann man nämlich auch kleinere Blöcke als eine ganze Spalte
rekonfigurieren. Naja, ich schweife ab...


T.M.

Autor: Jonathan Steinbuch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich glaube du hast mich nicht vollständig verstanden.

Wenn die "dynamische Rekonfiguration" nicht im ms-Bereich
programmierbar ist, stört das nicht einmal, für meinen Vorschlag. Es
darf ja ruhig eine Sekunde dauern, bis die Beschleunigereinheit für ein
Spiel oder ähnliches geladen ist, und dann die ganze Laufzeit des
Spiels(der Anwendung) verfügbar ist.

Außerdem meine ich damit auch nicht die "beschränkten" derzeitigen
FPGA's.Ein FPGA für meine Anwendungsmöglichkeit kann ja (aufgrund der
zu erwartenden großen Stückzahl(von Spiele-beschleunigenden
Grafikkarten werden Tausende verkauft) kostengünstig) speziell
entwickelt werden. Und hier ging es ja um generelle Vorteile von
FPGA's. Oder?

Beschleunigereinbaukarten sind heutzutage mit ASIC's versehen(also
Mikrocontrollern...). Wenn man jedoch eine einzelne universelle
Beschleunigerkarte mit einem modularen FPGA versieht, von dem
Anwendungen(Spiele) einzelne Module "reservieren" können, dann würde
dass viel mehr Möglichkeiten geben Spiele/Anwendungen mit individuellen
derzeit rechenintensiven Elementen zu programmieren...

Es tut mir leid, wenn ich eine subjektive Meinung vertrete, da ich mich
erstens eher mit Spieleentwicklung als mit
"Mikrokontrollerentwicklung/programmierung"(oder so ähnlich)
beschäftige.

Ich hoffe ihr versteht den generellen Aufbau von FPGA's(Rechensysteme
durch Flipflop-gitteraufbau dynamisch konfigurierbar machen), und kennt
nicht nur seine Ausprägungen und praktischen Anwendungen. Tut mir leid,
ich bin nicht vom Fach. Aber denkt euch doch mal über menschengemachte
Beschränkungen hinweg.

gruß jostone

Autor: Axel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Außerdem meine ich damit auch nicht die "beschränkten" derzeitigen
FPGA's.Ein FPGA für meine Anwendungsmöglichkeit kann ja (aufgrund der
zu erwartenden großen Stückzahl(von Spiele-beschleunigenden
Grafikkarten werden Tausende verkauft) kostengünstig) speziell
entwickelt werden."

Also bei ca. 1,5 Mio US$ für einen Maskensatz in diesen Technologien
und wenigen 1000 Stück für High End Spiele Karten sind das ca. 1500 US$
pro FPGA. Und da ist noch nicht einmal der  Siliziumpreis und die
Entwicklung berücksichtigt.

Gruss
Axel

Autor: Jonathan Steinbuch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"für einen Maskensatz in diesen Technologien"
Was meinst du mit in diesen Technologien? Kostet das maskieren von
Siliziumchips, nicht unabhängig von der Technologie dasselbe?

Allerdings halte ich da 1,5Mio$ für sehr hoch, aber da ich nicht
verstehe warum das maskieren(der maskensatz) je nach Technologie
verschieden kostet, würde jede Argumentation die ich dagegen wagen
würde, möglicherweise am selben Punkt scheitern.

Und, es lohnt sich auch Highendgrafikkarten zu entwickeln, oder
Flashspeicher für 30€, das Stück mit 1GB Kapazität...

Vermutlich verstehe ich das jetzt nicht ganz, weil ich nicht vom Fach
bin, aber deshalb bitte ich dich hiermit darum, zu versuchen mir das zu
erklären. Ich lasse mich gerne überzeugen.

gruß jostone

Autor: Axel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Was meinst du mit in diesen Technologien? Kostet das maskieren von
Siliziumchips, nicht unabhängig von der Technologie dasselbe?"

Nein, das fängt so bei 15.000 € für eine 0,5µ Technologie an und hört
bei 1,5 Mio für eine 65 nm Technologie voraussichtlich noch lange nicht
auf.

Grund ist der, dass die neueren Technologien schlicht wesentlich mehr
Masken brauchen (0,5µ hat 2 Metallagen, 65 nm bis zu 9 ML) und eine auf
0,5µ genaue Maske auch wesentlich billiger ist als eine, die auf 65 nm
genau sein muss.

"Und, es lohnt sich auch Highendgrafikkarten zu entwickeln, oder
Flashspeicher für 30€, das Stück mit 1GB Kapazität..."

Die werden dann aber auch eher in Millionen Stückzahlen (bzw. 100 Mio
für so einen Flashspeicher) gefertigt. Du hast hier von einigen Tausend
geschrieben.

Gruss
Axel

Autor: Jonathan Steinbuch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Okay, das war dann eher ein kleines verständigungsproblem beiderseits.

Danke dir für deine Erklärung.

Ich glaube nicht, dass man unbedingt die neueste 65nm-Technologie für
ein Produkt mit einigen 1000 Stück braucht(90nm wäre wohl schon das
höchste der Gefühle sein...), und andererseits meinte ich das mit
einigen 1000 Stück auch nur, weil ich mir nicht sicher über die
wirkliche Größe des Marktes bin...

Also, ich glaube man kann dann schon sagen, dass sich in einem Markt,
in dem sich die Produktion einer statischen Physikbeschleunigerkarte
nur für Spiele für ca. 200€ das Stück lohnt, sich auch die Produktion
einer dynamischen relativ universellen Beschleunigerkarte lohnt.
Zumindest nach ein paar Jahren Eingwöhnungszeit.

Danke dir nochmal für deine Klarstellung.

gruß jostone

Autor: Marco S. (masterof)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn es als Hardware wie zum Beispiel nur genutz wird wie SLI. Dann
macht NVIDIA 1% vom Grafikkarten umsatzt aus und das sind mehr als
1000Stück wo für SLI verkauft wurden.

Autor: Markus K. (markus-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Warum sollte ein FPGA schneller als ein ASIC sein? Ich hätte das
andersrum erwartet.

Autor: Jonathan Steinbuch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein ASIC kann schneller getaktet werden als ein FPGA.

Aber: Ein FPGA kann wie gesagt völlig dynamisch rekonfiguriert werden
und Aufgaben übernehmen, für die man erst einen neuen ASIC bauen
müsste.

Und für diese Aufgaben ist ein FPGA dann deutlich schneller als jede
Simulation durch eine CPU.

(Ja, es wäre möglich einen höher taktbaren ASIC mit der jeweils
gleichen Funktion zu bauen, aber das lohnt sich für die meisten
Funktionen nicht, und würde noch länger in der Herstellung dauern)

gruß jostone

Autor: T.M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das gibts doch auch jetzt schon. Dafür gibts ja FPGA-Boards mit
PCI(express)-Interface wie von http://www.4dsp.com/PCI.htm zum
Beispiel.
Da kann man ja dann die Algorithmen laufen lassen und über eine API
kann der FPGA vom Host aus umkonfiguriert werden. Das funktioniert
sogar ganz gut, wir haben so ein Board hier im Einsatz.


T.M.

Autor: Tom (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, aber die dürften als Spielebeschleuniger noch deutlich zu teuer
sein, wobei mir nicht so ganz klar ist worin denn nun dieser spezielle
Game-FPGA sich von den bereits existenten und angebotenen
unterscheidet. Da gibts doch eigentlich schon (fast) alles: kleine und
große Logigblöcke, dezidierte Ram-Bereiche, Multilpizierer, DSP-Cores,
ARM und PPC-Kerne. Und 'einfach' und 'billiger' will erstmal
erfunden werden, sonst müsste man ja 'nur' einen einfachen und
billigeren und schnelleren x86 Core erfinden und davon dann 32 oder
mehr auf ein Die packen. Da wäre mann dan auch gleich das Problem los
spezielle FPGA erst noch konfigurieren zu müssen, bzw. die
Konfiguration erstmal zu systhetisieren.

Autor: Markus K. (markus-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein FPGA als Grafikbeschleuniger dürfte erstmal langsamer und teurer als
eine klassische Grafikkarte sein - auch bei großen Stückzahlen. Dass man
damit auch eine Physik-Karte ersetzen kann (auf Kosten der
Grafikleistung?) ist zwar toll, wird aber Hardcore-Gamer nicht wirklich
beeindrucken.

Deswegen sehe ich für einen reinen Game-FPGA keine Zukunft. Wenn, dann
für das ganze System. Ich schau ein HDTV-Video an und der FPGA
unterstützt die CPU, ich spiele ein Spiel und der FPGA wird zur
Physik-Engine, ich mache Bildbearbeitung und kann in Photoshop komplexe
Filter in Echtzeit sehen. Dann lohnt sich das.

An der Stelle wäre eine konkrete Resourcenabschätzung interessant.
Wieviele FPGA-Resourcen braucht es (für ein konkretes Problem), um eine
aktuelle CPU mit 2x3GHz zu ersetzen. Schließlich kann auch eine CPU
mehrere Dinge gleichzeitig machen. Kennt da jemand irgendwelche
Beispiele?

Markus

Autor: Axel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Man darf bei der ganzen Diskussion nicht vergessen, dass die ganzen
aktuellen Grafikkontroller bereits ASICs sind. Und zwar jeweils so
ziemlich das Beste, was es an Technologie zu kaufen gibt.

Ein FPGA, welches ja auch nicht in einer schnelleren Technologie
gefertigt werden kann, wird im direkten Vergleich deutlich langsamer
sein. Das kann man vermutlich auch nicht durch die Optimierung auf
bestimmte Sequenzen/Szenen/Features ausgleichen. Denn die
Graphikcontroller sind ja schon auf Spiele optimiert, sonst braucht ja
keiner diese Leistung.

"Wieviele FPGA-Resourcen braucht es (für ein konkretes Problem), um
eine aktuelle CPU mit 2x3GHz zu ersetzen. Schließlich kann auch eine
CPU mehrere Dinge gleichzeitig machen."

Das mit dem gleichzeitig machen geht natürlich auch gleich in die
Performance.

Filteralgorythemen oder Dekompressionsverfahren (MPEG4 wird da
interessant) sind in Hardware schon schneller als in einer CPU, das
macht u. U. Sinn, vor allem wenn es auch um Stromverbrauch etc. geht.

Allerdings ist es dann wohl einfacher mehrere ASICs in den Rechner zu
bauen, als das Ganze in einem FPGA variabel zu halten.

Übrigends gibt es bei der Geschichte noch das Problem des
Kopierschutzes. So einen MPEG4 Dekoder (als Beispiel) für ein FPGA zu
entwickeln ist ganz schön aufwendig und kostet einiges. Und wenn man
den Bitstream quasi in die Software einbettet kann man kaum verhindern,
dass der kopiert wird. Dann verdient zwar der FPGA Hersteller an dem
FPGA, nicht aber der Entwickler des Dekoders. Dann giesst der das
lieber gleich in einen ASIC, wo er mehr Performance hat und die
Kontrolle über seine Entwicklung.

Gruss
Axel

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Axel,

"Dann giesst der das lieber gleich in einen ASIC, wo er mehr
Performance hat und die Kontrolle über seine Entwicklung."


Auch FPGAs lassen sich schützen, sonst würde die ja keiner einsetzen.

Dazu ist ein kleiner OTP integriert, in dem dann der Schlüssel abgelegt
wird.
Und der externe Konfigurationsspeicher enthält die verschlüsselten
Daten die nur der FPGA mit dem zugehörenden Schlüssel dekodieren kann.


Peter

Autor: Axel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Peter,

rein interessehalber: gibt es sowas schon ?

Gruss
Axel

Autor: Jonathan Steinbuch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der (auch nur in endlicher Zeit) unknackbare Schlüssel wurde noch nicht
erfunden.
Allerdings gilt es in der Hinsicht auch zu beachten, dass auch mit
Opensource-Software Geld verdient wird (Beispiel sun), und dass auch
wenn es möglich ist Produkte mit geringem Kosten/Zeitaufwand zu
reproduzieren dies nicht unbedingt erlaubt ist.
(Geldfälschung/Raubkopien)

Klar sind Grafikkontroller auf Spiele optimiert, aber sie unterstützen
dabei nur das "rendern" von Vektordaten, sowie Texturdaten, auf einen
standardisierten Bildschirm. Es gibt viel mehr Möglichkeiten Grafik(vor
allem dreidimensionale) zu verarbeiten.

Markus hat vollkommen Recht, wenn er schreibt, dass solch ein FPGA
nicht nur für Spiele, sondern auch für andere Anwendungen genutzt
werden könnte. Dadurch könnte die Zielgruppe auch ausgeweitet werden.
Ich glaube allerdings, dass als Anhängsel eines anderen Hardwareteils
im Markt leichter Fuß fassen kann. Idealer als die Grafikkarte wäre
vielleicht die CPU.

Allerdings muss ich inzwischen leider zustimmen, dass FPGA's in
absehbarer Zeit unweigerlich teurer sind als ASIC's, auch unabhängig
von der Vermarktung. Sie benötigen mehr Die-Fläche, und dadurch ist
nicht nur mehr Ressourcenverbrauch verbunden, sondern vor allem eine
größere Menge fehlerhafte Chips, da auf größerer Fläche auch mehr
Materialfehler auftreten können.

gruß jostone

Autor: Axel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jonathan:

"Der (auch nur in endlicher Zeit) unknackbare Schlüssel wurde noch
nicht erfunden."
Es ging mir eigentlich nicht um den Schlüssel (das Problem ist wohl
eher ein akademisches), sondern ganz praktisch um ein FPGA, welches
solch eine Funktion schon hat. Würde mich interessieren.

"und dass auch wenn es möglich ist Produkte mit geringem
Kosten/Zeitaufwand zu reproduzieren dies nicht unbedingt erlaubt
ist."

Das interessiert so eine kleine chinesische Bude eher nicht.

"Markus hat vollkommen Recht, wenn er schreibt, dass solch ein FPGA
nicht nur für Spiele, sondern auch für andere Anwendungen genutzt
werden könnte. "

Dabei dürfte sich das aber auf die Aufgabe als Rechenknecht begrenzen.
Man könnte sich zwar auch andere Dinge ausdenken, dafür müsste dann
aber ein Interface nach aussen (mit ADC und/oder DAC) vorhanden sein.
Ich denke, vieles davon wird durch die Multicore Prozessoren schon ganz
gut erschlagen.

Und die Erfahrung zeigt, dass man immer genau das Interface vergessen
hat, was man gerade braucht.

Und ein weiteres Problem liegt dann auch darin, dass man die dann nicht
gleichzeitig nutzen kann. Ein FPGA welches ich alternativ als
Graphikbeschleuniger oder als Physikalischer Beschleuniger nutzen kann,
dürfte für ein Spiel nicht viel bringen.

"Allerdings muss ich inzwischen leider zustimmen, dass FPGA's in
absehbarer Zeit unweigerlich teurer sind als ASIC's, auch unabhängig
von der Vermarktung."

Ist natürlich eine Stückzahlfrage. Bei 100 Stück ist der FPGA
günstiger. Bei 10.000 sieht das schon anders aus.

Gruss
Axel

Autor: SiO2 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da einige nen  FPGA als "CoProz" wollen, dann macht hier mit
http://wikihost.org/wikis/openhardware/programm/ge...

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Axel

Muß mich korrigieren, ist kein OTP sondern benötigt ne Stützbatterie:

"Virtex-II devices have an on-chip decryptor using one or two
sets of three keys for triple-key Data Encryption Standard
(DES) operation. Xilinx software tools offer an optional
encryption of the configuration data (bitstream) with a triple-
key DES determined by the designer.
The keys are stored in the FPGA by JTAG instruction and
retained by a battery connected to the VBATT pin, when the
device is not powered."


Peter

Autor: Axel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter,

trotzdem vielen Dank. Hatte ich nicht gewusst.

Gruss
Axel

Autor: Tobias Schneider (tobias)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,
Altera Stratix FPGAs haben einen internen Speicher fuer die Schluessel.
Ich weis jetzt aber nichtmehr, ob das als EEPROM oder als OTP
ausfgefuehrt ist.
Diese Zellen sind dann auf dem Chip so verteilt, dass sie nicht so
einfach auszulesen sein sollen, wenn man den Chip von seinem Gehaeuse
"befreit". Ob dies jedoch langfristigen Schutz vor hochgeruestete
Angreifern bietet ist wohl fraglich. Ein auf RAM basierender Schutz
bietet da wohl mehr Sicherheit, da es da wohl sehr viel schwerer sein
duerfte, den Chip unter ein Analysewerkzeug zu bekommen, ohne das RAM
zu loeschen.
Wenn ich mich richtig erinner hat das US-Militaer da auch eindeutige
Vorschriften, wenn es daraum geht, wie sich eine ihrer neuen
"High-Tech" Waffen zu verhalten hat, wenn sie in feindliche Haende
geraet und versucht wird an das enthaltene Know-How zu kommen ...

Gruss Tobias

Autor: Axel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für die Hinweise.

Habe mich jetzt mal selbst schlau gemacht (ja, wenn man weiss wo man
suchen muss :-) )

Also der Altera hat sowohl einen programmierbaren als auch einen
eingebrannten Schlüssel, so dass zumindest die Anwendung, die wir oben
diskutiert haben, gehen würde.

Den zweiten Ansatz für so eine Verschlüsselung hätte ich beim Schutz
von Know How bei Fertigung in Fernost gesehen. Aber da nützt das leider
nichts, weil der Fertiger trotzdem immer in der Lage wäre, FPGAs
woanders zu besorgen und mit dem ihm bekannten (evtl. auch
verschlüsselten) Bitstream eine Parallelfertigung auf eigene Kosten
aufzuzuiehen.

Gruss
Axel

Autor: Markus Stehr (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
*Thread nicht vollständig gelesen Warnung!*
Wo kriegt man den jetzt nen FPGA für 15, maximal 30 Euro auf
Adapterplatine für zum Basteln her?
So ein Spartan ist mir mit 100-150 Euro zu Teuer zum rumspielen.
Oder könnte mir einer sowas fertig machen?

Autor: Dirk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Wo kriegt man den jetzt nen FPGA für 15, maximal 30 Euro auf
>Adapterplatine für zum Basteln her?
>So ein Spartan ist mir mit 100-150 Euro zu Teuer zum rumspielen.
>Oder könnte mir einer sowas fertig machen?

Für den Preis wird es maximal ein CPLD Board. Ich haette ein
Anfaengerboard zuverkaufen.

Platine bestückt mit XC9572 PLCC , Laengsregler , Quarz und alle IO's
auf Pinheader für 20 Euro.

Bei interesse bitte meine Email Adresse nutzen.

Gruß,
Dirk

Autor: Markus Stehr (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
In einem CPLD kriegt man aber nix unter was mit dem VIC-2 vergleichbar
währe. (Grafikchip des C64)

Autor: Arif Balci (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Markus,

wo kann man M32192 kaufen? Ich versuche es seit langer Zeit, aber Glyn
sagt die M32R Familie nich für europäischen Markt gedacht ist.

Grüsse

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Keine Ahnung wo wir den den M32192 her haben, aber ich arbeite schon in
Deutschland und der Firmensitz ist meines Wissens nach auch in
Deutschland. Wir erwarten allerdings langfristig sechsstellige
Stückzahlen, vielleicht bekommt man die Dinger dann auch in Europa.

Markus

Autor: Mido (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

Fpga ist ehe fuer eingebetete Systemen gedacht..So kann man den BRAM 
Groesse beliebig festlegen oder gar nicht. die Wichtigste Anwendung von 
der FPRA ist, dass man auf die Hardware geroutete Funktionen PARALLEL 
laufen lassen..... je komplexer die Funktionen sind, umso besser eigenet 
sich die FPGA zum Einsatz zu kommen.

Autor: fvbbg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei ACTEL FPGA (z.B. Fusion) haste die Probleme nicht...

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]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [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.