RedHawk-SC/ClockFX Solutions

for Jitter Analysis

Version 2020.1.0

Contents
1. Introduction .................................................................................................................................................................................... 2
2. Flow Overview................................................................................................................................................................................. 2
Steps Involved ................................................................................................................................................................................ 2
Clock FX Operations ....................................................................................................................................................................... 3
RHSC Operations ............................................................................................................................................................................ 4
Jitter Calculation Description ......................................................................................................................................................... 5
3. Input Requirements ........................................................................................................................................................................ 6
Clock FX Inputs ............................................................................................................................................................................... 6
RHSC Inputs .................................................................................................................................................................................... 7
Common Issues with Input Data .................................................................................................................................................... 8
4. Flow Setup....................................................................................................................................................................................... 8
Creating the Clock FX database...................................................................................................................................................... 8
Creating the RHSC database .......................................................................................................................................................... 9
Creating the Supply Noise file ........................................................................................................................................................ 9
Using a ClockFX session ........................................................................................................................................................... 10
Using an RHSC session............................................................................................................................................................. 10
Setting up the clock jitter run and generating reports ................................................................................................................ 11
Setting up a sanity check run ....................................................................................................................................................... 12
5. Reports and Outputs ..................................................................................................................................................................... 13
Jitter Report Generation .............................................................................................................................................................. 13
Jitter types available in ClockFX .............................................................................................................................................. 14
6. Options in ClockFX ........................................................................................................................................................................ 16
7. How do I..? .................................................................................................................................................................................... 17
Decide on the number of workers to use? .................................................................................................................................. 17
Find jitter at a specific endpoint? ................................................................................................................................................ 18
Find the full path from the clock source to the endpoint? .......................................................................................................... 18
Create a set up for spice correlation? .......................................................................................................................................... 19
8. Troubleshooting Tips .................................................................................................................................................................... 20
Troubleshooting Checklist............................................................................................................................................................ 20
No jitter found at a given endpoint ............................................................................................................................................. 20
Fewer edges than expected ......................................................................................................................................................... 21
9. Conclusion ..................................................................................................................................................................................... 21

© 2020 ANSYS Inc Page | 1

1. Introduction
FX is a fast transistor level simulator that offers SPICE-accurate modelling and can capture complex effects,
miller capacitances and non-linear voltages. The transistor models used in FX (called FX models or FXMs)
are built using the foundry SPICE models, the LPE netlists and liberty files. It is a full-fledged engine with
Verilog/SPEF/SDC parsing capabilities, as well as an API to enable scripting.

RedHawk-SC is an advanced SoC power-noise and reliability analysis platform. It is a production-proven

tool and is certified by leading foundries at advanced technology nodes. It is capable of analyzing IR/EM
for all types of designs, supporting a wide variety of flows as per the need of the end user.

The two technologies can be used in tandem to perform very accurate, SPICE-verifiable jitter analysis on
designs even at advanced technologies. RedHawk-SC generates the switching scenario by propagating the
clocks through the clock tree and calculates the IR drop at every instance based on this scenario. This
information is passed to Clock FX, which is a specialized tool to analyze clock trees, where it is used to
perform delay calculations using FX models.

Unlike previous solutions, where the voltage distribution used for jitter calculation is statistically
generated, this solution uses real supply noise data coming from an advanced IR-drop analysis tool. This
provides the end user with the ability to connect jitter violations directly to the switching scenario which
led to it – such capabilities are desirable at advanced technologies, where the voltage impact on timing is
quite complex in nature.

2. Flow Overview
Steps Involved
There are generally 3 steps required to run the RHSC-ClockFX flow for clock jitter analysis. These are:

1. Prepare and read in the data:

a. Read the FXMs, Verilog, SPEF and SDC into ClockFX.
b. Create a RedHawk-SC database with an AnalysisView
2. Generate the supply noise file using the data mining script in RedHawk-SC.
3. Run the jitter analysis in ClockFX using the supply noise file.

Each of these steps are discussed in detail in later sections. There are additionally a few intermediate
steps which are optional, such as sanity checks.

© 2020 ANSYS Inc Page | 2

Clock FX Operations

Figure 1: ClockFX Operations

As described earlier, there are two stages to be completed within ClockFX – reading the inputs, and
calculating the jitter. ClockFX has straightforward APIs which can be used to read in the basic input
collaterals. These are listed below:

1. FXMs and Liberty Files – In FX, all the master cells in the design need to be characterized to
generate FX models. These are transistor-level models which are read in all FX products, and are
the primary source of structural, functional, and electrical information for any given master cell.
This information is used to calculate the delay through the cell given a transition sense and supply
noise value. A note on FXM characterization is available in section 4 of this Appnote.

For more complex cells such as macros and memory cells, it is not necessary (and may not be
feasible) to generate and provide FXMs. It is sufficient to provide regular NLDM models (liberty
files) for such cells. This is because these cells are generally endpoints in the clock tree – as such,
ClockFX requires only the pin capacitance and the clock pin names for these cells.

Cells without FXMs or Liberty models are treated as blackboxes, and may cause breaks in the clock
tree leading to sections where jitter cannot be calculated downstream. ClockFX issues a
‘V2C:BLKBX’ warning in case such cells are found.
2. Verilog Files – The instance names in the Verilog netlist given to ClockFX must match those in the
DEF files given to RHSC. If this is not ensured, it may lead to incorrect mapping of the supply noise
file.
3. SPEF – The SPEF file contains parasitic information for all nets, which is required to accurately
calculate the delay through a path. If unavailable, a wire load model will be used.
4. SDC – The SDC is an important input, since it contains information about the clock sources in the
design, in addition to any generated clocks and design constraints. It must be ensured that the
SDC file used in ClockFX is synchronous with the timing file provided to RHSC.

The second stage of ClockFX operations is the actual jitter calculation. The key input here is the supply
noise file generated using RedHawk-SC, about which more details are provided in section 4. A detailed
overview of the jitter calculation is provided under the ‘Jitter Calculation Description’ heading in this
section.

© 2020 ANSYS Inc Page | 3

RHSC Operations

Figure 2: RHSC Operations

RedHawk-SC is used to generate the supply noise file that will be used by ClockFX during jitter calculation.
This is a file that captures, for all clock instances of interest, both the switching scenario as well as the
instantaneous IR drop for each transition. There are three modes possible:

1. dvdfast – Captures the minimum value over the timing window for both the power and ground
pins for each transition. This is the recommended mode.
2. eff_Vdd – Captures the minimum compression voltage (voltage difference between power and
ground pins) and applies it to the power pin, keeping the ground pin at 0 V. This is a common
practice in STA.
3. dvd_pwl – Captures the PWL waveform of the power and ground pin voltages for a window
around each transition time. Since the supply noise file is uncompressed, this mode may lead to
a significant disk space overhead for large designs. Generally, this mode is considered to be the
most accurate – however, this may not be worth it due to the extra memory and runtime costs.

The supply noise file is generated using a data mining script, which can be invoked from an RHSC session.
The recommended approach, however, is to use a wrapper function within ClockFX that internally runs
RHSC to generate the supply noise file. This wrapper assumes that an RHSC db containing an AnalysisView
is already available. It is also possible to generate the supply noise file by running the relevant commands
within RHSC once view creation is complete. The choice between using the ClockFX wrapper or using the
commands directly in RHSC depends on the customer’s preference (since EMIR and Timing may be
handled by different departments, for example).

An important point to be noted while creating the RHSC database is that the scenario must be logically
consistent. This rules out the possibility of using a No-Propagation Vectorless scenario for this flow. This
means that for every event that happens at a given instance, there should be a corresponding event
occurring at its driver – these events should be traceable all the way to the source. For logic cells, the
output at the logic cell should be calculated by applying the logic function to the signals propagated to its
inputs. The only exception is in the case of endpoint cells such as registers – since delay (and thus, jitter)
does not need to be calculated through these cells, the input and output events here do not have any
significance. The clock events, however, should still be traceable to the clock source. Generally, customers
are requested to use the logic-propagated vectorless engines available in RHSC (such as regular vectorless
or PCVS). Another option is to provide a vector input (VCD/FSDB file). It is possible to use a combination
of vectorless and vector-based blocks in the scenario.

© 2020 ANSYS Inc Page | 4

Jitter Calculation Description
Consider the following scenario:

Figure 3: Example Clock Network

Here, the difference between the deviation from the ideal arrival time of the first and second rise edges
at ‘reg_inst’ would be the period jitter measured at that point. To calculate this number, ClockFX does the
following calculations:

Figure 4: Period Jitter Calculation

1. For any given edge (say, Rise 1), calculate the delay through each stage in the clock path to find
the actual arrival time at the endpoint. This is a function of the delay offered by each cell (which,
in turn, depends on the supply noise), the parasitics of the net connecting the path instances
(from SPEF) and the capacitance of the pins. Calculate the deviation from the ideal arrival time
based on the calculated actual arrival time.
2. The delay now represents the time taken for a given edge (Rise1, Rise2) to reach a given point
(clock pin of reg_inst). It follows that the jitter can be calculated as the difference between the
deviations from the ideal time, calculated earlier. This will give the same result as the calculation
shown in the figure.

In ClockFX, each edge can be solved in parallel in multiple ‘experiments’ using workers. Depending on the
worker distribution, it may be so that multiple edges are solved by the same worker (in the same
‘experiment’). To obtain details about a particular edge solve, it is possible to use API queries in a ClockFX
session after loading the corresponding experiment.

© 2020 ANSYS Inc Page | 5

The main takeaway from this section is that every jitter number reported in ClockFX is associated with the
following parameters:

1. Source point - Typically, this is the clock source

2. End point - This is the point at which jitter is measured
3. Jitter sense – Rise or Fall edge jitter
4. Early/Late cycle – Clock edges used to calculate this jitter (for example, here, the early cycle would
be 1 (rise edge of the 1st cycle) and the late cycle would be 2 (rise edge of the 2nd cycle)).
a. The number of cycles depends on the jitter type.
5. Early/Late experiments – The name of the experiments that solved the early/late cycle edges,
respectively.
a. The number of experiments depends on the jitter type.

ClockFX is capable of reporting various kinds of jitter broadly based on JEDEC definitions, in addition to a
few other jitter types. These are discussed in more detail in a later section.

3. Input Requirements
Clock FX Inputs
Clock FX requires the following inputs

1. FXMs and/or Liberty models – A description of this input requirement is available in section 2. A
detailed document regarding FXM creation can be found in the following area:

<fx_build_area>/docs/pdf/Build_FXM_UserGuide.pdf

Figure 5: FX Model Creation Inputs

2. Design collateral – Design related inputs, namely Verilog files, SPEF files and SDC file. As
described in section 3, care must be taken to ensure that there are no mismatches between the
Verilog netlist and the DEF files (given to RedHawk-SC). Further, the SDC file and the STA file
given to RHSC must come from the same timing session.

3. Supply noise file – This file is generated using the ‘process_rhsc_voltages’ command in Clock FX,
which internally uses a data mining script in an RHSC session. The output captures the switching

© 2020 ANSYS Inc Page | 6

 events and the supply noise for each clock instance to analyze, in the following format:

INST <instance_name> <is_clock_instance> <cycle_time>

SWITCH <event1_type> <event1_time> <event2_type> <event2_time> ...
PIN <pin_name> <voltage_at_event_1> <voltage_at_event_2> ...

The event type in the SWITCH statements could be one of the following:
- c00 : Clock/input rise, output steady
- c11 : Clock/input fall, output steady
- c10 : Output fall
- c01 : Output rise

There will be a PIN entry for each of the power/ground pins for the cell. Depending on the RHSC
setup, bulk pins may also appear in the generated file with empty voltages. However, these will
not affect the results as long the ideal voltages at each pin are specified correctly. For this
purpose, the script also generates a second file with a file name suffix ‘_pg_domain’ to ensure
that ClockFX and RHSC use the same ideal voltages. The format of this file is

set_user_voltage <inst1>/<pin1> <ideal_voltage>

set_user_voltage <inst1>/<pin2> <ideal_voltage>

There will be entries for all instance/pins in this file. Instructions regarding the specific
commands to use in ClockFX are mentioned in the ‘Flow Setup’ section.

RHSC Inputs
The specifics of the RedHawk-SC run are dependent on the exact requirements of the customer.
However, the commonly used inputs to RedHawk-SC are:

1. LIB file – these are NLPM/NLDM Liberty models capturing the functional and a few electrical
parameters for all cells in the design.
2. APL files – the APL files contain spice-accurate current profiles for all cells, captured over a
sweep of supply voltages and output transitions.
3. LEF/DEF files – these files contain physical layout information per-cell and per-block,
respectively.
4. Tech file – The tech file contains layer-wise information that is required for extraction, in
addition to other parameters such as EM current limit equations.
5. SPEF files – Contains the parasitics for the nets in the design, used for extraction.
6. STA files – This contains all the timing related information for the design, such as clock
definitions, timing windows and slews. This can be generated from commonly used timing tools
– it must be ensured that the SDC file given to Clock FX should be generated from the same
session.
7. VCD/FSDB files – Vectors to annotate activity at instances.

As described earlier, logical consistency is a must when creating the scenario view. Additionally, the
following points should be kept in mind:

- For jitter calculation, at least two edges of the same sense are required. This means the lower
limit on the scenario duration should be calculated as

© 2020 ANSYS Inc Page | 7

 min_scenario_duration = 3 x period_of_slowest_clock

Here, ‘slowest clock’ represents the clock having the lowest frequency for which jitter numbers
are required (this may be different from the lowest frequency clock in the whole design).
- As a rule of thumb, longer scenarios are expected to produce more accurate jitter numbers
(since more edges will be considered in the calculations) at the cost of longer runtimes.
- While creating the AnalysisView, the KeepStats mode must be set correctly depending on the
required mode of operation in ClockFX, as follows:

For ‘dvdfast’ or ‘eff_Vdd’, set KeepStats(‘Medium’, cycle_stats = True)

For ‘dvd_pwl’, set KeepStats(‘Full’)

Common Issues with Input Data

1. Mismatch between STA file and SDC file
a. This will result in instances having a different frequency between the supply noise file
and the ClockFX session – unless specifically overridden, ClockFX will not propagate
beyond this instance.
2. Mismatch between Verilog and SPEF
3. Missing instances in supply noise file
a. This can be verified by checking the number of instances in the supply noise file against
the number of instances available in the voltage information file (suffix ‘_pg_domain’).

4. Flow Setup
Use the starter scripts available in the following area (relative to the FX build) to run the flow:

<fx_build_area>/starter_scripts/ClockFX/

Creating the Clock FX database

© 2020 ANSYS Inc Page | 8

 Figure 6: ClockFX Database Inputs

In this stage, we create the initial Clock FX database that reads in all the input data. The steps are
covered in the ‘build_clkdb.tcl’ script available in the starter scripts directory. You will need to modify
this script to specify the lib database, verilog, spef, and SDC files. It is the fastest if you run this
threaded. By default, ClockFX will run with as many threads as it can get on the machine it is running
on. You can control this by adding "--num_cpus X" on the command line. This part of the run will not
use distributed workers.

This script will build the design database. You only need to rerun this when the design data changes.

$> <grid_launcher_command> clock_fx --num_cpus <num_threads> build_clkdb.tcl

© 2020 ANSYS Inc Page | 9

Creating the RHSC database

Figure 7: RHSC View Creation Schematic

The RedHawk-SC database is to be created using the input files specified in the earlier section. The
commands to be used for creating the various views are covered in detail in the RedHawk-SC user
manual. The main python control script generally takes care of the following:

- Set up pointers to the input data

- Set up the worker distribution
- Handle the database and view creation
- (Optionally) Generate the supply noise file once the AnalysisView is ready

$> <grid_launcher_command> redhawk_sc <control_file.py>

Creating the Supply Noise file

The supply noise file can be created in two ways depending on the preference of the customer.

Using a ClockFX session

If it is to be created within the ClockFX session, the ‘run_process_rhsc_voltages.tcl’ file in the starter
scripts directory contains the necessary commands to generate the supply noise file. This script uses the
design database and the RHSC database to mine the supply data information that is needed to run the
jitter calculations. You will need to modify this script to give enough information so ClockFX can run
RHSC to get the supply data. In particular, the following line should be modified:

process_rhsc_voltages -rhsc_bin RHSC_BIN -output output_file -rhsc_dir

rhsc_tmp -rhsc_db rhsc_db -launcher_command RHSC_LAUNCH_COMMAND -tool
clock_fx -effvdd dvd_type

© 2020 ANSYS Inc Page | 10

 1. RHSC_BIN is the a pointer to the directory containing the ‘redhawk_sc’
binary. For example, ‘/appls/ansys/redhawk_sc/latest/bin/’
2. Output_file is the name of the final supply noise file. Two files will
be created, ‘output_file’ and ‘output_file_pg_domain’
3. Rhsc_tmp is the directory in which the RedHawk-SC session will be run
internally. Please ensure it exists and is accessible.
4. Rhsc_db is the RedHawk-SC database from which the data is to be mined.
If no rhsc_av is specified, the latest AnalysisView available in the db
will be picked up.
5. RHSC_LAUNCHER_COMMAND is the command to be used to launch workers in
the internal RedHawk-SC session. Please refer to the RedHawk-SC manual
for more details.
6. Dvd_type should be one of ‘eff_Vdd’, ‘dvdfast’ or ‘dvd_pwl’. Please
read the previous section for details.
7. (optional) rhsc_av can be used to specify the exact AnalysisView to be
used. Only the view tag needs to be specified.

More details regarding available options can be found by running the command ‘help
process_rhsc_voltages’ from the ClockFX shell.

Using an RHSC session

The files can also be generated using an RHSC session. This flow is useful especially for large fullchip
designs, since the commands can be added to the regular control script given to RedHawk-SC. This flow
eliminates the need for the ‘process_rhsc_voltages’ command in the ClockFX session. The following lines
are to be used (assuming that workers are already available in the session):

>> include(‘<clock_fx_build_area>/lib/clkda-packages/clkda/rhsc_voltages_to_fx.py’)

>> Apply_Effdvd_RHSC(
rhsc_db_str = <rhsc_db_directory>,
options = {
'effvdd_algo' : <supply_noise_algorithm>,
'tool' : 'clock_fx',
'rhsc_av' : <rhsc_analysis_view_tag> or ‘use_latest_view’
},
rhsc_data = <rhsc_data_file>,
out_file = <out_file_name>
)

The inputs required here are the same as those given to the ‘process_rhsc_voltages’ command detailed
earlier. The additional input is the ‘rhsc_data’ key, which is a file containing a list of clock instances for
which supply noise is to be generated. There are multiple ways to generate the file –
- Manually writing out a list of instances
- Using the ‘process_rhsc_voltages’ command with a dummy RHSC db; this will create the file
‘rhsc_data_clock_fx’ in the ‘rhsc_tmp’ dir, with a list of all clock instances.
- Editing a path trace dumped from any timing tool

© 2020 ANSYS Inc Page | 11

 - Using scripts that can generate the file from a ClockFX path trace on a given list of startpoint /
endpoint pairs

Here is a snapshot of the resulting supply noise file – there are entries in this file for every instance, for
every event.

Figure 8: Supply Noise File Snapshot

Setting up the clock jitter run and generating reports

This final step in the flow is covered in the starter script ‘run_clock_fx.tcl’. This is the script that runs
eval_clock to do the jitter calculations. The main commands are:

source <supply_noise_file>_pg_domain

eval_clock -supply_noise <supply_noise_file> -post_command {

set_option show_clock_jitter_keep_exp_open true

show_clock_jitter -path_type summary -jitter_type <jitter_type> -sig 4 -

max 10000 > <jitter_report_filename>
}

- The ‘source’ command reads in the file containing the ideal supply voltages for all the pins in
the design.
- The ‘eval_clock’ command performs the actual jitter calculations. Please ensure that the
proper worker configuration is being used before executing this command. More details
regarding worker setup are available in section 7.
- When ‘eval_clock’ is run, ClockFX creates an internal experiment relative to the current
directory named ‘clk1’ by default. This experiment can be loaded in a future session to run
jitter queries such as ‘show_clock_jitter’.
- All the commands in the ‘post_command’ section will be executed as soon as the eval clock
run finishes.
- The option ‘show_clock_jitter_keep_exp_open’ keeps the jitter results in memory after the
solve is complete – as a result, ‘show_clock_jitter’ commands can run faster. This option
should be disabled in case of memory constraints.

© 2020 ANSYS Inc Page | 12

 - ‘show_clock_jitter’ is a reporting command that creates a text report based on the results of
the jitter calculation. It can be used to show jitter for specific paths, or to generate a summary
report for the whole design. A note on the various jitter types available in ClockFX is available
in section 6.
- More details regarding the inputs to this command are available on running ‘help
show_clock_jitter’ from the ClockFX shell.
- There can be multiple ‘show_clock_jitter’ commands within the ‘post_commands’ section.

Setting up a sanity check run

Clock FX has a feature to perform a sanity check on the input supply noise file to verify the logical
consistency of the RHSC scenario. The key attraction here is that a supply noise file can be generated
based on the RHSC ScenarioView itself using the data mining script, thus eliminating the need to run the
full AnalysisView and the jitter evaluation to check for initial issues with the supply noise. This file can
only be created from an RHSC session, by using the following commands:

>> include(‘<clock_fx_build_area>/lib/clkda-packages/clkda/rhsc_voltages_to_fx.py’)

# The following function can be used to generate a supply noise file using ideal
# voltages only
#
# ‘scn’ -> RedHawk-SC ScenarioView object
# ‘rhsc_data’ -> Path to the rhsc_data file containing a list of clock instances
# ‘out_file’ -> Desired output file name
# ‘time_step’ -> Time step which will be used by the AnalysisView object
# ‘presim_cutoff’ -> RHSC AnalysisView demand current shift (approximate value)
#

>> Create_sanity_check_file(scn, rhsc_data, out_file, time_step, presim_cutoff)

The resulting file can be imported into Clock FX using the following command:
eval_clock -sanity_check -supply_noise <ideal_supply_noise_file>

This will run one edge of jitter using ideal voltages and the switching scenario given in the supply noise
file. Once the run is complete, the Clock FX logs will contain various warnings outlining issues faced with
propagation.

5. Reports and Outputs

Jitter Report Generation
Jitter reports can be generated using the ‘show_clock_jitter’ command as described above. If the
database is available, this command can be run standalone after loading the corresponding experiment.
Typically, the experiment name is similar to:

© 2020 ANSYS Inc Page | 13

 <main_clkdb>.clkdb/<experiment_1>/<experiment_1_1>/clk1

Depending on the type of jitter report required, the exact layout of the jitter report may change, as well
as a few of the headers. However, most of the information remains the same – here is a sample of a
summary report for the full jitter analysis:

Figure 9: Summary jitter report

Here is a sample snippet from a jitter report for a specific path:

© 2020 ANSYS Inc Page | 14

 Figure 10: Path jitter report

Jitter types available in ClockFX

The following jitter types are available for show_clock_jitter:

- Cycle-to-cycle jitter

- Period jitter

© 2020 ANSYS Inc Page | 15

 - Peak-to-peak period jitter

- Phase jitter

- Long term jitter

© 2020 ANSYS Inc Page | 16

 - Duty cycle jitter

More details regarding the various jitter types are available in the document referenced in the
Appendices section.

6. Options in ClockFX
There are various options in Clock FX that affects the way the supply noise file is parsed. These may be
useful in order to deal with common issues such as frequency mismatch between STA and SDC, multi-
clock cells in the path, missing supply noise, incorrect events and so on. Under ideal circumstances, such
errors are not expected – as such, these options should not be used unless there are issues with the
supply noise data.

The following commands can be set to the desired value using the ‘set_option’ command in Clock FX.

1. effective_supply_valid_vcd : true/false – If true then ClockFX assumes the SWITCH supply data
was generated with logically consistent VCD data. If false, then ClockFX will mostly ignore this
information and make up what it thinks is reasonable. Also, if the cycle time mismatches, then it
will be changed to be the fastest clock that ClockFX has. Setting false can also patch up cells
that have impossible arcs across them (like buffers that need inverting arcs) by making them
seed cells. It can also turn data cells into clock cells. It is true by default.
2. effective_supply_worst_min_switch_delay : time – ClockFX requires a cause and effect
condition for a path. This option sets the worst minimum delay for a cell. Setting this to a
negative value means the downstream cell can switch before the upstream cell switches. For

© 2020 ANSYS Inc Page | 17

 example, if this option is set to -10 ps, a receiver that switches (at most) 10 ps before the driver
will still be considered for analysis. This usually occurs with high-drive buffers, where the APL
waveform in RHSC has a long tail. The default value is 0.
3. effective_supply_limit_auto_fixup : true/false – If false then any cell with supply data will
check to make sure the clocked inputs have drivers with supply data. If they do not, then
ClockFX will make up supply data for the driver cell so the clock path can be traversed. If this
option is true, then this will only be done if all the clock inputs are missing drivers with supply
data. It is true by default.
4. effective_supply_filter_on_cycle_time : true/false – when true, the tool filters out clock
propagation based on the cycle time in the supply noise file. For example, if there are two clocks
coming into a combinational instance, the tool will check the cycle time for that instance in the
supply noise file and propagate only the associated clock. When false, the tool will attempt to
propagate all clocks. It is true by default.
5. effective_supply_cycle_equal_threshold : time – this is a threshold within which two clocks
with different cycle times should be treated as equal. The comparison is between the cycle time
obtained from the SDC and that from the supply noise file. For example, if this option is set to 10
ps, an SDC cycle time of 100 ps and a supply noise file cycle time of 110 ps will be considered
equal (as long as they are associated with the same clock). The default value is 0.

7. How do I..?
Decide on the number of workers to use?
The number of workers to use is decided based on the number of edges to be solved and
resource/license restrictions. Ideally, we would want every clock edge to be solved in parallel by
dedicated workers, with each worker having access to multiple threads. Consider the following
calculations, which show the optimal worker configuration:

Figure 11: Worker Distribution in Clock FX

max_num_clock_edges = 2 x (total_analysis_duration)/(period_of_fastest_clock)
num_jitter_workers = max_num_clock_edges
num_jitter_worker_subordinates = num_threads_per_jitter_worker

num_cpu_cores_required = num_jitter_workers * num_jitter_worker_subordinates

© 2020 ANSYS Inc Page | 18

Such a configuration would provide worker optimal distribution at the expense of a higher resource
requirement. The best possible configuration needs to be figured out based on the constraints like
license availability and resource usage restrictions.

Do keep in mind that the worker launch command used should request the desired number of threads
from the grid. The ClockFX worker launch command uses the ‘%numcores’ string to refer to the number
of cores required. For example, in the UGE grid, the switch “-pe pe_smp %numcores” should be added
to the command to request the required number of cores. Further, please ensure that Clock FX is
invoked with the ‘manager’ switch as follows (‘manager_name’ is a file that will be created by Clock
FX):

$> <grid_launcher_command> clock_fx --manager <manager_name> <..other_args..>

The licensing for workers is straightforward – the main session requires one ‘fx_clock’ token, and every
core that is used for solving jitter requires one ‘fx_path_worker’ token. The following options can be
used to control the worker distribution:

- num_workers : This is absolute upper limit on the number of workers

that may be launched.
- num_jitter_workers : Number of edge solve workers. This number should
optimally be equal to the number of edges to solve.
- num_jitter_worker_subordinates : Number of threads per jitter worker.
Each thread requires one ‘fx_path_worker’ token. This option will be
scaled to match the value of (num_workers / num_jitter_workers).

Find jitter at a specific endpoint?

1. Open the ClockFX database and traverse to the experiment where jitter calculation was done
(using the set_database and set_experiment commands). This experiment typically has a name
ending with ‘clk1’.
2. Run the ‘show_clock_jitter’ command, setting the following switches:
a. -to <endpoint_of_choice>
b. -path_type <full, full_clock_expanded, summary>
c. -jitter_type <required_jitter_type>

Find the full path from the clock source to the endpoint?
The following steps can be used to generate a path trace based on the Verilog connectivity, before any
jitter calculation is done.

1. From the main experiment where the input files were read, create a new experiment using
‘create_experiment <exp_name>’.
2. From this new experiment, perform the following steps:
a. Set the option ‘report_unconstrained_paths’ to true
b. Run the command ‘eval_clock -fast’. This is a quick operation that traces out the clock
network without running any analysis.
3. From the same experiment (as in step 2), run the ‘show_timing_path’ command with the
necessary switches to generate a path trace. Use ‘help show_timing_path’ to see the options.

© 2020 ANSYS Inc Page | 19

This is a powerful debug tool to check whether the paths of interest exist before moving on to the
supply-noise based analysis. If step 3 does not return any path, it means that the issue lies at the Verilog
stage itself.

Create a set up for spice correlation?

1. Select a timing path (for example, using one of the endpoints in the worst jitter report)
2. Write out spice decks for each of the four experiments: early rise, early fall, late rise, late fall
3. Run spice on these decks to generate spice outputs
4. Investigate the spice logs (to check the output of the .measure statements)

Here is a sample script you may use to dump the spice decks for a path with endpoint "i1/CP":

set_database ./[Link]
# /jitter is the experiment where eval_clock -supply_noise was performed,
clk1 is internally created
set_experiment ./jitter/clk1

# the following report will give us the experiments to use for early rise,
late rise
show_clock_jitter -rise_to 'i1/CP' -path_type full

# look for something similar to the following lines

# Early Cycle: 1
# Early Experiment: /jitter/clk1/run_0000
# Late Cycle: 10
# Late Experiment: /jitter/clk1/run_0018

exec mkdir -p spice_decks/i1_CP/early_rise/

exec mkdir -p spice_decks/i1_CP/late_rise/

# set experiment to the one corresponding to early rise

# the spice deck will be dumped corresponding to the supply noise received by
this experiment
# this means the methodology (effVdd, dvdfast, dvd_pwl) will be taken care of
by setting the correct experiment

set_experiment /jitter/clk1/run_0000
set_option report_unconstrained_paths true

# use the following lines to dump a spice deck corresponding to this path
# change the experiment and run the same commands to dump a spice deck for
the other edges

set path [ get_timing_path -to i1/Y -path_type full_clock_expanded ]

© 2020 ANSYS Inc Page | 20

write_spice -print_measures -paths $path -directory
./spice_decks/i1_CP/early_rise/ -spice_include spice_include.inc -
spice_simulator hspice

The write_spice command will output the complete spice decks for this path, along with the necessary
measure statements to output the delay and slew for each stage. Futher, there are also accuracy-related
measure statements which give the percentage difference between the spice calculated metric and the
fxm metric. The formula used for this is:

100.0 * ((fxm_metric) - (spice_metric)) / (spice_metric)

The next step is to run spice on the resulting spice decks. You can find them in the 'path1' directory. The
measure statements in the spice decks may be of interest to understand the exact values that are being
reported finally.

In the spice decks directory, you will find the

file ./spice_decks/i1_CP/early_rise/path1/full_path.[Link] . Source this file after setting up the
proper spice environment. Also, make sure that the spice models and subcircuits are included correctly.

After the spice run is complete, check the spice log (for hspice, this is the *.lis file) to see the output of
the measure statements. The important lines to look out for are:

• accuracy_path_delay : This is the percentage accuracy of the cumulative delay for this path. This
is the most important metric to check. We expect to achieve atleast within 5% accuracy for the
delay calc over the full path.
• accuracy_delay_<inst_name>_<pin_name> : This is the percentage accuracy of this stage. The
stage delays of individual stages may vary, but the positive deviations and negative deviations
tend to cancel out.

8. Troubleshooting Tips
Troubleshooting Checklist
1. Verilog and DEF names should match
2. STA and SDC should be from the same session
3. Use ‘eval_clock -fast’ and ‘show_timing_path’ to verify basic path tracing in Clock FX
4. Verify the instance count in the supply noise file
5. Verify the supply noise data – there should be a voltage value for every event
6. If necessary, use the sanity check flow to clear up any propagation issues from RHSC
7. Check the Clock FX logs for messages like:
a. CST:EV*
b. TMG:SCN*

No jitter found at a given endpoint

This situation could arise due to issues either from the Clock FX side (Verilog + SDC), or from the supply
noise information. Use the following steps to root cause such issues.

1. Create (or load) an experiment and run the ‘eval_clock -fast’ command (details in ‘How Do I’
section)

© 2020 ANSYS Inc Page | 21

 2. Check whether the path exists based on Verilog tracing
a. show_timing_path -from clk_source -to endpoint -path_type full_clock_expanded
b. Make sure the option ‘report_unconstrained_paths’ is true
c. If the above query returns no paths, the issue is at the Verilog stage
3. Copy the path trace from step 2 to a file, and load the experiment where eval_clock -
supply_noise was performed
4. Find the breakpoint by binary searching on the path trace – we are looking for the last point in
the path where jitter is available
a. Use the command ‘show_clock_jitter -from clk_source -to endpoint’
5. Once the breakpoint instance is isolated,
a. Check the supply noise file to verify the data for that instance
b. Check the ClockFX logs – most issues will be reported here
6. Contact Ansys AE for further debug if the issue is not understood

Fewer edges than expected

As described in the earlier section on worker setup, the number of edges that should be solved by Clock
FX is roughly twice the number of cycles of the fastest clock which can be accommodated within the
analysis duration. The Clock FX logs will contain lines such as

I:TMG-SJEXP {23.44} Start jitter experiment run_0000. Starting 1 of 10.

Here, the ‘10’ represents the number of edges that Clock FX will solve in this session. If this is lower than
the expected number, it could indicate an issue with the supply noise file or the SDC that is causing
edges to be dropped. Check the Clock FX log for warnings or setup issues – the ‘CST-EVBCE’ message is
especially useful since it lists out all the instances for which there was a problem while setting up the
input data. Keep in mind that by default, all problem instances as well as downstream instances are
dropped from the analysis.

It is very important to eliminate these issues either by fixing the underlying input data or by using the
options mentioned is section 6, so that the expected number of edges will be solved, ensuring the
validity of the jitter numbers.

9. Conclusion
The RHSC-ClockFX solution for jitter analysis is a highly accurate methodology for SoC jitter analysis. The
flow can be easily customized as per the end user requirements and is capable of generating detailed
reports both for specified paths, as well as for the whole design.

© 2020 ANSYS Inc Page | 22