C-testcases automatiseren voor verificatie van embedded systemen

Terwijl systeem-op-chip (SoC)-ontwerpen opmars naar grotere complexiteit, worden testsuites met duizenden regels code voor verificatie op systeemniveau nog steeds met de hand geschreven, een ouderwets ouderwetse en ineffectieve praktijk die het adagium 'automatiseer wanneer mogelijk." Dit geldt met name voor C-tests die worden uitgevoerd op de ingebouwde processors van een SoC om het hele apparaat te verifiëren voorafgaand aan fabricage.

Het is aangetoond dat het waar mogelijk automatiseren van de samenstelling van verificatietests de productiviteit verhoogt voor vele fasen van SoC-ontwikkeling. Beperkte willekeurige technieken, bijvoorbeeld in een Universal Verification Methodology (UVM) testbank, maken gebruik van gerandomiseerde testvectoren gericht op specifieke scenario's om de dekking te vergroten. Hoewel deze de verificatie-efficiëntie op hardwareblokniveau hebben verhoogd, wordt het ontwerp nog steeds gezien als een zwarte doos met afzonderlijk geschreven stimulus, controles en dekkingscode, nog steeds een lastige en foutgevoelige taak voor grote blokken.

Het is moeilijk om deze methodologie uit te breiden naar het systeemniveau, gezien de noodzaak om processortestcode te combineren met I/O-transacties, vaak uitgevoerd op een emulator- of prototypingsysteem. Om een ​​SoC goed te verifiëren, moeten de verwerkers zelf worden uitgeoefend. UVM en andere beperkt-willekeurige benaderingen houden geen rekening met code die op de processors wordt uitgevoerd. Om UVM op een SoC te gebruiken, worden de processors vaak verwijderd en vervangen door virtuele in- en uitgangen op de SoC-bus, waardoor het subsysteem minus de processor kan worden geverifieerd.

SoC-verificatie-ingenieurs erkennen de beperkingen van beperkte willekeurige testbanken, waardoor ze C-tests met de hand schrijven die op de processors worden uitgevoerd voor zowel simulatie als hardware-emulatie, ook al zijn ze beperkt in het volledig uitoefenen van het SoC-ontwerp. De prestaties van deze verificatieplatforms zijn niet goed genoeg om een ​​volledig besturingssysteem (OS) uit te voeren, dus deze tests worden "bare-metal" uitgevoerd, wat een aanzienlijke overhead toevoegt aan de compositie-inspanning. Het is ongebruikelijk dat handgeschreven tests, vooral zonder de hulp van OS-services, op een gecoördineerde manier worden uitgevoerd over multi-coreprocessors die gebruikmaken van meerdere threads. Het resultaat is dat aspecten van SoC-gedrag, zoals gelijktijdige bewerkingen en coherentie, minimaal worden geverifieerd.

Automatisch C-tests genereren

Natuurlijk zullen automatisch gegenereerde C-tests efficiënter gebruik maken van technische middelen. Ze vergroten ook de dekking. Gegenereerde C-testcases kunnen meer van de SoC-functionaliteit uitoefenen dan handgeschreven tests en zullen moeilijk voor te stellen complexe hoekgevallen zoeken. Testgevallen met meerdere threads en meerdere processors kunnen alle parallelle paden binnen het ontwerp uitvoeren om gelijktijdigheid te verifiëren. Ze kunnen gegevens tussen geheugensegmenten verplaatsen om coherentie-algoritmen te benadrukken, en coördineren met de I/O-transacties wanneer gegevens naar de ingangen van de chip moeten worden verzonden of van de uitgangen moeten worden gelezen. Het algehele effect hiervan is dat de functionele dekking van het systeem wordt vergroot, doorgaans meer dan 90% van de cijfers die kenmerkend veel lager zijn.

De testgeneratiesoftware, bekend als Test Suite Synthesis, maakt gebruik van een gemakkelijk te begrijpen, op grafieken gebaseerd scenariomodel dat het beoogde ontwerpgedrag vastlegt. Deze modellen kunnen worden geschreven met behulp van de Accellera Portable Stimulus Standard met native C++ of visueel worden beschreven. Scenariomodellen worden gemaakt door ontwerp- of verificatie-ingenieurs als een natuurlijk onderdeel van SoC-ontwikkeling, omdat ze lijken op traditionele chipgegevensstroomdiagrammen die op een whiteboard kunnen worden getekend om een ​​deel van de ontwerpspecificatie uit te leggen.

Deze modellen omvatten inherent stimulus, controles, dekkingsdetails en debug-informatie, waardoor de generator alles heeft wat hij nodig heeft om hoogwaardige, zelfcontrolerende C-testgevallen te produceren die elk aspect van het ontwerp benadrukken. Omdat ze hiërarchisch en modulair zijn, kunnen alle tests die op blokniveau zijn ontwikkeld, volledig worden hergebruikt als onderdeel van het volledige SoC-model en eenvoudig worden gedeeld met verschillende teams en tussen projecten. Ten slotte kan het enkele intentiemodel worden ontleed door de synthesetool om de gelijktijdige tests over threads en I/O-poorten te bieden, allemaal samen gesynchroniseerd.

Voordelen testsuite-synthese

Een belangrijk voordeel van de synthese van testsuites is de mogelijkheid om dekkingsdoelen vooraf te definiëren in het intentiemodel. Zodra de intentie is gespecificeerd, kan de tool deze analyseren om inzicht te krijgen in het aantal tests dat zou kunnen worden geproduceerd en de dekking van de functionele intentie die zou worden bereikt.

Voor een SoC kan dit vele duizenden tests tellen. Dekkingsdoelen kunnen vervolgens worden vastgesteld door de te testen intentie te beperken en de tool op belangrijke gebieden te concentreren. Deze mogelijkheid bespaart de pijnlijke iteratieve lus die optreedt bij traditionele benaderingen, namelijk het opzetten van de tests, het uitvoeren van de verificatietool, het begrijpen van de bereikte dekking en het vervolgens steeds opnieuw resetten van de tests.

In een typisch project op een grote SoC ontwikkeld door een bekend halfgeleiderbedrijf, verminderden de verificatie-ingenieurs de testcompositietijd tot 20% van wat eerder handgeschreven tests nodig waren. De automatiseringstechnologie leverde strengere testgevallen op, waardoor de dekking steeg van 84% naar 97%. Bovendien zijn de modellen draagbaar.

Een enkel model kan testgevallen genereren voor virtuele platforms, register transfer level (RTL) simulatie, emulatie, field programmeerbare gate array (FPGA) prototypes of een daadwerkelijke chip in het laboratorium die post-siliciumvalidatie ondergaat.

Debuggen is een ander tijdverlies voor ingenieurs, vooral op SoC-niveau. Als een testcase een loerende ontwerpbug aan het licht brengt, moet de verificatie-engineer begrijpen welke test de bug heeft veroorzaakt om de bron op te sporen. Het mislukken van een testcase kan te wijten zijn aan een fout in het scenariomodel, dus het moet mogelijk zijn om de testcase terug te correleren met de grafiek waarin de ontwerpintentie is vastgelegd. Dit proces creëert zeer modulaire en op zichzelf staande tests die gemakkelijk kunnen worden ontleed, zodat de test die wordt uitgevoerd om de bug te ontdekken, gemakkelijk te zien is.

Toepassingsscenario's

Gesynthetiseerde testgevallen kunnen realistische gebruiksscenario's, toepassingsscenario's genoemd, voor het ontwerp uitvoeren. Kijk bijvoorbeeld eens naar de SoC van de digitale camera die wordt getoond in figuur 1.

klik voor grotere afbeelding

Figuur 1:Voorbeeld van beeldverwerking SoC. (Bron:Breker-verificatiesystemen)

De SoC-componenten op blokniveau omvatten twee processors, de randapparatuur en het geheugen. Een eenvoudige grafiek voor de SoC wordt weergegeven onder het blokschema. De grafiek bevat de mogelijke paden op hoog niveau die kunnen worden uitgeoefend in het SoC-verificatieproces. Een mogelijk scenario, uitgedrukt in het bovenste pad van de grafiek, leest bijvoorbeeld een JPEG-afbeelding van de SD-kaart en geeft deze door aan de fotoprocessor via een toegewezen regio in het geheugen. De afbeelding wordt verwerkt tot een vorm die kan worden weergegeven en in een tweede blok in het geheugen kan worden geladen. Van daaruit wordt het doorgegeven aan de displaycontroller. Natuurlijk is elk van deze blokken op hoog niveau hiërarchisch van aard, waarbij veel acties en beslissingen worden uitgevoerd als onderdeel van het proces.

De synthesetool neemt de gerandomiseerde test en plant ze op de juiste manier. In de eenvoudigste vorm, zoals weergegeven in de afbeelding, kan de test worden gepland in een enkele thread, gevolgd door de volgende test, enzovoort. Het vermogen van testcases om de SoC te benadrukken, komt echter van het interleaven van applicaties over meerdere threads en meerdere processors. De tool zal zoveel applicaties parallel draaien als ondersteund door de inherente gelijktijdigheid van het ontwerp, waarbij geheugen op een zo kronkelige manier wordt toegewezen. Dit wordt ook als alternatief getoond in de afbeelding waar de tests zijn verspreid over drie threads, waarbij gebruik wordt gemaakt van verschillende regio's die zijn toegewezen aan de SoC-geheugens.

Uiteraard wordt dit voorbeeld op hoog niveau gepresenteerd om het proces duidelijk te maken. In werkelijkheid zal de hiërarchische grafiek worden afgevlakt door de synthesetool, waardoor een groot aantal acties en verbindingen ontstaat. Deze omvatten ook gerandomiseerde beslissingen, die via een oplosseralgoritme moeten worden uitgevoerd. Terwijl de grafiek wordt gelopen, worden AI-planningsalgoritmen gebruikt die de gewenste outputs inspecteren en de inputtests optimaliseren om hieraan te voldoen. De synthesetool omvat OS-achtige services die geheugen toewijzen, adreskaarttoegang, procesonderbrekingen en andere taken bieden die nodig zijn om teststructuren te voltooien. De tests worden vervolgens willekeurig gepland met opslag en andere bronnen die op de juiste manier zijn toegewezen.

Conclusie

Net zoals constrained-willekeurige testbanken handmatig werk voor blokverificatie elimineerden, is bewezen dat gesynthetiseerde testinhoud voor embedded processor-gebaseerde SoC's de verificatie-inspanning op systeemniveau vermindert. Bovendien wordt deze oplossing nu toegepast op blokniveau en voor post-siliciumvalidatie. In dit voorbeeld passen geautomatiseerde C-testcases het adagium 'automatiseer waar mogelijk' toe, waardoor de dekking drastisch verbetert en de verificatieschema's worden verkort.