Memory Modeling in ESL-RTL Equivalence Checking

Transcription

1 11.4 Memory Modelng n ESL-RTL Equvalence Checkng Alfred Koelbl 2025 NW Cornelus Pass Rd. Hllsboro, OR koelbl@synopsys.com Jerry R. Burch 2025 NW Cornelus Pass Rd. Hllsboro, OR burch@synopsys.com Carl Pxley 2025 NW Cornelus Pass Rd. Hllsboro, OR cpxley@synopsys.com ABSTRACT When desgners create RTL models from a system-level specfcaton, arrays n the system-level model are often mplemented as memores n the RTL. Knowng the correspondence between ESL arrays and RTL memores can sgnfcantly reduce the complexty of a formal equvalence check between the ESL model and the RTL. In practce, however, handlng memory mappngs n ESL- RTL equvalence checkng s non-trval for the followng reasons: Frst, because of a lack of bt-accurate data-types n the systemlevel language, the nformaton stored n an array locaton may be stored n a compressed form n the RTL. Second, a sngle array n the ESL model may be mplemented by multple memores n the RTL and/or correspondng data tems may be stored n dfferent locatons. And last but not least, due to tmng dfferences between the ESL model and the RTL, the correspondence between arrays and memores may not hold n every clock cycle. In ths paper, we propose an approach to ESL-RTL equvalence checkng whch can deal wth all of these dffcultes. Categores and Subject Descrptors J.6 [Computer-Aded Engneerng]: Computer-Aded Desgn General Terms Algorthms, Verfcaton Keywords ESL, Equvalence checkng, Verfcaton, Memory 1. INTRODUCTION Wth the rsng complexty of modern embedded systems, a growng trend toward desgnng hardware at hgher levels of abstracton has emerged. Many companes have adopted a methodology that starts out wth a desgn specfcaton n a system-level programmng language lke C++. In ths phase, the focus s purely on algorthm desgn and desgn exploraton. A hgher abstracton level enables faster desgn changes and more thorough valdaton due Permsson to make dgtal or hard copes of all or part of ths work for personal or classroom use s granted wthout fee provded that copes are Permsson not made ortodstrbuted make dgtal for proft or hard or commercal copes of alladvantage or part ofand thsthat work copes for personal bear ths notce or classroom and theuse fulls ctaton granted onwthout the frstfee page. provded To copythat otherwse, copes are or not republsh, made or todstrbuted post on servers for proft or to redstrbute or commercal to lsts, advantage requres and pror thatspecfc copes bear permsson ths notce and/or anda the fee. full ctaton on the frst page. To copy otherwse, to republsh, DAC 2007, tojune post4 8, on servers 2007, San or todego, redstrbute Calforna, to lsts, USA. requres pror specfc permsson Copyrght 2007 and/or ACM a fee /07/ $5.00. DAC 2007, June 4 8, 2007, San Dego, Calforna, USA. Copyrght 2007 ACM ACM /07/ $5.00. to a hgher smulaton speed. By addng more and more mplementaton detals, the system-level specfcaton s then refned to a Regster-Transfer-Level (RTL) descrpton. Today, the prevalent technque for checkng f the resultng RTL comples wth the system-level specfcaton s smulaton. As exhaustve smulaton s not feasble for ndustral-szed desgns, subtle bugs n the desgn frequently reman undetected. Ths problem gves rse to the use of formal technques. Formal equvalence checkng can detect dscrepances whch are not detected n week long smulaton runs. Whereas formal equvalence checkng for RTL to RTL comparsons has been n producton use for many years now, ESL to RTL checkng s stll n ts nfancy. Unfortunately, formally provng the equvalence of an RTL aganst a system-level model s much harder than comparng two RTLs for equvalence, manly due to the ncredble amount of freedom desgners have n refnng the systemlevel model to the RTL. In ths paper, we focus on a specfc problem related to formal equvalence checkng of system-level models aganst RTL, namely the handlng of memores. Black-boxng memores as t s done n RTL-RTL equvalence checkng only works f the memory read and wrte patterns n both desgns match exactly. In general, ths s not the case n ESL equvalence checkng and a more sophstcated memory model that can reason about memory reads and wrtes s requred. However, smlar to regster mappng n RTL-RTL verfcaton, the equvalence check can be smplfed sgnfcantly f the mappng between ESL arrays and RTL memores s consdered. Unfortunately, even though most arrays n ESL models are mplemented by memores n the RTL, the number of dfferent possble mplementatons s huge. For effcency reasons, the memory layout may dffer, shadow regsters may be used to cache data or a sngle array may be splt nto multple memores n the RTL. In addton to that, tmng dfferences between the system-level model and the RTL usually make t necessary to detect at whch ponts n tme the arrays/memores match. Secton 3 dscusses all the features that a memory model should provde n order to be sutable for systemlevel equvalence checkng. We rely on the user to provde the nformaton about memory mappngs. If the mappng between the memores s known, the basc dea for provng the equvalence of both desgns s the followng: We assume that both desgns start wth matchng memores/arrays before the computaton. Then, both desgns perform a sngle transacton and we check f the results match. Fnally, we prove that the memores match agan after the transacton, whch makes t necessary to reason about the equalty of memores. The detaled proof procedure s descrbed n Secton

2 2. RELATED WORK Theores for reasonng about arrays/memores have been a research subject for a long tme [6], [7]. In 2001, Stump et al. [8] presented a paper on an extensonal theory of arrays. Extensonal theores formalze the ntuton that f two arrays store the same value at each array locaton, they are equvalent. Bradley et al. [1] further extend the theory of arrays by allowng quantfers. They show that ther fragment results n a complete satsfablty proof. Our approach for unversal quantfer elmnaton s based on ther work. The applcaton of ths memory model n formal equvalence checkng has been dscussed n many papers, related to ppelne verfcaton [3] and symbolc smulaton [9]. Bryant and Velev [2] made use of an effcent memory model n showng that two ppelned mcroprocessors, when started wth matchng memores produce the same results. Some recent papers descrbe clever encodngs of read/wrte formulas nto CNF [4], [5]. For example, Manolos et al. [5] presented an encodng that tres to mnmze the number of bts/clauses requred for modelng memores. Even though we don t deal wth ths problem, ther deas can potentally be appled to our approach, too. 3. REQUIREMENTS FOR MEMORIES In the rest of the paper, we don t dstngush between arrays and memores and refer to both of them as memores. The relatonshp between ESL and RTL memores s descrbed by a memory mappng: Defnton: Memory mappng A memory mappng MM s a unversally quantfed expresson over all memory locatons. It relates the contents of one memory to the contents of another memory (or several other memores). The memory mappng s expressed n terms of reads of both memores. Example: A one-to-one memory mappng between two memores M A and M B, both havng 10 elements, s descrbed by the followng expresson: MM(M A, M B):= read(m A, ) = read(m B, ) 0 <10 In Sectons 3.1 and 3.2 we descrbe memory mappngs for the followng cases: If the layout of both memores dffer. If a memory n one desgn s splt nto multple memores n the other desgn. If the same data s stored n dfferent addresses n both memores. Secton 3.3 deals wth non-mappng related constrants on memores. 3.1 Memory layout dfferences Dfferng memory layouts frequently occur when comparng a desgn specfed n a system-level language (e.g. C++) wth a desgn specfed at the regster-transfer level. Due to the lack of btaccurate data-types n the system-level language, a memory element may be represented wth more bts than actually needed. Consder for example the two memores M A and M B n Fg. 1. M A s a memory n a C++ desgn and M B s a memory n an RTL desgn. The layout of M A s determned by the C++ struct elem. Due to the lmted number of avalable data-types n C++, t may be necessary to represent a feld n the struct wth more bts than actually necessary. In ths partcular case, even though only three bts are used per element, they are stored n two character varables, resultng n a total of 16 bt storage. In the RTL memory on the other hand, the correspondng data s stored n a compressed format. The actual mappng between the bts n the C++ memory and the RTL memory s ndcated n Fg. 1. ESL desgn struct elem { char a; char b; }; elem MA[4]; Memory M A Memory M B RTL desgn reg [3:0] MB[2:0] Fgure 1: Mappng wth layout dfferences The mappng can be expressed as MM(M A, M B):= read(m A, )[7:0] = {6 d0, read(m B, )[2:1]} 0 <4 read(m A, )[15:8] = {7 d0, read(m B, )[0]} Havng the user specfy such a formula for more complex mappngs s very nconvenent. To deal wth ths ssue, we ntroduce "templates". For memory mappngs where the layout wthn each memory locaton s dfferent, the user can specfy a template whch descrbes the mappng wthn a sngle memory locaton. For the example n Fg. 1, the user would create the followng template t : template t { a = [2:1]; b = [0]; } Wth ths template, the mappng expresson smplfes to: MM(M A, M B):= read(m A, ) = template t (read(m B, )) 0 <4 3.2 Multple memores and address mappngs Memory mappngs can also be used to relate multple memores to each other. Also, correspondng data tems don t need to be stored at the same address n the memores. Consder for example the mappng n Fg. 2. The frst four memory locatons n memores M E, M F and M G are all mapped one-to-one. Locaton 5 n M E s mapped to locaton 4 n M F and locaton 6 n M E s mapped to locaton 4 n M G. A case lke ths sometmes occurs f a sngle memory n the system-level model (here M E) s splt nto multple memores n the RTL (here 206

3 Memory M E Memory M F Memory M G Fgure 2: Mappng between multple memores M F and M G) n order to ncrease memory access performance. The memory mappngs of ths example are descrbed by: MM(M F, M E):= read(m F, ) =(<4)? read(m E, ) : read(m E,5) 0 <5 MM(M G, M E):= read(m G, ) =(<4)? read(m E, ) : read(m E,6) 0 <5 3.3 Constrants on memores In addton to mappngs between memores t can be necessary to allow the user to defne constrants on the memory contents, for example f t s known that a memory can only hold certan datavalues. Furthermore, a constrant can also become part of a proof oblgaton, for example, f the correctness of the equvalence check requres that the memory content ends up wth a certan set of datavalues after the computaton. In our approach, the user can ether specfy constrants on ndvdual memory locatons or n a unversally quantfed form over all memory locatons. A constrant may also be expressed over multple memores. Examples: c 0 = (read(m A,3)=2) c 1 = (read(m A, ) < 3) c 2 = (read(m A, ) + read(m B, ) > read(m C, )) 4. PROOF PROCEDURE A common noton of equvalence between two desgns wth memores s transacton equvalence: Assumng that the desgns start out n a vald state, both desgns execute a sngle transacton. If both of them produce equvalent outputs on the way and end up n a vald state, the desgns are consdered equvalent. The proof method we use for provng transacton equvalence s nducton. In the nducton step, a vald startng state s assumed, the two desgns are unrolled for an entre transacton and the outputs at the end of the transacton are compared. Furthermore, the state n whch both desgns end up s compared aganst the startng state. The nducton base s requred f the startng state does not nclude the ntal state. In ths case, we addtonally need to prove equvalence of the desgns untl the state becomes a subset of the startng state. In descrbng the subsequent steps we assume that the ntal state s ncluded n the startng state and no nducton base s requred. The procedure s depcted n Fg. 3. In ths example, a transacton on the ESL model requres two cycles whereas the same transacton requres three cycles on the RTL. The two desgns are unrolled for two (ESL 0, ESL 1) and three tme-frames (RT L 0, RT L 1, RT L 2), respectvely. Both desgns start n a vald state (S A, M A) and (S B, M B)whereS A, S B denote the regster state and M A, M B denote the memory state of the correspondng desgn. Both desgns are fed wth equvalent nput data. However, due to tmng dfferences between both models, the nputs don t necessarly match one-to-one. For example, the ESL model mght receve the entre data at the same tme, whereas the RTL model mght receve t n seralzed form. In Fg. 3 ths s ndcated by nput assgnments I whch are not connected together. By unrollng both desgns, we can construct a formula for the outputs O A, O B, as well as for the state (S A, M A)and(S B, M B) after the transacton. The desgns are consdered to be equvalent f O A = O B and the combned states are vald states. I A0 S A M A I B0 S B M B ESL 0 I A1 I B1 Transacton T A ESL 1 I B2 RT L 0 RT L 1 RT L 2 Transacton T B Fgure 3: Proof procedure O A S A M A O B S B M B In order for the nducton proof to succeed, addtonal nductve nvarants may be requred. For example, even f we assume that the memores start out n the most general state, a successful equvalence check generally requres that ther contents match n both desgns. Memory mappngs and constrants as dscussed n Secton 3 provde such nvarants. From the nformaton the user supples,.e., constrants, templates and mappngs, we construct a system of assumpton formulas: Assumptons relatng the memores n both desgns. These assumptons nvolve all the user specfed memory mappngs: a 0 =MM 0(M A, M B) MM 1(M A, M B)... Constrants on the memores: a 1 = c 0(M A, M B) c 1(M A, M B)... Regster mappngs between the two desgns: a 2 = r 0(S A, S B) r 1(S A, S B)... Addtonal state nvarants gven by the user nvolvng memores and regsters: a 3 = 0(M A, M B, S A, S B)... Gven these assumptons, the followng proof oblgatons are requred for an equvalence check: Prove that the memory mappngs hold after the transacton: a 0 a 1 a 2 a 3 MM 0(M A, M B)... Prove that the constrants stll hold after the transacton: a 0 a 1 a 2 a 3 c 0(M A, M B) c 1(M A, M B)... Prove that the regster mappngs hold after the transacton: a 0 a 1 a 2 a 3 r 0(S A, S B) r 1(S A, S B)

4 Prove that the addtonal nvarants hold after the transacton: a 0 a 1 a 2 a 3 0(M A, M B, S A, S B)... Prove that no memory accesses are out-of-bounds. The behavor of an out-of-bounds array access s undefned n most system-level languages lke C++. Thus, for a correct equvalence check, we must make sure that ths never happens. Some of these formulas stll have unversal quantfers n them whch must be removed before they are handed over to a SAT solver. In addton to that, bt-blastng the memores s mpractcal for most desgns. Thus, we use a memory model whose sze only depends on the number of accesses, not on the actual sze of the memores. The algorthm for removng the quantfers and convertng the memores s outlned here: 1. Propagate reads over wrtes. Ths s done by applyng the followng rewrte rule on the formulas: read(wrte(m,, d), j) te( = j, d, read(m, j)) where s the address of the wrte, d s the wrtten data and j s the address of the read. Applyng ths rule successvely removes all wrtes to memores n the formulas. 2. Replace unversal quantfer varables on the rght-hand sde of a proof oblgaton by free varables and drop the quantfer. Because quantfers can only occur n the top-level conjuncton of the rght-hand sde, a (read(m A, ) = read(m B, ) s equvalent to a (read(m A, ) = read(m B, )) when gven to a valdty checker ( s a fresh free varable). The valdty proof only returns true f the formula s satsfed for all assgnments to. If bounds were gven for the quantfer varable, those bounds become part of the assumptons. 3. Expand assumpton quantfers. Removng unversal quantfers on the left-hand sde of a proof oblgaton,.e., an assumpton, can be done by expandng the quantfed expresson over all possble values of the quantfer varable: (read(m A, ) = read(m B, )) p s equvalent to read(m A, 0) = read(m B,0) read(m A, 1) = read(m B,1). read(m A, n) = read(m B,n) p In practce, t s usually not necessary to expand over all possble values of the quantfer varable. If a specfc value s never used n any other read, t can safely be dropped wthout compromsng completeness. In our approach, we use a smlar heurstc for computng suffcent quantfer varable values as n [1]. We collect all address expressons that are used n reads on memores, ncludng the fresh varables ntroduced n removng the rght-hand sde quantfers. The assumpton quantfers are then expanded for all those address expressons. Consder for example the followng formula: (read(m A, ) = read(m B, )) (read(m A, j) < 2) j read(m A, 4) + read(m B, a) < 3 Both quantfers are expanded wth the read addresses a and 4 : read(m A, a) = read(m B, a) read(m A, 4) = read(m B,4) read(m A, a) < 2 read(m A,4)< 2 read(m A, 4) + read(m B, a) < 3 4. Perform completeness check. Because we allow general expressons n mappngs, the heurstc used n expandng assumpton quantfers may not be complete (but not unsound!). Consder for example the followng mappng: (read(m A, +1) = read(m B, +1) read(m B,1)=1 read(m A,1)=1 Wth the gven heurstc, the formula s expanded nto (read(m A, 2) = read(m B,2)) read(m B,1)=1 read(m A,1)=1, whch obvously wll produce a false counter-example. The heurstc used n expandng assumpton quantfers s only complete for certan cases. For example, f the address of all reads n quantfed expressons s the quantfer varable tself (all reads have the form read(m, )), the heurstc s complete. In our approach, we detect cases for whch we know that the result s complete. For all other cases, we flag a warnng to the user. The completeness check s based on the work n [1]. 5. Replace reads by free varables. At ths pont, the formulas are free of quantfers. The only memory operatons stll left are reads on memores. In ths last step, we replace reads by free varables. Multplexers are ntroduced whch mantan the equvalence relatonshps between reads. For example, f there are three reads read(m, a), read(m, b), read(m, c) n the formulas, they are rewrtten nto: read(m, a) v 1 read(m, b) te(b = a, v 1, v 2) read(m, c) te(c = a, v 1, te(c = b, v 2, v 3) 6. Prove formulas usng a valdty checker. In our approach, we convert the problem nto a satsfablty problem and solve t usng a SAT solver. 5. TIMING DIFFERENCES In the proof procedure n Secton 4, we assumed that the memory mappngs hold before the transacton s started. Ths s not always the case. For example, when comparng a non-ppelned ESL desgn aganst a ppelned RTL desgns, the memores at the begnnng of a transacton may not match up because the RTL may stll have a prevous transacton n-flght whch has not yet commtted ts result to memory. However, both desgns can stll be equvalent f the memores match up rght before the current RTL transacton wrtes to memory. In essence, ths means that there exsts a memory mappng between the ESL model and the RTL at dfferent tme steps. In the example n Fg. 4, the ESL model computes an entre transacton n a sngle cycle whereas the RTL s a ppelned desgn wth three stages. The wrte to memory happens n stage three. If both desgns start out wth matchng memores at tme zero, the ESL desgn already wrtes ts frst result at the end 208

5 M A M B t=0 Intal state t=1 t=2 t=3 w T 1 w T 2 w T 3 w T 4 w T 5 w T 6 w T 1 t=4 t=5 w T 2 w T 3 w T 4 Fgure 4: Mappng wth tmng dfferences ESL RTL of the frst cycle (w T 1) whereas the RTL has only fnshed the frst stage. Thus, memory M B at tme-step 1 s stll equvalent to M A at tme-step 0 (depcted by the dashed lne n Fg. 4. In the second cycle, the ESL wrtes yet another result to memory (w T 2) whereas n the RTL, the wrte of the frst transacton stll hasn t happened yet. Thus, memory M B at tme-step 2 s stll equvalent to M A at tme-step 0. Fnally, n the thrd cycle, the RTL wrtes the frst result to memory. From there on, each of the desgns produces a new result every cycle, wth the dfference that the memory M B at tme-step t corresponds to memory M A at tme-step t-2. The proof procedure does not need to be fundamentally changed to handle tmng dfferences. Because we re operatng on an unrolled model, we have access to the state of the desgn n several tme frames. The only dfference s that our memory mappngs now have tme as addtonal parameter. MM(M A, M B, t):= (read(m A(t 2), ) = read(m B(t), )) When computng the formulas, t must be confrmed that when referrng to M A and M B, the correct tme frames n the unrolled model are chosen. Another dffculty that arses s that now the nducton base becomes necessary. Frst of all, we need to ensure that the gven mappng really holds after the desgn has settled and second, we need to make sure that the desgns are ndeed equvalent n the frst few cycles untl the mappng stablzes. 6. EXPERIMENTAL RESULTS The memory modelng s mplemented n our C++ to RTL equvalence checker Hector. It has been used on a number of ndustral desgns whch all contan memores. The C++ as well as the RTL were hand-coded by dfferent desgners, so they dffer rather substantally. In order to prove the desgns equvalent, all of the features of our memory model,.e., templates, mappngs between multple memores and quantfed constrants had to be used. They were provded by the desgners who knew exactly how the C++ arrays and the RTL memores were related. Table 1 presents the results. The second and thrd columns show the number of lnes of code of the C++ and the RTL code, respectvely. These numbers are approxmate numbers because we ddn t count code n lbrares. The fourth column contans the number of memores. The frst number s the number of memores n the C++, the second number s the number of memores n the RTL. Column fve shows the number of dscrepances that were found usng Hector. Some of the dscrepances were caused by mssng constrants, some turned out to be real bugs. The actual number of bugs found s shown n column sx. Column seven gves the tme requred for the proof and column 6 shows the fnal result. All desgns could be proven correct (after fxng the bugs) except desgn D5. For D5, Hector could prove most of the outputs correct except for a few where t found counter-examples. All output checks were conclusve, though, whch means we ether got a proof or a counter-example. 7. CONCLUSION We have dscussed several problems that occur when formally checkng the equvalence of an RTL model wth memores aganst ts ESL specfcaton. Specfcally, due to mplementaton decsons, the memory layouts may dffer or constrants may be requred whch can only be formulated by unversally quantfed expressons on the memores. We have presented a proof approach for transacton equvalent desgns wth memores. The dea s to use memory mappngs provded by the user as nvarants for an nducton proof. Fnally, we ve demonstrated the practcalty of the approach by applyng t to several ndustral desgns. 8. REFERENCES [1] A. R. Bradley, Z. Manna, and H. B. Spma. What s decdable about arrays? In VMCAI, pages , [2] R. E. Bryant and M. N. Velev. Verfcaton of ppelned mcroprocessors by comparng memory executon sequences n symbolc smulaton. In ASIAN 97: Proceedngs of the Thrd Asan Computng Scence Conference on Advances n Computng Scence, pages Sprnger-Verlag, [3] J. R. Burch and D. L. Dll. Automatc verfcaton of ppelned mcroprocessor control. In CAV, pages 68 80, [4] M. K. Gana, A. Gupta, and P. Ashar. Verfcaton of embedded memory systems usng effcent memory modelng. In DATE 05: Proceedngs of the conference on Desgn, Automaton and Test n Europe, pages IEEE Computer Socety, [5] P. Manolos, S. K. Srnvasan, and D. Vroon. Automatc memory reductons for rtl model verfcaton. In ICCAD 2006: ACM-IEEE Internatonal Conference on Computer Aded Desgn, [6] J. McCarthy. Towards a mathematcal scence of computaton. In IFIP Congress, pages 21 28, [7] G. Nelson and D. C. Oppen. Smplfcaton by cooperatng decson procedures. ACM Trans. Program. Lang. Syst., 1(2): , [8] A. Stump, C. W. Barrett, D. L. Dll, and J. R. Levtt. A decson procedure for an extensonal theory of arrays. In Logc n Computer Scence, pages 29 37, [9] M. N. Velev, R. E. Bryant, and A. Jan. Effcent modelng of memory arrays n symbolc smulaton. In CAV 97: Proceedngs of the 9th Internatonal Conference on Computer Aded Verfcaton, pages Sprnger-Verlag, Desgn #LOC C++ #LOC RTL #MEMs #DIS #BUGS tme result D / mn proven D / mn proven D / mn proven D /4 8 2 <1h proven D /33 > mn proven or cex Table 1: Equvalence check of desgns wth memores 209