LEC Verification Guide

LEC Verifi ri ficatio cation n Guide Guid e Product Version 12.1 July 31, 2013

This guide reviews the key steps in the synthesis verification flow. This guide has recommendations on RTL Design / Synthesis for ease of verification, running LEC effectively, resolving abort, debugging non-equivalence and updating LEC dofile, etc that will help streamline the verification process.

LEC Verification Guide

Copyright Statement © 2008-2013 Cadence Design Systems, Inc. All rights reserved worldwide. Cadence and the Cadence logo are registered trademarks of Cadence Design Systems, Inc. All others are the property of their of their respective holders.


Contents Purpose ....................................................................................................................... 5 RTL Design for Ease of Verification ............................................................................. 5 RTL Coding Guidelines for Ease of Verification ....................................................... 5 Removing Don’t Care Conditions in RTL ................................................................. 6 Removing Don't Care Conditions in RTL.................................................................. 6 Removing Don't Care Conditions in RTL (index out-of-range reading) .................... 6 Removing Don't Care Conditions in RTL (unique case) ........................................... 7 Removing Don't Care Conditions in RTL (X assignment)......................................... 7 Removing Don't Care Conditions in RTL (range constraint)..................................... 8 Structural Implementation in RTL ............................................................................. 8 Design Partitioning in RTL ....................................................................................... 8 Design Report .......................................................................................................... 9 Design Partitioning in RTL (add module hierarchy) .................................................. 9 Design Partitioning in RTL (add module hierarchy) .................................................. 9 Understand Design Verification Complexity ........................................................... 10 Run LEC RTL Rule Checker .................................................................................. 10 Checklist for RTL Designs ...................................................................................... 11 Synthesis for Ease of Verification .............................................................................. 11 Multi-Stage Synthesis ............................................................................................ 12 Embed Verification Requirements in Synthesis...................................................... 12 Module Based Datapath (MDP) Analysis ............................................................... 12 Synthesis Script to Enable MDP Analysis .............................................................. 12 Synthesis Script to Enable MDP Analysis (continued) ........................................... 13 Collecting Synthesis Data ...................................................................................... 13 Qualifying Your Synthesis Environments ............................................................... 13 Checklist for Synthesis ........................................................................................... 14 Running LEC Effectively ............................................................................................ 14 Verification Flow ..................................................................................................... 14 Checklist for Running LEC ..................................................................................... 14 What is an Abort ........................................................................................................ 15 What Causes an Abort? ......................................................................................... 15 LEC Methods to Resolve Abort .............................................................................. 15 Advanced LEC Techniques .................................................................................... 15 User can Help to Resolve Abort ............................................................................. 16 Review Synthesis Flow .......................................................................................... 16 Review LEC Dofile/Logfile...................................................................................... 16 Make LEC Hierarchical Compare Successful ........................................................ 16


Abort Diagnosis ...................................................................................................... 17 Abort Diagnosis (Isolation for Datapath Module) .................................................... 17 Abort Diagnosis (Isolation for Datapath Module) .................................................... 18 Unresolved Aborts .................................................................................................. 18 Checklist for Resolving Aborts ............................................................................... 18 Set Up LEC Correctly for NEQs ................................................................................. 19 Debugging NEQs ....................................................................................................... 19 Ensure High Quality Mapping ................................................................................ 19 Validate the RTL Elaboration Results .................................................................... 20 Incomplete Modeling .............................................................................................. 20 Using Higher Effort for Modeling and Setup ........................................................... 20 Re-synthesis for Resolving NEQ ............................................................................ 20 Loops and Cuts ...................................................................................................... 20 Checklist for Debugging NEQs............................................................................... 21 Getting Help ............................................................................................................... 21 Checklist for Preparing Testcase ........................................................................... 21 Use LEC New Features in the Dofile ......................................................................... 22 Conformal LEC Drop-In Beta Program ................................................................... 22 Recommended Directory Layout ............................................................................ 22 Appendix: Example Dofile for RTL-to-Gate Verification ......................................... 22 Appendix: Example Dofile for Gate-to-Gate Verification ........................................ 23


Purpose This guide reviews the key steps in the synthesis verification flow. Following are the recommendations in this guide will help streamline the verification process. This guide covers the following topics: • • • • • • •

RTL design for ease of verification Synthesis for ease of verification Running LEC effectively Resolving abort Debugging non-equivalence Getting help Updating LEC dofile

RTL Design for Ease of Verification This describes the following: • •

The impact of RTL design on verification Factors of RTL designs that can affect the ease of veri fication: Don’t care conditions in RTL Structural implementation Partitioning of designs Coding RTL with the previously-mentioned factors in mind to help avoid aborts in verification   

•

Coding guidelines are provided in the following slides.

RTL Coding Guidelines for Ease of Verif ication •

•

•

Adopt RTL coding guidelines for verification and include them into the designer's coding style guide. Being aware of verification during the design stage can streamline all the downstream synthesis and verification processing. Run LEC in the early stages of design. Check that the coding guidelines are fulfilled o o Understand verification complexity for your design style and avoid recoding RTL at the last minute to resolve aborts


Removi ng Don’t Care Cond itio ns in RTL Removing don't care conditions in RTL is good for • • • •

Resolving aborts Diagnosis Performing ECO Simulation

Don’t care conditions are created in RTL by • • • •

Array index out-of-range reads Parallel/Full case statements X assignments Range constraints (VHDL)

A don’t care condition in RTL can be synthesized to any Boolean function.

Removi ng Don't Care Condi tion s in RTL LEC can report the RTL source of don't care conditions: report message -rule F34 -verbose // Converted 'type of don't care' at 'gate_name' be don't care source_code_file_name:line_number (LEC mode) Example: // 1: Converted 'index out of range' at 'n1' be don't care design.sv:321 // 2: Converted 'parallel_case' at 'n2' be don't care design.sv:322 // 3: Converted 'full_case' at 'n3' be don't care design.sv:323 // 4: Converted 'X assignment' at 'n4' be don't care design.sv:324

General rules for removing don't care conditions: • •

Preserve the function under the care condition Implement a deterministic function under the don't care condition

Removi ng Don't Care Cond itio ns i n RTL (index out -of-range reading) Interpret the index as a constant 0 when it is out of range:


// RTL wire A, B[6:0], C[2:0]; // Since the index of B only allows from 0 to 6, // don't care conditions are introduced when C[2:0] > 6. A = B[ C[2:0] ]; // RTL without don't care conditions A = B[ (C[2:0] > 6) ? 0 : C[2:0] ];

Removi ng Don't Care Conditio ns i n RTL (uniq ue case) Use and/or logic to implement selection function: In general, the implementation using this coding style is more compact and thus it can yield optimal synthesis QoR performance. // RTL wire sel[1:0]; wire in0, in1, in2; reg out; always @(*) // one-hot case selection unique case (1'b1) sel[0] : out = in0; // sel = 01 sel[1] : out = in1; // sel = 10 endcase // sel = 00, 11 : don't care // RTL without don't care conditions // (branch-1-condition & branch-1-data) | // ... | // (branch-n-condition & branch-n-data) out = (sel[0] & in0) | (sel[1] & in1);

Removi ng Don't Care Conditio ns i n RTL (X assig nment) Implement the X assignment as a constant: // RTL wire sel[1:0]; wire in0, in1, reg out; always @(*) case (sel) 2'b01 : 2'b10 : default : endcase // RTL without always @(*) case (sel) 2'b01 : 2'b10 : default : endcase

in2;

out = in0; out = in1; out = 1'bx; don't care conditions out = in0; out = in1; out = 1'b0;


Removi ng Don't Care Cond itio ns in RTL (range constr aint) Extend the range to the full range of the bit vector: // RTL (VHDL) entity mult is # Since the range is not the full range of the bit vector [1:0], # don't care conditions are introduced. port (a, b : IN integer range -1 to 1; prod : OUT integer); end mult; architecture rtl of mult is begin prod <= a * b; end rtl; // RTL without don't care conditions entity mult is # Extend to the full range of the bit vector [1:0] port (a, b : IN integer range -2 to 1; prod : OUT integer); end mult; architecture rtl of mult is begin prod <= a * b; end rtl;

Structu ral Implementation in RTL •

•

As the structural similarity between RTL and the synthesis netlist increases, the ease-ofverification increases. Use detailed structural descriptions in RTL so that structural changes in synthesis are easier to control. o For complex arithmetic expressions, introduce intermediate signals and additional assignments o Implement datapath word-level structures in an explicit way

Design Partiti onin g in RTL • •

•

•

Partitioning design breaks into smaller pieces for ease of veri fication Separate logic into different blocks. Specifically, separate datapath blocks from control blocks. Keep datapath intensive modules to a reasonable size. Modules that have less than 50k primitives and 50 datapath operators are generally easier to verify. Add additional module hierarchies to prevent critical signals from being optimized away for ease of verification.


Design Repor t LEC can report the module size in design hierarchies to help you partition the design into reasonable sizes. Example: ============================================ Summary Golden Revised ============================================ Design-modules 31 5 -------------------------------------------AND * 3323 3821 .... XOR * 2106 0 ------ word-level -------------------------ADD * 40 0 MULT * 2 0 SUBTRACT * 34 0 -------------------------------------------Total 7927 10158

Design Partiti oni ng in RTL (add modu le hierarchy) Make critical intermediate signals in RTL as module boundaries and preserve them during synthesis. // RTL module top (input [31:0] a, b, c, d, e, f, output [31:0] out); wire [31:0] t; assign t = a + b + c + d + e; assign out = t * f; endmodule // Recoded RTL module top (input [31:0] a, b, c, d, e, f, output [31:0] out); wire [31:0] t; // add module for preserving intermediate RTL signals new_mod i0 (a, b, c, d, e, t); assign out = t * f; endmodule // add additional module hierarchy module new_mod (input [31:0] a, b, c, d, e, output [31:0] t); assign t = a + b + c + d + e; endmodule

Design Partiti oni ng in RTL (add modu le hierarchy) Convert critical functions in RTL to modules and preserve the module boundaries during synthesis.


// RTL module top (input [31:0] a, b, c, d, e, f, output [31:0] out); wire [31:0] t; function [31:0] func_add; input [31:0] a, b, c, d, e; begin func_add = a + b + c + d + e; end endfunction assign t = func_add(a, b, c, d, e); assign out = t * f; endmodule // Recoded RTL module top (input [31:0] a, b, c, d, e, f, output [31:0] out); wire [31:0] t; // Convert the function into module new_mod i0 (a, b, c, d, e, t); assign out = t * f; endmodule // add additional module hierarchy module new_mod (input [31:0] a, b, c, d, e, output [31:0] t); assign t = a + b + c + d + e; endmodule

Understand Design Verif ication Compl exity •

•

Run LEC in an early design stage to understand the verification complexity of the design style. If the design has aborts, LEC can analyze the abort point.

Example: • ----------------------------------------------• Compared result is abort. • (G) + 38 PO /O1 • (R) + 38 PO /O1 • ----------------------------------------------• Don't care condition 1) (G) X-assignment • • rtl.v:line 17, column 319 • ----------------------------------------------• Similarity degree of the abort point fanin cone • 20% fanin cone of gate O1 • ----------------------------------------------• Datapath resources which cause abort: 1) (G) Datapath_module instance • • rtl.v:line 5, column 346 •

-----------------------------------------------

Run LEC RTL Rule Checker The LEC RTL rule checker can help reduce many potential synthesis and verification issues.


•

•

Check the rules that highlight potential ambiguities in verification, such as simulation mismatches. Ensure that there are no error/warning messages reported by RTL rule checks. To specify rule severity: report rule check Example: RTL5.1: Overlapped case items are in parallel case statement Type: Golden

Severity: Warning

Occurrence: 1

RTL5.4: Partial case items are in full case statement Type: Golden

Severity: Note

Occurrence: 1

HRC3.10a: An input port is declared, but it is not completely used in the module Type: Golden

Severity: Warning

Occurrence: 1

Checkli st fo r RTL Design s Checklist Items Remove don't care conditions in the RTL Use structural descriptions instead of behavioral descriptions in RTL Partition the design into a reasonable size No error/warning messages reported by the RTL rule checker No simulation mismatches reported by RTL rule checker

Synthesis for Ease of Verification Setting up a synthesis flow with verification considerations can significantly reduce verification challenges: • •

Synthesis bugs are more easily identified Enables the use of more LEC features (such as module-based datapath analysis and hierarchical comparisons) to streamline the verification process


Multi-Stage Synth esis The basic guideline for ensuring ease of verification is to break down the difficulty in order to verify synthesis optimizations in stages. Recommended synthesis stages: •

•

RTL to first mapped netlist o Enable: datapath synthesis o Disable: ungrouping, boundary optimizations, clock gating, phase inversions, and name changes Mapped netlist to optimized mapped o Enable: ungrouping, incremental optimizations, boundary optimizations, and clock gating

Embed Verificatio n Requi rements in Synthesis •

•

•

To deploy a synthesis flow that is easy to verify, embed the verifications into the synthesis scripts instead of re-synthesizing after running into verification challenges. Control synthesis options that impact verification, such as: o Range constraint optimization o Datapath synthesis, resource sharing o Ungrouping, boundary optimizations, and clock gating Allow for a range of verification requirements to allow for trade-offs in verifiability

Module Based Datapath (MDP) Analysis Module-based datapath (MDP) analysis performs datapath abstraction at the module level, and is performed prior to the regular operator-level analysis. MDP analysis requires that synthetic datapath modules be preserved during synthesis. MDP analysis is performed in order to improve the quality of the operator-level analysis.

Synthesis Scrip t to Enable MDP Analysis LEC provides a synthesis script that ensures that the MDP analysis can be effectively applied for ease of verification. The script can be embedded into the overall synthesis script as follows: ## generate the first mapped netlist source /share/cfm/lec/scripts/mdp.tcl compile_ultra_mdp ## generate the final mapped netlist (with incremental optimization) compile -incremental


•

compile_ultra_mdp procedure is invoked before the first compile command in the DC script

•

design_module argument in the procedure is the name of the top module that is

synthesized

Synthesis Scrip t to Enable MDP Analysi s (conti nued) The level argument in the procedure can be 1, 2, 3, or 4 and affects the synthesis as follows:

MDP Level

Preserve Hierarchy of DP/DW

Design

Boundary Optimization Sequential Output Inversion

1

YES

NO

ALLOW

ALLOW

2

YES

NO

DISABLE

ALLOW

3

YES

NO

DISABLE

DISABLE

4

YES

YES

DISABLE

DISABLE

Collecting Synthesis Data During the synthesis process, the following information should be collected for verification: •

• •

Datapath resource file: Required to ensure that datapath intensive design can be easily verified Change name file: Required to ensure name-based mapping for ease of ve rification Synthesis log file: Can contain information to help guide the setup of the verification

Qualifying Your Synthesis Environments •

•

New versions of synthesis tools can introduce new verification requirements o New optimization techniques (such as, sequential constant groups) o New datapath structures (such as, new multiplier architectures) o New technology mapping techniques (such as, using multi-bit library cells) o Changes in naming conventions (such as, in generate statements) o Changes in default synthesis option settings (such as, having sequential merge optimizations ON by default) LEC is shipped with IP-free designs that can be used as testcases in a new synthesis environment or tool o Enable users to provide early feedback to the Conformal team to ensure success of verifications in the latest synthesis environment


Checklist fo r Synthesis

Check Items Use 2-step synthesis (RTL to first mapped, first mapped to final netlist) Use MDP synthesis flow Only incremental optimization is used for gate-to-gate compare Collect datapath resource file and synthesis logfile

Running LEC Effectiv ely To ensure the best results of verification: • • •

Standardize on a dofile Deploy advanced features Review dofiles regularly

Verification Flow •

•

•

Standardize a verification flow (see example dofile in Appendix) Use hierarchical comparisons when verifying RTL to mapped netlist o o Use module-based analysis for datapath designs o Mapped to optimized mapped (can be flattened comparison) Deploy advanced LEC capabilities Capture these in the standardized dofiles o o Multi-threading for abort analysis and comparison o Datapath analysis o Analyze abort Review dofiles regularly

Checkli st for Runni ng LEC Check Items Use a standard LEC dofile to verify the designs Use hierarchical comparison to compare RTL with the first mapped netlist Do datapath analysis: analyze datapath -module; analyze datapath Use "analyze abort -compare " to solve aborts Use multi-threading for compare and abort analysis: set parallel option -threads 4


What is an Abort •

•

•

•

All formal verification tools have a worst-case scenario where it takes an exponential amount of time to complete To avoid the unrealistically long execution and to give a timely response, LEC aborts the comparison Abort is a notion that LEC finds it not likely to prove or disprove the equivalence relationship within a reasonable amount of time Abort also means that LEC will need much more effort and time on the proof, after which it still may not resolve them

What Causes an Abort ? •

•

•

Design size The larger the size of the design, the more difficult it can be to compare o o Ungrouping design modules or boundary optimization increases the design size Design similarity o Less design similarity makes compare more difficult Advanced synthesis optimization usually decreases the design simil arity o Design function o More complex function such as don't care conditions or datapath makes compare more difficult o Synthesis has more chance to optimize the design with datapath or don't care conditions

LEC Metho ds to Resolv e Abort •

•

LEC integrates many techniques to resolve abort o Compare engine o Datapath analysis o Hierarchical compare o Structural partition o Functional partition o Multi-threading Following LEC recommended usage to execute the tool can utilize the advanced techniques

Ad vanced LEC Tec hn iques •

LEC commands are available to resolve aborts o o o o

analyze abort -compare analyze datapath -wordlevel analyze partition add partition points read design –norangeconstraint –vhdl 


User can Help to Resolve Abor t •

•

•

Use LEC recommended synthesis flow o DC-MDP o RC-LEC o Incremental synthesis (gate-to-gate compare) Resolving abort through re-synthesis o Adjust synthesis optimizations o Keep design hierarchies and preserve critical signals Resolving abort through recoding RTL o Remove don't care condition

Review Synthesis Flow •

Check if non-standard synthesis flow is used: o Advanced optimizations are turned on during synthesis o Boundary optimization or ungrouping is applied on the complex modules, which causes hierarchical compare not efficient

Review LEC Dofile/Logfile •

•

•

•

Hierarchical comparison o For abort modules, check that no sub-modules (primitive size larger than 5k) are not blackboxed For datapath-intensive designs Check that MDP has been used ( analyze datapath –module ) o o Check that datapath analysis is successful Abort Analysis o Check that LEC abort analysis has been used ( analyze abort ) Multithreading o Check that multithreading is used for abort analysis

Make LEC Hierarchi cal Compare Successf ul • •

•

Sub-modules with high compare complexity must use hierarchical compare to resolve abort For hierarchical compare to be successful, it needs to keep the module boundary and disable all the optimizations across boundary o Preserve module boundary o Disable clock gating o Disable boundary optimizations LEC can report the reason that hierarchical compare cannot be applied on the module


•

LEC generated hier.do

•

// Module Pair: mod (G) and mod (R) • // Cause for mismatched ports is hierarchical clock-gating • // IN (R) port_name (REP) • // (Extra clock pin due to hierarchical clock-gating) • ... •

It can guide the user to adjust the synthesis flow to generate the netlist in which the submodule can run hierarchical compare

•

Ab or t Di agnosi s •

•

When aborts cannot be completely resolved, identifying the region where aborts occurred: o Allows for more targeted re-synthesis Allows for better understanding on the netlist that leads to abort o o Allows for additional verification to these smaller regions Techniques for isolating aborts: o Ensure that the modules are hierarchically compared Easier if RTL is partitioned well o In MDP analysis flow, abstracted datapath cluster can be automatically isolated 

Ab or t Di agnosi s (Iso latio n f or Datap ath Mod ule) When using MDP analysis, LEC can isolate the datapath module that causes the abort so that the remaining non-aborting netlist can be verified: •

•

Narrow down the abort region. Instead of reporting all fanout keypoints from the datapath module as abort, only the datapath module is reported as abort (See next slide) Invoke abort isolation using the following command: •

analyze datapath –isolate_abort_module -module \ [-resourcefile ]

Automatically generate a testcase for the abort datapath module using the following command:

•

set project name ... • analyze datapath -module [-resourcefile ] • •


Ab or t Di agnosi s (Iso latio n f or Datap ath Mod ule) •

Results with abort: • • • • •

=========================================== Compared points PO Total -------------------------------------------Abort 256 256 ============================================

Results with abort isolation: • • • • • • • • • • • •

============================================ compared points PO Total ------------------------------------------Equivalent 256 256 ============================================================ Compared results of isolated instances in Revised design (top) ============================================================ Status Instance (Module) -----------------------------------------------------------Abort i0/add_1_S1_DP_OP_1_1 (block_add_1_S1_DP_OP_1_1) ============================================================

Unresolved Aborts When an abort cannot be resolved, running the following methods on the abort points can increase the chance to detect non-equivalence if it exists in the designs: • • •

Simulation Functional partition Set LEC compare effort as complete

Checklist for Resolving Abort s Check Items All the sub-modules (primitive size > 5k) in the aborted module have been blackboxed in hierarchical compare Use the LEC command to isolate aborted MDP datapath module and extract the testcase Use "analyze datapath -wordlevel " for the aborted module Recode RTL to remove don't care conditions for the aborted module


Set Up LEC Correctly for NEQs •

•

•

Turn on necessary options that are off by default o Options in set flatten model , such as clock gating o Mapping method options, such as phase mapping o Retiming Take advantage of synthesis generated files o Generate mapping files via change name when name correspondence is destroyed o Sequential merge information o Retiming state point information Properly constrain the design o Instance equivalence Pin constraints o

Debugging NEQs •

•

•

• •

Remove sequential elements that are not in loops from circuits by using remodel -seq2buf -all -both to see if the NEQs exist in the combinational logic When high numbers of NEQs are reported, make sure verification environment is properly setup o Missing top-level constraints (test mode vs. function mode) o Missing design files, library files Large number of unbalanced DFF and DLAT in golden and revised o set flatten mode –latch_fold is turned on? RTL elaboration differences LEC incomplete modeling

Ensure High Quality Mappin g • •

Avoid duplicate names for key points If percentage of name-based mapping is low, use: o Renaming rules to map key points with particular patterns change name report from synthesis if available to assist mapping o o o

SETUP> CHAnge NAme file_name [-Summary | -Verbose] [-Golden | -Revised | -Both] 



mapping involving multibit library cells without the default multibit naming convention Turn on phase mapping if necessary If unreachable key points need to be compared, first map the reachable keypoints, then turn on the -unreach option for set mapping method o

• •

This should be read in after reading the designs/libraries.

•

set multibit option for

Confirm mapping result o

report map point –method –summary


o

report unmap point -summary

Validate th e RTL Elaboratio n Results •

• •

When NEQs occur during RTL-netlist comparison o Generate a synthesis elaborated netlist so that multiple comparisons can be done o RTL vs. elaborated netlist Confirm or rule out RTL interpretation differences Elaborated netlist vs. netlist o Very likely, name-based mapping is ideal

Incomplete Modeling •

Check modeling messages to see if modeling options are correctly enabled or disabled with report message -modeling

•

•

• • •

When majority of the design is properly setup, invoke analyze noneq -verbose to see possible causes Correlate synthesis log with LEC modeling messages: o Use read setup information file_name -type RCLOG | DCLOG o Check missing sequential constants and constant values o Check missing and/or incorrect sequential merges Clock gating issues Check wire-resolution behavior Check for same number of cut points created to break feedback paths between golden and revised

Using Higher Effort for Modeling and Setup • • • •

Using set analyze option -auto -effort high for high effort automatic analyze setup Invoke analyze setup -verbose twice Invoke analyze setup –effort high after compare Use the -repeat option for the remodel command

Re-synthesis for Resolv ing NEQ • • •

Re-synthesize module without advanced optimizations Iteratively turn on each synthesis optimization Isolate the step which introduces NEQs

Loops and Cuts • •

Avoid combinational loops in the design, especially oscillating ones If combinational loops are due to IO pads, black-box the IO pads if they are instantiated in RTL and gates


•

• •

Use set flatten model -loop_as_dlat if the NEQ key points involving unbalanced number of DLATs and CUTs Use analyze setup -cut to fix the cut point positions Use abstract logic to abstract away state-holding loops

Checkli st fo r Debug ging NEQs

Check Items Use phase mapping when the mapping is successful and compare is NEQ Use renaming rules for verifying the synthesis flows that involve name changes Use analyze setup to automatically correct setup issues Use analyze noneq to determine the causes of the NEQs Use diagnose to debug specific compare points Make sure retiming modules are verified separately from the rest of the designs

Getting Help •

•

• •

Providing a testcase is the best way to help Conformal improve the capability and help you resolve the verification issues Saved sessions are limited in usefulness for debugging o Cannot view RTL files, resource files, netlist information, etc. o Cannot provide RTL recoding Review LEC Web Interface documents to see if any latest features can be applied Running LEC early and often and reporting LEC issues to Cadence early will provide us time to investigate and resolve them in a timely manner

Checkli st fo r Preparing Testcase

Check Items All the necessary design files to reproduce the problem LEC dofile and logfile LEC project directory Synthesis logfile, resourcefile and other report files


Use LEC New Features in the Dofile •

usage -auto

Automatically displays usage at the end of every command •

set project name

Automatically stores running information and extracts testcase •

set analyze option -analyze_renaming_rule

Report mapping renaming rule analysis during the flattening process •

write hier_compare dofile -balanced_extractions

Enable more modules to be compared in hierarchical compare

Conform al LEC Drop -In B eta Prog ram • • •

Best way to learn of upcoming features in LEC Help you deploy the latest features of LEC Contains standard dofiles that you can use as reference to exploit the latest features in LEC

Recomm ended Director y Layout design1/

•

libs/ rtl/ scripts/ sdc/ syn1/ fv/ outputs/ reports/ scripts/ wlec_rtl2g1_dofile wlec_g1tog2_dofile ... syn2/ ...

Each synthesis directory should contain: o The RTL Compiler generated verification directory fv/ o The intermediate and final netlists in outputs/ o LEC dofiles generated by write_do_lec

Ap pendi x: Ex ample Dof ile for RTL-to-Gate Verifi cati on // Set up log file, get misc info about the run set log file -replace usage -auto // Read in design and library read library -liberty -replace -both \ \ read design -verilog -replace -golden -noelaborate \ \ elaborate design -golden read design -verilog -replace -revised -noelaborate \ elaborate design -revised


report design data report black box // Setup design and LEC run uniquify -all -nolibrary // Specifying user renaming rules if needed to help mapping add renaming rules \ [-golden|-revised|-Both] // Specify user constraints for test/dft/etc add pin constraint 0 scan_en -golden/revised add ignore output scan_out -golden/revised // Specifying the modeling directives for constant optimization, // clockgating set flatten model -seq_constant set flatten model -gated_clock // Enable multi-threading set parallel options -threads 4 set analyze option -auto // Write hierarchical compare dofile write hier dofile -replace -usage -constraint -noexact \ -balanced_extractions -input_output_pin_equivalence \ -function_pin_mapping \ -prepend_string "report design data; \ analyze datapath -module -resourcefile -verbose; \ analyze datapath -verbose;" // Run hierarchical compare run hier

Ap pendi x: Ex ample Dof ile for Gate-to-Gate Verifi cati on // Set up log file, get misc info about the run set log file -replace usage -auto // Read in design and library read design -verilog -replace -golden -noelaborate \ \ elaborate design -golden read design -verilog -replace -revised -noelaborate \ \ elaborate design -revised // Setup design and LEC run // Specifying user renaming rules if needed to help mapping add renaming rules \ [-golden|-revised|-Both] //Specify user constraints for test/dft/etc add pin constraint 0 scan_en -golden/revised add ignore output scan_out -golden/revised // Enable multi-threading set parallel options -threads 4 set analyze option -auto set system mode lec // Compare add compare point -all compare

LEC Verification Guide

Recommend Documents