Day 1 Agenda

DAY 1 Introduction to Formality

1
2 Getting Started with Formality

3 Basic Formality Flow

4 Reading Designs

5 Matching

6 Verification

Formality 2005.09 1- 1
Unit Objective

After completing this unit, you should be able to:

 Describe:
 What Formality does

 Where it fits in your design flow

 Explain the key concepts of equivalence checking

 Logic Cones

 Compare Points

 Define Formality terminology

 Containers

 Reference and Implementation Designs

 Matching, Verification and Debug

Formality 2005.09 1- 2
Formality is an Equivalence Checker

 Assumes that the reference design is good

 Determines if the implementation design is functionally equivalent

 Is mathematically exhaustive, no missing corner cases

 Does not require test vectors

Reference Functionally Implementation

Equivalent?
Design Design
module top (…); ?
always @ (posedge clk)
.
.
.
endmodule

Formality 2005.09 1- 3
4
Synopsys Smart Verification

VCS Magellan
RTL LEDA • LEDA – RTL Checker
VCS MX Vera

• VCS – Verilog Simulation DC/PC

• VCS MX – VHDL Simulation
• Vera – Testbench Automation
• Magellan – Property/Model Checking
PC/Astro

Timing ®
PrimeTime Functional
Formality®
Regressions
Static Timing Analysis Regressions
Equivalence Checking

ECO

SignOff

Formality 2005.09 1- 4
6
Formality® Equivalence Checker
Verifies Functionality Throughout Entire Flow

RTL
RTL Coding
Ambiguities Synthesis
Scan
BIST
JTAG

Design Flow Problems Floorplanning

Formality®
Placement Equivalence Checking

CTS
IPO
Route
ECO
Manually Generated
Bad Logic Signoff Netlist

Formality 2005.09 1- 5
7
Formality® in Your Verification Flow

RTL
RTL RTL to gate (handoff)
Simulation Check chip integration
Final verification (setup)

Gate to gate
Formality
Most common application
Faster verification
Faster debugging
Isolates errors as they occur
Formality
RTL to gate (tape out)
Final verification
Formality ECO verification

Formality
Formality 2005.09 1- 6
8
What Formality® Is Not

 Formality is not a simulator (like VCS or VCS MX)

 It does not validate that your RTL functions correctly

 Formality is not a testbench generator (like Vera)

 It does not generate testbenches

 Formality is not a model checker (like Magellan)

 It does not validate protocols such as ‘a request is
always acknowledgd within two clock cycles’

 Formality is not a timing analyzer (like PrimeTime)

 Formality considers “static” responses
 Formality does not check for timing hazards

Formality 2005.09 1- 7
10
Two Key Concepts

A design contains Logic Cones and Compare Points

 Compare Point
 A primary output of a circuit
 A registers within a circuit
 An input to a black boxes within circuit

 Logic Cone
 A block of combinational logic which drives a compare
point

Formality 2005.09 1- 8
12
Two Key Concepts - schematic

A design contains Logic Cones and Compare Points

Compare Point

Logic
Cone
BB
BB

Inputs Compare Points

• Outputs from Registers • Inputs to Registers

• Primary Input Ports • Primary Output Ports
• Outputs from Black Boxes • Inputs to Black Boxes

Formality 2005.09 1- 9
13
Breaking Design Into Cones and Points

 Breaks the two logic circuits up into logic cones:

 End points (compare points) are primary outputs,
registers, and black box inputs

D Q
BB

Determining Compare Points

Formality 2005.09 1- 10
15
Match Compare Points

 Compare points are then aligned:

 This process is called “compare point matching”
 End points of logic cones (compare points) are primary
outputs, registers, and black box inputs
Reference Design
D Q
BB

CP
CP CP

D Q
BB

Implementation Design
Formality 2005.09 1- 11
17
Verify Design

 For each matched pair of compare points Formality tries to :

Either
 Confirms same response for all possible input combinations.
 Marks point as “passed”

Or
 Finds a “counter example” that shows different response
 Marks point as “failed”

 This analysis is performed by solvers

 Formality deploys many different solvers
 Each solver uses a different algorithm to prove equivalence /
non-equivalence

Formality 2005.09 1- 12
19
Formality Flow Overview

Formality® Equivalence Checker

REF
READ : Load Reference Design
IMP

LIB READ : Load Implementation Design

MATCH : Match Compare Points

(first break into cones & compare points)

VERIFY : Verify functional equivalence

Yes

DEBUG : GUI, Reports Pass? Done!

No

Cause?

Formality 2005.09 1- 13
20
Formality Terminology - 1

 Reference Design
 The “golden” design under test
 Implementation Design
 The modified design under test that is to be checked against
the reference design

 Containers
 Entity which stores all elements of a design to be tested
 Default reference container is named “r”
 Default implementation container is named “i”
 You can create other containers and use as reference or
implementation

Formality 2005.09 1- 14
21
Formality Terminology - 2

 Matching
 Process of aligning compare points between two designs

 Verification
 Process of proving / disproving that compare points are
equivalent (have same functionality)

 Debug
 Designer investigation of a failing verification to identify
why compare point(s) have failed verification

Formality 2005.09 1- 15
22
Summary

 Formality is an equivalence checker

 Formality can be used throughout the design flow
 From RTL to gates
 Whenever design is modified
 The key concepts of equivalence checking are:
 Compare Points
 Logic Cones
 Key Formality terms are:
 Containers
 Reference and Implementation Designs
 Matching, Verification and Debug
Formality 2005.09 1- 16
23
Quiz

1. What type of verification does Formality perform?

2. Give an example where you would use Formality but not Magellan?
3. Give an example where you would use Magellan, but not Formality?
4. Name the three types of object that can be a compare point?
5. What is a logic cone?
6. What happens during the process of matching a design?
7. What happens during the process of verifying a design?
8. You simulate your RTL with VCS, and compile to gates with DC.
Would you make the gates or RTL the reference design?
9. What is a container?
10. What are the names of the default containers?

Formality 2005.09 1- 17
24
Day 1 Agenda

DAY 1 Introduction to Formality

1
2 Getting Started with Formality

3 Basic Formality Flow

4 Reading Designs

5 Matching

6 Verification

Formality 2005.09 2- 1
Unit Objectives

After completing this unit, you should be able to:

 Invoke Formality – both shell and GUI
 Launch GUI from within the shell
 Modify setup files
 Create log files
 List Formality commands and variables
 Display syntax for commands and variables
 Display detailed explanations of commands
and variables
Formality 2005.09 2- 2
Invoking Formality: fm_shell

To invoke the Formality shell type fm_shell:

<3> % fm_shell

Formality (R)
Version X-2005.09 – Aug 10, 2005
Copyright (c) 1988-2005 by Synopsys, Inc.
ALL RIGHTS RESERVED

This program is proprietary and confidential information of

Synopsys, Inc. and may be used and disclosed only as authorized in
a license agreement controlling such use and disclosure.

Loading db file '/sw/formality/X-2005.09/libraries/syn/gtech.db’

fm_shell (setup)>

Redirect output to a file

<4> % fm_shell | tee data.log

Formality 2005.09 2- 3
4
Invoking Formality: GUI

To invoke the Formality GUI, type formality:

<2> % formality
<2> % fm_shell –gui

Formality 2005.09 2- 4
6
Launching GUI from within fm_shell

To launch the GUI type start_gui:

<3> % fm_shell

Formality (R)
Version 2005.09 – Aug 10, 2005
Copyright (c) 1988-2005 by Synopsys, Inc.
ALL RIGHTS RESERVED

This program is proprietary and confidential information of

Synopsys, Inc. and may be used and disclosed only as authorized in
a license agreement controlling such use and disclosure.

Loading db file '/sw/formality/X-2005.09/libraries/syn/gtech.db’

fm_shell (setup)>start_gui

Formality 2005.09 2- 5
8
.synopsys_fm.setup File
 When Formality is invoked, it reads a file called
.synopsys_fm.setup, containing commands such as:
set search_path “. ./lib ./netlists ./rtl”
history keep 200
alias h history

 It is read from each of the following 3 locations:

1st. <formality_root>/admin/setup/.synopsys_fm.setup
2nd. Your home directory
3rd. Current working directory

 The effect of the setup files is cumulative:

 The setup files in all 3 locations are read into Formality, in
the order shown above

Formality 2005.09 2- 6
9
Formality Command Syntax and Tcl

 Formality command syntax is based on Tcl:

fm_shell (verify)> set search_path {. ./rtl}
fm_shell (verify)> read_verilog –r {fifo.v fifo_ctrl.v}
fm_shell (verify)> find_ports clk*

Formality Tcl wildcard Tcl list

command

 Full support for Tcl constructs such as lists and

procedures
 Most Formality commands support Tcl wildcards

Formality 2005.09 2- 7
11
Tcl Variables in Formality

 Tcl variables are used to set options in Formality

 Currently there are over 100 Tcl variables
 Fewer than 20 are commonly used
 Use printvar to display the value of a Tcl variable
Example:
fm_shell (setup)> printvar
bus_dimension_separator_style = "]["
bus_extraction_style = "%s[%d:%d]"
bus_naming_style = "%s[%d]"
bus_range_separator_style = ":"
diagnosis_pattern_limit = "256"
edifin_ground_cell_name = "logic_0"
...
fm_shell (setup)>
fm_shell (setup)> printvar search*
search_path = ”. ./lib"

Formality 2005.09 2- 8
13
Formality’s Tcl Variables

 How to set a Tcl variable:

fm_shell (setup)> set search_path ”. ./lib ./rtl”
. ./lib ./rtl
fm_shell (setup)>
fm_shell (setup)> printvar search*
search_path = ”. ./lib ./rtl"

 Many variables can take only predefined values:

fm_shell (setup)> set sh_enable_page_mode true
true
fm_shell (setup)> set sh_enable_page_mode page
Error: can't set “sh_enable_page_mode": invalid value: use true or false
Use error_info for more info. (CMD-013)
fm_shell (setup)>

Formality 2005.09 2- 9
15
Formality’s Tcl Variables

 Info message displayed when a variable name is

spelled incorrectly:
fm_shell (setup)> set sh_enavle_page_mode true
Information: Defining new variable 'sh_enavle_page_mode'. (CMD-041)
true

Formality 2005.09 2- 9
16
Getting Brief Help On Commands

 From the Formality prompt:

 Type help command_name
fm_shell (setup)> help report_con*
report_constants # Report user specified constants
report_constraint # Reports on the defined constraints
report_constraint_type # Reports information about constraint types
report_containers # Report containers in session

fm_shell (setup)>

 help -verbose command_name

fm_shell (setup)> help -verbose set_user_match
set_user_match # Sets the specified design objects as matched points
[-type type] (Type of objects:
Values: port, net, cell, pin)
objectID1 (First design object of point pair)
objectID2 (Second design object of point pair)

fm_shell (setup)>

Formality 2005.09 2- 10
18
Command Editing and Completion

 The TCL shell supports powerful command editing

and completion capabilities
 set the variable sh_enable_line_editing to true in your
.synopsys_fm.setup file

 For example, command completion with “Tab”

fm_shell (setup)> read_v

read_verilog read_vhdl
fm_shell (setup)> read_verilog

Hit Tab key Enter “e” and hit Tab key

Formality 2005.09 2- 11
20
Getting Detailed Help

To get detailed help on commands, variables and error

or warning messages, type man command_name (or
tcl_variable_name or msg_id).
fm_shell (setup)> man set_user_match
fm_shell (setup)> man hdlin_interface_only

fm_shell (setup)> read_verilog r400.v

Error: Can't open file r400.v (FM-016)
0
Formality (verify)> man FM-016

Command Reference N. Messages messages

NAME
FM-016 (error) Can't open file %s

DESCRIPTION
The specified file does not exist or cannot be created.

WHAT NEXT
Verify that you specified the correct filename and that
you have permission to open and create files.

Formality 2005.09 2- 12
21
Other Help Sources

 Outside of Formality:
 Formality documentation (release notes and user
guides) in .pdf format on the web
 http://www.synopsys.com
 SolvNET

 Login to SolvNet

 Documentation and Media->Documentation on the Web

 Choose a document

 Click on the book icon to download it

 SOLV-IT
 http://www.synopsys.com
 SolvNET

 Login to SolvNet
Enter your “Search SOLV-IT” question or
Choose from one of the SOLV-IT search choices
 See appendix B for more information on SOLV-IT
Formality 2005.09 2- 13
23
Running Formality Scripts

To execute a tcl script in formality:

<2> % fm_shell –f script.tcl | tee script.log
fm_shell > source script.tcl
Formality GUI: File->Run Script

Formality 2005.09 2- 14
25
Files that Formality Generates

 Record of commands issued

 fm_shell_command.log

 Logfile of informational messages

 formality.log

 Working files
 FM_WORK directory
 fm_shell_command.lck and formality.lck
 Formality automatically deletes all Working files when
you exit (gracefully).

Formality 2005.09 2- 15
27
Summary

 The three most important commands for getting help:

 printvar
 Displays the value of a Tcl variable
 Accepts wildcards
 help
 Display brief description of a Formality command
 Accepts wildcards
 man
 Displays detailed info on a Formality command or Tcl variable
 Does not accept wildcards

Formality 2005.09 2- 16
29
Review Questions

1. What command would you use to:

Invoke the Formality shell?
Invoke the Formality GUI?
2. Explain the following command:
% fm_shell | tee data.log
3. When Formality is invoked, what file does it read and
from what 3 locations will it read this file?
4. Are Tcl variables used to set options in Formality?
5. How many Tcl variables are there currently?
6. What are the three most important commands for finding
help? State at least one function of each.
7. Name at least two other sources for help.
Formality 2005.09 2- 17
31
Lab 2: Getting Started With Formality

GUI/shell
Getting to know the
Formality environment
25 minutes printvar/help/man

source script.tcl

Report

Formality 2005.09 2- 18
33
Command Summary
fm_shell [-gui] Launch Formality from Unix
command line
formality Launch Formality GUI from
Unix command line
start_gui Launch Formality GUI from
Formality shell
printvar Display current value of a tcl
variable
set Set value of a tcl variable

help [-verbose] Get brief help on a Formality

command
man Get detailed help on a
Formality command, variable
or error message.

Formality 2005.09 2- 19
35
Day 1 Agenda

DAY 1 Introduction to Formality

1
2 Getting Started with Formality

3 Basic Formality Flow

4 Reading Designs

5 Matching

6 Verification

Formality 2005.09 3- 1
Unit Objectives

After completing this unit, you should be able to:

 Describe the seven-step Formality flow

 Read in libraries and designs

 Interactively compare two designs

 Create and run a script to compare

two designs

 Save the results of a verification for later

analysis
Formality 2005.09 3- 2
Formality Flow Overview

Start

0: Guidance
3: Setup
Specify Automated Setup File

1: Read Reference 4: Match

Design + Libs 6: Debug
5: Verify
set_top

Success
2: Read Implementation ? N
Design + Libs Y

set_top End

Formality 2005.09 3- 3
4
Basic Formality Script

#Step 0: Guidance
set_svf default.svf

# Step 1: Read Reference

read_verilog -r alu.v
set_top -auto

# Step 2: Read Implementation

read_db –i class.db
read_verilog -i alu.fast.vg
set_top alu

# Step 3: Setup
# No setup required here

# Steps 4 & 5: Match and Verify

verify
Formality 2005.09 3- 4
6
Step 0: Guidance

 Load automated setup file (.svf)

 Optional (but recommended) step.
 Removes/reduces need for user setup later in flow
 All guidance validated by Formality
 If information cannot be validated it is ignored (by default)
 Automated setup files are generated by:
 Design Compiler, Physical Compiler and IC Compiler
 Created by default in DC 2004.12 and later (default.svf)

 DC FPGA
 Third Party Tools
 Xilinx ISE

Formality 2005.09 3- 5
8
Step 0: Guidance - Example

fm_shell (setup)> set_svf default.svf

fm_shell (setup)> report_guidance –to myguidance.txt

 Here set_svf loads the file default.svf

 Default name of the binary file generated by DC
 Command also generates an ASCII version of default.svf
called default.svf.txt

 Here report_guidance generates file “myguidance.txt”

 “myguidance.txt” is an ASCII version of the file default.svf

 Note - set_svf can load ASCII versions too

Formality 2005.09 3- 6
10
Steps 1 and 2: Reading the Designs

 Formality supports the following input formats:

 Verilog (synthesizable subset) - read_verilog
 Verilog (simulation libraries) - read_verilog -vcs
 VHDL (synthesizable subset) - read_vhdl
 EDIF - read_edif
 Synopsys binary files - read_db, read_ddc, read_mdb (*)

 Read designs into containers

 -r # default reference container
 -i # default implementation container

 Link top level of design with set_top

 Must load required designs and libraries prior to executing set_top
 Must execute set_top before loading subsequent containers

Formality 2005.09 3- 7
11
Setting Reference and Implementation Design

 For the default “r” container the set_top command automatically sets
the reference design
 The read-only variable $ref specifies the current reference design

 For the default “i” container the set_top command automatically sets
the implementation design
 The read only variable $impl specifies the current implementation
design

 Format of $ref and $impl is:

 Container:/Library/Design
 Examples:
 r:/DESIGN/chip
 i:/WORK/alu_0

Formality 2005.09 3- 8
12
Step 1: Read the Reference - Example

fm_shell (setup)> read_verilog –r alu.v

fm_shell (setup)> set_top -auto

 read_verilog loads design into container

 The “-r” signifies the (default) reference container

 This script does not load a technology library into “r”

 The file alu.v is pure RTL (no mapped logic)

 “set_top –auto” finds and links the top-level module

 set_top uses the current container (“r”)
 The top level module found by Formality is “alu”
 set_top sets the variable $ref to r:/WORK/alu

Formality 2005.09 3- 9
13
Step 2: Read the Implementation Design - Example

fm_shell (setup)> read_verilog –i alu.vg

fm_shell (setup)> read_db –i class.db
fm_shell (setup)> set_top alu_0

 read_verilog loads the implementation design

 The “-i” signifies the (default) implementation container

 read_db loads the technology library class.db

 Since “-i” specified this library is visible only in the container “i”

 set_top links top-level module “alu_0”

 Script reads both design and technology library before set_top
 Here set_top uses the current container (“i”)
 set_top sets the variable $impl to i:/WORK/alu_0

Formality 2005.09 3- 10
14
Step 3: Setup

 In the setup stage you can enter additional

information to guide matching and/or verification.

 Setup is most likely required when:

 You are not using SVF files
 There are complex design transformations
 You are working outside the Synopsys flow

 Module 5 will cover setup commands for matching

 Module 7 will discuss setup for design

transformations

Formality 2005.09 3- 11
15
Step 3: Setup - Example

fm_shell (setup)> set_constant $impl/test_se 0

 This script disables scan logic in the

implementation design
 This is a typical setup step

 The “Basic Script” slide 3-4 did not contain

any setup commands

Formality 2005.09 3- 12
16
Step 4: Match
 Before verification you must match compare points by either:
 Explicitly running Formality’s matching algorithms
 Allowing the “verify” command to run matching for you

 Formality uses powerful algorithms to match points

 Can match most points automatically
 SVF files will help – particularly if your DC script changes
object names

 Manual intervention is possible through

 Rules created by user
 Explicit matches by user
 Module 5 will discuss matching in detail

Formality 2005.09 3- 13
17
Step 4: Match - Example

fm_shell (setup)> match

 This script uses the explicit match command

 An optional command.
 The verify command will run matching if you do not
execute the match command explicitly

 Recommendation:
 In interactive work use the explicit match command
 Gives you important feedback
 Omit the match command from scripts
 Reduces runtime

Formality 2005.09 3- 14
18
Step 5: Verify

 Run Formality’s verification algorithms

 By default all points are verified

 Four possible results:

 Succeeded: implementation is equivalent to the reference
 Failed: implementation is not equivalent to the reference
 Logic difference or setup problem
 Inconclusive: no points failed, but analysis incomplete
 Analysis incomplete due to timeout or to complexity
 Module 9 will discuss techniques for very complex designs

 Not run: a problem earlier in the flow prevented verification

from running at all.
 Module 6 will discuss Verification in detail
Formality 2005.09 3- 15
19
Step 5: Verify - Example

fm_shell (match)> verify

 By default the verify command verifies all points

 However there are options allowing you to:

 Run verification on a single point
 Exclude points from verification

Formality 2005.09 3- 16
20
Step 6: Debug

 If verification fails, you need to determine the cause:

 An incorrect setup?
 A logical design difference between the two designs?

 Module 8 will discuss debugging in detail

Formality 2005.09 3- 17
21
The Seven Steps and the GUI
 You have learned the seven steps
using Tcl
 The GUI prompts you to perform
the same seven steps:
 Numbered tabs identify each
step
 If you skip a step, you are
informed
 Step-sensitive tabs allow you to
see detail
 You do not have to remember
Tcl syntax
 The GUI translates your mouse
clicks to Tcl for you
 The GUI stores your preferences
in ~/.synopsys.fmg
 You will work with the GUI in the
lab

Formality 2005.09 3- 18
23
Saving/Restoring Containers

fm_shell (match)> write_container -r

fm_shell (setup)> read_container –r r.fsc

 Save linked design after set_top

 Load faster than RTL or netlist formats

 No setup information saved

 Most useful when your reference design is stable

 Work “across releases”

 FM 2005.09 can read containers from earlier releases

Formality 2005.09 3- 19
25
Saving/Restoring Session Files

fm_shell (match)> save_session fail.fss

fm_shell (setup)> restore_session fail.fss

 Save “Snapshot” of current state of design

 Saves all setup information, matching results and verification
results

 Useful in a batch mode environment to save work for

interactive study

 Only work for current releases

 FM X-2005.09 can only read session files from X-2005.09

Formality 2005.09 3- 19
26
Saving/Restoring Your Work - Example

# Batch mode script

set_svf alu.svf
read_container -r alu.fsc
read_db –tech class.db
read_verilog -i alu.fast.vg
set_top alu
if {[verify] != 1} {
save_session –replace ./fail.fss
}

fm_shell (setup)> restore_session fail.fss

Formality 2005.09 3- 20
27
Summary

 The seven-step Formality flow

 Specify Guidance File
 Read Reference
 Read Implementation
 Setup
 Match
 Verify
 Debug

 Save and restore your work

 Containers
 Session Files
Formality 2005.09 3- 21
28
Basic Flow Review Questions

1. How do you load a guidance file from Design Compiler?

2. What are the three ASCII formats that Formality can read
design data in?

3. What are the three Synopsys binary formats that Formality

can read design data in?
4. After reading in the reference design, what sub-step must you
perform before reading in the implementation design?
5. Define the following design verification results: Succeeded,
Failed, Inconclusive, Not Run.
6. How can you save and restore the results of a verification?

Formality 2005.09 3- 22
29
Find the problem in this script - 1

read_verilog -r alu.v
set_top alu

read_verilog -i alu.fast.vg
set_top alu
read_db –i class.db

verify

Formality 2005.09 3- 23
31
Find the problem in this script - 2

read_verilog -r alu.v

read_db –i class.db
read_verilog -i alu.fast.vg

set_top r:/WORK/alu
set_top i:/WORK/alu

verify

Formality 2005.09 3- 24
32
Lab 3: Basic Formality Flow

Lab 3 is split into two parts:

In Part A you will use the Formality Flow
GUI to read in two designs and
successfully verify them.
20 minutes READ

In Part B you will create a Verify

Formality run script which can be
used to perform the verification
from Part A.
Script
10 minutes

Formality 2005.09 3- 25
33
Command Summary - 1
set_svf Specify guidance file

report_guidance Show contents of guidance file

read_verilog Read Verilog source files

read_vhdl Read VHDL source files

read_edif Read EDIF source file

read_db, read_ddc, read_mdb Read Synopsys binary formats

set_top Link the design

write_container Save current container

read_container Reads container file created by

write_container
Formality 2005.09 3- 26
35
Command Summary - 2

match Match compare points

verify Check designs for equivalence

save_session Save “snapshot” of current

work

restore_session Restore session file created by

save_session

Formality 2005.09 3- 27
36
Day 1 Agenda

DAY 1 Introduction to Formality

1
2 Getting Started with Formality

3 Basic Formality Flow

4 Reading Designs

5 Matching

6 Verification

Formality 2005.09
4- 1
Unit Objectives

After completing this unit, you should be able to:

 Write a simulation style script to read a Verilog design

 Use command line declaration of Verilog Text Macros to

match either VCS or DC

 Write a script to read a VHDL design

 Load a technology library (Verilog format)

 Load a technology library (db format)

 Read an RTL design with instantiated DesignWare

Formality 2005.09
4- 2
Formality Flow Overview

Start

0: Guidance
3: Setup
Specify Automated Setup File

1: Read Reference 4: Match

Design + Libs 6: Debug
5: Verify
set_top

Success
2: Read Implementation ? N
Design + Libs Y

set_top End

Formality 2005.09
4- 3
4
Design Libraries

 Within Formality you load designs into:

container:/library/design

 Examples:
r:/WORK/top
i:/MY_LIB/top_0

 A design library is a “collection” of designs

 Very important if your RTL uses design libraries to
distinguish objects of the same name
 Default name is “WORK”
 Do not confuse with Technology Library (see below)
Formality 2005.09
4- 4
5
Verilog Simulation Option File

 The command read_verilog can read designs as a Verilog

simulator does
 Much simpler for complicated designs
 More intuitive for verification engineers
 Why write a new script if you can reuse one that already works?

 read_verilog -f sim_option_file
 Simulator setup file containing file pathnames and other
commands and options
 Irrelevant switches are ignored
 Can load all design files and simulation models for the technology
libraries in one command

Formality 2005.09
4- 5
6
Simulation-style Verilog Design Read

 The read_verilog command also supports VCS style switches

 read_verilog top.v -vcs “switches” where “switches” include:
 -y <dir_name>
 Search <dir_name> for unresolved modules
 -v <file_name>
 Search <file_name> for unresolved modules
 +libext+<extension>
 Look at files with this extension, typically “.v” or “.h”
 +define+ : Define values for Verilog parameters
 +incdir <dirname> : Directory containing `include files

 Can use “-vcs” only once per container

Formality 2005.09
4- 6
7
Simulation-style Verilog Design Read Example

# file read.tcl

read_verilog –i top.vg –vcs

“-y ./synthesis
–y ./tech_lib/verilog +libext+.v”

set_top –auto

 Formality will look for undefined modules in:

 Directory “./tech_lib/verilog”
 Directory “./synthesis”
 With file type “.v”, for example “dff2.v” or “xblock.v”

Formality 2005.09
4- 7
9
Verilog Text Macros in Formality (VCS style)

 VCS
vcs file1.v file2.v +define+def1
 def1 applies to all files read on vcs command line

 Formality
read_verilog { file1. file2.v } -vcs
"+define+def1"
 def1 applies to all files in read_verilog and during
set_top commandExactly matches VCS

 Formality models will match VCS simulation

Formality 2005.09
4- 8
11
Verilog Text Macros in Formality (DC Style)

 Design Compiler
analyze –f verilog file1.v –define {def1}
analyze –f verilog file2.v –define {def2}
 Each analyze command has its own list of defines

 Formality
read_verilog {file1.v} –define {def1}
read_verilog {file2.v} –define {def2}
 Each read command has its own list of defines

 Formality models will match those from DC

Formality 2005.09
4- 9
13
Reading Verilog Netlist and RTL files
 Formality has an optimized netlist reader
 Formality tries the optimized netlist reader first, and
falls back on an RTL reader if necessary
 Mixing netlists and RTL files in the same read
command will slow the reading
 Use separate commands to read netlist and RTL files

# read netlist files

read_verilog –r {encode.vg alu.vg}
–vcs “–y ./sim_lib +libext+.v”

# read RTL file (s)

read_verilog –r code_module.v

Formality 2005.09
4- 10
15
Technology Libraries

 What is a Technology Library?

 The basic building blocks from your ASIC or FPGA Vendor

 Any special handling in Formality?

 Can sometimes be shared between containers (see
below)
 Internals of cells are not shown (except in debug)
 Formats of Technology Libraries?
 For most verifications the Technology Libraries will be:
 Synthesis libraries - Synopsys binary (db) format
 Verilog simulation libraries

Formality 2005.09
4- 11
17
Technology Library: Simulation or Synthesis?

 Which format library should I use?

 Results with Verilog simulation library will match VCS
 Results with db will match VCS, provided db library
verified against Verilog library

 Formality supports library verification

 Checks db against Verilog for each cell
 Not covered in this class
 Check that your ASIC Vendor has validated db library

Formality 2005.09
4- 12
18
Synopsys Synthesis Libraries

 Compiled by Library Compiler

 Source is the Liberty format (“.lib”)
 Stored as binary “.db” files
 Read synthesis libraries with read_db command
 Formality will recognize as technology libraries
 Stored as <container>:/<library_name>
 <library_name> is defined within library file
 Formality does not read Liberty format
 Can load as shared technology libraries
 Load into all containers with single read command
 Do not specify “-r” “-i” or “-container”
 Example read_db class.db

Formality 2005.09
4- 13
19
Verilog Simulation Libraries

 Load simulation libraries with the VCS switches.

 For Verilog designs
read_verilog –i gate.v –vcs “-y ./sim +libext+.v”
 For other netlist formats create an empy file “dummy.v”
read_edif –i gate.edf
read_verilog –i dummy.v –vcs “-y ./sim +libext+.v”
 Remember you can use “-vcs” on just one read command for
each container

 Simulation libraries cannot be shared

 Read library into each container that uses that library

Formality 2005.09
4- 14
20
Verilog Simulation Libraries

 Technology library cells are stored in a separate library

 By default this is <container>:/TECH_WORK

 Formality automatically recognizes cells as technology

library cells where a cell is
 A UDP (User Defined Primitives)
 A module enclosed by `celldefine … `endcelldefine

Formality 2005.09
4- 15
21
Verilog Simulation Libraries

 Formality very strict in checking of UDPs

 Many libraries will generate warnings
 Most warnings are on X handling
 Details are in the formality.log file

 For library experts

 Excellent way of ensuring your UDPs handle all X
conditions in a consistent fashion

 For others
 Leave it to the library experts
 Won’t cover in this class
Formality 2005.09
4- 16
23
Reading VHDL designs – recommended flow

Let Formality determine the order to read the files in:

1. Read the technology library

2. Use a single read_vhdl to read all vhdl files

 Use the default library “WORK”

3. Link with set_top

This will work unless there are:

 Package/entity name conflicts
 Configuration declarations in the files

Formality 2005.09
4- 17
25
Reading VHDL – multiple read_vhdl commands

 If a file A.vhd references a package or entity you must either:

 Read the package/entity declaration and A.vhd in the same
read command
 Read the package/entity declaration in an earlier read
command

 You can read files into either:

 The library specified in the VHDL code
 The default (WORK) library

 If there are identical (conflicting) names of packages/entities

 Read files into the library specified in the VHDL code

Formality 2005.09
4- 18
26
DesignWare: What Is It?

DesignWare is a library of functions that you can instantiate

in a netlist or infer in RTL code.

Example of instantiated DesignWare

module mult256 ( Y, A, B );

parameter width=256;
parameter A_width=256, B_width=256;
output [width*2-1:0] Y;
input [width-1:0] A, B;

//instantiation of DesignWare multiplier

DW02_mult #(A_width,B_width) m1 ( A, B, 1'b0, Y );

endmodule

Formality 2005.09
4- 19
28
DesignWare: How to Deal With It

 If you instantiate DesignWare elements in RTL, you need to set the

variable hdlin_dwroot to the root of your Synopsys tree
 Not required for:
 RTL with inferred DesignWare
 Netlists compiled by DC from RTL

 You must set variable before you read anything into the container
that will hold the RTL

fm_shell (setup) > set hdlin_dwroot “/synopsys/2005.09”

fm_shell (setup)> read_verilog –r alu.v
fm_shell (setup)> set_top r:/*/alu

Formality 2005.09
4- 20
30
Example - How not to load DesignWare
fm_shell output when user forgets to set hdlin_dwroot

fm_shell (setup)> printvar hdlin_dwroot

hdlin_dwroot = ""
fm_shell (setup)> read_ver -r chip.v -vcs "-v tsc6000.v"
Loading verilog file '/users/boston/brandall/labs/fm_2005.09_working/fm/lab7a/chip.v '
No target library specified, default is WORK
Current container set to 'r'
1
fm_shell (setup)> set_top chip
Setting top design to 'r:/WORK/chip'
Status: Elaborating design chip ...
Status: Elaborating design pll ...
Status: Elaborating design ff ...
Status: Elaborating design dp ...
Error: Design 'DW01_add' is not defined but cell '/WORK/dp/u0' references it. (FM-234)
Error: Design 'DW01_add' is not defined but cell '/WORK/dp/u1' references it. (FM-234)
Error: Design 'DW01_add' is not defined but cell '/WORK/dp/u2' references it. (FM-234)
Error: Design 'DW01_add' is not defined but cell '/WORK/dp/u3' references it. (FM-234)
Status: Elaborating design cntrl ...
Error: Failed to set top design to 'r:/WORK/chip' (FM-156)
0
fm_shell (setup)>

Formality 2005.09
4- 21
32
Summary

 Reading Verilog Designs

 Use the VCS simulation option file (if available)
 Use the VCS style switches to save typing

 Reading VHDL Designs

 Let Formality determine order to read files in

 Technology Libraries
 Read db libraries as shared libraries
 Use VCS switches to read Verilog simulation libraries

 If your RTL instantiates DesignWare parts

 Set tcl variable hdlin_dwroot to point to Synopsys tree
Formality 2005.09
4- 22
33
Review Questions

1. Which read_verilog option allows you to use a VCS simulation

option file?
2. Name the 5 VCS style switches that you can use in read_verilog –
vcs “<switch>”?
3. How would you make a command line declaration of Verilog Text
Macros to match VCS?
4. How would you make a command line declaration of Verilog Text
Macros to match DC?
5. There are just two cases which prevent Formality from determining
the order to read VHDL files in. What are they?
6. Which command and switch(es) would you use to load a Verilog
simulation library in ./sim_lib/class.v? (Class.v is a single file)
7. How would you load class.db as a shared technology library?
8. What tcl variable must you set before reading an RTL design with
instantiated DesignWare

Formality 2005.09
4- 23
34
Command Summary - 1
read_verilog -f Read Verilog using VCS
simulation option file
read_verilog –vcs Read Verilog files using VCS
“<switches>” style switches
VCS switches

-vcs “-y” Search <dir_name> for

unresolved modules
-vcs “-v” Search <file_name> for
unresolved modules
-vcs “+libext+” Look at files with this
(Used with –y) extension, typically “.v” or “.h”
-vcs “+define+” Define values for Verilog
parameters
-vcs “+incdir+” Directory containing `include
files
Formality 2005.09
4- 24
35
Command Summary - 2
read_verilog –define Read Verilog with Text Macro
“<Text Macro Defines>” defined from command line
read_verilog – Read Verilog model as a
technology_library technology library cell
read_vhdl – Read VHDL model as a
technology_library technology library cell

hdlin_dwroot Tcl variable to declare root of

your Synopsys tree. Required
when using instantiated
DesignWare parts

Formality 2005.09
4- 25
36
Day 1 Agenda

DAY 1 Introduction to Formality

1
2 Getting Started with Formality

3 Basic Formality Flow

4a Reading Designs: Black Boxes

5 Matching

6 Verification

Formality 2005.09
4a- 1
Unit Objectives

After completing this unit, you should be able to:

 List 4 ways of creating a blackbox model

 Give two reasons why allowing Formality to

create black boxes for unresolved modules can
result in a failing verification

 Find black boxes using both GUI and command

line

Formality 2005.09
4a- 2
Black Boxes: What Are They?

 A Black Box is a empty model for a module/entity

 Black boxes DO affect verification

 Black box input pins are compare points
 Black box output pins are inputs to logic cones
 Black box pins of unknown direction are treated as inouts

Formality 2005.09
4a- 3
Black Boxes: Require Attention

 If black box pin directions are undefined Formality:

 Attempts to infers pin direction from connectivity
 Will label the pin an I/O if it cannot infer direction

 Plenty of opportunities for failing verifications!

 A cell is a black box in reference but not in implementation
 A cell is a black box in both designs, but has additional
pins in reference
 A pin is an inout in reference but an input in
implementation
 More details in Section 6

Formality 2005.09
4a- 4
5
When would you want to use a Black Box?

 No suitable model exists (analog cell)

 No point in verifying (RAM)

 You wish to exclude a sub-module from verification

 Known problem within module
 You only want to check other areas of design

Formality 2005.09
4a- 5
7
How to create a black box

1. Before ‘read’: create a wrapper model

 Model that defines pin out but has no functionality

2. Before ‘read’: set hdlin_interface_only {sRAM01}

 Formality loads pin out but no functionality

3. Before set_top: set hdlin_unresolved_modules

black_box

 Formality creates a black box for any instantiated cell

that is unresolved

4. Before match: set_black_box i:/WORK/sRAM01

 Formality sets a black box property on the cell

Formality 2005.09
4a- 6
8
Black Boxes - recommendations

 Be consistent about blackboxes in ref and impl

 Unmatched blackboxes will give failing verification (in general)

 Ensure no unintended black boxes

 Leave hdlin_unresolved_modules in default state of error
 (set_top will error out if there is a missing model)

 Provide pin direction information if black boxes are deliberate

1. Create a wrapper model
2. Use hdlin_interface_only
3. Use set_black_box
4. Use set_pin_direction (last resort)

 If you have a model and are experimenting

 Use set_black_box
 Can remove effects without reloading container

Formality 2005.09
4a- 7
9
Black Boxes: Wrapper Model

/*File ram.v */

module ram (d, rw, ck, q);

input [7:0] d;
output [7:0] q;
input rw, ck;

endmodule;

 Simply an empty model, but with pins defined

Formality 2005.09
4a- 8
10
Black Boxes: hdlin_interface_only

 You can read in just the interface information for a design

 Eliminates having to create wrappers
 Does require a description for design or module

set hdlin_interface_only RAM*

read_verilog –i gates.vg –vcs “-y ./sim_lib +libext+.v”
 The argument is the design or module name
 Not the filename
 Not the instance name
 You can use wildcards
 Works for both netlists and RTL
 Works for all input formats
Formality 2005.09
4a- 9
11
Black Boxes: hdlin_unresolved_modules

 Formality tcl variable that determines how to

handle instances that are not resolved
 Possible values are ‘error’ and ‘black_box’
 ‘error’ means no design is created (default value)
 ‘black_box’ means Formality creates a black box

 The default value of error

 Prevents you creating black boxes by mistake
 Prevents verification from proceeding
 Set_top will error out if there is an unresolved module
 If set_top errors out all subsequent steps error out too

Formality 2005.09
4a- 10
12
Black Boxes: why is an instance unresolved?

 Formality cannot find a corresponding module/entity

 File is missing or you typed in wrong file name
 File name and VCS options don’t match
 The file for the module or entity contains
 syntax errors
 unsupported constructs
 The instance and the module/entity are inconsistent
 Pinout doesn’t match
 Formality analysis shows risk of simulation/synthesis
mismatch
 (By default) Formality will not create a model
 See Section 4b for details

Formality 2005.09
4a- 11
13
Setting a Black Box property

 You can set/unset the black_box property on a

design in either the REF or IMP or both
 Inputs will become new compare points, outputs will
become new cone inputs

set_black_box r:/WORK/mod
remove_black_box r:/WORK/mod
report_black_boxes “mod” is the
design name, not
the instance name

Formality 2005.09
4a- 12
14
Black Boxes: Specifying Pin Directions

 Tell Formality about the directions of black box pins:

 Find the code for the missing cell and read it in
 Find the code for the missing cell and read in only the
interface information (hdlin_interface_only)
 Alternative: create a dummy definition for the black box cell
containing the input and output port declarations but
containing no logic
 Read this cell into Formality so that it knows the directions of
the pins
 Last Resort: Use the set_direction command to set the pin
directions on unresolved modules
set_direction r:/WORK/mAlu/reg[0] out

Formality 2005.09
4a- 13
15
Finding Black Boxes using fm_shell
fm_shell (setup)> report_black_box
Information: Reporting black boxes for current reference and implementation designs.
(FM-184)
__________________________________________________
| |
| Legend: |
| Black Box Attributes |
| s = Set with set_black_box command |
| i = Module read with -interface_only |
| u = Unresolved design module |
| e = Empty design module |
| * = Unlinked design module |
|___________________________________________________|

##################################################################
#### DESIGN LIBRARY - i:/WORK
##################################################################
Design Name Attributes
----------- ----------
sRAM01 s

##################################################################
#### DESIGN LIBRARY - r:/WORK
##################################################################
Design Name Attributes
----------- ----------
sRAM01 i

Formality 2005.09
4a- 14
17
Finding Black Boxes with the GUI

Formality 2005.09
4a- 15
19
Black Box Summary
Method Command / Variable report_black_box
shows as

Read a Empty Module

Wrapper

Read in the hdlin_interface_only Interface Only

interface only

Set a property set_black_box Set with command

after reading in
(remove_black_box undoes)

Don’t read in hdlin_unresolved_modules Unresolved Design

the design Module
(may need set_direction too?)

Formality 2005.09
4a- 16
21
Review Questions

1. List 4 ways of creating a black box model

2. Which commands or variables would you use for

each of these 4 ways?

3. Give two reasons why allowing Formality to create

black boxes for unresolved modules can result in
a failing verification

4. How would you find black boxes from the

command line?

5. How would you find black boxes using the GUI?

Formality 2005.09
4a- 17
22
Command/Variable Summary
set hdlin_interface_only Following read operations
<Design Name(s)> will read only the interface
declaration for the design
set hdlin_unresolved_modules Determines how unresolved
<error | black_box > modules are handled

set_black_box <design> Set a black box property on

a design
remove_black_box <design> Removes a black box
property from a design

report_black_box Lists black boxes and

shows source of black box
set_direction <pin> Set pin direction on a black
box (use on unresolved
modules)
Formality 2005.09
4a- 18
23
Day 1 Agenda

DAY 1 Introduction to Formality

1
2 Getting Started with Formality

3 Basic Formality Flow

4b Reading Designs: Sim/Synth Warnings

5 Matching

6 Verification

Formality 2005.09
4b- 1
Unit Objectives

After completing this unit, you should be able to:

 List the three categories of causes for simulation/synthesis
differences
 Name three tools that will warn you of potential
simulation/synthesis differences
 Override simulation/synthesis mismatch warnings in
Formality
 Name the DC and Formality variable that controls how out of
range array accesses are handled and explain its operation
 Name the two DC pragmas that can give simulation/synthesis
differences when used inappropriately
 Explain when/how these two pragmas can give
simulation/synthesis differences
 Explain how you would check Formality warnings of
simulation/synthesis mismatches

4b- 2
RTL Simulation and Synthesis

 Some ‘legal’ coding styles in RTL are interpreted differently by

simulation and synthesis
 These lead to the possibility that the gate level netlist will have
different behavior than the RTL.
 RTL is what’s validated to insure your design meets
the functional requirements
 Gates are what get turned into product
 What is your goal?
 To be sure that final gates match what you simulated
 Your goal is not
 To get a “Verification succeeded” at all costs!

4b- 3
Why Simulation / Synthesis Differences?

 The problem areas are well understood

1. No reasonable hardware implementation exists

 Correspond to poor coding practices in RTL
 Example: Incomplete sensitivity list
 Good simulation RTL, but designer didn’t “think hardware”
 Example: Comparison to X

2. Out of range accesses to arrays

 Results are under variable control in Design Compiler

3. Synthesis pragmas
 User directives to Design Compiler
 Ignored by simulators

4b- 4
Warnings throughout Synopsys flow

 LEDA – issues warning

 Presto – issues warnings
 but will give gates
 Formality – always warns
 Model built depends upon category of warning
1. No reasonable hardware implementation
 (By default) set_top will Error out
2. Out of range accesses to arrays
 (By default) model for RTL matches simulation
3. Synthesis pragmas
 (By default) model for RTL matches simulation

4b- 5
6
Simulation-Synthesis Recommendations

 Use LEDA Formality rule set to check code

 LEDA Coding Rules Manual (Volume II page 49)

 Recommendation – Correct the RTL

 Best Practice

 Enforce this and we can skip the rest of this unit 

4b- 6
8
No hardware implementation - list

 Incomplete sensitivity list

 Comparison to X or Z
 Explicit
 Comparison to undriven signals
 Use of “===“ in Verilog

 Read before write

 Assignment in multiple concurrent processes

 Function may not return a value

 Initial statements

 Delay or transport (VHDL) statements

4b- 7
9
Incomplete Sensitivity List - RTL

module top (a, b, q);

input a, b;

output q;

reg q;

always @ (a)

q = a & b;

endmodule

4b- 8
12
Incomplete Sensitivity List – Formality (Overridden)

 Set hdlin_warn_on_mismatch_message

 Formality model then matches synthesis

 Since no reasonable model we can’t match simulation

 Is this what you really want?

4b- 9
14
No hardware implementation - checking

 Always safest to fix in RTL

 Incomplete sensitivity list

 Comparison to X or Z

 Can ignore if system will always be reset before simulation or

operation
 Read before write

 Initial statements

 Timing dependent
 Delay or transport (VHDL) statements
 OK if total delay on path less than clock period in RTL and in gates
 Example unit delay blocking assignment style is OK
 Depends if difference is reachable
 Assignment in multiple concurrent processes

 Function may not return a value

4b- 10
16
No hardware implementation - Summary

 Warnings mean real risk that gates will behave

differently to simulation

 You can override warnings with

hdlin_warn_on_mismatch_message

 If you override warnings then Formality model will

match synthesis not simulation!

 Be very careful!

4b- 11
17
Out of range access - Verilog

 Consider an 8 bit array with 4 bit address line

 What happens with address = 15?

 Verilog Language Reference Manual (and VCS)

 Write operation leaves register undisturbed
 Read operation returns 1’bX

4b- 12
18
Out of range access Verilog – DC (default)

 For hdlin_dyn_array_bnd_check = false (default)

 Input pin address[3] is not read

 Access to address 15
 Write operation writes to array[7]
 Read operation returns contents of array[7]

4b- 13
19
Out of range access Verilog – DC (Non default)

 For hdlin_dyn_array_bnd_check = true

 Input pin address[3] is read

 Access to address 15
 Write operation leaves array undisturbed
 Read operation returns ??
 Matches simulation
 In simulation read returns X

4b- 14
20
Out of range access – Formality (Verilog)

 Controlled by hdlin_dyn_array_bnd_check
 Important settings are:
 Verilog (default)
 None

 Formality models
 For ‘Verilog’ matches simulation
 For ‘None’ matches default synthesis

4b- 15
21
Out of range access – Formality (VHDL)

 Simulation
 Out of range access is a VHDL runtime error

 Design Compiler
 As Verilog

 Formality
 Controlled by hdlin_dyn_array_bnd_check
 Important settings are Verilog (default) and VHDL
 (By default) Formality matches synthesis for VHDL Files
 Since out of range access is a runtime error your RTL and
synthesized gates will not “disagree” in simulation

4b- 16
23
Out of range access - Recommendations

 For Verilog RTL

 Change the default setting of
hdlin_dyn_array_bnd_check in your master DC
.synopsys_dc.setup file to true!
 Leave Formality hdlin_dyn_array_bnd_check in
default state of Verilog
 Change default setting to None (or VHDL) only if you’re
sure!

 For VHDL RTL

 Use default settings in both DC and Formality

4b- 17
25
Synthesis Pragmas

 Pragmas are comments in RTL code that provide information to

Design Compiler
 Most commonly used pragmas are:
 synthesis_on / synthesis_off
 translate_on / translate_off
 dc_script_begin / dc_script_end
 parallel_case
 full_case
 Simulators ignore pragma information
 Risk:
 DC uses the pragma information to create a netlist that simulates
differently from the RTL

4b- 18
26
How Does Formality Handle Pragmas?

 (Default) Formality ignores

 dc_script_begin / dc_script_end
 parallel_case
 full_case
 (Default) Formality respects
 synthesis on / synthesis_off
 translate on / translate_off
 Design intent in these cases is clear.

 Tcl variables control Formality behavior

 hdlin_ignore_synthesis
 hdlin_ignore_translate
 hdlin_ignore_dc_script
 hdlin_ignore_parallel_case
 hdlin_ignore_full_case

4b- 19
27
Full_case and Parallel_case

 // synopsys full_case
 Asserts that all possible clauses of a case statement have been
covered
 Avoids the need for default logic, and
 Can avoid latch inference from a case statement by asserting that
all necessary conditions are covered by the given branches of the
case statement.

 // synopsys parallel_case
 Tells the synthesis tool to evaluate all case-items in parallel.
 Generates multiplexer logic instead of priority encode logic.

 Both can lead to simulation/synthesis differences if used

inappropriately!

4b- 20
29
Possible false equivalence from full_case

 Here are the conditions that would have to exist:

 User forces Formality to obey full_case pragma
 Not all cases are covered - error condition by default
 User forces downgrade of error to warning
 The uncovered case is reachable in the full design context
(…could use Magellan to find out)
 User ignores RTL interpretation warning message

 Always safer to use a default clause.

4b- 21
30
full_case - Example

module block_b (current_state, next_state);

input [3:0] current_state;

output [3:0] next_state;

parameter state1 = 4'b0001, state2 = 4'b0010,

state3 = 4'b0100;
reg [3:0] next_state;

always @ (current_state)
case (1) // synopsys full_case
current_state[0] : next_state = state2;
current_state[1] : next_state = state3;
current_state[2] : next_state = state1;
endcase

endmodule

4b- 22
31
full_case - Example

Gates produced by DC using full_case

4b- 23
32
full_case - Example

Gates produced by DC without using full_case

4b- 24
33
full_case – Simulation Results

Simulation of Ver ilog code Simulation of gates from DC

Chronologic VCS simulator copyright Chronologic VCS simulator copyright
1991-1997 1991-1997
Contains Viewlogic proprietary Contains Viewlogic proprietary
information. information.
Compiler version 4.0.3; Runtime Compiler version 4.0.3; Runtime
version 4.0.3; Feb 3 19:11 2000 version 4.0.3; Feb 3 16:59 2000

Simulation of top.v Simulation of top.v

------------------- -------------------
in=00 out=0010 in=00 out=0010
in=01 out=0100 in=01 out=0100
in=10 out=0001 in=10 out=0001
in=11 out=0001 in=11 out=0001
in=00 out=0010 in=00 out=0010
in=11 out=0010 in=11 out=0001
in=01 out=0100 in=01 out=0100
in=11 out=0100 in=11 out=0001
$stop at time 8000 Scope: testbench $stop at time 8000 Scope: testbench
File: top.testbench.v Line: 24 File: top.testbench.v Line: 24
C1 > C1 >

4b- 25
34
full_case - Simulation Results: explanation

 When simulating the RTL code

 If the input to the case statement is not one of the listed
case items
 The output of the case statement holds its value from the
previous state

 When simulating the gate level netlist

 If the input to the case statement is not one of the listed
case items
 The output of the case statement is the output of the
combinational logic that the synthesis tool optimized for the
other case items

4b- 26
35
fulll_case - Summary

 Improper use of the full_case pragma can result in

a netlist that simulates differently than your RTL

 When you apply an external constraint to your

synthesis tool (in the form of a RTL pragma) you
need to be sure that the constraint is valid

4b- 27
36
Is Difference Reachable?

 Formality is a static equivalence checker

 For all 3 categories difference may not be reachable

 Example
 Full case for one hot decoding driven by one hot counter
 In simulation/operation no problem – provided there is a
power on reset

 Formality considers all 2**n states

 How to handle?
 Check with Formal Vera
 Apply constraint
 Override warning

4b- 28
37
Simulation / Synthesis Summary

 Check and understand the warnings!

 Scenarios that can lead to failing verification

 Abuse of full_case / parallel_case
 Different default settings of hdlin_dyn_bnd_array_check
 Others ….

 Scenarios that can lead to silicon / simulation

mismatch
 Overriding default settings without checking

4b- 29
38
Review Questions

1. List the three categories of causes for simulation/synthesis

differences
2. Name three tools that will warn you of potential
simulation/synthesis differences
3. Explain how you would override simulation/synthesis
mismatch warnings in Formality
4. Name the DC and Formality variable that controls how out of
range array accesses are handled and explain its operation
5. Name the two DC pragmas that can give simulation/synthesis
differences when used inappropriately
6. Explain when/how these two pragmas can give
simulation/synthesis differences
7. Explain how you would check Formality warnings of
simulation/synthesis mismatches

4b- 39
Lab 4: Design Read

Lab 4 :
1. ???

4b- 25
40
Backup Slides

4b- 30
41
VHDL Signed Division by Power of 2

 For DC HDLC Reader

 DC implements division by power of 2 as shift
 Results differ from simulation for negative numerator

 Formality VHDL Reader gives sim/synth warning

 FMR_ELAB-151
 If you override warning Formality model matches DC
and not simulation (default)

 Formality can match simulation in VHDL

 Set hdlin_vhdl_presto_shift_div true

4b- 31
42
Presto VHDL: Signed Division by Power of 2

 For DC Presto Reader

 DC (by default) matches simulation results

 Can enable old behavior by setting

 hdlin_signed_division_use_shift true
 Recommendation when using VHDL Presto (Current)
 Set DC and Formality to match simulation
 # Use default value in DC
 set hdlin_signed_division_use_shift false
 # Formality, enable simulation model
 set hdlin_vhdl_presto_shift_div true
 In future releases, when Presto is default DC VHDL reader
 Formality defaults will match simulation

 Therefore, leave DC and Formality in default settings

4b- 32
43
Day 1 Agenda

DAY 1 Introduction to Formality

1
2 Getting Started with Formality

3 Basic Formality Flow

4 Reading Designs

5 Matching

6 Verification

Formality 2005.09 5- 1
Unit Objectives

After completing this unit, you should be able to:

 Explain the benefits of using the Synopsys Guidance

Flow (SVF files) in matching compare points

 List DC commands that can slow Formality compare

point matching

 Use the filter character list and compare rules to speed

matching for regular name changes

 Use the matching summary message to determine if

there are any significant unmatched points

 Match individual points from GUI or from command line

Formality 2005.09 5- 2
Compare Point Matching

 Fundamentals of Matching

 Challenges posed by Design Compiler

 Synopsys Guidance Flow (DC and SVF Flow)

 Matching Designs without SVF

 Unmatched Objects

 Recommendations (Summary)

Formality 2005.09 5- 3
4
Compare Point Matching – align designs

Reference Design Implementation Design

BB BB

a_reg[31] a_reg[31]

BB BB

•Match cone inputs •Match cone outputs

•Registers •Registers
•Primary Inputs •Primary Outputs
•Outputs from Blackboxes •Inputs to blackboxes

Formality 2005.09 5- 4
5
Fundamental Assumptions by Formality

 By default Formality assumes:

 Identical name in ref and imp should be matched
 1:1 match from each point in ref to impl

 User can override both assumptions

 Formality won’t match objects of incompatible types

 E.g. You cannot match an input port to a flip-flop
 Note that black-box pins can only be matched to black-box
pins. A problem if you have a blackbox in ref (imp) but not
in imp (ref).

Formality 2005.09 5- 5
7
Matching would be trivial if ….

1. Objects always had same name in REF and IMPL

2. There were always a 1:1 match

 Every object in REF matches a single object in IMPL
 Every object in IMPL matches a single object in REF

 Neither point is true for typical real designs

 Even in basic DC Flow (This section)
 Worse for more advanced design transformations
(Section 7)

Formality 2005.09 5- 6
8
Compare Point Matching

 Fundamentals of matching

 Challenges posed by Design Compiler

 Synopsys Guidance Flow (DC and SVF Flow)

 Matching Designs without SVF

 Unmatched Objects

 Recommendations (Summary)

Formality 2005.09 5- 7
9
DC and Formality instance names

 (By default) compare point names are same in ref and impl:
 (By default) Formality and DC create same names from RTL

 For gate level netlists all instance names are explicit

 But designers can change names with DC commands

 Regular name changes
 change_names

 ungroup

 group

 uniquify

 Complex name changes

 ungroup –simple_names

Formality 2005.09 5- 8
10
Examples of Name Changes by DC

 Regular (from change_names)

1. (REF) : reg_a[0]....reg_a[31] ->

(IMP) : reg_a_0_....reg_a_31_

2. (REF) : reg[0][0]....reg[0][31] ->

(IMP) : regy00y....regy031y

3. (REF) : reg[0][0]....reg[0][31] ->

(IMP) : reg_0_0_0....reg_0_31_0

 Examples from ungroup –simple_names

1. (REF) : top/mod1/mod2/mod3/mod4/regA ->
(IMP) : top/modx/regA

Formality 2005.09 5- 9
11
Cases from DC where no 1:1 Match Exists

 Redundant (Unread) Flip-Flop

 DFF optimized away by DC

 Constant value flip-flop

 DFF optimized away by DC

 For basic DC flow

 Possible unmatched object in ref but not in impl
 Ports are not created or removed

Formality 2005.09 5- 10
12
Compare Point Matching

 Fundamentals

 Challenges Posed by Design Compiler

 Synopsys Guidance Flow (DC and SVF Flow)

 Matching Designs without SVF

 Unmatched Objects

 Recommendations (Summary)

Formality 2005.09 5- 11
13
Synopsys Guidance Flow

 Addresses issue of different names in ref and impl

 Identifies and validates constant flip-flops

 Many other benefits too

 Based on Setup Verification Files (.svf)

Formality 2005.09 5- 12
14
Guidance Flow - Script

Set_guidance example.svf

Read_container –r r.fsc

Read_container –i i.fsc

match

Formality 2005.09 5- 13
15
Guidance Flow - Summary

 Its really that simple for basic compile flow!

 All information is validated

 Explicitly e.g. constant registers
 Implicitly name changes

 For more advanced design transformations user

setup may be required.
 See Section 7

Formality 2005.09 5- 14
16
Compare Point Matching

 Fundamentals

 Synopsys Guidance Flow (DC and SVF Flow)

 Changes Posed by Design Compiler

 Matching Designs without SVF

 Unmatched Objects

 Recommendations (Summary)

Formality 2005.09 5- 15
17
Compare Point Matching without SVF

 How does Formality match compare points?

 To help understand control techniques

 User control
 Compare Rules
 Filter Character
 Variables
 User Matches

 Strategy for Regular Name Changes

Formality 2005.09 5- 16
18
Compare Point Matching - Flow

1. Apply user guidance (if any)

1. Explicit matches from set_user_match command
2. Modify names in internal database using
change_names

2. Exact Name Matching

3. Signature Analysis

4. Topological Analysis

5. Subset Name matching

Formality 2005.09 5- 17
20
Exact Name Matching

 How does it work?

 First pass (in both Ref and Imp)
 Find instance names of objects to be matched
 Remove filter characters from names
 Break names into tokens
 Look for exact match based on tokens
 If there are unmatched points
 Similar technique on names of nets attached to

 Advice
 There are a number of control variables
 In general you should only need to alter setting of
name_match_filter_char_list

Formality 2005.09 5- 18
21
Exact Name Matching example

 Original names
 (REF) : $ref/a_reg[1]
 (IMP) : $impl/a_reg_1

 Break into tokens – remove filter characters

 (REF) : a?reg?1?
 (IMP) : a?reg?1?

 Compare tokens
 a == a, reg == reg, 1 == 1

 Formality matches these two compare points

Formality 2005.09 5- 19
22
Exact Name Matching - Quiz

 Which of the following pairs of objects will be

matched by exact name matching?

 (Insert a table)
 $ref/alu/a_reg[1] and $impl/alu/a_reg_1_
 $ref/alu/a_reg[1] and $impl/alu_a_reg_1_
 $ref/alu/a_reg[1] and $impl/alu_a_reg_1_v
 $ref/alu/a_reg[1] and $impl/alu/a_regy1y
 $ref/alu/a_reg[1] and $impl/alu_1_a_reg_1_

Formality 2005.09 5- 20
23
Exact Name Matching - Quiz

 How could you modify the filter list of filter

characters to match the following pairs of objects
by exact name matching?

1. $ref/alu/a_reg[1] and $impl/alu_a_reg_1_v

2. $ref/alu/a_reg[1] and $impl/alu/a_regy1y

Formality 2005.09 5- 21
24
Signature Analysis

 Signature analysis is turned on by default

 Signature analysis can do a good job at matching

points that would have otherwise remained
unmatched

 The disadvantage of signature analysis is that it

can take a lot of time to run

If you notice Formality spending a lot of time in signature analysis then

investigate – see Strategy for Regular Name Changes

Formality 2005.09 5- 22
26
Subset Name Matching

 A last attempt – looks for fuzzy matches based on

names

 Settings of name_match_allow_subset_match
 None – very safe
 Strict – default
 Any – some risk of incorrect matches

 Run after signature analysis because priority is

correct matches rather than speed

Formality 2005.09 5- 23
27
Regular Name Changes – a strategy

 If your design flow is reused

 But name changes are not exact name matches
 Create reusable Formality settings
 Append characters to filter char list
And/or
 Create compare rules
 To identify names not matched by exact name matching:
1. Disable signature analysis
Set signature_analysis_match_compare_points false
2. Disable subset name matching
Set name_match_allow_subset_match none

Formality 2005.09 5- 24
28
Reviewing unmatched by name points

 Look at list of unmatched points (or points

matched by SA)

 If you can fix it with name_match_filter_char list

that is easiest way.

 Can experiment using incremental matching and

undo matches

 If name_match_filter_char_list won’t work then use

compare rules

Formality 2005.09 5- 25
29
Write Compare Rules (1/2)

 If names have changed in a predictable way and many

compare points are unmatched as a result, you can write
a compare rule in SED syntax to translate the names in
one design to the corresponding names in the other
design:
 set_compare_rule
fm_shell (match)> set_compare_rule i:/WORK/chip –from reg_x -to {reg[}
fm_shell (match)> match

The GUI can write the SED syntax for you.

 To see the resulting translated names for still unmatched

compare points, use one of the following:
fm_shell (match)> report_unmatched -compare_rule
fm_shell (match)> report_failing -compare_rule

Formality 2005.09 5- 26
30
Write Compare Rules (2/2)

Exercise:
 Transformed name – sample 1:
 RegA[1] -> RegA_10
 RegA[31] -> RegA_310
Logically, how can you fix this with search and replace?

 Transformed name – sample 2:

 Pc_arb_bus[0] -> pcarb0
 Pc_arb_bus[31] -> pcarb31
Logically, how can you fix this with search and replace?

Formality 2005.09 5- 27
32
Compare Point Matching

 Fundamentals

 Synopsys Guidance Flow (DC and SVF Flow)

 Matching Designs without SVF

 Unmatched Objects

 Recommendations (Summary)

Formality 2005.09 5- 28
35
What can cause unmatched points?

 Design Objects do not have similar names

 Name-based algorithms no longer useful
 Signature analysis disabled or swamped

 Missing setup – e.g. constant on test_se

 Signature analysis will see different simulation results in ref
and impl
 Simulation/synthesis differences
 Full case
 Redundant registers removed by DC
 Unread registers

 Constant registers

 Inconsistent black-boxes in ref and impl

Formality 2005.09 5- 29
36
Unmatched Points: Summary
If tab 4.Match->Unmatched Points shows you have
unmatched points, use the following table to determine
what action you need to take.
Symptom Possible Cause Action
Same number of unmatched Names have - set user match
points in ref and imp undergone a - write compare rule
transformation - modify name_match* variables
- turn on signature analysis
- verify the fix with match
More unmatched points in ref DC has removed - no action necessary
than in imp Redundant regs
Ignoring a full case - change hdlin_ignore_full_case
directive in rtl code to false
black box was - read missing cells into ref
created for missing - make black box in imp
cells
More unmatched points in imp design - account for design
than in ref transformation transformation
created extra logic
black box was - read missing cells into imp
created for missing - make black box in ref
cells
Formality 2005.09 5- 30
37
Compare Point Matching

 Fundamentals

 Synopsys Guidance Flow (DC and SVF Flow)

 Matching Designs without SVF

 Unmatched Objects

 Recommendations (Summary)

Formality 2005.09 5- 31
38
Matching - Recommendations

 Use SVF files from DC for hassle free matching

 If you don’t use SVF files then handle regular name changes with:
 Name_match_filter_char_list

 And/Or compare name rules

 Ensure that matching is complete before verifying

 Check the matching summary for unmatched points
 Use report_unmatched to list unmatched points
 (If necessary) Use set_compare_rule and set_user_match to
complete matching of design
 Unmatched points may be a correct result
 But review before verifying!
 Incorrectly matched points will give a failing verification
 Can only check by verifying the design

Formality 2005.09 5- 32
39
Review Questions

1. How can SVF files help in matching compare points?

2. Which DC commands can slow Formality compare point

matching?

3. Which variable would you use to speed matching for regular

name changes. (Ex: all_reg[12] -> all_regx12x)

4. How would you use the matching summary message to

determine if there are any significant unmatched points

5. How would you match individual points from GUI or from

command line

Formality 2005.09 5- 40
Lab 5: Matching compare points

Lab 5 was compiled using the

“ungroup –simple_names”
command
1. Try matching the design using
the SVF file. How long does
matching take?
2. Try matching the design
without the SVF. How long
does it take? How many points
are matched by signature
analysis.
3. Can you successfully match
the design without signature
analysis or SVF?

Formality 2005.09 5- 25
41
Day 1 Agenda

DAY 1 Introduction to Formality

1
2 Getting Started with Formality

3 Basic Formality Flow

4 Reading Designs

5 Matching

6 Verification

Formality 2005.09
6- 1
Unit Objectives

After completing this unit, you should be able to:

 List and explain the 7 point types that appear in Formality’s summary
report for a verification
 Report failing and passing points
 Explain what an unread point is and how unread points can appear in
verification reports
 Exclude point(s) from verification
 Define the default number of failing points at which Formality will stop
verification, and how to change this limit
 Explain the difference between consistency mode and equality mode.
Give an example of when you might want to use equality mode.
 Explain how Formality handles undriven signals by default, and how
you can change this behavior

6- 2
Possible Results of Verification

 Verify command
fm_shell (match)> verify

 Possible Results
 Succeeded: implementation is equivalent to the reference

 Failed: implementation is not equivalent to the reference

 Inconclusive: no points failed, but analysis incomplete

 Analysis incomplete due to timeout or to complexity
 Module 9 will discuss techniques for very complex designs
 Not run: a problem earlier in the flow prevented verification from
running at all.
 See earlier sections
 This section will focus on Succeeded and Failed

6- 3
4
Successful Verification #1 (Transcript)

fm_shell (match)> verify

Reference design is 'r:/WORK/test'
Implementation design is 'i:/WORK/test'

*********************************** Matching Results ***********************************

16 Compare points matched by name
0 Compare points matched by signature analysis
0 Compare points matched by topology
9 Matched primary inputs, black-box outputs
0(0) Unmatched reference(implementation) compare points
0(0) Unmatched reference(implementation) primary inputs, black-box outputs
****************************************************************************************

Status: Verifying...

********************************* Verification Results *********************************

Verification SUCCEEDED
----------------------
Reference design: r:/WORK/test
Implementation design: i:/WORK/test
16 Passing compare points
----------------------------------------------------------------------------------------
Matched Compare Points BBPin Loop BBNet Cut Port DFF LAT TOTAL
----------------------------------------------------------------------------------------
Passing (equivalent) 0 0 0 0 8 8 0 16
Failing (not equivalent) 0 0 0 0 0 0 0 0
****************************************************************************************
fm_shell (verify)>

6- 4
5
Classification of Points

 BBPin - black-box pin compare points

 Loop - loop compare points

 BBNet - black-box-resolved multiply-driven nets

 Cut - cut-points

 Port - primary (top-level) ports

 DFF - DFF register

 LAT - latch register

(See on-line documentation for more details)

6- 5
7
Reporting Passing Points

 To report all passing points

 report_passing_points

 Restrict report to a particular compare point type

 report_passing_points –point_type
report_passing_points –point_type dff

 Restrict report by name

 report_passing_points –sub
report_passing_points –sub alu_reg

6- 6
8
When will a verification pass? (Default)

 If a compare point in reference is read:

 There must be a matching point in the implementation
 The signal value at the implementation point must
always be consistent with the value in the reference

 Can verification SUCCEED when

 There are unmatched points in the reference?
 There are unmatched points in the implementation?
 Signal value in the implementation differs from that in
reference?

6- 7
9
Successful Verification #2 (RTL)

module test (d, clk, q_op);

input clk;
input [7:0] d;
output [7:4] q_op;
reg [7:0] q;

always @ (posedge clk)

q <= d;

assign q_op = q[7:4];

endmodule

 Will DC build registers q_reg[3:0]?

6- 8
11
Successful Verification #2 (Gates)

module test ( d, clk, q_op );

input [7:0] d;
output [7:4] q_op;
input clk;

FD1 \q_reg[4] ( .D(d[4]), .CP(clk), .Q(q_op[4]) );

FD1 \q_reg[5] ( .D(d[5]), .CP(clk), .Q(q_op[5]) );
FD1 \q_reg[6] ( .D(d[6]), .CP(clk), .Q(q_op[6]) );
FD1 \q_reg[7] ( .D(d[7]), .CP(clk), .Q(q_op[7]) );

endmodule

 Compiled by DC using lsi_10k library

 How should Formality handle q_reg[3:0]?

6- 9
12
Successful Verification #2 (Transcript)
fm_shell (match)> verify
Reference design is 'r:/WORK/test'
Implementation design is 'i:/WORK/test'

*********************************** Matching Results ***********************************

8 Compare points matched by name
0 Compare points matched by signature analysis
0 Compare points matched by topology
5 Matched primary inputs, black-box outputs
0(0) Unmatched reference(implementation) compare points
0(0) Unmatched reference(implementation) primary inputs, black-box outputs
4(0) Unmatched reference(implementation) unread points

****************************************************************************************

Status: Verifying...

********************************* Verification Results *********************************

Verification SUCCEEDED
----------------------
Reference design: r:/WORK/test
Implementation design: i:/WORK/test
8 Passing compare points
----------------------------------------------------------------------------------------
Matched Compare Points BBPin Loop BBNet Cut Port DFF LAT TOTAL
----------------------------------------------------------------------------------------
Passing (equivalent) 0 0 0 0 8 8 0 16
Failing (not equivalent) 0 0 0 0 0 0 0 0
****************************************************************************************
fm_shell (verify)>

6- 10
13
Unread Points

 A point which is not connected to any downstream point

 Top-level output ports are never reported as unread
 To report unread points use
 report_unmatched –status unread
 For previous example:

fm_shell (verify)> report_unmatched -status unread

4 Unmatched points (4 reference, 0 implementation):

Ref DFF r:/WORK/test/q_reg[0]

Ref DFF r:/WORK/test/q_reg[1]

Ref DFF r:/WORK/test/q_reg[2]

Ref DFF r:/WORK/test/q_reg[3]

fm_shell (verify)>

6- 11
15
Successful Verification #3 (RTL)

module test (d, clk, q);

input clk;
input [7:0] d;
output q;
reg[7:0] last_d;

always @ (posedge clk)

last_d <= d;

assign q = last_d[7] && (last_d[7] ||

last_d[6] || last_d[5] || last_d[4] ||
last_d[3] || last_d[2] || last_d[1] ||
last_d[0]) ;

endmodule

 Will DC build registers last_d[6:0]?

 Hint – does the logic expression simplify?

6- 12
16
Successful Verification #3 (Gates)

module test ( d, clk, q );

input [7:0] d;
input clk;
output q;

FD1 \last_d_reg[7] ( .D(d[7]), .CP(clk), .Q(q) );

endmodule

 Compiled by DC using lsi_10k library

 How should Formality handle last_d_reg[6:0]?

6- 13
17
Successful Verification #3 (Transcript)
fm_shell (match)> verify
Reference design is 'r:/WORK/test'
Implementation design is 'i:/WORK/test'

*********************************** Matching Results ***********************************

2 Compare points matched by name

0 Compare points matched by signature analysis
0 Compare points matched by topology
2 Matched primary inputs, black-box outputs
7(0) Unmatched reference(implementation) compare points
0(0) Unmatched reference(implementation) primary inputs, black-box outputs
----------------------------------------------------------------------------------------

. . . . .
********************************* Verification Results *********************************
Verification SUCCEEDED
----------------------
Reference design: r:/WORK/test
Implementation design: i:/WORK/test
2 Passing compare points
----------------------------------------------------------------------------------------
Matched Compare Points BBPin Loop BBNet Cut Port DFF LAT TOTAL
----------------------------------------------------------------------------------------
Passing (equivalent) 0 0 0 0 1 1 0 2
Failing (not equivalent) 0 0 0 0 0 0 0 0
****************************************************************************************

fm_shell (verify)>

6- 14
18
Successful Verification #4 (Circuits)

// Reference
module test ( a, b, q1 );
input a, b;
output q1;
AN2 U2 ( .A(b), .B(a), .Z(q1) );
endmodule

//Implementation
module test ( a, b, q1, q2 );
input a, b;
output q1, q2;
wire n3, n4;
AN2 U2 ( .A(b), .B(a), .Z(q1) );
AN2 U5 ( .A(n3), .B(a), .Z(q2) );
IV U7 ( .A(b), .Z(n3) );
endmodule

6- 15
19
Successful Verification #4 (Transcript)

*********************************** Matching Results ***********************************

1 Compare points matched by name

0 Compare points matched by signature analysis
0 Compare points matched by topology
2 Matched primary inputs, black-box outputs
0(1) Unmatched reference(implementation) compare points
0(0) Unmatched reference(implementation) primary inputs, black-box outputs
----------------------------------------------------------------------------------------
. . . .
****************************************************************************************

Status: Verifying...

********************************* Verification Results *********************************

Verification SUCCEEDED
----------------------
Reference design: r:/WORK/test
Implementation design: i:/WORK/test
1 Passing compare points
----------------------------------------------------------------------------------------

Matched Compare Points BBPin Loop BBNet Cut Port DFF LAT TOTAL
----------------------------------------------------------------------------------------
Passing (equivalent) 0 0 0 0 1 0 0 1
Failing (not equivalent) 0 0 0 0 0 0 0 0
****************************************************************************************

fm_shell (verify)>

6- 16
20
Successful Verification #5 (Circuits)
// Reference
module test (d, q, r_w, clk);
input [3:0] d;
input r_w, clk;
output [3:0] q;

ram U1 (.d_in(d), .d_out(q),

.clk(clk), .r_w(r_w));

endmodule

//Implementation
module test (d, q, r_w, clk, te);
input [3:0] d;
input r_w, clk, te;
output [3:0] q;

ram_test U1 (.d_in(d), .d_out(q),

.clk(clk), .r_w(r_w),
.te(te));
endmodule

6- 17
21
Successful Verification #5 (Transcript)

*********************************** Matching Results ***********************************

10 Compare points matched by name

0 Compare points matched by signature analysis
0 Compare points matched by topology
2 Matched primary inputs, black-box outputs
0(1) Unmatched reference(implementation) compare points
0(1) Unmatched reference(implementation) primary inputs, black-box outputs
----------------------------------------------------------------------------------------
. . . .
****************************************************************************************

Status: Verifying...

********************************* Verification Results *********************************

Verification SUCCEEDED
----------------------
Reference design: r:/WORK/test
Implementation design: i:/WORK/test
10 Passing compare points
----------------------------------------------------------------------------------------

Matched Compare Points BBPin Loop BBNet Cut Port DFF LAT TOTAL
----------------------------------------------------------------------------------------
Passing (equivalent) 6 0 0 0 4 0 0 10
Failing (not equivalent) 0 0 0 0 0 0 0 0
****************************************************************************************

fm_shell (verify)>

6- 18
23
Successful Verification #6 (Circuits)

// From Reference
case (q)
4'b0001 : q <= 4'b0010 ;
4'b0010 : q <= 4'b0100 ;
4'b0100 : q <= 4'b1000 ;
4'b1000 : q <= 4'b0001 ;
default : q <= 4'bXXXX ;
endcase

//From Implementation
FD1 \q_reg[0] ( .D(N15), .CP(clk), .Q(q[0]) );
FDS2 \q_reg[1] ( .D(q[0]), .CP(clk), .CR(n2), .Q(q[1]));
FDS2 \q_reg[2] ( .D(q[1]), .CP(clk), .CR(n2), .Q(q[2]));
FDS2 \q_reg[3] ( .D(q[2]), .CP(clk), .CR(n2), .Q(q[3]), .QN(net2));
ND2 U5 ( .A(n2), .B(net2), .Z(N15) );
IV U6 ( .A(start), .Z(n2) );

 What is next state of q after 4’b0011?

6- 19
24
Successful Verification #6 (Transcript)

*********************************** Matching Results ***********************************

8 Compare points matched by name

0 Compare points matched by signature analysis
0 Compare points matched by topology
2 Matched primary inputs, black-box outputs
0(1) Unmatched reference(implementation) compare points
0(0) Unmatched reference(implementation) primary inputs, black-box outputs
----------------------------------------------------------------------------------------
. . . .
****************************************************************************************

Status: Verifying...

********************************* Verification Results *********************************

Verification SUCCEEDED
----------------------
Reference design: r:/WORK/test
Implementation design: i:/WORK/test
8 Passing compare points
----------------------------------------------------------------------------------------

Matched Compare Points BBPin Loop BBNet Cut Port DFF LAT TOTAL
----------------------------------------------------------------------------------------
Passing (equivalent) 0 0 0 0 4 4 0 1
Failing (not equivalent) 0 0 0 0 0 0 0 0
****************************************************************************************

fm_shell (verify)>

6- 20
26
Failed Verification #1 (Transcript)

fm_shell (match)> verify

Reference design is 'r:/WORK/test'
Implementation design is 'i:/WORK/test'

*********************************** Matching Results ***********************************

16 Compare points matched by name
0 Compare points matched by signature analysis
0 Compare points matched by topology
9 Matched primary inputs, black-box outputs
0(0) Unmatched reference(implementation) compare points
0(0) Unmatched reference(implementation) primary inputs, black-box outputs
****************************************************************************************

Status: Verifying...

********************************* Verification Results *********************************

Verification SUCCEEDED
----------------------
Reference design: r:/WORK/test
Implementation design: i:/WORK/test
14 Passing compare points
----------------------------------------------------------------------------------------
Matched Compare Points BBPin Loop BBNet Cut Port DFF LAT TOTAL
----------------------------------------------------------------------------------------
Passing (equivalent) 0 0 0 0 8 6 0 14
Failing (not equivalent) 0 0 0 0 0 2 0 0
****************************************************************************************
fm_shell (verify)>

6- 21
27
Reporting Failing Points

 To report all failing points

 report_failing_points

 Restrict report to a particular compare point type

 report_failing_points –point_type
report_failing_points –point_type dff

 Restrict report by name

 report_failing_points –sub
report_failing_points –sub alu_reg

6- 22
29
When will a verification fail? (Default)

 If a compare point in reference is read:

 But the signal value at the matched implementation
point is not always consistent with the value in the
reference
 We will discuss such cases in the debug section
 But there is no matched point in the implementation

6- 23
30
Failed Verification #2 (Transcript)
verify
Reference design is 'r:/WORK/test'
Implementation design is 'i:/WORK/test'

*********************************** Matching Results ***********************************

1 Compare points matched by name

0 Compare points matched by signature analysis
0 Compare points matched by topology
2 Matched primary inputs, black-box outputs
1(0) Unmatched reference(implementation) compare points
0(0) Unmatched reference(implementation) primary inputs, black-box outputs
----------------------------------------------------------------------------------------
. . .
Status: Verifying...

********************************* Verification Results *********************************

Verification FAILED
-------------------
Reference design: r:/WORK/test
Implementation design: i:/WORK/test
1 Passing compare points
1 Failing compare points
0 Aborted compare points
----------------------------------------------------------------------------------------
Matched Compare Points BBPin Loop BBNet Cut Port DFF LAT TOTAL
----------------------------------------------------------------------------------------
Passing (equivalent) 0 0 0 0 1 0 0 1
Failing (not equivalent) 0 0 0 0 0 0 0 0
****************************************************************************************
0

6- 24
31
Failing Verification – Example #3

 (By default) Formality stops when there are 20

failing points
 Remaining points reported as aborted

 You can change behavior with variable

 verification_failing_point_limit

6- 25
32
Failing Verification #3 (Transcript)

********************************* Verification Results *********************************

Verification FAILED
----------------------
Reference design: r:/WORK/test
Implementation design: i:/WORK/test
34 Passing compare points
20 Failing compare points
14 Aborted compare points

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

Matched Compare Points BBPin Loop BBNet Cut Port DFF LAT TOTAL
----------------------------------------------------------------------------------------
Passing (equivalent) 0 0 0 0 34 0 0 34
Failing (not equivalent) 0 0 0 0 0 20 0 0
Aborted
Unver (^C/limit hit) 0 0 0 0 0 14 0 14
****************************************************************************************

fm_shell (verify)>

6- 26
33
Review Questions

1. What are the 7 point types that appear in Formality’s

summary report for a verification?
2. How would you generate a list of failing (passing) points?
3. What is an unread point and where would it appear in the
verification summary report?
4. How would you exclude point(s) from verification?
5. What is the variable which determines the number of failing
points at which Formality will stop verification? What is its
default value?
6. What is the difference between consistency mode and
equality mode. Give an example of when you might want to
use equality mode.
7. How does Formality handles undriven signals by default?
How you can change this behavior

6- 27
34
Lab 6: Verification

Lab 6 – will give a failing

verification
1. From the transcript can you
suggest why verification fails?
2. Can you check that your
hypothesis explain all the
failing points? (No RTL
changes or re-synthesis)

6- 28
35
Command Summary - 1
verify Verify design

report_passing_points Generates report

-point_type <point_type> Option on report

generation
-inputs <undriven | Option on report
unmatched> generation
report_failing_points Generates report

–point_type Option on report

generation
–matched / -unmatched Option on report
generation
-inputs Option on report
generation

6- 29
36
Command Summary - 2
set_dont_verify Exclude point(s) from
verification
remove_dont_verify Undo exclusion of point(s)
from verification
report_dont_verify Generate report listing all
points that are excluded from
verification

6- 30
37
Variables Summary
verification_failing_point_limit Determines when
verification will stop if
there are failing points
verification_passing_mode Determines if passing
points are required to be
exact matches or
consistent
verification_set_undriven_signals Determines how undriven
signals are modeled
verification_status Read only variable. Useful
for tcl scripts.

6- 31
38
Day 2 Agenda

DAY 7 Advanced Setup – Design Transforms

2
8 Debug

9 Advanced Usage

Formality 2005.09 7- 1
Unit Objectives

After completing this unit, you should be able to:

 Explain how valid design transformations can cause a

failing verification

 Describe such design transformations in the Synopsys

synthesis flow from
 Design Compiler
 Power Compiler
 DFT Compiler

 Handle these design transformations in Formality by

using advanced setup commands

Formality 2005.09 7- 2
Two Key Concepts - reminder

A design contains Logic Cones and Compare Points

Compare Point

Logic
Cone
BB
BB

Inputs Compare Points

• Outputs from Registers • Inputs to Registers

• Primary Input Ports • Primary Output Ports
• Outputs from Black Boxes • Inputs to Black Boxes

Formality 2005.09 7- 3
4
Difficult Design Transformations

 Verification will fail for design transformations that

 Change the logic function of individual cones
 Change register boundaries

 Transformations can impact matching as well as

verification

 How does Formality handle (internally)?

 “Turns off” function changes in implementation
 Re-adjusts register boundaries

 But Formality requires guidance from user or SVF

Formality 2005.09 7- 4
5
Examples from Synopsys synthesis flow

 DFT Compiler
 Internal Scan

 BSD Compiler
 Boundary Scan

 Power Compiler
 Clock Gating

 Design Compiler
 Constant Register Removal
 Pipeline retiming
 FSM Optimization

Formality 2005.09 7- 5
6
Formality Flow Reminder

Start

Setup
Read Reference
Design + Libs
Match
set_top
Debug
Verify

Read Implementation Success

Design + Libs ? N
Y
set_top
End

Formality 2005.09 7- 6
8
Internal Scan: What Is It?

 Implemented by DFT Compiler

 Replaces flip-flops with scan flops
 Connects scan flops into shift registers or “scan chains”

 The scan chains make it easier to set and observe

the state of registers internal to a design for
manufacturing test

Formality 2005.09 7- 7
9
Internal Scan: Why It Requires Attention

The additional logic added during scan insertion

means that the combinational function has changed.

data_in D Q D Q D Q data_out

clk
Pre-Scan
Post-Scan

data_in D Q D Q D Q data_out
scan_in si so si so si so scan_out
scan_en se se se

clk

Formality 2005.09 7- 8
11
Internal Scan: How to Deal With It

 Determine which pins disable the scan circuitry

 Default for DFT Compiler is test_se

 Set those pin(s) to the inactive state using the

set_constant command

fm_shell (setup) > set_constant i:/WORK/TOP/test_se 0

Formality 2005.09 7- 9
13
Boundary Scan: What Is It?

 Boundary scan is similar to internal scan in that it

involves the addition of logic to a design:
 The added logic makes it possible to set and or observe
the logic values at the primary inputs and outputs (the
boundaries) of a chip
 Used in manufacturing test at board and system level
 Added by BSD Compiler

 Boundary scan is also referred to as

 The IEEE 1149.1 specification
 JTAG

Formality 2005.09 7- 10
15
Boundary Scan: Why It Requires Attention
 The logic cones at the primary outputs are different
 The logic cones driven by primary inputs are different
 The design has extra state holding elements
Pre-Boundary Scan Post-Boundary Scan

data1 out1
data1 out1
DQ

data2 data2 out2

out2
DQ

data3 out3
data3 out3 Tap
DQ
Controller

Formality 2005.09 7- 11
17
Boundary Scan: How to Deal With It

 Disable the Boundary scan:

 If the design has an optional asynchronous TAP reset
pin (such as TRSTZ or TRSTN), use set_constant
on the pin to disable to scan cells
 If the design only has the 4 mandatory TAP inputs
(TMS, TCK, TDI and TDO), you will have to force an
internal net of the design; again, use the
set_constant command
fm_shell (setup) > set_constant i:/WORK/TOP/TRSTZ 0
fm_shell (setup) > set_constant i:/WORK/alu/somenet 0

Formality 2005.09 7- 12
19
Clock Gating: What Is It?

 Added by Power Compiler

 Clock gating is the addition of logic in a register’s
clock path which disables the clock when the
register output is not changing
 The purpose of clock gating is to save power by not
clocking register cells unnecessarily

Formality 2005.09 7- 13
21
Clock Gating
Before Clock Gating
0
1
Data In
DQ Data Out

CLK Register Bank

Data In DQ Data Out

DQ

GN
clken

Register Bank
CLK
Formality 2005.09 7- 14
23
Clock Gating: Why Is It an Issue?

 Without user intervention, two failing points will result:

 A compare point will be created for the clock gating latch
 This compare point does not have a matching point in the
other design and will fail
 The logic feeding the clock input of the register bank has
changed
 The compare points created at the register bank will fail

Formality 2005.09 7- 15
25
Clock Gating: How to Deal with It

 Set the variable: verification_clock_gate_hold_mode

 Four possible values:
 None - default
 Low - allows clock gating that holds the clock low when
inactive (often latch based)
 High - allows clock gating that holds the clock high when
inactive (often combinational)
 Any - allows for both low and high clock gating in the same
design

fm_shell (setup)> set verification_clock_gate_hold_mode any

Formality 2005.09 7- 16
27
Clock Gating: Things to Be Aware Of

 When using combinational logic to gate the clock,

Formality will not detect glitches:
 Use a static timing tool such as PrimeTime

 verification_clock_gate_hold_mode affects
the entire design:
 It can not be placed on a single instance

Formality 2005.09 7- 17
29
Constant Register Removal – the Problem

 DC will remove registers that are constant

 If Formality recognizes that these registers are

constant then verification will pass

 Problem if Formality does not recognize register as

constant
 If RTL says register can go to 0 or X, then DC may
choose to make register constant 0
 Formality will not recognize such a register as constant
0

Formality 2005.09 7- 18
31
Constant Register – The solution

 Use SVF

 SVF will indicate which registers are treated by DC

as cosntant 0 (1)

 Formality
 Verifies that register can only go to 0 (or X)
 For downstream verification uses constant 0

Formality 2005.09 7- 19
32
Pipeline Retiming: What Is It? (1/2)

 Retiming a design involves moving logic across register

boundaries

 It is done to meet timing and area constraints

 Retiming can occur during synthesis (balance_registers)

or by making manual changes to a design

Formality 2005.09 7- 20
33
Pipeline Retiming: What Is It? (2/2)

 Although the sequential behavior of the overall design

is not changed, the register to register behavior is
 Individual logic cones will fail
 New logic cones may appear in one design which do
not occur in the other

D Q
D Q

D Q

Before Re-timing After Re-timing

Formality 2005.09 7- 21
35
Pipeline Retiming: How to Deal With It

 You must tell Formality which block was retimed

by setting the -retimed parameter on that block

 Exception
 DesignWare DW02_n_stage_mult components
 Formality recognizes and retimes automatically

 Formality applies special solvers to verify the

retimed block

fm_shell (setup)> set_parameter -retime i:/WORK/add_pipe

Formality 2005.09 7- 22
37
Retiming: Things to Be Aware of

 The number of pipeline stages must be the same in

both designs to be verified:
 The number of registers can be different

 Retimed sequential loops require 2005.09

 Retiming can significantly affect performance:

 Use only on modules that were retimed

Formality 2005.09 7- 23
39
Re-encoded FSM: What is it?

Formality 2005.09 7- 25
41
Re-encoded FSM - Options

 In order to verify Formality needs to know

 The state registers involved in $ref and $impl
 The encoding for each state in $ref and $impl
 That is a lot of information!

 To provide this information you can

(In order of preference)
1. Use SVF
2. Use DC report_fsm command & read into Formality
3. Hand–code the information into a tcl script

Formality 2005.09 7- 26
43
Re-encoded FSM: SVF Solution

dc_shell > set_svf design.svf

fm_shell (setup)> set_svf design.svf

Operation :
fsm_reencoding
Current design :
Design_A
Previous state vector :
State_reg[1]
State_reg[0]
Text version of Current state vector :
file state_info S3
S2
S1
S0
State reencoding :
begin : 2#00 -> 2#0001
state1 : 2#01 -> 2#0010
state2 : 2#10 -> 2#0100
end : 2#11 -> 2#1000
Formality 2005.09 7- 27
44
Re-encoded FSM: SVF Solution

 By default Formality ignores FSM info in SVF

because there is no way for Formality to
independently prove it is correct

 User must explicitly tell Formality to use FSM info:

fm_shell (setup)> set svf_ignore_unqualified_fsm_information

false

Formality 2005.09 7- 27
45
Re-encoded FSM: DC report_fsm

 Formality accepts the file generated from the

report_fsm command from dc_shell
dc_shell > report_fsm > state_info
fm_shell (setup)> read_fsm_states state_info $ref

.state_vector
s_reg[0]
s_reg[1]
File state_info
.encoding
rd 16#0
wr 16#1
rs 16#2

Formality 2005.09 7- 28
47
Re-encoded FSM: FM commands

 Two commands tell Formality the name of the

registers holding the state vector and the encoding:
 set_fsm_state_vector - identifies state registers
 set_fsm_encoding - defines state encoding
fm_shell (setup)> set_fsm_state_vector {s_reg[0] s_reg[1]} $ref
fm_shell (setup)> set_fsm_encoding {rd=2#00 wr=2#01 rs=2#10} $ref
fm_shell (setup)>
fm_shell (setup)> set_fsm_state_vector {reg0 reg1 reg2} $impl
fm_shell (setup)> set_fsm_encoding {rd=2#000 wr=2#010 rs=2#100} $impl

Formality 2005.09 7- 29
49
Re-encoded FSM: Things to Be Aware Of

 Number of states in each state machine must be

the same:
 Number of state bits can be different (a one-hot machine
can be verified against a binary encoded machine)
 Number of states must be the same (exception:
Formality can handle when unused states are optimized
away)

Formality 2005.09 7- 30
51
Review Questions

1. What are six common design transformations in

the Synopsys synthesis flow?

2. Why can each of these transformations cause a

failing verification in Formality?

3. When running Formality, how do you handle these

design transformations?

Formality 2005.09 7- 31
53
Day 2 Agenda

DAY 7 Advanced Setup – Design Transforms

2
8 Debug

9 Advanced Usage

Formality 2005.09 8- 1
Unit Objectives

After completing this unit, you should be able to:

1. Apply the recommended debugging

procedure to a failing verification

2. List the failing points

3. Run Error Diagnosis to isolate setup errors or

errors in implementation

4. Use Pattern Window and Logic Cone Display

to investigate failures that are not isolated by
Error Diagnosis.
Formality 2005.09 8- 2
Formality Flow Overview (review)

Start

0: Guidance
3: Setup
Specify Automated Setup File

1: Read Reference 4: Match

Design + Libs 6: Debug
5: Verify
set_top

Success
2: Read Implementation ? N
Design + Libs Y

set_top End

Formality 2005.09 8- 3
Debugging Flow Chart

Start
display failing 3: Setup
points

run diagnosis change setup

resolve black boxes

unmatche N
Problem Design Fix
identified? Error?
d
points?
design
Y
choose point
Check for failing to debug
SVF operations

display pattern
change setup window

display logic isolate

cone difference
4: Match

Formality 2005.09 8- 4
Resolving Black Boxes

 Use report_black_box command

fm_shell (setup)> report_black_box

Formality 2005.09 8- 5
Unmatched points - example

fm_shell (verify)> verify

Reference design is 'r:/WORK/chip'
Implementation design is 'i:/WORK/chip'

******************************* Matching Results *******************************

258 Compare points matched previously
0 Compare points matched by name
0 Compare points matched by signature analysis
0 Compare points matched by topology
128(128) Unmatched reference(implementation) compare points
0(0) Unmatched reference(implementation) primary inputs, black box outputs
--------------------------------------------------------------------------------
Unmatched Objects REF IMPL
--------------------------------------------------------------------------------
Registers 128 128
DFF 128 128
********************************************************************************

***************************** Verification Results *****************************

Verification FAILED
-------------------
Reference design: r:/WORK/chip
Implementation design: i:/WORK/chip
130 Passing compare points
20 Failing compare points
108 Aborted compare points
--------------------------------------------------------------------------------
Matched Compare Points BBPin Loop Net BlPin Port DFF LAT TOTAL
--------------------------------------------------------------------------------
Passing (equivalent) 2 0 0 0 128 0 0 130
Failing (not equivalent) 0 0 0 0 0 20 0 20
Aborted
Unver (^C/limit hit) 0 0 0 0 0 108 0 108
********************************************************************************
Formality 2005.09 8- 6
Unmatched Points – Clues to Identify Causes

Symptom Possible Cause Action

More unmatched points in ref than FM is ignoring full case - change hdlin_ignore_full_case to false
in imp DC removed constant registers - check for failed SVF operations
- adjust FM reg init settings
- read missing cells into ref
Black box in ref
- make black box in imp
- check for failed SVF operations
Re-encoded FSM
- apply FSM reencoding manually
More unmatched points in imp than Design transformation created - check for failed SVF operations
in ref extra logic - set verification_clock_gate_hold_mode
- read missing cells into imp
Black box in ref
- make black box in ref
- check for failed SVF operations
Re-encoded FSM
- apply FSM reencoding manually

Insertion of test - disable test with set_constant

Same number of unmatched points Names have undergone a - check for failed SVF operations
in ref and imp transformation - set user match
- write compare rule
- modify name_match* variables

Formality 2005.09 8- 7
Unmatched Points – The 5 Main Causes

1. Failing SVF operations

 guide_reg_constant
 guide_fsm_reencoding
 guide_change_names
 guide_uniquify, guide_ununiquify
2. Inconsistent black-boxes in ref and impl
3. Simulation/synthesis differences
 Remember to check if full_case or parallel_case pragmas are used
4. Missing setup
5. Constant register removal or name change not recorded in SVF
• Report to Synopsys if you encounter this

Formality 2005.09 8- 8
Displaying Unmatched Points

 To display list of unmatched points in the shell:

fm_shell (verify)> report_unmatched

 See Section 4 for guidance on investigating / fixing

 Remember! Unmatched points are sometimes OK but you
should review them to make sure before continuing

Formality 2005.09 8- 9
Display Failing Points

 Once the unmatched points have been accounted

for, you can start debugging the failing points:
 Use report_failing_points to get a list of the failing points

Formality 2005.09 8- 10
Display Failing Points - GUI

 Display Information from the GUI:

Formality 2005.09 8- 11
Diagnosis

 Run diagnosis

 Creates a set of failing test vectors

 Performs an analysis of the failing vectors to help

pinpoint the cells in the logic cones that are causing the
failure

Formality 2005.09 8- 12
Error Diagnosis Vocabulary

 Error – Location of error in implementation design

 Error Candidates – Set of Errors / Alternates

Examples

Single error detected in implementation design.

Number of error candidates: 2

2 distinct errors detected in implementation design.

Number of error candidates: 3

 Matching regions in the reference design

 areas in the reference design that corresponded to the
diagnosed error in the implementation.

Formality 2005.09 8- 13
How does it work?

 The algorithm works by analyzing intersecting path traces for all

failing compare points.
 If all the path traces intersect with each other, it may indicate the
presence of a single error.
 If no single error is identified, the algorithm enters an iterative
stage of multiple error diagnosis.
 If there are too many errors ( >5 ), the algorithm fails to report any
error candidates. In such cases, the user can do a directed
diagnosis by specifying a subset list of failing points.

Formality 2005.09 8- 14
Path Trace Procedure : example

0 1 0 1 1 0 1 1 1 0 1 1 0 1 0
A B C D E A B C D E A B C D E A B C D E

X1 X2 X1 X2 X1 X2 X1 X2

0 1 1 0 0 1

X3 X4 X3 X4 X3 X4 X3 X4
0 0 1 0 1 0

X5 X6 X5 X6 X5 X6 X5 X6

O1 O2 O1 O2 O1 O2 O1 O2
0 0 0 0 0 0

Formality 2005.09 8- 15
Path Trace Procedure : example

0 1 0 1 1 0 1 1 1 0 1 1 0 1 0
A B C D E A B C D E A B C D E A B C D E

X1 X2

X3 X4 X4 X4 X4

X5 X6

O1 O2 O1 O2 O1 O2 O1 O2

Formality 2005.09 8- 16
Example: Start with a failing verification and click diagnose button

Formality 2005.09 8- 17
Diagnosed Error Window: After diagnosis completes

Formality 2005.09 8- 18
Viewing error logic cone

Formality 2005.09 8- 19
Which failing compare do you want to debug?

Formality 2005.09 8- 20
Schematic zooms to failing gate and matching region

Formality 2005.09 8- 21
Pruning button – Shows the failing path

Formality 2005.09 8- 22
Diagnosing subset of failing points

 Diagnosis is unable to determine an error candidate (FM-417, FM-

420)
 Check for setup problems
 Select subset from failing points window
 Select signals with common names ( ex. 32 bit bus )
 Windows type selection
 Click then shift-click selects group between
 Click then ctrl-click selects individual
 Click “Diagnose Selected Points” button
 Final Straw: Diagnose a single point
 Diagnosis accuracy drops with fewer failing points

Formality 2005.09 8- 23
TCL commands and variables

 diagnose – Run diagnosis from the command line

 report_error_candidates – Text list of error candidates
 report_diagnosed_matching_regions – Text list of matching
regions
 diagnosis_enable_find_matching_regions – The display of
matching region is on by default. Can be disabled.
 diagnosis_cone_size_limit – maximum size of failing point
cone

Formality 2005.09 8- 24
Things to watch for…

 Diagnosis may not find an error. Try selected failing points

 Diagnosis may not find a matching region

 Logic cone sizes > 50000 are not diagnosed by default. See
diagnosis_cone_size_limit

 Large amount of failing points ( > 100 ) can cause

performance of diagnosis to degrade. Verify with
verification_failing_point_limit set to default (20)

Formality 2005.09 8- 25
If Error Diagnosis is unable to isolate the problem?

 Pick a point to debug by inspection

 You want to debug the failing point which will show the
design difference as quickly and easily as possible:
 Start with primary outputs
 You know the designs are equivalent at primary outputs
and that internal points might have different logic cones
due to changes like boundary optimization or inversion
propagation
 Look for a point which is not part of a vector
 Pick the smallest cone to debug

Formality 2005.09 8- 27
26
Show Cone Sizes

 Show cone sizes:

Formality 2005.09 8- 28
27
Display Pattern Window

Formality 2005.09 8- 29
28
Display Pattern Window – Look for Clues

 2 Benefits of Pattern Window

2 1

Formality 2005.09 8- 30
29
Display Logic Cone

Formality 2005.09 8- 31
30
Isolate Difference

 Prune logic to reduce

complexity:
 Manually using
Isolate/Remove
Subcone
 Automatically using
Remove Non-
Controlling

Formality 2005.09 8- 32
31
Review Questions

1. How would you list the failing points from a failing

verification

2. Which command attempts to isolate setup errors

or errors in implementation for you?

3. What would you try if Formality reports that it is

unable to determine an error candiate?

4. How would you select a compare point for debug

by inspection?

5. Which Formality features would you use to help

you investigate a failing point?

Formality 2005.09 8- 33
32
Day 2 Agenda

DAY 7 Advanced Setup – Design Transforms

2
8 Debug

9 Advanced Usage

Formality 2005.09 9- 1
Unit Objectives

After completing this unit, you should be able to:

1. Use the distributed processing option

2. Run a single point verification

3. Exploit incremental verification capabilities

4. Generate a hierarchical verification script

5. Describe some potential causes of false

failures when verifying a design
hierarchically
Formality 2005.09 9- 2
Formality Advanced Usage

 So far in this class all the verifications have run:

 On a single machine
 On all points
 In a single pass
 On the complete design
 Top-down

 This section will explore relaxing these restrictions

Formality 2005.09 9- 3
Topics

 Distributed processing

 Single point verification

 Incremental verification

 Hierarchical Verification
 Changing level with $ref, $impl
 Problems of bottom-up
 Hier-IQ
 Write_hierarchical_script
 Manual intervention

Formality 2005.09 9- 4
Formality® Distributed Verification
Distribute load across 4 processors for faster run time

Master process
• Reads design
• Matches design
• Sends partitions out for verification
• Debug design

2 Processors 1 Processor 1 Processor

Verify Verify Verify
Verify
Formality 2005.09 9- 5
Distributed Verification

 Distributes verification task among up to 4

processors
 Significant improvement in time-to-results
 Recommended for use when design:
 is >250k gates, and
 Takes >2 hours to verify

 Based on Formality dividing design into partitions

 Partitioning is not user visible or controllable

Formality 2005.09 9- 6
Distributed Verification - Example
• Design contains 9 verification partitions
• One partition takes 60 minutes to verify
• Remaining partitions take 10 minute
• Sent to 3 distributed processors

Serial verification: 140 minutes

Parallel verification: 60 minutes
Verification improvement: 2.3X 60m 10m 10m
10m 10m
If read and match took 20 minutes time- 10m 10m
to-results improvement: 2X 10m 10m

Formality 2005.09 9- 7
Distributed Verification

 Distributed verification is enabled by default

 To add distributed processors:

add_distributed_processors [list of machines]

 To use with LSF:

add_distributed_processors –lsf bsub_exec –
nservers 4 –toptions “optionslist”

Formality 2005.09 9- 8
Single Point Verification

 You can verify a single point:

 Against another point
 Against another point for inverse relationship
 Against a constant

fm_shell (match)> verify $ref/reg_a $impl/reg_a_reg

fm_shell (match)> verify $ref/reg_a $impl/reg_a_reg -inverted
fm_shell (match)> verify $ref/reg_a –constant1

Formality 2005.09 9- 9
Incremental Verification -1

fm_shell (match)> verify -incremental

 To resume verification
 Useful after a verification has timed out
 Preserves failing and passing points
 Works on inconclusive points only
 Ignores changes in setup or matching
 Changes may invalidate previous results

 Default behavior
 You do not need to enter the -incremental

Formality 2005.09 9- 10
Incremental Verification -2

fm_shell (match)> verify -restart

 To restart verification
 Works on all points
 Previous verification results are ignored
 Respects changes in setup or user matches
 Will rerun matching if there are changes

Formality 2005.09 9- 11
Changing design to be verified

 So far we have worked from top of design

 We have used the command set_top
 Elaborates and links design
 Automatically sets $ref (or $impl)

 But you can change reference and implementation

 set_reference_design r:/*/alu
 set_implementation_design i:/*/alu_0

Formality 2005.09 9- 12
Caution

 Verifying sub-blocks of design can result in false

failures!

 Can you suggest some possible reasons?

Formality 2005.09 9- 13
Hierarchical Verification - Background

 Previous generations of EC tools faced a choice:

 Bottom-Up/Hierarchical Verification
 Lost time with non-equivalent lower blocks (see below)
 Setup required
 Unpredictable memory usage
 Flat Verification
 Increased complexity
 Large memory consumption

 Formality “Hier-IQ” changed the rules

Formality 2005.09 9- 14
Hier-IQ reduces need for bottom-up verification

 Breaks design into partitions

 Predictable memory usage

 Top-down but exploits hierarchical information

 Simplifies setup
 Reduces complexity of verification

 (In general) no need for bottom-up verification for

performance reasons
 Please report exceptions

 Bottom-up still useful when

 Debugging a failing verification
 Checking a change in one portion of the design

Formality 2005.09 9- 16
15
Why can bottom-up give false failures?

 A sub-block is optimized “in context”

 Bottom-up verification verifies it “out of context”

 Potential problems:
 Equivalent input ports (e.g. clock buffering)
 Constant inputs that are optimized in implementation
 More complex constraints on input ports
 Unread output ports optimized in implementation
 Equivalent output ports on black-boxed modules
 Constant output ports on black-boxed modules

Formality 2005.09 9- 17
16
Example - Clock Tree Buffering

Clock tree buffering is the addition of buffers in

the clock path to allow the clock signal to drive
large loads.
Pre-Buffering Post-Buffering
top top

blocka clk_buf blocka

ff1 clk ff1
D Q D Q
clk clk1
clk
ff2 ff2
D Q D Q
clk clk2

ff3 ff3
D Q D Q
clk clk3

Formality 2005.09 9- 18
Clock Tree Buffering: Why It Requires Attention

 Without user intervention, a verification of top,

which instantiates blocka, will succeed

 Without additional setup, a module-level

verification of blocka will fail because:
 The pre-buffer blocka has one clock port; the post-buffer
design has three
 In the pre-buffer design the clock pin of ff3 is clk
 In the post-buffer design the clock pin of ff3 is clk3

Formality 2005.09 9- 19
Automated Solution

 If you need to verify design bottom-up

 Use command
write_hierarchical_verification_script

 Generates script that

 Performs bottom-up verification
 Attempts to avoid false negatives by:
 Marking equivalent unmatched input ports
 Setting constants on input ports driven by constants
 Masking unread outputs

Formality 2005.09 9- 20
21
Manual hierarchical or bottom-up verification

 Formality does support manual bottom-up

verification

 Commands required
 Set_black_box
 Set_constant
 Set_dont_verify
 Set_user_match

 Warning
 Be very cautious about using set_equivalence!

Formality 2005.09 9- 21
22
Example – Hierarchical Verification

How to verify topa?

Pre-Buffering Post-Buffering
top top

blocka clk_buf blocka

ff1 clk ff1
D Q D Q
clk clk1
clk
ff2 ff2
D Q D Q
clk clk2

ff3 ff3
D Q D Q
clk clk3

Formality 2005.09 9- 22
23
Clock Tree Buffering: How to Deal With It

 Use the set_user_match command to tell Formality

that the buffered clock pins are equivalent:

fm_shell (setup)> set_reference_design r:/WORK/blocka

fm_shell (setup)> set_implementation_design i:/WORK/blocka
fm_shell (setup)> set_user_match r:/WORK/blocka/clk \
i:/WORK/blocka/clk1 \
i:/WORK/blocka/clk2 \
i:/WORK/blocka/clk3
fm_shell (setup)> verify

Formality 2005.09 9- 23
24
Review Questions

1. What command would you use to distribute verification

across several processors?

2. How would you verify a single point?

3. How would you restart a timed out verification – if you

wanted to preserve previous verification results?

4. How would you restart a timed out verification – if you

wanted to start the verification all over?

5. How would you generate a hierarchical verification script?

6. Describe some potential causes of false failures when

verifying a design hierarchically

Formality 2005.09 9- 24
26