Full Flow RAK - RTL To Place & Route, Including ECO: Rapid Adoption Kit (RAK)

Full Flow RAK - RTL to Place & Route,
Including ECO
Rapid Adoption Kit (RAK)
Product Version:
Conformal 17.1,
Genus 16.2,
Innovus 16.2,
Xcelium 16.1
July, 2017
Note: RAK Testcase Database can be downloaded from the 'Attachments' section at the
bottom of this PDF from the support ONLINE system https://support.cadence.com. This RAK
can also be searched on the support portal i.e. https://support.cadence.com, using the ‘Title’
of the RAK.
Copyright Statement
© 2017 Cadence Design Systems, Inc. All rights reserved worldwide. Cadence and the Cadence logo are
registered trademarks of Cadence Design Systems, Inc. All others are the property of their respective
holders.
Learn more at Cadence Support Portal - https://support.cadence.com

© 2017 Cadence Design Systems, Inc. All rights reserved worldwide. Page 2
Full Flow: RAK – RTL to Place & Route, Including ECO
Contents
Purpose ....................................................................................................................... 4
Audience...................................................................................................................... 4
Software ...................................................................................................................... 4
Design ......................................................................................................................... 5
Module A: Introduction / Preparation ........................................................................... 6

A.1 Tool Setup ......................................................................................................... 6
A.2 RAK Setup ......................................................................................................... 7
Module B: Design Steps Overview ............................................................................ 11
Module C: Design Step Execution ............................................................................. 15
Module D: Flow Flow RAK Makefile........................................................................... 37
Support ...................................................................................................................... 38
Feedback ................................................................................................................... 38

Purpose
This Full Flow RAK demonstrates implementing and verifying a small low power design
from RTL to Place and Route, including functional ECO, using the full Cadence flow.
Key features
1. Design is small and easy to understand.

2. Run time is short, about 30 minutes for the entire flow.
3. Design steps are ordered numerically and thus, easy to follow.
4. Execution is simple. cd to a design step and do RUNME.sh or use the Makefile
utility.
5. README and CLEANUP.sh are provided for most design steps.
Notes:
1. This Cadence flow RAK is not intended to replace other Cadence RAKs. Refer to
other RAKs for more details on the individual tool features / flows. Design used
for this full flow RAK is fairly small, as a result QoR issues are not discussed
here.
2. RAK Testcase Database can be downloaded from the 'Attachments' section at

the bottom of this PDF via ONLINE portal. This RAK can also be searched on the
support portal (https://support.cadence.com) using the ‘title’ of the RAK.
Audience
This RAK is for users who implement and verify low power 1801 (UPF 2.0) designs
using Cadence verification and implementation tools:
 Learning: Make a change, rerun the step(s) to see the effects.

 Testing: Test out the new tool features / flows.
 Debugging: Modify testcase to show the tool issue to R&D.
Software
Examples in this kit were developed using the following tool versions:
 Conformal 17.10-p100
 Genus 16.22-s033_1
 Innovus 16.20-p002_1
 Xcelium 16.11-s005

Note: Some of the features described in this workshop may not be supported in earlier
releases of this tool.
Design
The RTL design used in this RAK has the following features:
1. Low power (1801-2009, UPF 2.0) design where level shifter, isolation, retention,
and power switch cells will be inserted
2. Asynchronous designs with two clocks, with two reset and two DFF
synchronizers
3. Three scan chains are inserted.
4. Mixed language design, Verilog and VHDL
5. Function ECOs using both premask and postmask flows are demonstrated.
6. Cadence 45nm generic PDK (11M/2P) is used.

Module A: Introduction / Preparation

Objective: Set up the environment to run this RAK and identify the design and steps.
A.1 Tool Setup

This RAK was developed using the following tool versions:
 Conformal 17.10-p100 (lec)

 Genus 16.22-s033_1 (genus)
 Innovus 16.20-p002_1 (innovus)
 Xcelium 16.11-s005 (irun)
Using earlier versions is not recommended. Using later version is acceptable, but it may
return slightly different outputs. Find out if you have the following tools available and
their versions:
linux$ which lec
/tools/cadence/lec/lec.17.10-p100/bin/lec
linux$ lec -Version
Tool: lec 17.10-p100
linux$ which genus

/tools/cadence/genus/16.22-s033_1/bin/genus
linux$ genus -version
Program Name: Genus(TM) Synthesis Solution, Version: 16.22-s033_1
@(#)CDS: SYNTECH 16.21-e008_1 () Nov 30 2016 23:19:23 ( )
@(#)CDS: SGN 10.10-p122 (22-Jan-2016) (64 bit executable)
Normal exit.
linux$ which innovus

/tools/cadence/innovus/16.20-p002_1/lnx86/bin/innovus
linux$ innovus –version
@(#)CDS: Innovus v16.20-p002_1 (64bit) 11/08/2016 11:31 (Linux 2.6.18-
194.el5)
@(#)CDS: NanoRoute 16.20-p002_1 NR161103-1425/16_20-UB (database version
2.30, 354.6.1) {superthreading v1.34}
@(#)CDS: AAE 16.20-p004 (64bit) 11/08/2016 (Linux 2.6.18-194.el5)
@(#)CDS: CTE 16.20-p008_1 () Oct 29 2016 08:26:57 ( )
@(#)CDS: SYNTECH 16.20-p001_1 () Oct 27 2016 11:33:00 ( )
@(#)CDS: CPE v16.20-p011
@(#)CDS: IQRC/TQRC 15.2.5-s803 (64bit) Tue Sep 13 18:23:58 PDT 2016 (Linux
2.6.18-194.el5)
@(#)CDS: OA 22.50-p051 Thu Aug 4 00:05:16 2016
@(#)CDS: SGN 10.10-p124 (19-Aug-2014) (64 bit executable)
@(#)CDS: RCDB 11.8
linux$ which irun

/tools/cadence/xcelium/16.11.005/tools/bin/irun
linux$ irun –version
TOOL: xrun 16.11-s005

Cadence tools can be obtained from https://downloads.cadence.com under the

following selections:
 Conformal > CONFRML171

 Genus > GENUS162
 Innovus > INNOVUS162
 Xcelium > XLM201611
A.2 RAK Setup

A.2.1 Get the RAK database from the attachments section below the PDF from the
ONLINE system i.e. https://support.cadence.com or search this website with the RAK
title to reach to this PDF.
Extract the RAK database and change the directory to it:
linux$ tar xvf ff_rak_testcase.tar.gz

linux$ cd ff_rak_testcase
A.2.2 Cadence 45nm generic PDK is needed to run this Cadence Full Flow RAK:
GPDK045 - 45nm CMOS 11M/2P Generic PDK. It is already in the
ff_rak_testcase.tar.gz.
A.2.3 Test out the RAK database and library setup by doing the following:
linux$ cd ff_rak_testcase # if not already there

linux$ cd design_steps
linux$ cd 1.0*
linux$ ./RUNME.sh
…
// Command: report rule check -sdc_lint * -status fail -verbose
==================================================================
=============
= All Commands =
==================================================================
=============
| Number of Commands: 53
| Status (Fail): 0
==================================================================
=============
// Command: exit -f

If you see the above after ./RUNME.sh, the RAK database and library are set up
properly.
A.2.4 Check out the design files located in the input_data directory:

linux$ cd input_data
linux$ ls -1
design.1801@
design.upf20
design.upf21
dff_synchronizer.sv
lib.cpf
phy.sdc
phy.v
pm_good.v
reset_synchronizer.v
reset_synchronizer.vhd
Design RTL files consists of the following:
 dff_synchronizer.v
 phy.v
 pm_good.v
 reset_synchronizer.v or reset_synchronizer.vhd
phy.v is the main RTL file that instantiates other files. The output of the design tree (the
“report modules –instantiation” Conformal command) is as follows:
SETUP> report modules -instantiation

design:
phy
(1) u_pm (pm)
pm
(1) u_rstX_sync (reset_synchronizer)
(2) u_rst_sync (reset_synchronizer)
reset_synchronizer
(1) u_tm (TopMod)
TopMod
(1) x1 (mod_SW)
mod_SW
(1) x2 (mod_AO)
(2) x4 (mod_AO)
mod_AO
(1) x3 (sync_mod_AO)
sync_mod_AO
(1) u_2dff_sync (dff_synchronizer)
dff_synchronizer
(1) u_2dff_sync (dff_synchronizer)
dff_synchronizer
(1) u_us (upshift)
upshift
As mentioned earlier, this simple design has two asynchronous clock domains and thus,
requires two reset synchronizers. Also, it has two DFF synchronizers. It is a low power
design and therefore, contains a power control module that generates the isolation
control, retention control, and power off signals. The following waveforms describe the
relationship among these signals:
Notice that iso_en is enabled before power_off. Similarly, power_off is disabled before
iso_en. In this simple design, the iso_en and power_off signals are controlled by
counters. So, they are easy to understand and modify for experimentation. Refer to
pm_good.v for more detail.
design.1801 is the power intent file for the design. It is a softlink to design.upf20. There
is also a design.upf21. But this design.upf21 file is not being used in the RAK. It is for
only references and experimentation because not all tools support UPF2.1 (1801-2013).
There are two voltages being used: 0.9V and 1.08V. All instances are always on, except
for u_tm/x1, which is switchable at 0.9V. So, there are three power domains: 0.9V
always-on, 1.08V always-on, and 0.9V switchable. There are crossings among these
domains that need to be protected. Power intent identifies what needs to be done.

Following is a diagram that explains power intent of the design. Power domains are
color-coded, and domain interfaces are identified by half-colored circles. Low power
strategies are only allowed on domain interfaces. Refer to design.1801 for detail.
phy.sdc is the timing constraint file. This file identifies asynchronous clocks, clock
frequencies, input and output delays for top-level ports, and so on. phy.sdc is used in
many of design and verification steps. Finally, lib.cpf is only for references. It is an
output of the Conformal command, “write power intent –cpf –library”, which is just a
library CPF for the 45nm library used in this RAK.

Module B: Design Steps Overview

B.1 Nomenclature used in this RAK:
R1 = RTL of original design

S1 = Synthesized netlist of R1
G1 = Place and routed netlist of S1
R2 = ECO’ed RTL of R1
S2 = Synthesized netlist of R2, using the same flow as S1
G3 = Conformal ECO output after adding ECO into G1
E3 = G3 implemented by P&R
B.2 Overview of design steps for this RAK is as follows:
Step # Tool Used Description Input Output (if any)

0.2 LEC Library Verilog libraries
qualification and Liberty
between Verilog libraries
and Liberty
0.3 LEC Library Liberty libraries
qualification
between Liberty
and Liberty
1.0 CCD SDC quality R1, SDC,
check Liberty libraries
1.1 CCD CDC check R1, SDC,
Liberty libraries
1.2 CLP Verify 1801 quality R1, Liberty
check libraries, 1801
2.0 Xcelium LP simulation R1, 1801,
testbench
3.0 Genus Initial synthesis R1, SDC, Initial S1
Liberty libraries,
LEF
3.1 Innovus Initial floorplan Initial S1, SDC, Initial DEF
Liberty libraries,
LEF, 1801
3.2 Genus Physical R1, SDC, S1, updated
Physical synthesis Liberty libraries, 1801, updated
LEF, 1801, SDC, updated
Initial DEF DEF and
scanDEF,
scripts for LEC,
Innovus


3.5 CCD R1 vs S1 SDC R1, S1, SDCs,
comparison Liberty libraries
3.6 CLP Verify CLP Verify on S1 S1, Liberty
libraries, 1801
3.7 CLP EC CLP EC between R1, S1,
R1 vs S1 intermediate
netlist, Liberty
libraries, 1801s
4.0 Innovus P&R S1, Liberty G1, updated
libraries, DEFs, 1801, updated
1801s, SDC, SDC, updated
LEF DEF and
scanDEF,
scripts for LEC,
Genus
4.3 CLP Verify CLP Verify on G1 G1, Liberty
libraries, 1801
4.4 CLP EC CLP EC between S1, G1, Liberty
S1 vs G1 libraries, 1801s
5.1 CCD SDC quality R2, SDC,
check Liberty libraries
5.2 CCD CDC check R2, SDC,
Liberty libraries
5.3 CLP Verify 1801 quality R2, Liberty
check libraries, 1801
5.4 Genus Physical R2, SDC, S2, updated
Physical synthesis Liberty libraries, 1801, updated
LEF, 1801, SDC, scripts for
Initial S1DEF LEC and
Innovus
5.6 CCD R2 vs S2 SDC R2, S2, SDCs,
comparison Liberty libraries
5.7 CLP Verify CLP Verify on S2 S2, Liberty
libraries, 1801
5.8 CLP EC CLP EC between R2, S2,
R2 vs S2 intermediate
netlist, Liberty
libraries, 1801s
6.1a Conformal Premask FEF G1, S2, 1801s, G3
ECO patch generation SDC, Liberty
libraries
6.1b Conformal Postmask FEF G1, S2, 1801s, G3, mapping
ECO patch generation SDC, Liberty file, change


libraries, DEF, script, updated
LEF DEF
6.2 CLP EC CLP EC between G3, S2, Liberty
G3 and S2 libraries, 1801s
6.3 CLP Verify CLP Verify on G3 G3, Liberty
libraries, 1801
6.4a Conformal ECO premask G3, Liberty E3, updated
ECO implementation libraries, 1801, 1801
SDC, LEF,
DEFs
6.4b Conformal ECO postmask G3, Liberty E3, updated
ECO implementation libraries, 1801, 1801
SDC, LEF,
DEFs
6.6 CLP Verify CLP Verify on E3 E3, Liberty
libraries, 1801
6.7 CLP EC CLP EC between S2, E3, Liberty
S2 and E3 libraries, 1801s
6.8 CLP EC CLP EC between R2, E3, Liberty
R2 vs E3 libraries, 1801s

B.3 The flow diagram depicting the design steps for this RAK follows. Implementation
steps for S1/G1 are 3.0, 3.1, 3.2, 4.0. For ECO, the implementation steps are 5.4, 6.1,
and 6.4. All the other steps are for verification.

Module C: Design Step Execution

To execute a design step, cd to that directory and then do ./RUNME.sh. To run the Full
Flow RAK, follow the order shown in the flow chart on the previous page, starting with
1.0, 1.1, and so on. Depending on what you are trying to do, some steps can be
skipped. However, if you want to generate G1 (the P&R netlist), you will need to run 3.2.
To run 3.2, you will need 3.1, and so on. That said, if you have already run 3.0, 3.1, and
3.2 and want to modify the script for Innovus to see the effect, you do not need to rerun
3.0, 3.1, and 3.2. You just need to run 4.0.
For Conformal, if you are doing premask ECO, you only need to do 6.1a and 6.4a (not
6.1b or 6.4b), after getting S2 using 5.4. This is the default for this RAK. If you want to
do postmask ECO, you will need to run 6.1b and 6.4b (not 6.1a or 6.4a). Before running
6.1b or 6.4b, you will need to set the following environment variable:
linux$ setenv ECO_MODE postmask
R2 is in the eco1_data directory. Currently, there are two files that are different between
R1 and R2:

linux$ diff –q input_data eco1_data
Files input_data/dff_synchronizer.sv and
eco1_data/dff_synchronizer.sv differ
Files input_data/phy.v and eco1_data/phy.v differ
Only in eco1_data/: README
To see differences between the files, use tkdiff.
Example:
linux$ tkdiff input_data/phy.v eco1_data/phy.v &

Following are the READMEs in the design step directories:
0.0_setup
setup.cshrc defines the environment variables for paths that are used by other design
steps, for example, $TC_PATH is the base testcase directory, $DEMOLIB is the
directory containing all libraries needed to run the design, and $SOURCE_DATA is the
directory containing the RTL, SDC, and 1801 file, and so on.
Note: There is nothing to run in this directory. But setup.cshrc gets called by all other
design steps. Following is its content:
#!/bin/csh
set VAR = `pwd`
setenv TC_PATH $VAR:h:h
setenv DEMOLIB $TC_PATH/lib/gsclib045_svt_v4.4/gsclib045
setenv SOURCE_DATA $TC_PATH/input_data
setenv ECO1_DATA $TC_PATH/eco1_data
echo "// Note: setting TC_PATH variable to $VAR:h:h"
echo "// Note: setting DEMOLIB to $DEMOLIB"
echo "// Note: setting SOURCE_DATA to $SOURCE_DATA"
setenv S1init "$TC_PATH/design_steps/3.0_S1_initial_synthesis"

setenv S1fp "$TC_PATH/design_steps/3.1_S1_initial_floorplan"
setenv S1 "$TC_PATH/design_steps/3.2_S1_physical_synthesis_lp"
setenv G1 "$TC_PATH/design_steps/4.0_G1_place_and_route"
setenv S2 "$TC_PATH/design_steps/5.4_S2_physical_synthesis_lp"
if (! $?ECO_MODE) then
echo "// Note: ECO_MODE is not defined; defaults to premask"
setenv S3 "$TC_PATH/design_steps/6.1a_S3_premask_FEF_patch_generation"
setenv G3 "$TC_PATH/design_steps/6.4a_G3_premask_eco_implementation"
else
if ($ECO_MODE == "") then
echo "// Note: ECO_MODE is empty; defaults to premask"
else if ($ECO_MODE == "premask") then
echo "// Note: ECO_MODE is premask"
else if ($ECO_MODE == "postmask") then
echo "// Note: ECO_MODE is postmask"
setenv S3 "$TC_PATH/design_steps/6.1b_S3_postmask_FEF_patch_generation"
setenv G3 "$TC_PATH/design_steps/6.4b_G3_postmask_eco_implementation"
else
echo "// Note: $ECO_MODE is neither premask nor postmask; default to premask"
endif
endif
echo "// Note: setting S1 initial to $S1init"

echo "// Note: setting S1 FP to $S1fp"
echo "// Note: setting S1 to $S1"
echo "// Note: setting G1 to $G1"
echo "// Note: setting G3 to $G3"

0.2_library_qualification_verilog_vs_liberty
An ASIC library has many views. For example, Liberty view is needed for synthesis and
Verilog view is needed for simulation. The functionality defined in the Liberty and Verilog
views should be the same for all cells. Conformal LEC has the capability to check
whether all the cells defined in these two views are functionally the same.
Notes:
1. Only cells defined in both views are compared. Thus, subcells like UDPs are not
compared because they only exist in one view.
2. There is a cell that is non-equivalent between the two views: HOLDX1. This cell
has an attribute of dont_use placed on it though.
Tool(s) used: Conformal LEC (lec -xl)
To run the design step: ./RUNME.sh
Other References
Article: Comparing liberty format library with Verilog simulation library

http://support.cadence.com/wps/mypoc/cos?uri=deeplinkmin:ViewSolution;solutionNumber=11009735
0.3_library_qualification_liberty_vs_liberty
A Liberty library view can have many files, each characterized for a corner (PVT,
process/voltage/temperature) of operation. While the process numbers for these
different corners / files may be different, many attributes (for example, pg_function,
related_power_pin, and so on) should be consistent across all Liberty files. Conformal
Low Power (CLP) has the capability to check whether the attributes between the two
Liberty files are the same.
Notes:
1. The dofile uses a Tcl for-loop to check Liberty files against one another.
2. Use the command to waive certain known inconsistency
Example:
SETUP> add liberty_compare filter skip_cap -attribute_name capacitance -waive
Tool(s) used: Conformal LEC (lec -lp)

Other References
man page: man compare liberty -verbose

man add liberty_compare filter –verbose
1.0_R1_sdc_quality_check
The Synopsys Design Constraint (SDC) file documents the timing intent of a design,
among other things. This SDC file is used by many tools for design and verification.
Issues in the SDC file can cause incorrect optimization that may lead to poor quality of
result and/or incorrect functionality.
Conformal Constraint Design (CCD) has the capability to check whether the SDC file
conforms to SDC language specifications and that it is correct and complete. This
design step shows how to set up and run a SDC quality check.
Notes: R1 refers to the original design RTL.
Tool(s) used: Conformal Constraint Designer (ccd)
Other References
RAK: Conformal Constraint Designer: SDC Constraint and CDC Verification

Methodologies

1.1_R1_cdc_structural_check
When a design contains asynchronous clocks, care may be taken to ensure proper
synchronizers are properly placed within the clock domain crossings (CDC) to avoid the
metastability issue. CCD has the capability to check whether clock domain crossings
are properly synchronized. These CDC checks includes normal CDC check, set / reset
check, FIFO synchronizer check, and so on.
Notes:
1. R1 refers to the original design RTL. This design has two asynchronous clocks.
Two clock domain crossings require synchronization. The synchronizer is a two-
DFF synchronizer. The set / reset check is also performed.
2. No issues are found since there are two properly placed DFF synchronizers and
two properly constructed reset synchronizers.
3. input_data/phy.sdc defines asynchronous clocks:
set_clock_groups -name grp4 -asynchronous -group {slow_clk}

-group {fast_clk}
Other References
Article: Is there any clock domain crossing (CDC) primer available with examples in
Conformal Constraint Designer (CCD)?
RAK: Conformal Constraint Designer: SDC Constraint and CDC Verification

Methodologies

1.2_R1_power_intent_quality_check
Just as the SDC file is the timing specification for a design, the 1801 file is the power
specification / intent for a design. The quality of this 1801 file is crucial to the success of
a low power design, because the file is used throughout implementation and verification.
Missing isolation strategies, for example, in the 1801 file, can lead to design failure. CLP
has the capability to check the quality of the 1801 file as well as the correctness of the
design when verified against power intent in the 1801 file.
Notes:
1. R1 refers to the original design RTL. This design is small and simple. It contains
v0.9 and v1.08 domains. There is also a switchable instance and other always-on
instances. Isolation, level shifter, and retention cells are used in this design.
2. The 1801-2009 (UPF 2.0) file is used. There is also a 1801-2013 (UPF 2.1) file in
the same input_data directory. This UPF 2.1 shows how an enabled level shifter
is coded. However, the simulation tool currently does not support this.
3. The intent of this RAK is not to explain 1801 coding. So, there is no explanation
on how 1801 is coded.
Tool(s) used: Conformal Low Power (lec -lp -verify)
Other References
Language Reference Manual for IEEE 1801-2009.

2.0_R1_lp_simulation
After the 1801 file has been qualified, next important step in the design flow is to
perform low power simulation (LP sim) on the RTL design. Running LP sim may
highlight issues that do not show up in a usual simulation. Xcelium is capable of
running LP simulation with UPF 2.0.
Notes:
1. The power control logic is in the input_data/pm_good.v file. It is basically a

counter that sends a sequence of isolation control, retention control and power
off/on signals in the correct order.
2. In the SimVision window, notice the following:
a. iso_en becomes active, followed by power_off, in that order.
b. Once iso_en becomes the isolated signals take on the clamp_value (1)
specified in the 1801 file:
i. tb.top_inst.u_tm.Wi => 1
ii. tb.top_inst.u_tm.iY => 1
iii. tb.top_inst.u_tm.Zi => 1
iv. tb.top_inst.u_tm.X => 1
c. Values inside the switchable instance become X, and become active once
powered off.
d. count[7:0] get saved when the retention save signal is active, and
count[7:0] get restored when the restore signal is active.
e. While power_off is active, count[7:0] are X.
3. RUNME.sh runs the simulation and saves the database. To view the waveform of
the simulation, execute the following command after RUNME.sh is finished:
simvision –input simvision.svcf
Tool(s) used: Xcelium (irun)
Other References
RAK: Conformal Low Power, Genus and Incisive: Low Power Verification for Beginners in 1801

3.0_S1_initial_synthesis
After checking that SDC and 1801 are fine (in the previous design steps), you are ready
to synthesize the RTL. You will be using Genus Physical Synthesis. Genus Physical
Synthesis requires a DEF file as an input, in addition to the normal .lib, .sdc, .1801, and
RTL. So, you will do the following in order:
3.0_S1_initial_synthesis/ -> Quick synthesis to get a non-LP netlist

3.1_S1_initial_floorplan/ -> Use the P&R tool to get a starting floorplan,
using the netlist from the design step 3.0*.
3.2_S1_physical_synthesis_lp/ -> Using the floorplan from the design step 3.1*,
and RTL, .sdc, .1801, and .lib to get a netlist and a new DEF
Notes:
1. Normal optimization is done in the initial synthesis run.

2. No 1801 file is used.
3. No scan logic is inserted.
Tool(s) used: Genus (genus -legacy_ui)
Other References
RAK: Genus Synthesis Solution: Genus RAK for Beginners with Legacy UI

3.1_S1_initial_floorplan
After checking that SDC and 1801 are fine (in the previous design steps), you are ready
to synthesize the RTL. You will be using Genus Physical Synthesis. Genus Physical

3.1_S1_initial_floorplan/ -> Use P&R tool to get a starting floorplan, using
the netlist from the design step 3.0*.
Notes:
1. The 1801 file is used during initial floorplanning, in addition to the netlist
generated in the design step 3.1*.
2. After placeDesign, DEF is written out. This will be used in the design step 3.2*
for Genus Physical Synthesis.
Tool(s) used: Innovus Implementation Systems (innovus)
Other References
Article: Innovus Implementation 1801 Flow


3.2_S1_physical_synthesis_lp
After checking that SDC and 1801 are fine (in previous design steps), you are ready to
synthesize the RTL. You will be using Genus Physical Synthesis. Genus Physical

3.1_S1_initial_floorplan/ -> Use the P&R tool to get a starting floorplan,
using the netlist from the design step 3.0*.
Notes:
1. This is a physical synthesis run with 1801. Three scan chains are defined.
2. After connect_scan_chains, the commit_power_intent command needs to be run
again to ensure power intent are implemented for the scan logic.
3. Netlists and LEC dofiles are written out after syn_map and syn_opt. But dofiles
are not used for verification. Refer to the design step 3.7*.
4. syn_opt netlist is called outputs/phy_m.v. This will be used for P&R. Updated
sdc, 1801, and def files are also written out. Files for Innovus are saved in the
output directory to be used in the design step 4.0*.
Tool(s) used: Genus (genus -legacy_ui)
Other References
RAK: Genus Synthesis Solution: Genus RAK for Beginners with Legacy UI
RAK: Genus Synthesis Solution: Genus Physical RAK

RAK: Genus Synthesis Solution: GENUS Low Power RAK with Legacy UI

3.5_R1_S1_sdc_compare
After synthesis, Genus writes out an updated SDC file that is used by tools operating on
the netlist. The correctness of this updated SDC is important to ensure quality as well as
correctness of the design. CCD has the capability to compare two SDCs to ensure they
are same.
Notes: Genus added the set_dont_touch and group_path commands in SDC. Hence,
there are 26 failures. This is expected.
3.6_S1_LP_structural_check
After synthesis, Genus writes out an updated 1801 file that is used by tools operating on
the netlist. The correctness of this updated 1801 is important to ensure quality as well
as correctness of the design. Also, Genus has implemented low power strategies
specified in the original 1801 file. It is important to check the netlist to ensure it is
implemented correctly per the original 1801 intent. CLP has the capability to verify the
updated 1801 file and the netlist. This is done in two steps:
1. CLP EC (done in the next design step 3.7*)
a. compare power intent: Compares the golden 1801 file as against the
updated 1801 file
b. compare: Compares logic between the golden as against revised designs
c. compare power consistency: Golden domain as against the revised
domain
2. CLP Verify (done in this step): Checks to see if the netlist meets power intent
specified in the 1801 file
Notes:
1. Notice there is no warning or error reported by the "read power intent" command.
This does both reading of power intent as well as checking the netlist against the
intent specified in the 1801 file.
2. Both design steps, 3.6* and 3.7*, need to be done to completely check
correctness of the netlist and the 1801 file. See article 20452386 below.

Tool(s) used: Conformal Low Power Verify (lec -lp -verify)
Other References
RAK: Conformal Low Power (CLP) RAK for Beginners

RAK: Conformal Low Power and Genus: Low Power Verification for Advanced Users
Article: What are the different flows in Conformal Low Power (CLP)?
App Note: Differences between CLP-Verify, LPEC and LEC

3.7_R1_S1_LPEC
After synthesis, Genus writes out an updated 1801 file that is used by tools that operate
on the netlist. The correctness of this updated 1801 is important to ensure quality as
well as correctness of the design. Also, Genus has implemented low power strategies
specified in the original 1801 file. It is important to check the netlist to ensure it is
implemented correctly per the original 1801 intent. CLP has the capability to verify the
updated 1801 file and the netlist. This is done in two steps:
1. CLP EC (done in this step)
a. compare power intent: Compares golden 1801 file as against the updated
1801 file
c. compare power consistency: The golden domain as against the revised
domain
2. CLP Verify (done in the previous step 3.6*): Checks to see if the netlist meets
power intent specified in the 1801 file
Notes:
1. Notice there are two CLP EC runs. There are no non-equivalences reported
between the RTL and syn_map netlist, and there are no non-equivalences
reported between syn_map and syn_opt netlist.
correctness of the netlist and 1801 file. See article 20452386 below.

Tool(s) used: Conformal Low Power EC (lec -lp)
Other References


Article: Why are there extra primary outputs in my CLP EC comparison?


4.0_G1_place_and_route
Using outputs from Genus (DEF, SDC, 1801, netlist, scripts), you run place and route to
implement the design. Since the design contains a switchable domain, a switch chain is
inserted in the design. Clock tree synthesis is not run.
Notes:
1. Since the design has multiple supply voltages, multiple power / ground rings and
stripes are inserted.
2. In addition to the spare cells already inserted in the RTL, more spare cells are
inserted in different power domains during P&R.
Tool(s) used: Innovus Implementation System (innovus)
Other References
RAK: Innovus Implementation 1801 Flow

RAK: Basic Floorplanning in Innovus Implementation System 17.1

RAK: Introduction to Innovus Implementation System 17.1 & Block Implementation Flow

4.3_G1_LP_structural_check
After P&R, Innovus writes out an updated 1801 file that is used by tools operating on
as correctness of the design. Also, Innovus may have modified the low power logic in
the design. It is important to check the netlist to ensure it is implemented correctly per
the original 1801 intent. CLP has the capability to verify the updated 1801 file and the
netlist. This is done in two steps:
1. CLP EC (done in next design step 4.4*):
a. compare power intent: Compares the golden 1801 file as against the
updated 1801 file
c. compare power consistency: Compares golden domain as against the
revised domain
2. CLP Verify (done in this step): Checks to see if the netlist meets power intent
specified in the 1801 file.
Notes:
1. There is one error reported by CLP Verify. It says the u_tm/x1/mode signal is
missing an isolation cell. This error can be waived since this signal is driven by a
power switch cell that stays on even when u_tm/x1 is powered off.
2. Both design steps, 4.3* and 4.4*, need to be done to completely check the
Other References:



4.4_S1_G1_LPEC
After P&R, Innovus writes out an updated 1801 file that is used by tools operating on
as correctness of the design. Also, Innovus may have modified the low power logic in
the design. It is important to check the netlist to ensure it is implemented correctly per
the original 1801 intent. CLP has the capability to verify the updated 1801 file and the
netlist. This is done in two steps:
1. CLP EC (done in this design step)

a. compare power intent: Compares the golden 1801 file as against the updated
1801 file
c. compare power consistency: Compares the golden domain as against the
revised domain
2. CLP Verify (done in the previous step 4.3*): Checks to see if the netlist meets
power intent specified in the 1801 file.
Notes:
1. There are no non-equivalences reported between the Genus and Innovus

netlists.
Other References


Article: Why are there extra primary outputs in my CLP EC comparison?

5.*_ECO_related_steps
Terminology used in Conformal ECO:
R1: Original RTL

S1: Synthesized netlist from Genus for R1
G1: P&R netlist from Innovus for S1
R2: ECO'ed RTL (R1 + ECO)

S2: Synthesized netlist from Genus for R2, using the same environment as S1
G3: Output of Conformal ECO, after patching G1 to add the ECO

E3: Implemented netlist from Innovus for G3
First, Conformal ECO can ONLY do functional ECO. It cannot do timing and other non-
functional ECOs. Further, ECO can be combinational or sequential, but must be
contained within a power domain (ECO crossing power domains is not supported). Also,
no changes to 1801 is allowed.
If ECO is needed for G1, Conformal ECO can be used to simplify the process. After
adding ECO to R1 to get R2 and running simulation on R2, you need to take R2 through
the same synthesis flow that S1 went through to get S2. Design steps 5.* are used to
generate and verify S2 before running Conformal ECO. So, all verification steps in 5.*
should be clean before continuing to step 6.*.
The Cadence ECO process has two parts: creating and implementing the patch.
6.1* is for creating the patched netlist G3 (done by Conformal ECO).

6.4* is for implementing the patch to get E3 (done by Innovus).
Notes:
1. LP sim should be running on R2. This step is left out of this RAK.
2. Make sure R2 as against G2 is EQ before continuing Conformal ECO.
3. Note that only 6.1 and 6.4 (a or b) need to be done, depending on whether ECO
is premask or postmask. This is controlled by an environment variable
$ECO_MODE. Default for this variable is "premask". To run postmask ECO, do
"setenv ECO_MODE postmask" before executing step 6.*.
4. After Conformal ECO/Innovus, make sure S3 and G3 are also clean.

Conformal Constraint Designer (ccd)
Conformal Low Power Verify (lec -lp -verify)
Genus (genus -legacy_ui)
Innovus Implementation System (innovus)
Design Steps for Generating and Verifying S2:
5.0_eco_start.README
5.1_R2_sdc_quality_check/
5.2_R2_cdc_structural_check/
5.3_R2_power_intent_quality_check/
5.4_S2_physical_synthesis_lp/
5.6_R2_S2_sdc_compare/
5.7_S2_LP_structural_check/
5.8_R2_S2_LP_EC/
Design Steps for Generating and Verifying G3:
6.1a_G3_premask_ECO_FEF/
6.1b_G3_postmask_ECO_FEF/
6.2_G3_vs_S2_LPEC/
6.3_G3_LP_structural_check/
6.4a_E3_premask_eco_implementation/
6.4b_E3_postmask_eco_implementation/
6.6_E3_LP_structural_check/
6.7_S2_E3_LPEC/
6.8_R2_E3_LPEC/
References: Refer to similar RAKs and articles from previous design steps.
6.1a_G3_premask_ECO_FEF
Refer to 5.0_eco_start.README for more info about the ECO flow.
After S2 is generated and verified, Conformal ECO can be used to generate G3.
Conformal ECO patches G1 so that it has the same functionality as S2. It works by
"fixing" non-equivalences found during comparison between G1 and S2. Thus, it is
important to check after comparison between G1 and S2 to ensure all non-equivalences
are related to ECO. If not, delete the non-ECO related non-equivalent points before
doing "analyze eco". If non-ECO related non-equivalent points are not removed, the
patch size and ultimately G3 may be bigger than necessary.
Notes:
1. The "optimize patch" command uses Genus to map and optimize the patch.
Thus, Genus executable needs to in $PATH. Otherwise, update "optimize patch
-synexec" to point to the correct executable.
2. Top-level ports added / deleted due to ECO need to be specified via the "add eco
pin" and "delete eco pin" commands. The added or deleted hierarchical can be
determined automatically.
3. This is a premask ECO run, default for this RAK. The ECO mode is called by the
$ECO_MODE environment.
Tool(s) used: Conformal ECO Designer (lec -eco)

Genus (called by Conformal ECO Designer to do "optimize patch")
To run the design step:
linux$ setenv ECO_MODE premask

linux$ ./RUNME.sh
Other References
RAK: Conformal ECO Designer and EDI System: Enabling RTL-to-GDSII ECO Flows
Article: Error: Failed to find corresponding net(s) in the root module for the following
gates(s)
App Note: ECO-Enabling_RTL_to_GDSII_ECO_Flows Overview

6.1b_G3_postmask_ECO_FEF
Refer to 5.0_eco_start.README for more info about the ECO flow.
After S2 is generated and verified, Conformal ECO can be used to generate G3.
Conformal ECO patches G1 so that it has the same functionality as S2. It works by
"fixing" non-equivalences found during comparison between G1 and S2. Thus, it is
important to check after comparison between G1 and S2 to ensure all non-equivalences
are related to ECO. If not, delete the non-ECO related non-equivalent points before
doing "analyze eco". If non-ECO related non-equivalent points are not removed, the
patch size and ultimately G3 may be bigger than necessary.
Notes:
1. The "optimize patch" command uses Genus to map and optimize the patch.
Thus, Genus executable needs to in $PATH. Otherwise, update "optimize patch -
synexec" to point to the correct executable.
2. Top-level ports added / deleted due to ECO need to be specified via the "add eco
pin" and "delete eco pin" commands. The added or deleted hierarchical can be
determined automatically.
3. This is a postmask ECO run. Default for this RAK is premask. To run postmask,
do "setenv ECO_MODE postmask" before running this design step.

4. There are two sets of spare cells available in this design. One set was added to
the RTL and another was added during P&R (step 4.0). Both are available for
patching process.
5. There should be zero violation after optimize patch, which means that ECO can
be implemented using spare and freed cells. A non-zero violation value means
that ECO cannot be implemented. S3 will still be written out that is functionally
correct. But it cannot be used since it cannot be implemented.
ECO-INFO: Total ECO Violations - 0

ECO-INFO: SYNTHESIS PASSED WITH NO VIOLATIONS
----------------------------------------------------
Tool(s) used: Conformal ECO Designer (lec -eco)

Genus (called by Conformal ECO Designer to do "optimize patch")

linux$ ./RUNME.sh
Other References
Article: Error: Failed to find corresponding net(s) in the root module for the following gates(s)
App Note: ECO-Enabling_RTL_to_GDSII_ECO_Flows Overview


6.2_G3_vs_S2_LPEC
After Conformal ECO generates S3, it is prudent to verify it to make sure S3 is

equivalent to S2. Typically, you use the same ECO dofile and replace G1 with S3.
Sometimes that is not enough, which means false NEQs may show up during
comparison between G3 and G2. Streamlined Setup for ECO Verification is used to
ensure correct validation of S3. This special methodology utilizes information saved
during the Conformal ECO run for verification.
Notes: There is one non-equivalent point (primary output ack_out) between S3 and S2.
This is expected as S2 does not have power switches that were added during P&R.
linux$ setenv ECO_MODE [premask | postmask]

linux$ ./RUNME.sh
Other References
Article: How to speed up the final ECO netlist (G3) versus the new synth netlist (G2)
comparison
Article: What to do if the patched netlist does not prove equivalent to the new
synthesized netlist in the same Conformal ECO session?

6.3_S3_LP_structural_check
After Conformal ECO generates S3, it is prudent to verify it to make sure S3 still
conforms to the original 1801 power intent. Conformal Low Power Verify needs to be
run on S3.
Note: Both design steps, 6.2* and 6.3*, need to be done to completely check the
linux$ setenv ECO_MODE [premask | postmask]

linux$ ./RUNME.sh
Other References


6.4a_E3_premask_eco_implementation
After G3 has been created and verified, you implement the changes in the P&R tool.
Since this is a premask ECO, G3.v is read in and ecoPlace and ecoRoute are run.
linux$ setenv ECO_MODE premask

linux$ ./RUNME.sh
Other References
6.4b_E3_postmask_eco_implementation
After G3 has been created and verified, you implement the changes in the P&R tool.
Since this is postmask ECO, G3.v is read in and only ecoRoute is run. Also,
swapcells.tcl from the ECO run was used to identify how the spare cells are swapped.

linux$ ./RUNME.sh
Other References
Module D: Flow Flow RAK Makefile

The design_steps directory has a Makefile that simplifies the execution of this RAK.

linux$ cd design_steps
linux$ make
===============================================================================================
USAGE: make target_name
--------------------------------------- TARGETS ------------------------------------------
=> make help
<step #> => make <step #>, ex. make 1.0 = run step 1.0
c<step #> => make c<step #>, ex. make c1.0 = clean files in step 1.0
libqual => make libqual performs library qualification, verilog/liberty

=> liberty/liberty
R1qual => make R1qual performs SDC quality, CDC check, UPF quality, LP sim
[v]S1[v] => make S1 = run all steps in order to generate/verify S1

[v]G1[v] => make G1 = run all steps in order to generate/verify G1 from P&R
[v]S2[v] => make S2 = run all steps in order to generate/verify S2 for ECO purpose
[v]premaskG3[v] => make S3 = run all steps in order to generate/verify S3 for ECO purpose
[v]postmaskG3[v] => make S3 = run all steps in order to generate/verify S3 for ECO purpose
[v]premaskE3[v] => make G3 = run all steps in order to generate/verify G3 for ECO purpose
[v]postmaskE3[v] => make G3 = run all steps in order to generate/verify G3 for ECO purpose
=> need to run make S2 first before running make S3 or G3
=> also make sure "setenv ECO_MODE postmask" is run
allpre => run all steps for premask ECO flow from beginning to end
allpost => run all steps for postmask ECO flow from beginning to end
------------------------------- ADMINISTRATIVE TARGETS ------------------------------------

help => Displays this message.
status => State of the FF RAK (which directory has log files)
clean => Removes temp files and directories
eco_clean => Removes temp files and directories related to ECO
===============================================================================================

Some of the tasks you can do are:
 make status: Prints the log file names that exists in the design steps directory;
this indicates steps executed so far.
 make clean: Removes all run data to bring the RAK testcase back to the original
clean state. Design data is removed.
 make vS1: Verifies S1 is implemented correctly; S1 should have already been
done.
 make S1: Implements S1 only, no S1 verification is done.
 make S1v: Implements S1 and then verifies it
 make allpre: Runs all steps starting from library qualification to verifying the G3
after premask ECO implementation. Make sure “setenv ECO_MODE premask” is
executed first.
Support
Cadence Support Portal provides access to support resources, including an extensive
knowledge base, access to software updates for Cadence products, and the ability to
interact with Cadence Customer Support. Visit https://support.cadence.com.
Feedback
Email comments, questions, and suggestions to [email protected].


Full Flow RAK - RTL To Place & Route, Including ECO: Rapid Adoption Kit (RAK)

Uploaded by

Copyright:

Available Formats

Full Flow RAK - RTL To Place & Route, Including ECO: Rapid Adoption Kit (RAK)

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Full Flow RAK - RTL To Place & Route, Including ECO: Rapid Adoption Kit (RAK)

Uploaded by

Copyright:

Available Formats

Full Flow RAK - RTL to Place & Route,

Rapid Adoption Kit (RAK)

Learn more at Cadence Support Portal - https://support.cadence.com

Module A: Introduction / Preparation ........................................................................... 6

Module B: Design Steps Overview ............................................................................ 11

Module C: Design Step Execution ............................................................................. 15

Module D: Flow Flow RAK Makefile........................................................................... 37

Learn more at Cadence Support Portal - https://support.cadence.com

1. Design is small and easy to understand.

2. RAK Testcase Database can be downloaded from the 'Attachments' section at

 Learning: Make a change, rerun the step(s) to see the effects.

Learn more at Cadence Support Portal - https://support.cadence.com

Learn more at Cadence Support Portal - https://support.cadence.com

Module A: Introduction / Preparation

A.1 Tool Setup

 Conformal 17.10-p100 (lec)

linux$ which genus

linux$ which innovus

linux$ which irun

Learn more at Cadence Support Portal - https://support.cadence.com

Cadence tools can be obtained from https://downloads.cadence.com under the

 Conformal > CONFRML171

A.2 RAK Setup

Extract the RAK database and change the directory to it:

linux$ tar xvf ff_rak_testcase.tar.gz

linux$ cd ff_rak_testcase # if not already there

Learn more at Cadence Support Portal - https://support.cadence.com

linux$ cd ff_rak_testcase # if not already there

Design RTL files consists of the following:

SETUP> report modules -instantiation

Learn more at Cadence Support Portal - https://support.cadence.com

Learn more at Cadence Support Portal - https://support.cadence.com

Module B: Design Steps Overview

R1 = RTL of original design

B.2 Overview of design steps for this RAK is as follows:

Step # Tool Used Description Input Output (if any)

Learn more at Cadence Support Portal - https://support.cadence.com

Step # Tool Used Description Input Output (if any)

Learn more at Cadence Support Portal - https://support.cadence.com

Step # Tool Used Description Input Output (if any)

Learn more at Cadence Support Portal - https://support.cadence.com

Learn more at Cadence Support Portal - https://support.cadence.com

Module C: Design Step Execution

linux$ setenv ECO_MODE postmask

linux$ cd ff_rak_testcase # if not already there

To see differences between the files, use tkdiff.

linux$ tkdiff input_data/phy.v eco1_data/phy.v &

Learn more at Cadence Support Portal - https://support.cadence.com

Following are the READMEs in the design step directories:

setenv S1init "$TC_PATH/design_steps/3.0_S1_initial_synthesis"

echo "// Note: setting S1 initial to $S1init"

Learn more at Cadence Support Portal - https://support.cadence.com

Tool(s) used: Conformal LEC (lec -xl)

To run the design step: ./RUNME.sh

Article: Comparing liberty format library with Verilog simulation library

SETUP> add liberty_compare filter skip_cap -attribute_name capacitance -waive

Tool(s) used: Conformal LEC (lec -lp)

To run the design step: ./RUNME.sh

Learn more at Cadence Support Portal - https://support.cadence.com