Een aantal mensen moet zich het hoofd krabben over wat UVM en machine learning (ML) gemeen hebben, zodat ze kunnen worden omschreven als met dezelfde gebreken. In beide gevallen is het in zekere zin een fout van weglating.

Laten we beginnen met ML, en in het bijzonder objectherkenning. Tien jaar geleden slaagde Alexnet erin om, in combinatie met GPU's, alle objectdetectiesystemen te verslaan die op traditionele technieken vertrouwden. Vanaf die dag zijn er gestage verbeteringen aangebracht. Modellen zijn groter en complexer geworden en hun resultaten hebben de nauwkeurigheid van mensen overtroffen. Een soortgelijk verhaal zou te maken kunnen hebben met verificatie die vroeger berustte op gericht testen. Vervolgens zorgde de introductie van het genereren van beperkte willekeurige testpatronen, gevolgd door SystemVerilog en UVM, voor een grotere dekking.

Maar er zijn twee problemen. Het eerste probleem voor ML is dat je nooit weet of je het netwerk met voldoende afbeeldingen hebt getraind en of elk van die afbeeldingen nuttig is. Er is één duidelijk gemeenschappelijk punt met het idee van het genereren van willekeurige testpatronen. Geen van beide heeft een manier om voltooiing te definiëren, en de patronen die worden gebruikt voor functionele verificatie - net als de afbeeldingensets die worden gebruikt voor ML - zijn verre van efficiënt. Er wordt veel tijd en geld besteed aan het definiëren van goede datasets voor ML die zowel compleet als vrij van vooringenomenheid zijn, maar meestal mislukken.

Misschien denk je dat functionele prikkels vrij zijn van vooroordelen, maar dat is ook niet waar. Het is bevooroordeeld in de richting van de problemen waarvan elk team op de hoogte is, problemen waardoor ze recentelijk zijn gestruikeld, of gebieden die nieuw zijn - om nog maar te zwijgen van de problemen die het meest waarschijnlijk een respin veroorzaken. Er zijn vrijwel zeker heel weinig tests die zoeken naar prestatieproblemen, stroomproblemen, beveiligingsproblemen, veiligheidsproblemen en vele andere dingen die gemakkelijker onder het tapijt kunnen worden geveegd.

Het idee van volledigheid is aangepakt door functionele verificatie, door dekking op te nemen, maar die statistieken zijn zowel onvolledig als bevooroordeeld. Ze zijn onvolledig omdat het bereiken van 100% functionele dekking u niets zegt over hoe goed uw ontwerp is geverifieerd. Het toont alleen vooruitgang in de richting van een willekeurig doel. Er is mij vaak verteld dat functionele dekking vaak scheef ligt in de richting van die problemen die gemakkelijk te vinden zijn, in plaats van echt representatief te zijn voor de staatsruimte van het ontwerp.

Aan de andere kant heeft objectherkenning geen echte statistieken. Ze tellen grootte zonder een echte maatstaf voor kwaliteit. Autonoom rijden moet bijvoorbeeld straatnaamborden kunnen herkennen. In 2013 werd een database gecreëerd die ongeveer 900 afbeeldingen bevatte met 1,200 verkeersborden die werden vastgelegd tijdens verschillende weersomstandigheden en tijdstippen van de dag. In 2016 was een andere database gegroeid tot ongeveer 100,000 afbeeldingen met een veel hogere resolutie. Maar is het compleet? Wie weet?

Hoeveel beter zijn detectiesystemen gebaseerd op die nieuwe database? Zoals Steven Teig, CEO van Perceive in zijn DAC 2022-keynote opmerkte, blijven ze vrij gemakkelijk voor de gek te houden door alleen wat ruis te injecteren. Maar dat is slechts één vorm van vijandige aanval op hen. Ze hebben het vaak helemaal bij het verkeerde eind.

En dit brengt ons bij de tweede en grootste fout die ze hebben. ML is van nature onbetrouwbaar. Van auto's is bekend dat ze zonder goede reden tegen geparkeerde voertuigen van hulpdiensten botsen of tot een noodstop komen, waardoor ongelukken ontstaan. Hoe kan dit gebeuren als ze zogenaamd beter zijn dan een mens in het onderscheiden van elk denkbaar hondenras? Het is omdat ze geen idee hebben van belangrijkheid of kritiek. Elke foto, elke herkenning wordt als een gelijke behandeld. En hoewel ze gemiddeld beter zijn dan een mens, is het zeer onwaarschijnlijk dat mensen dit soort catastrofale fouten maken. Kan iemand aangeven wat er mis was met het model, of welke afbeelding in de trainingsset had moeten staan? Nee. ML blijft dus inherent onbetrouwbaar.

Hoe verhoudt zich dat tot functionele verificatie? We hebben ook geen manier om het belang of de ernst te meten. Elk dekkingspunt wordt als een gelijke behandeld. Teams stoppen wanneer ze 99.99% dekking hebben, maar wat als dat laatste dekkingspunt eigenlijk een fatale fout is? Alleen omdat de willekeurige verificatie er niet in slaagde om te activeren, maakt het niet minder belangrijk. Ja, het is mogelijk dat via een verificatieplan in de loop van de tijd dekkingspunten worden toegevoegd, zodat functionaliteitsniveaus kunnen worden geverifieerd voordat wordt overgegaan op meer obscure functionaliteit. Maar ik ken geen enkel bedrijf dat hiervoor een geformaliseerde methode heeft.

Zowel ML als UVM kunnen niet definiëren wat belangrijk en cruciaal is, en daarom is ML onbetrouwbaar - en waarom verificatiemanagers 's nachts niet kunnen slapen. Het gebruik van use-case scenario's is een stap in de goede richting, omdat het ons in staat stelt om te definiëren wat belangrijk is, maar dat brengt ons in wezen een stap terug naar gericht testen. Het was beperkt willekeurig waardoor er veel meer testcases konden worden gemaakt en het ontwerp in een toestand kon komen waarvan niemand misschien had gedacht om er een test voor te maken, maar door dat te doen, verloren we de noties van focus, belang en efficiëntie.

Het is tijd om de voltooiing en het belang van zowel functionele verificatie als machine learning te heroverwegen, en daarnaast een methodologie in te voeren die afsluiting efficiënt definieert.