13.07.2015 Views

Magazine - 1000 BiT

Magazine - 1000 BiT

Magazine - 1000 BiT

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

Logicul Verijiccltion of the NVAX CPU Chip Designpreferretl sing SEGIJE to hand-coding Inanyfocusetl tests.Before simulations were performed, motleldemons were set up. Demons were enabled or disabled,and their operating modes were selectedpseudorantlomly. Demons tilap be features of thelnoclel environment that cause some exteni;llevents such ;IS interrupts, single-bit errors, or cacheinvalidates to occur at pseutlor;~ndom, varyingintervals. 1)emons may also be niotles of operationfor the systenl model that cause pseudorandomvariation in operations such as the chip bus prottrcol, memory latency, or the order in which data isretilrnetl. Some demons were implemented to forcechip-internal events. e.g., ;I primary cache parityerror or ;I pipeline stall. 'These chip-internillclernons li;~tl to be carefully irnplementecl, bec;iusesometimes tliey forced ;II internal state from whichtlie chip was not necessarily designetl to operate. 111a pseuclorantlomly generated test, it is frequentlytlifficult or i~iipossible to check for the correct handlingof an event caused by ;I demon, e.g.. checkthat an interrupt is serviced by the proper h;~ndlerwith correct priority However, simply triggeringthose events ant1 ensuring that the design tlitl notenter so~iie catastrophic state proved to be a 1,owerfillverification techniclue.Chip/system co~lfiguration options such ;IS c;~cheenables, the floating-point unit enable, ant1 thebackup cache size and speetl were also preselectedpseuclorandomly. Asisit from testing the chip in allpossible configurations, e.g., with a specific c;~cliedis;ibled, varying the configuration in a pseudorandommanner c;~usetl instruction sequences toexecute in ve1-y tlifferent ways and evoked many tlifferenttypes of OLI~S unrelatetl to the specific configuration.Also, specific configurations and demonsetlips would signific;lntly slow down tlie simulatedexecution of the test program, sometimes totlie point where intended testing was not beingaccomplished. To work arountl this probleni, theverification engineer coultl force the configurationant1 demon selection to avoitl problematic setilps.Simulation and VM Reference ExecutionAfter ;~ssernbling and linking the test program, itwas loadecl into modeled memory, and its executionwas sin~~~lated on either the behavioral or tlieCkMN(;O moclel. As the test program simi~l;~tiontook place, ;I simulation log file ancl a binary-formatfile, which cont;rinecl a trace of the state of the pinsant1 various internal signals, were created. As theexerciser test programs execucecl, various VAYarchitectural state information was written periodicallyto a region of modeled memory referrecl to asthe dump area. When the sirnul;~tetl execution ofthe test program completed, tlie contents of theclump are;l were storecl in a file. Also, the test programwas executed under the VMS operatingsystem running on a Vr\X cornpilter used as a referencemachine. At tlie end of execution, tlie contentsof tlie memory dump ;trea were stored inanother file.AnalysisA tool calletl SAVES allo\vs users to create C programsin ortler to analyze tlie contents of bin;lr).trace f les. SAVES was used to ~,rovitle cover;lge ;ln;llysisof tests, and to check for correct be1i;lvior ofchip-internal logic and give a pass/fail indication.For coverage analysis purposes, informationsuch as the number of times that a certain eventoccurred during simulation or the intervalbetween occurrences was ;~ccumulated acrossseveral simulations. This tlat;~ gave the verificzltionengineer ;I sense of the over;lll effectiveness ofan exerciser. For example, ;I verification engineerwho wanted to check an exerciser that wasintended to test tlie branch prediction logic w;~sable to use the SAVES tool to measure the number ofbranch mispreclictions.Frequently, verification engineers ilsecl the SAVEStool to perforn~ cross-protluct ;~nalysis and tlataacculiiulation. For cross-procluct analysis, the engineersl,ecifietl two sets of clesign events to he xnalyzed.The ;u~i;clysis determined the number of timesthat events from the first set occurred simultaneouslywith (or skewed by some number of cyclesfrom) events in the secontl set. For example, oneverification engineer analyzed tlie occurrence ofdifferent types of primary cache p;~rity errors relativeto different types of metnory accesses.,4nalyzi1ig the cross-protluct of state 11iachine st;ttesagainst one :inother, skewed by one cycle, alloweclstate m;icIiine transition cover;lge to be qilicklyunderstootl.The verification team used this SAVES informationabout the exerciser coverage in the following ways:To enhance productivity by helping the engineersidentify plannetl tests that 110 1o1ig~'rneetlecl to be developed ;lnd run bec;~use theexerciser ;rlreadjr coveretl the test case

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!