Conformal_Verification_Guide_8.1

I N VE N TI V ECONFIDENTIALFormal Verification GuidePrototype | Implement | VerifyAgenda• Equivalence Checking Refresh • Verification Guide– RTL Design – Verifiable Synthesis Flow – Abort Resolution• ECO Automation • Best Practice Recommendation2August 6, 2009Cadence ConfidentialEncounter Conformal Product FamilyVerifies 100% of design functionality without requiring test vectors Provides independent verification for lowest risk silicon Validates CPF LP Equivalence Checking Verifies Low Power design implementation Performs structural and functional checksEquivalence CheckingRTL or Gate RTL or GateDigital Custom Verification including Memories, Data Paths, and IO Orders of magnitude faster than simulationLow Power VerificationFunctional Checksv1v2ISOABFinds bugs earlier in the design cycle Verifies proper CDC synchronization to avoid clock related re-spins Creates safer EC environmentValidation, generation and analysis of constraints Uses industry proven formal engines Shorter design cycle with improved timing constraintsConstraint DesignECO Implementationo1 o2Provides automated RTL2GDS ECO solution Identifies and generates fix to implement ECO Interfaces with physical implementation tool flow3August 6, 2009Cadence ConfidentialEncounter Conformal & FED Product FamilyEquivalence CheckingRTL or Gate RTL or GateConstraint DesignLow Power VerificationFunctional ChecksAValidation, generation & analysis of constraints Shorter design cycles with improved timing constraintsv 1v2ISOB100% Independent vector-less verification of implementation RTL Gate Transistor CDC & Ext ChecksStructural and functional LP checks LP design implementation Verification LP Equivalence CheckingNew Products ECO Implementation RC-Physical Synthesis Chip Planning Systemso 1 o 2Automated RTL2GDS ECO solution Identifies and generates ECO fix Physical Correlation & Predictability with final backend Congestion Analysis & Opto (Congestion Relief) Architectural & Economic Forecasting Lower IC Cost & Expedite TTM4August 6, 2009Cadence ConfidentialI N VE N TI V ECONFIDENTIALCrash Course on Equivalency CheckingPrototype | Implement | VerifyEquivalence Checking FlowGolden Design Standard Library Revised DesignSpecify Constraints and Design ModelingSetup Mode LEC ModeSpecify Compare ParametersCompare DesignsMiscompare?yesDiagnosenoEquivalence Checking Complete6August 6, 2009Cadence ConfidentialMapping! What is that?Pairing corresponding golden and revised key points:G RPI PO DFF DLAT BBOX CUT Z EPI PO DFF DLAT BBOX CUT Z E Key points Combinatorial logicGolden RevisedE UExtra Points Unreachable Points Unmapped Points7August 6, 2009Cadence ConfidentialComparison– Only mapped points can be compared. – Comparison is an iterative process.• Conformal remembers points already compared. • Comparison can be interrupted with Control-c. • Enter compare to continue comparing.set log file logfile.$LEC_VERSION -replace add notranslate module *sram* -library -both read design cpu_rtl.v -verilog -golden read design -file verilog.vc -verilog -revised // Command:pin constraint 0 scan_en -revised add compare ================================================================================ set flatten model -latch_fold Compared points PO DFF DLAT BBOX Total add renaming rule rule0 "abc" "xyz" -map -revised -------------------------------------------------------------------------------Equivalent renaming rule rule1 "xyz" "C" -map -golden 2 146 2 1 151 add -------------------------------------------------------------------------------set system mode lec Non-equivalent 0 2 0 0 2 add compare points -all ================================================================================ compare ...8August 6, 2009Cadence ConfidentialUsing the Mapping Manager to Debug NEQsMain windowUnmapped pointsMapped pointsCompared points9August 6, 2009Cadence ConfidentialCategories of Comparison ResultsEquivalent: Key points proven to be equivalent (green-filledcircle)Inverted-Equivalent: Key points proven to be complementary (divided green-filled circle) Nonequivalent: Key points proven to be different (red-filled circle) Abort: Key points not yet proven equivalent or nonequivalent due to timeout or other system parameters (yellow-filled circle) Not-Compared: Key points not yet compared?10LEC> report compare data -class [...]August 6, 2009Cadence ConfidentialI NVENTIVE CONFIDENTIAL RTL DesignFor Ease of VerificationRTL Design For Ease of Verification•To highlight the impact of RTL design on verification –Useful for RTL designers to understand their impact of coding styles on verification–Useful guidelines for machine/script generated RTL codes •Factors in RTL designs that can affect the ease of verifications are–Don’t care conditions in RTL description–Structuring of logics–Partitioning of designsRTL Design For Ease of VerificationDon’t-Cares Conditions in RTL•Don’t-care conditions are created in RTL by–X assignments–Incomplete case–Out-of-range indexing–Range constraint (VHDL)• A don’t-care condition can be synthesized to– a constant (zero or one)–or any Boolean function•Designs with extensive don’t-care conditions can be difficult to verify •Use LEC “report design data”to report don’t cares•Use LEC “report rule checks”to report out-of-range indexingRTL Rule Checkers•LEC’s RTL rule checker provides an fast and easy way to detect RTL coding styles that can impact verification •For example, index out of range is reported as –// Warning: (RTL7.3) Array index in RHS might be out of range (occurrence:1)•Running LEC RTL rule checker early in the RTL design process can reduce many potential synthesis andverification issues later onRTL Rule CheckersSETUP> read design –golden rtl.vSETUP> read design –revised rtl.vSETUP> set system mode lecSETUP> report rule check –golden –design –verbose > lint.rptSETUP> report message –golden –model –verbose > model.rpt•Consider Synthesis and EC ramifications of design –Multiply-driven and floating nets–Combinational cycles–Assignment size mismatch–Ambiguities leading to simulation mismatches–EtcRTL Design For Ease of VerificationDon’t-Cares Due to Index Out of Range•Don’t care is created when index is out of range –When the index can address more locations thanwhat an array can hold•For examplereg[4:0] q; // q has 5 locationsReg[2:0] A; // A can index 8 locationsBAD -q[A];// (1) out-of-range conditionGOOD -q[(A> 4) ? 0: A)];// (2) No out-of-rangeLogic Structuring•Structural Similarity–How closely does RTL structure match the netlist •Designs with higher structural similarity between RTL and netlist are easier to verify•Synthesis can restructure code. For examples:–Resource sharing–Map unsigned operators to signed operators•Minimize structural differences between RTL and netlist by:–Using Verilog 2K to code signed arithmetics–Using explicit grouping (such as in additions) with parenthesis –Manually code resource sharingDesign Partitioning•Partitioning a complex block breaks it into smaller pieces for ease of verification•Guidelines–Keep high complexity design modules small in size–Avoid excessive logic cone depth–Separate datapath block (especially those requiring retiming) from control block–Partitioning may impact QOR so the tradeoffs should be explored early in the design cycle•Smaller blocks are easier to verify. Well partitioned designs can also make use of more techniques to ease verificationsI NVENTIVE CONFIDENTIAL Verifiable Synthesis FlowModule Data PathArchitecture & Advanced Synthesis Optimizations Create Verification Challenges DatapathArchitectureBoundary OptimizationPhase Inversion Resource Sharing• A synthesis flow with verification considerations can significantly reduce verification challenges–Enable the identification of synthesis bugs more easily–Allow use of more LEC features (e.g., module-based datapath analysis, hierarchical comparisons) to streamline the verification processL E CSynthesis Optimization on Datapath Modules•Synthesis tools like RC and DC can group several datapath operators into asingle datapath unit which called datapath module. These modules can be synthetic or they can be instantiated components such as DW modules•For Design Compiler, these modules are reported in the resource report with string DP_OP as naming convention•These modules boundary are not preserved if ungrouping and boundary optimization are applied, making them difficult to prove Synthesis Flow Needs To Be Verification-Friendly R T L D a t a p a t h D e si g n ungroup/boundary optimizationMulti-Stage Synthesis•The basic principle of ensuring ease of verification is to break difficult to verify synthesis optimizations intostages in the synthesis flow•Recommend synthesis stages–RTL to first mapped netlist•Enable: datapath synthesis•Disable: ungrouping, boundary optimizations, phase inversions –Mapped netlist to optimized mapped•Enable: Ungrouping, Incremental optimizations, boundaryoptimizationsEmbed Verification Requirements in Synthesis •To deploy an easy to verify synthesis flow, embed the verificationsinto the synthesis scripts–Instead of resynthesizing after running into verification challenges •Control synthesis options that impact verification, e.g.,–Range constraint–Datapath synthesis, resource sharing–Ungrouping, boundary optimizations•Allow for a range of verification requirements to allow for trade-offs in verifiability•This is default behavior for Encounter RTL Compiler (RC)LEC Feature Module Based Datapath (MDP) Analysis (DC Synthesis)•Datapath synthesis may cause aborts because of operator optimization.•This is handled in RTL Compiler with Netlist Verification (more later). DC netlists require MDP.•Module-Based Datapath (MDP) Analysis performs datapath abstraction at a module level•This analysis is performed in addition to and prior to the regular operator level analysis•The result goal is to improve the quality of the operator-level analysis•Requires the preservation of synthetic datapath modules during synthesisRTLRTLFinal GateDC Script LE C DC Script Original Flow New Flow RTL FinalGate DC + MDP Script Intermediate Gate L E C LE C •Include MDP Script •Output Intermediate &Final Netlist•Perform RTL2Gate•Perform Gate2Gate Improve Synthesis Script to Ensure Verification Success (MDP) Analysis (DC Synthesis)DC Synthesis Script to Enable MDP Analysis•To enable the successful verification of datapath design using Design Compiler synthesis, LEC provides a script to ensure that LEC’s Module-Based Datapath (MDP) Analysis can be effectively applied•The script can be embedded into the overall synthesis script as followssource <lec_release_path>/share/cfm/lec/scripts/mdp.tcl…compile_ultra_mdp<level> <design_module>compile_ultra……<continue original DC synthesis script commands>…•compile_ultra_mdp command is placed before the first compile_ultra command in the DC script•Design module is the name of the top module that is synthesizedDC Synthesis Script for Datapath Verification •MDP level can be 1, 2, 3, or 4, and affects the synthesis as followsMDP Level Preserve Hierarchy ofBoundaryOptimizationSequentialOutputInversion DP/DW Design1YES NO ALLOW ALLOW 2YES NO DISABLE ALLOW 3YES NO DISABLE DISABLE 4YES YES DISABLE DISABLECollecting DC Synthesis Data•During the synthesis process, the following information should be collected for verification–Datapath Resource File: This is required to ensure that datapath intensive design can be easily verified–Change Name File: This is required to ensure name-based mapping for ease of verification–VSDC File: This file contains information that can help to guide the setup of the verification–Synthesis log file: This can contain information to help guide the setup of the verificationLEC Feature Qualifying Your DC Synthesis Environments •New versions of synthesis tools may introduce new verificationrequirements–New optimization techniques (e.g., sequential constant groups)–New datapath structures (e.g., new multiplier architectures)–New technology mapping techniques (e.g., using multi-bit library cells)–Changes in naming conventions (e.g., in generate statements)–Changes in default synthesis option settings (e.g., having sequential merge optimizations ON by default)•LEC ships with IP-free designs that can be used as testcases in a new synthesis environment or tool–Enable users to provide early feedbacks to the Conformal team to ensure success of verifications in the latest synthesis environment –At $conformal_dir/share/cfm/lec/demo/*How to Determine QoR ImpactRTL RTLFinalGate DC ScriptL E CDCScriptOriginal FlowNew FlowRTLRTLFinalGateDC ScriptDC + MDPScriptIntermediateGate L ECL E CQoR ImpactRC Netlist Verification Flow• RC verification flow– Only one intermediate netlist between RTL code and the final netlist – Two LEC comparisons: RTL-to-Intermediate & Intermediate-toFinal – Better support of advanced (datapath) optimizations – LEC-friendly netlist by 'write_hdl –lec’• additional datapath info (as comments) about architecture changes31August 6, 2009Cadence ConfidentialRC Netlist Verification Flow•Synthesize with no ungrouping •Output Intermediate & Final Netlist •Perform RTL2Gate •Perform Gate2GateNew Flowwrite_hdl -lecRTLFinal GateEC LIntermediate GateEC LIntermediate netlist to Ensure Verification Success32August 6, 2009Cadence ConfidentialRC Netlist Verification Flow for Datapathread_hdl elaborate read_sdcFirst netlist generated with “-lec” optionsynthesize -to_mapped write_hdl -lec > intermediate.v write_do_lec -revised intermediate.v > rtl2map.do [ungroup in any way] <no more datapath architecture change> Do not ungroup before first netlistsynthesize -incr as many times as wished without “-lec” option; write_hdl > final.v write_do_lec -golden intermediate.v -revised final.v > map2final.do exit Every “write_hdl” followed by “write_do_lec”33August 6, 2009Cadence ConfidentialRC Netlist Verification Flow for Datapath• First LEC run (RTL-gate):read design <RTL_code> -golden read design intermediate.v -revised compare – write_do_lec generates a hierarchical dofile script (rtl2map.do) – Conformal dofile script will contain the following commands: analyze datapath –module –verbose analyze datapath -verbose• Second LEC run (gate-gate):read design intermediate.v -golden read design final.v -revised compare – write_do_lec generates a flat dofile script (map2final.do)34August 6, 2009Cadence ConfidentialSummary• When a design is complex and contains many datapath operators, with today’s advance synthesis optimizations, the datapath become structurally different between RTL and netlist, creating challenge to all verification tools • To effectively help Conformal datapath analysis quality and improve verification result, an integrated synthesis & verification flow is needed • DC MDP Analysis and the recommended synthesis script will help close the gap between datapath synthesis and verification • RC Netlist Verification flow reduces the chance of aborts for a more complete verification35August 6, 2009Cadence ConfidentialI N VE N TI V ECONFIDENTIALAbort ResolutionResolving Aborts• Abort is reported when formal (exhaustive) analysis cannot provide a complete proof of equivalence within a resource limit– The design has been partially verified since no input vector resulting in non-equivalence has been found either• Resource limit is adjusted by compare effort– SET COMPARE EFFORT <LOW|MED|HIGH|COMPLETE>• This section describes– Techniques to resolve aborts – Methods to isolate abort to better understand the aborted region and options for further verifications37August 6, 2009Cadence ConfidentialResolving AbortsReview Synthesis Flow• Abort can be avoided by following the guidelines given earlier • For datapath intensive design– Check that MDP level 4 has been used for DC synthesis – Use Netlist Verification Flow for RC synthesis• RTL design for ease of verification– Check for excessive don’t care conditions with LEC’s rule checker and design report• Partition the design well and use LEC’s hierarchical comparison– Check that all complex modules can be hierarchically compared38August 6, 2009Cadence ConfidentialResolving AbortsReview LEC Dofiles• Hierarchical Comparison– Check that hierarchical comparison is used – For module containing abort, check that it has no submodules that can be further hierarchically compared• For datapath intensive design– Check that MDP has been used (Analyze datapath –module) – Check that datapath analysis are successful• Abort Analysis– Check that LEC’s abort analysis has been used (analyze abort)• Multithreading– Check that multithreading is used for abort analysis39August 6, 2009Cadence ConfidentialResolving AbortsAdvanced LEC Techniques• Several advanced techniques are available to resolve aborts • Advanced options for ‘analyze datapath’– – – – -wordlevel -share -effort high -addertree• Advanced commands and techniques– run partition_compare (help run partition_compare –verbose) – add partition points – read design –norangeconstraint –vhdl40August 6, 2009Cadence ConfidentialRe-synthesis and RTL Recoding•Re-synthesis of problem blocks–Adjust effort level–Disable range constraints–Preserve key signals and boundaries •Pros–Makes verification easy for all future runs •Cons–Requires additional efforts, may impact qualityAbort Isolation•When aborts cannot be completely resolved, it is useful to identify the region where aborts occurred–Allow for a more targeted re-synthesis–Allow for a better understanding on the netlist that leads to abort –Allow for additional verification to these smaller regions •Techniques to isolate abort–Ensure that the modules are hierarchically compared•Easier if RTL is partitioned well–In MDP analysis flow, abstracted datapath cluster can be automatically isolatedAbort Isolation for Datapath Module •When using MDP analysis, LEC can isolate the datapathmodule that causes the abort so that the remaining non-aborting netlist can be verified–That is, if the remaining netlist is equivalent and the datapath module is also equivalent, then the entire netlist is equivalent •Provides more visibility into the region of abort –Instead of reporting all fanout keypoints from the datapath module as abort, only the datapath module is reported as abort(See next slide)•The is invoked as–ANALYZE DATAPATH –isolate_abort_module…Abort Isolation for Datapath Module •Results with abort:==============================================================Compared points PO Total--------------------------------------------------------------Abort 67 67==============================================================•Results with abort isolation:==============================================================Compared points PO Total--------------------------------------------------------------Equivalent 67 67==============================================================Compared results of isolated instances in Revised design (top)==============================================================Status Instance (Module)--------------------------------------------------------------Abort i5/add_123_S1_DP_OP_123_456(NV_GR_PE_STRI_core_add_123_S1_DP_OP_123_456) ==============================================================Multi-Threading•For machines with multi-core CPUs–No need to set up the parallel processing environment–Takes advantage of multi-core, multi-CPU machines •Parallel ComparisonLEC> compare –threads #•Best for large gate-to-gate comparisons, where the comparison canbe distributed to multiple comparison threadsLEC> analyze abort –compare –threads #•Best for RTL-to-gate comparison aborts, where a few keypoints canconsume a large portion of the runtime*Obsoletes the previous method of parallel comparisons using the command Run Parallel Compare•Support two new multiplier architectures •Improve divider architecture analysis•Support higher effort analysis for better datapath learning quality.Results from sample testcasesRadix-8Unsigned DividerHigh Effort AnalysisDatapath AnalysisI NVENTIVE CONFIDENTIAL ECO AutomationPrototype | Implement | VerifyECO ChallengesNomenclature•Engineering Change Order (ECO) is the process of making local changes to the design netlist without re-running the entire synthesis and P&R flow•ECO Types–Functional ECO•Changes the functionality of the design–Non-functional ECO•Fix timing, cross talk, DRV, routing violations with minimal effort•ECO Stages–Pre-Mask ( Pre tape-out) ECO•Uses normal logic gates to implement change–Post-Mask (Metal-only ECO)•Uses spare gates only to implement changeECO ChallengesManual Task•Current ECO flows are manual–Process is very time and resource consuming–Error Prone–Limited by ECO size•Very difficult to identify location of needed fix–Easy to modify RTL, yet difficult to transfer fix to gate netlist•Manual ECO changes do not easily incorporate use of –Spare gates, location, timing, routing access–Freed cells (used originally but not used in ECO patch)•Hard to manually optimize the eco patchECO ChallengesManual Flow Targeting Post Mask ECOSynthesisNew RTL (R2)Old RTL (R1)Old Netlist (G1)Final Netlist (New DEF)ECO Route/DRV/SIOld DEFP&RManual EditingTest InsertionNew Netlist(G2)ECECDelete/add connections Map to spare gatesDifficult to identify where to fix!Which logic cones are affected?P&RWhat type/many spare cells are available and how can I optimally map new gates to them?Use limited Metal Layers!How can I get the smallest possible change?Create ECO CmdWill this ECO meet timing, is it DRC clean?ORB a c k -e n d EC Or o n t -e n d E C ORepeat process for each ECO。