Synopsys Formality Flow

Cheatsheet Content

### Introduction to Formality Synopsys Formality is a **Formal Equivalence Checking (FEC)** tool used in ASIC design flow to verify that two different representations of a design have the same functionality. This is crucial after synthesis, place and route, or any design modification to ensure no unintended changes were introduced. **Key Use Cases:** - **RTL vs. Netlist:** Verifying the synthesized netlist is functionally equivalent to the original RTL code. - **Netlist vs. Netlist:** Verifying post-synthesis netlist against post-layout netlist, or verifying ECO (Engineering Change Order) changes. - **Gate-level vs. Gate-level:** Comparing different versions of gate-level netlists. ### Formality Flow Overview The typical Formality flow involves these main steps: 1. **Read Reference Design:** Load the "golden" or reference design (usually RTL). 2. **Read Revised Design:** Load the "implementation" or revised design (usually synthesized netlist). 3. **Map Design:** Establish correspondence between the reference and revised design elements. 4. **Set Up Equivalence:** Define comparison points and constraints. 5. **Verify Equivalence:** Run the formal verification engine. 6. **Analyze Results:** Interpret the verification report. ### Setup and Key Commands #### 1. Start Formality ```tcl formality -gui # For GUI mode formality -dc # For command-line mode integrated with Design Compiler ``` #### 2. Read Designs ```tcl # For Reference Design (RTL) read_hdl -sv {file1.sv file2.sv} # SystemVerilog read_hdl -v {file.v} # Verilog read_hdl -vhdl {file.vhd} # VHDL set_top_module # Specify top module # For Revised Design (Netlist) read_db # Synopsys DB format read_verilog # Verilog netlist set_top_module # Specify top module ``` #### 3. Set Up Global Options ```tcl set_fec_mode lec set_case_analysis_pins {TOP/pin_A TOP/pin_B} {0 1} # For specific pin states set_constant # Set constant value on a pin set_dont_care_ports {port_name1 port_name2} # Ignore specific ports set_undriven_signals_as_x # Treat undriven signals as unknown ``` #### 4. Map and Match ```tcl # Automatic mapping (usually sufficient) match # Manual mapping (if auto-match fails for specific points) add_compare_points add_black_box # Treat a module as a black box (e.g., SRAM) ``` #### 5. Verify Equivalence ```tcl verify_equivalence ``` #### 6. Analyze Results ```tcl report_unmatched_points report_unverified_points report_failing_points report_equivalent_points ``` #### 7. Debugging Mismatches If a mismatch occurs, Formality can generate a debug database and show discrepancy points in the GUI. ```tcl write_fec_debug_db ``` Use the GUI to trace the logic at the mismatch point. ### Key Concepts - **Reference Design (Golden):** The design version considered correct (e.g., RTL code). - **Revised Design (Implementation):** The design version being verified against the reference (e.g., synthesized netlist). - **Compare Points:** Internal signals or outputs that Formality compares between the two designs. By default, all primary outputs and blackbox outputs are compare points. - **Black Box:** A module whose internal logic is not verified by Formality. Its inputs and outputs are compared, but not its internal behavior. Used for IPs, memories, or unverified blocks. - **Don't Care (DC) Points:** Outputs or specific bits of outputs that are not functionally relevant and can be ignored during verification. Use `set_fec_dont_care_output_ports`. - **Equivalence Status:** - **Equivalent:** Functionally identical. - **Not Equivalent:** Functional mismatch detected. - **Undetermined:** Formality could not conclusively prove equivalence or non-equivalence (e.g., due to complexity, black boxes, or unmapped points). - **Mapping:** The process of identifying corresponding logic cones and registers between the reference and revised designs. - **Case Analysis:** Setting specific input pins or internal signals to constant values (0 or 1) to simplify verification for certain modes or conditions. ### Common Issues and Troubleshooting | Issue | Possible Cause | Solution | | :---------------------------------- | :----------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Undetermined Points** | Unmapped points, deep logic, black boxes | - Ensure all relevant modules are read and mapped. - Add explicit compare points if auto-mapping fails. - Check for black boxes; if a black box is intended, ensure its I/O are correctly matched. - Increase verification effort using `set_verification_effort high`. - Check for `set_undriven_signals_as_x` usage. | | **Not Equivalent Points (Mismatch)** | Real design bug, synthesis issue, incorrect constraints | - This usually indicates a functional difference. - Use the GUI to trace the failing point. - Check for `set_case_analysis_pins` or `set_constant` that might be masking a real issue or are incorrectly applied. - Review synthesis options (e.g., constant propagation, register re-timing). - Ensure correct handling of X-propagation. | | **Unmapped Points** | Missing design files, naming mismatches, hierarchy diffs | - Verify all HDL/netlist files are read. - Check for instantiation name changes between RTL and netlist. - Use `set_flatten_model` if hierarchy is significantly modified. - Use `set_attribute_map` for name mapping if necessary. | | **Long Runtime/Memory Issues** | Large design, complex logic, high effort | - Try `set_verification_effort medium` or `low`. - Use black boxing for known good IP blocks. - Simplify the design by setting constant inputs or using `set_dont_care_ports`. - Run in incremental mode if supported. | ### Best Practices - **Consistent Naming:** Maintain consistent naming conventions between RTL and netlist to aid automatic mapping. - **Top-Down Approach:** Start with top-level verification, then debug down to specific modules if mismatches occur. - **Incremental Verification:** For large designs or ECOs, verify changes incrementally. - **Review Warnings:** Always check Formality warnings; they often indicate potential issues that could lead to undetermined points or mismatches. - **Version Control:** Ensure the correct versions of RTL and netlist are being compared. - **Script Everything:** Automate the Formality run using TCL scripts for consistency and reproducibility.