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
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).
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
>...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#Schriftliche_Multiplikation Damit kann auch ein µC 128bit Multiplikationen machen. (Achtung: nicht sooo überaus schnell) Feadi
Ich glaube "passen" steht hier eher für "angemessen sein".
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.
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.
"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
#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).
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
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.
@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?
Nachtrag: Peripherie kann ich auch alles in einem FPGA unterbringen. Sogar die, welche an einem µC extern angebracht werden muss.
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.
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.
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
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.
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
Kann ich die Quelle fuer einen Spartan 3 mit 200k-Gates fuer 15 Euro erfahren?
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
#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.
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
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.
>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...
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 ;-)))
#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.
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
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...
>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.
#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.
>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...
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
@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 ...
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.
#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.
> 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.
#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.
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?
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.
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.
@ 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-nios_can.html NIOSII Advanced CAN -- IFI -- http://www.altera.com/products/ip/iup/can/m-ifi-can20b.html
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 :-)
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)
#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.
#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.
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...
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.
Angehängte Dateien:
-
CPC_ONBO.jpg
150 KB
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
#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.
#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.
"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
@ 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!
@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
#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.
Bei FPGA gehts ja wohl um echte harte echtzeit und man verwendet sie wenn kleine nicht so komplexe aufgaben übernehmen sollen. gruß Florian
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.
@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
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
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.
>>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
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.
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
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.
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
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...
#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.
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.
#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.
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...
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
>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...
#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
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?
Stimmt vollkommen. Man muss nur die Pinnamen ändern, synthetisieren und fertig... Daniel
@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.
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
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.
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
"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
"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
"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
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
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.
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
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.
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.
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
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
@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
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
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
Da einige nen FPGA als "CoProz" wollen, dann macht hier mit http://wikihost.org/wikis/openhardware/programm/gebo.prg?name=kad
@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
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
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
*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?
>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
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
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
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.