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? Mit besten Grüßen Mardini
:
Verschoben durch Moderator
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.
Mango M. schrieb: > 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. https://numato.com/blog/differences-between-fpga-and-asics/
:
Bearbeitet durch User
Beitrag #7315180 wurde vom Autor gelöscht.
Beitrag #7315292 wurde von einem Moderator gelöscht.
Mango M. schrieb: > 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. 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. 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...).
Christoph Z. schrieb: > Mango M. schrieb: >> 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.
Mango M. schrieb: > 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. Das FPGA hat sich geteilt: 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.
Ach ja, kleines Beispiel: 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.
FPGA-Expert schrieb im Beitrag #7319103: > (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). Schätze das Verhältnis auf 1:5.
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.
Beitrag #7319316 wurde von einem Moderator gelöscht.
FPGA-Expert schrieb im Beitrag #7319277: > 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. FPGA-Expert schrieb im Beitrag #7319277: > Ein bissl VHDL kann heute praktisch jeder. Glaube ich nicht. Ja, viele haben das an der Uni mal gesehen, aber scheitern dann sobald es über die blinkende LED hinausgeht. FPGA-Expert schrieb im Beitrag #7319277: > 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. FPGA-Expert schrieb im Beitrag #7319277: > 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.
:
Bearbeitet durch User
FPGA-Expert schrieb im Beitrag #7319277: > Ein bissl VHDL kann heute praktisch jeder. Da musste ich doch auch noch schmunzeln. 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. Mango M. schrieb: > Und als Junior FPGA Programmierer findet man schnell eine > Stelle/Projekt? Wie üblich: wenn du ein guter Junior FPGA ~Programm~ Entwickler bist, dann durchaus. Zum Thema "FPGA-Programmierer" ist mein Geheimtipp der hier: Beitrag "FPGAs in der Lehre" Wenn du verstanden hast, worum es da geht, dann sehe ich kein Problem mit der FPGA-Karriere.
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.
Christian B. schrieb: > Wenn man mal einen Schritt zurück geht sieht man, dass FPGAs ein > Bereich > eines Kontinuums an Lösungsmöglichkeiten für Probleme sind. Nein. Kein Continumm. Mikrocontroller = Apfel, FPGA = Birnen! Genauer FPGA=unbestellter Garten, in dem das wächst wofür der Gärtner seinen grünen Daumen hat.
Christian B. schrieb: > 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.
Gustl B. schrieb: > 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. Lothar M. schrieb: > 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.
FPGA-Expert schrieb im Beitrag #7319029: > 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... Duke
Duke Scarring schrieb: > FPGA-Expert schrieb im Beitrag #7319029: >> 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".
Entschlipser schrieb: > das eigentliche FPGA-design läuft auch ohne den "Softwareschmuss". wobei: 1) manche FPGA-Cores wirklich SW brauchen, um zu laufen. 2) 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!
FPGA-Expert schrieb im Beitrag #7320091: > Simulieren > und mit Signaltap angucken geht nur das digitale Signal. FPGA-Expert schrieb im Beitrag #7320091: > Da kommst du mit den internen tools nicht weit. Selbst mit IBERTs nicht. Aktuelle FPGAs können da auch das ganze Augendiagramm liefern. FPGA-Expert schrieb im Beitrag #7320360: > 2) 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.
Gustl B. schrieb: > 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 ...
:
Bearbeitet durch User
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.