Verificatie is het fundamenteel vergelijken van twee modellen, elk onafhankelijk afgeleid, om uit te zoeken of er verschillende gedragingen zijn tussen de twee modellen. Een van die modellen vertegenwoordigt het beoogde ontwerp, en de andere is onderdeel van de testbank.

In een ideale stroom zou het ontwerpmodel worden afgeleid van de specificatie en zou elke fase van het ontwerpproces andere details toevoegen totdat het definitieve ontwerp is verkregen. Informatie hoeft niet twee keer te worden toegevoegd, wat vaak de oorzaak is van fouten of ertoe leidt dat modellen niet meer op elkaar aansluiten.

Wat ook deel moet uitmaken van die stroom, is een duidelijk pad voor verificatie, en dit moet uit het vereistendocument komen. Vereisten zijn wat de hele verificatiestroom moet aansturen. We zien dat voor een klein deel bij verificatieplanning, waarin de functies worden vermeld en vervolgens hoe die functies moeten worden geverifieerd. Maar dat is een ad-hocproces, dat leidt tot een nog meer ad-hocstatistiek die functionele dekking wordt genoemd.

Als zowel de specificatie- als de vereistenmodellen zouden worden geformaliseerd, zou het veel gemakkelijker zijn om te zien hoe AI en ML kunnen worden gebruikt om de relaties tussen die modellen te begrijpen en zo directe hulp te kunnen bieden bij taken zoals het invullen van dekkingsdoelen, debuggen en dit zou op zijn beurt leiden tot een beter algemeen proces. Het zou ook voldoen aan de eisen van de huidige zeer betrouwbare stromen die volledige tracking vereisen, van vereisten tot implementatiedetails en tests.

We moeten teruggaan en kijken naar het gebruik van geformaliseerde vereisten. Elke eigenschap, of elke run, houdt rechtstreeks verband met ervoor zorgen dat aan een bepaalde vereiste wordt voldaan. Elke eis heeft zijn eigen definitie van wat volledig betekent. Valt een eis weg, dan wordt duidelijk welke toetsen achterwege kunnen blijven. Of wanneer een agile benadering wordt gebruikt, kunnen vereisten worden toegevoegd naarmate het product rijpt en kleine incrementele batches worden toegevoegd aan de regressiesuite.

Het moet mogelijk zijn om te gaan analyseren welke delen van een ontwerp een rol spelen bij het vervullen van een eis, mogelijk overbodige activiteiten vinden die niet bijdragen aan het resultaat, en die dus kunnen worden gezien als een kandidaat voor energiebesparing.

Functionele dekking was in die tijd een belangrijke vooruitgang. Zonder dit zouden beperkte willekeurige verificatietechnieken niet zo succesvol zijn geweest als ze zijn geweest. Maar ze zijn ook problematisch omdat er geen directe associatie is met de daadwerkelijke functionaliteit. Het is een model dat nergens anders mee te maken heeft. Deze onnodige indirectheid maakt het voor machine learning moeilijker om goed werk te leveren. Door het te vervangen door iets dat rechtstreeks is afgeleid van of verband houdt met vereisten, kunnen hiaten in de dekking gemakkelijker worden gelokaliseerd en opgevuld, en kunnen de kosten die aan bepaalde vereisten zijn verbonden, beter worden gevolgd.

Maar de halfgeleiderindustrie heeft een hekel aan verstoring van de ontwerpstroom. Het is vele malen geprobeerd en mislukt, vooral als het gaat om veranderende abstractieniveaus. Na verloop van tijd zal dit nog moeilijker worden omdat shift-left steeds meer onderlinge koppelingen tussen tools veroorzaakt, en dat betekent dat elke verandering een grotere impact heeft op het aantal tools dat het aanraakt. Individuele tools worden ontwikkeld in afzonderlijke groepen binnen elk EDA-bedrijf, en elk is verantwoordelijk voor het succes van zijn eigen tools, wat betekent dat een verandering van dit type volledige bedrijfsondersteuning zou vereisen. Daarvoor moet er eerst voldoende vraag zijn en dat wordt ook steeds onwaarschijnlijker.

Betekent dat dat we gedoemd zijn? Helemaal niet. Veel veranderingen in het verleden kwamen tot stand toen duidelijk werd dat de winst groot genoeg was om de negatieve impact van de verstoring te overwinnen. Zou AI daarin de eerste stap kunnen zijn? Als AI kan fungeren als een schakel tussen vereisten en de verificatiestroom, dan zouden we na verloop van tijd nieuwe talen of tools kunnen zien ontstaan ​​die het vermogen van de AI-tools zouden versterken, en dat op zich zou het nodige momentum kunnen stimuleren om het kapotte systeem langzaam te vervangen we hebben vandaag.

Misschien is de meer relevante vraag: zal dit gebeuren? Of zullen de onmiddellijke voordelen die AI-technologie biedt, voorzien in de onmiddellijke behoeften? Dat zou kunnen betekenen dat u niet verder hoeft te zoeken naar grotere winsten. Dit is in feite het incrementele verbeteringspad, en hoewel de uiteindelijke winst misschien een fractie is van wat ze hadden kunnen zijn, zijn die incrementele verbeteringen voldoende om de verstoring te onderdrukken.

Ik zou mijn geld op de laatste uitkomst zetten, maar ik zou graag ongelijk krijgen.