Intel Keynote om Formal a Mind-Stretcher

Intel Keynote om Formal a Mind-Stretcher

Kildeknude: 2528571

Synopsys har postet på SolvNet-siden en fascinerende tale holdt af Dr. Theo Drane fra Intel Graphics. Emnet er kontrol af datastiækvivalens. Det lyder måske som endnu en Formel DPV-godkendelse fra Synopsys VC, men du bør se den alligevel. Dette er en bevidsthedsudvidende diskussion om brugen af ​​og overvejelserne i det formelle, som vil bringe dig ud over den rutinemæssige brugervejlednings slags pitch til mere fascinerende territorium.

Intel Keynote om formel

Intellektuel forståelse versus prøvetestning

Testdrevet simulering i alle dens former er fremragende og ofte uerstattelig til at verificere rigtigheden af ​​en designspecifikation eller implementering. Det er også nemt at komme i gang. Bare skriv et testprogram og begynd at simulere. Men bagsiden af ​​den enkelthed er, at vi ikke behøver det fuldt ud forstå, hvad vi tester for at komme i gang. Vi overbeviser os selv om, at vi har læst specifikationerne omhyggeligt og forstår alle hjørnesager, men der skal ikke meget sammensat kompleksitet til for at overvælde vores forståelse.

Formel opfordrer dig til at forstå funktionaliteten på et dybt niveau (i hvert fald hvis du vil levere et værdifuldt resultat). I eksemplet ovenfor kan et simpelt spørgsmål – kan z nogensinde være alle 1'ere – ikke demonstrere et eksempel i en milliard cyklusser på en simulator. Ikke overraskende, da dette er en ekstrem hjørnesag. En formel test giver et specifikt og meget ikke-oplagt eksempel på 188 sekunder og kan bevise, at dette er det eneste tilfælde på lidt kortere tid.

OK formelt gjorde, hvad dynamisk test ikke kunne gøre, men endnu vigtigere lærte du noget, som simulatoren måske aldrig har fortalt dig. At der kun var ét muligt tilfælde, hvor den tilstand kunne ske. Formel hjalp dig med bedre at forstå designet på et intellektuelt niveau, ikke bare som en sandsynlighedsopsummering på tværs af et begrænset sæt af testcases.

Specifikationsproblemer

Theos næste eksempel er baseret på en bug-automat (såkaldt, fordi når du trykker på en knap, får du en fejl). Dette ligner et ret ligetil C til RTL-ækvivalenskontrolproblem, C-model til venstre, RTL-model til højre. En overraskelse for Theo i hans tidlige dage i formelle var, at højreskift-adfærd i C-modellen ikke er fuldstændigt defineret i C-standarden, selvom gcc vil opføre sig rimeligt. DPV vil dog klage over et mismatch i en sammenligning med RTL, som det skal. Udefineret adfærd er en farlig ting at stole på.

Formel som en fejlautomat

Specifikationssammenligning mellem C og RTL kommer med andre farer, især omkring bitbredder. Trunkering eller tab af en bærebit i et mellemsignal (#3 ovenfor) er gode eksempler. Er disse spec-problemer? Måske en gråzone mellem spec og implementeringsvalg.

Ud over ækvivalenskontrol

Det primære formål med DPV, ser det ud til, er at kontrollere ækvivalens mellem en C- eller RTL-reference og en RTL-implementering. Men det behov er relativt sjældent, og der er andre nyttige måder, sådan en teknologi kan anvendes på, hvis den er lidt ude af boksen. Først en klassiker i implementeringsverdenen – jeg lavede en ændring, rettede en fejl – introducerede jeg nogle nye fejl som et resultat? Lidt ligesom SEQ-tjek efter at du har tilføjet clock gating. Reachability-analyse i blokoutput kan være en anden nyttig applikation i nogle tilfælde.

Ikke kun ækvivalenskontrol

Theo bliver endnu mere kreativ og beder praktikanter om at bruge modeksempler for bedre at forstå designet, løse Sudokus or faktorisere heltal. Han erkender, at DPV er en mærkelig måde at nærme sig sådanne problemer på, men påpeger, at hans hensigt er at bryde illusionen om, at DPV kun er til ækvivalenskontrol. Interessant idé og bestemt hjernestrækkende at tænke sådanne udfordringer igennem. (Jeg indrømmer, at jeg straks begyndte at tænke på Sudoku-problemet, så snart han nævnte det.)

Wrap up

Theo afslutter med en diskussion om metoder, der er vigtige i produktionsbrug, omkring begrænsninger, regressioner og sammenligninger med ældre RTL-modeller. Også udfordringerne med at vide, om det, du tjekker, faktisk matcher specifikationen for det naturlige sprog på øverste niveau.

Meget energigivende snak, værd at se her på SolvNet!

Del dette opslag via:

Tidsstempel:

Mere fra Semiwiki