Complexity = Time or Memory Blowup Two ways to see complexity Tool crash (hopefully won’t happen) Compare Points reported as ‘Abort’ What does this mean? Logic was too complex to analyze Maybe bad options selected
Tool Solutions Some tool options can help resolve set compare effort high|ultra|complete –Causes LEC to work harder before giving up analyze datapath [-merge] | analyze multiplier –LEC looks for common datapath structures –Useful if lots of arithmetic operations –Specialized alg if you have a multiplier compare -single –Slow, but concentrates on each point standalone analyze abort New feature to look at abort point & try to ID good tool options Sloooow though (can run overnight, or abort too!)
Tool Capacity Issues Monitor LEC process for memory blowup May be root cause of abort or seg fault Look for options for run on hi-mem server Memory blowup is known FV hazard If you were close, this may be just enough Also try new “compare –parallel” Uses multiple machines on network May improve memory & runtime
Design Issues: Memories Memories are complex Usually bbox a memory, verify standalone Conformal supplies special library –LEC is easy with ‘verplex memory primitives’ –Otherwise extremely hard How are memories FEVed? Inherently transistor-based, not simple gates Need to define common structures for tool
Design Issues: Don’t Cares Don’t-Care (DC) Space Remember, a DC is an RTL ambiguity –Synthesis has freedom to decide Large DC space makes verification hard –If DCs cause aborts, consider assigning all values How to diagnose? Look for this compile message –F34: Convert X assignment(s) as don't care(s) –report messages -rule F34 –verbose for exact lines Experiment: set x conversion 0 –gold –Ambiguous (X) cases = 0 false negatives –But experiment useful to see if DCs did cause aborts
Hierarchy Example Simple option: FEV full TOP design Best option if feasible
Hierarchy Example Hierarchical: 3 FEV comparisons TOP.Green, Top.Yellow TOP with Green and Yellow bboxed Are there problems with this approach?
Hierarchy Problem: Constraints Circuit topology constraints for bboxes What constraints needed in this example?
Hierarchy Problem: Constraints Circuit topology constraints for bboxes What constraints needed in this example? Green: add pin eq a b Yellow: add pin constraint 0 c TOP: add pin constraint 0 Yellow.d
Hierarchy In Conformal write hier dofile –constraint Odd but convenient command IDs common hierarchies Writes new dofile, verifying all pieces Generates summary report at end Tricky when debugging! Need to rerun on hierarchy with error
Generated dofile: excerpts set root module top add pin constraint 0 yellow.d -both set sys mode lec compare report hier_compare data … set root module green add pin eq a b –both …
Challenges of Hierarchical FEV Synthesis tools can flatten hierarchy May make hierarchical FEV impossible May need to request backend preserve some hierarchy Mismatching submodule interfaces Extra pins inserted in synthesis Pin name changes May need to use Conformal commands to ignore/map pins
Hierarchy Special Case: Cell Libraries Should use pre-FEVed library No sense in repeatedly verifying basic flops, latches, ANDs, ORs, etc Be sure lib team is doing low-level FEV! Check that this is the case Should have.v (or.lib) file defining each cell You should see simple behavioral RTL for cells, not full transistor-level logic clk) q<=d
What is a cut point? Verifying big logic cone may be hard Harder in low-frequency designs Divide logic at points other than states? Hard– synthesis only requires state matching But often some internals correspond too In extreme cases, recode RTL to enable Cut point = non-state to treat as key point Map & verify just like latches/flops Reduces logic cones being analyzed
Cut Point Example add cut point p1 –gold add cut point p2 –rev add ren rule r1 p1 p2 -gold
Cut Point Problems? Is p1 still a useful cut point?
Cut Point Problems? Is p1 still a useful cut point? Maybe…
Cut Point Problems? Is p1 still a useful cut point? Maybe… Don’t forget about constraint issues too
What is Case Splitting? FV is analyzes all cases together Good tool engines may be smarter What if small inputs activate/deactivate lots of logic? Example: mode bits Constrain appropriate pins to 1 or 0 Then compare twice Or constrain bits, then 2^n compares
Case Splitting Example Suppose compare of f2 & f4 Aborts, and we want to case-split on f1/f3.
Compare Case #1 First assign const of 0 to flop.
Compare Case #2 Then assign const value of 1. After both cases pass, we are equivalent!
Case splitting in Conformal Conformal terminology: “partition” Convenient commands add partition key_point write partition dofile Be careful! partition points 2^n iterations Poorly chosen points worse than useless!
Simulation Obvious, defeats point of formal! But may be useful last resort If small handful of points defying FEV Be sure you exhausted FEV options! All tool compare/analyze options? Did you try hierarchical verify? Did you try cut points & case splitting? Did you consider recoding RTL to increase cut points and/or hierarchy, or reduce don’t- care space?
Simulation compare in LEC compare –random Runs simulation vectors Should only run on specific problem points Not a good solution But better than nothing Probably will get more vectors than GLS –Fast simulation only on problem cone