0% found this document useful (0 votes)
62 views12 pages

Confrmal Tools

The document outlines the functionalities and modes of Conformal tools used for design verification, including Conformal L, XL, and GXL, which support various data path architectures and equivalence checking. It details the processes of mapping and comparing designs, emphasizing the importance of key points, compare points, and the need for accurate mapping to ensure logical equivalence across design iterations. Additionally, it describes commands for managing blackboxes, applying design constraints, and resolving mapping issues during the verification process.

Uploaded by

Veeresh 6j
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as TXT, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
62 views12 pages

Confrmal Tools

The document outlines the functionalities and modes of Conformal tools used for design verification, including Conformal L, XL, and GXL, which support various data path architectures and equivalence checking. It details the processes of mapping and comparing designs, emphasizing the importance of key points, compare points, and the need for accurate mapping to ensure logical equivalence across design iterations. Additionally, it describes commands for managing blackboxes, applying design constraints, and resolving mapping issues during the verification process.

Uploaded by

Veeresh 6j
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as TXT, PDF, TXT or read online on Scribd
You are on page 1/ 12

Confrmal tools :

Conformal L : for the synthesis and pnr


Conformal XL : For the complex data path (Conformal L+ )
●Operator merging, advanced pipelining.
●Supports a wide variety of datapath architectures
Conformal GXL : Verifies custom logic , custom memories and std
cells, verifies final lvs netlist ( Conformal XL+)

Conformal modes : There are 2modes setup mode and lec mode
setup mode: ▪ Reading VHDL and Verilog Designs and Libraries
▪ Reading Verilog Designs and Specifying Blackboxes
LEC mode : ▪ Using Renaming Rules to Complete Key Point
Mapping
▪ Debugging Nonequivalent Key Points

why LEC : During development, a chip design undergoes numerous transformations and
iterations
before the final layout –and each step in this process has the potential to
introduce logical
bugs. Conformal Equivalence Checker compares your designs across each stage. This
process is called Equivalence Checking.

Keypoints :The design consists of combinational logic cones bounded by key points.
All the following are
considered key points:
● Primary inputs (PI), Primary outputs (PO)
● D flip-flops, D latches
● Blackboxes
● Tie-Z, Tie-E, and CUT gates

To compare the two designs, each of the key components is identified as the key
point.

TIE-Z gate –Conformal creates a Z gate to drive a floating net or pin. It also
creates a Z gate when
modeling a tristate. The tool assumes that a Z gate can be 0 or 1.
TIE-E gate –By default, Conformal creates an E (error) gate for x-assignment in the
Revised. A
Golden x-assignment converts to a don’t care. The tool assumes that an E gate can
be 0 or 1.

CUTgates–Combinational loops are cut and one or more points to ease comparison.

What Is Mapping?
Mapping is pairing corresponding Golden and Revised key points.

Golden → Revised
PI→PI
PO→PO
DFF→DFF
DLAT→DLAT
BBOX→BBOX
CUT→CUT
Z→Z
E→E
Why mapping is necessary?
We need mapping so that corresponding combinational logic cones are correctly
paired.
Mapping is necessary so that the tool knows which Golden combinational logic cone
to compare to
which Revised combinational logic cone. When mapping is complete, the two designs
are ready for
comparison.

what is compare process?


During the compare process, all the corresponding combinational logic cones in the
Golden
and Revised designs are compared for equivalency.
The two designs are equivalent when ALL corresponding cones are equivalent.

Conformal compares all the compare points in your design, which are the primary
outputs, the cut gates,
the blackboxes, the flops, and the latches.
Conformal breaks down your design at such compare points and compares the two
designs by the logic
cones at each of these compare points.
In the case of a flop, let’s say it has 4 input logic cones like the D cone, the
clock cone, and the set and
reset cones. Then, each of those logic cones must be successfully compared in order
forthat flop to be
considered as compared and equivalent. For the blackbox, each input pin is a logic
cone. In order forthe
Golden and Revised blackboxpair to be equivalent, all the corresponding input pins
must be equivalent.
If each of the compare points and key points are successfully paired during
mapping, then we can
compare each of these logic cones. The two designs are considered equivalent when
all the
corresponding logic cones are equivalent.

Compare points are sink points of logic cones. For example:


●Primary outputs, cut gates, DFFs, D-latches, and blackboxes

The compare points are the endpoints of your logic cones. We compare the two
designs at these
compare points.
In this example, we have a primary output as a compare point. The tool provides
input vectors to the
logic cone, starting at the output of the flop and alsothe outputs of the blackbox.
We can give 0 or 1 at
any of these start points and then determine whether the output at PO is 0 or 1 on
the Golden side. Then,
we do the same on the Revised side. If the results at PO on both golden and revised
match, then these
compare points are considered equivalent.
The tool tries to provide the minimum necessary and sufficient vectors at each
compare point to prove
that the two compare points are not equivalent.
All the primary outputs, cut gates, the blackboxes, and the flops are considered
compare points.
Regardless of how many inputs the flop has, the entire flop is considered as one
compare point. Thus, if
any of the inputs of that flop fail, then the entire flop has failed.
Conformal will report that failed flop as one nonequivalent compare points.
Similarly, for the blackboxes, if any of the inputs of the blackbox fail,
Conformal will report the entire
blackbox as one nonequivalent compare point.
You can later diagnose each of the failed nonequivalent compare points to determine
the root cause of
the problem.

What Happens at Flops, Latches, Cut Points, and Blackboxes?


The tool assumes that there is no connection from input to output.
Therefore, the inputs and outputs are verified separately.

In Conformal, we assume that there is no connection between the inputs and the
outputs of a flop, a
latch, a blackbox, or a cut point. Think of the flop or the latch being cut in
half. All the logic cones that
end at the inputs of your flop are verified separately from the logic cones that
begin at the outputs of the
flop. In other words, the logic cones end at the inputs of these flops, and then a
new logic cone starts at
the output of the flop. So, we are breaking down the design at the flops and at
other key points so that
the verification is simplified. Thus, we can assume that the outputs of this flop
behave independently
from the inputs.
For example, if you have a constant 0 input that's driving D, logically, that
wouldmake the output at Q a
constant 0. But, for the purposes of equivalence checking, you will assume the Q
output to still have a
value of 1 or 0, independent of the constant 0 input. The same holds true for
latches, cut points, and
blackboxinputs and outputs.

To compare your two designs, you'll be reading both designs. One design will be
read as Golden, and
the other design will be read as Revised.
The libraries for each will also be read for either or both designs. For some
Verilog RTL, you might not
have to read any libraries. For VHDL, you must map the libraries so that it will
associate the VHDL
entities with their architectures.
Then you can specify constraints and modeling directives.

You can also start the tool from a previous


checkpoint.
The checkpointcommand saves all the data
from a session as a checkpointso that it can be
restarted later.

Example
LEC> checkpoint LEC.ckpt –replace
LEC> exit -f
%>lec -restart_checkpoint LEC.ckpt When
you save your session as a checkpoint, the
tool
preserves the following:

●Hierarchical and flattened databases

●Environment settings

●Constraints

●Verification results
●User-
defined variables

●User-defined procedures

command to change the modes : set system mode [setup | lec]

ou can turn on the Tcl interface by entering the


following command:
tclmode
To exit the Tcl interface, enter the following
command:
vpxmode

The write_templatecommand generates the starting Conformal template scripts with


the necessary
commands and attributes. Modify this script to suit your design verification.

Example
write_template -outfile mydofilesmartlec-flat-compare-do

You can specify the name of the log file to save


the log file into something other than lec.log.
Example
set log file logfile –replace

Viewing Usage Statistics


usage [-elapse | -delta | -auto]

The -elapse option gives you the


elapsed time since the session
started.

The -delta option gives you the


runtime in seconds since the last
time the “usage” command was
used.

he -auto option automatically


displays the usage at the end of
every command.

LEC Flow: Setup Mode

In this module, you


●Specify blackboxesin a design
●Read Verilog designs and libraries
●Read VHDL designs and libraries
●Apply design constraints
●Apply modeling directives

Step 1: Specifying Blackboxes


The first step is specifying blackboxes.
When verifying designs, you might have some empty modules, analog blocks, or other
modules that you
don't want to verify.
Conformal verifies all the logic cones connected to the blackbox, whether ending at
it; or coming out of
it.
Blackbox inputs are considered as endpoints of the logic cone. Its outputs are
considered as inputs to
other logic cones. Therefore, all blackboxinputs and outputs are necessary for
complete verification of
your design.

You can blackbox a module using either add no-translate or set undefined cell or
add blackbox
commands.
If you have a missing module definition, then specify either the set undefined cell
command or the
addno-translatecommand.
These are considered system blackboxes.
With the add no-translatecommand, just reading the I/O specification is sufficient.
Read the designs
only after the blackboxes have been defined. If you do it after reading the
designs, the blackboxesare
loaded into the memory of the design; and you are already wasting memory. Also, if
you add a blackbox
now, that would be considered as a user blackbox. Reserve the add black box
command for hierarchical
comparison.

Command : add notranslatemodule *ram* *rom* \–library -both

Command : report_black_box
To check for unbalanced blackboxes after
reading in the Golden and Revised designs:

When constructing blackboxes, the Conformal software attempts to determine the port
directions of the
blackboxes. This is important for comparison because blackboxinput pins are compare
points, whereas
its output pins are faninsto the next logic cones. We recommend you blackboxknown
modules using
the Add NotranslateModule command. In the example below, the wild characters grab
all modules with
the strings “ram” or “rom” in their name and convert them to system blackboxes.

What Are Design Constraints?


Design constraints are user inputs that control part of a design’s logic.
After Conformal successfully reads the designs and libraries, you can place
constraints on
the designs to do the following

●Exclude sections of a design from verification


●Specify behavior, such as one-hot or one-cold
●Specify relationships, such as pin equivalence
●Constrain internal nets, such as primary input,
primary output, and tied signals
●Constrain instances, such as instance equivalence
●Constrain feedback

When comparing an RTL against a netlist with test inserted logic, the test logic
needs to be disabled in
the netlist if the RTL doesn’t have the test logic. When comparing your designs,
constraints help you
provide relationships between different parts of the design or exclude parts of the
design from
verification.

Let’s say your synthesis netlist has test logic, but RTL does not. Then, you need
to exclude that test
logic from your RTL to synthesis verification for a successful comparison.

Command :add pin constraint 0 scan_en-revised

What Are Modeling Directives?


Modeling directives are needed to handle modeling styles specific to vendor
libraries or
synthesis tools.

Examples of Modeling Options


●Clock gating
● Latch transparency
● Latch folding
●Sequential redundancy
●Sequential constant
●Sequential merging

● In Setup mode, you can specify directives to


influence the way Conformal LEC models the
design.
●All modeling is done via the following command:
SETUP> set flatten model

set flatten model –gated_clock

LEC Flow: LEC Mode

Mapping automatically happens when you switch to the LEC mode. But let’s
look at how we can alter mapping if needed.

Name-based mapping is based


strictly on instance path names (or net
names) of key points

Function-based mapping is based on


the function and structure of logic
cones.
In name-based mapping, we will map golden to revised sides by name. All the key
points, such as
instance names and pin names, are mapped by name. In the example comparison shown
on the top, we
use name-based mapping and map “A” to “A”, B to B, and CK to CK. Then, we map the
D-flop as core
fd0 to core-fd0. Name-based mapping is faster than all other mapping methods.

where you map based on the function and


the structure of your logic cones. This is a slightly slower process because the
tool has toanalyze your
design and the logic cones to pair the corresponding key points. So, it can look at
the structure of your
logic and then map “A” to “A”, B to B, CK to CK. But, in order tomap the core-fd0
flop, because it is
differently named, it has tolook at the structure of each of the cones and then
decide if it's the correct
pairing or not. Therefore, it will take slightly longer.

By default, the tool does name first mapping, which


is name-based mapping followed by function-based mapping. This default method can
map most of the
designs with only a few naming differences between golden and revised.
For smaller designs, you can use the default method, which is the name first. But,
on large designs, we
recommend that you use the name only to map your designs first to save time. Later,
you can change the
mapping method in the LEC mode, andmap the remaining key points.

2. If your design did not finish mapping and has a large number ofmapping issues,
then what do you
most likely need to do?
B.Delete mapped points and run name-based mapping.

Mapping seems to hang, and Conformal®LEC displays this message:


// Warning: more than 1/3 of the key points have mismatched names
M

Solution: Incomplete Mapping


●Use the add renaming rulecommand to resolve mapping issues.
●Determine renaming rules from the Mapping Manager.
●Mapping is incomplete,and you have a lot of unmapped points.
●Unmapped points must be resolved before comparison.
Mapping

This is the second type of message that you might see. The report shows incomplete
mapping with not
mapped points. The 144 not-mapped points in the revised design need to be mapped to
the 144 not
mapped points in the Golden design. Use renaming rules to resolve incomplete
mapping.
When you apply renaming rules, you change the names of the key points so that the
Golden and the
Revised corresponding pairs can be mapped using name-based mapping.

add compare points -all


compare

Only mapped points can be compared.


●Comparison is an iterative process.
▪ Conformal remembers points already compared.
▪ Comparison can be interrupted with Control-c.
▪ Enter compareto continue comparing.
All nonequivalences and aborts need to be resolved

The analyze nonequivalent command helps identify the possible causes of


nonequivalent compared points. This command
must be used in the LEC mode.

The -summary and -verbose options of the analyze nonequivalent command report the
following nonequivalence issues:
● Sequential constants
● Clock gating
● Sequential redundancy
● Sequential merge
● Z gate mapping
● Phase mapping
● Direct feedback
● DLAT folding
ANAlyzeNonequivalent [ <gate_id> | <instance_pathname*>
[-Golden | -Revised] ] [-Summary | -Verbose]
Analyze Nonequivalent Command
● DFF to DLAT zero
● DLAT transparency
● DFF Set/Reset/Data interaction
● Redundant DLAT
● Unbalanced blackbox
● User-added cut points
● User-added partition points
● Output Z gate (true error)

root causes NEQs due to:


●Genus™FV information: Incorrect synthesis guidance
● Isolation cell: Wrong clamp value/type, unbalanced or
extraneous isolation cell
●DFT constraint: Incorrect constraint or missing constraint
● Sequential optimization: seq_merge, seq_constant
● True non-equivalence

If the following are all true, then the NEQ is likely not a setup issue
● There are NOunbalanced black boxes
● There are NOnot-mapped key points at the end of comparison
● There is NOfunctional mapping
●ALLguidance information can be applied to the designs (Genus Synthesis Solution)

The analyze setup command automatically resolves the setup-related issues so that
nonequivalence
due to incorrect setup can be prevented or resolves
●Phase mapping
●Sequential constants
●Clock gating
●Sequential merging
●Remove redundant cut points

Aborts are comparepoints that have not been conclusively compared. By the time
aborts are
reported, the Conformal software has applied multiple algorithms without a
deterministic
result

Aborts can have several causes, including:


1.Don’t cares,
2.Large cones, and
3.Large numbers of inputs
●Cones with these attributes will result in increased runtime.
●To deal with extremely long runtimes, the Conformal®software uses a limited amount
of time on a specific
compare point.
●This might result in a few aborts.

Aborts are nothing but compare points that haven't been conclusively compared at
this point, and the
tool has moved on by the time aborts are reported; Conformal has tried different
things and still cannot
conclusively say the result is either nonequivalent or equivalent. It cannot
determine either. This
inability to generate a conclusive or deterministic result is because the tool
wants to save on runtime and
move on to other comparisons that it needs to do at the other compare points.

Avoiding aborts
The best method for handling aborts is to avoid them in the first place. This
implies the use
of equivalency checker-friendly coding practices and modularization of large cones
of logic

First, do not write too large a Verilog module. Keeping it small will help with the
comparison. The same
is true with creating hierarchies; they make the comparison easier. In situations
with difficult arithmetic
operations, it will help isolate your aborts.
During synthesis, always remember that ungrouping and inverter pushing will cause a
comparison to be
difficult. Always separate out ungrouping from other optimization tasks. Your
comparison will be much
easier between the optimized netlist and the ungrouped netlist rather than
combining it all into one. The
idea is to simplify your verification and not do all the tasks at once. Beware of
inverter pushing because
the return on investment may be minimal, considering the amount of time you spent
verifying your
designs versus the improvement in timing results.
Another recommendation, is that you must avoid using Xsor don't caresin your RTL.
Minimize using a
full-case, parallel-case, or default Xs; as these will create X sources in your
design and therefore cause
The analyze abort command analyzes the abort points and recommends actions to help
solve them.
This command also provides useful information for further investigation in case the
abort point cannot
be diagnosed. This command must be used in the LEC mode.
The following commands run abort analysis after the initial comparison and resolve
the aborts:

If you just use the analyze abort command, it gives you


recommendations on how to further resolve the aborts. For example, it might tell
you that there is a
don’t care, so you can run the analyze DC command with the -constraint option, or
if you have a
datapath in your design to run the analyze datapath command.

Common abort scenarios


●Don't care x-assignment
● Index-out-of-range
●Resource sharing
● Low-quality datapath learning
●Ungrouped datapath modules
Command
analyze_abort-source_diagnosis

Hierarchical comparison is a bottom-up, module-by-module comparison.


● It is done automatically with a tool-generated script (.dofile) simply called
hierarchical dofile.
●Requirement –Design must contain some hierarchy.
●Benefits –Shorter runtime, easier to debug.

Hierarchical comparison is faster than flat comparison in most cases because only
one module or a
small group of modules is being compared at a time. This method helps to speed up
the comparison
process. It also helps the debugging process because problem logic is isolated to a
particular part of the
design.
Hierarchical comparison is very easy to set up. It is almost like the setup for
flat comparison. The tool
has a command that automatically generates the script to perform the hierarchical
comparison.

Set root module to U1 Compare U1 Save U1 Result


Blackbox U2 2. Set root module to U2 Compare U2 Save U2 Result
Blackbox U3 3. Set root module to U3 Compare U3 Save U3 Result
Blackbox U4 4. Set root module to U4 Compare U4 Save U4 Result
5. Set root module to TOP Compare TOP Save TOP Result
Note: Modules U4 and their submoduleswill be compared flat.

After the design setup is complete, use the command below to generate a dofilefor
hierarchical comparison:
WRIteHIer_compare Dofile <filename> [-RUN_HIER_compare]

In order tomake a hierarchical comparison, the tool generates or writes out a


hierarchical comparison
dofile with all the modules for comparison written into that dofile. Re-read that
dofileback into
Conformal for comparison. Each individual module, as you saw in the example before,
will be
compared one after the other, and then the results will be saved. After your design
setup is complete,
including flattening options and constraints, you write out this dofile. Dynamic
comparison dofile
generation writes more modules by ignoring some setup issues.

LEC FLW

read_implementation info

- To associate block-level implementation information to the corresponding design


block or submodule.
- To assign specific implementation information to a particular block or submodule.
- To read detailed information on `seq_constant` and `seq_merge` for verification
purposes.
- To improve the verification setup and reduce turnaround time significantly.
- To get all the corresponding optimization information when comparing at the top
level.

The `add_name_alias` command is used to specify a JSON data file that contains
name aliases for changing keypoint names during mapping.

- The `add_name_alias` command is used to specify a JSON data file that contains
name aliases for changing keypoint names during mapping.
- These aliases are enabled with the `SET MAPPING METHOD -alias` command.
- The JSON data file must follow a specific format for the array of name aliases,
which includes information such as module name, instance type, original name, and
alias.
- For multibit cells, a different format is used, including details like module
name, instance type for multibit cells, original name, pin name, and alias.
- The tool will then change the specified keypoint names or driver names based on
the provided aliases in the JSON file.
- Additional parameters for the `add_name_alias` command include:
- `-GOLden`: Specifies the use of name aliases for the Golden design (default
behavior).
- `-REVised`: Specifies the use of name aliases for the Revised design.
- `-REPlace`: Clears any previous name alias data before adding new name aliases.

You might also like