Lynx Jump Start

Lynx 0.6

1
Agenda
Unit
Topic Lab

1 Lynx Introduction

2 Getting Started with Lynx

3 Technology Library Data

4 Running The Flow

5 Adding New Designs

6 Documentation and Help

2
Moore’s Law Driving Product Complexity

Significant Increase in Design Performance

Average 800
Gate Count 768
at 8.5M

600 Average chip =

M 11 Clock Domains
H
z 400 30+ IP Blocks
on an SoC
Implementation of
200
2003 2004 2005 2006 Low Power2008
2007 is #1
Challenge
Source: SNUG 2007, 2008 Mean

3 Synopsys Confidential
 Challenges @ 65nm & Below
Need Advanced Number of Design Rules By
Process Node
●
● Low Power, SI, DFM, DFY,
Design MM, MC
700

Techniques
600

500 65nM - 1000 Rules!

400

Limited Project ●
● Project progress 300

Visibility ●
● Informed decisions 200

100

350 250 180 150 130 90 6565 45

Complicated (nm)

●
● Validated foundry data
Library & ●
● Sign-off checks
Foundry Setup

Validated ●
● Implement clean IP
Design Inputs ●
● IP compatibility

4
 Introducing Lynx: Delivering Higher
Productivity and Predictability
Production
Production

Runtime
Flow

Runtime
Flow

Manager
Manager

IP-
DFT DFM
Specific
RTL GDSII

Timing/SI Hierarch Low

Closure Design Power

Tech Lib Prep

Foundry
FoundryTape-In
Tape-In
Checklist
Checklist
Lynx Area Performance Power
 DFM/DFY
(fill, vias, diodes )
12.7
12.7 x
x 12.5
12.5 326
326 MHz
MHz 3.0
3.0 W
W
Libs  DRC/LVS rqmts 12.0
12.0 x
x 12.0
12.0 325
325 MHz
MHz 3.0
3.0 W
W
 Post-GDS checks
(added to Lynx) Actual
 STA guidelines Target
(OCV, extr. corners)
100%
100% 97.2%
97.2% 7
7
 EM rqmts
100% 98.5% 5
Tech Files 100% 98.5% 5
Other checks
DRC ATPG ECOs

Manageme
ntntCockpit
Manageme
Ready System

Cockpit
Ready System
Foundry-
Foundry-

5 Synopsys Confidential
 Flo
Produc
Produ
onFlo
Runtim
Runtim
Manag
Manag

on
Building On Proven Success Lynx

Manageme
ntntCockpit
Manageme
Ready System

Cockpit
Ready System
Foundry-
Foundry-

• “Methodologies
7+ years ofassociated
flow deployment
with designing
2009 –
s!

experience
advanced chips that take years to learn
Lynx
t
peou

and understand were incorporated into

• Pilot.”
Close collaboration with IG
– Synchronized w/ tool releases
00 ta

2006-2008 VP of Engineering
Pilot – Based on tool RM’s
Tundra Semiconductor
1

– Support for latest technologies

Over

2002-2006
“TIGER”

6
 Silicon-
ProvenFlo
Fl
Silicon-
Runtim
Runtim
Automati

Proven
Automati

Modular Flow Step

Lynx

Architecture

Manageme
ntntReports
Manageme
Ready System

Reports
Ready System
Foundry-
Foundry-

Global Analysis
PT PT/SI Formality STAR Herc
Tasks
Flow
Steps SYN & DFT DP PNR FINISH

ICC MCMM
DCT ICC
QOR ICC
DCT RM DP RM
RM-Mode

DCT RM DP RM ICC RM

Flow is kept up to date with the latest Synopsys Tool Releases

7
 Producti
Productio
Flow
Runtim

nnFlow
Runtim
Manag
Manag

Foundry-Ready System (FRS) Lynx

Manufacturing-Ready Designs

Manageme
ntntCockpit
System

Manageme
System
Ready

Cockpit
Ready
Foundry-
Foundry-

Accelerate Project Start Accelerate Tape In

Pre- Process
Pre- Validated -specific
Libraries Rep methods
Validated
settings
Tech
Files (OCV…)

Essential
Update
reports
Utilities (PTSI…)

First Time Right First Time Right

Technology Data GDSII Finishing

8
 Producti
Productio
Flow
Runtim

nnFlow
Runtim
Manag
Manag

Technology Prep System Lynx

Manageme
ntntCockpit
System

Manageme
System
Ready

Cockpit
Ready
Foundry-
Foundry-

• Library and technology files

Foundry libs,
pre-validated with the flow tech files
– Automatically configures data for
the Lynx flow
• Eases foundry technology data Pre-test
Pre-test
acquisition
– Continuously synchronized to the
latest foundry updates
Update
Update && Sync
Sync
– Scripted system for downloading with
with Foundry
Foundry
foundry data updates
• Accelerates project start and
Deploy
Deploy complete
complete set
set in
in
execution Lynx
Lynx flow
flow

9 Synopsys Confidential
 Producti
Productio
Flow
Runtim

nnFlow
Runtim
Manag
Manag

Foundry Tape-In Checks Lynx

Manageme
ntntCockpit
System

Manageme
System
Ready

Cockpit
Ready
Foundry-
Foundry-

• Foundry-endorsed, process- Foundry

Foundry Tape-In
Tape-In
specific checks Checklist
Checklist
• Improves “tape-in” quality with
embedded foundry criteria  DFM/DFY
(fill, vias, diodes)
Automated
– Proven methodologies (e.g., metal  DRC/LVS rqmts
In Lynx
fill) Post-GDS checks
 (added to Lynx)
– Representative settings (e.g., OCV)
– Essential reports (e.g., STA w/ SI)
 STA guidelines
(OCV, extr. corners) Partial Automation
• First-time-right, User Completes
 EM rqmts
manufacturing-ready design
submissions Other checks User Checks

10 Synopsys Confidential
 Producti
Runtim

Productio
Flow
Runtim

nnFlow
Manag
Manag

Runtime GUI Improves

Lynx

Designer Productivity

Manageme
ntntCockpit
Manageme
Ready System

Cockpit
Ready System
Foundry-
Foundry-

Guided
Variable Setup

Block-Level
Execution &
Monitoring

Drag-& Drop
Flow
Configuration

Color –Coded
for Easy Error
Identification

11 Synopsys Confidential
 Producti
Productio
Flow
Runtim

nnFlow
Runtim
Manag
Manag

On-Demand Management
Lynx

Reports
Total Area

Manageme
ntntCockpit
Manageme
Cockpit
Ready System
Ready System
Foundry-
Foundry-

• Visibility to key chip metrics Block Area

ATPG Coverage Lynx
Lynx
– User-configurable reports from Flow
Flow
design data captured at run time TNS
…..
Report
Query
– Real-time query means data is
accurate and timely
• Easy access through web Lynx
Lynx dB
dB
(SQL)
(SQL)
browser
• Provides important project info
for management decisions

12 Synopsys Confidential
Anatomy Of A Complete Solution
What’s In Lynx?

Design Environment
Full-Chip R2G Flow
Tool Methodologies
Automation & Utilities
Automation & Utilities Lynx Design System
•• Individual
Advanced tool
•• Recommended
Technology
deployment (UPF,
technologies
configuration
starting point
(hierarchical, MCMM, etc.)
••Block-Level
Based on proven
Technology Node Optimization • Flow execution,
Hard IP Sub-Flows
validation monitoring
flows
Metrics&reporting
•Technology
Optimized technology
hard & soft core sub-
Node
flows
Full-Chip, Hierarchical R2G Flow •DesignFully integrated
Environment
Optimization
• Full flow analysis for timing,
•• power,
Validated
Tested
Job arealibraries
distribution
ARM iRMs •ARM
•• Validated techMethodologies
Reference
Data management
Updated
files
• Core-specific
Tapeout checklists w/
flows optimized for
Block Level Sub-Flows • power,
File &performance,
tool version control
• foundry-specific
Supported tape-in area
•• Endorsed
Multi-user support
criteria by ARM
DCT RM DP RM ICC RM

13
Lynx Benefits: “EDA In A Box”

Lynx Design System

• Proven, low-risk path to

Production
Production
Runtime

Flow
Flow
Runtime
Manager
Manager

65nm and below

• Enhanced designer
productivity
• First-time-right, Lynx
manufacturing-ready
designs
• Improved project visibility
and predictability

Manageme
ntntCockpit
Manageme
System

Cockpit
System
Foundry-Ready
Foundry-Ready

Up and running in a week!

14 Synopsys Confidential
Agenda
Unit
Topic Lab

1 Lynx Introduction

2 Getting Started with Lynx

3 Technology Library Data

4 Running The Flow

5 Adding New Designs

6 Documentation and Help

15
Lynx 0.6 Tools and Utilities for
Flow, Runtime Manager, and FRS
• Running the Lynx R2G Flow involves a wide spectrum of Synopsys tools
• This jumpstart guide assumes the required Synopsys tools and unix
utilities listed below have already been installed
• Synopsys 2008.09 tools require QSCB compliance
– http://www.synopsys.com/Support/Licensing/SupportPlatform/ReleaseSupport/Pages/default.
aspxfor Lynx Flow
• Tools
• Leda 2008.06
• MV Tools 2008.12 • Unix Utilities for Lynx Flow
• DC 2008.09-SP2
• Activetcl 8.4.13
• PT 2008.12
• Formality 2008.09-SP2 • Gmake 3.80
• Tetramax 2008.09-SP2
• ICC 2008.09-SP2
• Tools & Utilities for Lynx FRS
• Milkyway 2008.09 –SP2 • Activetcl 8.4.13
• StarRCXT 2008.12 • Gtar 1.14
• Gmake 3.80
• Hercules 2008.09-1
• Perl 5.8.5
• PrimeRail 2008.12 • Patch 2.5.4
• Hspice 2008.09-SP1 • DC 2007.12
• Milkyway 2008.09
• VCS MX 2008.12 • StarRCXT 2008.06-SP2
• ICWB 2008.12

16
Management Cockpit Unix Utilities
• Synopsys QSC A/B/C
• Java Runtime Environment - Sun Java 2
Standard Edition 6.0 Update 7 or higher
– available on micro, can be loaded by module
load
– Installing Java Runtime Environment
• Go to
– http://java.sun.com/javase/downloads/index.jsp
• Select latest version
– Java SE Runtime Environment (JRE) 6 Update 10
• Click “Download”
• Select your platform and follow the installation
instructions on the download page
17
Management Cockpit 3rd-party Libraries
Name Version License Link Download
ZK 3.5.2 Commercial https://sourceforge.ne Link
(JFreeC (JFreeChart LGPL ) t/project/downloading. (tar.gz)
hart php? Link (zip)
included groupname=zk1&filen
) ame=zk-bin-prof-
3.5.2.zip
Apache 5.5.27 Apache License V2.0 http://apache.mirror.fa Link(tar.gz)
Tomcat cebook.com/tomcat/t Link(zip)
omcat-
5/v5.5.27/bin/apache-
tomcat-5.5.27.zip
Apache 10.4.2 Apache License V2.0 http://www.hightechim Link(tar.gz)
Derby pact.com/Apache/db/ Link(zip)
derby/db-derby-
10.4.2.0/db-derby-
10.4.2.0-lib.zip

18
Loading the Runtime Manager (Internal
only)
• Internal Synopsys users do not need to install the
runtime manager.
• Internal users can simply load the runtime
manager that has already been installed on all
Synopsys DSA clusters

Unix> module use /global/cust_apps_sgps001/pilot/admin/modulefiles

Unix> module load lrtm

19
Installing the Runtime Manager - External
(1/2)
• External customers must install the Lynx Runtime Manager
• The Runtime Manager is delivered as a compressed tarfile. It includes all binary files needed
by the Lynx flow.
• The runtime manager is delivered separately from the flow so that multiple projects can utilize
the same binaries. It does NOT have to be installed in the same directory as the lynx flow.

Unix> mkdir <rtm_install_dir>

Unix> cd <rtm_install_dir>
Unix> cp version_X.X.X.tar.gz .
Unix> gunzip version_X.X.X.tar.gz
Unix> tar xvf version_X.X.X.tar

<rtm_install_dir>/
<rtm_install_dir>/

version_X.X.X/
version_X.X.X/

admin/
admin/ auxx/
auxx/ bin/
bin/ doc/
doc/ linux/
linux/ suse32/
suse32/

20
Installing the Runtime Manager - External
(2/2)
• To use the binaries contained in the Runtime Manager installation,
simply add the bin directory to your unix path.
• Some binaries delivered with the Runtime Manager will pull a
license: Lynx-DB. This feature must exist in the license file you are
pointing to with LM_LICENSE_FILE or SNPSLMD_LICENSE_FILE

Unix> setenv LM_LICENSE_FILE <license_server> ## must contain LYNX features

Unix> setenv PATH <rtm_install_dir>/version_X.X.X/bin:$PATH

21
Installing the Lynx Flow

• The Lynx Flow is delivered as a compressed tarfile. Install

Lynx Flow as shown.
• Every project will have a separate installation of the Lynx Flow,
but multiple projects can use the same Runtime Manager.

Unix> mkdir <flow_install_dir>

Unix> cd <flow_install_dir>
Unix> cp lynx_version_X_X.tar.gz .
Unix> gunzip lynx_version_X_X.tar.gz
Unix> tar xvf lynx_version_X_X.tar
Unix> ./lynx_version_X_X/bin/install.tcl –style project –tech TSMC65LP.TSMC.A

<flow_install_dir>/
<flow_install_dir>/

bin/
bin/ cache/
cache/ doc/
doc/ metrics/
metrics/ release/
release/ user/
user/

22
 Verifying Unix Utilities

• Lynx flow Unix> ./lynx_version_X_X/bin/check_apps.tcl

contains a utilities
to use to verify
that you have the
correct unix
utlities installed
• Invoke this utility
after installation

23
 Environment Settings for Lynx Flow

• You must make a few settings in your environment

before using Lynx Flow
• You can use the same settings as shown below.
– The first 2 lines define where Lynx is installed and adds a
directory to your unix path
– The last 2 lines tell Lynx which library data you are using.
The value of SEV_TECHLIB_ROOT will be different for
each customer. This will be discussed further in the
Library Data section
Unix> setenv SEV_PROJECT_ROOT <flow_install_dir>
Unix> setenv PATH $SEV_PROJECT_ROOT/bin:$PATH
Unix> setenv SEV_TECHLIB_ROOT /global/cust_apps_sgps001/pilot/techlib/tsmc65lp.tsmc.a.2009_01_07
Unix> setenv SEV_TECHLIB TSMC65LP.TSMC.A

24
Configuring Job Distribution (1/2)

• By default, Lynx is configured

to use LSF for job distribution
(SEV_JOB_DIST=lsf)
• Lynx also has support for
GRD and for running without
job distribution
(SEV_JOB_DIST=grd|none)
• If you need to change the
default settings, edit the
appropriate variables in
<flow_install_dir>/user/exam
ple_user/example_workarea/
scripts_global/conf/tool_laun
ch_part2.make

25
Configuring Job Distribution (2/2)

• In addition to specifying
whether you are using LSF,
GRD, or no job distribution,
Lynx contains variables for
specifying which log options get
passed to LSF or GRD
– LSF
• SEV_JOB_RESOURCES – the
value of this variable get passed by
Lynx to LSF through the –R option.
E.g. bsub –R
$SEV_JOB_RESOURCES
– GRD
• SEV_JOB_OPTS – the value of this
variables allows you to specify valid
GRD options that get passed
automatically to qrsh. E.g. setenv
SEV_JOB_OPTS “-l
arch=glinux,qsc=b”.

26
 Configuring Tool Loading
• By default, Lynx is configured to
an application called modulefiles
for loading and unloading of tool
paths and licenses
(SEV_APP_METHOD=module)
• If you do not use modulefiles and
would like Lynx to simply use the
tool setup that already exists in
your environment, Lynx also has
support for running without
modulefiles.
(SEV_APP_METHOD=none)
• If you need to change the default
settings, edit the appropriate
variables in
<flow_install_dir>/user/example_u
ser/example_workarea/scripts_glo
bal/conf/tool_launch_part1.make

27
Lynx Work Area
• Lynx is a full design system that is
architected to support multiple users and
flat or hierarchical designs
• The first step for any user to start working
with Lynx is to create a Lynx user directory
and work area
<flow_install_dir>/
<flow_install_dir>/

bin/
bin/ cache/
cache/ doc/
doc/ metrics/
metrics/ release/
release/ user/
user/

example_user/
example_user/

example_workarea/
example_workarea/
28
 Workarea Directory Structure
• A Lynx workarea consists of 4 directories. For the 3 directories where scripts can be located, Lynx
automatically defines 3 variables which are used to point to these 3 different areas
– sample_designs – default location for RTL, this is optional
– scripts_techlib – technology scripts, $SEV_TSCRIPT_DIR=scripts_techlib/$SEV_TECHLIB
– scripts_global – global scripts, $SEV_GSCRIPT_DIR=scripts_global
– blocks – this is where work is done, $SEV_BSCRIPT_DIR=blocks/<design_name>/scripts_block
<username>/
<username>/

<workarea>/
<workarea>/

sample_designs/
sample_designs/ scripts_techlib/
scripts_techlib/ scripts_global/
scripts_global/ blocks/
blocks/

Location for sample design “global”

source HDL <$SEV_TECHLIB>/
<$SEV_TECHLIB>/ scripts …
<block>/
<block>/ <block>/
<block>/
conf/
conf/ scripts_block/
scripts_block/ scripts_block/
scripts_block/

common.tcl
common.tcl “block” “block”
scripts scripts

“technology”
scripts
29
Creating a Work Area

• In a real project involving multiple users, it

is recommended that the Lynx workarea
directories (blocks, scripts_techlib,
scripts_global, sample_designs) be kept
under revision control.
• For jumpstart training, it is fine to simply
make a copy of the example_workarea
directory
Unix> cd <flow_install_dir>/user
Unix> mkdir <username>
Unix> cd <username>
Unix> cp –r ../example_user/example_workarea my_workarea
Unix> cd my_workarea

30
Lynx Runtime Manager

• The Lynx RunTime

Manager is the
user interface into
the Design System.
– Library data
configuration
– Design Flow
configuration
– Running the flow

31
 Starting the Runtime Manager

• Note!!! To invoke the

Runtime Manager, the
host machine most
meet the following
requirements
• Linux QSCB
compliant
• You can specify your
preferred text editor by
setting SEV_EDITOR
• E.g. setenv
SEV_EDITOR nedit

Unix> cd <flow_install_dir>/user/<username>/my_workarea
Unix> setenv SEV_EDITOR nedit
Unix> rtm_shell &
32
LAB 1

• See lab manual

33
Agenda
Unit
Topic Lab

1 Lynx Introduction

2 Getting Started with Lynx

3 Technology Library Data

4 Running The Flow

5 Adding New Designs

6 Documentation and Help

34
 Lynx Built-In Library Support

• Lynx has built-in support for

TSMC65LP libraries.
– technology-specific scripts are
provided
– Lynx FRS generates the library data
for TSMC65LP
• Lynx is flexible enough to be
used with any library
– Lynx is architected to separate
technology-specific scripts for global
scripts that should work for any
technology. This make it very easy
to “unplug” TSMC65LP and insert a
different library.
– For non-TSMC65LP operation,
users must provide their own Unix> setenv SEV_PROJECT_ROOT <flow_install_dir>
technology-specific scripts and Unix> setenv PATH $SEV_PROJECT_ROOT/bin:$PATH
Unix> setenv SEV_TECHLIB_ROOT <lynx_techlib_location>
library data. Unix> setenv SEV_TECHLIB TSMC65LP.TSMC.A

35
 Library Data in Lynx

• The Lynx
Runtime Manager
contains a
window called
Common
Navigator.
• To open this
window, select
Window->
Common
Navigator

36
 Common Navigator == common.tcl
• Common Navigator is a graphical editor for an important Lynx file called common.tcl
• Common.tcl is located in a Lynx directory called scripts_techlib. This directory is where all common
technology-specific settings and scripts are stored in Lynx. The library itself is NOT stored in
scripts_techlib
• Note that the environment variable SEV_TECHLIB must be set to be to the same value as the name of the
directory directly underneath scripts_techlib
<username>/
<username>/

<workarea>/
<workarea>/

sample_designs/
sample_designs/ scripts_techlib/
scripts_techlib/ scripts_global/
scripts_global/ blocks/
blocks/

Location for sample design “global”

source HDL <$SEV_TECHLIB>/
<$SEV_TECHLIB>/ scripts …
<block>/
<block>/ <block>/
<block>/
conf/
conf/ “local” “local”
scripts scripts

common.tcl
common.tcl

Multiple Block Support

“technology”
scripts
37
Common Navigator Details
• Common Navigator allows
you to modify common.tcl
• common.tcl is a file which
consists solely of Lynx
variable definitions called
SVAR(*)
• Double clicking on a listing
in Common Navigator (e.g.
Milkyway) will bring up a
panel with variable
definitions
• Notice that the variable
values may reference a
variable called
SEV(techlib_root)
– This TCL variable is
automatically derived from
the environment variable
SEV_TECHLIB_ROOT

38
 common.tcl Details

• common.tcl
• Located under
Lynx directory
scripts_techlib/$S
EV_TECHLIB/conf
• Can be edited using
Common Navigator
window in Runtime
Manager
• Contains SVAR
definitions that point to
your library data located
underneath
$SEV_TECHLIB_ROOT

39
SEV_TECHLIB_ROOT Details
<$SEV_TECHLIB_ROOT>
<$SEV_TECHLIB_ROOT>

• SEV_TECHLIB_ROOT is a tech/
tech/ lib/
lib/
pointer to the root directory doc/
doc/ <lib
<lib1>/ <lib
<libN>/
that contains your library 1>/ N>/
hercules_drc/
data hercules_drc/ doc/
doc/ doc/
doc/

• For TSMC65LP, the hercules_lvs/

hercules_lvs/ db/
db/ db/
db/

contents of hspice/
hspice/ gds/
gds/ gds/
gds/
SEV_TECHLIB_ROOT are milkyway/
milkyway/ hspice/
hspice/ hspice/
hspice/
created with Lynx FRS starrc_xt/
starrc_xt/ lef/
lef/ lef/
lef/
(Foundry Ready System)
lvs/ lvs/
– FRS is a separate lvs/ lvs/

component of Lynx milkyway/

milkyway/ milkyway
milkywa
– FRS is currently available verilog/
verilog/ verilog/
verilog/
only for TSMC65LP
vhdl/
vhdl/ vhdl/
vhdl/

40
 FRS Creates SEV_TECHLIB_ROOT

DW_TSMC_tcbn65lpcg_front_140a.tar.gz
DW_TSMC_tcbn65lpcg_back_140a.tar.gz
DW_TSMC_tcbn65lp_front_140b.tar.gz
DW_TSMC_tcbn65lp_back_140b.tar.gz
DW_TSMC_tcbn65lp_ccs_140b.tar.gz
DW_TSMC_tcbn65lpcg_ccs_140a.tar.gz

DW_TSMC_tcbn65lpcglvt_front_140a.tar.gz
DW_TSMC_tcbn65lpcglvt_back_140a.tar.gz
DW_TSMC_tcbn65lplvt_front_140b.tar.gz
DW_TSMC_tcbn65lplvt_back_140b.tar.gz
DW_TSMC_tcbn65lplvt_ccs_140b.tar.gz
DW_TSMC_tcbn65lpcglvt_ccs_140a.tar.gz
Foundry-
DW_TSMC_tcbn65lpcghvt_front_140a.tar.gz
DW_TSMC_tcbn65lpcghvt_back_140a.tar.gz
DW_TSMC_tcbn65lphvt_front_140b.tar.gz Ready
DW_TSMC_tcbn65lphvt_back_140b.tar.gz
DW_TSMC_tcbn65lphvt_ccs_140b.tar.gz
DW_TSMC_tcbn65lpcghvt_ccs_140a.tar.gz System
DW_TSMC_tpzn65lpgv2_front_140b.tar.gz
DW_TSMC_tpzn65lpgv2_back_140b.tar.gz
DW_TSMC_tpbn65gv_front_140a.tar.gz
DW_TSMC_tpbn65gv_back_140a.tar.gz

tn65clls001e1_1_3b.zip
tn65cldr001h3_1_4a.zip
tn65cldr001h2_1_4a.zip
t-n65-cl-dr-001-h1_1_4b_20080708.zip
t-n65-cl-sp-009-b1_1_2a_20070119.zip

41
 Flo
Flow
Silicon-
Runtim

Silicon-
Proven
Runtim
Automati

Proven
Automati

FRS Lynx

Manageme
ntntReports
System

Manageme
System
Ready

Reports
Ready
Foundry-
Foundry-

• The Foundry-Ready System consists of 2 main

components
– Scripts to create a complete pre-validated library
– Custom check-lists with foundry-specific signoff criteria
• Using FRS is not a requirement for being a Lynx
customer
• Out of the box-testing of the Lynx flow is only
possible using a pre-configured FRS node
– Using non-FRS libraries will require some
customization by the user

42
Using Lynx FRS for TSMC65LP

• Download FRS scripts and untar

• Download FRS library files
• Configure for your environment (job dist, tool loading)
• Run FRS
• The end-result is a Lynx-ready library

43
Downloading FRS Scripts

• FRS is a tarfile
• Get the tarfile from the Lynx CAE. Eventually, this may
come from EST
• Uncompress/Untar the tarfile
• gunzip lynxxx_frsyy_<TECH>.tar.gz
• tar xvf lynxxx_frsyy_<TECH>.tar

44
FRS Directory Structure
FRS
FRSROOT/
ROOT/ User need to setenv for FRS_ROOT
release/
release/ Contains BOM list
work/
work/ newlib/
newlib/ Generated lib store here
tmp/
tmp/ Directory where FRS is invoked
patch/
patch/ Contains patch for tech files
scripts_frs/
scripts_frs/
All scripts are kept in scripts* directory
scripts_stdcell/
scripts_stdcell/ scripts_frs – Top level makefile, setup scripts
scripts_tech/
scripts_stdcell – stdcell lib build flow
scripts_tech/
scripts_tech – for star-rcxt, hercules
scripts_ram/
scripts_ram/ scripts_ram – ram lib build flow
scripts_io/
scripts_io/
scripts_io – io lib build flow
scripts_pll – pll lib build flow
scripts_pll/
scripts_pll/

logs/
logs/ Logs for FRS run
Misc
MiscPDF
PDFfile
file RELEASE_NOTES / README / KNOWN_ISSUES

45
 BOM (Bill of Materials) List

• The BOM contains a list of

library files the user needs
before running FRS.
• The list of files needed is
located in release/ref_bom.list.
• The BOM is split into sections.
Users only need to download
files from the sections they plan
to use
• There are 2 different types of
files in the list.
• DesignWare TSMC library
files
• Technology files from TSMC

46
 Lynx FRS: Technology Installation

TSMC65LP:1P8LM Technology FRS

tn65clls001e1_1_3b.zip
tn65cldr001h3_1_4a.zip
tn65cldr001h2_1_4a.zip TSMC65LP
t-n65-cl-dr-001-h1_1_4b_20080708.zip Technology setup
t-n65-cl-sp-009-b1_1_2a_20070119.zip

TSMC65LP:tcb65_hvt Library FRS

DW_TSMC_tcbn65lphvt_front_140b.tar.gz
DW_TSMC_tcbn65lphvt_back_140b.tar.gz
TSMC65LP
DW_TSMC_tcbn65lphvt_ccs_140b.tar.gz Library setup

TSMC65LP:tcb65_lvt Library FRS

DW_TSMC_tcbn65lplvt_front_140b.tar.gz
DW_TSMC_tcbn65lplvt_back_140b.tar.gz
TSMC65LP
DW_TSMC_tcbn65lplvt_ccs_140b.tar.gz Library setup

47
 Downloading DesignWare TSMC
Libraries
• Download designware
TSMC files (DW_*) from
SVP café. 
http://www.synopsys.com/dw/tsmc.php

  
• Must have a solvnet
account, and be a
designware customer with
a click-thru agreement.
• NOTE!!!!!! Internal
Synopsys users should
use SVP Cafe Ultra to get
the DW libraries
http://svpcafeultra.synopsys.com/

48
 Downloading TSMC Technology Files

• Download techfiles (Herc, Star, …) from

http://online.tsmc.com/online/ .  Must
have a TSMC online account.
• Login using your TSMC username
and password
• Click on the “Design Portal 2.0” link
from the home page
• In the “Technology Selection” tab,
click to select the “65nm” Technology
Node and “CLN65LP”. Then click the
“Next” button
• Under “Technology File and PDK”
select the following and then click the
“Search” button
• DRC Command File
• RC Extraction
• GDS Layer Usage Description
• LVS Device Formation Doc
• LVS Command File
• Synopsys (under LVS Command
File)
• Download the Files in bom.list

49
 Configure FRS for Your Environment

• Read README.pdf and

RELEASE_NOTES.pdf.
Instructions for configuring FRS
are contained in README.pdf.
• Configure FRS job distribution
by editing appropriate variables
in
scripts_frs/frs_config.gmake
• FRS required tool versions are
listed in README.pdf. The
user must have these tool
versions loaded in your
environment before running
FRS

50
 frs_config.gmake (1/4)

• At a minimum, you will

need to set
FRS_ROOT and
change
FRS_DWNLOAD_SRC
to point to the location
where you downloaded
the FRS library data.
• You may also need to
change variables
related to job
distribution

51
 frs_config.gmake (2/4)

• Contains job
distribution settings,
FRS_JOB*. Adjust
these appropriately
for your
environment. FRS
has built-in support
for LSF, GRD, and
no job distribution.

52
 frs_config.gmake (3/4)

• FRS has several variable that

allow you to customize which
library data is processed.
This enables users to only
download the BOM files that
they need instead of
downloading all files
• FRS_TLP_MVTH_MODE
• FRS_TLP_CCS_REQD
• FRS_TLP_VDD_REQD
• FRS_PROCESS_STDCELL
• FRS_PROCESS_IO
• FRS_PROCESS_RAM
• FRS_PROCESS_TECH

53
 frs_config.gmake (4/4)
• FRS has 3 different methods for
creating TLUPLUS/NXTGRD Data
controlled by the variable
FRS_STARRC_DATA.
• TSMC(default) – Use TSMC pre-
generated files where possible and
generate the remaining data from
scratch. TLUPLUS/NXTGRD files
with emulated metal fill capabilties
are not provided by TSMC and
must be generated.
• SNPS – Use Synopsys pre-
generated files. This option is only
available to internal Synopsys
users
• USER – generate all
TLUPLUS/NXTGRD files from
scratch (runtime may be very long)

54
 Running FRS

• The top-level makefile which defines the FRS flow is

“scripts_frs/frs_cust.gmake”
• To run FRS
• Cd <frs_install_dir>/tmp
• Make sure tools and utilities are installed.
• Active TCL 8.4.13
• Perl 5.8.5
• Tar 1.14
• Gmake 3.80
• Patch 2.5.4
• Syn 2007.12
• Milkyway 2008.09
• StarRCXT 2008.06-SP2
• gmake -f ../scripts_frs/frs_cust.gmake build_frs

55
 FRS Outputs
<$SEV_TECHLIB_ROOT>
<$SEV_TECHLIB_ROOT>

• FRS creates a TSMC65LP tech/

tech/ lib/
lib/
library in
doc/
doc/
<frs_install>/TSMC65/work/ <lib
<lib1>/
1>/ <lib
<libN>/
N>/

that can be used to build hercules_drc/

hercules_drc/ doc/
doc/ doc/
doc/
the des_chip sample design hercules_lvs/
hercules_lvs/ db/
db/ db/
db/
• Set SEV_TECHLIB_ROOT hspice/
hspice/ gds/ gds/
gds/ gds/
to point to the library milkyway/
milkyway/ hspice/
hspice/ hspice/
hspice/
created by FRS
starrc_xt/
starrc_xt/ lef/
lef/
• The technology-specific lef/ lef/

scripts directory lvs/

lvs/ lvs/
lvs/

scripts_techlib/TSMC65LP. milkyway/
milkyway/ milkyway/
milkyway/
TSMC.A will work with the verilog/
verilog/ verilog/
verilog/
FRS-generated techlib
vhdl/
vhdl/ vhdl/
vhdl/

The end-result is a Lynx-ready library !

56
 Using non-TSMC65LP Library Data

• Lynx can be used with any library data.

• Running FRS is not a requirement for running Lynx.
• Using a different library involves the following steps
• Pick a name for your library, e.g. NEW_LIB.
• Create a new scripts_techlib directory for your library by copying
scripts_techlib/TSMC65LP.TSMC.A
• Set SEV_TECHLIB and SEV_TECHLIB_ROOT to the appropriate
values.
• Start the Runtime Manager and configure common.tcl for you library
Unix> cd <flow_install_dir>/user/<username>/my_workarea/scripts_techlib
Unix> cp –r TSMC65LP.TSMC.A NEW_LIB
Unix> setenv SEV_TECHLIB NEW_LIB
Unix> setenv SEV_TECHLIB_ROOT <root directory for your library>
Unix> rtm_shell &

57
 common.tcl Outline
• There are three classes of
variables defined in the
common.tcl file
– SVAR(config,*)
• Library /Scenario
settings
• Flow configuration
settings
– SVAR(tech,*)
• Identifies a technology
specific variable that is
common across all
libraries used in the
flow. E.g. techfile,
layer mapping files,
tluplus, nxtgrd,
DRC/LVS
– SVAR(lib,<lib_name>,*)
• Identifies a library
specific variable for the
indicated library name

58
 Library/Scenario Variables
• Expand the tree below
Library/Scenario in the Techlib
Navigator window to show “Library
Names” and “Scenario Elements”
• These variables are propagated
forward into other sections of
variable configuration as will be
shown in the following slides
• Double click on either of these
entries to configure the SVARs
associated with them
– Library Names
• SVAR(config,setup,lib_types_list)
– Scenario Elements
• SVAR(config,setup,oc_types_list)
• SVAR(config,setup,rc_types_list)
• SVAR(config,setup,mm_types_list)

59
 Technology Variables, SVAR(tech,*)

• These variables are

associated with technology
components that are
common to all libraries
used in the project
• They are split into three
panels.
– Milkyway
– Parasitics
– Hercules
• In the “Parasitics” window,
you will be allowed to enter
data (nxtgrd,tluplus) for
each RC type defined
previously in the
Library/Scenario variables

60
 Library Variables, SVAR(lib,<lib_name>,*)

• For each Library Name

defined earlier, the
Runtime Manager will
allow the user to point
to the specific library
files for each library
– DB files (one for each
OC type defined earlier)
– SDB (if it exists)
– Milkyway reference
library
– Verilog files
– LVS and hspice netlists

61
Saving Changes to common.tcl (1/2)

• After you make

changes to a
SVAR, you
must click the
“Apply” button
to commit the
changes
• Clicking Apply
does NOT save
the changes

62
Saving Changes to common.tcl (2/2)

• If you have applied

your changes and
are ready to save
them, click
Variables-> Save
SVAR Files…
• In the pop-up
menu, click the
check-box next to
Common. Then
click OK to save
the new version of
common.tcl

63
Agenda
Unit
Topic Lab

1 Lynx Introduction

2 Getting Started with Lynx

3 Technology Library Data

4 Running The Flow

5 Adding New Designs

6 Documentation and Help

64
 Blocks Directory
• The Lynx flow itself is actually run from within
“blocks” directory
• Each block that is built separately as part of your
chip will have its own directory underneath “blocks”

<username>/
<username>/

<workarea>/
<workarea>/

sample_designs/
sample_designs/ scripts_techlib/
scripts_techlib/ scripts_global/
scripts_global/ blocks/
blocks/

Location for sample design “global”

source HDL <$SEV_TECHLIB>/
<$SEV_TECHLIB>/ scripts
<block>/
… <block>/
<block>/ <block>/
conf/
conf/ “local” “local”
scripts scripts

common.tcl
common.tcl

“technology” Multiple Block Support

scripts

65
 Des_hard_macro

• Des_hard_macro is the
recommended design to use
for quickly testing the flow
and library configuration.
– It can be built out-of-the box
with FRS-generated
TSMC65LP data
– It is very small and thus builds
very quickly which allows for
quick turnaround times.
– It is a standard-cell only
design so it can very easily be
targeted to any non-FRS
library

66
Lynx Flow Architecture
• The Lynx R2G flow is made of 4 “steps”: SYN, DP, PNR, and
FINISH
• Analysis (STA, formality,…) is run at the end of each step.
• All Lynx flows, whether they are step flows or analysis flows
– Are encapsulated in makefiles
– Can be viewed and configured graphically with the Runtime Manager
– Can be executed, monitored, and debugged within the Runtime Manager

Global Analysis
PT PT/SI Formality STAR Herc
Tasks
Flow SYN DP PNR FINISH
Steps

DCT ICC ICC ICC

67
Lynx Flows Example
blocks

des_hard_macro
Block Flow – block_flow.rtm/
block_flow.make

scripts_block syn dp pnr finish

formal sta power syn dp pnr finish

formal.rtm sta.rtm power.rtm flow_syn.rtm flow_dp.rtm flow_pnr.rtm flow_finish.rtm

Analysis Flows Step Flows

Task Flows
• There will always be one Block Flow per block
• Task Flows
– There will always be one Step Flow per step
– There will usually be one Analysis flow for each type of analysis

68
Lynx Flow Terminology

• All Lynx flows are saved in a .rtm format that is configurable

with the Runtime Manager
• An executable version of the flow , in .make format, can be
written out from the Runtime Manager.
flow.rtm  Runtime Manager  flow.make
• There are 2 types of flows that are captured in Lynx
– Block Flows
• Defines entire design flow for a block
• Contains block targets (call to a task flow for the current block) and/or sub-
block targets(call to a block flow for a sub-block)
– Task Flows
• Define one part of the design flow for a block, e.g. synthesis or STA
• Contains only task targets

69
Opening Block/Task Flows

• Double-click on a
block in the Block
Navigator to access
any block/task flows
defined for a given
block.
• Browse through the
“Block Flows” or
“Task Flows” tree
and click the flow
you want to open.
• All flows are saved
as a *.rtm file.

70
.rtm Files

• A .rtm file is a TCL file

which is used to store
rtm_shell commands
(ds_*) that define a flow.
• All flow modification can
be done graphically
through the GUI.
• Although it is possible to
edit the *.rtm file by
hand, it is recommended
that you use the GUI to
do all configuration for
step/analysis flows.

71
Building des_hard_macro
• After running FRS to build the TSMC65LP
library, you are ready to build des_hard_macro
– The flow for des_hard_macro is defined in a series of
makefiles that we will discuss in the following slides
• The entire RTL2 GDS flow for des_hard_macro
can be run by executing the block flow.
• The recommended method for executing the
block flow is to use the Runtime Manager
although it is also possible to invoke the flow
from the unix command line.

72
Des_hard_macro Block Flow:
block_flow.rtm
• This is the block flow for
des_hard_macro
• It contains only block
targets (8 of them).
• It is considered “flat” in
nature because it does not
contain any sub-block
targets
• The arrows indicate
dependencies. E.g.
dp.optimize cannot run until
syn.optimize has completed
• The “all” target is a phony
target that when invoked will
result in all 8 block targets
being invoked in order,
according to the
dependencies.

73
Flat Block Flow Structure

• The default structure of a flat block

flow consists of 1 <step>.optimize
block target and 1 <step>.analyze
block target for each step
• <step>.optimize – refers to the step
task flow for <step>
• <step>.analyze – refers to 1 or
more analysis task flows which are
run at the end of the step
• Right-click over a block target and
select “Properties” from the pop-up
menu to see what each block
target refers to

74
Building des_hard_macro with the
Runtime Manager (1/2)
• Right-click on
the “all”
target and
select
“Execute”
• This will
Bring up the
Execution
Manager

75
Building des_hard_macro with the
Runtime Manager (2/2)
• The Execution
Manager
allows us to
execute,
monitor and
debug the Flow
• It conists of a
list of all tasks
needed to build
the “all” target

76
Executing the Flow (1/3)
• Click on the
“Execute” button
to run the flow
and build the “all”
target.
• This will invoke
the flow using the
job distribution
settings that have
been configured
previously

77
Executing the Flow (2/3)
• You can build a
target other than
“all” by right-clicking
over the target you
want to build (e.g.
syn.optimize) and
selecting “Set
Execute Target”
from the pop-up
menu
• Then click the
“Execute” button to
build the target

78
Executing the Flow (3/3)
• Once the flow
has started to
run, you can
stop
execution of
the flow at
any point by
click the
“Stop” button

79
Running the block flow for
des_hard_macro (1/3)
• Here is a more detailed look at what
happens when you run the block flow for
des_hard_macro as indicated previously

• The “all” target is executed which will…..

• 1. Run syn.optimize
• 2. after syn.optimize completes, run syn.analyze
and dp.optimize
• 3. after dp.optimize completes, run dp.analyze and
pnr.optimize
• 4. after pnr.optimize completes, run pnr.analyze and
finish.optimize
• 5. after finish.optimize completes, run finish.analyze

80
Running the block flow for
des_hard_macro (2/3)

• The <step>.optimize and <step>.analyze targets invoke task flows

• To see which task flows are being invoked, right-click on any of the
block targets and select “Properties” in the pop-up menu
– Step – Tells Lynx which step directory to invoke the flow file from
– Flow File – Tells Lynx which flow file(s) to invoke
– Target – Tells Lynx which target in the Flow File to build

81
Running the block flow for
des_hard_macro (3/3)
• Each block target (e.g. syn.optimize) invokes 1 or more
task flows
• Syn.optimize ==
• scripts_block/syn/flow_syn.rtm
• Syn.analyze ==
• Scripts_block/formal/flow_formal.rtm
• Scripts_block/sta/flow_sta.rtm
• Scripts_block/atpg/flow_atpg.rtm
• Dp.optimize ==<view task properties>
• Dp.analyze==<view task properties>
• Pnr.optimize ==<view task properties>
• Pnr.analyze==<view task properties>
• Finish.optimize ==<view task properties>
• Finish.analyze==<view task properties>

82
 Lynx Task Flows
• A task flow is defined for each Lynx “step” for each design. A task flow is also defined for each
analysis type.
• The task flows are composed of related tasks, task targets, with each task target corresponding to a
single tool script that is run in the flow
SYN – flow_syn.rtm DP – flow_dp.rtm PNR – flow_pnr.rtm FINISH – flow_finish.rtm

83
Lynx Task Flow Example: flow_syn.rtm
• Block Name: Flow
Name – Use this to
identify each flow
when multiple flows
are open at the same
time
• Flow Diagram
• Task target – each
box corresponds to a
single invocation of a
tool to run a task
script
• Connector – arrow
connecting 2 task
targets

84
Most Common Types of Flow
Configuration
• Edit properties for existing task targets
– Automation
– Script
• Add/remove task targets
• Change/add task connections
• Save a Flow

85
Task Properties

• Double-click
over a task
target to bring
up the
Properties
window. There
are 2 tabs
– Script
– Automation

86
Script Settings

• The script tab allows the

user to specify task-
specific settings (TEV)
which are defined in the
script which is referenced
on the Script tab
• There are different
methods for modifying
TEV values, depending
on the variable type
– Use the default
– File Browsing
– String entry
– Boolean (0/1)

87
Automation Settings

• The automation tab supplies the basic

information Lynx needs in order to run a
task
– Tool – tells Lynx which tool to run
– Source/Destination – set automatically
according to connections between tasks, but
can be changed manually simply entering
the desired source or destination in the text
box or by selecting from the pull-down menu
– Script - tells Lynx which script to run. Can
be changed by choosing a different script
– Log Checking – gives the user the ability to
specify custom logfile checks for each task
– Pre/Post Tool Shell Commands – rarely
used option that allows the user to run
additional scripts before and/or after the tool
listed in the “Tool” entry has run.

88
Saving a Flow

• Select Flow ->

Save Flow to
save flow
changes you
have made. This
will update the
.rtm file and write
out a .make file.
• To save the flow
to a different
name or location,
select Flow->
Save Flow As

89
Monitoring the Flow (1/3)
• As the flow runs, the
execution manager
uses color-coding to
communicate the
status of tasks. A
completed task will
have one of 3 possible
colors
– Red: the task has failed
– Green: the task has
passed
– Yellow: a passfile has
been manually touched
to allow the flow to
continue

90
Monitoring the Flow (2/3)
• As a task is
running,
additional
colors are used
to tell you the
current status
of the task.
• Click Window
-> Legend to
see what each
color means

91
Monitoring the Flow (3/3)
• As you run the
flow, the
Runtime
Manager will
print out a
banner which
gives you
details about
the current task
that is running

92
Re-starting the Flow From an Earlier
Point
• You can re-execute
the flow starting with
any task, even if the
task has passed.
• Right-click on the task
(e.g. setup), select
“Pass Files” and click
“Delete Current” to
delete the passfile.
• To create a passfile for
a task that has failed,
select “Pass Files” ->
“Touch Current”
• Click Execute to re-
start flow execution.

93
Viewing Flow Results with Runtime
Manager
• You can
view log
files,
pass/fail
files, and
report files
from within
the
Execution
Manager

94
Viewing Flow Results Manually
blocks

des_hard_macro
Block Flow – block_flow.rtm/
block_flow.make

scripts_block syn dp pnr finish

formal sta power syn dp pnr finish

formal.rtm sta.rtm power.rtm flow_syn.rtm flow_dp.rtm flow_pnr.rtm flow_finish.rtm

Analyze Flows Step Flows

Task Flows
• As you run the flow, each task target will create logs, reports, and design data.
• The output data from each task will be stored underneath the step directory
that the task belongs to. For example, data generated by tasks that belong to
flow_syn.rtm will be stored under the “syn” directory

95
Step Directory Structure

• As shown previously, each task target has a

<<step_name>/ source and a destination. When the flow is
step_name>/
invoked, these source and destination
directories will be created in the step directory
and used to store data.
tmp
tmp work/
work/ logs/
logs/ rpts/
rpts/ • Data movement from task to task is based
upon the source and destination.
• The source and destination directories
beneath work/, logs/, and rpts/ can have any
task01/
task01/ task01/
task01/ task01/
task01/ name
• There is no formalized structure beneath the
task02/
task02/ task02/
task02/ task02/
task02/ source and destination directories.
– They are simply containers for related design
task03/
task03/ task03/
task03/ task03/
task03/ information.
• Task scripts are always ran from the tmp
directory
– Source and destination paths are “inferred”
from location in which tasks are ran

96
Step Example
• Simple SYN step example
• Assuming the existence of a
syn/
syn/
GTECH database, a first pass
synthesis task could specify:
– SEV_SRC=elab
tmp
tmp work/
work/ logs/
logs/ rpts/
rpts/ – SEV_DST=task1
• A second pass, incremental
synthesis task could specify:
– SEV_SRC=task1
elab/
elab/ elab/
elab/ elab/
elab/
syn.tcl
syn.tcl – SEV_DST=task2
task1/
task1/ task1/
task1/ task1/
task1/
• A STA task could specify
syn_inc.tcl
syn_inc.tcl – SEV_SRC=task2
task2/
task2/ task2/
task2/ task2/
task2/ – SEV_DST=task2

sta.tcl
sta.tcl

97
Setup & Promote

• All step flows

syn/
syn/ (SYN,DP,PNR,FINISH) begin with a
setup task and end with a promote
task.
• Setup Tasks:
tmp
tmp work/
work/ logs/
logs/ rpts/
rpts/ – SEV_DST == “inputs”
– Read a list of files and directories,
and copy these to SEV_DST
“setup” inputs/ inputs/ – The files and directories are
inputs/ inputs/
task generally from a hdl directory (inside
or outside of Lynx) or from the
elab/ elab/ elab/ work/outputs/ directory of other steps
elab/ elab/ elab/
• Promote Tasks:
syn/ syn/ syn/ – SEV_DST == “outputs”
syn/ syn/ syn/
– Read a list of files and directories
and copy these to SEV_DST
syn_inc/
syn_inc/ syn_inc/
syn_inc/ syn_inc/
syn_inc/ – The files and directories are from
“promote” any of the task work directories of
task the current step
outputs/
outputs/ outputs/
outputs/

98
Running Block and Task Flows from the
Command Line
• So far, we have shown you how to execute flows from within the Runtime
Manager
• It is also possible to run block and task flows from the unix command line
with rtm_make.
• To run a block flow, do the following
Unix> cd <flow_install_dir>/user/<username>/my_workarea
Unix> cd blocks/des_hard_macro
Unix> rtm_make –f block_flow.make

• To run a task flow, you must cd to the tmp directory corresponding to the
step that you are running.
• For example, to run the promote target in the syn flow (flow_syn.make) for
des_hard_macro, you would do the following
Unix> cd <flow_install_dir>/user/<username>/my_workarea/blocks/des_hard_macro
Unix> cd syn/tmp
Unix> rtm_make –f ../../scripts_block/syn/flow_syn.make promote

99
 Lynx Des_chip Sample Design
des_chip

• Des_hard_macro dft_support
u_dft_support
PLL
des_chip_core
u_des_chip_core
is part of a larger
hierarchical Lynx des_ctl
u_des_ctl
design called added during DFT step

des_chip des_hard_macro
u_des_hard_macro_1
– Full RTL is TAP

provided des_hard_macro
u_des_hard_macro_2 BSRs
– Complete flow io
and scripts are u_io des_soft_macro_a
u_des_soft_macro_a
provided to build
des_chip with the des_soft_macro_b
u_des_soft_macro_b
FRS-created
TSMC65LP des_soft_macro_c
u_des_soft_macro_c
techlib

10
0
Design Hierarchy & Block Directories
• Lynx block directories are organized in a “flat” structure regardless of the design
hierarchy.
– At a minimum, the blocks/ directory is organized in terms of physical hierarchy.
Additional block directories can be created to support pre-floorplanning
partitioning. For example, separate block directories to support bottom-up
synthesis.
– In the des_chip design we have 5 partitions:
• 4 physical partitions: des_chip, des_hard_macro, des_soft_macro_a, and
des_soft_macro_b.
• 1 logical partition: des_soft_macro_c

<work_area>
<work_area>

blocks/
blocks/

des_chip/
des_chip/ des_hard_macro/
des_hard_macro/ des_soft_macro_a/
des_soft_macro_a/ des_soft_macro_b/
des_soft_macro_b/ des_soft_macro_c/
des_soft_macro_c/

10
1
Hierarchical Block Flow Example –
des_chip block_flow.rtm
• A hierarchical block
flow contains …
– Block targets. E.g.
syn.analyze target
for des_chip
– Sub-block targets.
E.g. invoke block
flow
(block_flow.rtm) for
des_soft_macro_a
and run
syn.analyze target

10
2
Building des_chip

• After building
des_hard_macro,
you are ready to
build des_chip
– When des_chip is
built, it will call block
flow makefiles for
des_soft_macro_a,
des_soft_macro_b,
and
des_soft_macro_c

10
3
LAB 2

• See lab manual

10
4
Agenda
Unit
Topic Lab

1 Lynx Introduction

2 Getting Started with Lynx

3 Technology Library Data

4 Running The Flow

5 Adding New Designs

6 Documentation and Help

10
5
Adding a New Lynx Design

• Create a block
directory
• Configure block.tcl
• Add your design
data
– Constraints
– Scan Configuration
– Floorplan data

10
6
 Lynx Sample Designs
• As mentioned previously, Lynx comes with several
designs: a block called des_hard_macro and a
hierarchical chip call des_chip.
• Lynx also comes with a UPF (unified power format for low
power, IEEE-1801) design called des_hard_macro_upf
• Lynx also provides the complete flow that can be used to
build each design with the TSMC65LP library

<work_area>
<work_area>

blocks/
blocks/

des_chip/
des_chip/ des_hard_macro/
des_hard_macro/ des_soft_macro_a/
des_soft_macro_a/ des_soft_macro_b/
des_soft_macro_b/ des_soft_macro_c/
des_soft_macro_c/ des_hard_macro_upf/
des_hard_macro_upf/

10
7
 Creating a New Block Directory (1/3)

• To create a new Lynx block directory, you

should consider the sample design blocks
to be templates.
<work_area>
<work_area>

blocks/
blocks/

des_chip/
des_chip/ des_hard_macro/
des_hard_macro/ des_soft_macro_a/
des_soft_macro_a/ des_soft_macro_b/
des_soft_macro_b/ des_soft_macro_c/
des_soft_macro_c/ des_hard_macro_upf/
des_hard_macro_upf/

Top-level Hard Logic Macro UPF design

Hierarchical Macro (bottom-up compile)
Design Soft
Macro
10
8
Creating a New Block Directory (2/3)

• A copy of the block scripts for the sample

designs are kept in scripts_global/templates
– Scripts_global/templates/hard (des_hard_macro)
– Scripts_global/templates/soft_a (des_soft_macro_a)
– Scripts_global/templates/soft_b (des_soft_macro_b)
– Scripts_global/templates/top (des_chip)
– Scripts_global/templates/upf (des_hard_macro_upf)

10
9
Creating a New Block Directory (3/3)
• Within the Runtime
Manager, select File->
Create Block
• In the pop-up window,
enter the name of the
new design and simply
pick the “template” that
most closely matches the
design you are adding
• For most designs, hard
(des_hard_macro) will
probably be the best
template.
• Another option in the
Create Block pop-up
window is to use an
existing block as the
template.

110
SVAR Configuration and Lynx Tool
Wrapper
• All tasks that are in run withing the Lynx Flow make use of
the Lynx tool wrapper
• The tool wrapper ensures that all tasks begin with a
common setup be using a set of Lynx configuration
variables called SVARs
• There are 2 Lynx files where all SVARs are defined
– common.tcl: One for the whole project. Default values for all
SVARs are defined here.
– block.tcl: One for each block. Sourced after common.tcl, so it can
over-ride values set in common.tcl
## Lynx
Lynx Tool
Tool Wrapper
Wrapper Script
Script scripts_global/conf/tool_wrapper.tcl
scripts_global/conf/tool_wrapper.tcl
Accessible
source
source common.tcl
common.tcl
source
source common_setup.tcl
common_setup.tcl Via GUI
source
source block.tcl
block.tcl Variable Tabs
source
source block_setup.tcl
block_setup.tcl

source
source $SEV_SCRIPT
$SEV_SCRIPT ###
### the
the task
task script
script is
is sourced
sourced after
after setup
setup files
files

111
Resetting Block.tcl
• When using a Lynx
template to create a
new block directory, A
good practice you may
want to consider is to
reset the contents of
the block.tcl file after
creating your block
directory.
• This will reset block.tcl
so that no common.tcl
SVAR settings are
being over-ridden.
• To reset block.tcl,
Variables-> Reset
SVAR Files. Select the
check-box next to the
block whose block.tcl
file you want to reset
and click OK.

112
Configuring block.tcl for your New
Design
• After creating a directory for your new block, the
next thing you should do is configure block.tcl.
• You will usually only need to modify a handful of
SVAR(config,*) variables in block.tcl.
• In the following slides we will show some of the
most common block.tcl settings you may need
to change. It is possible that your design may
require additional modifications to block.tcl

113
Block Navigator

• You can edit

block.tcl by using
the “Block
Navigator”
window in the
Runtime
Manager
• To bring up the
Block Navigator
window, double-
click on the block
name.

114
block.tcl Scope Indicator (1/2)

• Since block.tcl allows

you to over-ride
variable settings that
were made in
common.tcl, it
contains a scope
indicator to visually
indicate which
variables you have
over-ridden
– Blue – common.tcl
value is being over-
ridden with a different
value in block.tcl
– Green – common.tcl
value is NOT being
over-ridden in
block.tcl

115
block.tcl Scope Indicator (2/2)

• Click on the
scope
indicator to be
able to view
settings for
this variable
defined in
common.tcl
as well as in
the block.tcl
file for other
blocks

116
Library Setup

• Make sure
the Target
Library
and Link
Library
lists are
set
correctly
for your
design.

117
Integration Info

• If your design is a
chip, make sure to
check the box next to
“Is Chip?”
• Only fill out the other
variables , such as
hard macro list, if
your design is
hierarchical in nature
– Separately compile
sub-blocks
– Physically hierarchical
with soft macros being
generated during
design planning

118
Synthesis

• Check all of
the settings
in the
Synthesis
panel to see
if they are
appropriate
for your
design
– DFT settings

119
Building Your Design
• When you created your
block directory, you copied
a template for one of the
sample design blocks.
• This template will contain
files that refer to the
template design. Some of
these files will need to be
modified to contain data for
your design.
• The best way to see which
files you will need to modify
is to run the flow and see
which tasks fail. Even if a
flow passes all automated
checks, the customer is
ultimately responsible to
verify the flow contains all
required implementation
and verification steps and
settings for ensuring a
design meets sign-off
requirements

12
0
Pass/Fail Files
• All tasks generate a
logfile
• Upon task
completion, the
logfile is parsed and
either a .pass or .fail
file is generated.
• You can view
pass/fail files,
logfiles, reports, and
design databases
from within the
Execution Manager

12
1
Task Failures
• When putting a new design into
Lynx, some tasks will fail.
• There are three primary causes for
task failures in Lynx
– SNPS_ERROR – these are Lynx-
specific errors that are produced by
checks that are built into the Lynx flow
– Unexpected tool errors – tool-specific
error messages
– Expected messages not appearing in
the logfile
• E.g. Formality “Verification SUCCEEDED”
message
• START_TIME and STOP_TIME
messages
• When a task failure occurs, your
goal is to find out why it occurred.
• You should start by examing the
.fail file. The reason the .fail file
was generated will appear at the
top.

12
2
Adding Your Design Data into Lynx

• The following data is needed for any design you want to

build
– RTL
– Constraints
– Scan Information (if scan is inserted)
– Floorplan Data
• As you try to run through the flow for a new design, you
will get task failures if you have not told Lynx where to get
your design data
• The following slides will discuss the most common places
in the Lynx flow where your design data is needed.

12
3
Adding RTL for Your Design

• For the SYN step, you must tell

Lynx where to find your RTL
• The setup task copies your RTL
into
blocks/<design_name>/syn/work/
inputs
– RTL is listed in a manifest file
– Default manifest filename is setup.f
– Edit setup.f to include pointers to
your RTL by clicking in the edit icon
Each of the steps (SYN / DP / PNR /
FINISH) begin with a “setup” and
end with a “promote” task.
Example shown here is “setup” task
in SYN step.

12
4
Manifest File
• The manifest file is a TCL file which contains calls to sproc_manifest. Each
call to sproc_manifest will result in a file being either copied to or linked to
the syn/work/inputs directory.
sproc_manifest $SEV(workarea_dir)/sample_designs/des_chip/des.vh TYPE=NONE
sproc_manifest $SEV(workarea_dir)/sample_designs/des_chip/des_hard_macro.v
sproc_manifest $SEV(workarea_dir)/sample_designs/des_chip/des_hard_macro_bypass.v
sproc_manifest $SEV(workarea_dir)/sample_designs/des_chip/des_hard_macro_core.v TYPE=RTL_SVLOG
sproc_manifest $SEV(workarea_dir)/sample_designs/des_chip/convert_8_64.v
sproc_manifest $SEV(workarea_dir)/sample_designs/des_chip/convert_64_8.v
sproc_manifest $SEV(workarea_dir)/sample_designs/des_chip/des_encrypt_mixed.v
sproc_manifest $SEV(workarea_dir)/sample_designs/des_chip/des_decrypt_mixed.v
sproc_manifest $SEV(workarea_dir)/sample_designs/des_chip/des_functions.vh TYPE=NONE

Example shown here is manifest

• sproc_manifest can accept several arguments. file in SYN step!
sproc_manifest Manifest file for DP/PNR step
<file>
[COPY= | COPY=<new_file> | LINK= | LINK=<new_file>]
will be shown in detail flow
[TYPE=<type>] [LIB=<libname>] training.

• Possible values for TYPE are RTL_VLOG (default), RTL_SVLOG,

RTL_VHDL, NETLIST_VLOG, NETLIST_VHDL, DB, DDC, NONE
• For RTL_VHDL, user can optionally defined LIB=<libname>, so that the
analyze files will be in the library <libname>.

12
5
 Manifest Examples
• Copy des.vh to
syn/work/inputs. TYPE=NONE
indicates to Lynx that this file
should not be read in directly
into DC. It will appear in the
sproc_manifest $SEV(workarea_dir)/sample_designs/des_chip/des.vh TYPE=NONE search_path so it will be
sproc_manifest $SEV(workarea_dir)/sample_designs/des_chip/des_hard_macro.v included indirectly by any
sproc_manifest $SEV(workarea_dir)/sample_designs/des_chip/des_hard_macro_bypass.v
`include statements in the RTL
sproc_manifest $SEV(workarea_dir)/sample_designs/des_chip/des_hard_macro_core.v TYPE=RTL_SVLOG
sproc_manifest $SEV(workarea_dir)/sample_designs/des_chip/convert_8_64.v • Copy des_hard_macro.v to
sproc_manifest $SEV(workarea_dir)/sample_designs/des_chip/convert_64_8.v syn/work/inputs. Since no type
sproc_manifest $SEV(workarea_dir)/sample_designs/des_chip/des_encrypt_mixed.v
sproc_manifest $SEV(workarea_dir)/sample_designs/des_chip/des_decrypt_mixed.v is explicitly declared,
sproc_manifest $SEV(workarea_dir)/sample_designs/des_chip/des_functions.vh TYPE=NONE TYPE=RTL_VLOG is assumed
and the file will be read into DC
as a verilog RTL file
• Copy des_hard_macro_core.v
to syn/work/inputs and read
Example shown here is manifest
into DC as a system verilog file
file in SYN step! since TYPE=RTL_SVLOG
Manifest file for DP/PNR step
will be shown in detail flow
training.

12
6
Adding Constraints for Your Design

• The dc_compile task in

the SYN step reads in
the timing constraints
for your design.
• The default timing
constraint file is
constraints_design.tcl
• Edit this file to include
your timing constraints
by clicking on the edit
icon OR set
TEV_CONSTRAINT_FI
LE to point to a
different constraint file

12
7
Clock Gating Information

• The dc_compile task

in the SYN step
reads in clock gating
information for your
design.
• The default file for
clock gating
information is pre-
compile.tcl
• Edit this file to
include your clock
gating information by
clicking the edit icon

12
8
 Scan Configuration
• The dc_dft task in the
SYN step reads in
scan configuration
information before
inserting scan.
• The default file for
scan configuration
information is
scan_configuration.tcl
• Edit this file to include
your scan configuration
information by clicking
on the edit icon

12
9
 Design Planning Information
• Design Planning is
part of the flow that
requires the most
data from the user.
• You will have to
modify multiple files
to integrate your
design planning
information into Lynx
• Please refer to the
Lynx DP step
documentation for
more details

13
0
Lynx Task Debugging

• When debugging task failures, there are

several tools that the Runtime Manager
provides to make this process as easy as
possible

13
1
Running Tasks Interactively with the
Runtime Manager
• Right-click on a task in the
Execution Manage and select
“Run Task”.
• A pop-up window will allow
you to choose from several
options
– GUI: run tool in GUI mode
– FORCE PASS: always create a
passfile to allow flow to continue
running even if the task fails
– DONT RUN: Start tool, but do
not run the script. This allows
you to run the script
interactively line-by-line
– DONT EXIT: Start tool and run
the script, but do not exit.
– TRACE: Run tracelog for the
task to generate a trace file.
• Click OK to start the task

13
2
Running Tasks Interactively on the
Unix Command Line with rtm_make
• Lynx implements several arguments which can be used to control the way
task scripts are ran
– All Lynx rtm_make variables are prefixed with SEV_
• Values can be assigned on the command line or by setting an environment
variable.
– On the command line variables should always appear after the name of any
target that is specified
– Multiple options are separated by white space
rtm_make –f ../../scripts_block/syn/flow_syn.make 020_dc_compile ARG1=value1 ARG2=value2

• Variables set in the environment are persistent – they will apply to all Lynx
tasks until they are unset
– setenv ARG1 value1
• There is no way to error check for correct spelling of arguments
– If the expected behavior does not occur check the spelling of the arguments

13
3
Lynx rtm_make Options

• Refer to Lynx Reference Guide for more

details and variables
• SEV_TEE_LOG=1 “Tee” the log file as script runs
• SEV_GUI=1 Run script in tool GUI

• SEV_DONT_EXIT=1 Run script but do not exit

• SEV_DONT_RUN=1 Start tool but do not run script
• SEV_FORCE_PASS=1 Force a pass status on a run
• SEV_DEBUG=1 Run with additional output
reporting

13
4
Running View Targets
• Use a view target when you
just want to start a tool (e.g.
ICC, DC), but do not want to
run a script.
• Right-click on a task in the
Execution Manage and
select “View Design Data”.
• A pop-up window will allow
you to choose from several
options
– GUI: run tool in GUI mode
– DONT RUN: Start tool, but do
not run the script. This allows
you to run the script
interactively line-by-line
• Click OK to start the view
target

13
5
Lab 3

• See lab manual

13
6
Agenda
Unit
Topic Lab

1 Lynx Introduction

2 Getting Started with Lynx

3 Technology Library Data

4 Running The Flow

5 Adding New Designs

6 Documentation and Help

13
7
Lynx Help

• Solvnet
• Lynx CAE team
• Detailed Training Modules

13
8
Detailed Training Modules

• Detailed Lynx training modules. Available

modules include
– Lynx Reference Guide
– Environment
– FRS (README.pdf and RELEASE_NOTES.pdf)
– SYN
– DP
– PNR
– FINISH
– UPF

13
9