Kas teate kindlasti, et teie RISC-V RTL ei sisalda üllatusi?

Arvestades RISC-V RTL-i disainide suhtelist uudsust ja keerukust, olenemata sellest, kas ostate kaubanduslikult toetatud tuuma või laadite alla populaarse avatud lähtekoodiga pakkumise, on väike, kuid nullist erinev risk, et soovimatud üllatused pääsevad märkamatult teie lõpptootesse. Suure tõenäosuse järjekorras kaaluge järgmist:

• Kummalise, kuid siiski täiesti võimaliku nurgakorpuse vea olemasolu
• Vead kohandatud juhiste sees, mille teie või teie müüja teie rakenduse jaoks loote
• Vead kohandatud käsu "servades" – nt käsk täidetakse õigesti, kuid jätab masina kuidagi rikutud olekusse
• Seotud: dokumenteerimata ja/või halvasti määratletud uued funktsioonid, mis avavad kujunduses tahtmatult auke
• Tarneahela rünnaku kaudu salaja sisestatud pahatahtlik trooja loogika

Levinud leevendusmeetodid

Loomulikult on esimene kaitseliin sissetuleva või areneva RTL-koodi ekspertkontroll. Ilmselgelt tuleks seda teha; kuid sama ilmselge peaks olema, et see tehnika – nagu matemaatikas öeldakse – “on vajalik, kuid mitte piisav” (isegi kui lasite professor Pattersonil endal oma koodi üle vaadata).

Järgmine kaitseliin on simulatsioonipõhiste lähenemisviiside rakendamine: juhiste komplekti simulatsioon (ISS), teie DUT-i automaatne võrdlemine küpsete kuldsete mudelitega, piiratud juhuslikud UVM-testipingid DUT-i RTL-i simulatsiooniks ja isegi reaalse maailma stiimuli ühendamine riistvaratoega emulatsiooniks. DUT-st. Jällegi, need lähenemisviisid on kõik väärtuslikud ja neid tuleks teha; kuid neil kõigil on sama viga: nad on oma olemuselt ebatäielikud, kuna toetuvad stiimuli genereerimisele. Näiteks äärmuslikul, kuid võimalikul tarneahela rünnaku korral on Trooja loogika arendaja teadlikult loonud signaalide ja andmete käivitava jada, mis tõenäoliselt pääseb isegi kõige loomingulisema valge mütsi häkkeri tuvastamisest. Ja loomulikult on funktsionaalsetel vigadel oma viis kasutada looduslikult esinevat entroopiat, et jääda varjatuks.

Põhimõte on see, et ainus viis olla täiesti kindel, et teie RISC-V RTL pole loomulikest või pahatahtlikest üllatustest vaba, on kasutada kujunduse kontrollimiseks põhjalikke ja ametlikke meetodeid.

Lihtsam öelda kui teha, eks?

Jah ja ei: 14 aastat tagasi said seda tüüpi analüüsi teha ainult doktorikraadiga teadlased, kasutades oma käsitsi valmistatud programme. Kuid alates 2008. aastast on tööriistad ja tehnikad toodetud nii, et igaüks, kes tunneb ametliku kontrollimise põhitõdesid ja IEEE standardi System Verilog Assertions (SVA) kirjutamist, saab siin kiiresti rakendada ja edu saavutada.

Kolmeastmeline formaalne protsess

Soovitatav formaalne voog on järgmine:

1. Looge ametlik testbench, mis "modelleerib" DUT-spetsifikatsiooni
2. Määratlege sisendpiirangud ja kontrollid, mida DUT-i suhtes käivitada
3. Teostage analüüs

1. samm – looge ametlik testbench, mis "modelleerib" DUT spetsifikatsiooni

Selle metoodika aluseks on atribuutide komplekti kirjutamine, mis esindavad iga juhise käitumist teie RISC-V disainis. Ülesanne on tabada antud käsu mõju IP väljunditele ja sisemistele arhitektuursetele olekutele (RISC-V maailmas on see programmiloendur (PC) ja registrifail (RF)) mis tahes antud meelevaldselt pika sisendjada puhul. Selleks kasutatakse IEEE SVA spetsiaalselt loodud laiendust nimega Operational SVA. Lühidalt öeldes on see teek, mis on tarnitud formaalse protsessori kontrollimise tööriistaga; ja kontrollija vaatevinklist näeb see välja nagu tuttava SVA-koodi intuitiivne alamhulk. Joonis 1 näitab üldist struktuuri:

omaduse käsk_A; // kontseptuaalne olek t ##0 ready_to_issue() ja // päästik t ##0 opcode==instr_A_opc viitab // kontseptuaalne olek t ##0 ready_to_issue() ja // mäluliideste väljundid // järgmise käsu lugemine t ##0 imem_access(instr_A_opc) ja // andmete laadimine/salve t ##1 dmem_access(instr_A_opc) ja // arhitektuuriregistrid t ##1 RF_update(instr_A_opc) ja t ##1 PC_update(instr_A_opc) endproper 

Joonis 1: Protsessori käsu spetsifikatsiooni hõivava operatiivse SVA-koodi struktuur. [1]

Viidates joonisele 1, vasakpoolne külg kaasamine (koodi osa üle märksõna eeldab) näitab, millal masin on uue juhise andmiseks valmis, ja väljastava juhise. Väide hõlmab arhitektuuriliste olekute praeguseid väärtusi ja implikatsiooni paremas servas (koodi osa alla märksõna eeldab), tõestab nende järgmisi väärtusi.

Lisaks tuleb tõestada, et protsessori väljundid on õiged – sel juhul veendumaks, et käsk pääseb juurde eeldatavatele andmetele ja käsumälu asukohtadele. Väide tõestab ka, et masin on järgmisel tsüklil valmis väljastama uue juhise. See on ülioluline selleks, et lahutada käsu kontrollimine käskude jadast, mille osaks see võiks olla. Näiteks käsku A võib õigesti täita, kuid masin jääb rikutud olekusse. See ekslik olek võib põhjustada järgmise käsu B andmise valesid tulemusi ilma enda süül. Seega operatiivse SVA lähenemisviisi korral mööduks väidet kontrolliv käsk B, samas kui väidet kontrolliv käsk A ebaõnnestuks (kus mälu lugemis- ja kirjutamistoimingud võivad kesta mitu tsüklit).

Alumine rida: Operational SVA koodis arhitektuurseid olekuid esindavad funktsioonid peavad olema vastendatud rakendussignaalidega ja need peavad peegeldama protsessori mikroarhitektuuri. Näiteks võib raadiosageduse olek sõltuda edastusteede aktiveerimisest. [1]

[Märkus. Neile, kes tunnevad kas simulatsiooni või formaalset funktsionaalset katvust, ei tugine see täielikkuse mõiste struktuursetele katvuse mõõdikutele ega funktsionaalse katvuse mudeli mõõdikute loomisele ja kogumisele. Selle asemel (ja ülejäänud sammudest ja tulemustest veidi ette jõudes) on siin analüüsiväljundis kõigi omaduste jaoks täielikud tõendid. Täielikud tõendid näitavad ka kaudselt, et pole ühtegi muud funktsiooni – mis oleks määratlemata või ootamatu (spetsifikatsiooni- või kodeerimisviga) või pahatahtlikult sisestatud –, mida see atribuutide komplekt ei haaraks. Ümbersõnastades, selle metoodika eesmärk on saavutada 100% "testiplaani katvus", mida kinnitavad ammendavad formaalsed analüüsitulemused – kus miski pole "täielikum" kui matemaatiline tõestus!]

2. samm – määrake sisendpiirangud ja kontrollid, mida DUT-i suhtes käivitada

Iga käsu spetsifikatsiooni atribuutide täiendamiseks on järgmine samm sisendipiirangute ja täiendavate väljundkontrollide määratlemine. Jällegi kasutatakse operatiivset SVA-d, kus kasutaja määrab nüüd "täielikkuse plaani", et määratleda nii legaalsed sisendid kui ka ebaseaduslikud signaalid, mida DUT peaks ignoreerima. Joonisel 2 näidatud näites on kolm osa: määramise eeldused, määramisnõuded ja omaduste graafik.

täielikkuse protsessor; determination_sumptions: // SISENDID määratud(imem_andmed_i); määratud(dmem_kehtiv_i); if (dmem_valid_i) määratud(dmem_andmed_i) endif; determination_requirements: // VÄLJUNDID määratud(imem_read_o), if (imem_read_o) määratud(imem_addr_o) endif; määratud(dmem_enable_o); if (dmem_enable_o) määratud(dmem_rd_wr_o), määratud(dmem_addr_o) endif; // ARHITEKTUURID määratud (PC); määratud (RF); omadus_graaf: kõik_juhised := käsk_mitte_a, käsk_lisa_a, käsk_ala_a, [...] kõik_juhised -> kõik_juhised; lõpu täielikkus; 

Joonis 2: Näide täielikkuse plaanist koos tingimusliku määramise eelduste ja nõuetega.

Täpsemalt:

• „Determination_ssumptions” on lihtsalt sisendväärtuse piirangute väljamõeldud nimi
• "Determination_requirements" on kontrollitavate signaalide määratlus (nii protsessori väljundsignaalid kui ka arhitektuursed olekud)
• Jaotis "property_graph" on lihtsalt selle faili sidumine kõigi 1. sammus loodud atribuutidega

Kokkuvõtteks, kus me praegu oleme: 1. etapis lõite DUT-i tsüklilise täpsusega mudeli, mis tuleb tõestada kogu aja ja kõigi sisendite jaoks; 2. sammus määrate piirangud ja kõik erilised käitumisviisid, millele tähelepanu pöörata. Kui liitke need kokku, saate ametliku testimise, mis on töövalmis!

3. samm – viige läbi analüüs

Kõigi formaalsete tööriistade eesmärk on ammendavalt tõestada, et kõik omadused kehtivad kogu aja ja kõigi sisendite kohta. RISC-V protsessori kontrollimise korral tõestab tööriist, et suvaliselt pikka sisendjada saab sobitada määratud operatiivse SVA kordumatu jadaga, mis ennustab väljundite ja arhitektuursete olekute väärtusi.

Ja täpselt nii juhtubki. Kui spetsifikatsiooni ja DUT-i käitumises tuvastatakse erinevusi, esitab ametlik tööriist „vastunäite” lainekuju, mis näitab täpselt sisendsignaalide ja andmete seeriat, mis võivad spetsifikatsiooni rikkuda. Nagu eespool mainitud, võib selliseid tõrkeid leida juhendi RTL-i loogikast või "handoff-loogikast", mis ühendab järgmise juriidilise haru/juhise.

Mõlemal juhul, kui need probleemid on lahendatud ja tööriist tõestab kõiki omadusi, on tulemused tõeliselt "täielikud" - st võite olla matemaatiliselt kindel, et RTL-i kodeerimisvigu pole - formaalne analüüs on sõna otseses mõttes tõestanud vigade puudumist. !

Tulemused

Esiteks, nagu eespool märgitud, on aastate jooksul paljud protsessorite arendajad sellest voost kasu saanud [2], [3], [4].

Seda metoodikat RISC-V-ga proovile pannes tegid mu kolleegid juhtumiuuringu, kasutades populaarset Rocket Chipi avatud lähtekoodiga tuuma. Täpsemalt uuriti RV64IMAFDC – sv39 vm konfiguratsiooni. See on 64-bitine protsessorituum, millel on 39-bitine virtuaalmälusüsteem [5] ja laiendused, nagu tihendatud ja aatomikäsud [6]. See avatud lähtekoodiga RISC-V ISA juurutus kasutab viieastmelist, ühe väljaandega, järjestikust konveierit, mille lõpuleviimine on korrast ära pika latentsusajaga juhiste jaoks, näiteks jagamise või vahemälu vahelejäämise korral. Tuum toetab ka "misa" registri harude ennustamist ja käitusaja muutmist, võimaldades sellel teatud käsukomplekti laiendusi välja lülitada.

Kuigi seda Rocket Chipi hetktõmmist oli põhjalikult kontrollitud ja mitu korda lindistatud, tuvastati neli varem tundmatut, nurgapealset kahtlast käitumist, millest teatati Rocket Core RTL-i arendajatele. Need probleemid ([7], [8], [9] ja [10]) avastati ainult selles artiklis kirjeldatud täieliku ametliku kontrollimise süstemaatilise rakendamise kaudu.

Täpsemalt [10] käsitledes – mittestandardse käsu CEASE (Opcode 0x30500073) avastamine RTL-is: Rocket Chipi meeskond jäi selgelt oma dokumentatsioonist maha (ja nad parandasid selle peaaegu kohe pärast GitHubi tõmbamistaotluse esitamist). Suurem asi on see, et see näitab, et terve käsu rakendamiseks vajalik loogika – kümned koodiridad ja paljud sünteesitud, paigutatud ja suunatud loogika väravad – pääseb visuaalse kontrolli, RTL-i simulatsiooni, värava taseme simulatsiooni ja kogu tuvastamise eest. taustarakendusprotsess ja riistvara prototüübid laboris!

Aga kuidas on lood selle voo toimimisega?

Kõigepealt käsitleme „jõudluse” laiemat tähendust. Rocket Chipi disaini uudse olemuse tõttu kulus selle juhtumiuuringu jaoks ligikaudu 20 insenerinädalat, enne kui meie ametlikud kontrollijad töötasid välja kogu katsestendi ja piirangud. Selle voo varasemad rakendused struktureerituma kaubandusliku IP puhul on aga tavaliselt võtnud sellest ajast murdosa. Loomulikult läheb kogu avamisprotsess palju kiiremini, mida stabiilsemad ja küpsemad on tehnilised andmed, kui hästi dokumenteeritud ja loetav on DUT RTL-kood ning kui palju on teil küsimuste ja vastuste jaoks projekteerimisinseneridele juurdepääs.

Kui keskkond oli seadistatud, oli seinakella tööaeg kõik 2 tundi – st palju vähem, kui võis mõistlikult eeldada piiratud juhusliku RTL-i simulatsiooni ja isegi riistvara abil kontrollimise korral. Lisaks pidage meeles, et selle analüüsi tulemused kehtivad kõigi sisendite ja kogu aeg – ühesõnaga, need on ammendavad [11].

kokkuvõte

Selles artiklis esitatud täielik, formaalne protsessori kontrollimise lähenemisviis kasutab IEEE SVA laiendust Operational SVA, et ametlikult kontrollida, kas RISC-V ISA-s pole lünki ja ebakõlasid. Erinevalt piiratud juhusliku simulatsiooni testimistest, emulatsioonist või füüsilisest prototüüpimisest tuvastab atribuutide ja piirangute komplekt ammendavalt mitut tüüpi RTL-i vigu, samuti dokumenteerimata või halvasti määratletud koodi ja pahatahtlike troojalaste olemasolu.

viited

1. – 2019. aasta GOMACTechi konverents, Albuquerque, NM, 28. märts 2019: Trooja vabade usaldusväärsete IC-de RISC-V protsessori IP-de täielik ametlik kinnitamine, David Landoll jt.

2 – DVCon 2007: TriCore2 ja teiste protsessorite täielik ametlik kontroll, Infineon Gmbh.

3 - 51^st Disaini automatiseerimise konverents (DAC): Renesase MCU disainiplatvormi ametlik kinnitamine OneSpini tööriistu kasutades

4 – DVCon Europe 2019: autotööstuse DSP-de perekonna täielik ametlik kinnitamine, Bosch Gmbh.

5 – RISC-V kasutusjuhend, II köide: privilegeeritud arhitektuur, dokumendi versioon 1.10.

6 - https://github.com/freechipsproject/rocket-chip [kasutatud 20. detsembril 2018]

7 – DIV juhise tulemust ei kirjutatud registrifaili
https://github.com/freechipsproject/rocket-chip/issues/1752

8 – JAL-i ja JALR-i juhised salvestage erinevad tagastusarvutid
https://github.com/freechipsproject/rocket-chip/issues/1757

9 – Ebaseaduslikud opkoodid on taasesitatud ja põhjustavad ootamatuid kõrvalmõjusid
https://github.com/freechipsproject/rocket-chip/issues/1861

10 – mittestandardne juhend CEASE (Opcode 0x30500073), mis avastati RTL-is, https://github.com/freechipsproject/rocket-chip/issues/1868

11 – ajaveeb Verification Horizons, Kuidas saab öelda, et ametlik kinnitamine on ammendav?, Joe Hupcey III
https://blogs.sw.siemens.com/verificationhorizons/2021/09/16/how-can-you-say-that-formal-verification-is-exhaustive/

Allikas: https://semiengineering.com/do-you-know-for-sure-your-risc-v-rtl-doesnt-contain-any-surprises/