Hallöle, ich frage mich, wie man beispielsweise herausfindet, ob ein Unternehmen mit FPGAs entwickelt. Beispiel: INFICON GmbH Köln Natürlich kann man hergehen, und in einer Suchmaschine den Firmennamen zusammen mit FPGA eingeben. Aber nicht immer ist ersichtlich, ob FPGAs zum Einsatz kommen. Wie geht Ihr vor? Was sind Eure Erfahrungen? Danke für Eure Meinungen. Gruß, Fragender
Nee, kann man nicht generell ausschliessen. Auf die andere Seite spezialisiert man sich nicht auf FPGA alleine.
indem man bei der Firma anruft und nachfragt. Wenn sie es einem sagen wollen, werden sie es dann tun. Oder Du wirst Xilinx FAE, dann hast du alle Kunden in der Datenbank.
Bei einem Elektronikentwicklungsdienstleister sollte man das auf der Homepage finden, z.B. wie bei uns gelöst: http://www.leber-ingenieure.de/leber-losungsingenieure/leistungsspektrum/produktentwicklung/programmierbare-logik/. Ansonsten hilft nur anrufen... Bei Fragen zu FPGA-Entwicklung jederzeit gerne an mich wenden.
Hallo Olaf, bei einem Dienstleister liegt der Einsatz von FPGAs quasi auf der Hand (und vielleicht auch wie in Deinem Fall auf der Homepage). Es gibt aber Firmen, die verwenden FPGAs in ihren Produkten, man erfährt dies bspw. auf der Homepage jedoch nicht. Wenn man Glück hat, dann existiert von einem Mitarbeiter dieser Firma ein Paper o.Ä., aus dem der FPGA-Einsatz hervorgeht. Dies ist aus meiner Sicht doch eher die Ausnahme. Und die Frage ist: Wie kann man als Arbeitssuchender diesen "verdeckten" FPGA-Einsatz aufdecken? Gruß, Fragender
Olaf schrieb: > Bei einem Elektronikentwicklungsdienstleister sollte man das auf der > Homepage finden Die fragliche Firma ist KEIN Dienstleister: http://www.inficon.com/de/index.html
Fragender schrieb: > die verwenden FPGAs in ihren Produkten, was noch nicht heisst, dass sie sie auch selber programmieren
Mac Gyver schrieb: > In denjenigen welchen wo ein ASIC oder ein passendes ASSP verwendet > wird? ;-) Wo ein ASIC drin steckt ist meistens vorher ein FPGA-Prototyp gebaut worden.
Fpga Kuechle schrieb: > Mac Gyver schrieb: >> In denjenigen welchen wo ein ASIC oder ein passendes ASSP verwendet >> wird? ;-) > > Wo ein ASIC drin steckt ist meistens vorher ein FPGA-Prototyp gebaut > worden. Ja das stimmt natürlich. So war zumindest ein FPGA "beteiligt" ;-)
M. F. schrieb: > In welcher Digitalschaltung ist denn heute kein FPGA mehr drin? Wenn ich mir hier auf mikrocontroller.net so anschaue wie lebendig das FPGA Forum und das µC Forum im Vergleich sind, ist mir die Antwort eigentlich sonnenklar ;) Solange eine Applikation nicht absolut zeitkritisch ist, würde ich als Entwickler immer einem Microcontroller den Vorzug geben - da kommt man mit konventionellen Programmierkenntnissen ziemlich weit. Und auch schon mit den "ganz kleinen" µCs wie etwa einem Attiny kann man schon erstaunliche Dinge machen. Die Dinger spielen ihre Stärke bei Ablauf-Programmierung aus. FPGA & Co. dann eher für ganz flotte Sachen wie Signalverarbeitung, aber das wird eben nicht wirklich immer gebraucht. Für Hobbyisten (wie mich) werden FPGAs aus einem Grund hochinteressant, der für kommerzielle Anwendung wohl eher abartig ist: man kann damit so wunderschön alte Prozessor-Architekturen nachbasteln ;)
Micha schrieb: > man kann damit so wunderschön alte Prozessor-Architekturen nachbasteln ;) Aber man sollte sich verkneifen, mit einem Softcore gegen aktuelle Prozessoren anstinken zu wollen. Das geht sicher schief, und man muss sich einiges in die Tasche lügen und sich selber Sand in die Augen streuen, um gegen einen uC ankommen zu können (so etwa auf dem Niveau: "FPGA ist eh' in der Schaltung" oder "Kann den Controller auf meine Anwendung zuschneidern" oder "Bin viel flexibler" oder "Dann ist alles in einem Chip" oder ...).
Lothar Miller schrieb: > Micha schrieb: >> man kann damit so wunderschön alte Prozessor-Architekturen nachbasteln ;) > Aber man sollte sich verkneifen, mit einem Softcore gegen aktuelle > Prozessoren anstinken zu wollen. > Das geht sicher schief, und man muss sich einiges in die Tasche lügen > und sich selber Sand in die Augen streuen, um gegen einen uC ankommen zu > können (so etwa auf dem Niveau: "FPGA ist eh' in der Schaltung" oder > "Kann den Controller auf meine Anwendung zuschneidern" oder "Bin viel > flexibler" oder "Dann ist alles in einem Chip" oder ...). IMHO vergleichst du hier Äpfel mit Birnen. Ein FPGA kann in weiten Teilen einen microcontroller wie AVR/PIC ( http://gadgetforge.gadgetfactory.net/gf/project/avr_core/ ) locker ersetzen, die überzüchteten PC-Prozessorarchitekturen dagegen nicht. Die Grenze für LowCost-FPGA liegt m.E. beim 68020 der auf einen S3A-1400 passen sollte, eventuell auch 386DX, also bei den ersten Unix-fähigen 32bit Single-Cores im zweistelligen MHz-Bereich aus den 90igern. MfG,
Numboz Cranchos schrieb: > Ein FPGA kann in weiten Teilen einen microcontroller wie AVR/PIC > locker ersetzen Das sind Prozessoren aus dem letzten Jahrtausend. Hatte ich nicht was von "aktuellen" Prozessorarchitekturen geschrieben? > Ein FPGA kann in weiten Teilen einen microcontroller wie AVR/PIC > locker ersetzen Und zu welchem Preis? (bitte incl. Programmspeicher und RAM rechnen, die Peripherie darfst du auf die digitale Ecke reduzieren) Rechnet sich das? > die überzüchteten PC-Prozessorarchitekturen dagegen nicht. Dazwischen gibts auch noch was: die 32-Bit Dinger von ARM mit der entsprechenden Peripherie. > Die Grenze für LowCost-FPGA liegt m.E. beim 68020 der auf einen > S3A-1400 passen sollte Naja, da sind Kosten egal, denn den 68020 gibt es nicht mehr. Wenn ich den aber brauche, dann ist jede Lösung günstig. Dagegen einen 68000, den ich bei Freescale für 5$ bekomme. Da klappt das schon nicht mehr mit der Kostenrechnung. Glaub mir: ich würde auch gern einen Prozessor ins FPGA packen (ist ja irgendwie cool), aber sooft ich es anpacke: es rechnet sich einfach nicht (abgesehen von solchen kleinen FSM-Rechnern wie den Picoblaze für spezielle Aufgaben).
>> Ein FPGA kann in weiten Teilen einen microcontroller wie AVR/PIC >> locker ersetzen >Und zu welchem Preis? (bitte incl. Programmspeicher und RAM rechnen, die >Peripherie darfst du auf die digitale Ecke reduzieren) Da kriegt man in fertigen uCs (die oft auch noch subventioniert werden) die CPU (und Teile v. RAM u. Perif.) sogar geschenkt.
Lothar Miller schrieb: > Numboz Cranchos schrieb: >> Ein FPGA kann in weiten Teilen einen microcontroller wie AVR/PIC >> locker ersetzen > Das sind Prozessoren aus dem letzten Jahrtausend. > Hatte ich nicht was von "aktuellen" Prozessorarchitekturen geschrieben? Auch. Das isnd je die Birnen und die Äpfel oben schreibst du von "aktuellen" Prozessorarchitekturen (lese ich als GHz-Multicore-Monster) , unten von "um gegen einen uC ankommen" (lese ich als 12MHz 8 bit Wald und Wiesen AVR/PIC). Lothar Miller schrieb: > Und zu welchem Preis? (bitte incl. Programmspeicher und RAM rechnen, die > Peripherie darfst du auf die digitale Ecke reduzieren) > Rechnet sich das?" Das ist doch eh in dem FPGA, das liegt doch brach. Beispielsweise in einem Design das einen S3A-1000 passen würde, da es aber keinen -1000 gibbet (nur -700 oder -1400) in einen -1400. da bleibt quasi ein -400 übrig in den locker mehrere 8 bit uC passen und BRAM/DRAM für die paar kB RAM Arbeitsspeicher bleiben auch übrig, der ROM für die Firware wird auch durch den FPGA-Konfigspeicher miterledigt. Extra einen FPGA einzudesignen um einen uC zu ersetzen macht kaum Sinn, dagen zu schon ob man mit den 30% frei ressourcen nicht den tasten-/AlphaNum/Consolen Controller schlucken kann dagegen schon. MfG
Fred Werkel schrieb: > "aktuellen" Prozessorarchitekturen (lese ich als GHz-Multicore-Monster) Ich sag da (noch)mal ARM. Und auch weitab von GHz... > Extra einen FPGA einzudesignen um einen uC zu ersetzen macht kaum Sinn, > dagen zu schon ob man mit den 30% frei ressourcen nicht den > tasten-/AlphaNum/Consolen Controller schlucken kann dagegen schon. Wenn ich den schlucken will, dann lege ich das Design so aus, dass ich den schlucken kann. Und überlasse das nicht dem Zufall, dass mein FPGA gerade mal zum Glück zu groß ist. Vor allem implementiere ich dann nicht den Controller (z.B. Tastaturcontroller 8047) und behalte die Software bei, sondern ich implementiere die Funktion des Controllers direkt in Hardware... > Beispielsweise in > einem Design das einen S3A-1000 passen würde, da es aber keinen -1000 > gibbet (nur -700 oder -1400) in einen -1400. da bleibt quasi ein -400 > übrig in den locker mehrere 8 bit uC passen und BRAM/DRAM für die paar > kB RAM Arbeitsspeicher bleiben auch übrig, der ROM für die Firware wird > auch durch den FPGA-Konfigspeicher miterledigt. Und wofür willst du die nehmen? Das da was "übrigbleibt" kannst du doch nicht von vorn herein wissen, wenn du nicht dein Design darauf hintrimmst, dass es gerade so kommen wird... Wir können da gerne ewig weitermachen. Jeder will und wird Recht haben. Aber das ursprüngliche Thema des Threads war eigentlich ein anderes...
Bitte 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.