Kodtäckningen ger extra trygghet i asicprojekt

Konstruktörerna i ett pågående asicprojekt på Ericsson Radio

i Nacka Strand hittar snabbt overifierad VHDL-kod.

Hemligheten ligger i ett kodtäckningsverktyg som pekar ut var det saknas testfall.

- Många inser nog inte hur lätt det är att använda kodtäckningsanalys och hur mycket det faktiskt tillför. Men utan kodtäckningsanalys har man alltid kod som inte testas. Det behöver visserligen inte ge problem, men det kan göra det, säger Peter Ljung.

Han har haft verifiering som sitt levebröd i snart tio år, dels på FFV, dels på Ericsson. Nu är han konsult på ISS Consulting och är delansvarig för verifieringen i ett asicprojekt på Ericsson Radio i Nacka utanför Stockholm. Och då tar han hjälp av ett verktyg för kodtäckningsanalys för att verifiera att testbänken verkligen ger konstruktionen en genomkörare.

Peter Ljung beskriver asicen som komplex med många beroenden som ger svår verifiering och många olika testfall. Den har runt 200 000 grindar plus DRAM och ska tjänstgöra som väljarport i en ny WCDMA-plattform.

- Det känns bra att köra kodtäckningsanalys för att snabbt upptäcka saknade testfall, säger han.

Pressad tidsplan

Projektets åtta konstruktörer är färdiga med beteendebeskrivningen och utvecklar nu registerkod, RTL. Tidsplanen är pressad. När registerkoden är färdig ska Peter Ljung och hans medarbetare ha testbänken med runt 80 testfall startklar.

- Vi utvecklar testbänken med ett RTL-gränssnitt redan från början. Det tror jag inte är så vanligt, men det sparar tid jämfört med att ta fram en beteendetestbänk som sedan måste översättas till registernivån.

Kodtäckningsverktyget används på beteende- såväl som registernivå. Målet är att 100 procent av koden ska vara analyserad.

- Vid en första körning med kodtäckningsverktyget brukar man ligga mellan 85 till 90 procent. Sedan förbättrar man testbänken tills man når uppemot 95 procent. De otestade delarna analyserar vi sedan manuellt.

Att delar av konstruktionsbeskrivningen är otestade behöver inte alls betyda att testbänken är dålig, utan kan bero på att konstruktionsbeskrivningen exempelvis innehåller "when else"-satser som ska styra syntesverktyget.

inga problem med testtider

Kodtäckningsverktygens förespråkare påpekar gärna att kodtäckningsanalys kan användas för att minimera testbänken genom att man hittar och kan ta bort redundanta testfall. Men den möjligheten utnyttjar inte Peter Ljung.

- Vi har inte problem med våra testtider. Vi har många testfall som körs i korta simuleringar under felsökningsfasen. Sedan kör vi hela testbänken över en helg, så kodtäckningsanalysen kostar egentligen ingen extra tid.

Trots att Peter Ljung är positiv till metoden använder han långt ifrån alla varianter på kodtäckning.

- Det gäller att hitta en lagom balans. Om man sätter målen för högt blir man inte färdig i rimlig tid.

En lagom balans i det här projektet tycker han är att använda programsatstäckning, statement coverage. Och skulle han lägga till något skulle det vara grentäckning, branch coverage.

Charlotta von Schultz

ISS Consulting tillhör ISS-gruppen, som distribuerar kodtäckningsverktyget HDLScore från Summit. I Peter Ljungs nuvarande projekt används dock HDLCover från TransEDA, som distribueras av Hardi Electronics.