formality: Formal verification process

blog.csdn.net/m0_61544122/article/details/127068317

The formality tool is used to verify whether the logic function has changed during the
design and development process, regardless of layout and timing, and can be used as a
substitute for dynamic simulation. Restricted by the design scale, the simulation time is
related to the number of input vectors, while formal verification does not require input
vectors.

1. Formality usage scenarios

After synthesis: compare the rtl netlist with the gate-level netlist, and compare before and
after inserting dft.

After back-end design: Use the integrated netlist to compare with the netlist after back-
end layout and routing, and compare before and after eco .

1/9
There are two concepts here, reference design and implement design, the former as a
reference design and the latter as a modified design.

2.formality verification process

formality supports two working environments, formality shell and formality GUI.

2.1 formality GUI

1) Load Guidance

Add the svf file (the file that records the synthesis optimization process). If you compare
the synthesis with the back-end netlist, or the back-end eco netlist, the svf file is generally
not needed.

2) Load Design

Read the reference design and implement design, and related timing library files, and
then link.

read design file > verlog > load files

2/9
To read db files, read DB libraries> DB> load files

Set top cell name and link design, set top design > set top

3/9
Adding an implement design process is similar to the reference design process.

4/9
3) Performing Setup

After reading the design, you need to set the formal verification environment. For
example, after inserting dft , you don’t need to consider scan mode/test mode
(corresponding to set_case_analysis in sdc) when doing function verification, or for
artificially created ports, you need to set a constant for these ports to tell the tool not to
check. In addition, various set_app_vars that use tcl scripts to run fm_shell are set in
"TCL Variables".

5/9
4) Matching Compare Points

Check whether the comparison points of reference design and Implementation design
match: match>run matching

6/9
The occurrence of unmatched points will not always lead to verification failure. For
example, inserting an antenna cell will also generate unmatched points, so the match step
is usually skipped when running formality (depending on personal habits).

5) Verifing the Design and Interpreting Results

Verify whether the function is consistent, verify> verify

"Verification succeeded!" means success, if there is a failure, you need to go to the next
step, debug.

6) Debugging Verification

If the functions are inconsistent, use the debug function for analysis.

7/9
When debugging, you will encounter a definition of logic cone. Logic cones refer to all the
combinatorial logic in the middle of going back from one design object to another design
object.

The starting point of logic cones is the compare point in formality:

primary outputs, internal registers, black box input pins, or nets driven by multiple
drivers where at least one driver is a port or blackbox。

The termination points of the logic cones are:

primary inputs or compare points。

2.2 formality shell

Instruction: fm_shell -f formality.tcl

set_app_var verification_clock_gate_hold_mode any

#Allow implementation design to optimize and add new icg (both active at high level
and active at low level), if set_app_var verification_clock_gate_edge_analysis true,
set_app_var verification_clock_gate_hold any will be invalid.

set_svf xx.svf

#Comprehensive process file, if you compare the netlist after inserting dft with the
original netlist, you need to add the svf file.

set synopsys_auto_setup true

#The undriven will be set to the X attribute , and set_dont_verify_point {r: xx} can be set
for points that are not checked. For example, the attribute of some pins is inout, which
cannot be checked.

read_db {

8/9
std.db \

mem.db \

read_sverilog -r $gloden_verilog

set_top r:/WORK/$top_cell_name

read_s verilog -r $imp_verilog

set_top i:/WORK/$top_cell_name

set_constant r: /WORK/top_cell_name/atpg_mode 0 -type port

set_constant i: /WORK/top_cell_name/atpg_mode 0 -type port

set_constant I:/WORK/top_cell_name/PEN_VDD_OPT 0 -type port

#Here, set_constant is made for scanmode-related ports, because the logic of scan does
not analyze, and set constant is made for an opt net because this net and the
corresponding port are created by pr itself, and there is no original netlist, so
Set_constant only in imp.v.

match

verify

analyze_points -failing

9/9