Säkerhetskritiska system ställer speciella krav på verifieringsarbetet. Ian Gibbins, applikationsingenjör hos Aldec, tar i den här artikeln upp verifieringsproblem för FPGA-baserade system.

Att verifiera komplexa FPGA-konstruktioner blir allt mer utmanande i säkerhetskritiska tillämpningar inom många sektorer, såsom flyg-, bil- och sjukvård, och verksamhetskritiska tillämpningar inom försvarssektorn.
För sådana tillämpningar måste FPGA-verifieringen prägla hela utvecklingscykeln, från projektets utformning, planering, design, implementering och samtliga teststadier. Dessutom måste kraven på spårbarhet vara med, kontinuerligt, från hårdvaran ända tillbaka till den ursprungliga specifikationen.
FPGA-implementeringen verifieras vanligtvis genom RTL-simulering. I de flesta fall är denna simulering utförd efter det att konstruktionskraven har identifierats. RTL- och timingsimulering åtföljs av kodtäckningsanalys för att bekräfta en hundraprocentig täckning av alla möjliga kombinationer av insignaler.
Men, även om simuleringsresultat kan visualiseras, analyseras, jämföras och kraven på spårbarhet uppfylls, så kan beteendet i verkligheten inte alltid vara lätt att spåra tillbaka till simulering.
Resultatet blir ofta att det krävs en hel del tid och ansträngning för att kontrollera att alla krav på konstruktionen har förverkligats i målsystemet. Ändå är det inte möjligt att uppnå hundraprocentig specifikationstäckning när FPGA-kretsarna väl är på kretskorten. Detta utgör då ett stort problem för branschstandarder som ex vis DO-254 (DO-254 specificerar kraven för flygburen elektronik) som ju kräver att säkerhetskritiska konstruktioner verifieras på riktig hårdvara före certifieringen.

Utmaningar med hårdvaruverifieringar:
Traditionellt görs hårdvaruverifieringen på kretskortsnivå, där korten i huvudsak bestyckats med FPGA-kretsar. FPGA-komponenterna kommer sannolikt att innehålla huvuddelen av kortets funktioner och IP, förutom då komponenter såsom mikroprocessorer, DSP och minne.
Tyvärr kan sådan verifiering på kortnivå vara förenat med problem och leda till betydande projektförseningar om stabiliteten i FPGA-koden inte är bekräftad först. Dessutom kan ju kort innehålla mer än en FPGA, vilket gör problemet med kontroll, observerbarhet och testtäckning ännu mer komplicerat.

I Aldecs Compliance-verktyg genereras ”golden vectors” och ingångsvektorer automatiskt för alla tillämpliga testbänkar.

I många fall, då kretskortledarna förblir osynliga (ex vis. ledare mellan BGA-kontakter), blir kontrollen av en FPGA (på pin-nivå) mycket begränsad.
Därför uppstår många stora utmaningar vid verifiering på FPGA-nivå. Dessa problem inkluderar bl a:
* Spårbarhet av testresultat – t ex att kartlägga och jämföra hårdvaruutgångar till motsvarande RTL-simuleringsresultat och spåra dem mot den ursprungliga kravspecifikationen. Detta är en stor utmaning. Eftersom de flesta traditionella testmetoder inte tillåter faktiskt test av hårdvaran med alla tänkbara kombinationer av stimuli, definierade av kodtäckningsgraden för RTL-simulering, kan inte alla krav spåras och ytterligare analys kommer därför att krävas.
* Att manuellt generera testvektorer för att verifiera specifikationen är en tidsödande uppgift – och en som inte sällan kan ta ett halvår för en inte alltför komplex applikation. För RTL-simulering skapas testbänkar för att verifiera specifika krav och utmaningen här blir att hitta ett sätt att återanvända dem för att förkorta tiden för hårdvarutestningen.
* FPGA-implementeringsprocessen kan i sig introducera fel i funktion eller timing. Inte minst kan en uppdatering av syntesverktyget ofta resultera i fel. Eftersom målenheten inte kan innehålla några ytterligare debugmoduler (exempelvis prober specifika för JTAG-debugverktyg), är det inte lätt att analysera och felsöka problemen.
* Ett flertal testmiljöer behövs sålunda, för att verifiera olika uppsättningar av testfall. Detta tenderar att involvera manuell förbikoppling av ledningar och kablar, där ingenjören riskerar att lätt koppla fel. Dessutom måste man för varje testmiljö utveckla flera testfall, som var och en skall analyseras – vilket som bekant kan ta månader att slutföra.
Att verifiera specifikationen på FPGA-nivå är absolut nödvändigt för säkerhets- och verksamhetskritiska tillämpningar, men kombinationen av alla ovanstående frågor innebär att en kontroll på kretskortsnivå är ganska svår och ibland helt enkelt inte möjlig.
Följaktligen väljer ingenjörer allt oftare att verifiera direkt i hårdvaran.

Verifiering i hårdvara
Denna metod bygger på användning av en bit-exakt, hårdvaruverifieringsmiljö som kan kontrollera och spåra samma FPGA-krav från RTL till målenheten, och detta med hög klockhastighet.
Ett exempel på detta är Aldecs miljö för hårdvaruverifiering. Det är en verktygsuppsättning som består av:
* Ett anpassat dotterkort som innehåller en FPGA (dvs den som ska verifieras).
* Ett COTS-moderkort (PCIe) för att skicka testvektorer till och läsa resultat från dotterkortet.
* Mjukvara för att få det hela att fungera tillsammans.
Som en del av ett traditionellt designflöde, är testbänkarna skapade för RTL-simulering. De innehåller testvektorer för att köra hela konstruktionen. Hårdvaruverifieringsmetoden bygger på detta grundläggande steg, med tillägg av en simulator-plug-in för lagring av sekvenser av stimuli som körs (inom RTL-simuleringen). Dessutom genererar dessa plug-in automatiskt testvektorer från flera testbänkar.

PCIe-moderkort som används för att sända testvektorer till och läsa resultat från ett dotterkort som innehåller en mål-FPGA.

Processen, som hos Aldec är helt automatiserad, genererar två uppsättningar testvektorer för alla tillämpliga testbänkar. Dessa är:
* ”Gyllene Vektorer”, som består av RTL-simuleringsresultaten och kommer att användas för jämförelser.
* Ingångsvektorer, som används för verifiering i full hastighet.
Automation leder här till en betydande tidsbesparing jämfört med att manuell testa vektorer. Även testvektorer för hårdvaruverifiering – om den förberetts i en vågform – kan användas för ytterligare granskning och analys före och efter hårdvaruverifieringen.
Efter att nu enkelt ha skapat testvektor blir resterande uppgifter att:
* Använda dessa testvektorer för att kontrollera hårdvaran i systemhastighet;
* Dokumentera resultatet;
* Koppla resultaten till RTL-simuleringar;
* Se till att RTL-simulering och hårdvaruverifieringsresultaten matchar.
För att göra detta i t ex Aldecs Compliance-miljö, läses ingångsvektorerna in (från en arbetsstation) till moderkortet. Compliance Software-mjukvaran kontrollerar sedan i verifieringsprocessen i maskinvaran genom att generera ingångsvektorer till FPGA-pinnarna i rätt klockhastighet. Processen görs klar automatiskt utan att lägga några ”wrappers” till vektoruppsättningen. Detta skulle ju vara negativt med tanke på kravet på spårbarhet.

Full fart
De resultat som erhållits under hårdvaruverifiering samplas sedan i full klockfrekvens och sparas i en vågformsfil. Aldec Compliance-mjukvaran jämför sedan automatiskt verifieringsresultaten i hårdvaran (dvs utgångsvektorerna) med RTL-simuleringsresultaten (de ”Gyllene Vektorerna”).
Att köra FPGA-delen på det här sättet gör att FPGA-komponenten eller FPGA-komponenterna utför avsedda funktioner, isolerat, i avsedd klockhastighet och i den verkliga hårdvaran. Detta tillvägagångssätt har en klar fördel gentemot hårdvaruacceleratorer, som bara kör en kartläggning av designen på testbänksklockorna och är begränsade till simulatorns maxhastighet.

Dotterkort med mål-FPGA.

Att köra hårdvaruverifieringen i full fart och i hårdvaran gör att man lättare kan upptäcka flera typer av fel, t ex:
* Fel orsakade av syntes- och place & route-verktyg;
* Problem med samtidigt switchande utgångar (SSO) – vilket kan leda till överhörningsproblem;
* Skillnader mellan simuleringsmodeller och nätlistor;
* Klocknings- och resetfel;
* Allmänna begränsningar eller krav beroende på FPGA-komponenten, som helt enkelt inte syns vid simuleringen (t ex om klockan är ansluten till vanliga I/O istället för den rätta klocksignalen.)
En särskilt krävande tillämpning är flygburna system, där Aldecs Compliance-verktyg har visat sig särskilt effektiva som verifieringsplattform för DO-254-standarden. DO-254-certifiering baseras på uppgifter om projektets utformning, planering, design, genomförande och utprovning, och konstaterar att de krav som kontrolleras under RTL-simulering måste återverifieras under hårdvarukontroll.

Viktigt
Hårdvaruverifiering på FPGA-nivå kan vara av avgörande betydelse för säkerhets- och verksamhetskritiska tillämpningar. Att tidigt kunna testa den faktiska FPGA-kretsen, isolerad och vid systemets klockhastighet, förvissar konstruktören om att designen är felfri och stabil.
Att kunna återanvända testbänken som testvektorer för hårdvarutester ger garantier för att samma FPGA-krav verifieras helt oberoende, från RTL till målenhet. Samma tester kan köras på målenheten som i RTL-simulatorn. Därför kan man uppnå hundraprocentig täckning, säkert och automatiskt. Och eftersom testvektorer genereras automatiskt, finns det ingen anledning att utveckla ytterligare tester för enbart hårdvaran.
Observera att det inte finns någon anledning att ändra testvektorerna, eftersom detta skulle äventyra spårbarheten mot RTL-testbänken, som ju kommer direkt från den ursprungliga specifikationen.
Slutligen ger hårdvaruverifiering på FPGA-nivå hundraprocentig visibilitet och kontrollerbarhet, något som normalt sett knappast är möjligt att uppnå.
Ian Gibbins, applikationsingenjör, Aldec
 

Filed under: EDA