FPGA-prototyper kan ta lång tid att utveckla. Stephan van Beek, Sudhir Sharma och Sudeepa Prakash från MathWorks beskriver här hur man kan använda modellbaserade metoder för att korta konstruktionstiden.

ASIC/FPGA-konstruktörer och testingenjörer skriver ofta så mycket som tio rader testbänkskod för varje rad VHDL/Verilog-kod som ska implementeras i kisel, dessutom spenderar de ofta mer än 50% av projekttiden på verifiering. Trots denna arbetsinsats innehåller nästan 60% av alla chip funktionella fel som kräver en respin.
Insikten att HDL-simulering inte räcker för att hitta alla systemnivåfel resulterar ofta i att designingenjörer använder sig av FPGAer för att accelerera utveckling och verifiering av algoritmer. Detta kan vara ett tidskrävande arbete och att stressa fram en FPGA-design i ett labb utan att först göra en ordentlig systemnivå- och HDL-simulering är inte heller någon bra idé. Flera studier visar att tiden i ett labb för att hitta orsaken till ett funktionellt fel kan vara mer än fem timmar för enkla system, och mer än 30 timmar för mer komplexa system.

Fig 1. Ett modellbaserat utvecklingsflöde med “best practices” för FPGA-prototyping.

Med andra ord är det nödvändigt med en systematisk, pålitlig, och repeterbar arbetsprocess för att ta fram FPGA-prototyper.
För att nå detta mål har vi identifierat fyra viktiga steg i ett utvecklingsflöde för att ta fram prototyper med hjälp av modellbaserad utveckling (fig 1):
1. Användning av modellering och simulering för optimering på systemnivå.
2. Automatisk generering av HDL-kod från systemmodellen för att skapa läsbar och spårbar kod för FPGA-prototyper.
3. Återanvändning av systemtestbänkar tillsammans med HDL-samsimulering.
4. Regressionstester med FPGA-in-the-loop-simulering.

Varför använda fpgaer för prototyper?
Att prototyptesta algoritmer på en FPGA ökar sannolikheten att den slutgiltiga produkten uppfyller de funktionella kraven. Detta ger också möjlighet att köra testvektorer för olika användningsscenarion i full hastighet. FPGA-prototypen kan dessutom användas för att testa mjukvara och närliggande systemfunktionalitet, t ex RF eller analoga subsystem. Eftersom en FPGA-implementering exekverar snabbt kan större testset användas för att upptäcka fel som annars kanske aldrig skulle ha upptäckts med ett mindre testset som bara körts i en simuleringsmodell.

Fig 2. Hårdvarudesign i ett modellbaserat utvecklingsflöde ger kortare designcykler, snabbare prototyper och kortare designiterationer.

Modellbaserad utveckling med automatisk HDL-kodgenerering hjälper ingenjören att snabbt ta fram FPGA-prototyper, se fig 2. Figuren visar hur den detaljerade designfasen traditionellt ofta förkortas till förmån för implementeringen. Förhoppningen är på ett tidigt stadium slutföra HDL-kodningen och på så sätt möta tidplanen. I praktiken får ingenjören ofta gå tillbaka till detaljdesignen under tiden som HDL-koden skrivs när man upptäcker att t ex fixtalsalgoritmen inte möter systemkraven. De här iterationerna förlänger HDL-implementeringfasen, illustrerad i lila i fig 2. Det kan också resultera i olika kompromisser, som tex extra klisterlogik eller olika ”designfixar”.

Fig 3. Ett typiskt kommunikationssystem med en Digital Down Converter (DDC).

Eftersom automatisk HDL-kodgenerering är en snabbare process är manuell handkodning kan man i stället använda tiden för att ta fram en bättre fixtalsmodell i den detaljerade designfasen. Det här arbetssättet gör det möjligt för ingenjören att ta fram en bättre FPGA-prototyp på kortare tid än med ett manuellt designflöde.

Exempel – digital down converter
Vi kommer här använda en Digital Down Converter (DDC) som ett exempel för att illustrera ovan nämnda arbetsflöde. En DDC (nedkonverterare) är en vanligt komponent i många digitala signalbehandlings- och kommunikationssystem, se fig 3. Den används för att transformera en snabb passbandssignal till en långsammare basbandssignal. Basbandssignalen kan sedan filtreras med en lägre klockfrekvens än den ursprungliga passbandssignalen. Resultatet blir lägre effektförbrukning och resursförbrukning i den slutgiltiga hårdvaran.

Fig 4. Systemmodell av en DDC.

Fig 4 visar de huvudsakliga delarna i en DDC:
– Numeriskt styrd oscillator (NCO)
– Mixer
– Digital filterkedja

Användning av modellering och simulering för att optimera på systemnivå
Att spendera mer tid med modellering och simulering av systemmodellen är en bra investering för att identifiera en optimal arkitektur. Investeringen betalar ofta igen sig i form av bättre systemprestanda. Genom att arbeta på en hög abstraktionsnivå kan ingenjören snabbt utvärdera olika algoritmer och arkitekturer för givna systemkrav. Som ett exempel kan ingenjören tidigt analysera effekterna av fixtalskvantisering och optimera ordlängder för en yteffektiv och effektsnål implementering.
Ingenjören utvärderar typiskt nya idéer och utvecklar algoritmer med flyttalsmodeller. En implementering som ASIC eller FPGA kräver dock ofta en konvertering till fixtal. Fixtalsmodellen ger dock upphov till kvantiseringsfel. I ett manuellt arbetsflöde sker fixtalskonverteringen ofta i samband med HDL-kodningen. I ett sådant arbetsflöde kan det vara svårt att uppskatta effekterna av fixtalskvantiseringen genom en jämförelse med flyttalsmodellen. Det är också svårt att analysera effekterna av overflow i HDL-modellen.

Fig 5. Skillnaden mellan flyttals- och fixtalsmodellen för första steget i lågpassfiltret i vår DDC.

För att kunna fatta väl genomtänkta designbeslut om t ex skalning av fixtal behöver ingenjören ett sätt att jämföra simuleringsresultat från flyttalsmodellen med fixtalsmodellen innan man börjar skriva kod för HDL-modellen. Om skalningen ändras så att kvantiseringsfelet minskar, dvs vi använder fler bitar ur ordlängden till talets bråkdel, behöver vi troligen öka totala ordlängden för att undvika overflow. Effekten av detta blir att vi behöver mer kiselyta och effektförbrukningen kommer att öka.
I fig 5 ovan ser vi skillnaden mellan flyttals- och fixtalsmodellen för första steget i lågpassfiltret i vår DDC. Skillnaderna beror här på fixtalskvantiseringen. I den övre delen har vi plottat resultatet från flyttalssimuleringen och fixtalssimuleringen i samma graf. Den nedre grafen visar kvantiseringsfelet i varje tidpunkt, i storleksordningen 10-5.

Fig 6. Användning av fixtalsanalys för att identifiering av optimal ordlängd och skalning.

Beroende på designkraven kan ingenjören välja skalning och ordlängd för att minska effekterna av kvantiseringsfelet. Ett minskat kvantiseringsfel innebär ofta en längre ordlängd som i sin tur kostar kiselyta och effektförbrukning. Kan å andra sidan ordlängden minskas så krävs mindre kiselyta och lägre effektförbrukning. Med andra ord är det viktigt att hitta rätt skalning och ordlängd för att möta systemkraven till lägsta kostnad och bästa prestanda. Fig 6 visar ett exempel där ordlängden kunde minskas med åtta bitar, tack vare en effektiv fixtalsoptimering.

Steg 2 – automatisk generering av hdl-kod från systemmodellen
Verilog och VHDL är industristandard för att konstruera FPGAer. En övervägande del av alla FPGAer konstrueras utifrån handskriven HDL-kod. Nu finns teknologin att automatiskt generera HDL-kod från systemmodeller på hög nivå vilket har många fördelar, tex:
– Direkt kunna utvärdera om algoritmen kan implementeras i hårdvara
– Enkelt kunna testa olika implementeringar av algoritmen och välja den bästa
– Snabbt kunna göra en FPGA-prototyp från algoritmen
Säkerhetskritiska applikationer, som t ex kräver DO-254 certifiering, kräver verifiering av hårdvaruimplementeringen mot systemkraven. För att åstadkomma detta måste det finnas spårbarhet från HDL-koden tillbaka till systemmodellen, och till den systemspecifikation som modellen representerar. I vårt exempel är den genererade HDL-koden både läsbar och spårbar tillbaka systemmodellen, som i sin tur sedan kan spåras tillbaka till systemspecifikationen, se fig 7.

Fig 7. Spårbarhet mellan HDL-kod, systemmodell, och systemspecifikation är ett krav för säkerhetskritiska applikationer som följer standarder som tex DO-254.

Vårt DDC-exempel innehåller nästan 5800 rader hypertextlänkad HDL-kod som automatgenererades på ca en minut från vår systemmodell. Möjligheten att generera HDL-kod innebär att ingenjören kan spendera mer tid på att snabbt och iterativt optimera systemmodellen och i förlängningen kunna ta fram en optimal FPGA-prototyp för sin applikation.

Steg 3 –återanvändning av systemtestbänkar tillsammans med hdl-samsimulering
Eftersom systemmodell och HDL-kod kan samsimuleras går det även att återanvända testbänkarna från systemsimuleringen. Dessa kan användas för att generera stimuli för HDL-simulatorn och även för att göra en interaktiv analys av resultaten på systemnivå, se fig 8.

Fig 8. Användning av samsimulering för att debugga HDL-kod innan hårdvaruimplementering.

En HDL-simulator visualiserar resultaten typiskt med digitala vågformer. Med HDL-samsimulering får man full insyn i HDL-koden samtidigt som resultaten kan analyseras på systemnivå. Samsimulering gör det möjligt för ingenjören att utvärdera hur skillnader mellan de förväntade resultaten och HDL-simuleringen kommer att påverka systemprestanda.

Fig 9. Användning av verktyg för systemnivåanalys för att utvärdera en HDL-implementering.

I fig 9 ser vi hur en frekvensanalys gör det möjligt för ingenjören att fatta ett välgrundat beslut att ignorera skillnaden mellan förväntat resultat och HDL-simuleringen eftersom skillnaden ligger i filtrets stoppband. De digitala vågformerna visar bara att det finns en skillnad men inte hur det påverkar systemprestanda. En ingenjör kommer troligtvis till samma slutsats i båda fallen men det skulle troligen ta betydligt längre tid med de digitala vågformerna som utgångspunkt.

Steg 4 – regressionstester med fpga-in-the-loop simulering
Efter systemnivåsimulering och samsimulering med HDL-kod är nu vår DDC-algoritm redo för implementering på en FPGA. FPGA-baserad verifiering, också kallad FPGA-in-the-loop simulering, ökar sannolikheten att algoritmen kommer att fungera i den slutgiltiga applikationen. Det gör det möjligt för ingenjören att exekvera testscenario betydligt snabbare än med traditionell HDL-simulering.
För DDC-algoritmen använder vi systemmodellen för att generera stimuli för FPGAn och sedan analysera utsignalerna från kretsen, figur 10. Precis som vid samsimulering med HDL-koden kan resultaten sedan användas för en systemnivåanalys.
Tabell 1 jämför de två verifieringsmetoderna för DDC-exemplet, samsimulering med HDL-kod respektive FPGA-in-the-loop-simulering.

Fig 10. Användning av FPGA-in-the-loop för att verifiera funktion och prestanda hos hårdvaruimplementeringen.

I det här fallet var FPGA-in-the-loop-simuleringen 23 gånger snabbare än samsimuleringen. Uppsnabbningen gör det möjligt att använda ett större testset och regressionsanalys för designen. På det här sättet kan potentiella problem enklare identifieras och sedan analyseras i mer detalj.

Tabell 1. Jämförelse mellan de två verifieringsmetoderna för DDC-exemplet, samsimulering med HDL-kod respektive FPGA-in-the-loop-simulering.

Även om samsimulering med HDL-kod är långsammare så ger den bättre insyn i HDL-koden. Samsimulering lämpar sig därför bra till mer detaljerad analys av problem identifierade vid FPGA-in-the-loop simulering.

Snabbare prototyper
Genom att följa de fyra “best practices”-stegen i den utvecklingsprocess som vi har beskrivit i den här artikeln kan ingenjörer utveckla FPGA-prototyper betydligt snabbare och med större säkerhet än med ett traditionellt manuellt arbetsflöde. Dessutom kan ingenjören fortsätta förfina modellen genom utvecklingscykeln och snabbt generera ny kod för FPGA-implementering. Detta gör det möjligt att korta designiterationerna jämfört med ett traditionell flöde med manuell HDL-kodning.
Stephan van Beek, Sudhir Sharma, and Sudeepa Prakash, MathWorks

Filed under: Embedded