Embed Size (px)
Citation preview
Applying Verification Intentionfor Design Customization via Property Mining
under Constrained TestbenchesChih-Neng Chung
GIEE,National Taiwan University,
Taipei, Taiwan
Chia-Wei ChangEE,
National Central University,Jhongli, Taiwan
Kai-Hui ChangAvery Design System, Inc.,
Andover, MA, [email protected]
Sy-Yen KuoGIEE,
National Taiwan University,Taipei, Taiwan
Abstract—Most synthesis tools perform optimizations basedon the design itself and do not utilize the information presentin the verification environment. Not using such informationgreatly limits the optimization capabilities of synthesis tools,which is especially serious for circuit customization because mostenvironment constraints are encoded in the testbench. To exploitverification intention, we propose a methodology that utilizesfunctional assertions for design optimization. To support circuitcustomization, we also propose a property mining technique thatcan extract properties from the design under the constraints inthe testbench. Our experimental results show that these methodscan reduce design size after synthesis, and the optimization isorthogonal to other existing circuit customization methods.
I. INTRODUCTION
Logic synthesis has been extensively studied and mostexisting tools can efficiently generate high-quality netlists.However, many tools only analyze the design by itself and donot take other useful information into consideration. For ex-ample, while the Register-Transfer Level (RTL) code faithfullycaptures the design intention aspect of the specification, thereare other aspects of the specification that do not exist in theRTL code, such as the verification intention of the specificationimplicitly encoded in the verification environment. Given thatboth intention adhere to the specification, utilizing verificationintention in synthesis tools may considerably improve syn-thesis quality. For example, constrained-random testbenchescan provide abundant controllability don’t-cares due to thesurrounding environment that a design block is embedded in,and it has been shown that utilizing such information canconsiderable improve circuit customization quality [1]. Simi-larly, assertions, score board checkers, as well as executablereference models all provide alternative interpretations of thespecification that can help the design optimization process.
In this work we focus on circuit customization using ver-ification intention encoded in functional assertions. To thisend, our first contribution is a new methodology that utilizesfunctional assertions for synthesis optimization instead of de-sign verification. Functional assertions describe the functionalrelationship among several signals in an abstract level thatis different from design implementation, and such informationcan provide useful hints to synthesis tools because it may con-
tain Boolean relations that do not exist in the implementationitself. By utilizing such new information, more optimizationscan be achieved compared with analyzing the design alone.Typically, functional assertions are written by designers orverification engineers. Alternatively, tools that try to extractsuch assertions have been developed recently [5]. However,they require fairly comprehensive simulation waveforms towork effectively. Given that most of the information usefulfor circuit customization is encoded in the testbench, wealso propose a technique that mines properties in the designbased on the constraints from the testbench. Our method cantake advantage of existing constrained-random testbenches andgenerate assertions that are aware of the input constraints.This feature is especially useful in optimizing circuits that areembedded in a system-on-chip design, where abundant con-trollability don’t-cares exist and many functions in the circuitsmay not be used. Due to the use of formal methods duringour property extraction step, no pre-simulation waveforms arenecessary, thus reducing the designers’ efforts in preparingthe waveforms. We applied our methodology to a processorand found that smaller circuits can be produced after logicsynthesis if functional properties have been used.
The rest of this paper is organized as follows. In Section IIwe briefly review existing circuit customization and assertionextraction methods. Our methodology for circuit customizationand assertion extraction are presented in Section III and Sec-tion IV, respectively. Empirical results are shown in SectionV, and Section VI concludes this paper.
II. BACKGROUND
In this section, we first review existing work that utilizesverification environments for circuit customization. We thenintroduce several assertion extraction techniques that can pro-duce properties for synthesis optimizations.
A. Circuit Customization Techniques
Most existing work that utilizes verification environmentfor synthesis optimization focuses on extracting controllabilitydon’t-cares from the testbench. To this end, Chou et al.[3] utilizes code-statement reachability analysis to identify
978-1-4577-1954-7/11/$26.00 ©2011 IEEE 84
code that becomes unreachable due to testbench constraintsand then remove such code to reduce circuit size. Chang etal. [1], [2] simulates all possible input patterns to generatesignatures and perform localized design optimizations basedon the signatures. Unlike such work, we focus on utilizingassertions for design optimization. In addition, we provide atechnique to generate functional assertions using constrained-random testbenches. In this way, we can extract controllabilitydon’t-cares from the testbench like existing work and utilizethem for design optimization.
B. Automatic Assertion Generation
Ideally, assertions should be written by designers or verifica-tion engineers as alternative interpretations of the specificationin order to find bugs quickly. Such assertions can be usefulfor synthesis optimizations because they may provide designinformation that is orthogonal to the implementation itself.However, writing assertions can be a tedious task. Therefore,assertion generation techniques have been proposed to auto-mate this process [4], [5], [6].
Wang et al. [6] proposed a methodology to generate asser-tions using symbolic simulation by analyzing code statements.However, it depends on particular code styles, which may notbe scalable and accurate. Another commonly-used approachis to analyze simulation waveforms. To this end, Chang et al.[5] proposed an event-based data-mining approach to extractassertions from simulation traces. However, such methodsare not comprehensive and the generated assertions are notguaranteed to be correct. To address this problem, Vasudevanet al. [4] proposed an engine which combines data miningand static analysis. Assertion candidates are verified by aformal checker, which can considerably improve the qualityof assertions. Due to the popularity of assertion-based verifi-cation, commercial tools that perform assertion synthesis havealso been developed. For example, IFV from Cadence DesignSystems can generate assertions based on templates [13].
One advantage of waveform-based assertion synthesis tech-niques is that the produced properties capture verificationintention from the testbench and the simulated patterns, whichcan be different from the design intention encoded by theimplementation. On the contrary, techniques that extract as-sertions from the design itself only capture design intention.Therefore, assertions generated using the waveform-basedmethods can potentially benefit synthesis optimizations more.
III. OUR DESIGN CUSTOMIZATION METHODOLOGY
Design reuse is getting popular for cost reduction. Thesereused blocks, such as circuits from an existing design orintellectual properties purchased elsewhere, typically havedifferent valid inputs in the new environment compared withthe environment that the blocks were originally designed for.Therefore, some portions of the blocks may be unused in thenew environment. How to automatically customize the reusedblocks and identify such portions then become importantissues. In traditional synthesis flows, the designer needs to
customize the design manually because the information fromthe environment cannot be utilized by synthesis tools easily.
To address this problem, we propose a methodology thatutilizes proven functional properties for circuit customization.In this work we focus on extracting such properties underthe testbench that encodes environment constraints and utilizethem for circuit customization. However, the properties canalso be written by designers or verification engineers. Inaddition, properties generated by other assertion generationtools can be used as well.
A. Problem FormulationOur circuit customization problem is formulated as follows.
Given a design containing N key variables and a constrainedrandom testbench that can generate all valid combinations ofinputs, find design optimizations using properties generatedamong the key variables that comply with the testbench. Theoptimized circuit should be equivalent to the original circuitunder the constraints in the testbench, and is allowed to benon-equivalent for inputs that violate the constraints.
Figure 1(a) provides an example to explain the problem andour solution. Assume that the design is a simple state machine,the state transitions are controlled by input sequences, and theinitial state is ’00’. If the input sequences contain all fourpossible patterns (2’b00, 2’b01 ,2’b10 and 2’b11), then all thestates can be reached. However, if the input is constrainedso that only 2’b00, 2’b01 and 2’10 are possible due to theenvironment, then only states 00 and 01 can be reached. In thiscase, if we can identify the property that “the most significantbit of state is constant 0 under the constraint that only 2’b00,2’b01 and 2’b10 are allowed as inputs”, then we can performdesign optimization by removing the bit from the circuit.
Deign properties:If input sequences only contain 2’00, 2’b01 and 2’b10.
Property DM found variable tb.dut.state[1] to be constant 1'b0Verified by SAT
DUT
Set1: inputs 00, 01, 10 and 11
Set2: inputs 00, 01, and 10
00/10/1101
00
01/10
00
11
01/10/11
Modified DUT
DUT
testbench
b. Constrained random testbench
d. Equivalence check
a. Design specification
c. Mining design property
Fig. 1. Circuit customization example. (a) Design to be optimized. (b)Illustration of Design under Test (DUT) and testbench. (c) Mined designproperty if inputs are constrained to contain only 2’b00, 2’b01 and 2’b10. (d)Equivalence checking is used to ensure the correctness of the modified DUT.
In this paper we assume that the constrained randomtestbench can generate all valid combinations of inputs, andwe represent the properties using SystemVerilog Assertion(SVA) format. Note that not all of assertions can help designoptimization. Typically, assertions that provide more don’t-care conditions are more useful.
85
B. Overview of the Methodology
The purpose of the methodology is to extract environmentconstraints from the constrained-random testbenches and rep-resent them as properties. The properties can then be usedfor design customization. The methodology is composed ofseveral key steps and they are explained in detail below.
1) Extract properties from the testbench.2) Validate properties using a formal engine for bounded
cycle length.3) Optimize design using proven properties.4) Perform equivalence checking between the original DUT
and the modified DUT. If equivalence checking fails,undo the optimizations that cause the failure.
5) Perform logic synthesis with existing tools.The first step of the methodology is to extract design proper-
ties from the testbench. In this step, a constrained random test-bench is necessary. Take Figure 1(b) as an example, we need tocreate a testbench that generates input sequences constrainedto be 2’b00, 2’b01 and 2’b10 according to the environmentconstraints. We then run the property mining algorithm (seeSection IV) to extract design properties. Note that in ad-dition to properly-constrained testbenches, under-constrainedtestbenches can also be used in our framework because ourmined properties will still be valid for all legal inputs. The onlydrawback of using under-constrained testbench is that we mayfail to identify certain properties because of the illegal inputs.On the other hand, given that developing an under-constrainedtestbench is typically much easier than developing one thatperfectly matches the environment constraints, the flexibilityfrom supporting under-constrained testbenches enables ourmethodology to be applied to a wider range of designs. Usingover-constrained testbenches in our framework may produceincorrect initial properties. However, as long as the verificationstep can find the problems, such testbenches can still be used.Finally, if the testbench has bugs and they were not caught bythe verification step, then the properties that we mined maybe incorrect. However, this represents verification holes in thedesign process, and methods to address such problems are notin the scope of this paper.
The second step is to validate the mined properties usinga formal engine. The formal method used here is bounded insequential depth so that its runtime can be short. Only provenproperties will then be used for optimization. The propertiesin our methodology are expressed using the standard SVAlanguage, hence they can be proved by existing formal tools. Inthis work, we use an internal formal engine based on symbolicsimulation to validate the assertions [10].
The next step is to apply these proven properties for designoptimization. The procedure to achieve this will be explainedin the next subsection.
Step four is to double check the correctness of the cus-tomized design by an equivalence checker between the cus-tomized design and original design under the same constrainedrandom inputs. Figure 1(d) shows an example that the originaldesign is used as a golden design for comparison with the
modified design. This step uses more elaborated and un-bounded formal proof methods to ensure the correctness of theoptimized design. Note that if bounded verification in Step twocan already prove design correctness, then this step is optional.
The final step is to synthesize the optimized RTL designusing existing synthesis tools to produce an optimized netlist.
C. Design Optimization Using Properties
In this subsection, we classify the properties into threegroups and show how to use them for design optimization.
1) Constant Variables: The first group of properties isconstant variables for both word level and bit level. Constantvariables are known to be useful for design simplification viaconstant propagation. For example, ”AND” gates or ”OR”gates can be simplified if one of the inputs are constant 0or 1, respectively. If we can prove that the value of a keyvariable is constant at either the word or bit level, we cansafely remove the code statements that access the constantparts of the variables as well as the associated portions of theregisters that store the constant values. The constant values canthen be propagated into the RTL code for more optimizations.
2) Signal Equivalency: Two signals in a design are equiv-alent if they have the same functionally. In this work weconsider both polarities of equivalency, “a = b” and “a = ¬b”.To utilize an equivalency property, we disconnect one of thevariables, say it is variable b, and connect it to variable a if thelogic level of a is smaller. If inversion is involved, then an INVgate is added. The benefit of this modification is that timing ofthe circuit may be improved since a probably changes beforeb. In addition, logic that produces b can be removed.
3) Other Combinational Relations: Properties belong tothis group are combinational in nature and involve two ormore variables. Such properties provide additional informationto describe the logic functions among different variables.Currently, we utilize implication properties in the form of“a 7→ b” for our optimizations. So we use implication as anexample to show how combinational relations can be utilized.
To apply “a 7→ b” (i.e., a implies b at the same cycle) foroptimization, we modify the design with the following steps.
1) Create a new variable, bn, such that bn = a|b.2) Replace all the places where b is used with bn.The new variable bn is equivalent to b because a = 1 and
b= 0 is a don’t-care according to property “a 7→ b”. In general,the Boolean function that can be used to replace the old one isgenerated by first identifying all the minterms that can neveroccur from the proven property. The Boolean function canthen be generated by optimizing the original Boolean functionwhile marking those minterms as don’t-cares. For implication“a 7→ b”, its Boolean function should be “¬a|b”. However,because a = 1 and b = 0 can not happen, this input patternbecomes a don’t-care. Therefore, the Boolean function can besimplified to a|b. What this does is that b can now take a peekat a to see if itself should be 1. If a has a smaller logic level,then timing of b may be improved. Otherwise, this “look-ahead” may also simplify part of the logic due to additionaldon’t-cares.
86
In summary, the constant properties can almost always helpoptimize the design since they can reduce both combinationallogic and the number of registers. Other types of propertiesmay help optimize the design but the usefulness of theproperties depends on the logic levels of the involved signalsas well as the logic functions among the signals.
IV. PROPERTY MINING
In this section we explain how to extract properties underthe environment constraints encoded in the testbench.
A. Property Mining Algorithm
Our property mining algorithm is based on symbolic sim-ulation, logic simulation and formal verification. Symbolicsimulation is used for converting the testbench into Booleanlogic [7], [8], [9], [11], but can be replaced by other for-mal methods that serve the same purpose. The algorithm isshown in Figure 2. The inputs to the algorithm are vars thatcontains key variables to be analyzed, the circuit design tobe optimized, the testbench tbench, the number of symbolicsimulation cycles M, and the number of initial random patternsfor logic simulation N. The output of the algorithm is a set ofproperties that describe logic relations among variables in varsthat are proven to hold under the constraints. In this algorithm,the length of symbolic simulation is M cycles, hence theproperties we generated are guaranteed to hold under all Mcycles. If M is greater than the sequential depth of the design,then the properties will hold unboundedly. Otherwise, otherformal methods, such as equivalence checking or proof-by-induction, will need to be performed to ensure the correctnessof the properties.
procedure property mine(vars,design, tbench,M,N)1 symbolically simulate design under tbench for M cycles
while replacing each $random in tbench with a new symbol;2 at each cycle save symbolic trace for each var ∈ vars;3 simulate N random patterns using the symbolic traces to
generate N values for each var ∈ vars at each cycle;4 foreach var ∈ vars that have the same simulated values at
all cycles5 use formal engine to prove if var is constant;6 if (var is not constant)7 resimulate using the counterexample as a new pattern;8 properties← pattern matching(vars)9 foreach (property ∈ properties)10 if (property is proven to hold))11 f inal properties← property∪ f inal properties;12 return f inal properties;
Fig. 2. Our property mining algorithm.
In line 1 of the algorithm we perform symbolic simulationfor M cycles while replacing each $random in the testbenchwith a new symbol. This step serves two purposes. First, byreplacing $random with a symbol we can consider all possiblevalues simultaneously. Second, by simulating through the test-bench we can utilize the environment constraints encoded bythe testbench in our analysis. Note that in modern testbenches$random may be replaced by complex randomization schemesbased on constraints. However, the underlying concept is still
the same. The symbolic trace for each var ∈ vars at eachcycle is then saved in line 2. In line 3 we simulate N randompatterns to generate N simulated values for each variable ateach cycle. For pattern j in cycle i, we save the simulatedvalue of variable var into its var.value[i][ j] field. Althoughthis can be done by performing random logic simulation on thedesign itself, we found that simulating symbolic traces is moreefficient because the traces are optimized during symbolicsimulation. From line 4 to line 7 we formally check all thevariables that have the same simulated values for all patternsat all cycles to see whether those variables are indeed constant.This is achieved by forming a SAT problem that constrains theoutputs of symbolic traces to a value other than the constantvalue and see if a solution can be found. If a solution can befound, it becomes a counterexample that proves the variableto be non-constant. We then resimulate all the symbolic tracesusing the counterexample as a new pattern. The purpose ofthis step is to generate patterns that can exercise the designsbetter so that the pattern matching step will have fewer falsepositives. In line 8 of the algorithm we use pattern matchingto mine properties from the simulated values, which will bedescribed later. In lines 9 to 11 we use formal methods to provewhether the property holds except the constant properties thathave already been proved in line 5. In line 12 we return allthe properties that are proved to hold. Note that the the timecomplexity of the algorithm may be high due to the use offormal methods, and standard complexity-reducing techniquessuch as abstractions can be used to alleviate the problem.
Procedure patten matching is shown in Figure 3. It rec-ognizes predefined property templates using the simulationvalues saved in var.value[i][ j] for variable var at cycle i withthe j-th random pattern. The input to the procedure is the setof key variables vars, and the output is the mined properties.
procedure pattern matching(vars)1 foreach var ∈ vars2 if (∀i, j (cycle i pattern j) var.value[i][ j] is the same)3 properties← properties∪ const prop(var);4 var pairs← get var pairs(vars);5 foreach (var1,var2) ∈ var pairs6 if (∀i, j (cycle i pattern j)
var1.value[i][ j]=var2.value[i][ j] —var1.value[i][ j]=¬var2.value[i][ j])
7 properties← properties∪ equiv prop(var1,var2);8 else if (∀i, j (cycle i pattern j)
var1.value[i][ j]→ var2.value[i][ j] is true)9 properties← properties∪ imply prop(var1,var2);10 return properties;
Fig. 3. Pattern matching procedure from simulated values.
In lines 1 to 3, the algorithm checks whether the simulatedvalues for a variable are the same for all cycles and all patterns.If so, then a constant property is recognized for the variable.We then extract variable pairs in line 4. For each pair ofvariables var1 and var2 we then check whether they alwayshave the same or inverted simulated values in lines 6. If so,then equivalency relation has been found between var1 andvar2. In line 8 we check if implication relation exists between
87
var1 and var2. If so, then implication relation has been found.All the mined properties are then returned in line 10.
In this work procedure get var pairs is implemented withtwo methods. The first one returns all possible variable pairsin the design. This method ensures that no property willbe missed. However, runtime overhead can be significant.The second one is to do a breadth-first traversal for eachvariable and only return pairs of variables that are structurallyconnected. The reason behind this is that logic relations aremore likely to exist for variables that are connected. In ourimplementation we extract pairs of variables that are 3 to 5steps from each other, where one step is defined as a con-nection from a variable to another. The numbers of steps areparameters that can be changed for different designs. We foundthat this method can reduce runtime without considerablysacrificing the number of mined properties.
In summary, Figure 4 shows the Boolean templates that weuse to mine properties in our current implementation.
Property type Descriptionsvar1 7→ var2 var1 implies var2var1 = var2 var1 and var2 are functionally equivalent
(or inversely equivalent)Constant var1 var1 is a constant that never changes
Fig. 4. Properties that can be recognized in this work.
B. Implementation Insights
In the property mining algorithm, properties are extractedfrom the patterns produced by random simulation; therefore,no pre-simulation waveform is necessary. To improve thequality of random simulation, we use formal methods toobtain input patterns so that all non-constant variables canbe distinguished by at least one pattern. In this way, we willreduce the number of properties that are falsely identifiedby the pattern matching procedure. Instead of using formalmethods, patterns obtained from regression tests can also beused. Since regression tests contain the patterns to hit cornercases, they can also improve the quality of simulation.
Selecting too many key variables can make runtime un-necessarily long because there are more relations to check.A heuristic for selecting good key variables is to excludevariables in the data path and focus on the variables in controllogic. The reason is that few properties can be mined in thedata path unless the environment has constraints on data thatcan be processed, which is rare in practice. Most often theconstraints are related to the control logic, such as configuringthe design to a specific mode or not allowing the use ofcertain functions. Therefore, focusing on the control logic cantypically produce better results.
Sometimes more than one testbenches are used to verifydifferent aspects of the design. Given that different testbenchesrepresent different sets of legal inputs, the properties for designcustomization should be the union of all the properties. How-ever, if any property failed verification under any testbench,then the property should not be used because the Booleanrelation it represents is invalid under different sets of inputs.
V. EXPERIMENTAL RESULTS
We applied our methodology to a DLX processor from thethe BugUnder Ground (BUG) project in the University ofMichigan [12]. The experiments were conducted on a Linuxmachine running Ubuntu Linux 8.04 with AMD Phenom IIx4 940 CPU and 8G memory. Logic synthesis was performedwith a commercial tool with a 0.13µm library. The clock periodwas set to 20ns, and the setup time of this library was 0.68ns.The total area and timing slack for the synthesized DLXwere 133420.728µm2 and 0.13ns, respectively. These numbersare used as the baseline for the comparisons performed inour experiments. Note that larger slacks mean the circuit canoperate on higher frequencies, resulting in better performance.
To perform circuit customization, we developed testbenchesthat allow different sets of instructions, which is shown inTable I. We chose the sets of instructions to be the same asthose used in [3] so that we can compare our results with[3]. Control signals and state registers of the DLX design areselected as key variables. The number of symbolic simulationcycle was set to 7 since DLX is a 5-stage pipeline design, andkey variables can reach all their possible states in 7 cycles.Hence these mined properties will be proven with the boundedlength equal to 7. The number of random patterns was set to8192 to generate the simulated values for property mining.
In some cases, the control signals in a design may be com-plicated and it may be difficult to calculate the required logicdepth to cover all possible state transitions. To handle suchdesigns, unbounded model checking or reachability analysiscan be applied to prove the correctness of the mined properties.
TABLE IDLX INSTRUCTIONS ALLOWED IN EACH GROUP.
Inst. Group Instructions allowedG1 NOPG2 ADD, ADDI, NOPG3 ADD, ADDI, SW, LW, NOPG4 ADD, ADDI, SW, LW, SRL, SLL, SRA, BEQ, NOPG5 ADD, ADDI, AND, ANDI, XOR, SLT, SLTI, SW, LW,
SRL, SLL, SRA, BEQ, BNE, J, JAL, NOP
TABLE IIDLX OPTIMIZED USING OUR METHODOLOGY.
Inst. Group Runtime #Applied Area Reduction Timing(s) properties (µm2) ratio slack (ns)
G1 0.98 722 3148.6 97.6% 8.07G2 47.03 66 108441.79 18.7% 2.13G3 60.79 40 118857.0 10.9% 2.83G4 76.22 26 127466.2 4.5% 0.24G5 109.49 24 132088.2 1% 0.07
In our first experiment we performed property mining basedon the testbenches that allow different sets of instructions,optimized the RTL code according to the mined properties, andthen synthesized the optimized code. The synthesis results arelisted in Table II. In the table, runtime is from property miningin our methodology. Currently, we need to manually changethe RTL code according to the mined properties. In the futurewe will automate this process. From the results, we can seethat property mining was fast in that it finished in two minutesfor all the sets of instructions. In addition, circuit areas reducedafter our optimizations, and the timing slack improved for most
88
cases. These results show that our methods can perform circuitcustomization efficiently and effectively. In our experience, themost useful properties are the signals proven to be constantbecause they always simplify part of the logic in the circuit.We also observed that these properties are valid due to theconstraints from the testbench instead of the design itselfbecause when running the testbench that allows all possibleinstructions, these properties do not exist. This result showsthat our methodology can successfully mine properties fromthe testbench and utilize them for design optimization.
In Table II we also show the number of applied propertiesfor each set of instructions. Note that set G1 only containsNOP (no operation implemented using left-shift by 0 bits)and is not practical. However, it shows an intereseting conrnercase — 97.6% logic can be removed when most functionalityof the circuit is not used.
In our second experiment, we applied our techniques toDLX designs which were already optimized by [3]. The resultsare summarized in Table III. Compared with the runtime inTable II, runtime in this experiment became smaller becausethe circuits have been optimized already, thus there were fewpairs of variables to check and fewer properties to extract.However, the results show that even though the designs werealready optimized, we could still find optimizations that furtherreduce circuit area, suggesting that our optimizations areorthogonal to those provided by [3] and can provide additionalarea reduction. To identify where the additional optimizationswere from, we performed a more detailed analysis, and theresults are shown in Table IV. From the results, we can seethat our methods reduced some combinational logic. However,most of the area reduction was from sequential logic. This is anarea that [3] could not perform well: their methods are basedon code reachability analysis and tend to optimize combina-tional logic, while ours can optimize both combinational andsequential portions of the circuit.
TABLE IIIDLX OPTIMIZED USING OUR METHODOLOGY AFTER OPTIMIZATIONS
FROM [3] IS PERFORMED.
Inst. Run #Pro- Opt. by [3] Further opt. by this work SlackGro- time per- Area Reduc- Area Reduc- timeup (s) ties (µm2) tion ratio (µm2) tion ratio (ns)G1 0.20 174 7429.5 94.4% 5407.9 95.9% 8.07G2 2.85 39 101353.4 24.0% 99552.5 25.4% 3.32G3 3.37 24 116295.6 12.8% 108445.2 18.7% 3.41G4 18.01 19 124339.6 6.8% 123226.1 7.6% 0.75G5 34.49 19 130526.6 2.2% 129243.4 3.1% 0.12
TABLE IVCOMPARISON OF OPTIMIZATIONS ACHIEVED BY [3] AND OUR WORK.
Area after opt. from [3] (µm2)Comb. logic Seq. logic Total
Inst. Group 52310.4 63985.2 116295.6G1 Area after further opt. by our methodology (µm2)
Comb. logic Seq. logic Total50329.6 58115.6 108445.2
Runtime comparison between our methods and [3] showsthat our runtime (within two minutes) is much shorter than thatin [3] (over an hour for most cases ). This comparison showsthat our methodology based on properties is more efficient than
code reachability analysis. On the other hand, a comparisonof area reduction between Table II and III shows that utilizingeither one of the optimization methods cannot achieve whatthe combined methods provide. Therefore, it is best to applyboth techniques so that designs can be better optimized.
VI. CONCLUSION
Synthesis tools have evolved to a point where most designscan be synthesized and optimized efficiently and effectively.However, most tools only utilize design intention representedin the RTL code and do not consider verification intentionencoded in the verification constructs such as testbenches orassertions. Not being able to utilize the information from veri-fication environment greatly limits optimization capabilities ofsynthesis tools. This problem is especially serious for circuitcustomization because most environment constraints are foundin the testbenches. To address this problem, we proposeda methodology that utilizes functional assertions for designoptimization. In addition, we proposed a new technique thatextracts assertions from the design under the constraints inthe testbench. Experimental results show that our methodscan reduce design sizes after synthesis, and the optimizationis orthogonal to another optimization based on reachabilityanalysis [3]. These results show that our techniques can helpdesigners better address the circuit customization problem. Inthe future, we plan to enhance our property miner to recognizemore types of properties. By utilizing more properties, moredesign optimization opportunities can be exposed and utilized.
ACKNOWLEDGMENT
This research is supported by the Institute for InformationIndustry, Taiwan under Grant 99-FS-C02.
REFERENCES
[1] K.-H. Chang, V. Bertacco, I. L. Markov and A. Mishchenko, “Logic Syn-thesis and Circuit Customization Using Extensive External Don’t-Cares,”ACM Transactions on Design Automation of Electronic Systems,,Vol. 15,No. 3, Article 26, 2010
[2] K.-H Chang, V. Bertacco, and I. L. Markov, ”Customizing IP Coresfor System-on-Chip Designs Using Extensive External Don’t-Cares,”DATE’09, pp. 582-585.
[3] H.-Z. Chou, K.-H. Chang and S.-Y. Kuo, ”Optimizing Blocks in an SoCUsing Symbolic Code-Statement Reachability Analysis” ASPDAC’10,pp. 787-792.
[4] S. Vasudevan, D. Sheridan, S. Patel, D. Tcheng, B. Tuohy and D. Johnson,”GoldMine: Automatic assertion generation using data mining and staticanalysis” DATE’10, pp. 626 - 629.
[5] P.-H. Chang and L.-C. Wang, ”Automatic assertion extraction via sequen-tial data mining of simulation traces” ASPDAC’10, pp. 607-612.
[6] L.-C. Wang, M. S. Abadir and N. Krishnamurthy, ”Automatic generationof assertions for formal verification of PowerPC microprocessor arraysusing symbolic trajectory evaluation” DAC’98, pp. 534-537.
[7] R. E. Bryant, “Symbolic Simulation – Techniques and Applications,”DAC’90, pp. 517-521
[8] A. Kolbl, J. Kukula and R. Damiano, “Symbolic RTL Simulation,”DAC’01, pp. 47-52.
[9] A. Kolbl, J. Kukula, K. Antreich and R. Damiano, “Handling SpecialConstructs in Symbolic Simulation,” DAC’02, pp. 105-110.
[10] H.-Z. Chou, I.-H. Lin, C.-S. Yang, K.-H. Chang and S.-Y. Kuo, “Enhanc-ing Bug Hunting Using High-Level Symbolic Simulation,” GLSVLSI’09,pp. 417-420.
[11] Insight, http://www.avery-design.com[12] Bug UnderGround, http://bug.eecs.umich.edu[13] http://www.cadence.com
89
