Gjør UVM raskere gjennom et nytt konfigurasjonssystem - Semiwiki

Publisert av Platon

Følgere: 0

Universal Verification Methodology (UVM) er en populær måte å hjelpe med å verifisere SystemVerilog-design, og den inkluderer en konfigurasjonssystem som dessverre har noen problemer med hastighet og bruk. Rich Edelman fra Siemens EDA skrev en detaljert 20-siders artikkel om hvordan du unngår disse problemene, og jeg har gått gjennom den for å oppsummere høydepunktene for deg. Verifikasjonsingeniører bruker en UVM-konfigurasjonsdatabase for å angi verdier, for så å hente verdiene senere i UVM-testen. Et eksempel på å angi og få en verdi 'T' er:

uvm_config#(T)::sett(omfang, forekomstbanenavn, feltnavn, verdi); uvm_config#(T)::get(omfang, forekomstbanenavn, feltnavn, verdi);

Kobling av UVM-testbenken til enheten som testes, bruker konfigurasjonsdatabasen for å sende de virtuelle grensesnittene. Det er tre problemer med å bruke UVM-konfigurasjonen:

Stor kode, rundt 2,600 linjer med kode
Krever nøyaktig type samsvar, så 'int' og 'bit' er ikke det samme
Treg kode

Tenk på tilfellet med treg kode, for med tusenvis av kall til set() kan det ta opptil 30 minutter å bruke navn med jokertegn å fullføre 'set'- og 'get'-fasen.

Forløpt tid min

Rich foreslår en ny løsning for UVM-konfigurasjoner som har mye høyere hastigheter, og tar bare noen få sekunder i sammenligning.

ny løsning min

Hvis UVM-koden din unngår å bruke jokertegn og har få "sett"-kommandoer, vil koden din kjøre raskere.

Mulige løsninger på UVM-konfigurasjonsproblemene er:

Bruk en global variabel i stedet
Bruk UVM-konfigurasjon med ett sett()
Bruk UVM-konfigurasjon med noen få sett()
Bruk et konfigurasjonstre
Prøv noe annerledes

Den siste tilnærmingen til å prøve noe annerledes er den nye løsningen, og den fortsetter å bruke set() og get() API, for så å forenkle ved å fjerne parameterisering av konfigurasjonene, fjerne prioritet og fjerne oppslagsalgoritmeendringen. Resultatene av denne nye tilnærmingen er høye hastigheter.

Ditt nye konfigurasjonselement er definert i den avledede klassen fra 'config_item', og eksemplet nedenfor viser 'int-verdi' som egenskapen som settes. For feilsøkingsformål legger du til funksjonen pen utskrift.

klasse my_special_config_item utvider config_item; funksjon ny(strengnavn = "my_special_config_item"); super.ny(navn); sluttfunksjon int verdi; virtuell funksjon streng convert2string(); return $sformatf("%s - verdi=%0d <%s>", get_name(), verdi, super.convert2string()); sluttfunksjon sluttklasse

'config_item' har et navneattributt, og dette navnet slås opp, pluss forekomstnavnet. Konfigurasjonsobjektet har også en get_name() funksjon for å returnere navnet. For å finne noen "forekomstnavn.feltnavn" bruker konfigurasjonsdatabasen en assosiativ matrise for raske oppslags- og opprettelseshastigheter.
For sporbarhet kan du finne ut hvem som har satt eller hvem som ringte get, fordi et filnavn og linjenummer er felt i funksjonskallene set() og get().

set(null, "top.ab*", "SPEED", my_speed_config, `__FILE__, `__LINE__) get(null, "top.abcdmonitor1", "SPEED", speedconfig, `__FILE__, `__LINE__)

Accessor-køen kan skrives ut under feilsøking for å se hvem som kalte set() og get().

For å støtte jokertegn kreves det å legge til en oppslagsmekanisme ved hjelp av containere. Tenk på forekomstnavnet 'top.abcd*_0'.

Jokertegndelen av forekomstnavnet håndteres ved å bruke beholdertreet, i stedet for den assosiative matrisen.

Oppsummering

Deling av data mellom modulen/instansen og den klassebaserte verden i en UVM-testbenk kan gjøres ved å bruke UVM-konfigurasjonsdatabasen, bare vær oppmerksom på hastighetsreduksjonene. Hvis metodikken din bruker mange konfigurasjoner, bør du vurdere å bruke den nye tilnærmingen som er introdusert som har en pakke som bruker omtrent 300 kodelinjer i stedet for de 2,600 kodelinjene i UVM-konfigurasjonsdatabasefilen.

Les hele avisen på 20 sider, Unngå konfigurasjonsgalskap på den enkle måten hos Siemens EDA.