FPGA, første kontakt

Men lad os nu holde tungen lige i munden. For selvom en softcore sikkert kan løse mange algoritmisk tunge opgaver udmærket på en FPGA, så er der vitterlig ting hvor man er nødt til at lave det hardwarenært, før det giver mening. Især hvis det gælder om at behandle en synkron datastrøm tæt på den øvre grænse for FPGAens formåen. Hvis man har input/outputbuffere på 2.5 Gbps eller derover begynder en softcore også at blive en klods om benet for PHY layer processering, som f.eks. descrambling, etc.</p>
<p>Og hvis ens opgave ikke er større og mere kompliceret end at den kan passe i en Arduino, så burde man også bruge en sådan. Her ville en FPGA jo være som at skyde gråspurve med kanoner. Over åen. Efter vand :-)

Fordelen ved der bruges CPU-softcores er følgende:

1. En CPU core fylder relativ lidt, og ofte mindre end VHDL kode, der skal løse en tilsvarende opgave.
2. Det er nemmere at kode end VHDL
3. Du kan bruge så mange cores der er plads til. Normalt er plads til en del. Specielt, hvis du laver timing kritisk elektronik, er det en fordel at du "bare" tager en CPU til jobbet. Den kan f.eks. køre i en uendelig løkke, eller resettes med fast hastighed, hvor der udføres en funktion. En CPU der genstartes med fast hastighed opfylder nemt realtidskrav, da alt skal være udført, inden næste reset. Styring af intelligente LCD displays, scanning af tastaturer og meget andet, er også praktisk at bruge microcontrollere til.
4. CPU kernen er defineret i VHDL eller verilog. Det betyder, at dens funktion er defineret i dit design. Der kommer ikke en producent, og pludseligt laver en version 2 eller 3, så det ikke mere fungerer med dit design, og du skal til at udvikle nye versionsnumre for at kunne bruge de nye CPU'er, som er på markedet i dag. En CPU core skrevet i VHDL er mere robust for fremtiden, end en købt CPU, der oftest kun er på markedet 5-7 år.
5. Ulempen er at den fylder, men de fleste FPGA'er er i dag så store, at der er plads til adskillige CPU'er i chippen. Og dermed fylder de kun plads op, der ellers ikke havde været brugt. Du kan lave dit design mere simpelt, og i mange tilfælde nøjes med en FPGA, samt en flash der indeholder FPGA'ens program.

Den største ulempe ved en CPU som soft-core er hastigheden. Har du behov for ekstrem hastighed i en CPU, så er nødvendigt med en ekstern CPU, eller at bruge en FPGA med indbygget hurtig CPU.

De fleste af Xilinx design eksempler indeholder enten PicoBlaze eller MicroBlaze. PicoBlaze bruges f.eks. til tastaturscanning, dekodning af rotary encoders, udskrift på LCD displays, kommunikation med RS232, test og kontrol, programmering og læsning af flash typer, opsætning af værdier der bruges af logikken mv. MicroBlaze bruges i mere komplicerede eksempler skrevet i C, f.eks. ethernet stack og en webserver på FPGA'en.

Selvom et er sjovt at lave sin egen CPU, så tager det tid - og jeg vil nok anbefale, at man starter med at bruge tid på at sætte sig ind i en af de almindelige, f.eks. PicoBlaze. Derved læres også hvordan f.eks. JTAG fungerer, da det bruges til at uploade koden. Det kan være "handy" i mange tilfælde, at kunne uploade kode til FPGA'ens RAM/ROM moduler, uden at skulle kompilere hele VHDL koden igen. Der findes mange processorkerner på nettet, så måske er også muligt at få en op at stå, med din "yndlingscpu".

Et godt sted at starte er at downloade eksempler, og mange af disse indeholder en soft-cpu.

I dit tilfælde, er der en CPU på kortet, og du kan måske bruge den i stedet for en soft-cpu. Men, den er ikke så portabel, som en CPU på FPGA'en. Og på en Spartan 6 skulle være "råd" til nogle kerner.

Sparsø's kursus er for mange år siden skiftet til FPGA'er. I dag køber de studerende et Xilinx kort før kurset starter, og laver øvelserne på deres eget kort.

Hej Jens,

Jeg var også blandt tilhørerne til Sparsøs kursus, torsdag morgener, vist nok, kl 8 (ikke 8:10!!! :-) for mange år siden. Ligeledes sad vi også og proppede Patterson/Hennessy CPUen ned i en gammel Altera med en win16 udgave af MAX+PLUSII. FPGAen er et vældigt pædagogisk værktøj og drønsmart som testbænk for prototyper.

Men lad os nu holde tungen lige i munden. For selvom en softcore sikkert kan løse mange algoritmisk tunge opgaver udmærket på en FPGA, så er der vitterlig ting hvor man er nødt til at lave det hardwarenært, før det giver mening. Især hvis det gælder om at behandle en synkron datastrøm tæt på den øvre grænse for FPGAens formåen. Hvis man har input/outputbuffere på 2.5 Gbps eller derover begynder en softcore også at blive en klods om benet for PHY layer processering, som f.eks. descrambling, etc.

Og hvis ens opgave ikke er større og mere kompliceret end at den kan passe i en Arduino, så burde man også bruge en sådan. Her ville en FPGA jo være som at skyde gråspurve med kanoner. Over åen. Efter vand :-)

Jeg har ikke tænkt mig at lave en CPU. Motorstyringens formål er at aflaste en Arduino med - f.eks. encoder læsning, genererer stepping pulser hurtigere og jævnere og muligvis (har ikke undersøgt det endnu) at den laver strømstyringen med chopping.

At få en motor startet og stoppet og køre nogle steps burde kunne klares.

Dernæst at køre 2 motorer lineært samtidigt, så man får en skrå bevægelse.

Og en cirkel.

Og et buestykke.

Og hvis man så kan få FPGA'en til at følge en bézier-kurve, så skulle det være muligt at sende en SVG-fil direkte til den atmega32u4, og så få fræset alt hvad man kan finde på.

Med en forberedt SVG-fil forestiller jeg mig brugerfladen ala:

$ cat spiral.svg > /dev/ttyUSB0

Men hvis blot systemet klare 90° buestykker, så vil den være rigtig god til printplader.

Du har fuldstændig ret. At fylde een eller anden softcore i kredsen og så muntre sig med dét, softcoren tilbyder er at gå over åen. At anlægge en lidt mere hardwarenær betragtningsvinkel vil nok være mere givende. Jeg er så gammel, så jeg har siddet med fumlebrædder, wraptråd og TTL-logikkredse og lært om kombinatoriske og sekvenskredsløb. FPGA'en tilbyder nøjagtig samme læring, bare i et virtuelt miljø. En nærmest uendelig forsyning af alle de logiske grundelementer man kan forestille sig, signaltræk uden wraptråd, mulighed for at gemme backups af opstillinger og meget mere. Og selvom værkstedsbordet er virtuelt får man et anderledes håndgribeligt indblik i race conditions, propagation delay og mere af samme skuffe. Min egen drøm er at prøve at bygge en CPU. Sådan en art Build-A-Brain projekt hvor aaaalt overflødigt er skrabet af og kredsløbet er reduceret til det allermest basale. En miniversion af f.eks. Intels 4004 CPU måske?

Hvis du har haft 02200 eller et tilsvarende kursus på DTU, så vil du vide at der faktisk spares plads med en CPU kerne. Jens Sparsø bruger en del af undervisningen (han er en fantastisk god forelæser), på at forklare "motivationen" for at bruge en CPU eller mikrokodet ALU, og at det netop sparer gates og plads på FPGA'en eller en chip. Bruges en CPU, så genbruges komponenterne, og du kan løse komplicerede opgaver, på en brøkdel af den plads det fylder at lave det i ren VHDL. En ekstern processor, er naturligvis en mulighed, men ofte en dårlig løsning. Til debugging er det fint, men hvis processoren udfører en del af opgaverne, så er det absolut en fordel at holde den på chippen.

Picoblaze fylder ikke meget på en chip - jeg mener der er plads til ca. 18 CPU kerner med hukommelse på en Spartan 3E CPU. Spartan 6 er større.

En soft-core behøver ikke at være ultra kompliceret. Skal du lave din egen RISC cpu, og gøre den kompatibel med en eksisterende processor - så vil jeg anbefale at gøre den PIC compatibel. Her findes både C kompilere, Basic kompilere, og gode debuggere. Der findes også mange biblioteker til f.eks. aflæsning af matrix tastatur, kommunikation med displays, grafiske displays mv. Du kan også vælge en af de gamle CPU'er, som 8080, 8085 eller lign. men det er lidt mere kompliceret end en PIC CPU. Og bruges Basic eller C til kodningen, betyder instruktionssættet stort set intet. Z80/8085 kode ermere kompakt i rom'en end PIC og Picoblaze's. Picoblaze er meget begrænset, og jeg mener ikke der findes ordentlige C compilere til picoblaze. Der findes nogle, men de er lidt specielle at bruge. Oshonsoft's simulator supporterer f.eks. Z80 og PIC kredsene, og har indbygget f.eks. simulering af matrix tastatur, LCD displays mv. Derudover har den en lille mini-basic, der også supporterer dette. Og der findes flere visual basic plugin's med f.eks. analoge signalgeneratorer, skop mv.

Et andet lydprojekt, her for audiofile, kunne være at lave en S/PDIF 16bit/44kHz til 24 bit/96 kHz konverter, og eksperimentere med, hvor meget eller om man kan forbedre/interpolere almindelig 16 bit CD audio, så det lyder bedre gennem en DAC.

Ellers er der masser af verilog eksempler rundt om på nettet på digitale filtre, forskellige interfaces, m.v.

Sikken masse ideer - det med lyden havde meget kort været igenem mine tanker, men jeg ved meget lidt om digital lydbehandling, så det ville nærmest være nogle "random kredsløb" og se hvad der laver en ændring i lyden.

Jeg har ikke tænkt mig at lave en CPU. Motorstyringens formål er at aflaste en Arduino med - f.eks. encoder læsning, genererer stepping pulser hurtigere og jævnere og muligvis (har ikke undersøgt det endnu) at den laver strømstyringen med chopping.

Jens svarede hurtigere end mig - med det er Verilog syntaxen indtil videre.

Interessant bog. Men lad nu være med at gøre den antagelse at jeg vil videre end 4004'er-størrelsen :)

Den gamle udgave jeg har af bogen starter med "én instruktion per clockcyklus"-designet, og derefter viser den hvordan man ved at skære kredsløbet i skiver, og sætte registre imellem (pipelining), lige pludselig kan clocke den meget hurtigere. At sætte sig ned bagefter og beskrive det i VHDL er en meget interessant øvelse.

En FPGA kunne også være interessant at benytte til noget der skal gå rigtig hurtigt. Highspeed link-layer handling ifbm noget optik eller sån't. Jaja, jeg ved godt at det hele fåes som færdige moduler, men det er ikke så sjovt med dem, vel?

Nemlig, eller man kunne implementere digitale filtre (uden brug af CPU IP-blokke) til f.eks. realtidsprocessering af lyd. Der er mange sjove projekter.

Interessant bog. Men lad nu være med at gøre den antagelse at jeg vil videre end 4004'er-størrelsen :)

Det handler om opdagelse - om at skille vækkeuret ad og lære hvordan det virker. Og om at kunne samle det igen bagefter.

Får jeg brug for en større CPU, er det langt mere kosteffektivt at købe en færdiglavet. Samme historie hvis det skal være nemmere - hurra for f.eks PIC16F873 eller måske et helt arduino-board hvis man ikke orker at bakse med power, afkobling og IO. Hele baduljen fåes som userfriendly stumper, ifald man ønsker at bygge sig en elektronisk 'lille hjælper'.

En FPGA kunne også være interessant at benytte til noget der skal gå rigtig hurtigt. Highspeed link-layer handling ifbm noget optik eller sån't. Jaja, jeg ved godt at det hele fåes som færdige moduler, men det er ikke så sjovt med dem, vel?

Min egen drøm er at prøve at bygge en CPU. Sådan en art Build-A-Brain projekt hvor aaaalt overflødigt er skrabet af og kredsløbet er reduceret til det allermest basale. En miniversion af f.eks. Intels 4004 CPU måske?

Så vil jeg kraftigt anbefale Patterson og Hennessy: "Computer Organization and Design"https://www.amazon.com/Computer-Organization-Design-Fourth-Edition/dp/0123747503

Med den i hånden kan du nå langt videre end 4004'eren. Tilbage i slutningen af halvfemserne puttede DTU-studerende rutinemæssigt en RISC-cpu ned i en Altera 10k20 oldsags-FPGA med lidt over 1000 celler. Nu om dage er softwaren langt bedre, og FPGAerne meget større og billigere, så værs'go at komme i gang :-)

at bruge den som en mikrocontroller er som at gå over åen efter vand

Du har fuldstændig ret. At fylde een eller anden softcore i kredsen og så muntre sig med dét, softcoren tilbyder er at gå over åen. At anlægge en lidt mere hardwarenær betragtningsvinkel vil nok være mere givende. Jeg er så gammel, så jeg har siddet med fumlebrædder, wraptråd og TTL-logikkredse og lært om kombinatoriske og sekvenskredsløb. FPGA'en tilbyder nøjagtig samme læring, bare i et virtuelt miljø. En nærmest uendelig forsyning af alle de logiske grundelementer man kan forestille sig, signaltræk uden wraptråd, mulighed for at gemme backups af opstillinger og meget mere. Og selvom værkstedsbordet er virtuelt får man et anderledes håndgribeligt indblik i race conditions, propagation delay og mere af samme skuffe. Min egen drøm er at prøve at bygge en CPU. Sådan en art Build-A-Brain projekt hvor aaaalt overflødigt er skrabet af og kredsløbet er reduceret til det allermest basale. En miniversion af f.eks. Intels 4004 CPU måske?

Mange ser ud til at tage softwarevinklen på FPGA'er i denne tråd. Det er en sjov teknologi at lege med, med dens fleksible pinout og funktion, men at bruge den som en mikrocontroller er som at gå over åen efter vand. Så brug hellere en SoC af en eller anden slags.

Der hvor den virkelig gør gavn, er til de tidskritiske, hardwarenære opgaver, samt som pædagigisk legetøj for digitaldesignere, der bygger deres første RISC-cpu, f.eks.

Alle nybegyndere bør bruge lidt tid på at sætte sig ind i, hvordan man syntetiserer kombinatoriske og sekventielle kredsløb i hånden, bare for at få lidt grundviden om emnet. Se f.eks. Zvi Kohavis bog om tilstandsmaskiner.

https://books.google.lu/books/about/Switching_and_Finite_Automata_Theory.html?id=pQy_yQD-hT4C&redir_esc=y

At pusle med FPGA har faktisk også været på min todo-liste en stund. Måske du kan finde inspiration i andres arbejde med denne komponenttype. F.eks Chris Fenton her, som har bygget sin egen Cray-1 replica:

https://www.eetimes.com/document.asp?doc_id=1278417

Man skal sikert lede længe efter den rationelle begrundelse for at kaste sig ud i en opgave, som for mig ser ud til at være af nærmest herkuliske dimensioner. Det forhindrer mig dog ikke i at ta' hatten af for hans frembringelse. I mine øjne er dette hacking når det er allerbedst.

Hvis der er nogle der gerne vil prøve, så kører der en kickstarter i øjeblikket, hvor et FPGA PCB kobles til Raspberry Pi eller Beagleboard:

https://www.kickstarter.com/projects/1575992013/logi-fpga-development-board-for-raspberry-pi-beagl

Det er til at betale, men hvad man så kan bruge det til, det må andre vist fortælle.

Der er tre dage tilbage.

Vil bare nævne ghdl + gtkwave sammen med en editor som emacs med vhdl mode er en god kombination at have ved siden af xilinx tools. Netop fordi roundtrip tiden er så høj med syntesering, map, par osv. så kan det virkelig betale sig at lave gode testbenches, og den kombination kan køre på nix, mac, windows. Med hensyn til debug, så ved jeg ikke om Michael har adgang til en xilinx jtag og chipscope. Hvis chipscope er muligt, kan jeg stærkt anbefale dette på en xilinx platform. Til sidst vil jeg lige nævne https://opencores.org/ som et sted der forsøger at formidle open source hardware cores. Det er ikke alt der er lige godt, men der er nogen gode designs hvor man kan finde inspiration.

Held og lykke i din nye verden, hvor der skal tænkes helt anderledes når der skal beskrives hardware, frem for at programmers en cpu.

En soft-cpu gør det nemmere at debugge dit hardware.

På det kort der er tale om her, sidder der en AVR lige ved siden af, så frem for at bruge en masse tid og areal på at syntetisere en soft-CPU ville jeg bare bruge den...

Xilinx webpack bruger som standard VHDL eller Verilog. Der er også muligt - men kompliceret - at tegne schematics. Deres schematic editor er ikke god. Så de fleste skifter sikkert hurtigt til VHDL. Endeligt, er muligt at tegne signal flow grafer. Embedded versionen (ej gratis) giver mulighed for at kode en soft-processor i C.

Jeg vil anbefale, at man starter med at finde en god soft-cpu som du kender, og kan programmeres i C eller Pascal - der findes i dag Pascal til mange microcontrolere, f.eks. til Microchips PIC kredse, Atmels kredse mv. Jeg føler selv, at Pascal er et mere sikkert sprog end C, men det er nok fordi jeg er Pascal årgangen. Basic er også en mulighed, og findes til flere microcontrollere. F.eks. har Oshonsofts debugger indbygget en lille Basic, og er også et godt program til at debugge de microcontrollere som supporteres i assembler.

En soft-cpu gør det nemmere at debugge dit hardware. Du kan forbinde indgange og udgange til CPU'en/Microcontrolleren, og teste hardwaren i højniveau sprog som Pascal eller C, f.eks. sætte en MUX på, så du kan skifte mellem debug tilstand, hvor program styrer klok og signaler, og "hardware" tilstand, hvor programmet udføres. Du kan bruge processoren til at aflæse tastatur, skrive til displays mv. og f.eks. aflæse og sætte værdier, du bruger i hardwaren.

Er det vhdl, gezel eller noget helt tredje du programmerer logikken i?

/Mads