lynx jump start 0.6

1

Lynx Jump StartLynx 0.6

2

AgendaTopic LabUnit

Running The Flow4

Getting Started with Lynx2

Documentation and Help6

Lynx Introduction1

Adding New Designs5

Technology Library Data3

3Synopsys Confidential

Moore’s Law Driving Product Complexity

2003 2004 2005 2006 2007 2008200

400

600

800

768

Significant Increase in Design Performance

Mean

MHz

Source: SNUG 2007, 2008

Average Gate Count at 8.5M

Average chip = 11 Clock Domains

30+ IP Blockson an SoC

Implementation ofLow Power is #1

Challenge

4

Challenges @ 65nm & Below

Need Advanced Design

Techniques

• Low Power, SI, DFM, DFY, MM, MC

Limited Project Visibility

• Project progress• Informed decisions

Complicated Library &

Foundry Setup

• Validated foundry data• Sign-off checks

Validated Design Inputs

• Implement clean IP• IP compatibility

350 250 180 150 130 90

100

200

300

400

500

600

700

Number of Design Rules By Process Node

(nm)

65 45

65nM - 1000 Rules!

65


Introducing Lynx: Delivering Higher Productivity and Predictability

Production Flow

Runtime Manager

Foundry-Ready System

Management Cockpit

LynxFoundry Tape-In

Checklist

STA guidelines(OCV, extr. corners)

DFM/DFY(fill, vias, diodes)

DRC/LVS rqmts

Post-GDS checks(added to Lynx)

Other checks

EM rqmts

Libs

Tech Files

Tech Lib Prep

12.7 x 12.512.0 x 12.0

Area

ActualTarget

326 MHz325 MHz

Performance

3.0 W3.0 W

Power

97.2%98.5%

ATPG

75

ECOs

100%100%

DRC

Timing/SIClosure

Hierarch Design

Low Power

DFT DFMIP-

Specific

GDSII RTL

6

Building On Proven Success

• 7+ years of flow deployment experience

• Close collaboration with IG– Synchronized w/ tool releases– Based on tool RM’s– Support for latest technologies

Production Flow

Runtime Manager


Management Cockpit

Lynx

2009 –

2006-2008

2002-2006

Pilot

“TIGER”

Lynx

Ove

r 10

0 ta

peou

ts! “Methodologies associated with designing

advanced chips that take years to learn and understand were incorporated into Pilot.”

VP of EngineeringTundra Semiconductor

7

SYN & DFT DP PNR FINISH

Global Analysis Tasks Flow

Steps

Modular Flow Step Architecture

DCTICC

ICCICC

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

PT FormalityPT/SI STAR Herc

MCMM

QOR

RM-ModeDP RMDCT RM

DCT RM DP RM ICC RM

Silicon-Proven Flow

Runtime Automation


Management Reports

Lynx

8

Foundry-Ready System (FRS) Manufacturing-Ready Designs

Accelerate Project Start

First Time Right Technology Data

Update

Utilities

Pre-Valida

ted Tech Files

Pre-Valida

ted Librari

es

Accelerate Tape In

First Time Right GDSII Finishing

Essential

reports

(PTSI…)

Rep settin

gs (OCV

…)

Process-

specific

methods

Production Flow

Runtime Manager


Management Cockpit

Lynx


Technology Prep System

• Library and technology files pre-validated with the flow– Automatically configures data for

the Lynx flow

• Eases foundry technology data acquisition – Continuously synchronized to the

latest foundry updates– Scripted system for downloading

foundry data updates

• Accelerates project start and execution

Pre-test

Deploy complete set in Lynx flow

Update & Sync with Foundry

Foundry libs, tech files

Production Flow

Runtime Manager


Management Cockpit

Lynx

10

• Foundry-endorsed, process-specific checks

• Improves “tape-in” quality with embedded foundry criteria– Proven methodologies (e.g., metal

fill)

– Representative settings (e.g., OCV)

– Essential reports (e.g., STA w/ SI)

• First-time-right, manufacturing-ready design submissions

Foundry Tape-In Checks

Synopsys Confidential

Foundry Tape-In Checklist

STA guidelines(OCV, extr. corners)

DFM/DFY(fill, vias, diodes)

DRC/LVS rqmts

Post-GDS checks(added to Lynx)

Other checks

EM rqmts

Automated In Lynx

Partial AutomationUser Completes

User Checks

Production Flow

Runtime Manager


Management Cockpit

Lynx

11

Runtime GUI Improves Designer Productivity

Synopsys Confidential

Drag-& DropFlow

Configuration

Block-Level Execution & Monitoring

Color –Coded for Easy Error Identification

Guided Variable Setup

Production Flow

Runtime Manager


Management Cockpit

Lynx


On-Demand Management Reports

• Visibility to key chip metrics– User-configurable reports from

design data captured at run time– Real-time query means data is

accurate and timely

• Easy access through web browser

• Provides important project info for management decisions

Lynx dB(SQL)

LynxFlow

Query

Block Area

Total Area

ATPG Coverage

TNS Report…..

Production Flow

Runtime Manager


Management Cockpit

Lynx

13

Tool Methodologies• Individual tool deployment• Recommended starting point

Block-Level Sub-Flows• Optimized hard & soft core sub-

flows• Full flow analysis for timing,

power, area

ARM Reference Methodologies• Core-specific flows optimized for

power, performance, area • Endorsed by ARM

Full-Chip R2G Flow• Advanced technologies (UPF,

(hierarchical, MCMM, etc.)• Hard IP validation

Technology Node Optimization

• Validated libraries• Validated tech files• Tapeout checklists w/

foundry-specific tape-in criteria

Automation & Utilities• Technology configuration• Flow execution, monitoring• Metrics reporting

Design Environment• Job distribution• Data management• File & tool version control• Multi-user support

Lynx Design System• Based on proven

flows & technology• Fully integrated• Tested• Updated• Supported

Anatomy Of A Complete SolutionWhat’s In Lynx?

DCT RM DP RM ICC RM

Block Level Sub-Flows

ARM iRMs

Full-Chip, Hierarchical R2G Flow

Technology Node Optimization

Automation & Utilities

Design Environment


• Proven, low-risk path to

65nm and below

• Enhanced designer

productivity

• First-time-right,

manufacturing-ready

designs

• Improved project visibility

and predictability

Lynx Benefits: “EDA In A Box”

Production Flow

Runtime Manager


Management Cockpit

Lynx

Lynx Design System

Up and running in a week!

15

AgendaTopic LabUnit

Running The Flow4



Lynx Introduction1

Adding New Designs5


16

• 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/defa

ult.aspx

Lynx 0.6 Tools and Utilities forFlow, Runtime Manager, and FRS

• Tools for Lynx Flow• Leda 2008.06• MV Tools 2008.12• DC 2008.09-SP2• PT 2008.12• Formality 2008.09-SP2• Tetramax 2008.09-SP2• ICC 2008.09-SP2• Milkyway 2008.09 –SP2• StarRCXT 2008.12• Hercules 2008.09-1• PrimeRail 2008.12• Hspice 2008.09-SP1• VCS MX 2008.12• ICWB 2008.12

• Unix Utilities for Lynx Flow• Activetcl 8.4.13• Gmake 3.80

• Tools & Utilities for Lynx FRS• Activetcl 8.4.13• Gtar 1.14• Gmake 3.80• Perl 5.8.5• Patch 2.5.4• DC 2007.12• Milkyway 2008.09• StarRCXT 2008.06-SP2

http://www.synopsys.com/Support/Licensing/SupportPlatform/ReleaseSupport/Pages/default.aspx

http://www.synopsys.com/Support/Licensing/SupportPlatform/ReleaseSupport/Pages/default.aspx

17

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

http://java.sun.com/javase/downloads/index.jsp

18

Management Cockpit 3rd-party Libraries

Name Version License Link Download

ZK (JFreeChart included)

3.5.2 Commercial (JFreeChart LGPL )

https://sourceforge.net/project/downloading.php?groupname=zk1&filename=zk-bin-prof-3.5.2.zip

Link (tar.gz)Link (zip)

Apache Tomcat

5.5.27 Apache License V2.0 http://apache.mirror.facebook.com/tomcat/tomcat-5/v5.5.27/bin/apache-tomcat-5.5.27.zip

Link(tar.gz)Link(zip)

Apache Derby

10.4.2 Apache License V2.0 http://www.hightechimpact.com/Apache/db/derby/db-derby-10.4.2.0/db-derby-10.4.2.0-lib.zip

Link(tar.gz)Link(zip)

19

• 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

Loading the Runtime Manager (Internal only)

Unix> module use /global/cust_apps_sgps001/pilot/admin/modulefilesUnix> module load lrtm

20

• 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.

Installing the Runtime Manager - External (1/2)

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

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

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.gzUnix> tar xvf version_X.X.X.tar

<rtm_install_dir>/<rtm_install_dir>/

21

• 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

Installing the Runtime Manager - External (2/2)

Unix> setenv LM_LICENSE_FILE <license_server> ## must contain LYNX featuresUnix> setenv PATH <rtm_install_dir>/version_X.X.X/bin:$PATH

22

• 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.

Installing the Lynx Flow

<flow_install_dir>/<flow_install_dir>/

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

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.gzUnix> tar xvf lynx_version_X_X.tarUnix> ./lynx_version_X_X/bin/install.tcl –style project –tech TSMC65LP.TSMC.A

23

• Lynx flow contains a utilities to use to verify that you have the correct unix utlities installed

• Invoke this utility after installation

Verifying Unix Utilities

Unix> ./lynx_version_X_X/bin/check_apps.tcl

24

• 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

Environment Settings for Lynx Flow

Unix> setenv SEV_PROJECT_ROOT <flow_install_dir>Unix> setenv PATH $SEV_PROJECT_ROOT/bin:$PATHUnix> setenv SEV_TECHLIB_ROOT /global/cust_apps_sgps001/pilot/techlib/tsmc65lp.tsmc.a.2009_01_07Unix> setenv SEV_TECHLIB TSMC65LP.TSMC.A

25

• 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/example_user/example_workarea/scripts_global/conf/tool_launch_part2.make

Configuring Job Distribution (1/2)

26

• 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”.

Configuring Job Distribution (2/2)

27

• 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_user/example_workarea/scripts_global/conf/tool_launch_part1.make

Configuring Tool Loading

28

• 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

Lynx Work Area

<flow_install_dir>/<flow_install_dir>/

user/user/doc/doc/cache/cache/ metrics/metrics/

example_user/example_user/

example_workarea/example_workarea/

release/release/bin/bin/

29

• 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

Workarea Directory Structure

<workarea>/<workarea>/

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

<$SEV_TECHLIB>/<$SEV_TECHLIB>/<block>/<block>/

Location for sample designsource HDL

<username>/<username>/

“technology”scripts

“global”scripts

“block”scripts

<block>/<block>/

“block”scripts

…

conf/conf/

common.tclcommon.tcl

scripts_block/scripts_block/ scripts_block/scripts_block/

30

• 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

Creating a Work Area

Unix> cd <flow_install_dir>/userUnix> mkdir <username>Unix> cd <username>Unix> cp –r ../example_user/example_workarea my_workareaUnix> cd my_workarea

31

Lynx Runtime Manager

• The Lynx RunTime Manager is the user interface into the Design System.– Library data

configuration– Design Flow

configuration– Running the flow

32

Starting the Runtime Manager

Unix> cd <flow_install_dir>/user/<username>/my_workareaUnix> setenv SEV_EDITOR neditUnix> rtm_shell &

• 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

33

• See lab manual

LAB 1

34

AgendaTopic LabUnit

Running The Flow4



Lynx Introduction1

Adding New Designs5


35

• 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 technology-specific scripts and library data.

Lynx Built-In Library Support

Unix> setenv SEV_PROJECT_ROOT <flow_install_dir>Unix> setenv PATH $SEV_PROJECT_ROOT/bin:$PATHUnix> setenv SEV_TECHLIB_ROOT <lynx_techlib_location>Unix> setenv SEV_TECHLIB TSMC65LP.TSMC.A

36

• The Lynx Runtime Manager contains a window called Common Navigator.

• To open this window, select Window-> Common Navigator

Library Data in Lynx

37

• 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

Common Navigator == common.tcl







“global”scripts

“local”scripts

<block>/<block>/

“local”scripts

…

Multiple Block Support

conf/conf/


38

• 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

Common Navigator Details

39

common.tcl Details

• common.tcl• Located under

Lynx directory scripts_techlib/$SEV_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

40

• SEV_TECHLIB_ROOT is a pointer to the root directory that contains your library data

• For TSMC65LP, the contents of SEV_TECHLIB_ROOT are created with Lynx FRS (Foundry Ready System)– FRS is a separate

component of Lynx– FRS is currently available

only for TSMC65LP

SEV_TECHLIB_ROOT Details<$SEV_TECHLIB_ROOT><$SEV_TECHLIB_ROOT>

hspice/hspice/

lib/lib/

hercules_drc/hercules_drc/

doc/doc/

tech/tech/

hercules_lvs/hercules_lvs/

milkyway/milkyway/

<lib 1>/<lib 1>/

doc/doc/

db/db/

gds/gds/

lef/lef/

milkyway/milkyway/

verilog/verilog/

vhdl/vhdl/

<lib N>/<lib N>/

doc/doc/

db/db/

gds/gds/

lef/lef/

milkyway/milkyway/

verilog/verilog/

vhdl/vhdl/

starrc_xt/starrc_xt/

hspice/hspice/ hspice/hspice/

lvs/lvs/ lvs/lvs/

41

FRS Creates SEV_TECHLIB_ROOT

Foundry-Ready

System

DW_TSMC_tcbn65lpcg_front_140a.tar.gz DW_TSMC_tcbn65lpcg_back_140a.tar.gzDW_TSMC_tcbn65lp_front_140b.tar.gzDW_TSMC_tcbn65lp_back_140b.tar.gzDW_TSMC_tcbn65lp_ccs_140b.tar.gzDW_TSMC_tcbn65lpcg_ccs_140a.tar.gz

DW_TSMC_tcbn65lpcglvt_front_140a.tar.gzDW_TSMC_tcbn65lpcglvt_back_140a.tar.gzDW_TSMC_tcbn65lplvt_front_140b.tar.gzDW_TSMC_tcbn65lplvt_back_140b.tar.gzDW_TSMC_tcbn65lplvt_ccs_140b.tar.gzDW_TSMC_tcbn65lpcglvt_ccs_140a.tar.gz

DW_TSMC_tcbn65lpcghvt_front_140a.tar.gzDW_TSMC_tcbn65lpcghvt_back_140a.tar.gzDW_TSMC_tcbn65lphvt_front_140b.tar.gzDW_TSMC_tcbn65lphvt_back_140b.tar.gzDW_TSMC_tcbn65lphvt_ccs_140b.tar.gzDW_TSMC_tcbn65lpcghvt_ccs_140a.tar.gz

DW_TSMC_tpzn65lpgv2_front_140b.tar.gzDW_TSMC_tpzn65lpgv2_back_140b.tar.gzDW_TSMC_tpbn65gv_front_140a.tar.gzDW_TSMC_tpbn65gv_back_140a.tar.gz

tn65clls001e1_1_3b.ziptn65cldr001h3_1_4a.ziptn65cldr001h2_1_4a.zipt-n65-cl-dr-001-h1_1_4b_20080708.zipt-n65-cl-sp-009-b1_1_2a_20070119.zip

42

FRS

• 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

Silicon-Proven Flow

Runtime Automation


Management Reports

Lynx

43

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

44

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

45

FRS Directory Structure

scripts_frs/scripts_frs/

work/work/

release/release/

FRS ROOT/FRS ROOT/

tmp/tmp/

scripts_stdcell/scripts_stdcell/

scripts_tech/scripts_tech/

scripts_ram/scripts_ram/

scripts_io/scripts_io/

logs/logs/

newlib/newlib/

scripts_pll/scripts_pll/

patch/patch/

Misc PDF fileMisc PDF file

All scripts are kept in scripts* directory scripts_frs – Top level makefile, setup scripts scripts_stdcell – stdcell lib build flow scripts_tech – for star-rcxt, hercules scripts_ram – ram lib build flow scripts_io – io lib build flow scripts_pll – pll lib build flow

Contains patch for tech files

Directory where FRS is invoked

Contains BOM list

Generated lib store here

Logs for FRS run

RELEASE_NOTES / README / KNOWN_ISSUES

User need to setenv for FRS_ROOT

46

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

47

Lynx FRS: Technology Installation

TSMC65LPTechnology setup

DW_TSMC_tcbn65lplvt_front_140b.tar.gzDW_TSMC_tcbn65lplvt_back_140b.tar.gzDW_TSMC_tcbn65lplvt_ccs_140b.tar.gz

tn65clls001e1_1_3b.ziptn65cldr001h3_1_4a.ziptn65cldr001h2_1_4a.zipt-n65-cl-dr-001-h1_1_4b_20080708.zipt-n65-cl-sp-009-b1_1_2a_20070119.zip

TSMC65LP:1P8LM Technology FRS

TSMC65LPLibrary setup

TSMC65LP:tcb65_lvt Library FRS

TSMC65LPLibrary setup

TSMC65LP:tcb65_hvt Library FRS

DW_TSMC_tcbn65lphvt_front_140b.tar.gzDW_TSMC_tcbn65lphvt_back_140b.tar.gzDW_TSMC_tcbn65lphvt_ccs_140b.tar.gz

48

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/

http://www.synopsys.com/dw/tsmc.php

http://svpcafeultra.synopsys.com/

49

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

http://online.tsmc.com/online/

50

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

51

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

52


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

53


• 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

54


• 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)

55

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

56

FRS Outputs

• FRS creates a TSMC65LP library in <frs_install>/TSMC65/work/ that can be used to build the des_chip sample design

• Set SEV_TECHLIB_ROOT to point to the library created by FRS

• The technology-specific scripts directory scripts_techlib/TSMC65LP.TSMC.A will work with the FRS-generated techlib

<$SEV_TECHLIB_ROOT><$SEV_TECHLIB_ROOT>

hspice/hspice/

lib/lib/

hercules_drc/hercules_drc/

doc/doc/

tech/tech/

hercules_lvs/hercules_lvs/

milkyway/milkyway/

<lib 1>/<lib 1>/

doc/doc/

db/db/

gds/gds/

lef/lef/

milkyway/milkyway/

verilog/verilog/

vhdl/vhdl/

<lib N>/<lib N>/

doc/doc/

db/db/

gds/gds/

lef/lef/

milkyway/milkyway/

verilog/verilog/

vhdl/vhdl/

starrc_xt/starrc_xt/

hspice/hspice/ hspice/hspice/

lvs/lvs/ lvs/lvs/

The end-result is a Lynx-ready library !

57

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_techlibUnix> cp –r TSMC65LP.TSMC.A NEW_LIBUnix> setenv SEV_TECHLIB NEW_LIBUnix> setenv SEV_TECHLIB_ROOT <root directory for your library>Unix> rtm_shell &

58

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

59

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_li

st)

60

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

61

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

62

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

63

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

64

AgendaTopic LabUnit

Running The Flow4



Lynx Introduction1

Adding New Designs5


65

• 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”

Blocks Directory







“global”scripts

“local”scripts

<block>/<block>/

“local”scripts

…

Multiple Block Support

conf/conf/


66

• 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

Des_hard_macro

67

• 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

Lynx Flow Architecture

SYN DP PNR FINISH

Global Analysis Tasks

FlowSteps

DCT ICCICC ICC

PT FormalityPT/SI STAR Herc

68

Task Flows

Lynx Flows Example

• 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

des_hard_macro

syn dp pnr finishscripts_block

syn dp pnr finish

flow_syn.rtm flow_dp.rtm flow_pnr.rtm flow_finish.rtm

Block Flow – block_flow.rtm/block_flow.make

Step Flows

sta power

sta.rtm power.rtm

formal

formal.rtm

Analysis Flows

blocks

69

• 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

Lynx Flow Terminology

70

• 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.

Opening Block/Task Flows

71

• 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.

.rtm Files

72

• 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.

Building des_hard_macro

73

• 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.

Des_hard_macro Block Flow: block_flow.rtm

74

• 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

Flat Block Flow Structure

75

• Right-click on the “all” target and select “Execute”

• This will Bring up the Execution Manager

Building des_hard_macro with the Runtime Manager (1/2)

76

• 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

Building des_hard_macro with the Runtime Manager (2/2)

77

• 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

Executing the Flow (1/3)

78

• 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


79

• Once the flow has started to run, you can stop execution of the flow at any point by click the “Stop” button


80

• Here is a more detailed look at what happens when you run the block flow for des_hard_macro as indicated previously

Running the block flow for des_hard_macro (1/3)

• 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

81

• 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


82


• 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>

83

Lynx Task Flows

SYN – flow_syn.rtm FINISH – flow_finish.rtmPNR – flow_pnr.rtmDP – flow_dp.rtm

• 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

84

• 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

Lynx Task Flow Example: flow_syn.rtm

85

• Edit properties for existing task targets– Automation– Script

• Add/remove task targets• Change/add task connections• Save a Flow

Most Common Types of Flow Configuration

86

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

Task Properties

87

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)

88

• 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.

Automation Settings

89

• 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

Saving a Flow

90

• 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

Monitoring the Flow (1/3)

91

• 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


92

• As you run the flow, the Runtime Manager will print out a banner which gives you details about the current task that is running


93

• 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.

Re-starting the Flow From an Earlier Point

94

• You can view log files, pass/fail files, and report files from within the Execution Manager

Viewing Flow Results with Runtime Manager

95

Task Flows

Viewing Flow Results Manually

• 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

des_hard_macro

syn dp pnr finishscripts_block

syn dp pnr finish

flow_syn.rtm flow_dp.rtm flow_pnr.rtm flow_finish.rtm

Block Flow – block_flow.rtm/block_flow.make

Step Flows

sta power

sta.rtm power.rtm

formal

formal.rtm

Analyze Flows

blocks

96

Step Directory Structure

• As shown previously, each task target has a source and a destination. When the flow is invoked, these source and destination directories will be created in the step directory and used to store data.

• 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 name

• There is no formalized structure beneath the source and destination directories.

– They are simply containers for related design information.

• Task scripts are always ran from the tmp directory

– Source and destination paths are “inferred” from location in which tasks are ran

logs/logs/ rpts/rpts/work/work/

task01/task01/

task02/task02/

task03/task03/

task01/task01/

task02/task02/

task03/task03/

task01/task01/

task02/task02/

task03/task03/

tmptmp

< step_name>/< step_name>/

97

Step Example

• Simple SYN step example• Assuming the existence of a

GTECH database, a first pass synthesis task could specify:– SEV_SRC=elab– SEV_DST=task1

• A second pass, incremental synthesis task could specify:– SEV_SRC=task1– SEV_DST=task2

• A STA task could specify– SEV_SRC=task2– SEV_DST=task2

syn/syn/


elab/elab/

task1/task1/

task2/task2/

elab/elab/

task1/task1/

task2/task2/

elab/elab/

task1/task1/

task2/task2/

tmptmp

syn.tclsyn.tcl

syn_inc.tclsyn_inc.tcl

sta.tclsta.tcl

98

Setup & Promote

• All step flows (SYN,DP,PNR,FINISH) begin with a setup task and end with a promote task.

• Setup Tasks:– SEV_DST == “inputs”– Read a list of files and directories,

and copy these to SEV_DST– The files and directories are

generally from a hdl directory (inside or outside of Lynx) or from the work/outputs/ directory of other steps

• Promote Tasks:– SEV_DST == “outputs”– Read a list of files and directories

and copy these to SEV_DST– The files and directories are from

any of the task work directories of the current step

syn/syn/

“setup”task

“promote” task


elab/elab/

syn/syn/

syn_inc/syn_inc/

elab/elab/

syn/syn/

syn_inc/syn_inc/

elab/elab/

syn/syn/

syn_inc/syn_inc/

tmptmp

inputs/inputs/inputs/inputs/

outputs/outputs/ outputs/outputs/

99

• 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

• 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

Running Block and Task Flows from the Command Line

Unix> cd <flow_install_dir>/user/<username>/my_workarea/blocks/des_hard_macroUnix> cd syn/tmpUnix> rtm_make –f ../../scripts_block/syn/flow_syn.make promote

Unix> cd <flow_install_dir>/user/<username>/my_workareaUnix> cd blocks/des_hard_macroUnix> rtm_make –f block_flow.make

100

• Des_hard_macro is part of a larger hierarchical Lynx design called des_chip– Full RTL is

provided– Complete flow

and scripts are provided to build des_chip with the FRS-created TSMC65LP techlib

Lynx Des_chip Sample Design

des_chip_coreu_des_chip_core

des_chip

iou_io

dft_supportu_dft_support

des_ctlu_des_ctl

des_hard_macrou_des_hard_macro_1

des_hard_macrou_des_hard_macro_2

des_soft_macro_cu_des_soft_macro_c

des_soft_macro_bu_des_soft_macro_b

des_soft_macro_au_des_soft_macro_a

TAP

BSRs

added during DFT step

PLL

101

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_c/des_soft_macro_c/des_soft_macro_b/des_soft_macro_b/

102

• 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

Hierarchical Block Flow Example – des_chip block_flow.rtm

103

• 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

Building des_chip

104

• See lab manual

LAB 2

105

AgendaTopic LabUnit

Running The Flow4



Lynx Introduction1

Adding New Designs5


106

• Create a block directory

• Configure block.tcl• Add your design

data– Constraints– Scan Configuration– Floorplan data

Adding a New Lynx Design

107

• 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

Lynx Sample Designs


blocks/blocks/

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

108

• To create a new Lynx block directory, you should consider the sample design blocks to be templates.

Creating a New Block Directory (1/3)


blocks/blocks/

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

Top-levelHierarchicalDesign

UPF designHardMacro

SoftMacro

Logic Macro(bottom-up compile)

109

• 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)


110

• 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.


111

• 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

SVAR Configuration and Lynx Tool Wrapper

Accessible

Via GUI

Variable Tabs

# Lynx Tool Wrapper Script scripts_global/conf/tool_wrapper.tcl

source common.tclsource common_setup.tclsource block.tclsource block_setup.tcl

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

# Lynx Tool Wrapper Script scripts_global/conf/tool_wrapper.tcl

source common.tclsource common_setup.tclsource block.tclsource block_setup.tcl

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

112

• 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.

Resetting Block.tcl

113

• 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

Configuring block.tcl for your New Design

114

• 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.

Block Navigator

115

• 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

block.tcl Scope Indicator (1/2)

116

• 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

block.tcl Scope Indicator (2/2)

117

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

Library Setup

118

• 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

Integration Info

119

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

Synthesis

120

• 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

Building Your Design

121

• 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

Pass/Fail Files

122

• 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.

Task Failures

123

• 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.

Adding Your Design Data into Lynx

124

• 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

Adding RTL for Your Design

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.

125

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 can accept several arguments.

• 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>.

sproc_manifest $SEV(workarea_dir)/sample_designs/des_chip/des.vh TYPE=NONEsproc_manifest $SEV(workarea_dir)/sample_designs/des_chip/des_hard_macro.vsproc_manifest $SEV(workarea_dir)/sample_designs/des_chip/des_hard_macro_bypass.vsproc_manifest $SEV(workarea_dir)/sample_designs/des_chip/des_hard_macro_core.v TYPE=RTL_SVLOGsproc_manifest $SEV(workarea_dir)/sample_designs/des_chip/convert_8_64.vsproc_manifest $SEV(workarea_dir)/sample_designs/des_chip/convert_64_8.vsproc_manifest $SEV(workarea_dir)/sample_designs/des_chip/des_encrypt_mixed.vsproc_manifest $SEV(workarea_dir)/sample_designs/des_chip/des_decrypt_mixed.vsproc_manifest $SEV(workarea_dir)/sample_designs/des_chip/des_functions.vh TYPE=NONE

sproc_manifest<file>[COPY= | COPY=<new_file> | LINK= | LINK=<new_file>][TYPE=<type>] [LIB=<libname>]

Example shown here is manifest file in SYN step!Manifest file for DP/PNR step will be shown in detail flow training.

126

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 search_path so it will be included indirectly by any `include statements in the RTL

• Copy des_hard_macro.v to syn/work/inputs. Since no type is explicitly declared, 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 into DC as a system verilog file since TYPE=RTL_SVLOG

sproc_manifest $SEV(workarea_dir)/sample_designs/des_chip/des.vh TYPE=NONEsproc_manifest $SEV(workarea_dir)/sample_designs/des_chip/des_hard_macro.vsproc_manifest $SEV(workarea_dir)/sample_designs/des_chip/des_hard_macro_bypass.vsproc_manifest $SEV(workarea_dir)/sample_designs/des_chip/des_hard_macro_core.v TYPE=RTL_SVLOGsproc_manifest $SEV(workarea_dir)/sample_designs/des_chip/convert_8_64.vsproc_manifest $SEV(workarea_dir)/sample_designs/des_chip/convert_64_8.vsproc_manifest $SEV(workarea_dir)/sample_designs/des_chip/des_encrypt_mixed.vsproc_manifest $SEV(workarea_dir)/sample_designs/des_chip/des_decrypt_mixed.vsproc_manifest $SEV(workarea_dir)/sample_designs/des_chip/des_functions.vh TYPE=NONE

Example shown here is manifest file in SYN step!Manifest file for DP/PNR step will be shown in detail flow training.

127

• 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_FILE to point to a different constraint file

Adding Constraints for Your Design

128

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

129

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

130

• 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

Design Planning Information

131

• When debugging task failures, there are several tools that the Runtime Manager provides to make this process as easy as possible

Lynx Task Debugging

132

• 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

Running Tasks Interactively with the Runtime Manager

133

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

• 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

rtm_make –f ../../scripts_block/syn/flow_syn.make 020_dc_compile ARG1=value1 ARG2=value2

134

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

135

• 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

Running View Targets

136

Lab 3

• See lab manual

137

AgendaTopic LabUnit

Running The Flow4



Lynx Introduction1

Adding New Designs5


138

• Solvnet• Lynx CAE team• Detailed Training Modules

Lynx Help

139

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

Detailed Training Modules

lynx jump start 0.6

Documents

lynx flow foundry libs

proven flow execution

design data

lynx ocv

lynx technology library

flow configuration color

query lynx flow easy

ocv foundry tape