Hallo zusammen, Ich frage mich seit lange wie sieht es aus FPGA Zukunft, geht der Trend von FPGA in die Zukunft noch oben oder wird ASIC mehr dominieren?
Löhnt sich jetzt mit FPGA zu Anfängen? Und als Junior FPGA Programmierer findet man schnell eine Stelle/Projekt?
Sagen wir mal so.
ASIC sind dermassen teuer mit den vielen benoetigten Masken, dass sie sich nur fuer extrem hohe Stueckzahlen lohnen. Alles in kleineren Stueckzahlen laeuft mit FPGA
Und. FPGA werden als ASIC vorstufen verwendet. Bis die Funktionalitaet genau erfuellt und verfiziert ist, wird mit FPGA gearbeitet.
Also vergiss die ASIC.
Hallo zusammen, Ich frage mich seit lange wie sieht es aus FPGA
Zukunft, geht der Trend von FPGA in die Zukunft noch oben oder wird ASIC
mehr dominieren?
Beide benutzen für die Entwicklung eine hardware orientierte Beschreibungssprache (HDL) wie VHDL oder Verilog.
ASCI hat es lange vor FPGAs gegeben und wurden durch FPGAs wegen deren Programmierbarkeit abgelöst. Kein Design weder SW noch HW ist 100%ig fehlerfrei, daher ist die Programmierbarkeit eine wichtige Eigenschaft. Fehler können wie beider Software durch Updates eliminiert werden.
Da Wissen und Erfahrung mit VHDL oder Verilog benötigt wird ist der Wechsel von ASIC auf FPGAs leicht durchführbar. Mit FPGAs kann leichter experimentiert werden.
Trend von FPGA in die Zukunft noch oben oder wird ASIC mehr
dominieren?
Ein Trend bei der ASIC Entwicklung (oder mindestens Start-ups dazu) ist, dort einen Teil davon als embedded FPGAs zu bauen. Da gibt es mindestens Menta, nanoXplore und Quicklogic als Hersteller.
Löhnt sich jetzt mit FPGA zu Anfängen? Und als Junior FPGA Programmierer
findet man schnell eine Stelle/Projekt?
Ja, der Markt ist Staubtrocken.
Wenn dein Englisch besser ist als dein Deutsch klappt das, sonst auch noch an den Sprachen arbeiten, weil Dokumentation etc. schreiben gehört auch dazu (Bin ich froh, das ich mit Rechtschreibung und so irgendwann den Dreh gefunden hatte...).
Trend von FPGA in die Zukunft noch oben oder wird ASIC mehr
dominieren?
Ein Trend bei der ASIC Entwicklung (oder mindestens Start-ups dazu) ist,
dort einen Teil davon als embedded FPGAs zu bauen. Da gibt es mindestens
Menta, nanoXplore und Quicklogic als Hersteller.
Kommt darauf an, dann kloppt man sich auch mal ein FPGA-Board selbst zusammen, FPGA-Module gibt es zuhauf. Trenz, enclustra.
Mango M. schrieb:
Löhnt sich jetzt mit FPGA zu Anfängen? Und als Junior FPGA Programmierer
findet man schnell eine Stelle/Projekt?
Ja, der Markt ist Staubtrocken.
Weil es eben FPGA-Programmierer im Angebot gibt, aber keine FPGA Entwickler.
Löhnt sich jetzt mit FPGA zu Anfängen? Und als Junior FPGA Programmierer
findet man schnell eine Stelle/Projekt?
Ja, man findet schnell eine Stelle, wenn man bereit ist, mit den Indern zu konkurrieren, die sich die Firmen neuerdings in Massen in die Abteilungen ziehen. Woher die kommen, weis ich nicht und den Status kenne ich auch nicht. Ich nehme an, die sind über externe Zeitarbeitsfirmen drin oder waren über international agierende Firmen in DE, haben dann Deutsch gelernt und dann gewechselt, um sich zu verbessern.
Aus technischer Sicht ist FPGA heute fast nur noch CORE reinwerfen, anschließen und simulieren. Das Meiste wird von den Prozessoren in den SoCs abgewickelt, von daher ist C Pflicht und macht einen immer größeren Anteil aus.
Es gibt Leute, die nur noch die Programmierung machen und mit Elektronik nichts zu tun haben, meistens Softwareentwickler aus der C-Ecke, die sich da hinein entwickeln. Dazu kommen die fachfremden Programmierer, die für anspruchsvolle Software zu wenig wissen, aber das bischen C fürs FPGA gut abdecken, wie die PHysiker und Maschinenbauer.
Da gibt es massenhaft Leute, die die Preise drücken.
... und dann gibt es die wenigen anderen, die auch die Elektronik verstehen und mit schnellen Bussen umgehen können, es ausmessen und analyiseren um es zu verbessern oder ins Laufen zu bekommen. Das sind aber wenige Jobs und man braucht 20 Jahre Erfahrung.
Leute, die kleinen und optimalen FPGA code schreiben können, sind auch teilweise noch gefragt, aber das spielt sich meistens in den Massenprodukten ab, wo man kleine FPGAs einsetzt. Dort will man aber nicht viel bezahlen, weil das von Mickifirmen abgedeckt wird, die sich gegenseitig die Aufträge wegnehmen. Es gibt dort auch kaum Anforderungen, und so kann das jeder mit 3 Jahren BE leisen.
FPGA-Anfänger in unserer Firma vor einem halben Jahr, 65k für einen Entwickler mit 5 Jahren BE. (nur FPGA-Programmieren, Verifikation mit Modelsim, Testscripte mit Python)
Hat sich dann abgemacht, weil ein anderer mehr zahlt. Ich schätze 70k, weil ich weis wohin er gegangen ist und ich deren offer kenne.
(nur FPGA-Programmieren, Verifikation mit
Modelsim, Testscripte mit Python)
schätze für so a Verifikationspezialspezi gibt es weniger Jobs als für einen
Full stack FPGA-Entwickler aka vom Schaltplan bis Inbetriebnahme samt HDL-Firmwarerstellung und Peripherieanbindung).
Von wegen, full stack geht nur bei mini Projekten weil es sonst zu lange dauert und das "mini" bedeutet indirekt, dass im FPGA-Design nicht viel drin steckt. Schaltplan macht ein Schaltplanentwickler und das ist auch nötig, weil so ein typischen Design mit einem dicken fetten FPGA inklusive high-speed Busse, mal locker 3M dauert mit requirements, SPEC-Sichtung, Lynx-Simulation und allem drum und dran.
Das FPGA-Design dauert genau so lange (wenn es 3 parallel machen) und nur designs in dicken fetten FPGAs sind auch anspruchsvoll genug, damit es qualitativ hochwertige Leute erfordert.
Das Gemuckel, das in vielen FPGAs steckt und so einfach ist, dass es jeder bauen kann, wird kaum einer teuer bezahlen wollen. Wozu auch?
Ein bissl VHDL kann heute praktisch jeder. Damit gibt es keinen Blumentopf.
Mehrere high-speed-Transceiver-Subsysteme synchen, Datenströme effektiv puffern, TMR einbauen hingegen macht nicht jeder jeden Tag und die Fehler in Schnittstellen aufspüren auch nicht, weil allein das Messtechnik für 500k im Labor erfordert.
full stack geht nur bei mini Projekten weil es sonst zu lange
dauert und das "mini" bedeutet indirekt, dass im FPGA-Design nicht viel
drin steckt.
Witzig. Dann ist für Dich alles und sogar inklusive vollem >1000€-FPGA "mini"? Nur weil das bei Dir nicht so gemacht wird heißt das nicht, dass das nicht geht.
Mehrere high-speed-Transceiver-Subsysteme synchen, Datenströme effektiv
puffern, TMR einbauen hingegen macht nicht jeder jeden Tag
Natürlich macht das nicht Jeder jeden Tag. Wozu auch? Selbst wenn eine Person das alles in einem Design macht, dann auch nacheinander und nicht jeden Tag gleichzeitig an allen Baustellen. Und TMR ist eine Spezialgeschichte die bei vielen Projekten nicht gefordert ist, nicht jeder FPGA sitzt im Auto oder fliegt ins All.
die
Fehler in Schnittstellen aufspüren auch nicht, weil allein das
Messtechnik für 500k im Labor erfordert.
Es gibt auch andere Debuggingmöglichkeiten. Moderne Interfaces kann man meist simulieren und dann auf der Hardware gibt es viele Signale zum Debugging die man angucken kann. Auch das nicht mit dem Oszi sondern mit dem ILA/SignalTap. Direkt an die Leitung auf der Platine muss man doch nur wenn man was im Layout verbockt hat. Privat habe ich schon USB3/HDMI/HyperRAM gemacht (Schaltplan/Layout/FPGA) und das ohne schnelles Oszi. Funktioniert auch.
Es geht nicht darum, dass man "VHDL" kann, sondern dass man "Hardware" kann. Dann ist die Beschreibungssprache nachrangig. Und an diesem "seine Hardware kennen und und mit Verständnis einsetzen können" schwächelt es dann doch sehr oft.
Wenn man mal einen Schritt zurück geht sieht man, dass FPGAs ein Bereich eines Kontinuums an Lösungsmöglichkeiten für Probleme sind.
Das Kontinuum geht im Prinzip von Systemen die (relativ) langsam, dafür komplex steuern müssen für die man Mikrocontroller verwendet, bis hin zu relativ einfachen Dingen die aber sehr schnell sind. Irgendwo dazwischen sind FPGAs.
Ich weiß jetzt nicht ob FPGA-Entwickler als Beruf etwas erstrebenswertes wäre, denn eigentlich möchte man ja als Ingenieur erst das Problem verstehen und dann die sinnvollsten Werkzeuge dafür auswählen.
Ich weiß jetzt nicht ob FPGA-Entwickler als Beruf etwas erstrebenswertes
wäre, denn eigentlich möchte man ja als Ingenieur erst das Problem
verstehen und dann die sinnvollsten Werkzeuge dafür auswählen.
Stimmt irgendwie, aber da heute überall Digitaltechnik drinsteckt, ist halt FPGAs überall drin.
Es gibt auch andere Debuggingmöglichkeiten. Moderne Interfaces kann man
meist simulieren und dann auf der Hardware gibt es viele Signale zum
Debugging die man angucken kann. Auch das nicht mit dem Oszi sondern mit
dem ILA/SignalTap.
Ich meinte schon durchaus die Elektronik. Da gibt es wenig zu simulieren, um zu sehen, was sich auf den Leiterbahnen tut. Simulieren und mit Signaltap angucken geht nur das digitale Signal. Das ist trivial.
Es geht z.B. um das geschickte Setzen von preemp-Bits, deren Justierung an den Ports, um Signalanstiege zu beeinflussen. Oder z.B. geschicktes frequency spreading, Einsatz von Delays um Ports zu symmetrieren.
Da kommst du mit den internen tools nicht weit. Selbst mit IBERTs nicht.
Es geht nicht darum, dass man "VHDL" kann, sondern dass man "Hardware"
kann.
Das meine ich ja.
Nur ist es eben so, dass die meisten JOBs im Bereich FPGA solche lauen Programmierjobs sind, die wirklich jeder kann. Das wollte ich dem TE vermitteln.
Aus technischer Sicht ist FPGA heute fast nur noch CORE reinwerfen,
anschließen und simulieren.
Bei mir besteht FPGA-Entwicklung eigentlich nie aus 'Core reinwerfen', weil für die Aufgaben, die ich mit FPGA lösen muß, keine Cores zur Verfügung stehen...
Aus technischer Sicht ist FPGA heute fast nur noch CORE reinwerfen,
anschließen und simulieren.
Bei mir besteht FPGA-Entwicklung eigentlich nie aus 'Core reinwerfen',
weil für die Aufgaben, die ich mit FPGA lösen muß, keine Cores zur
Verfügung stehen...
Ausser selbstgeschriebenen Cores. Oder selbst-adaptierten (Filterkoeffizienten berechnet). Und auch das "Reinschmeissen" ist nicht "Kindergarteneinfach", da braucht es auch schon Wissen/Fähigkeiten aus dem bereich Computerarchitektur (Addressmapping, FIFO-Configuration, wissen was RAM/ROM/CIM kann und was nicht, synchronisation wo und wie, handshake, synchronisation, Takterzeugung, Verteilung, ...)
Aus dem vollen Zitat wird deutlich das hier lediglich von SoCs gsprochen wird, beim denen das Processing vom CPU Core gemacht wird:
" .. nur .. noch CORE reinwerfen, ... Das Meiste wird von den Prozessoren in den SoCs abgewickelt, von daher ist C Pflicht und macht einen immer größeren
Anteil aus."
"Das Meiste" bedeudet meiner Meinung nach nur Peripherie Configuration und "Housekeeping". Schön wenn auf dem SoC ein Linux läuft, aber das eigentliche FPGA-design läuft auch ohne den "Softwareschmuss".
das eigentliche FPGA-design läuft auch ohne den "Softwareschmuss".
wobei:
manche FPGA-Cores wirklich SW brauchen, um zu laufen.
immer mehr Personen das Wort "FPGA" mit SoC gleichsetzen:
Gerade heute wieder kam ein Angebot rein, wo ein "FPGA-Programmierer" gesucht wurde. Offenbar geht es NUR! um die SW, denn von VHDl war z.B. keine Rede. Es ist nur Python und C/C++ gefragt. Und es sind definitiv keine Treiber auf einem Controller, der den FPGA treibt, sondern tatsächlich der Code für die ARMs.
Eventuell sollte man mehr drauf achten, dass das Wort FPGA wirklich nur für die PL genutzt wird und die PS getrennt erwähnt wird?
Ich hatte direkt die Gelegenheit genutzt, das vorsichtig einzuwerfen, was bei dem Projektgeber überhaupt nicht gut ankam. Die Neo-FPGA-Fraktion hat eine sehr stabile Meinung über sich und ihr Wissen. Definieren die Welt auch gerne mal neu. ... auch ein Punkt, der zu der Frage "FPGA Zukunft" dazu gehört: Man hat es mit arrogantem Nachwuchs zu tun, die Begriffe um deuten.
Die Stelle ist übrigens für einen "Senior-FPGA-Entwickler" ausgeschrieben. In Klammern steht dann etwas von 3-5 Jahren. Aha!
immer mehr Personen das Wort "FPGA" mit SoC gleichsetzen:
Ist auch noch nicht eindeutig. Ja, es gibt Mischlösungen als Hardware wie den Zynq die auch gerne als "FPGA" benannt werden. Und dann gibt es echte reine FPGAs die aber als SoC verwendet werden. Mit CPU und Fertigbaukastenteilen vom FPGA-Hersteller.
Aber SoC mit FPGA kann dann Alles sein vom reinen Zusammenklicken und dann hauptsächlich Software für eine CPU schreiben bis hin zu sehr viel selber in einer HDL implementieren und da steckt auch noch irgendwo eine CPU für leichtere Hausmeistertätigkeiten. Das geht von 99% C-Code und 1% Zusammenklicken bis zu 99% eigenem HDL und nur 1% C-Code.
Daher finde ich muss man da schon genau die Tätigkeit kennen. Nur "was mit FPGA" ist zu ungenau.
aher finde ich muss man da schon genau die Tätigkeit kennen. Nur "was
mit FPGA" ist zu ungenau.
Sehe ich auch so: Der Begriff wird immer mehr gedehnt. Früher war FPGA ein vorwiegens "elektrisches" Thema und sonnenklar, dass der, der damit umgeht, ein PCB-Entwickler ist, der das einbaut, anschließt und testet. Vorher wird eben schnell noch das Programm erstellt.
Da dieser Punkt "Programm erstellen" aber heutzutage bei den Monster-FPGAs, die es gibt, eine Angelegenheit von Monaten und ganzen Abteilungen ist, hat sich ein SW-Prozess etabliert. "Innen drin" gibt es daher einen wachsenden Anteil von SW, der nur Ablauf ist und zudem noch SW-Strukturen wie Datenverwaltung beinhaltet, wo zunehmend klassische SW-Entwicklungsprinzipien wie Interprozesskommunikation, Semaphoren, Nutzung gemeinsamer Betriebsmittel eine Rolle spielen. Vom Prinzip her sind Informatiker da auch gar nicht falsch.
Die Bereiche ASIC, FPGA, GPU und CPU verwaschen immer mehr ...