Standardisert arkitektur for testbenker med VHDL

Vi er alle kjent med at arkitekturen i en FPGA-konstruksjon – fra toppen og helt ned til mikro arkitekturen – er kritisk både for kvaliteten på FPGAen og for utviklingstiden. Dette gjelder også for testbenken, men av en eller annen grunn er testbenker sjelden strukturerte. Dette til tross for at det i de fleste prosjekt fins et stor potensiale for tidsbesparelser og forbedringer av kvaliteten.

En viktig årsak er at det mangler kunnskap innen verifisering. Vel så viktig er det at FPGA-brukerne ikke etterspør en god, felles metodikk.

Ny virkelighet
Alt dette endret seg for to år siden, med lanseringen av UVVM (Universal VHDL Verification Methodology) som er et verktøy i form av åpen kilde. UVVM utgjør en god, kraftig og generell arkitektur for en testbenk som er lett å bruke for alle som utvikler FPGAer og ASIC. Standardiserte verifiseringskomponenter koples sammen akkurat som legoklosser, og en sentral testsekvenserer (eller flere) kan alltid tilføre høynivåkommandoer for å styre verifiseringskomponentene, og dermed hele testbenken. Dette innebærer at selv personer som ikke er FPGA-utviklere kan skrive avanserte testtilfeller.

Bygge egne testsett
Dermed blir det mulig for utviklerne å bygge egne testnett (harness) og testtilfeller mye raskere og bedre enn tidligere, samtidig som de kan gjenbrukes.

Verifiseringen utgjør i gjennomsnitt halvparten av det totale arbeidet i et FPGA-prosjekt. Et like interessant faktum er at i gjennomsnitt halvparten av verifiseringstiden går med til avlusing. Dette betyr at det fins et enormt forbedringspotensiale for verifiseringen generelt, men spesielt for avlusingen.

SystemVerilog vs. VHDL
Alle de store krets- og verktøyleverandørene snakker om dette verifiseringsgapet og tilbyr ”løsninger” som skal løse det. Dessverre er løsningene deres ofte en meget kompleks metode kalt UVM (Universal Verification Methodology) som medfører at man må lære seg et helt nytt språk, System Verilog, i tillegg til at man må kjøpe svært kostbare verktøy. De fleste FPGA-utviklere i Europa bruker VHDL for utvikling og verifisering. På verdensbasis er tallet omtrent 50 prosent.

Effektiv evolusjon
VHDL er kraftig nok for de fleste FPGA-prosjekter. Å bruke VHDL gjør det mulig for utviklerne å fortsette å benytte et språk de allerede kan, for å legge til ny funksjonalitet når det trengs, steg for steg. Det er med andre ord en myk og effektiv videreutvikling av din nåværende testbenk og ditt språk.

Funksjoner og egenskaper er dessverre langt fra tilstrekkelige i seg selv. Strukturer og arkitekturer er nøkler til alle viktige aspekter for en god FPGA-utvikling.

Designstruktur og -arkitektur
I figuren vises de mest kritiske faktorene for utvikling og verifisering under et prosjekt. Under konstruksjonsfasen er vi oppmerksomme på dette, noe som er den viktigste årsaken til at vi deler opp konstruksjonen i deler som er mer eller mindre selvstendige. Det gjelder eksempelvis for UART, SPI, DMA-kontroller og AD-omformer. Disse modulene, eller VHDL-komponentene, tildeles kommandoer fra programvaren, og siden utfører de sine tildelte oppgaver mens programvaren gjør noe helt annet. Om noe går galt, eller modulen trenger hjelp, sier den ifra om dette. Normalt gjøres det med et avbruddssignal, et interrupt. Det som er riktig hyggelig, er at FPGA-konstruksjonen, som er utviklet som toppnivå, er enkel å forstå. Vi ser modulene og kjenner deres funksjoner.

Bussen som kopler sammen modulene er standardisert, eksempelvis AXI4-lite eller Avalon, og modulenes bussgrensesnitt er standardiserte for å passe bussen. Programvaren som styrer det hele kjøres med høynivåkommandoer.

Verifikasjonsstruktur og -arkitektur
Det er åpenbart at strukturen som er beskrevet ovenfor er ekstremt effektiv og gir god kvalitet. For testbenker har det imidlertid ikke vært tilgjengelig tilsvarende systemer eller metodikk. Det er en av de viktigste årsakene til at testbenker er ustrukturerte, og hovedårsaken til at UVVM ble utviklet.

Arkitekturen i konstruksjonen speiles i UVVM, hvilket gir en arkitektur i testbenken som faktisk er enkel å forstå, og dessuten tar med seg alle fordelene med en god og modulbasert struktur.

• Verifiseringsmoduler med lettforståelig funksjonalitet og grensesnitt
• Et standardisert bussystem mellom sekvenseren til verifiseringsmodulene
• Et standardisert bussgrensesnitt på alle verifiseringsmoduler.

I UVVM kalles disse modulene for VVC (VHDL Verification Components)

Forstå arkitekturen
Arkitekturen i UVVM er svært lik arkitekturen i en FPGA-konstruksjon med den eksterne programvare-
sekvenseren som er nevnt over.

Sekvenseren i testtilfellet distribuerer kommandoen til VVCene på samme måte som programvaren distribuerer kommandoer til FPGA-modulene. Siden gjør VVCene det de er tiltenkt å gjøre, på samme måte som i en FPGA. Det innebærer at man normalt håndterer tilgangen på deres fysiske grensesnitt. For FPGA-modulen kan det være å sende noen data, og det kan være slik også for VVCen.

For testbenken til UARTen i figuren kan testsekvenseren ¬typisk sende en kommando til UART TX VVC for at en byte med data skal sendes til RX-inngangen på UARTen.

To nivåer
I UVVM fins det to måter å nå grensesnittet på det som skal testes (DUT, Device Under Test). Det enkleste er en vanlig BFM-prosedyre (Bus Functional Model) som:

uart_transmit (x"4C", "Apply byte on UART RX")

Den siste delen fungerer som kommentar til koden og skrives ut eller logges når den trengs. Denne prosedyren vil eksekveres direkte, og sender x4C til UART RX med hjelp av UARTens protokoll.

Det betyr at dersom testsekvenseren anroper prosedyren, vil den legge til UARTens protokoll bit for bit. Det vil ta en stund. I mellomtiden vil testsekvenseren være opptatt og kan ikke gjøre andre ting.

En mer avansert form kalles CDM (Command Distribution Method):

uart_transmit (UART_TX_VVCT,1  x"4C",  "Apply byte on UART RX")

Hvis sekvenseren anroper denne prosedyren – det som skjer med en gang er at denne kommandoen sendes til VVC med den måladressen som er angitt i rødt – med navn og instansnummer på VVCen som faktisk skal eksekvere kommandoen på testobjektet, DUTen. Å overføre testkommandoen fra testsekvenseren til VVCen tar ikke tid i det hele tatt, hvilket betyr at testsekvenseren umiddelbart er tilgjengelig for andre oppgaver, som å instansiere en tilgang til et annet grensesnitt. Den tidkrevende protokollen til UARTen tas hånd om av VVCen.

En komplett liten test
Kodeeksempelet under viser hvordan en liten test kan skrives for å samtidig teste tilgangen til alle grensesnitt. Eksemplet er fra en annen testbenk, der VVCene for UARTensTX og RX er slått sammen til en og samme VVC, for lettere å kunne gjenbrukes senere. For dette eksemplet har vi lagt til en annen parameter, for å vise kanalen. (RX vs TX).

sbi_write(SBI_VVCT,1, C_ADDR_TX_DATA, x"A0", "Send byte UART TC");
uart_expect(UART_VVCT,1,RX x"a0", "Check byte from UART TX");
uart_transmit(UART_VVCT,1,TX x"A1", "Apply byte on UART RX");
wait for C_FRAME_PERIOD;
sbi_check(SBI_VVCT,1, C_ADDR_RC_DATA. x"A1", "Check UART RX byte");

Kritisk mikroarkitektur
I en FPGA-konstruksjon er det bra, men ikke tilstrekkelig, å ha en bra arkitektur for det øverste nivået. Det er like viktig å ha en bra mikro-
arkitektur hele veien ned. Dette gjelder selvsagt også for testbenken, noe som i dette tilfellet innebærer at også arkitekturen i VVCene må være enkel å forstå, modifisere og gjenbruke. Igjen, standardisering hadde vært fint! 

Den grunnleggende VVCen består av de gule blokkene i figuren. Disse vil kunne se CDMene ovenfor, og bare akseptere kommandoer som er tiltenkt eksakt denne VVC. Den vil da legge kommandoen uart_transmit() i køen og la testsekvenseren fortsette. Eksekvereren vil hente kommandoen fra køen, oppdage at det er en kommando for UARTen og så eksekvere BFMen på testobjektet med de vedlagte parameterne.

Strukturerte utvidelser
Den sterkt strukturerte arkitekturen i VVCene har enda en fordel. Det er enkelt å legge til mer funksjonalitet i strukturen. Det kan være mer avanserte grensesnitt, eller å bare ta med gjen-
brukt funksjonalitet.

En protokoll som Avalon MM resulterer ofte i kaotiske testbenker, ettersom det kan komme flere lesekommandoer før det første svaret dukker opp. Med VVC-arkitekturen er det latterlig enkelt og svært strukturert. Eksekvereren henter lesekommandoen fra køen, og vet at det er en delt tilgang. Den anroper da BFM-prosedyren og sender samtidig lesekommandoen til neste kø. Svareksekvereren henter den og anroper så BFM- prosedyren for leserespons, og venter på respons. På denne måten kan et  betydelig antall leseforespørsler gjøres uavhengig av svarene, og alt er pent og pyntelig strukturert.  

Implementering av VVC
I UVVM er det et script som genererer VVCer for nye grensesnitt. Koden som lages er i praksis en mal, og det markeres klart og tydelig hvor brukeren må legge til sine egne BFMer og andre modifiseringer som trengs. Det må lages BFMer for alle testbenker. Når man har gjort det noen ganger, tar det ikke mer enn ca. 30 minutter å lage en VVC fra grunnen av.

Standardisering
Gjennom standardisering av FPGA-konstruksjonen over lang tid og med et godt konsept for arkitekturen, med registre for styring og status, et bussystem, autonome moduler og kommandoer for høynivå programvare, har man oppnådd en effektiv designmetodikk for FPGA:er men også effektiv programvareutvikling, i og med at programvareutviklerne ikke behøver å forstå detaljene i modulene de styrer. Dette kan kanskje synes åpenbart – og det er det. Så hvorfor har ikke dette skjedd med testbenkene, der vi har eksakt samme scenario med en sekvenser som styrer ulike grensesnitt?

UVVM tilbyr nettopp dette, samtidig som det også standardiserer de viktigste delene:

• Standardmodul (VVC) for grensesnitt til styring og status
• Standardprotokoll fra sekvenser til VVCer
• Standardkommandoer for sekvenseren (for felles oppgaver)
• Standardisert intern arkitektur for VVCen
• Standardkommando for køsystemet
• Standardhåndtering av flertrådede grensesnitt (eksempelvis delte transaksjoner)
• Standardmetoder for synkronisering mellom VVCer (eller andre prosesser)
• Standardiserte vente- og timeout-signaler
• Standardmeldinger og alarmhåndtering
• Standardkommandoer for multicast og broadcast
• Standardsupport for avlusing (debugging)

Global anerkjennelse
Internasjonale aktører med en sterk interesse for VHDL og verifisering har tatt til seg UVVM. Aldec kjører allerede en rekke webinarer om UVVM og vil snart inkludere UVVM i sine simulatorer.

Doulos er størst på utdanning innen FPGA og ASIC. De anbefaler nå UVVM for testbenker. Et siste bevis på at UVVM virkelig har skutt fart, er at den Europeiske Romfartsorganisasjonen, ESA, sponser utvidelser av UVVM med over 200.000 euro og kommer til å anbefale sine leverandører å anvende UVVM for FPGAer.

UVVM kommer med gratis VVCer og UBMer for eksempelvis UART, I2C, SPI, SBI, AXI4-lite, AXI4-stream, GPIO og Avalon MM, noe som gjør det enkelt å komme i gang. I løpet av andre kvartal i år vil vil slippe en mekanisme for å dele VVCer mellom VHDL-brukere. Det gjelder både for open source og kommersielle VVCer.

Referanser:
https://www.mentor.com/products/fv/multimedia/the-2016-wilson-research-group-asic-ic-and-fpga-functional-verification-study
https://www.doulos.com/
https://github.com/UVVM/UVVM_All