Om een traditionele processor voor je aan het werk te zetten, schrijf je software in een programmeertaal, die door een compiler wordt vertaald in instructies die de processor snapt. In de processor wordt dat weer vertaald in opdrachten voor de rekeneenheden. Dat kan natuurlijk efficiënter en sneller, want al die vertaalslagen leveren vertraging op. Door asics, of application specific integrated circuits, te gebruiken of door chips te maken die slechts een enkele taak kunnen uitvoeren, hoef je niet te programmeren. Je verliest daarmee echter flexibiliteit; wil je iets anders berekenen, dan heb je een nieuwe asic nodig. Met fpga’s krijg je het beste van beide werelden: de snelheid van asics met de flexibiliteit van normale processors. Hoe werkt zo’n fpga, en wat kun je ermee?
Op 1 juni in 2015 maakte Intel bekend dat het zijn grootste overname tot die tijd rond had. Ook sindsdien heeft de chipfabrikant nog geen grotere overnames gedaan, hoewel Intel één keer aardig in de buurt kwam. Intel betaalde in 2015 maar liefst 16,75 miljard dollar, destijds ongeveer 15,3 miljard euro, voor Altera, een bedrijf waarvan de gemiddelde consument waarschijnlijk nog nooit had gehoord. Niemand zal een door Altera gemaakte processor in zijn laptop of desktop hebben, maar wat maakte Altera dan wel dat zo'n enorm bedrag waard was?
Het antwoord is: fpga's, kort voor field programmable gate arrays. Die techniek is niet nieuw en is afgeleid van gate arrays, chips waarbij wel de transistors van een chip werden geproduceerd, maar de laatste metaallagen om ze te verbinden op een later moment werden gemaakt, op een door de afnemer gespecificeerd patroon. Zo konden uniforme gate arrays worden gemaakt en met variatie in de onderlinge verbindingen specifieke toepassingen in hardware worden gedefinieerd. Dat drukte de kosten om complete custom chips te ontwerpen, maar de prestaties waren wel minder dan die van een asic. Begin jaren tachtig werden gate arrays in onder meer de ZX81, de ZX Spectrum en de BBC Micro gebruikt: iconische, maar vooral goedkope thuiscomputers.
Twee eenvoudige, radiation-hardened fpga’s voor de ruimtevaart, zonder heatspreader. Beide chips hebben 72.000 logic gates in 6036 modules en 360 i/o-pinnen, foto Klabs.org
Fpga-structuur
De uncommitted logic arrays of gate arrays werden rond 1984 opgevolgd door volledig programmeerbare chips. In dat jaar kwam het voornoemde Altera met zijn eerste programmeerbare rom-chip en concurrent Xilinx bracht een jaar later een echte fpga uit, met slechts enkele tientallen logic gates. Dankzij steeds geavanceerdere lithografieprocessen kunnen cpu's en gpu's met steeds meer transistors gemaakt worden. Door die voortschrijdende techniek worden echter ook fpga's steeds krachtiger en daarmee breder inzetbaar. De geschatte totale markt voor fpga's was in 2019 ongeveer 9 miljard dollar en die waarde zou in het komende decennium jaarlijks met ongeveer tien procent groeien. Een moderne fpga heeft miljoenen programmeerbare gates en daarnaast een enorme hoeveelheid i/o. In eenvoudige fpga's konden alle gates nog individueel aangestuurd en met de fabric verbonden worden, maar inmiddels is de complexiteit dermate toegenomen dat de gates in blokken verdeeld worden.
Het idee achter die fpga's is dat fabrikanten elke gewenste functie achteraf in een fpga kunnen implementeren, zodat dezelfde chips verschillende functies kunnen vervullen. Daarbij gaat het vooral om zeer specifieke taken, waarvoor traditioneel een asic gebruikt werd. Zo'n chip kan slechts één taak uitvoeren, maar kan dat zeer efficiënt wat hardware en energie betreft. De benodigde logica voor de gewenste bewerkingen is namelijk in de hardware ingebakken; er is geen abstractie met instructiesets nodig. Die asics zijn in de praktijk ook de grootste concurrent voor fpga's. Daarbij bieden die laatste het voordeel dat één chip verschillende functies kan vervullen, waar je voor elke toepassing een aparte asic nodig zou hebben. En omdat de fpga's programmeerbare logica aan boord hebben, kun je net als bij asics functionaliteit hardwarematig laten uitvoeren. Overigens, zoals we straks zullen zien, kun je ook complete processors of microcontrollers in een fpga bouwen, zolang je maar voldoende gates om mee te werken hebt.
De schematische opbouw van een fpga met de clb's onderling en met i/o-blokken verbonden via de programmeerbare interconnects, foto van AllAboutFPGA
Om dit principe wat handen en voeten te geven, doen we een gedachte-experiment. Stel: je wil een supereenvoudige bewerking doen waarbij je twee waarden wil laten optellen. Bij een reguliere processor schrijf je dan een programma in een programmeertaal waarbij je de processor opdracht geeft a en b bij elkaar op te tellen en de resulterende waarde c als output te geven. Dat kun je echter niet zomaar aan de processor vertellen; daar zijn instructiesets voor die je opdracht vertalen in de machinetaal die de processor begrijpt, en die vervolgens vertaald wordt in de stappen die de integerblokken moeten aansturen. Dat werkt fantastisch en we doen het elke dag miljarden keren, maar er zijn nogal wat stappen voor nodig, met latency als gevolg. En wat als je niet één keer zo'n optelsom wil doen, maar miljoenen of miljarden keren? Je moet elke keer wachten tot de pipeline van de processor weer ruimte heeft voor nieuwe instructies en, afgezien van cores en threads, is er niet enorm veel parallelliteit.
Bij een asic daarentegen kun je logische blokken bouwen met elementaire bouwstenen voor processors: gates, die alleen maar twee waarden optellen en de output doorgeven. Met een paar gates kun je dat bewerkstelligen en het enige dat je nieuwe asic kan, is de inputs die je geeft, optellen en als output geven. Wil je nu aftrekken in plaats van optellen, dan moet je een nieuwe asic bouwen. Met een fpga kun je ook met gates zo'n 'optelchip' maken, maar je hoeft geen nieuwe chip te ontwerpen, bouwen of kopen als je wil aftrekken in plaats van optellen. Je programmeert je fpga simpelweg opnieuw en je hebt een 'aftrekchip'. En om het eerder genoemde parallellisme er weer bij te halen: als je heel veel tweetallen bij elkaar wil optellen of van elkaar wil aftrekken, kun je dat in een fpga parallel doen, zolang je maar voldoende gates en i/o hebt.
De opbouw van een adaptive logic module of alm in een Stratix IV-fpga. De acht inputs van de look-uptables kunnen opgedeeld worden, bijvoorbeeld in twee 4-lut's voor backward compatibility, foto Intel
We hadden het al even over de structuur van een moderne fpga, waarbij je idealiter elke gate zou aansturen en van elke gate zou kunnen aangeven hoe die met andere gates en i/o-pinnen verbonden is. In dat geval zouden de verbindende metaallagen echter veel te complex en te traag worden. Bovendien zou het programmeren tijdrovender worden naarmate de complexiteit toeneemt. Daarom worden fpga's opgebouwd uit configurable logic blocks, waarin logic cells zijn ondergebracht. Het verschilt per fabrikant en ook weer per fpga-familie hoe die clb's zijn opgebouwd. Ook de naamgeving verschilt per fabrikant.
Schematische opbouw van een configurable logic block met daarin twee logic cells, ieder opgebouwd uit een look-uptable of lut met vier inputs, een fma-blok en mux, en een flipflop, foto van AllAboutFPGA
In die cellen zitten niet alleen verschillende gates, maar ook additionele hardware, zoals een flipflop, een adder of optelschakeling en een multiplexer. De programmeerbare gates worden aangestuurd door hun look-uptables, of lut's, te definieren. De truth table van die lut vertelt de gates hoe ze zich moeten gedragen. Meestal bestaat een lut in een cel uit vier inputs, al dan niet gesplitst in twee keer drie inputs, maar ze zijn er ook met zes inputs.
De clb's zijn weer met elkaar en met i/o-clusters verbonden via interconnects, die op hun beurt door 'schakeldozen' met elkaar verbonden zijn. Net als de clb's zijn ook die i/o-blokken configureerbaar en ook de routering van de signalen is programmeerbaar. Sommige fpga's hebben nog extra functionele units in de vorm van een ARM-processor of dsp-blokken om veelvoorkomende functies uit te voeren. De i/o-blokken, waarmee de clb's verbonden worden, kunnen bovendien worden aangevuld met dedicated i/o-structuren, zoals PCIe-controllers, geheugencontrollers en netwerkcontrollers.
Het nut van fpga
Nu we meer weten over wat zich onder de motorkap van de fpga-chips afspeelt, kunnen we kijken waarvoor ze gebruikt worden. Zonet hebben we al aangehaald dat ze vooral geschikt zijn om heel snel data te kunnen verwerken, en dat ze dat op verschillende manieren kunnen doen doordat hun functie on-the-fly kan worden veranderd. Een logische taak waarvoor ze daarom worden ingezet, is het manipuleren van data. Veel netwerkapparatuur, zoals routers en switches, hebben fpga's aan boord. Dan gaat het niet om de Linksys in je meterkast, maar om apparatuur voor de netwerkinfrastructuur. Ook in andere data-intensieve toepassingen worden fpga's gebruikt, zoals bij optische netwerken en zendmasten voor telecommunicatie. Sterker, dat laatste is waarvoor Intel de door Altera geproduceerde fpga's gebruikt: 5G-netwerken moeten immers met veel standaarden overweg kunnen en door de radio's van fpga's te voorzien, kan een basisstation voor vele protocollen worden ingezet.
Voor supercomputers zijn de vele i/o-pinnen en de enorme bandbreedte daarvan juist weer interessant. Bij supercomputers worden immers terabytes aan data verplaatst tussen clusters en fpga's krijgen dat met zeer lage latencies voor elkaar. Dat is ook interessant voor wetenschappelijke doeleinden, waarbij grote hoeveelheden data gegenereerd worden. Denk aan de Large Hadron Collider of de arrays aan radiotelescopen die het heelal aftasten. Neem in die laatste categorie als voorbeeld de array radiotelescopen van Astron in Westerbork, met de van de tong rollende naam Westerbork Synthesis Radio Telescope - Aperture In Focus, of WSRT-Apertif in het kort. Deze maakt gebruik van custom hardware met fpga's voor signaalverwerking van de stroom data van de arrays. Die UniBoards zijn borden met Arria 10-fpga's van Intel/Altera en een latere generatie Gemini-borden met Xilinx Virtex-fpga's. De fpga-clusters moeten 5,8Tbit/s verwerken, ongeveer evenveel als wordt verwerkt door ons belangrijkste landelijke internetknooppunt, de Amsterdam Internet Exchange.
Een van de oorzaken waardoor fpga's zo snel zijn, is dat ze zeer lage latencies hebben. Bij een fpga is een realistische latency van een ordegrootte van één microseconde realistisch, waar processors als cpu's en gpu's latencies van tientallen microseconden hebben. Dat is deels dankzij het ontbreken van een compiler die opdrachten moet vertalen in code die de processor snapt, en deels doordat de in- en outputs direct worden aangesproken en niet via systeembussen worden benaderd.
Het UniBoard 2 dat door Astron werd ontwikkeld om de data van radiotelescopen met fpga's te verwerken, foto van Astron
Dat laatste, het direct benaderen van i/o-pinnen, is waarom fpga's zo nuttig zijn voor de verwerking van sensordata, zoals in het voorbeeld van de Astron UniBoards. De ruwe data kan direct verwerkt worden zonder een latency- of vertaalslag van die data. Dat maakt het mogelijk om veel meer bandbreedte te verwerken dan mogelijk zou zijn met een generieke processor. Ook voor realtime conversie van videosignalen worden fpga's ingezet, bijvoorbeeld in de broadcastsector, maar ook in settopboxen onder de tv.
Bij het ontwikkelen van processors, of asics, kunnen fpga's ingezet worden om een ontwerp te testen en valideren voordat het in silicium wordt gemaakt. Een ontwerp in een fab itereren is immers niet alleen erg duur vanwege de kosten van masks, maar ook bijzonder tijdrovend doordat de vele stappen die nodig zijn om van een wafer een verzameling werkende chips te maken, de doorlooptijd zeer lang maken.
Programmeren
In theorie kun je elke gate in een fpga-chip individueel programmeren, zodat je een circuit opbouwt uit gates als NAND, NOR, AND en OR, maar dat is alleen leuk als je enkele tientallen gates zou programmeren. Omdat je voor een logic block de bijbehorende lut en het gedrag van de overige logica moet programmeren en voor elke interconnect een stel switches moet programmeren, wordt het al snel onoverzichtelijk. Bij het programmeren van complexere fpga's zou dat een extreem lastige, langdurige en foutgevoelige exercitie zijn. Daarom zijn diverse programmeertalen ontwikkeld om fpga's op een hoger niveau te programmeren en de programmeertaal het zware werk te laten doen. Denk maar eens hoe lastig het zou zijn om een complex circuit met de bekende 7400-ttl-chips te bouwen. Het is mogelijk, maar knap lastig om daarmee iets te bouwen dat veel complexer is dan een 8bit-computer.
De hardwareconfiguratie van fpga's wordt in de regel gedefinieerd door sram-cellen. Die zijn verantwoordelijk voor de routering van de datalijnen en de definitie van de luts en geassocieerde hardware in een logic block. Het programmeren van een fpga-chip vertelt de chip dus welke waarden die sram-cellen moeten krijgen en zo welke hardware 'gemaakt' moet worden. Daarom wordt zo'n programmeertaal een hardware description language genoemd; hij beschrijft immers de hardware die in de fpga geprogrammeerd moet worden.
Een voorbeeld van een schema zoals gegenereerd door Vivado, een ontwikkeltool van Xilinx.
Programeertalen als VHDL of Verilog maken het programmeren wat abstract en laten je fpga's programmeren door register transfer levels te programmeren. Je weet dus wat je inputs en wat je outputs zijn voor een stap of blok. Dat maakt het programmeren nog steeds erg lastig en allesbehalve laagdrempelig. Bovendien is het goed mogelijk dat het programma dat je schrijft, prima werkt in de softwaresimulatie, maar in de praktijk in een fpga niet werkt, bijvoorbeeld door problemen met timings.
Een nog verdere abstractie van een hdl is een objectgebaseerde programmeertaal als SystemVerilog of Labview. Daarmee kun je C-varianten in je code importeren of zelfs grafisch programmeren. Het risico van een hoger abstractieniveau is echter een minder efficiënt gebruik van hulpmiddelen. Het is goed mogelijk dat de interpreter voor relatief eenvoudige functies een enorme hoeveelheid logica wil inzetten, met weer gevolgen voor de werking in de praktijk van zo'n schema. Met uitgebreide verificatiesoftware is dat tegen te gaan en met steeds meer elementen in een fpga die zuiniger en goedkoper zijn dankzij de Wet van Moore, hoeft hardware geen beperkende factor te zijn.
Fpga's voor de hobby
Als je een hardwareontwikkelaar bent en veel met asics werkt, is de kans groot dat je al met fpga's in aanraking bent gekomen. In dat geval heb je ongetwijfeld ook al ervaring met hdl-programmeren, maar wat heb je nu als consument aan een fpga? Los van de eerder genoemde toepassingen van fpga's, waarvan je er waarschijnlijk zonder het te weten al een aantal in huis hebt gehad, kun je ook zelf aan de slag met fpga's, omdat het kan.
De Saxo-L, een fpga-ontwikkelbordje met Altera Cyclone-fpga aan boord met 2910 logic cells. Het bordje kost slechts ongeveer 60 euro.
Waar fpga's vroeger buiten het domein van de hobbyist lagen, is daarin in de laatste jaren in rap tempo verandering gekomen. Door een combinatie van toegankelijkere software om ze te programmeren en steeds goedkopere developmentkits kan iedereen met een gezonde dosis interesse aan de gang met logic gates en een chipontwerp in hardware reproduceren. Een van de aanjagers daarvoor is de retrogamebeweging, al is het maar omdat de gamehardware van weleer dermate 'eenvoudig' was dat je die nu op betaalbare fpga's kunt nabouwen.
Arty S7-25, een ontwikkelbordje voor hobbyisten van 99 dollar met een Xilinx Spartan-7-fpga aan boord
Natuurlijk kon je, met de rauwe rekenkracht van een Core- of Ryzen-processor, met gemak een oude Game Boy of PlayStation emuleren. Bij gebrek aan the real thing kun je echter met een fpga zo dicht mogelijk in de buurt komen van het authentieke gevoel van een retroconsole. Een populair ontwikkelbord voor doe-het-zelf-fpga'ers is de DE10-Nano, een fpga-bord van Terasic Technologies. Het bord heeft een Intel/Altera Cyclone V-soc aan boord. Die fpga-soc heeft niet alleen twee Cortex A9-cores, maar ook 110.000 programmeerbare logic elements, goed voor 41.500 adaptive logic modules met 140 i/o's. Die i/o-pinnen zijn onder meer beschikbaar in standaard 40-pinsblokken voor compatibiliteit met Raspberry Pi-hats. Daarnaast zijn er pinnen die als Arduino Uno-pinnen met shield-compatibiliteit gebruikt worden, en pinnen die op knoppen en schakelaars zijn aangesloten.
De hardware is daarmee bij uitstek geschikt voor hobbyisten en het bordje kost slechts 130 dollar, omgerekend ongeveer 110 euro. Daarvoor krijg je niet alleen een hoop rekenkracht, maar ook een hoop aansluitmogelijkheden. Zonder software en 'programma's' voor de fpga doet de DE10 echter niets en daar komt de andere pijler die voor doe-het-zelvers belangrijk is, om de hoek kijken: de opensourcecommunity. Op GitHub is namelijk het MiSTer-project te vinden, dat je helpt bij het gebruik van je fpga om oude consoles en computers weer tot leven te brengen. En anders dan bij emulatie in software weet je dat het systeem op je fpga functioneel identiek is aan de oude hardware. Dat heeft, naast een gevoel van accuratesse, als voordeel dat alle perifere apparatuur en accessoires ook native met je fpga-systeem samenwerken.
Het DE10-Nano-bord met centraal de Altera Cyclone V-fpga
Op iets kleinere schaal kunnen bijvoorbeeld optische drives met een fpga-bordje worden geëmuleerd, zodat je zonder modificaties aan je console back-ups van games kunt benaderen. Zo kun je een Dreamcast-drive emuleren met een Lattice iCE40-HX8K break-outbord. De fpga daarop beschikt over 7680 logic elements, verdeeld over 960 logic array blocks, of lab's. Ook voor deze set-up is weer een opensourceproject op GitHub beschikbaar en bovendien is een complete toolchain om met de iCE-fpga's te werken beschikbaar.
Als laatste retrogamingvoorbeeld noemen we de Analogue Pocket. Dat is een, uiteraard draagbare, Game Boy-kloon die is opgebouwd met behulp van twee fpga's, waarop zonder emulatie alle generaties Game Boy-games gespeeld kunnen worden. Leuk detail daarbij is dat slechts één fpga gebruikt wordt voor die Game Boy-'emulatie'. De tweede is bedoeld voor ontwikkelaars die hun eigen implementaties kunnen maken. De Analogue Pocket is vooralsnog alleen als preorder verkrijgbaar, maar de bouwers hebben al een flink ecosysteem van accessoires ontwikkeld. Bovendien hebben ze al ervaring met de fpga-emulatie van onder meer de Sega Genesis en Mega Drive, en de SNES.
Ten slotte mag het geen geheim zijn dat Doom, id Softwares 3d-titel uit 1993, inmiddels naar bijna alle hardware die sindsdien is uitgekomen, is geport. Als je magnetron een microcontroller heeft, is de kans groot dat iemand heeft geprobeerd om Doom erop te krijgen. Dat zijn echter allemaal software-implementaties, maar op een fpga kun je ook Doom in hardware draaien. Nou ja, het eerste level dan, en zonder monsters, maar het is een mooi bewijs van enerzijds de mogelijkheden van fpga's en anderzijds de verbeterde toegankelijkheid van en toenemende interesse in een familie silicium die ooit ver buiten de hobbysfeer lag.
Ik ben eigenlijk een beetje verbaasd over dit artikel... waar komt het vandaan dat FPGA's in de opmars zouden zijn? Ik ben intussen al 20 jaar bezig met FPGA's en heb nou niet de laatste tijd bijzondere ontwikkelingen gezien. Voor zover ik weet zijn FPGA's altijd al groot geweest.... in bepaalde industrieën. Het is meer alsof de Tweakers redactie nu ineens FPGA's heeft ontdekt...
Zolang ik me kan herinneren hebben de Xilinx en Altera (nu Intel) altijd wel betaalbare ontwikkelborden gehad voor hun goedkopere producten. $100 was IMHO dan vaak een prijspunt voor de interessante borden. Eerst bijvoorbeeld op basis van de Spartan 3, toen de Spartan 6, etc. En later de SOC worden (met ARM cores)
Ook een FPGA met ARM core aan bord is niets nieuws. Xilinx heeft sinds 2011 al de Zynq series in z'n assortiment. Die weer te krijgen was op de Zedboard. Die waren in het begin wat duur voor de hobbyist ($500), maar er zijn al tijden betaalbare SOC bordjes verkrijgbaar.
Ook qua software is er weinig veranderd. FPGA's worden nog steeds geprogrammeerd in Verilog en VHDL. Wat tegenwoordig wat vaker gebruikt worden zijn zgn "high-level synthesis tools" die C/C++ code om kunnen zetten in verilog/vhdl. Maar dat is ook alweer 5 jaar oude technologie.
Speaking of which, in het artikel wordt gelinkt naar een site die de moderne FPGA architectuur zou beschrijven... dat gelinkte artikel is alweer 6 jaar oud. Dat is een eeuwigheid in de technologiesector. En ook de overname van Altera door Intel die in de introductie genoemd wordt is alweer 5 jaar geleden.
Kortom, in mijn ogen beschrijft dit artikel niets nieuws...
Er zijn zeker steeds nieuwe ontwikkelingen in de FPGA wereld, maar die worden hier niet genoemd.
[Reactie gewijzigd door MeMoRy op 22 juli 2024 14:21]
Ik denk eerder dat de fpga's in opmars zijn bij het "gewone publiek". Je ziet nu bij steeds meer hobby electronica projecten, dat er een Arduino of Raspberry Pi gebruikt word. FPGA's in zulke projecten zijn voorlopig nog een zelfdzaamheid.
Zelf ben ik heel toevallig op de Nano DE-10 op m'n weg tegengekomen via het Mister project. Onlangs een Vampire V4 SA gekocht, een FPGA based Amiga 68080 bord, en zo kwam ik terecht op het Mister project. Heb hem meteen betsteld omdat het me wel fijn lijkt om een FPGA te programmeren, just for fun.
... omdat het me wel fijn lijkt om een FPGA te programmeren, just for fun.
Dat heb ik meer mensen horen zeggen, maar veel heb ik ook weer de handdoek in de ring zien gooien. Het zal best een steile leercurve zijn. Als je hulp nodig hebt kan je o.a. op stack overflow kijken. Maar nog steeds kost het veel effort om een simpele toepassing te maken. Succes!
[Reactie gewijzigd door MeMoRy op 22 juli 2024 14:21]
Op https://forums.xilinx.com/ kan je allesinds terecht om hulp te krijgen. Op http://zedboard.org/ bvb kan je terecht voor voorbeeld designs en meer, en hebben ze ook een forum voor hulp te krijgen. Misschien daar kijken mocht je nog eens aan de slag willen gaan met FPGA's?
Precies wat ik zelf ook gezien heb. Ik ben tig jaren bekend met FPGA's maar heb interesse bij een groter publiek gezien met de komst van retro gaming projecten zoals de genoemde Mister. Ook tijdens de Cryptocurrency boom was er een enorme toename in FPGA gebruik om naast GPU's en ASIC's in een grote oplage mee te minen.
Exact, ik zou eerder zeggen dat ze een jaar of 5 á 10 geleden juist in opmars waren.
Ergens in die periode kwam Lattice met een aantal goedkope FPGA's en zeer uitgebreide CPLD's met bijbehorende ontwikkelbordjes die het ontwikkelen voor consumenten heel aantrekkelijk en goedkoop maakten.
In die tijd begon je ook FPGA's te zien in de mod wereld, met onder andere:
Mod-chips voor de Wii met een FPGA gebaseerd waren (althans, deze werden geadverteerd als FPGA oplossingen maar het waren in feite CPLD's).
Flash kaarten voor de DS en 3DS die gebaseerd waren op een FPGA.
FPGA gabaseerde console emulatoren zoals de Super Nt, MiSTer, Vampire V4, etc.
[Reactie gewijzigd door knirfie244 op 22 juli 2024 14:21]
Ik denk dat het artikel wat duidelijker had kunnen maken dat de opmars vooral in de hobby hoek zit incl de 8 bit pc/game implementaties. Meeste tweakers zullen niet beroepsmatig met fpga/cplds bezig zijn dus voor die doelgroep is het een nieuwe opmard
Dat is ook niet zo nieuw... Voorbeeld: de Z80 op FPGA is alwaar 6 jaar oud. De Minimig, een atari op FPGA, is al 15 jaar oud, etc, etc..
Als je op sites als [Hackster.io](https://www.hackster.io/projects/tags/fpga) kijkt, dan zie je ook genoeg projecten met FPGA's die 5 tot 10 jaar oud zijn.
"Opmars" insinueert dat het iets van afgelopen jaar is. Nou begrijp ik dat ivm corona meer mensen thuis zitten, dus meer dit soort dingen oppikken, maar toch lijkt me dit niet echt iets nieuws.
Ik durf de aantallen niet zo 123 te schatten en omdat ik zelf via mn werk wel al met fpga's te maken heb had ik al meer interesse in de mogelijkheden en toepassingen dan de gemiddekde hobby tweaker en dus zag ik wel links en rechts leuke toepassingen. Maar ik had wel het idee dat de bredere belangstelling vanuit de hobby hoek recentelikk (1-2-3 jaar) flink toenam. Inderdad ggen plotse explosie maar meer een gestage groei. Dat dan een vrij 'brede' site als Tweakers dat (uiteindelijk?) Oppakt en er een lang artikel over maakt zie ik dan als positief. Dat het voor de serieuze hobbyist dan vooral 'oud nieuws' bevat is dan logisch; maar denk dat er -ook binnen de tweakers lezers- voor veel mensen nog volstrekt onbekende materie is en kan ik me goed voorstellen dat het voor velen lijkt dat er idd iets van een opmars bezig is. En als je het attikel leest (tenzij content gewijzigd is nav jouw opmerkingen) wordt duidelijk gemaakt dat de techniek idd helemaal niet nieuw is en dat het meer een ontwikkeling is dat meer en meer mensen hobbyen met fpgas en dat een gestage groei is in toepassingen en community ondersteuning: maar een kop met een dergelijke omschrijving bekt niet echt.
Mijn voornaamste gevoel is 'eindelijk verdiende aandacht' en begrijp ik de titel/aanduiding vd ontwikkelingen wel. Dat het voor de 'kenner' dan 'wtf; dat wist ik allang' gevoelens oproept is echter ook logisch. Maar tweakers.net is (helaas?) allang niet meer de nerdie site die het ooit was....
Er zijn zeker steeds nieuwe ontwikkelingen in de FPGA wereld, maar die worden hier niet genoemd.
Zelf werk ik niet met FPGA's, maar ik probeer het nieuws altijd wel een beetje te volgen.
Nu zie ik dat Xilinx recent een lijn met ACAP's heeft uitgebracht; o.a. gericht op AI-toepassingen.
Maar wat is nou eigenlijk het vernieuwende van de Versal ACAP's ten opzichte van de bestaande FPGA's?
Een deel van het antwoord staat hier bij punt 2, maar behlave dat de NoC een grote rol heeft en er minder ervaring met hardware nodig is, en er kennelijk een AI-ASIC aan gekoppeld is snap ik nog niet helemaal op welke manier dit een vernieuwing is.
De ACAP's hebben een vast netwerk-on-chip voor data transport tussen interfaces en memory en de vrij programmeerbare delen. Naast standaard FPGA cellen en DSP blokken zitten er ook AI engines in die lijken op AVX-512 of GPU eenheden.
Tegenwoordig zie ik wel steeds meer FPGA's voor een leuk prijsje. Wat dat betreft zijn ze misschien in opmars voor de hobbyist, aangezien ze toegankelijker worden? Voor 1 a 2 tientjes kan je nu zo'n ding kopen. Maar dat is dan ook wel de enige reden die ik zie.
Hier ben ik het absoluut mee eens. Ik zal ook een voorbeeld geven uit de homecomputer wereld, de MSX standaard uit de jaren '80. Het begon bij de MSX, 1983, de opvolger MSX-2, 1985, MSX 2+, 1988, MSX Turbo R (de laatste MSX uit 1990). Het had de wereldstandaard moeten worden. Het was en is nog steeds een populair (inmiddels) retro systeem dat in leven wordt gehouden door FPGA projecten.
Voorbeelden hiervan zijn o.a. Carnivore 2 cartridge, GR8NET cartridge, beiden voegen vele functionaliteit toe aan een MSX waar je normaalgesproken in de jaren '80 en '90 voor elke functionaliteit een aparte cartridge voor nodig zou hebben gehad. Bijvoorbeeld: IDE harddisk interface, netwerk functionaliteit, MSX Audio, MSX Music en extra geheugen in één.
Dit soort oplossingen zijn al een aantal jaren op de markt en was toen wel een trend. Maar anno 2020 in opmars? Neuh.
Edit: vergeet ik nog het belangrijkste project uit 2006, FPGA based: de One-chip-MSX
2006! Het is 2020.
[Reactie gewijzigd door Mr.Master op 22 juli 2024 14:21]
Leuk artikel over een van de mooiere disciplines in mijn vakgebied (Embedded SW en FPGA architectuur). Gezien de complexiteit van FPGA-ontwikkeling is het logisch dat dit artikel echt het topje van de ijsberg schetst.
Er komt zoveel meer kijken bij FPGA-ontwikkeling: IO-bank beperkingen door gedeelde functionaliteit (denk aan DDR4 of PCIe interface; niet beide), Timing-closure (!), IO-standaarden, PLL/DLLs, meerdere klokdomeinen, gebruik van FPGA primitiven zoals BRAM, DSP, UltraRAM, multipliers, SRL16/32s, reset design, routing congestion, het goed gebruik van for-loops - logica kan daarmee 'exploderen' in complexiteit - etc. Te veel om op te noemen. Echter maakt dat alles bij elkaar het werk uitdagend en leuk!
Er is in mijn ogen een groot nadeel aan FPGA-development: debuggen. Afhankelijk van een design kost het 1 uur tot 10/12! uur voordat je een bit-file hebt om te programmeren. Als er dan een foutje in zit dan bouw je vaak een versie met een ILA/ChipScope (soort logic analyser) wat weer zo lang duurt. Dan debuggen, fixen, bouwen (1/10/12 uur), testen, enz. Wij maken producten waar het echt 10 tot 12 uur duurt voordat je een bit-file hebt. Je snapt dat je dan dagen bezig bent voordat je iets (eenvoudigs) gefixt hebt, zeker in een complex design. Uiteraard maken we zeer veel gebruik van ModelSim (simulatie) en (self-checking) Vunit testbenches. Het voordeel is dat je echt goed naar je code kijkt voordat je een bit-file gaat bouwen. 'Debug-driven-development' is het zeker niet :-)
Ikzelf werk met de top-of-the-line van Xilinx (Xilinx UltraScale+ met een list-price van ~64.000$. Dit is eigenlijk een hele grote FPGA met intern vier kleine DIEs/FPGA's; zogenaamde SLRs). Vorig jaar zomer heb ik een volledige 100Gbit/sec Audio/Video 'stack' gemaakt welke real-time meerdere audio en video stromen (tot/met UHD) over een 100Gbit (QSFP) netwerk kan versturen en ontvangen met een efficientie van bijna 100%. De core is ook schaalbaar naar elke ander Ethernet interface zoals 25Gbit/SFP of 10Gbit/SFP. Het is misschien wel interessant om hier wat statistieken van te vermelden:
- Klokfrequentie van 322MHz (100Gbit/sec), 390MHz (25Gbit/sec) of 156MHz (10Gbit/sec)
- Databus breedte: 512-bits (100Gbit) of 64-bit (25Gbit/10Gbit)
- Synthese+routing in een development applicatie: 1h20m
- Synthese+routing in een volledig product tezamen met nog veel meer andere (complexe) logica: 10/12h
- Bit-file grootte: ~55MByte voor de development versie; ~90MByte voor het product
- Tools: Vivado 2019.1, ModelSim DE voor simulatie, VUnit voor (zelf-checking) testbenches
Al met al zijn FPGA's geweldige dingen waar je veel mee kan, vooral real-time.
[Reactie gewijzigd door Anteros op 22 juli 2024 14:21]
Synthese an-sich weet ik niet zo uit mijn hoofd. Een enkele strategy run (synthese+routing) voor een product kan tot 64GB gebruiken. Wij hebben 128GB RAM in onze systemen en gebruiken een Intel i9-9900X op 3.5GHz.
[Reactie gewijzigd door Anteros op 22 juli 2024 14:21]
Hoe zijn je ervaringen met VUnit? Ik ben zeer nieuwsgierig naar hoe anderen omgaan met verificatie!
Wij gebruiken SV plus ons eigen framework (drivers, monitors, scoreboards, ...) om randomised te kunnen testen maar we lopen tegen de grenzen aan van wat we efficient kunnen modelleren in ons eigen framework.
Ik heb gekeken naar andere frameworks zoals cocotb en myhdl maar tot nu toe sprint niks er echt bovenuit.
[Reactie gewijzigd door zerokill op 22 juli 2024 14:21]
Wat betreft documentatie niet zo best. Maar an-sich as framework goed genoeg voor nu. Het grote voordeel is dat het in VHDL geschreven is is wat meer van onze engineers snappen. Python (Cocotb) is een wat ver-van-mijn-bed show. Ikzelf zou liever het een en ander in Python doen.
Wij gebuiken Gitlab CI samen met Vunit en ModelSim. Elke merge naar develop wordt via GitLab CI gesimuleerd met Vunit+Modelsim en een (self-checking) testbench. Al die testen (soms wel meer dan 400+ per component) en hun resultaten worden opgeslagen. Verder zien we meteen in GitLab CI (en een junit-file) of alle testen 'passed' zijn of niet. Ideaal.
Overigens wil ik nog wel eens naar SystemVerilog kijken omdat ik daar (ook) goede verhalen over hoor.
Leuk verhaal, maar dat is natuurlijk vanuit jouw oogpunt als professional.
Een hobbyist kijkt daar natuurlijk heel anders tegenaan, en zal het wat minder uitmaken hoeveel procent van de FPGA gebruikt wordt door zijn ontwerp, of wat de maximale kloksnelheid is, zolang het maar doet wat het moet doen. Daarnaast kan je tegenwoordig ook FPGA's programmeren via C, LabView, en allerlei andere (visuele) tooling, wat het ook allemaal een stuk toegankelijker maakt.
En met een 1 uur, laat staan 12 uur voor synthese/placement heb je het toch echt wel over een zeer grote FPGA. Bij een gemiddelde Spartan 6 kost doorgaans niet meer als een half uurtje ofzo op een degelijke PC. En op een dedicated server kost het zelfs maar een paar minuten.
Daarnaast is synthese natuurlijk geen debuggen , debuggen doe je in eerste instantie via simulatie.
Verder klinkt dat wel als een leuk project waar je aan werkt, de wereld heeft niet stilgestaan sinds die 1 gigabit single-wire videolink die ik 18 jaar geleden voor mijn afstudeeropdracht ontwikkeld heb.
[Reactie gewijzigd door knirfie244 op 22 juli 2024 14:21]
Vanuit hobby heb je helemaal gelijk. Dan maakt het allemaal niet uit en ben je al blij als er iets uit komt. Maar goed, hobbyen is leuk, maar is dus totaal anders als je de professionele wereld ingaat. Als je bv niet aan de timing-constraints voldoet, dan kan het wel LIJKEN dat je design werkt, maar dat is dan geen garantie. Afhankelijk van temperatuur, luchtvochtigheid, procesvariaties, kwaliteit van de voedingspanningen, enz werkt je design soms wel, soms niet. Daar kan je professioneel niet mee wegkomen. Dit staat overigens helemaal los of je in C, Verilog, VHDL, etc programmeert. Initieel maakt het de boel toegankelijk, maar zeker niet makkelijker.
Vwb synthese. Dat klopt, het zijn ook (zeer) grote designs. Zoals ik zal zei, het is een van de grootste FPGA die er te krijgen is. Daar betaal je niet alleen dik geld voor, maar dus ook doorlooptijd. Overigens is een Spartan 6 eeuwen oud en totaal niet te vergelijken met de huidige FPGAs.
Wij hebben overigens een dedicated server park met wel 10 tot 15 machines die elk 128GB RAM en een i9 hebben. Dan nog ben je zo lang bezig. FPGA synthese (en vooral het routen) is single threaded. Een hogere klok brengt meer performance dat tig-cores. Geloof me, we doen er alles aan om de doorlooptijd te verkorten maar helaas gaat dat bijna niet.
Echter gaat dit artikel over gebruik van FPGA's door hobbyisten, dus dat is het voornaamste onderwerp hier, niet het gebruik door professionals
En ook hobbyisten kunnen opletten of de synthese slaagt of niet, als je timing constraints niet behaald dan rolt dat gewoon als warning of error uit de tooling. Natuurlijk moet je wel weten dat je daar op moet letten.
En ja, de Spartan 6 is best een oud beestje, maar wel nog steeds één van de meestgebruikte FPGA's ter wereld, talloze consumenten apparaten gebruiken er één. Ondertussen is er de Spartan 7, maar dat ding voldoet gewoon totaal niet aan de eisen van de meeste Spartan 6 gebruikers (te weinig IO, te complexe/dure voeding, etc). Wij gebruiken nog altijd behoorlijk veel Spartan 6jes, en daarnaast her en der een Artix 7 of Virtex 7.
Overigens is Vivado gewoon multithreaded, maar wel met serieuze limitaties: 4 threads voor Synthese en 8 threads voor implementatie. Misschien dat routen inderdaad 1 thread is, maar ik dacht dat dat ondertussen ook multithreaded was. Daarnaast zou je voor synthese ook andere tooling kunnen gebruiken, synthese in Synplify Pro is sowieso vele malen sneller, die werkt wel met meer threads, en kan zelfs het werk verdelen over meerdere machines.
[Reactie gewijzigd door knirfie244 op 22 juli 2024 14:21]
Sorry, maar dit klink meer als 'klok/klepel'... De spartan 6 in 2011 op de markt gekomen (spartan 7 in 2015). Dat vind ik vrij oud. Dat zegt overigens niks of deze wel of niet bruikbaar is.
Verder is 'timing closure' wel wat meer dan 'in de tool kijken of je deze gehaald hebt'. Je moet weten wat je setup/hold tijden zijn, de aanwezige slack, de relatie van signalen tov de klok, de klokfrequentie, hoe je het beste logic kan ontwikkelen zodat je (veel) makkelijker je timing haalt, hoe je het beste reset-circuits kan maken, hoe je hoge fan-out of het aantal logic-levels beperkt, hoe je klokdomeinen het beste kan kruisen, enz. Dit alleen is een vak apart en een groot deel van de kennis die je nodig moet hebben om professioneel met FPGAs te werken (buiten het laten knipperen van een LEDje of iets dergelijks).
Vivado/Quartus zijn natuurlijk multi-threaded. Maar ik heb het niet daarover. Ik heb het over de daadwerkelijke synthese, maar voornamelijk routing wat inherent bijna compleet rust op een enkele core (single threaded). Natuurlijk zijn er (deel) processen die parallel kunnen lopen, maar het overgrote deel van de routing-tijd wordt besteed aan een single thread. Multi-core brengt dus niet zoveel, hogere CPU-klok daarentegen wel.
Spartan 7 is in 2017 in productie gegaan, maar echte verkrijgbaarheid was er niet voor medio 2018, naar mijn mening niet een echt oude FPGA. En nogmaals, het artikel gaat over gebruik door hobbyisten, die kopen geen FPGA's van duizenden euro's, die gebruiken eerder een Spartan, als ze al Xilinx gebruiken.
Daarnaast denk ik dat jij als professional te dicht op de hardware zit waarbij je als taak hebt het onderste uit de kan te trekken, in dat geval zijn al die zaken die je noemt inderdaad rete belangrijk. Echter is er voor de niet (professionele) VHDL ontwikkelaar veel verbeterd in de laatste jaren. Tegenwoordig kan je bijvoorbeeld een model van LabView exporteren naar VHDL, daarna resteert alleen nog copy-paste in Vivado, het toekennen van pinnen, configureren van de PLL, constraints instellen (maar doorgaans is gewenste kloksnelheid meer dan voldoende), en je klikt op 'sythesis & implement'. 99,9% kans dat er gewoon een goede bit-file uit rolt die voldoet.
Zelf schrijf ik tegenwoordig helaas geen VHDL meer, in het verleden heb ik dit wel veel gedaan. Nu is het meer in onze zelf ontwikkelde omgeving wat blokjes bij elkaar klikken, een target PCB selecteren, en op submit klikken. De tooling selecteert nu alle gewenste (in het verleden geschreven) VHDL blokjes, knoopt die op de juiste manier aan elkaar en aan de juiste FPGA pinnen, zet alle timing constraints, en stuurt het project vervolgens naar de server. En een paar minuten later heb ik een BIT file in mijn mailbox zitten
Overigens vind ik wel dat het artikel wat dieper in had kunnen gaan op de tooling die tegenwoordig bestaat.
[Reactie gewijzigd door knirfie244 op 22 juli 2024 14:21]
Ik zou nog even naar de instellingen van Vivado kijken want tijdens het routen (2019.1) kan vivado meerdere threads gebruiken (ik dacht dat het configureerbaar was tot 4).
Hebben jullie moeite met timing closure? Wij hebben daar enorme winst gepakt in onze build time door 30 verschillende implementatie strategieën met 4 threads over 96 cores te verdelen.
Uiteraard hebben wij deze op maximaal staan (want diverse zaken kunnen wel parallel maar de core routing is bijna single threaded). Maar dan nog kan je beter een hogere klok hebben dan meer cores. Dat is wat wij zien en ook wat Xilinx aangeeft. Verder is bouwen onder Linux 20% sneller dan onder Windows (eigen ervaring en ook weer wat Xilinx aangeeft).
Wij hebben ongeveer 20 strategieën over meerdere cores. Dat helpt idd enorm en we krijgen er dan ongeveer 6 tot 10 ‘op tijd’. Dat zou echter nog een stukje kunnen verbeteren als we oude blokken herschrijven naar nieuwe inzichten en architectuur.
Edit: heb je ervaring met 2020.1? Wij willen deze binnenkort evalueren om (oa) te zien of deze efficiënter en daardoor sneller is.
[Reactie gewijzigd door Anteros op 22 juli 2024 14:21]
Wij zitten jammer genoeg vast op 2018.2. Tijdens de evaluatie van 2019 vonden we een placement bug. Xilinx gaat de bug oplossen maar we hebben nog niet de tijd gehad om te kijken of het nu beter is 2020.1.
Overigens werk ik aan FPGAs voor finance toepassingen. Onze eisen zijn iets anders dan de meeste andere gebruikers. Afgaande op je beschrijving verwacht ik dat jullie chip op +90% utilisation zit? Wij zitten in het spelletje van zoveel mogelijk registers willen verwijderen om latency te verminderen. Jammer genoeg is dat niet iets waar de tools echt voor bedoeld zijn..
Wij zitten rond de +70% denk ik. Bij ons zijn block-rams (locaties op de chip en de hoeveelheid) de grootste beperking. Ook de SLR-overgangen zijn erg duur. Het routen van logica wordt (iets) minder efficient op zo'n grote chip en dan krijg je onder andere last van congestion.
Ik weet denk ik wel waar je werkt. Bij zo'n bedrijf is latency idd erg belangrijk (want dat is het hele doel om FPGA's te gebruiken, right). Zeker op een grote chip met SLR-overgangen zou dat een hele grote uitdaging zijn. Sowieso wordt geklokte (pipeline-)logica belangrijker omdat de chips groter worden en de klokfrequentie hoger.
Jup, latency is eigenlijk het allerbelangrijkste. Dat betekent werpt redelijk wat beperkingen op (SLR crossing kan je maar beter helemaal niet doen).
Het leuke is wel dat alle componenten die we gebruiken (tranceivers, URAM, BRAM, LUTs) echt goed moet kunnen doorgronden om erachter te komen of we het wel op de meeste efficiënte manier gebruiken.
Overigens zou het best leuk zijn om meer in contact te komen met andere FPGA developers in Nederland! Ik zou het zelf best interessant vinden om met anderen te praten over best practices, interessante bugs en dergelijke. In Amsterdam is een C++ meetup iedere maand. Iets soortgelijks voor FPGA developers in Nederland zou best leuk zijn!
Ik kan me best voorstellen dat je alles wilt gaan controleren en kijken of het programmeer werk goed en degelijk is dmv testsoftware zo je eventuele fouten kunnen detecteren Alvorens daarna verder te gaan met de volgende stap.Want als alles klaar is zoals jij het wilt hebben moeten er natuurlijk geen fouten inzitten.
Zelfs chipfabriekanten zoals intel en amd maken wel eens een productie fout wat verkeerd geprogrammeert is.Ik kan me best voorstellen dat sommige mensen hiermee een hobby hebben.Het licht eraan natuurlijk wat voor een bord je hebt en welke chip je gaat programmeren.
25G kan ook via QSFP. Je hebt dan 4x losse 25G welke met een break-out fiber/DAC-kabel naar SFPs gaan. Je kan ook met een QSFP (4x25) direct naar een switch gaan die 4x25G over QSFP ondersteunt (zoals bv Arista).
Ja en nee. SFP is (voor ethernet) alleen maar 1G. 10g is SFP+ en 25G is voor oa 25G.
Strikt genomen is QSFP allern voor 4G; QSFP+ is voor 40G (4 (quad) lanes van 10G) en QSFP28 is 100g of dus 4x25g
Verschil slechts een teken of getalletje aan het eind maar geef je de kost hoe vaak mensen problemen hebben met verbindingen omdat ze een QSFP+ DAC kabel hebben ipv QSFP28 (of welke andere combi ook)
Ik werk voor een bedrijf dat optische sorteermachines maakt voor de voedingsindustrie.
Met andere woorden, ruwe camera signalen worden via FPGA's (VHDL) verwerkt om te bepalen of die aardappel, wortel, ajuin of andere voldoet aan de kwaliteitseisen van de producent. Tientalle of soms honderden objecten per seconde worden zo volledig geinspecteerd op afmeting, kleur en (chemische)structuur.
Het is wel zo dat wij gedeeltelijk van deze werkwijze afgestapt zijn omdat het niet altijd of helemaal de nodige flexibiliteit geeft wanneer de klant bijvoorbeeld van ras of producttype veranderd.
edit: typo
[Reactie gewijzigd door denbatte op 22 juli 2024 14:21]
Ah ja, die fantastische kleursorteerders welke je zoveel boring werk uit handen nam.
Maar als die dan kapot was kon je urenlang handmatig iets te bruine rauwe frieten van de lopende band plukken voordat ze de frituuroven in gaan voor 'voorbakken'.
Menig uurtje bij Aviko gevuld met staren op een sorteerband als de kleursorteerder er geen zin in has... good old times 😁😀
Een oud studiegenoot zit in hetzelfde vakgebied. Hij zei dat ze geen FPGA's gebruiken maar gewoon een dikke Intel (x86_64).
Kennelijk zijn de voordelen van FPGA's niet zo heel interessant als je voor kleine aantallen iets maakt. Omdat bij kleine aantallen de kosten voornamelijk in R&D zitten kan ik dat wel begrijpen.
Dit klopt. Vandaar ook mijn originele opmerking dat er van die werkwijze wordt afgestapt wegens flexibiliteit. De taken die de FPGA tegenwoordig afhandeld zijn veel beperkter dan enkele jaren geleden maar ik kan je verzekeren dat (bij ons) zelfs in de nieuwere machines nog FPGA's zitten.
De grootste kost zit inderdaad in R&D maar dit is ook zo voor systemen die volledig op pc's draaien. Daar moet namelijk ook voor ontwikkeld worden en we spreken dan over het verwerken een enorme hoeveelheid bijna real time data.
Een collega van mij heeft met LabVIEW "4 player Tetris" op een FPGA geprogrammeerd, waarbij hij dus alleen gebruikt maakt van de IO van de FPGA om het beeld aan te sturen. Hij heeft gebruik gemaakt van de MyRIO, een product van NI waar dus een xilinx FPGA op zit. Hij heeft hier een tijdje geleden een online presentatie over gegeven welke je hier kan bekijken als het je interessant lijkt: https://www.youtube.com/watch?v=2xhieWMuXRM
Eind jaren 80 was ik een van de eerste Xilinx-gebruikers in Nederland. Rodelco uit Breda was de importeur en die toonde de mogelijkheden van Xilnx op 'het Instrument', het was toen ook al de concurrent van Altera met zijn EPLD's. Ik programmeerde Xilinx op 'gateniveau', zonder VHDL, vanwege de snelheid die zo bereikt kon worden bij de ontwikkeling van digitale telecommunicatie van de PTT/KPN. De eerste stappen voor ADSL werden met behulp van o.a. chips van Xilinx en de eerste DSP's gezet. Voor de hobbyist was Xilinx nog onbereikbaar: chips en ontwerpsoftware waren kostbaar. En voor het draaien van de ontwerpsoftware had je ook nog een dure AT PC (DOS) nodig met extended memory.
[Reactie gewijzigd door Brechtje op 22 juli 2024 14:21]
Zijn interessante dingen die FPGA's, alleen is volgens mij juist de taal een best wel beperkende factor. Je gebruikt namelijk een "Hardware Description Language" zoals VHDL (o.a. voor die DE-10). VHDL is een vorm van OO programmeren, maar heeft best wel afwijkende syntax. Aan de ene kant logisch omdat je een ander doel hebt, maar bijv. de punt uit de meeste OO talen schrijf je als ' in VHDL. Zo zijn er meer keuzes die het leerproces best wel zwaar maken, natuurlijk is elke taal leren een ding, maar ik zie ook dat studenten vaak er mee worstelen. Ben ook wel benieuwd naar ervaringen van tweakers met bijv. Xilink.
[Reactie gewijzigd door jopiek op 22 juli 2024 14:21]
VHDL is IMHO niet vergelijkbaar met een 'gewone' programmeertaal. Er zijn simulators als GHDL die de code kunnen compileren als een executable, maar dat betekent nog steeds niet dat je er programma's mee kan schrijven voor op de computer.
VHDL beschrijft de logica die gesynthetiseerd moet worden in de FPGA (of ASIC). De taal is event driven, ofwel al je statements worden parallel geëxecuteerd (tenzij je ze in een proces stopt). Ik heb veel beginners geholpen met VHDL en vaak gezien dat ze daar vooral moeite mee hadden.
Overigens is er ook nog Verilog als alternatief, dat vooral in de VS erg populair is.
En er zijn C/C++ naar VHDL compilers, maar dat kan je ook niet zomaar programmeren als een gewoon programma.
(25 jaar professioneel ervaring met VHDL hier)
En helemaal eens met dat je VHDL niet als gewone programmeertaal moet zien. Het is een Hardware Description Language, ofwel je gebruikt het om je hardware mee te schrijven. Het is dan van groot belang om bij elke regel die je intikt te snappen wat dat qua hardware ruwweg inhoudt.
y <= 4 * x
...kost geen hardware, want is alleen een bit shift, paar nullen achter x en je bent klaar.
y <= 3 * x
... kost je een opteller, want je telt '2x op bij 'x'.
y <= x * z
... kost je heel veel optellers, want een vermeningvuldiging van twee variabelen betekent heel veel optellers.
Als je op die manier naar je VHDL code kan kijken, kan je keuzes maken waardoor een chip (of stuk FPGA code) aanzienlijk kleiner wordt, of waardoor het op hogere snelheden kan functioneren.
Overigens is er ook nog Verilog als alternatief, dat vooral in de VS erg populair is.
Mwah, wellicht dat ik (met 25 jaar bij 1 bedrijf) in een bubble leef, maar zoals ik het zie is VHDL op sterven na dood. Fossielen zoals ik houden het nog in leven, maar verilog is echt een heel stuk breder in gebruik. Mensen in India waar ik mee samenwerk gebruiken het. Mensen in Oostenrijk, waar ik vorig jaar mee werkte, ook. Elke verificatie-engineer gebruikt Verilog (of liever nog SystemVerilog). Tool-ondersteuning is aanzienlijk beter voor Verilog - Spyglass, een populaire Lint-checker om code te beoordelen, heeft nog geen ondersteuning voor de 2008 (!) revisie van VHDL.
Zou iemand nieuw beginnen en moeten kiezen, dan zou ik echt wel Verilog aanraden. Ondanks dat ik het zelf een draak van een taal vind...
Voor zover ik weet is VHDL nog steeds de standaard op de meeste Nederlandse opleidingen, zowel Uni als HBO: ik heb geen letter Verilog geleerd (ben nu praktisch afgestudeerd)
Ach, als je de ene taal beheerst kan je vrij snel de ander lezen - en daarna ook snel genoeg schrijven.
En dat de opleidingen hier nog VHDL doen - zoals gezegd, wellicht dat ik teveel in een bubble zit waarin VHDL aan het uitsterven is. Maar kan ook zijn dat opleidingen achterlopen. Docenten die ~20 jaar geleden VHDL begonnen te doceren en er nu nog steeds zitten - en dus nog steeds VHDL doceren.
Maar uiteindelijk gaat het niet om de syntax. Het gaat om dat je 'een taal' gebruikt om hardware te beschrijven, dat je leert dat een if-then-else constructie een multiplexer oplevert bijvoorbeeld. Er wordt een manier van denken geleerd - en VHDL is de methode.
@vanaalten Ik heb 1 kort FPGA vak gehad op mijn opleiding, was heel beperkt en met VHDL.
Het werd me al meteen duidelijk dat je totaal anders moet denken. Ja in software land gebeurt er ook genoeg parallel (multi-threading) wat soms wat communicatie of zelfs synchronisatie nodig heeft, maar dat is niet het enige. Je bent gewoon niet serieel bezig met FPGA's zoals met een C functie wel.
Dus zelfs van beperkte lessen met een oude taal leer je genoeg.
Net als dat iemand prima kan leren programmeren met Delphi. En daarna vrij makkelijk naar C++ overstapt.
Overigens zijn VHDL en Verilog ongeveer even oud - het is meer dat Verilog de populariteitsrace gewonnen heeft, waardoor er betere tool-support is en ook de ontwikkeling van Verilog wat harder is gegaan.
En uiteindelijk zijn Verilog en VHDL behoorlijk vergelijkbaar, beide gericht op hardware (ASIC, FPGA) design. Met beide talen zou je dezelfde mindset leren en relatief makkelijk van de ene naar de andere kunnen overstappen.
Nu heb ik geen 25 jaar ervaring met HDLs, maar toch ook wel wat .
y <= 4 * x
...kost geen hardware, want is alleen een bit shift, paar nullen achter x en je bent klaar.
y <= 3 * x
... kost je een opteller, want je telt '2x op bij 'x'.
y <= x * z
... kost je heel veel optellers, want een vermeningvuldiging van twee variabelen betekent heel veel optellers.
Hetzelfde, of op zijn minst een vergelijkbaar, verhaal kan je doen als je het hebt over programmeren voor embedded targets (en dan bedoel ik niet een Raspberry, maar een ARM M0, of zelfs een 8-bitter). Vooral als je gaat delen krijg je vergelijkbare zaken.
Natuurlijk is Verilog/VHDL niet exact hetzelfde als regulier programmeren, maar een hele hoop concepten zijn overdraagbaar. Het grootste verschil is denk ik dat je rekening moet houden of zaken geklokt zijn, of asynchroon lopen, en er heel veel meer parallel gebeurd. Als je enkel Python kent, ja dan gaat de stap naar Verilog een behoorlijke zijn. Ben je bekend met C(++), dan is die stap vermoed ik al een stuk beter behapbaar. Zeker als je gewoon vergeet dat VHDL bestaat . Maar je gaat wel wat dingen tegenkomen waarbij je je afvraagt of ze de HDLs niet eens naar de 21ste eeuw kunnen brengen. Mijn persoonlijke favoriet: System Verilog voegt eindelijk support toe voor directe array initialisatie.
Zelf recentelijk weleens overwogen een FPGA te kopen om mee te hobby'en, maar mijn grote vraag blijft: Wat moet ik er dan in hemelsnaam mee doen? De voorbeelden hier zijn allemaal retro gaming, waarbij je gewoon de code van een ander laadt. Zelf ook geen interesse in retro gaming, dus wat dan? Natuurlijk je kan er een LEDje mee laten knippen, maar tja, dat kan ook op andere manieren
Bij programmeren kost het geen opteller, maar je gebruikt er 1 malig 1. Bij HDL maak je dus een fysieke opteller in transistors(ASIC) of LUT hardware(FPGA). Waar je in een programmeertaal een loop zou maken om dit 1000 keer te doen moet je er nu over na denken of je duizend tegelijk wil doen (kost veel hardware) of er een counter aan toevoegt en meer sequentieel gaat doen (kost veel tijd). De mindset lijkt me heel erg anders en ik als iemand die 30 jaar programmeer en een achtergrond heeft in electronica begrijp wel dat als je het gaat vergelijken met programmeren dat je al snel in de problemen komt. Misschien dat veel ervaring op low level threading en locking mechanismes je nog wat kan helpen aangezien het voornamelijk.
Ik heb me er ook al meerdere keren in verdiept voor de hobby, maar de bordjes die uitkomen schuiven het programmeren van de FPGA vaak naar de achtergrond en maken er meer een morphende microcontroller van waar je wat designs in de hardware kan flashen. En ik heb er ook nog geen geldig hobby project voor gevonden.
Volgens mij is het ook nog steeds een probleem om 'fpga talen' eenvoudiger in gebruik te maken het risico dat als een (nieuwe) taal dat mogelijk maakt en de hardware laag zo onzichtbaar mogelijk maakt (of zelfs deels hardware onafhankelijk maakt) je een groot risico loopt dat de vertaalslag naar 'echte' fpga leesbare cide erg inefficient wordt; en het idee om een fpga te gebruiken is juist de wens om een bepaalde taak heel snel (efficien) door hardware te laten doen. Maar dan is wel vereist dat de 'programmeur' juist heel goed de hardware begrijpt en begrijpt hoe bepaalde taken efficient door hardware gedaan kunnen worden.
Als je echter alleen denkt in hogere abstracte (hw onafhankelink) denkt dan zal je in meeste gevallen beter uitzijn met een general purpose cpu.
Tenzij het je lukt om die vertaalslag (hogere hw onafhankelijke abstractie) naar efficiente hw afhankelijke fpga code in AI kan inbakken: als je dat goed weet op te zetten kan je wellicht goed geld verdienen
Voor de mensen die het tellen via hardware willen begrijpen
Kan ik Silicon Zeroes aanraden. (er is een demo versie) Het gaf mij een goed inzicht hoe het tellen in HW gaat.
... De taal is event driven, ofwel al je statements worden parallel geëxecuteerd (tenzij je ze in een proces stopt). Ik heb veel beginners geholpen met VHDL en vaak gezien dat ze daar vooral moeite mee hadden...
Kleine correctie, ook statements in een process worden parallel 'geëxecuteerd '. Alles wat je in een synchroon process doet wordt pas aan het eind van het process 'uitgevoerd'. Signal assignments krijgen pas hun nieuwe waarde aan het eind van het process. Variabelen worden wel meteen geüpdatet maar a) deze pas je zo min mogelijk toe ivm timing-closure en logica complexity en b) dit zijn 'interne a-synchrone signalen' welke de logica in een process aan elkaar verbindt.
Wat veel mensen moeilijk te begrijpen vinden is dat er geen code 'executie' plaatsvindt. Je beschrijft logica en vervolgens gaan de elektrische signalen lopen via de beschreven logica. For-loops worden dus ook niet als een for-loop 'geëxecuteerd'. De loop wordt 'unrolled' in logica.
Of course. Als je beetje ervaring met VHDL hebt zie je dat ook meteen, je ontwerpt eerst de in- en outputs (entity) en dan de logica er tussen (architecture blok, zeg maar de manier waarop de 'draadjes' verbonden zijn). Toch zitten er wel constructies uit 'normale' programmeertalen in (zoals iteraties etc). Overigens is niet alleen VHDL best wel een 'stap', ook de tool(s), je moet met best wel veel zaken rekening houden waarmee je eigenlijk (zeker) beginners niet mee wilt vermoeien.
Ik ben wel erg benieuwd naar ervaringen met Verilog, heb daar zelf nog geen ervaring mee iig.
Ex-student hier (zijn we tenslotte allemaal toch?), en de moeite zat 'm totaal niet in de syntax. Ik vind ook niet dat syntax zo zwaar mag wegen voor een programmeur. Bij een degelijke technische IT opleiding (bijvoorbeeld Technische Informatica) leert men de technologie stack van begin tot eind, en hoe de gereedschappen op elk niveau werken. Je kan het je niet permitteren om met maar één paradigma overweg te kunnen (OOP) wanneer en zoveel variatie is. In mijn ogen heeft een goed programmeur ervaring met meerdere paradigms en kan desnoods er zelf een ontwerpen als het domein daarom vraagt.
Uiteraard moet elke (al dan niet embedded) software engineer met de gangbare paradigma's overweg kunnen. Alleen is de vraag of HDL's een 'gangbaar paradigma' in de traditionele zin zijn (ik zou zeggen nee, maar dat wil zeker niet zeggen dat ik voor TI / Embedded niet ook de waarde van HDL's van best groot belang acht). Leren van "de technologie stack van begin tot eind" wordt overigens steeds onmogelijker, heb jij bijv. assembler en/of vertalerbouw gehad? Dat kreeg ik rond de eeuwwisseling nog wel, zelfs al deed ik 'normale' informatica bachelor, want toen was keuze voor TI er nog niet, maar ik hoor vrijwel nergens meer studenten die assembler en/of machine taal leren en vertalerbouw al helemaal niet (wel voor andere ICT-profielen misschien). Een specifieke taal is alleen nog steeds wel een 'enabler' of soms juist een 'disabler', er zijn goede redenen waarom we geen lessen in ALGOL, COBOL etc. meer geven natuurlijk.
Wij (HAN Embedded Systems Engineering) hebben VHDL nu wel van jaar 1 naar jaar 2 verplaatst, dat lijkt me ivm de complexiteit toch wel een heel verstandige keus.
'Gangbaar' vind ik een lastige. Waar het mij voornamelijk om zal draaien is dat men 'gewoon' ervaring opdoet met verschillende paradigma's en ook het begrip ontwikkelt om er eventueel zelf een te ontwikkelen als de omstandigheden daarom vragen. Op een aantal scholen die bijvoorbeeld 'Software Engineering' geven zit je al snel vast aan frameworks of (web)libraries die nu actueel zijn, maar over een X aantal jaar niet meer. Dan vind ik de elementaire kennis veel interessanter, welke taal/toepassing je als vehikel gebruikt om dat over te brengen iets minder (al is praktijkervaring voor embedded systemen wel erg belangrijk). Zelf heb ik inderdaad ASM gehad, vertalerbouw niet. Door interesse vanuit CodeGolf ben ik hier overigens wel op een laag pitje mee bezig.
Dat alles gezegd hebbende, VHDL in jaar 1 is vrij fors
[Reactie gewijzigd door nst6ldr op 22 juli 2024 14:21]
OOP is meer gericht op menselijk abstractie naar de realworld wat uiteraard niet overeenkomt wat hardware op architectuur niveau verwerkt. Er zijn andere paradigma die dichter of meer rekening houden en architectuur en concurrency en parralelidatie in acht nemen zoals functioneel en data oriented wat dichter bij de hardware staat en van daaruit optimaler kan werken.
Mij lijkt het zo leuk prototype in OOP C++ up running vertaald direct naar fpga met OOP dat je dan niet rendable met resources omgaat van de FPGA.
Voor emuleren mogelijk niet zo belangrijk.
Maar als je een OV xxxx 4K 120fps sensor module de rauwe data een bewerking slag en dan naar H265 encoden. Lijkt mij OOP niet optimaal.
Ik heb op dit moment een stagiair die bij een bedrijf juist op dat laatste focust. Lijkt me perfecte toepassing. Ik zie verder ook wel nut in neurale engine voor ML in FPGA's te maken. Eigenlijk is OO natuurlijk ook voor 'normale' embedded toepassingen al veel overhead, maar de schaarste aan resources die microcontrollers van nature hebben is inmiddels ofwel niet heel schaars meer ofwel verdwijnt in rap tempo natuurlijk.
Reden dat ernin de jaren 50 of nog eerder al programmeertalen werden ontwikkeld om buiten die beperkingen te stappen. Veeemd dat we er heen terug willen
Gaam we ook weer bugs zoeken in de buizen
Jullie missen een belangrijke toepassing: finance en trading. Juist daar is 100 nanoseconde een eeuwigheid en regeren de FPGAs wereldwijd vanwege de lage latencies (en asics uiteraard). Dit is ook een gebied waar enom veel werk is voor echte goede hardware engineers die zeggen: een microsecond latency, dat is veel te lang, dat kan beter, en dan zo'n heel bord omgooien.
Ja, ik heb al een paar aanbiedingen gehad over de jaren. Zou echter nooit in die markt willen werken, want ik vind die nano seconde trading ethisch totaal onverantwoord.
Dat valt echt reuze mee hoor als je er iets meer van te weten komt. Het probleem is dat mensen vaak maar de halve waarheid horen waarbij net cruciale feiten worden weggelaten of verkeerd aangenomen, vaak ook nog eens om een mooier/schokkender verhaal te kunnen presenteren (zoals bijvoorbeeld onlangs bij Lubach). In het echt is er een enorm economisch belang en maakt die markt de dingen juist goedkoper en efficienter, vooral voor de consument. Je realiseert je dan ook hoe ontzettend veel regulering er is, en dat er wel degelijk ook echt veel wordt toegevoegd aan de maatschappij/economie als geheel. Nou zijn er zeker ook soms "rogues" die de grens van het toelaatbare opzoeken of zelfs overschrijden, maar als je bij een goede firm zit, dan zijn die ook fel tegen dat soort praktijken en veroordelen ze dat sterk (onmiddelijk ontslag best-case). Het is voor iedereen beter om zo eerlijk en transparant mogelijk te zijn.
Enorm uitdagend gebied met veel variatie, vrijheid, verantwoordelijkheid en uitstekende salarissen. Ik zou het iedereen die goed is zeker aanraden.
FPGA is ontzettend flexibel en je kan er meeste "vreemde" zaken software voor programmeren. Nadat de GPU's de difficulty van het minen van Bitcoin niet meer aan konden kon je een next step maken naar een FPGA miner. Die was energiezuiniger en krachtiger dat een PC vol gepropt met GPU's. De miningsoftware had nogal wat bugs in het begin maar door de kracht van opensource was dat snel opgelost. We hebben toch een jaar lang kunnen minen met een aantal Spartan 6 LX150 FPGA Boards https://www.ztex.de/usb-fpga-1/usb-fpga-1.15x.e.html . Later kwamen de dikkere (en ook stroomslurpende) ASCISs.
Uiteindelijk zal een ASCI efficiënter zijn dan een FPGA. Mensen zijn niet voor niets overgestapt.
Maar ASCIS zijn meestal niet interessant voor kleine oplage, omdat de initiële investering voor de maskers zo hoog is.
[Reactie gewijzigd door MeMoRy op 22 juli 2024 14:21]
Zoals @jopiek hierboven al aangeeft: Er zit een groot verschil in programmeren van een FPGA en een traditionele CPU. In VHDL/Verilog beschrijf je de werking van een stuk hardware dat je vervolgens in de FPGA laadt. Bij een traditionele CPU programmeer je deze met instructies waarmee je de CPU vertelt wat ie moet doen. Het is dus wel even 'omdenken' als je de stap van CPU's naar een FPGA maakt.
Ook een leuk bordje is de 'Go Board'. Zit een Lattice FPGA op. Compleet met voorbeelden in zowel VHDL en Verilog.
Mooi artikel! Voor wie er mee begint en ook zelf wil programmeren, probeer simpele projectjes te maken zoals:
Bepaalde input (zoals van een toetsenbord of wat andere knoppen) om te zetten naar (blokkerige) audio signalen. Daarna het aansturen van raspberry pi/arduino shields. Daarna beeld tonen op een display.
En houd in gedachte dat FPGAs in de basis voornamelijk bedoelt zijn om digitale input zo snel mogelijk om te zetten in output. Je werkt niet echt met geheugen, timers, etc. De kracht zit dan ook in dat er realtime data verwerkt kan worden. Als je input X hebt, komt er zo goed als direct een output Y uit, wat in no time door een (mogelijk heel complex) voorgeprogrammeerd algoritme gaat.
Het zette bijv. de bitcoin markt redelijk op de kop toen bitcoins mining voor het eerst sinds FPGAs konden, (niet zozeer omdat dat toen gelijk efficiënter via FPGA dan via GPUs kon, maar FPGAs zijn de eerste stap naar ASICs maken, die veel goedkoper en efficiënter zijn omdat ze puur 1 ding doen en niet geprogrammeerd kunnen worden zoals FPGAs).
[Reactie gewijzigd door svenk91 op 22 juli 2024 14:21]
Dat ben ik niet met je eens. Moderne FPGA's hebben vaak grote hoeveelheden geheugen op de FPGA zelf, extern geheugen is voor veel toepassingen niet meer nodig. Timers maak je gewoon zelf in logica, de retrocomputergemeenschap doet niet anders, een videochip die gesimuleerd wordt op een FPGA zit bijvoorbeeld vol met timers om het juiste moment het juiste ding te doen. FPGA's zijn net zoals ASIC's goed in realtime-taken, maar kunnen in beginsel alles wat een ASIC kan.
Je hebt helemaal gelijk! Ik had het verkeerd geformuleerd.
Wat ik probeerde over te brengen was vooral hoe je FPGAs het beste voor je eerste projectjes, als absolute beginner, kan inzetten. Dan vooral ook kijkend wat dit apart zet van de typische dev boards die rond een CPU zijn opgebouwd (ARM/X86/X64/RISC-V etc.).
:strip_exif()/i/2003872260.jpeg?f=imagenormal)
:strip_exif()/i/2003872294.jpeg?f=imagenormal)
/i/2003872296.png?f=imagenormal)
:strip_exif()/i/2003872298.jpeg?f=imagenormal)
:strip_exif()/i/2003872302.jpeg?f=imagenormal)
:strip_icc():strip_exif()/i/2004582632.jpeg?f=fpa_thumb)
:strip_icc():strip_exif()/i/2004086480.jpeg?f=fpa_thumb)
:strip_exif()/i/2003008940.jpeg?f=fpa)
/i/2003785544.png?f=fpa_thumb)
:strip_icc():strip_exif()/i/2003192634.jpeg?f=fpa_thumb)
:strip_icc():strip_exif()/i/2002090547.jpeg?f=fpa_thumb)
:strip_icc():strip_exif()/i/2001993641.jpeg?f=fpa_thumb)
:strip_exif()/i/2007003344.jpeg?f=fpa)
/i/2004611214.png?f=fpa)
:strip_exif()/i/2004791608.jpeg?f=fpa)
:strip_exif()/i/2003938218.jpeg?f=fpa)
/i/2001237765.png?f=fpa)
:strip_exif()/i/1177342434.jpg?f=fpa)
/i/1276430387.png?f=fpa)
:strip_exif()/i/2002554306.jpeg?f=fpa)
:strip_exif()/i/2003563108.jpeg?f=fpa)
/i/2003176277.png?f=fpa)
/i/1321728724.png?f=fpa)
:strip_exif()/i/2003140642.jpeg?f=fpa)
:strip_exif()/i/1286274802.jpeg?f=fpa)
/i/2001719227.png?f=fpa)
:strip_exif()/i/2002448390.jpeg?f=fpa)
/i/1238172325.png?f=fpa)
/i/2001665377.png?f=fpa)
:strip_exif()/i/1256021797.gif?f=fpa)
/i/2000593550.png?f=fpa)
/i/1316432985.png?f=fpa)
/i/2001752657.png?f=fpa)
/i/2001331269.png?f=fpa)
:strip_exif()/i/1398151713.jpeg?f=fpa)
/i/1325170337.png?f=fpa)
/i/1318494726.png?f=fpa)
/i/1242207182.png?f=fpa)
/u/112469/crop5dc0192471ec2.png?f=community){kind=small}
:strip_icc():strip_exif()/u/11567/spyder30.jpg?f=community){kind=small}
:strip_icc():strip_exif()/u/140379/Hond_icon.jpg?f=community){kind=icon}
/u/238475/crop5db01b7054bdf_cropped.png?f=community){kind=small}
, debuggen doe je in eerste instantie via simulatie./u/555636/crop5ee4f973cb785_cropped.png?f=community){kind=small}
/u/21071/avatar%252060x60.png?f=community){kind=avatar}
:strip_icc():strip_exif()/u/65843/chef60x60.jpg?f=community){kind=small}
:strip_icc():strip_exif()/u/487115/tux2.jpg?f=community){kind=small}
/u/254540/debian%2520avatar.png?f=community){kind=avatar}
/u/354442/FSJALSMALL.png?f=community){kind=small}
:strip_icc():strip_exif()/u/145751/check-in-minion-small2.jpg?f=community){kind=small}
.:strip_exif()/u/47900/baph.gif?f=community){kind=small}
/u/357965/avatar2.png?f=community){kind=avatar}
:strip_icc():strip_exif()/u/35767/images.jpg?f=community){kind=small}