About / Advertise
Är asicens testbänk tillräckligt bra? Det kan ett kodtäckningsverktyg ge en fingervisning om. Verktyget körs parallellt med simulatorn för att analysera hur pass fullständigt konstruktionsbeskrivningen simuleras.
Den största fördelen med analys av kodtäckning är att man snabbt hittar otestad kod, och därmed kan förbättra testbänken. En annan finess är att man inte behöver lägga ner mer krut än nödvändigt på att utveckla tester. När kodtäckningen är tillräckligt hög bör ju testbänken vara tillräckligt bra. Teststimulit överarbetas annars ofta - för säkerhets skull.
Men man ska vara medveten om att verktyget endast visar hur pass bra testbänken exekverat konstruktionsbeskrivningen. Däremot får man ingen som helst indikation på om testbänken verifierar att konstruktionen verkligen implementerar det som beskrivs i specifikationen.
Trots fördelarna och trots att verktygstypen har funnits på marknaden i flera år, så är det fortfarande inte en självklarhet att använda kodtäckningsanalys i dagens asicprojekt. I boken Reuse Methodology Manual, som samförfattats av Michael Keating på Synopsys och Pierre Bricaud på Mentor Graphics, rekommenderas dock metoden.
Boken vänder sig egentligen till konstruktörer som skapar eller använder färdiga konstruktionsblock, men riktlinjerna kan vara till nytta även för andra konstruktörer.
I RMM beskrivs följande kodtäckningstester:
Programsatstäckning - statement coverage - anger hur många gånger varje exekverbar programsats utförts.
Grentäckning - branch coverage - verifierar att varje gren i if-then-else- och casesatser har utförts.
Villkorstäckning - condition coverage - verifierar att alla undervillkor har triggat en viss gren. I exemplet nedan testas att den första raden utförts med a = 1 och att den utförts med b = 0.
if (a=`1´ or b = `0´) then
c <= `1´;
else
c <= 0;
endif;
Vägtäckning - path coverage - kontrollerar vilka vägar som har tagits mellan angränsande block av villkorad kod. I exemplet nedan finns det flera olika vägar genom de båda if-then-else-blocken beroende på värdet på a och b. Verktyget räknar hur många gånger varje möjlig väg har utförts.
if (a=`1´ or b = `0´) then
c <= `1´;
else
c <= 0;
endif;
if (a=`1´ or b = `1´) then
d <= `1´;
else
d <= 0;
endif;
Triggningstäckning - triggering coverage - kontrollerar vilka signaler i en sensitivitetslista som triggat en process.
Triggertäckning - trigger coverage - räknar hur många gånger en process har aktiverats av att alla signaler i sensitivitetslistan ändrar värde. I exemplet räknar verktyget hur många gånger processen aktiverats av att signal a ändrar värde, av att signal b ändrar värde och att signal c ändrar värde.
process(a,b,c)
...
Växlingstäckning - toggle coverage - analyserar hur många gånger en viss signal växlar från 0 till 1 och vice versa.
CvS
