Verifieringssignering bortom täckning

En vanlig designvy av verifieringssignoff är att börja med en omfattande verifieringsplan som täcker alla krav som definieras bland specifikationer och användningsfall, den arkitektoniska definitionen och alla andra relevanta dokument. Tester utvecklas sedan för att täcka alla funktioner i verifieringsplanen. Dessa tester körs och felsöks, och identifierade problem åtgärdas inom designen. Denna process upprepas tills den överenskomna täckningsnivån uppnås. Funktionell täckning är det mått som denna process mäts med, och den fungerar väl inom dess räckvidd. De stora leverantörerna av elektronisk designautomation (EDA) har verktyg för att köra simuleringar, ackumulera täckningsstatistik och hjälpa till att utveckla dessa mätvärden ytterligare. Men detta är inte hela historien i signoff. Täckning mäter efterlevnad av verifieringsplanen, som är flera steg borttagna från kundens krav. Hur vet designers att kritisk information inte har tappats eller lagts till på vägen?

Vad mer är viktigt vid signoff?

Allt innan de internt utvecklade funktionsspecifikationerna/kraven har betydelse. Det är inte möjligt att helt sluta slingan mellan kundkrav och implementeringen/verifieringen om inte dessa ingår i analysen. Nu är värdekedjorna komprimerade och system-on-chip (SoCs) blir mer applikationsspecifika. Kunder förväntar sig design som är anpassad till deras exakta behov, så vad de definierade som krav måste matchas vid implementering/verifiering. Det kommer inte att tas emot väl om kunden upptäcker att de förväntas lappa runt missmatchningar.

Utmaningen här är att definitionen kan vara en ganska blandad påse av input: Word, PDF, DITA-baserade dokument, kalkylblad, Simulink, SysML eller virtuella modellprototyper, och mjukvaruladdningar som bör köras på den slutliga hårdvaran (kanske med hänsyn till vissa ändringar). Det kan också finnas dokumenterade krav i DOORS, Jama Connect eller liknande format. Hur bekräftar verifieringsteamet, designteamet eller arkitekten att implementeringen och verifieringen matchar kraven? De kommer naturligtvis att göra sitt absolut bästa, men var är den detaljerade och granskningsbara processen för att säkerställa att varje krav kartläggs till en implementeringsförverkligande och att verifiering av implementeringen täcks på ett adekvat sätt?

För att göra detta mer konkret, anta att det finns en funktion som en viktig kund vill ha, men som ingen annan behöver. Kanske genom förbiseende eller missförstånd, kommer denna funktion inte in i funktionsspecifikationen/kravet. Det händer allt för ofta. Även idealet med 100 % täckning kommer inte att fånga detta problem eftersom täckningen bara är lika bra som verifieringsplanen. Det finns ett stort problem om verifieringsplanen inte exakt återspeglar kraven.

Eller anta att ett team under designen bestämmer sig för att det inte kan implementera exakt vad specifikationen efterfrågar, utan ett alternativ implementeras med tron ​​att det blir lika bra eller ännu bättre. Teamet är inte medvetet om att denna förändring kommer att påverka prestandan i vissa sällsynta men viktiga användningsfall. Kanske kommer detta att fångas i simulering? Kanske, men det är väldigt svårt att vara heltäckande i tester på systemnivå. Det finns en reell risk att denna problematiska förändring kommer att överleva hela vägen till kisel.

Kravspårning kompletterar täckningen för verifieringssignoff

Att köra likvärdighetskontroll mellan Word-dokument, virtuella modeller och registeröverföringsnivå (RTL) är sannolikt inte möjligt under våra liv, men det behöver inte vara det. Systembyggare och mjukvaruteam använder redan aktivt kravspårbarhet som en mycket robust metod för att spåra överensstämmelse mellan krav på toppnivå och implementeringsnivå, ner till realisering, verifiering och test. Denna spårbarhet stöds med kravspårning med hjälp av Requirements Interchange Format (ReqIF) med plattformar som DOORS och Jama Connect-verktyg.

Även om dessa verktyg är utformade för att enkelt kunna användas i mjukvaruvärlden, förstår de inte hårdvaransemantik. De stöder "främmande objekt"-länkar för att ansluta till design- och verifieringsdata, men bördan för att göra dessa länkar korrekt faller på design- och verifieringsingenjörer. Detta kanske inte är så illa om det bara fanns några hundra föremål att spåra. Men tänk på minneskartan, avbrottskartan, IO-muxingkartan; dessa kan omfatta tiotusentals föremål eller mer. Manuella uppdateringar av alla dessa objekt genom designändringar och ompartitionering blir extremt svårt, för att inte säga omöjligt.

Ett bättre tillvägagångssätt är genom spårbarhetshantering, som kan ansluta till verktyg som ReqIF på kundsidan och direkt till artefakterna som spåras av design- och verifieringsteamen. Att förstå designsemantik gör det möjligt att sluta sig till samband mellan krav och implementering och att hålla dessa spårade på rätt sätt när projektet utvecklas. Denna metod säkerställer granskningsbara kopplingar från kundspecifikationer, ner genom designkrav och i slutändan till förverkligandet av SoC.

Detta är spårbarhet som kan fullborda verifieringsmålet med låg påverkan på SoC-designteam. Den typ av spårbarhetsstöd du hittar i Arteris Harmony Trace.