Distributed Multi-Scenario Analysis

PrimeTime® Product Team

PrimeTime O-2018.06 Release

September 2018

© 2018 Synopsys, Inc. 1

 CONFIDENTIAL INFORMATION
The following material is confidential information of Synopsys and is being
disclosed to you pursuant to a non-disclosure agreement between you or your
employer and Synopsys. The material being disclosed may only be used as
permitted under such non-disclosure agreement.

IMPORTANT NOTICE
In the event information in this presentation reflects Synopsys’ future plans,
such plans are as of the date of this presentation and are subject to
change. Synopsys is not obligated to develop the products with the features
and functionality discussed in these materials. In any event, Synopsys’
products may be offered and purchased only pursuant to an authorized quote
and purchase order or a mutually agreed upon written contract.

© 2018 Synopsys, Inc. 2 Synopsys Confidential Information

 Topics

Introduction and Terminology

Configuring Multi-Scenario

Defining Scenarios

Issuing Tasks to Remote Processes

Managing License Resources

Managing Host Resources

Limitations

© 2018 Synopsys, Inc. 3 Synopsys Confidential Information

 Introduction and Terminology

© 2018 Synopsys, Inc. 4 Synopsys Confidential Information

 Overview

• Managing multiple operating modes across multiple corners is difficult

– Must manage multiple PrimeTime runs...
– Must analyze lots of reports...
– If there are violations... where do we start?

© 2018 Synopsys, Inc. 5 Synopsys Confidential Information

 Overview

• Distributed Multi-Scenario Analysis (DMSA) provides efficient analysis of multiple PrimeTime

analyses (or scenarios) from a single master PrimeTime process
– DMSA allows us to work with multiple analyses as easily as with a single PrimeTime analysis run!

DMSA PT PT
MASTER host host
network connection
PT
host

PT PT
host host

© 2018 Synopsys, Inc. 6 Synopsys Confidential Information

 Overview

• Each scenario in a DMSA run is a full PrimeTime analysis which can have its own unique:
– delay and slew timing
– detailed parasitics
– PrimeTime variable settings
– constraints
– etc.
CLK333 CLK333 CLK333 CLK333 CLK333 CLK333 CLK333
min: 0.8 min: 0.9 min: 1.8 min: 1.9 min: 3.2 min: 3.3 min: 4.3
CLK333 CLK333 max: 0.9
CLK333 max: 1.7
CLK333 max: 2.1
CLK333 max: 2.2
CLK333 max: 3.5
CLK333 max: 3.7 max: 4.8
min: 0.8 min: 1.0 min: 1.9 min: 2.0 min: 3.5 min: 3.8 min: 4.9
CLK400 CLK400 max: 1.0
CLK400 max: 1.2
CLK400 max: 2.2
CLK400 max: 2.3
CLK400 max: 3.9
CLK400 max: 4.3 max: 5.5
min: 0.8 min: 0.9 min: 1.9 min: 2.0 min: 2.9 min: 3.3 min: 4.4
max: 0.9 max: 1.7 max: 2.2 max:FF1
2.4 max: 3.6 max: 3.8 max: 4.9

FF1 scenario N

FF1 scenario 2
scenario 1

© 2018 Synopsys, Inc. 7 Synopsys Confidential Information

 Terminology
Master Process

• The master is a special PrimeTime process running in a "DMSA master" mode which controls
the remote worker processes
– It allocates license and machine resources, issues commands to the workers, and collects their data
– It provides the user with a single user interface to perform analysis across all scenarios

remote host processes:

DMSA PT PT
MASTER worker worker
network connection PT
worker

PT
PT
worker
worker

© 2018 Synopsys, Inc. 8 Synopsys Confidential Information

 Terminology
Remote Processes

• The remote process is a remote PrimeTime process that is controlled by the master
– A worker is also referred to as a worker process
– It is created by the master, and is given tasks to complete by the master
– At any given time, a worker process can only be performing a task on a single scenario

remote host processes:

DMSA PT PT
MASTER worker worker
network connection
PT
worker

PT PT
worker worker

© 2018 Synopsys, Inc. 9 Synopsys Confidential Information

 Terminology
Scenario

• A scenario is a single PrimeTime analysis of a certain mode at a certain corner

– The master's job is to orchestrate the analysis of the scenarios using the remote processes
– Scenarios can be swapped between memory and disk by the master if needed

S1 S3
PT
worker

S2 S4

© 2018 Synopsys, Inc. 10 Synopsys Confidential Information

 Terminology
Scenario - Example

• Consider a design with four operating modes, analyzed at three PVT corners
– This would result in 12 scenarios as shown below

Functional Scan shift Scan capture JTAG

mode mode mode mode
worst-case
(125ºC, 1.35V) func_wc scanshift_wc scancap_wc jtag_wc

typical
func_tc scanshift_tc scancap_tc jtag_tc
(25ºC, 1.50V)
best-case
func_bc scanshift_bc scancap_bc jtag_bc
(0ºC, 1.65V)

© 2018 Synopsys, Inc. 11 Synopsys Confidential Information

 Terminology
Tasks

• A task is the name for any unit of work which the master gives to a remote worker process for
execution
• Tasks are "atomic" operations
– Tasks complete uninterrupted at the remote process
– Scenario image swapping or license reallocation can only be performed between tasks

S1
PT
DMSA report_timing worker
MASTER

report_timing S2
PT
worker

© 2018 Synopsys, Inc. 12 Synopsys Confidential Information

 The Master Process

• The DMSA master process is the pt_shell invoked by the user

– The master is the user's point of contact
– The master invokes the remote worker processes
– The master issues tasks to the remote processes, and collects the resulting data

DMSA PT PT
MASTER worke worke
network connection r r
PT
worker

PT PT
worker worker

© 2018 Synopsys, Inc. 13 Synopsys Confidential Information

 Invoking the Master Process

• The DMSA master process is invoked with the

–multi_scenario switch:

unix> pt_shell –multi_scenario –f run_dmsa.pt

• This master pt_shell is a special DMSA control shell, not a regular PrimeTime shell
– different commands
– different warnings/errors
– different man pages
– does not require an extra license

© 2018 Synopsys, Inc. 14 Synopsys Confidential Information

 The Master Process
Execution Flow

• A "DMSA analysis" Tcl script is run at the master to perform the analysis

% pt_shell –multi_scenario –f run_dmsa.pt

• This DMSA analysis script looks different from a normal PrimeTime analysis script
– In the next section, we'll take a closer look at what a DMSA analysis script looks like...

© 2018 Synopsys, Inc. 15 Synopsys Confidential Information

 Configuring Multi-Scenario

© 2018 Synopsys, Inc. 16 Synopsys Confidential Information

 The DMSA Analysis Script

• What happens in a typical DMSA analysis Tcl script?

– Let's go through the steps...

% pt_shell –multi_scenario –f run_dmsa.pt

© 2018 Synopsys, Inc. 17 Synopsys Confidential Information

 Defining the Working Directory

• The multi-scenario working directory is:

– where the remote pt_shell processes are started
– where the scenario log files and swap images are stored
– typically located in the launch directory
– created by master if it does not exist
– must be readable/writeable by all remote processes
– where system_log directory resides

# set the working directory and error files

# (delete the old work directory first)
file delete -force ./work
set multi_scenario_working_directory ./work

© 2018 Synopsys, Inc. 18 Synopsys Confidential Information

 Working Directory Structure

• The following directories are automatically created inside the working directory:
– command_log/
– pt_shell command log files for each remote process
– a "scenario directory" for each scenario
– contains any temporary scenario images
– contains scenario output logfile named "out.log“
– system_log/
– Contains log files which have messages that can be useful for Synopsys to debug

$multi_scenario_working_directory/

command_log/ scenario_1/ scenario_2/ scenario_N/ system_log

scenario analysis out.log out.log out.log

logs go here Debug log files

© 2018 Synopsys, Inc. 19 Synopsys Confidential Information

 Specifying Remote Processes

• Next, a farm of remote processes must be specified using one or more set_host_options
commands
– Supports discrete machines and compute farms (Sun Grid, LSF, custom farms)
– Any mix of individual machines and farm types can be specified
– Multiple commands can be issued
– The combined set of hosts will be used

© 2018 Synopsys, Inc. 20 Synopsys Confidential Information

 Specifying Remote Processes:
Discrete Machines

• When using specific machines, simply specify the hostname and number of processes:

#
# create eight 64-bit processes on 'suse25'
set_host_options -num_processes 8 suse25

• An optional name for the resource can be given:

# create four 64-bit processes on 'linuxbox19'

set_host_options \
–name MY_LINUX -num_processes 4 linuxbox19

– This name will be used in host resource reports

© 2018 Synopsys, Inc. 21 Synopsys Confidential Information

 Specifying Remote Processes:
Compute Farms

• Compute farms submission options are specified using the –submit_command option
– The master process must be running on a valid submission host
• The submission command should include the full path
– The example below shows how to determine it automatically

# add some processes on a Sun Grid Engine farm

set_host_options \
-num_processes 12 \
–submit_command "[sh which qsub] \
–j y -cwd -o $multi_scenario_working_directory" \
-protocol sge

© 2018 Synopsys, Inc. 22 Synopsys Confidential Information

 Specifying Remote Processes:
Controlling Core Count

• The number of threading cores used by the remote processes can be specified with the
–max_cores option in the master script:
# use 4 remote processes with 8 cores each
set_host_options –num_processes 4 –max_cores 8 ...

– Compute farm submission options should request the desired core count to avoid CPU contention

© 2018 Synopsys, Inc. 23 Synopsys Confidential Information

 Specifying Remote Process:
Single Host

S1 S2 S1: 18GB, 8 cores set_host_options –name Hosts \

PT PT S2: 25GB, 8 cores –max_cores 16 –num_processes 4 \
worker worker S3: 90GB, 16 cores –submit_command \
W1 W3 S4: 110GB 16 cores {qsub -l mem_free=110G –pe mt 16 … }

create_scenario –name S1 …
PT
S3 PT S4 create_scenario –name S2 …
worker worker create_scenario –name S3 …
W2 W4 create_scenario –name S4 …
current_session {S1 S2 S3 S4}

• Each scenario is assigned to any worker

• The worker process definition should be big enough to fit the largest scenario
– In this example, S4 is the largest scenario, and requires 110GB
• Compute resources are over-specified, resulting in under-utilization of workers W1 and W3

© 2018 Synopsys, Inc. 24 Synopsys Confidential Information

 Specifying Remote Process:
Multiple Hosts
S1: 18GB, 8 cores set_host_options –name SmallHosts \
S2 S2: 25GB, 8 cores –max_cores 8 –num_processes 2 \
S3 S3: 90GB, 16 cores –submit_command \
W1 SmallHosts W3 S4: 110GB 16 cores {qsub -l mem_free=25G –pe mt 8 … }
set_host_options –name BigHosts \
–max_cores 16 –num_processes 2 \
–submit_command \
S1
PT PT S4 {qsub -l mem_free=110G –pe mt 16 … }
worker worker create_scenario –name S1
W2 W4 create_scenario –name S2
W2 W4 create_scenario –name S3
BigHosts create_scenario –name S4
current_session {S3 S2 S1 S4}

• Each scenario is assigned to a worker based on the order specified in current_session

• In this situation, we see over-utilization of worker W1 and under utilization of worker W2

© 2018 Synopsys, Inc. 25 Synopsys Confidential Information

 Specifying Remote Process:
Multiple Hosts with Scenario Affinity
S1: 18GB, 8 cores set_host_options –name SmallHosts \
S1 S2 S2: 25GB, 8 cores –max_cores 8 –num_processes 2 \
S3: 90GB, 16 cores –submit_command \
W1 W3 S4: 110GB 16 cores
SmallHosts {qsub -l mem_free=25G –pe mt 8 … }
set_host_options –name BigHosts \
–max_cores 16 –num_processes 2 \
–submit_command \
PT
S3 PT S4 {qsub -l mem_free=110G –pe mt 16 … }
worker worker
W2 W4 create_scenario –name S1 –affinity SmallHosts …
W2 W4 create_scenario –name S2 –affinity SmallHosts …
BigHosts create_scenario –name S3 –affinity BigHosts …
create_scenario –name S4 –affinity BigHosts …
current_session {S3 S1 S2 S4}

• Each scenario is assigned to a worker specified by its affinity

• Compute resources are utilized more optimally
© 2018 Synopsys, Inc. 26 Synopsys Confidential Information
 Specifying Remote Process:
Multiple Hosts with Scenario Affinity; Fewer Hosts than Scenarios
S1: 18GB, 8 cores set_host_options –name SmallHosts \
S1 S2 S2: 25GB, 8 cores –max_cores 8 –num_processes 1 \
S3: 90GB, 16 cores –submit_command \
W1 S4: 110GB 16 cores
SmallHosts {qsub -l mem_free=25G –pe mt 8 … }
set_host_options –name BigHosts \
–max_cores 16 –num_processes 1 \
–submit_command \
PT
S3 S4 {qsub -l mem_free=110G –pe mt 16 … }
worker
W2 create_scenario –name S1 –affinity SmallHosts …
W2 create_scenario –name S2 –affinity SmallHosts …
BigHosts create_scenario –name S3 –affinity BigHosts …
create_scenario –name S4 –affinity BigHosts …
current_session {S1 S2 S3 S4}

• Compute resources are shared

• Scenario swapping will occur within the affinity specified
– S1 and S2 will be assigned on W1
– S3 and S4 will be assigned on W2
© 2018 Synopsys, Inc. 27 Synopsys Confidential Information
 Specifying Remote Process:
Multiple Host Resource Affinities Defined for Scenarios
set_host_options –name SmallHosts \
S2 S1: 18GB, 8 cores
S1 –max_cores 8 –num_processes 1 \ S2: 25GB, 8 cores
W1 –submit_command \ S3: 90GB, 16 cores
SmallHosts {qsub -l mem_free=25G –pe mt 8 … } S4: 110GB 16 cores
set_host_options –name BigHosts \
–max_cores 16 –num_processes 1 \
–submit_command \
PT
S3 S4 {qsub -l mem_free=110G –pe mt 16 … }
worker
W2 create_scenario –name S1 –affinity {SmallHosts BigHosts} …
W2 create_scenario –name S2 –affinity [SmallHosts BigHosts} …
BigHosts create_scenario –name S3 –affinity BigHosts …
create_scenario –name S4 –affinity BigHosts …
current_session {S3 S4 S1 S2}

• Scenarios can be specified with multiple affinities

• Compute resources are shared
– S1 and S2 can be assigned on either W1 or W2
– S3 and S4 can be assigned on W2 only
© 2018 Synopsys, Inc. 28 Synopsys Confidential Information
 Specifying Remote Process:
Partial Host Resource Affinity
S1: 18GB, 8 cores set_host_options –name SmallHosts \
S1 S2 S2: 25GB, 8 cores –max_cores 8 –num_processes 1 \
S3: 90GB, 16 cores –submit_command \
W1 S4: 110GB 16 cores
SmallHosts {qsub -l mem_free=25G –pe mt 8 … }
set_host_options –name BigHosts \
–max_cores 16 –num_processes 1 \
–submit_command \
PT
S3 S4 {qsub -l mem_free=110G –pe mt 16 … }
worker
W2 create_scenario –name S1 …
W2 create_scenario –name S2 …
BigHosts create_scenario –name S3 –affinity BigHosts …
create_scenario –name S4 –affinity BigHosts …
current_session {S3 S4 S1 S2}

• When no affinity is specified for a scenario it can be assigned to any worker

• Compute resources are shared
– S1 and S2 can be assigned to either W1 or W2 as there is no affinity specified
– S3 and S4 can be assigned to only W2 only due to its specification
© 2018 Synopsys, Inc. 29 Synopsys Confidential Information
 Determining Launch Directory

• The sh_launch_dir variable contains the directory where PrimeTime was invoked
– If PrimeTime is launched in /user/myaccount/DMSA:

/user/myaccount/DMSA % pt_shell –multi

$sh_launch_dir

– $sh_launch_dir returns that directory, even if PrimeTime's current directory is moved somewhere
else:

pt_shell> cd /tmp
pt_shell> echo $sh_launch_dir
/user/myaccount/DMSA

© 2018 Synopsys, Inc. 30 Synopsys Confidential Information

 Invoking Remote Processes

• The start_hosts command launches the remote pt_shell processes on the specified
remote machines
– Command lines are printed as processes are invoked
pt_shell> start_hosts
1] Launched : /global/pt/bin/pt_shell \
-env_start LM_LICENSE_FILE ‘[email protected]' \
DISPLAY ‘snps:1.0' -env_end -multi_scenario \
-native -max_cores 4 -__zdpp_worker snps1 3799 3786 1 1 \
/home/snps_user/pt_dmsa/work \
PrimeTime 60225 /home/snps_user/pt_dmsa/
Status : Forking successful
Stdout : Process group is (4781)
Stderr : **<<EMPTY>>**

– Status messages are displayed as remote worker processes notify the master of success

Distributed farm creation timeout : 21600 seconds

Waiting for 3 (of 3) distributed hosts (Wed Jul 14 10:10:31 2010)
Waiting for 0 (of 3) distributed hosts (Wed Jul 14 10:10:41 2010)

© 2018 Synopsys, Inc. 31 Synopsys Confidential Information

 Reporting Remote Processes

• The report_host_usage command can be used to report information about the remote host
processes
– hostname, process ID, core count, etc.
Options Name Host Name Num Processes Protocol
--------------------------------------------------------------------
AUTO_0 >>farm<< 3 auto

Options Name # Host Name Job ID Process ID Status

--------------------------------------------------------------------
AUTO_0 1 igcae069 1630731 5416 ONLINE
2 igcae134 1630736 11871 ONLINE
3 ecss39 1630744 4895 ONLINE

Usage limits (cores)

Options Name # Effective

--------------------------------------------------------------------
(local process) - 4
AUTO_0 1 4
2 4
3 4
--------------------------------------------------------------------
Total 16

© 2018 Synopsys, Inc. 32 Synopsys Confidential Information

 Remote pt_shell Process Startup

• First, if a .synopsys_pt.setup file exists in the launch directory, a filesystem link to it will be
placed in the working directory

launch directory: working directory:

$sh_launch_dir $multi_scenario_working_directory/

.synopsys_pt.setup .synopsys_pt.setup@ command_log/ scenario/

out.log

© 2018 Synopsys, Inc. 33 Synopsys Confidential Information

 Remote pt_shell Process Startup

• Next, the master launches the remote pt_shell processes in the working directory
– The current directory of a pt_shell process at this point is shown in red below
– The linked .synopsys_pt.setup file (from the launch directory) is automatically executed, if
present

launch directory: working directory:

$sh_launch_dir $multi_scenario_working_directory/

.synopsys_pt.setup .synopsys_pt.setup@ command_log/ scenario/

out.log

© 2018 Synopsys, Inc. 34 Synopsys Confidential Information

 Remote pt_shell Process Startup

• When it's time for a remote pt_shell to do work for a scenario, it changes directory to that
scenario's directory and performs work for that scenario
– The analysis output for that scenario goes to its out.log file

launch directory: working directory:

$sh_launch_dir $multi_scenario_working_directory/

.synopsys_pt.setup .synopsys_pt.setup@ command_log/ scenario/

out.log

© 2018 Synopsys, Inc. 35 Synopsys Confidential Information

 Determining PrimeTime's Mode

• The pt_shell_mode variable specifies the current PrimeTime operating mode

– This could be useful in some .synopsys_pt.setup files

# determine which mode we are in

switch $pt_shell_mode {
primetime {
echo "Normal PrimeTime session"
}
primetime_master {
echo "Multi-scenario master session"
}
primetime_slave {
echo "Multi-scenario worker session"
}
}

© 2018 Synopsys, Inc. 36 Synopsys Confidential Information

 The Scenario's search_path

• Use the $sh_launch_dir variable for the search_path in the scenario analysis scripts
– This ensures the scenarios can find files while running from within the scenario directories
– This method also works when the script is run in a regular non-DMSA PrimeTime analysis

set sh_source_uses_search_path true ;# needed for read_sdc

lappend search_path \
$sh_launch_dir/netlist \
$sh_launch_dir/SBPF \
$sh_launch_dir/SDC

launch directory: $sh_launch_dir

.synopsys_pt.setup netlist SBPF SDC

© 2018 Synopsys, Inc. 37 Synopsys Confidential Information

 Defining Scenarios

© 2018 Synopsys, Inc. 38 Synopsys Confidential Information

 Defining Scenarios

• The analysis scenarios are defined in one of two ways:

– By providing PrimeTime scripts which load/constrain the analyses:
set link_path "* lib_${corner}.db" set link_path "* lib_${corner}.db"
read_verilog design.v.gz read_verilog design.v.gz
current_design eth_top current_design eth_top
link link

DMSA switch $corner {

bc {set_operating_conditions FAST –analysis_type
on_chip_variation}
switch $corner {
bc {set_operating_conditions FAST –analysis_type
set link_path "* lib_${corner}.db"on_chip_variation} set link_path "* lib_${corner}.db"

MASTER
read_verilog
wc {set_operating_conditions SLOW design.v.gz
–analysis_type read_verilog
wc {set_operating_conditions SLOW design.v.gz
–analysis_type
on_chip_variation} current_design eth_top on_chip_variation} current_design eth_top
} link } link
read_parasitics design.sbpf read_parasitics design.sbpf
switch $corner { switch $corner {
switch $mode { bc {set_operating_conditions FAST
switch –analysis_type
$mode { bc {set_operating_conditions FAST –analysis_type
func { on_chip_variation} func { on_chip_variation}
...functional constraints... wc {set_operating_conditions SLOW –analysis_type
...functional constraints... wc {set_operating_conditions SLOW –analysis_type
} on_chip_variation} } on_chip_variation}
test { } test { }
...test constraints... read_parasitics design.sbpf ...test constraints... read_parasitics design.sbpf
} }
} switch $mode { } switch $mode {
func { func {
...functional constraints... ...functional constraints...
} }
test { test {
...test constraints... ...test constraints...
} }
} }

– By providing existing PrimeTime saved sessions:

DMSA S1 S2
MASTER

S3 S4

© 2018 Synopsys, Inc. 39 Synopsys Confidential Information

 Defining Scenarios:
Using Scripts

• If you have a different script for each scenario, just point to the proper script for that scenario
definition:

foreach corner {bc wc} {

foreach mode {func test} {
create_scenario \
-name ${mode}_${corner} \
-specific_data "pt_${mode}_${corner}.tcl"
}
}

set link_path "* lib_${corner}.db" set link_path "* lib_${corner}.db" set link_path "* lib_${corner}.db" set link_path "* lib_${corner}.db"
read_verilog design.v.gz read_verilog design.v.gz read_verilog design.v.gz read_verilog design.v.gz
current_design eth_top current_design eth_top current_design eth_top current_design eth_top
link link link link

switch $corner { switch $corner { switch $corner { switch $corner {

bc {set_operating_conditions FAST – bc {set_operating_conditions FAST – bc {set_operating_conditions FAST – bc {set_operating_conditions FAST –
analysis_type on_chip_variation} analysis_type on_chip_variation} analysis_type on_chip_variation} analysis_type on_chip_variation}
wc {set_operating_conditions SLOW – wc {set_operating_conditions SLOW – wc {set_operating_conditions SLOW – wc {set_operating_conditions SLOW –
analysis_type on_chip_variation} analysis_type on_chip_variation} analysis_type on_chip_variation} analysis_type on_chip_variation}
} } } }
read_parasitics design.sbpf read_parasitics design.sbpf read_parasitics design.sbpf read_parasitics design.sbpf

switch $mode { switch $mode { switch $mode { switch $mode {

func { func { func { func {
...functional constraints... ...functional constraints... ...functional constraints... ...functional constraints...
} } } }
test { test { test { test {
...test constraints... ...test constraints... ...test constraints... ...test constraints...
} } } }
} } } }

pt_func_bc.tcl pt_test_bc.tcl pt_func_wc.tcl pt_test_wc.tcl

© 2018 Synopsys, Inc. 40 Synopsys Confidential Information

 Defining Scenarios:
Using Scripts

• The more common case is a single analysis script using variables to control which
mode/corner is analyzed
– Below, mode and corner control the analysis

set link_path "* lib_${corner}.db"

read_verilog design.v.gz
"pt_analysis.tcl"
current_design eth_top
link

switch $corner {
bc {set_operating_conditions FAST –analysis_type on_chip_variation}
wc {set_operating_conditions SLOW –analysis_type on_chip_variation}
}
read_parasitics design.sbpf

switch $mode {
func {
...functional constraints...
}
test {
...test constraints...
}
}

© 2018 Synopsys, Inc. 41 Synopsys Confidential Information

 Defining Scenarios:
Using Scripts

• In this case, we simply vary these variables across their different combinations and create
scenarios:
corner=bc
foreach corner {bc wc} { mode=func
foreach mode {func test} {
set link_path "* lib_${corner}.db"
read_verilog design.v.gz
current_design eth_top
link

create_scenario \ corner=bc switch $corner {

bc {set_operating_conditions FAST –
analysis_type on_chip_variation}
wc {set_operating_conditions SLOW –

mode=test
analysis_type on_chip_variation}

-name ${mode}_${corner} \
}
read_parasitics design.sbpf

switch $mode {
func {
...functional constraints...

-specific_variables {mode corner} \

}
test {

corner=wc }
}
...test constraints...

-specific_data {pt_analysis.tcl} mode=func pt_analysis.tcl

}
} corner=wc
mode=test

– The -specific_variables option “pushes” a variable’s current value at the master into the
scenario
– How does this work?

© 2018 Synopsys, Inc. 42 Synopsys Confidential Information

 Defining Scenarios:
Using Scripts

• Using –specific_variables in a scenario definition can be thought of as:

– invoking a PrimeTime session
– setting the specified variables
– sourcing the scenario script

master script: DMSA

MASTER
set mode func
set corner wc PT
remote pt_shell: host

create_scenario \ set mode {func}

-name func_wc \ set corner {wc}
-specific_variables {mode corner} \
-specific_data {pt_analysis.tcl} source pt_analysis.tcl

© 2018 Synopsys, Inc. 43 Synopsys Confidential Information

 Defining Scenarios:
Using Scripts

• Environmental shell variables can be passed to the scenarios using Tcl's env() array
– In Tcl, env(foo) represents environmental variable foo
– Simply include the desired environmental variable entries in the variable list

foreach corner {bc wc} {

foreach mode {func test} {
create_scenario \
-name ${mode}_${corner} \
-specific_variables {mode corner env(DESIGNDIR)} \
-specific_data {pt_analysis.tcl}
}
}

© 2018 Synopsys, Inc. 44 Synopsys Confidential Information

 Defining Scenarios:
Using Saved Sessions

• You can also define scenarios using saved sessions with the –image option:

create_scenario \
-name func_wc –image sessions/func_wc sessions/
create_scenario \
func_wc func_bc
-name func_bc –image sessions/func_bc

• SolvNet article 018039 provides a Tcl procedure to define scenarios for a directory of saved
sessions:

sessions/
restore_dmsa_session sessions/
S1 S2 S3 S4

© 2018 Synopsys, Inc. 45 Synopsys Confidential Information

 Specifying Scenarios for Analysis

• The current session is the list of scenarios which should be analyzed by DMSA
• Only scenarios in the current session are analyzed
– There is no resource penalty for defining many more scenarios than needed

current_session

func_wc atpg_shift_wc atpg_cap_wc jtag_wc

func_bc atpg_shift_bc atpg_cap_bc jtag_bc

func_tc atpg_shift_tc atpg_cap_tc jtag_tc

© 2018 Synopsys, Inc. 46 Synopsys Confidential Information

 Specifying Scenarios for Analysis

• For current_session, specify all scenarios

(-all) or a subset using wildcards

# enable analysis for all scenarios

current_session -all

# target only functional scenarios for analysis

current_session {*func*}

• current_session with no arguments returns the collection of scenarios in the current

session

© 2018 Synopsys, Inc. 47 Synopsys Confidential Information

 Merged Error Logging (Optional)

• The merged error log allows information, warning, and error messages to be summarized
across all scenarios
– All messages are collected during each task's execution
– The master determines which messages are common to which scenarios

# set the merged error log file location

set multi_scenario_merged_error_log ./work/merged_errors.log

./work/merged_errors.log:
Information: Related clock set 0 has base period 8000.00. (PTE-065)
( func_bc func_tc func_wc )
Information: Related clock set 0 has base period 100000.00. (PTE-065)
( atpg_capture_bc atpg_shift_bc atpg_capture_tc atpg_shift_tc )
Information: Related clock set 0 has base period 50000.00. (PTE-065)
( jtag_bc jtag_tc jtag_wc )

© 2018 Synopsys, Inc. 48 Synopsys Confidential Information

 Issuing Tasks to Remote Processes

© 2018 Synopsys, Inc. 49 Synopsys Confidential Information

 Setting the Current Scenarios

• Once the current session has been defined, the command focus can be restricted to a subset
of scenarios at any time using the current_scenario command
– The command focus controls which scenarios are used for task execution

# generate merged reports for the functional scenarios

current_scenario {func_*}
report_timing

# reset command focus to all scenarios in current_session

current_scenario -all

© 2018 Synopsys, Inc. 50 Synopsys Confidential Information

 Comparing current_session and current_scenario

• Only scenarios in the current_session set can be specified for current_scenario

current_session
current_scenario

func_wc atpg_shift_wc atpg_cap_wc jtag_wc

func_bc atpg_shift_bc atpg_cap_bc jtag_bc

func_tc atpg_shift_tc atpg_cap_tc jtag_tc

• The current_scenario command by itself returns the collection of scenarios in command

focus

© 2018 Synopsys, Inc. 51 Synopsys Confidential Information

 Merged Reports

• In DMSA, merged reports are reporting commands that report across the set of scenarios in
command focus
– Duplicate or subcritical information is suppressed, according to the merging rules for each report
– This dramatically reduces the time needed to analyze and interpret the results
• The merged reporting commands are:
– report_timing
– report_constraint
– report_global_timing
– report_qor
– report_analysis_coverage
– report_clock_timing
– report_si_bottleneck
– report_noise

© 2018 Synopsys, Inc. 52 Synopsys Confidential Information

 Merged report_timing

• Merged report_timing shows the worst paths across the scenarios in focus
– This avoids looking at repetitive paths across the scenarios

report_timing –max_paths 100

S1 PT S4 PT
DMSA worker worker
MASTER S7
PT
worker
S2 PT
S5 PT
Paths from all scenarios in focus worker worker
S8
PT
worker
S3 PT
S6 PT
worker worker
100 worst paths across ALL
scenarios in focus

Note: The -max_paths behavior applies across all path groups, not per path group (behavior before F-2011.12)

© 2018 Synopsys, Inc. 53 Synopsys Confidential Information

 Merged report_timing
Duplicate Removal

• Merged report_timing works just like a normal report_timing, but across scenarios in
focus:
– Paths are obtained from all scenarios in focus
– The usual options such as -max_paths, -nworst, and -unique_pins are available

• …but when duplicate paths are found across multiple scenarios, only the most critical path is
kept
– This is called duplicate path merging
– What is a "duplicate path?"

© 2018 Synopsys, Inc. 54 Synopsys Confidential Information

 Merged report_timing:
Duplicate Removal

• Paths from different scenarios are considered to be duplicates if they have the:
– Same sequence of pins along data portion of the path
– Same transition directions at every pin along the data path
– Same launch clock
– Same capture clock
– Same constraint type

• Once the subcritical duplicates have been removed, the –max_paths and –nworst limits are
reapplied to the merged set
• Duplicate merging can be disabled with:

report_timing –dont_merge_duplicates

© 2018 Synopsys, Inc. 55 Synopsys Confidential Information

 Merged report_timing

• Each merged timing report's header includes the name of the scenario that supplied the path:

Startpoint: m_wb_ack_i (input port clocked by wb_clk_i)

Endpoint: core/wishbone/IncrTxPointer_reg
(rising edge-triggered flip-flop clocked by wb_clk_i)
Path Group: inputs
Path Type: max
Scenario: wc
Max Data Paths Derating Factor : 1.00
Min Clock Paths Derating Factor : 0.95
Max Clock Paths Derating Factor : 1.00

© 2018 Synopsys, Inc. 56 Synopsys Confidential Information

 Merged report_timing

• The -path_type end format shows path summaries with endpoint, scenario, and slack
columns:

pt_shell> report_timing -path_type end -max_paths 10 –delay min

...

Endpoint Path Delay Path Required Slack Scenario

--------------------------------------------------------------------------------
Busy_IRQ_sync2_reg/D (DFQD1) 0.68 f 0.75 -0.07 wc
RxAbortSync4_reg/D (DFCNQD1) 0.72 f 0.78 -0.06 wc
ethreg1/SetTxCIrq_sync3_reg/D (DFCNQD1) 0.41 f 0.47 -0.05 bc
SendControlFrame_sync3_reg/D (DFCNQD1) 0.57 f 0.62 -0.05 tc
WriteRxDataToFifoSync3_reg/D (DFCNQD1) 0.58 f 0.63 -0.05 tc
miim1/RStat_q2_reg/D (DFCND1) 0.41 f 0.46 -0.05 bc
SyncRxStartFrm_q_reg/D (DFCND1) 0.73 f 0.78 -0.05 wc
Busy_IRQ_sync3_reg/D (DFQD1) 0.70 f 0.74 -0.05 wc
WriteRxDataToFifoSync2_reg/D (DFCND1) 0.58 f 0.63 -0.05 tc
miim1/EndBusy_reg/D (DFCND1) 0.41 f 0.46 -0.05 wc

© 2018 Synopsys, Inc. 57 Synopsys Confidential Information

 Merged get_timing_paths

• A merged get_timing_paths command is also available

– If you are using get_attribute on the path, the list of desired path attributes to be included must
be specified

get_timing_paths –max_paths 100

-attributes {points slack}
S1 PT
S4 PT
DMSA worker worker
MASTER S7
PT
worker
S2 PT
S5 PT
timing_path objects worker worker
from all scenarios in focus S8
PT
worker
S3 PT
S6 PT
worker worker
100 worst timing_path objects across
ALL scenarios in focus!
Note: The -max_paths behavior applies across all path groups, not per path group (behavior before F-2011.12)
© 2018 Synopsys, Inc. 58 Synopsys Confidential Information
 Merged report_constraint

• The merged report_constraint command shows the worst constraint slack for each
design object across scenarios
– The scenario providing the worst slack is displayed
– Other subcritical slacks for that design object are suppressed
– Supports path violations based on path based timing also (-pba_mode path | exhaustive)
pt_shell> report_constraint -nosplit -all_violators -max_transition
...
Required Actual
Pin Scenario Transition Transition Slack
-------------------------------------------------------------------------------
RxStatusInLatched_reg[2]/E wc 1.001 1.026 -0.025 (VIOLATED)
LatchedRxLength_reg[11]/E wc 1.001 1.026 -0.025 (VIOLATED)
RxStatusInLatched_reg[5]/E wc 1.001 1.025 -0.024 (VIOLATED)
rx_fifo/U201/B2 bc 0.554 0.571 -0.017 (VIOLATED)
rx_fifo/U197/B2 bc 0.554 0.571 -0.017 (VIOLATED)
rx_fifo/U210/B2 bc 0.554 0.570 -0.016 (VIOLATED)
rx_fifo/U202/B2 bc 0.554 0.570 -0.016 (VIOLATED)
LatchedRxLength_reg[5]/E tc 0.801 0.794 -0.007 (VIOLATED)
LoadRxStatus_reg/Q tc 0.801 0.794 -0.007 (VIOLATED)

© 2018 Synopsys, Inc. 59 Synopsys Confidential Information

 Merged report_analysis_coverage

• The merged report_analysis_coverage command shows the constraint arc coverage

across scenarios
– A constraint arc is:
– VIOLATED if the arc violates in any scenario, else… highest
– MET if the arc is met in at least one scenario, else…
– UNTESTED only if the arc is untested in all scenarios lowest

Scenarios: bc, tc, wc

Type of Check Total Met Violated Untested

--------------------------------------------------------------------------------
setup 20695 10435 ( 50%) 9677 ( 47%) 583 ( 3%)
hold 20695 20020 ( 97%) 92 ( 0%) 583 ( 3%)
recovery 1261 0 ( 0%) 0 ( 0%) 1261 (100%)
removal 1261 0 ( 0%) 0 ( 0%) 1261 (100%)
--------------------------------------------------------------------------------
All Checks 43912 30455 ( 69%) 9769 ( 22%) 3688 ( 8%)

© 2018 Synopsys, Inc. 60 Synopsys Confidential Information

 Merged report_analysis_coverage

• This constraint merging behavior ensures that each check is exercised in at least one scenario
– This allows constraint coverage to be assessed across dissimilar scenarios
• In the example below, a flip-flop is analyzed in both functional and scan shift scenarios
– When SE==0, CLK→SD is untested in functional mode
– When SE==1, CLK →D is untested in scan shift mode
– …but the entire flip-flop is fully tested across both scenarios

functional D Q scan shift D Q

mode: SD mode: SD
0 SE 1 SE

© 2018 Synopsys, Inc. 61 Synopsys Confidential Information

 Merged report_clock_timing

• The merged report_clock_timing command reports the worst clock latencies, skews, and
transitions across all scenarios
– The worst skews and worst latencies may exist in different scenarios

Scenarios: bc, tc, wc

Clock: mrx_clk_pad_i

Clock Pin Scen Latency Skew

----------------------------------------------------------------------------
rxethmac1/crcrx/Crc_reg[15]/CP wc 0.62 rp-+
macstatus1/LatchedCrcError_reg/CP 0.44 0.18 rp-+
----------------------------------------------------------------------------

Clock: mtx_clk_pad_i

Clock Pin Scen Latency Skew

----------------------------------------------------------------------------
txethmac1/txcounters1/ByteCnt_reg[11]/CP tc 0.41 rp-+
txethmac1/txcounters1/NibCnt_reg[13]/CP 0.29 0.11 rp-+
----------------------------------------------------------------------------

© 2018 Synopsys, Inc. 62 Synopsys Confidential Information

 Merged report_si_bottleneck

• The merged report_si_bottleneck shows the worst SI victims across all scenarios
– This makes it easy to find and fix the worst crosstalk problems across the scenarios

Bottleneck Cost: delta_delay

net scenario cost
------------------------------------------------------------------------------
n42 wc 0.08
m_wb_adr_o[8] wc 0.06
wishbone/bd_ram/C36257/n295 wc 0.05
temp_wb_dat_o[18] wc 0.03
n46 bc 0.02
wishbone/bd_ram/C36257/n311 wc 0.01
wb_sel_i[0] wc 0.01
wishbone/WriteRxDataToFifoSync1 wc 0.01
wishbone/ReadTxDataFromFifo_sync1 wc 0.01
wishbone/TxDone_wb bc 0.01
wishbone/TxAbortSync1 tc 0.01

© 2018 Synopsys, Inc. 63 Synopsys Confidential Information

 Merged report_global_timing

• The report_global_timing command

provides a fast and efficient top-level
summary of the timing violations of the
entire design

• To report the breakdown of violations

comprising the merged report by
scenario in DMSA ...

• Specify the option -include

{scenario_details} in the DMSA master

• Supports summary based on path-based

timing analysis also

© 2018 Synopsys, Inc. 64 Synopsys Confidential Information

 Merged report_noise

• Generates a merged report showing pins that have the worst slack
over all scenarios
• Additional column scenario reports the scenarios that contributed
to the worst slack
• Supports all existing options of report_noise

Report : noise
…
Design : multi-scenario design
…
slack type: height
scenarios: scen01, scen02, scen03
noise_region: above_low
pin name (net name) width height slack scenario
----------------------------------------------------------------------------------
ethreg1_MIICOMMAND1_DataOut_reg_0_/SI (n7483) 0.1788 0.4488 -0.0255 scen01
wishbone_rx_fifo_fifo_reg_2__22_/SI (n1412) 0.1487 0.5106 -0.0193 scen02
wishbone_TxLength_reg_3_/SE (n7726) 0.1936 0.4258 -0.0192 scen01
wishbone_StartOccured_reg/SI (net19402) 0.1503 0.4455 -0.0156 scen01
wishbone_RxByteCnt_reg_1_/SI (net31416) 0.1016 0.5286 -0.0151 scen03

© 2018 Synopsys, Inc. 65 Synopsys Confidential Information

 ECO commands
DMSA supports all ECO-related commands at the master

• fix_eco_timing
– setup
– hold
– path based (-pba_mode path | exhaustive)
– path collection based
• fix_eco_drc
– max_capacitance 1583172: "PrimeTime Automated Physically-Aware
– max_transition ECO Flow With IC Compiler Application Note"
– max_fanout
https://solvnet.synopsys.com/retrieve/1583172.html
– noise
• fix_eco_power
– Vt swapping
– Cell downsizing
• All three commands support both logical and physical ECO
© 2018 Synopsys, Inc. 66 Synopsys Confidential Information
 Master/Scenario Variable Communication

• Variables can be pulled from scenarios to the master

– An array is created at the master

DMSA set v 123

MASTER
scenA

set v 456
scenB
get_distributed_variables v

$v(scenA) == 123 set v 789

$v(scenB) == 456
scenC
$v(scenC) == 789

© 2018 Synopsys, Inc. 67 Synopsys Confidential Information

 Master/Scenario Variable Communication

• Variables can be pushed from the master to scenarios

– Scalar values or arrays at the master can be used

DMSA
MASTER $v == bar
scenA
$arr == 1

$v == bar
scenB
set v {bar} $arr == 2
set arr(scenA) 1
set arr(scenB) 2
$v == bar
set arr(scenC) 3 scenC
$arr == 3
set_distributed_variables {v arr}

© 2018 Synopsys, Inc. 68 Synopsys Confidential Information

 Saving Scenario Session

• save_session command can be issued either in the master or the worker

process
• By default a save_session issued in DMSA would share data that is
common to different scenarios
• Common data sharing during save_session can be disabled:
– save_session -disable_common_data_sharing
• Individual scenarios from DMSA sessions with shared data can be restored in
a single scenario PrimeTime

© 2018 Synopsys, Inc. 69 Synopsys Confidential Information

 Saving Scenario Session
Shared Parasitic Data

• Consider a design with 2 modes and 2 corners with a total of 2 scenarios

• All the modes at the same corner share the same parasitic file

• This common information is saved in a separate common directory to reduce the total disk
usage of the save_session database

Functional mode Scan shift mode

wc (125C 0.8V) wc spef wc spef

bc (-25C 1.0V) bc spef bc spef

© 2018 Synopsys, Inc. 70 Synopsys Confidential Information

 Saving Scenario Session
Directory Structure for save_session Issued at Master

Directory structure without data sharing Directory structure with data sharing

Save_session directory

Save_session directory Common_

Scenario1 Scenario2 Scenario3 Scenario4
data

Scenario1 Scenario2 Scenario3 Scenario4 a

© 2018 Synopsys, Inc. 71 Synopsys Confidential Information

 Saving Scenario Session
Directory Structure for save_session Issued at Worker

Directory structure without data sharing Directory structure with data sharing

Multi scenario working

directory
Multi scenario working
directory
Common_
Scenario1 Scenario2 Scenario3 Scenario4
data
Scenario1 Scenario2 Scenario3 Scenario4

session session session session a

session session session session
b

© 2018 Synopsys, Inc. 72 Synopsys Confidential Information

 Task Execution Status Messages

• When a task is executing, the master displays informational progress messages

– These can be controlled with multi_scenario_message_verbosity_level

Start of Master/worker Task Processing

-------------------------------------
Started : Command execution in scenario 'func_bc'
Started : Command execution in scenario 'func_wc'
Started : Command execution in scenario 'atpg_shift_bc'
Started : Command execution in scenario 'atpg_shift_wc'
Started : Command execution in scenario 'func_tc'
Succeeded : Command execution in scenario 'atpg_shift_wc'
Succeeded : Command execution in scenario 'atpg_shift_bc'
Succeeded : Command execution in scenario 'func_tc'
Succeeded : Command execution in scenario 'func_wc'
Succeeded : Command execution in scenario 'func_bc'
-----------------------------------
End of Master/worker Task Processing

© 2018 Synopsys, Inc. 73 Synopsys Confidential Information

 What Isn't Supported at the DMSA Master?

• Netlist exploration commands are not available

– get_*, all_fanin/fanout, all_registers, etc.
• Reporting commands that do not explicitly support merged reporting are not available
– report_crpr, report_net, report_delay_calc, etc.
• Most global application variables are not available
– CRPR, SI, etc.
– It doesn't make sense for these variables to be set at the master – they should be set within each
scenario
• Use remote_execute to work with these commands and variables …

© 2018 Synopsys, Inc. 74 Synopsys Confidential Information

 remote_execute

• remote_execute can be used to execute any valid PrimeTime commands at the scenarios:
# generate some non-merged reports in the scenario log files
remote_execute {
report_design
report_clocks
check_timing
}

– By default, command output is written to the scenario's out.log file

© 2018 Synopsys, Inc. 75 Synopsys Confidential Information

 remote_execute -verbose

• Or, use remote_execute -verbose to divert the output to the master:

pt_shell> remote_execute -verbose {list_lib}

worker output for bc:

list_lib
bc
Library Registry:
* fast /cad/libs/fast.db:fast

worker output for tc:

list_lib
tc
Library Registry:
* typical /cad/libs/typical.db:typical

worker output for wc:

list_lib
wc
Library Registry:
* slow /cad/libs/slow.db:slow

© 2018 Synopsys, Inc. 76 Synopsys Confidential Information

 remote_execute and Quoting

• If double quotes are used, normal Tcl soft-quoting rules are followed
– Allows variable substitution at the master
– Allows command substitution at the master using [...]

# generate some specific check_timing reports

set check_list {no_clock unconstrained_endpoints}
remote_execute "
check_timing –verbose –override_defaults {$check_list}
"

© 2018 Synopsys, Inc. 77 Synopsys Confidential Information

 remote_execute and Quoting

• If curly braces are used, normal Tcl hard-quoting rules are followed
– No variable substitution
– No command substitution using [...]
– String is passed exactly as-is to the scenarios

# show memory, cputime, and hostname in scenario log

remote_execute {
echo "Memory: [mem]"
echo "CPU time: [cputime]"
echo "Hostname: $env(HOST) process ID [pid]"
}

© 2018 Synopsys, Inc. 78 Synopsys Confidential Information

 Managing License Resources

© 2018 Synopsys, Inc. 79 Synopsys Confidential Information

 Scenario-Based Licensing
One license to run each scenario

• The default multi-scenario licensing mode is scenario-based: one license to run each scenario
• When (# licenses) < (# remote processes):
– Licenses are allocated to workers by master
– When a task finishes at a remote process, the master can immediately reclaim the license for use by
another waiting task
– Remote processes are not terminated to free license

PT license
PT PT
worke worke
r r
active (waiting)
DMSA
MASTER

PT PT
worke worke
r PT license r
(waiting) active
© 2018 Synopsys, Inc. 80 Synopsys Confidential Information
 Core-Based Licensing for DMSA
Each PrimeTime ADV Key Enables 32 Cores

Dedicated Machines Compute Cloud

100M inst. full-chip: 5M inst. block:
• Core-based licensing for 2 Scenarios x 16 cores 16 scenarios x 4 cores
multi-scenario STA & ECO
DMSA DMSA
Controller Controller
• License required based 1 PrimeTime ADV 2 PrimeTime ADV
on total number of cores
Reserved Distributed jobs on
Machines in compute grid
• Cores can be local or Compute Farm
across multiple machines

16 Cores x 2 Machines = 8 Cores x 8 Machines =

32 Cores Total 64 Cores Total
© 2018 Synopsys, Inc. 81 Synopsys Confidential Information
 Core-Based Licensing for DMSA

• One PrimeTime-ADV license is required for running up to 32 cores, regardless of the number
of scenarios

• To select core-based licensing, change the multi_scenario_license_mode variable setting

from scenario (default) to core in the DMSA master

pt_shell> set multi_scenario_license_mode core

Information: Checked out license 'PrimeTime-ADV' (PT-019)

• The core-based licensing mode requires a PrimeTime-ADV license

© 2018 Synopsys, Inc. 82 Synopsys Confidential Information

 Controlling License Resources

• By default, licenses are checked out as needed by scenarios, and no license controls are
required
• But if desired, license controls are available:
– The set_license_limit command can be used to specify an upper limit on each license feature's
usage:
# limit licenses to 4 PrimeTime and PrimeTime SI licenses
set_license_limit PrimeTime -quantity 4
set_license_limit PrimeTime-SI -quantity 4

• The license limits can be increased or decreased at any time

– License decreasing is enabled by default. To disable it, set value to “0” before invoking
pt_shell –multi_scenario

setenv SNPSLMD_ENABLE_INCREMENTAL_LICENSE_HANDLING 0

© 2018 Synopsys, Inc. 83 Synopsys Confidential Information

 License Auto-Reduction

• License auto-reduction allows licenses to be checked back in during lengthy tasks

– When a scenario completes its task, if no further scenarios are waiting for the license, it is returned to
the license server
# licenses checked out

update_timing report_clock_timing report_timing size_cell

4
3
2
1

time

© 2018 Synopsys, Inc. 84 Synopsys Confidential Information

 License Auto-Reduction

• License auto-reduction:
– ...can be good for long tasks like update_timing if runtimes are dissimilar across the scenarios
– ...can be bad for interactive work if your license server is slow
– You could spend more time waiting for checkins/checkouts than doing work
– You may not get all your licenses back

# perform timing updates

set enable_license_auto_reduction true
remote_execute {update_timing}

# reduce license count for interactive work

set enable_license_auto_reduction false
report_timing ...
size_cell ...
report_timing ...

© 2018 Synopsys, Inc. 85 Synopsys Confidential Information

 Managing Host Resources

© 2018 Synopsys, Inc. 86 Synopsys Confidential Information

 DMSA and Limited Hosts

• When (# remote processes) < (# scenarios in session):

– Scenario images must be swapped using save_session/restore_session by remote processes to
execute tasks
– This is very expensive in terms of disk activity and runtime
– This should be avoided unless absolutely necessary!

© 2018 Synopsys, Inc. 87 Synopsys Confidential Information

 DMSA Virtual Workers
Overview

• DMSA virtual worker multiplexes scenarios on the same host without save/restore operation

© 2018 Synopsys, Inc. 88 Synopsys Confidential Information

 DMSA Virtual Workers
Benefits of Feature

• When number of cores is limited, DMSA virtual workers reduces runtime by avoiding
save/restore for unloading/loading scenarios
• When number of machines is limited, DMSA virtual worker allows more scenarios per machine
– Memory allocation increases proportionally to load factor for each host to account for virtual workers
– Minimal runtime increase
Benefit for DMSA limited host user Benefit while reducing # core usage
Run time reduction # core reduction vs performance
18000 140 140 150 3.5
140
160
289.5% 140
3
15000
120
2.5
12000 100
-65% reduction 2 70
192.2% 100
9000 80
1.5 48
6000 50 99.9% 98%
60
1 36
67% 40
3000
0.5 34%
20
0 0 0 0
0 0
Baseline Load factor=2 Baseline Load factor 2 Load factor 3 Load factor 4
Run time # cores total run time increase % peak slave memory increase % # cores

© 2018 Synopsys, Inc. 89 Synopsys Confidential Information

 DMSA Virtual Workers
Command

• Use option –load_factor in set_host_options

pt_shell> set_host_options –load_factor 3 –num_processes 2 –max_core 4

• The load factor can be a integer between 1 and 4

– Default is 1 (virtual worker mode disabled)
– Maximum is 4
– If value is set > 4, CMCR-040 error message is generated

pt_shell> set_host_options -load_factor 5 –num_processes 2

Warning: The value for load_factor (5) must be within the range 1<=value<=4.
Resetting it to 4. (CMCR-040)
0

© 2018 Synopsys, Inc. 90 Synopsys Confidential Information

 DMSA Virtual Workers
Examples

• DMSA master host setup example:

– A design with 48 scenarios, 4 cores per scenarios

Default: Real workers only

pt_shell> set_host_options -num_processes 48 -max_cores 4 -submit_command {qsub -l mem_free=16G ….. }

192 cores

Virtual workers
pt_shell> set_host_options -num_processes 24 -max_cores 4 –load_factor 2 \
-submit_command {qsub -l mem_free=32G ….. } 96 cores

pt_shell> set_host_options -num_processes 12 -max_cores 4 –load_factor 4 \

-submit_command {qsub -l mem_free=64G ….. } 48 cores

© 2018 Synopsys, Inc. 91 Synopsys Confidential Information

 DMSA Virtual Workers
report_host_usage

• Host usage reports a virtual worker as one host process

pt_shell> set_host_options -num_processes 1 \ pt_shell> report_host_usage

-max_cores 1 -load_factor 2 ****************************************
1 Report : host_usage
****************************************
start_hosts Options Name Host Name Num Processes Protocol
Launching 1 Distributed Worker(s) ----------------------------------------------------------------
Real worker process
AUTO_0 localhost 2 auto
which can additionally launch 1 virtual worker(s) Options Name # Host Name Job ID Process ID Status
----------------------------------------------------------------
AUTO_0 1 localhost - 14178 ONLINE
1] Launched : sh localhost /tools/pt/bin/pt_shell \ 2 localhost - 14201 ONLINE
-slv_type dmsa_slv -max_cores 1 Usage limits (cores)
Options Name # Effective
Virtual worker process
----------------------------------------------------------------
---------------------------------------------------------------- (local process) - 4
AUTO_0 1 1
Distributed farm creation timeout : 21600 seconds
2 1
Waiting for 1 (of 1) workers : Thu Apr 26 22:58:17 2018 ----------------------------------------------------------------
Waiting for 0 (of 1) workers : Thu Apr 26 22:58:27 2018 Total 4
1
----------------------------------------------------------------

© 2018 Synopsys, Inc. 92 Synopsys Confidential Information

 Limitations

© 2018 Synopsys, Inc. 93 Synopsys Confidential Information

 Current Limitations

• Not all PrimeTime commands and variables exist at the DMSA master
– Use remote_execute as needed
• Limited to 256 remote processes
• GUI functionality is not available
• Beware of conflicts when running multiple runs in same directory
– Use different-named work directories to avoid overwriting files

© 2018 Synopsys, Inc. 94 Synopsys Confidential Information

 DMSA Example Design

• To try distributed multi-scenario analysis on your own, an example design is included in the
following SolvNet article:

014511: "Example Distributed

Multi-Scenario Analysis Design"
http://solvnet.synopsys.com/retrieve/014511.html

© 2018 Synopsys, Inc. 95 Synopsys Confidential Information

Thank You