Verificatie-afmelding buiten dekking

Een algemene ontwerpvisie op het aftekenen van verificatie is om te beginnen met een uitgebreid verificatieplan, dat alle vereisten omvat die zijn gedefinieerd in de specificaties en gebruiksscenario's, de architectonische definitie en alle andere relevante documenten. Vervolgens worden tests ontwikkeld die elk kenmerk van het verificatieplan bestrijken. Deze tests worden uitgevoerd en opgespoord, en geïdentificeerde problemen worden binnen het ontwerp aangepakt. Dit proces herhaalt zich totdat het overeengekomen dekkingsniveau is bereikt. Functionele dekking is de maatstaf waarmee dit proces wordt gemeten, en het werkt goed binnen de reikwijdte ervan. De grote leveranciers van elektronische ontwerpautomatisering (EDA) beschikken over tools om simulaties uit te voeren, dekkingsstatistieken te verzamelen en deze statistieken verder te helpen verbeteren. Maar dit is niet het hele verhaal over de ondertekening. Dekking meet de naleving van het verificatieplan, dat verschillende stappen verwijderd is van de eisen van de klant. Hoe weten ontwerpers dat er onderweg geen cruciale informatie is weggelaten of toegevoegd?

Wat is er nog meer van belang bij de ondertekening?

Alles vóór de intern ontwikkelde functionele specificaties/eisen is van belang. Het is niet mogelijk om de cirkel tussen de klantvereisten en de implementatie/verificatie volledig te sluiten, tenzij deze in de analyse worden meegenomen. Nu worden waardeketens gecomprimeerd en worden systems-on-chip (SoC's) steeds meer toepassingsspecifiek. Klanten verwachten ontwerpen die zijn afgestemd op hun exacte behoeften, dus wat zij als vereisten hebben gedefinieerd, moet bij de implementatie/verificatie worden afgestemd. Het zal niet goed ontvangen worden als de klant ontdekt dat er van hem wordt verwacht dat hij mismatches oplost.

De uitdaging hier is dat de definitie een nogal allegaartje van invoer kan zijn: Word, PDF, op DITA gebaseerde documenten, spreadsheets, Simulink, SysML of prototypes van virtuele modellen, en software die op de uiteindelijke hardware zou moeten draaien (misschien met enige ruimte voor wat veranderingen). Er kunnen ook gedocumenteerde vereisten zijn in DOORS, Jama Connect of een vergelijkbaar formaat. Hoe geeft het verificatieteam, het ontwerpteam of de architect aan dat de implementatie en verificatie voldoen aan de vereisten? Ze zullen uiteraard hun uiterste best doen, maar waar is het gedetailleerde en controleerbare proces om ervoor te zorgen dat elke eis aansluit bij een implementatierealisatie en dat de verificatie van de implementatie adequaat wordt afgedekt?

Om dit concreter te maken: stel dat er een functie is die één belangrijke klant wil, maar niemand anders nodig heeft. Misschien door onoplettendheid of misverstanden, komt deze functie niet in de functionele specificatie/vereiste terecht. Het gebeurt maar al te vaak. Zelfs het ideaal van 100% dekking zal dit probleem niet oplossen, aangezien de dekking slechts zo goed is als het verificatieplan. Er is een groot probleem als het verificatieplan de eisen niet nauwkeurig weergeeft.

Of stel dat een team tijdens het ontwerp besluit dat het niet precies kan implementeren wat de specificatie vraagt, maar dat een alternatief wordt geïmplementeerd in de overtuiging dat het net zo goed of zelfs beter zal zijn. Het team is zich er niet van bewust dat deze wijziging de prestaties in een zeldzame maar belangrijke gebruikssituatie zal beïnvloeden. Misschien wordt dit in simulatie gevangen? Misschien, maar het is erg moeilijk om alomvattend te zijn bij het testen op systeemniveau. Er bestaat een reëel risico dat deze problematische verandering tot aan silicium zal overleven.

Het traceren van vereisten vormt een aanvulling op de dekking voor verificatieaftekening

Het uitvoeren van gelijkwaardigheidscontrole tussen Word-documenten, virtuele modellen en register-transferniveau (RTL) is waarschijnlijk niet mogelijk in onze levens, maar dat hoeft ook niet zo te zijn. Systeembouwers en softwareteams maken al actief gebruik van de traceerbaarheid van vereisten als een zeer robuuste methode om de correspondentie tussen vereisten op het hoogste niveau en op implementatieniveau bij te houden, tot aan de realisatie, verificatie en test. Deze traceerbaarheid wordt ondersteund door het traceren van vereisten met behulp van Requirements Interchange Format (ReqIF) met platforms zoals DOORS en Jama Connect-tools.

Hoewel deze tools zijn ontworpen voor gemakkelijke adoptie in de softwarewereld, begrijpen ze de hardware-semantiek niet. Ze ondersteunen wel koppelingen van “vreemde objecten” om verbinding te maken met ontwerp- en verificatiegegevens, maar de last voor het correct maken van deze koppelingen ligt bij de ontwerp- en verificatie-ingenieurs. Dit zou misschien niet zo erg zijn als er maar een paar honderd objecten waren om te volgen. Maar denk aan de geheugenkaart, de interruptkaart, de IO-muxingkaart; deze kunnen oplopen tot tienduizenden objecten of meer. Handmatige updates van al deze objecten door ontwerpwijzigingen en herpartitionering worden uiterst moeilijk, zo niet onmogelijk.

Een betere aanpak is via traceerbaarheidsbeheer, dat verbinding kan maken met tools zoals ReqIF aan de klantzijde en rechtstreeks met de artefacten die worden bijgehouden door de ontwerp- en verificatieteams. Het begrijpen van de ontwerpsemantiek maakt het mogelijk om verbanden tussen vereisten en implementatie af te leiden en deze correct te volgen naarmate het project zich ontwikkelt. Deze methode zorgt voor controleerbare koppelingen vanaf klantspecificaties, via ontwerpvereisten en uiteindelijk naar de realisatie van de SoC.

Dit is traceerbaarheid die de verificatie-ondertekeningsdoelstelling kan voltooien met een lage impact op SoC-ontwerpteams. Het soort traceerbaarheidsondersteuning dat u zult vinden in Arteris Harmoniespoor.