RH-SC Valuechangeview RD Slides: Ansys Confidential and Proprietary

RH-SC ValueChangeView
RD Slides
ANSYS Confidential and Proprietary

Contents
‐ ValueChangeView Background ‐ Chunked Parser – Difference in stats
‐ ValueChangeView Flow ‐ VCV Partitioning of data
‐ VCV Flow ‐ Sample Cases – VCV Debug
‐ ValueChangeView UI ➢ Large memory usage
‐ ValueChangeView Details ➢ No FSDB coverage on instance/net
‐ ValueChangeView Other User Inputs ➢ VCV Chunking – Run stuck/crashed
➢ ValueChangeView RTL NameMapping File UI ➢ Large runtime
➢ ValueChangeView RTL NameMapping Rules UI ▪ Large runtime (non basic/advance namemapping flow)
‐ ValueChangeView settings ➢ Incomplete run / Crash
‐ ValueChangeView NameMapping Flow ➢ Low Coverage
➢ use_basic_name_mapping=True Flow ➢ Logic Signal annotation debug
➢ use_basic_name_mapping=False Flow ➢ Namemap file mapping debug
‐ ValueChangeView Chunking flow ➢ Auto Chunking related Debug
‐ ValueChangeView Design Aware Chunking flow ➢ FSDB verdi related Debug
‐ ValueChangeView User APIs
➢ ValueChangeView API get_coverage
➢ ValueChangeView API get_attributes
➢ ValueChangeView API get_stats
‐ ValueChangeView debug_settings
2
ValueChangeView Background
• ValueChangeView annotates input FSDB/VCD file data to design.

• It is an independent entity which can be used to pass VCD/FSDB processed data inside
applications like scn, swa, npv, scv.
• It is created for allowing flexibility to reuse same vcv db for several applications.
3
Glossary
Term Explanation
var
signal
4
ValueChangeView Flow
5
ValueChangeView Flow Dummy slide (to be deleted) Instances name ==> id
Instance_names
Def files
nets name ==> id
net_names
Lib files create_design_view
Nets => pins connections
Net connections
Lef files
Instance cell type ( seq, Instance types

comb etc )
6 © 2016 ANSYS, Inc. Ma rch 13, 2022

ValueChangeView Flow
1. Design connections independent.
2. Parallel processing for FSDB annotation on dv::instance_names
instances and nets.
3. Faster annotation and finer distribution of
instances and nets based vcv data ds files
Instances annotation Ds file -> instances vcv data
FSDB Read FSDB
vcv::instances_vcd_data
Slice job1
Separate Workers/Machines
FSDB Read FSDB vcv::nets_vcd_data

Slice job1
Ds file -> nets vcv data
Nets annotation
dv::net_names
7 © 2016 ANSYS, Inc. Ma rch 13, 2022

VCV Flow
1. Names Reading
‐ Log :
2. Signals Reading (Value Changes)
‐ Log :
8
ValueChangeView UI
• Specify FSDB/VCD files, Specify slices to be read I and list of instances for which this
FSDB/VCD data is applied
• vcd_files =
[{'file_name' : 'block1.fsdb', 'preamble' : 'sys/clock2_inst',
'instances' : [‘top/block1‘, ‘top/block2’]}, # slice0 and slice1 are applied to the blocks listed here
'time_slices' : [{'slice_name' : 'slice0', 'start_tick' : 0, 'stop_tick' : 250},
{'slice_name' : 'slice1', 'start_tick' : 1000, 'stop_tick' : 2250}]},
{'file_name' : 'block1.vcd', 'preamble' : 'sys/clock2_inst',
'time_slices' : [{'slice_name' : 'slice2', 'start_tick' : 0, 'stop_tick' : 250}],
'instances' : ['']}] # slice2 is applied to top
9
ValueChangeView UI
• vcd_files =
[{'file_name' : 'block2.vcd',
'time_slices' : [{'slice_name' : 'slice3'}], # slice3 covers all time in block2.vcd
'cell' : 'BLOCK’}, # slice3 is applied to all instances of cell “BLOCK”
{'file_name' : 'block1.fsdb', 'preamble' : 'sys/clock2_inst',
'time_slices' : [{'slice_name' : 'slice4', 'start_tick' : 0, 'stop_tick' : 250, 'instances' : ‘top/block3’},
{'slice_name' : 'slice5', 'start_tick' : 1000, 'stop_tick' : 2250 , 'instances' :
‘top/block4’}]}
# slice4 is applied to top/block3 and slice5 is applied to the top/block4
10
ValueChangeView UI
• Create vcv with design view

‐ vcv = db.create_value_change_view(design_view=dv, vcd_files=vcd_files, options=options, settings=settings)
• Specify slices from VCV data to be used, binding with design not required
‐ vcv_data = [{'view' : vcv, 'slice_name' : 'slice0'}, # slice0 and slice2 are applied from
simulation {'view' : vcv, 'slice_name' : 'slice2'}, start time.
{'view' : vcv, 'slice_name' : 'slice5', 'time_delay' : 750 }] # slice5 is applied with time shift
of 750 ps from simulation start time.
• Apply VCV for applications e.g. scn, swa, npv etc.
‐ scn = db.create_scenario_view(design_view=dv, timing_view=tv, … , value_change_data=vcv_data)
11
ValueChangeView UI
• Descriptions of keys in ValueChangeView input
‐ file_name - Path to the FSDB file
‐ instances - Hierarchical instance name for which to apply the file (optional)
‐ time_slices - Time slices to create after FSDB/VCD read, It contains following options
➢ slice_name : Name of the slice to be created
➢ start_time/start_tick : Starting time/tick value to consider for this slice in FSDB/VCD (optional)
➢ stop_time/stop tick : Ending time/tick value to consider for this slice in FSDB/VCD (optional)
➢ instances : Hierarchical instances list for which to apply the slice (optional)
➢ cell : Slice will apply to all instances of this Cell (optional)
‐ preamble - Name prefix to remove from identifiers in the file (optional)
‐ cell - Data will apply to all instances of this Cell (optional)
‐ top_only - Only read signals at top level of hierarchy (optional)
‐ fuzzy_chars - DEF to FSDB/VCD name matching may treat these characters as equivalent if exact match cannot
be found
12
ValueChangeView Details
• ValueChangeView is created based on DesignView

• FSDB/VCD files specified are parsed for the slice duration provided in separate workers
• db created only has data required by design stored for each slice. The data itself is stored
using Ids (Net or Instance/Pin) as keys and waveforms as value, ValueChangeView has id-
based block domain chunked db data.
• No need to parse file multiple times in case of multiple instances.
• Gives flexibility to apply instance prefix on certain slice in single file parsing itself.
13
ValueChangeView Other User Inputs
• RTL NameMapping Files
‐ User can provide pre defined set of RTL => gate mapping via RTL NameMapping File.
‐ VCV can read these files and use defined mapping instead of mapping on its own.
‐ These files can be provided using the settings i.e settings= {‘’namemap” : {“namemap_files” : <>}}
‐ Details in further slides.
• RTL NameMapping Rules
‐ User can provide rules to apply hile mapping a signal name to def instance/net name.
‐ VCV can read these rules and use while name mapping.
‐ These rules can be provided by the settings i.e settings= {‘’namemap” : {“namemap_rules” : <>}}
‐ Details in further slides.
14
ValueChangeView RTL NameMapping File UI
• Specify rtl_namemap_files
‐ rtl_namemap_files = [{'file_name' : 'namemap.txt',
'rtl_preamble' : 'RTLP1.RTLP2',
'gate_preamble' : 'GATEP1.GATEP2',
'delimiter' : '.',
'map_symbol' : '=>',
'instances' : [‘A/B']}]
• Create VCV with rtl_namemap_files
‐ settings = {‘namemap’: {
‘namemap_files’: rtl_name_mapping_files,
‘namemap_rules : rtl_name_mapping_rules}}
‐ vcv = db.create_value_change_view(design_view=dv, vcd_files=vcd_files, settings=settings,

options=options)
15
• Description of rtl_namemap_files options
‐ rtl_preamble (string) This gets removed from RTL entry in namemap file.
‐ gate_preamble (string) This gets removed from Gate entry in namemap file.
‐ delimiter (string) Delimiter used in namemap file.
‐ map_symbol (string) Map_symbol used in namemap file.
‐ Instances (list) Each entry of this list gets added to both RTL entry and Gate entry after removal of
preamble
• Example entry in namemapping file
‐ GATEP1.GATEP2.U3_reg_0_.Z => RTLP1.RTLP2.U3[0]
• Corresponding to this entry
‐ delimiter = . , map_symbol = =>
‐ Instance name = A/B/U3_reg_0_
➢ For successful mapping, This should have a valid instance id in design
‐ fsdb signal name = A/B/U3[0]
➢ For successful mapping, This should match with the input fsdb file signal name after removing preamble,
adding instances, provided in input vcd_files to create_value_change_view
16
• Example entry in namemapping file
‐ GATEP1.GATEP2.U3_reg_0_.Z => RTLP1.RTLP2.U3[0] \\\ Extra heirarchy to both sides
‐ U3_reg_0_.Z => RTLP1.RTLP2.U3[0] \\\ Extra heirarchy on one side
‐ U3_reg_0_.Z => U3[0] \\\ No heirarchy added
• Corresponding gate, rtl preamble set
‐ rtl_preamble' : 'RTLP1.RTLP2' 'gate_preamble' : 'GATEP1.GATEP2'
‐ rtl_preamble' : 'RTLP1.RTLP2' 'gate_preamble' : ' '
‐ rtl_preamble' :'' 'gate_preamble' : ' '
• Corresponding to these entries

‐ delimiter = . , map_symbol = =>
‐ Instance name = A/B/U3_reg_0_
➢ For successful mapping, This should have a valid instance id in design
‐ fsdb signal name = A/B/U3[0]
➢ For successful mapping, This should match with the input fsdb file signal name after removing preamble,
adding instances, provided in input vcd_files to create_value_change_view
17
ValueChangeView RTL NameMapping Rules UI
• Specify rtl_namemapping_rules
‐ Syntax -
'type' : Type of rule, it can be one of following types -
'rtl_to_gate', 'gate_to_rtl', 'define_bus_rule', 'generate_label'
'from' : pattern in rtl/gate name we want to replace.
'to' : desired pattern in rtl/gate name in place of 'from' for successful annotation.
‐ namemap_rules =
[{'type': 'rtl_to_gate', 'from' : "_abc", 'to' : "" },
{'type': 'rtl_to_gate', 'from' : CMRegex("_(ssrrkk|kkrrss)+_"), 'to' : "_" },
{'type': 'define_bus_rule', 'from' : "[%d][%d]", 'to' : "xx%dxxx%dx"},
{'type': 'generate_label', 'from' : "DFS_BLOCK", 'to' : "" }]
• Create VCV with rtl_namemapping_rules

‐ settings = {‘namemap’: {
‘namemap_files’: rtl_name_mapping_files,
‘namemap_rules’ : namemap_rules}}
‐ vcv = db.create_value_change_view(design_view=dv, vcd_files=vcd_files, settings=settings, options=options)
18
• Description of rtl_namemapping_rules
‐ rtl_to_gate
➢ {'type': 'rtl_to_gate', 'from' : CMRegex("_(t)+(r)+(k)+_"), 'to' : "_sample_" }
➢ FSDB signal - A/B/C/instance_tttrrkk
➢ Mapped to instance - A/B/C/instance_sample_reg
‐ gate_to_rtl
➢ {'type' : 'gate_to_rtl', 'from' : "/tvf_0_reg", 'to' : ""}
➢ FSDB signal - intg_lockstep/rccu_active
➢ Mapped to instance - intg_lockstep/rccu_active_reg/tvf_2_reg_
19
• Description of rtl_namemapping_rules
‐ define_bus_rule
➢ {'type' : 'define_bus_rule', 'from' : "[%d][%d]", 'to' : "_regx%dxx%dx"}
➢ FSDB signal - ahbmm_nex_top_0/ahbmm_nsd/ahbmm_nsd_bus_fifo/mem[0][36]
➢ Mapped to instance - ahbmm_nex_top_0/ahbmm_nsd/ahbmm_nsd_bus_fifo/mem_regx0xx36x
generate_label
➢ {'type' : 'generate_label', 'from' : "DFS_BLOCK" , 'to' : ""},
➢ FSDB signal - cgu_cluster_wrapper1/DFS_BLOCK_1_.cgu_cluster_core/clk_sel_sync_reg/data_out
➢ Mapped to instance - cgu_cluster_wrapper1/cgu_cluster_core_1/clk_sel_sync_reg/data_out_reg_27_
20
ValueChangeView settings
• "settings" argument is used to provide many control flags to vcv.

• vcv = db.create_value_change_view(design_view=dv, vcd_files=vcd_files,
options=options, settings=settings)
• “settings” is a dict that has the following keys:
➢ “annotation_type” : Sets the mode for FSDB annotation.
➢ “namemap” : Provides settings for name mapping along with name_mapping files and rules..
➢ “convert_x” : Defines modes to modify unknown toggle state(X) in FSDB to a valid state depending upon the
requirements.
➢ “time_based_chunks” : Used to set time-based chunks for FSDB parsing
➢ “signal_based_chunks” : used to set signal-based chunks for FSDB parsing
21
• “annotation_type” in settings, under settings provided as :

‐ settings = { “annotation_type” = ‘Net/Pin/All’}
• For the “annotation_type” we can have the following values:
‐ “net” : FSDB annotation will be done on nets only
‐ “pin” : FSDB annotation will be done on instances/pins only
‐ “all” (Default value) : FSDB annotation will be done on both instances/pin and nets in separate processes.
• Default behavior : Annotation on both instances and nets
• Default Value : “all”
• Valid values : “net/pin/all”
22
• “namemap” in settings, under settings provided as :

‐ settings = { “namemap” = {“fuzzy_chars”:<>, “multi_bit_delimiters”:<>, “multi_bit_prefixes”:<>, “auto_namemap”:<>,
“namemap_files” : <>, “namemap_rules” : <>}}
• For the “namemap” we pass a dict as a value. That should contain the following keys:
‐ “fuzzy_chars” : Interchangeable characters to consider in def instance name while mapping.
➢ Default Value : ./[]
➢ E.g FSDB signal “A/B/C/name[2]” can be mapped to def instance “A/B_C/name[2]”
‐ “multi_bit_delimiters” :
➢ FSDB signal A lbit 4 rbit 0
➢ Def instance A_reg_0_MB__reg_1__reg__2_
▪ Multibit delimiter here is MB.
➢ Can be set as settings = { “namemap” = {“multi_bit_delimiters” : [‘MB’]}}
23
‐ “auto_namemap” : To control the name mapping behaviour. Can be set to the following modes:
➢ “on” (Default Value) : Enables auto name mapping.
➢ “off” : If set to True, It disables all auto name mapping, only annotation is done using RTL NameMapping File.
➢ “exact” : If set to True, It disables annotation of FSDB signals on instances having name exactly same as signal itself (no fuzzy chars
)
➢ “fuzzy” : Allows fuzzy characters while name mapping.
‐ “multibit_prefixes” :
➢ FSDB signal A lbit 4 rbit 0
➢ Def instance MBIT_A_reg_0__reg_1__reg__2_
➢ Multibit prefix in above register name is MBIT.
➢ Can be set as settings = { “namemap” = {“multi_bit_delimiters” : [‘MBIT’]}}
‐ “namemap_files” :
➢ Used to provide name mapping files containing rtl to gate name transforms.
‐ “namemap_rules” :
➢ Used to provide rules or name map transforms between rtl and gate.
24
• “convert_x” in settings, under settings provided as :

‐ settings = { “convert_x” = <“ignore/fall_toggle/rise_toggle/toggle/retain_x”>}
• For the “convert_x” we can have the following possible values:
‐ “ignore” (Default value):
➢ Ignores X in waveform
‐ “low_state” :
➢ 'x' will be converted as fall toggle.
➢ e.g. 0 -> x = 0 -> 0 1 -> x = 1 -> 0 0 -> x -> x -> 1 = 0 -> 0 -> 0 -> 1
‐ “high_state” (Default value):
➢ X will be converted as rise toggle.
➢ e.g. 0 -> x = 0 -> 1 1 -> x = 1 -> 1 0 -> x -> x -> 1 = 0 -> 1 -> 1 -> 1
‐ “toggle” :
➢ 'x' toggle will be based on previous event
➢ e.g. 1 -> x = 1 -> 0 0 -> x = 0 -> 1 0 -> x -> x -> 1 = 0 -> 1 -> 0 -> 1
‐ “retain_x” (Default value):
➢ X is simply retained in the VCV
25
ValueChangeView NameMapping Flow
• Before 2021R2, Radix Tree search based technique known as basic namemapping used for name mapping as
default.
• Radix tree is created for all the instances/nets of single context and when incoming signal is searched , it returns
the id for mapped instances.
Radix Tree for Sample Instance_names Basic namemapping flow Limitations ->
A •Mapping QOR issues
•Some complex mapping required by customers are not supported by
radix tree name mapping flow . For e.g.
/ Input signal string -> A/B/P •MBFF mappings i.e. mapping signals with instances containing
Output instance -> multiple bits.
A/B_P_reg •Signal -> A/B/MB1 lbit 0 rbit 3
B C •Instance -> A/B/MB1_reg_2_MB1_reg_3_
•“reg_” occurrence with scope names.
•signal - sys/clock2inst/MB1
_ / •Instance -> sys/clock2inst_reg/MB1_reg_1__MB2_reg_3
•All required special mapping needed to support -> link
•High Peak Memory
M_reg •Memory used to create Radix tree is about 10x times
P_reg
_2 of instance_names/Net_names ds file.
ValueChangeView Non Basic NameMapping Flow
• Due the limitations mentioned in previous slides of basic namemapping flow , Default namemap flow has
been changed to "use_basic_namemapper" : False , onwards r21R2.
• New flow has two stages as mentioned below ->
‐ In first stage , we create keys from instance/net names per block in parallel jobs (create_namemap_for_block), store in
per block ds files <block>.hash , <block>.namemap.
‐ In second stage namemap ds files created are fed into VCV parsing jobs (read_vcv_slice_for_chunk)
• Both phases has been explained in next slide.
• All the special type mapping mentioned in the link is supported by the advance/non basic namemapping flow,
which basic namemapping flow was not able to map.
• Around ~30% memory reduction was seen in various customers cases like samsung2020 ,smi turret
ValueChangeView NameMapping Flow
Inst_names/ Keys Creation Hash and Hash and NameMap FSDB
net_names def files NameMap ds ds files FILES
files
Create_namemap_f A.hash, A.hash,
A
or_block A.namemap A.namemap
Create_namemap_f vcv::instances/n
A/B A/B.hash, A/B.hash, FSDB
or_block A/B.namemap A/B.namemap et_vcd_data
parsing
Create_namemap_f A/C.hash, A/C.hash,

A/C
or_block A/C.namemap A/C.namemap
PHASE1 PHASE2
• Create_namemap_for_block job creates keys for each • Ds files created in phase1 job are fed in FSDB parsing
instance/net in in the block. job.
• For each created key, important information like instance id, • During namemapping phase for each FSDB signal,
delimiters etc are stored. key is created which is then searched in Ds
• These containerers for each block is stored in Namemap and files container.
Hash Ds files, which will be used for mapping in later VCV • If key is found, we get all the neccassary data like
parsing phase id, delimiter count etc.
ValueChangeView Chunking flow
29
ValueChangeView Chunking flow
30
ValueChangeView Design Aware Chunking flow
• Non basic/Advance namemapping flow though had various advantages over basic namemapping flow, still has
some performance issues.
• Some issues observed in non basic namemapping flow ->
• VCV High Peak Memory
• High Peak Memory around 120GB seen in MTK testcase
• Loading Multiple Namemap Data Ds files in single job is resulting in high peak memory issue.
• VCV Ds File Contension Issue

• Top block data is required in every parsing job, whose ds file is read.
• Reading those Ds files are resulting in contention thus overall affecting the job runtime .
• To overcome the performance issues , we have created design aware chunking flow.
• Some features of this flow ->
• During non basic name mapping PHASE1 job ds files are created for each block and all those files were feed together in FSDB parsing
. Loading all such ds files in single job leads to high peak memory issues.
• To overcome the same , in design chunking flow whole design name mapping data is divided and chunks are created. Now for each
chunk a separate job is launched for FSDB parsing. (Pictorial representation is made over next slide)
• All the other type of chunking like signal, time and auto time slice chunking remains intact and are not affected by design chunking .
• Design aware chunking can be seen as improvement wrapper placed over advance name mapping flow , thus no impact on QOR is
observed.
• Design chunking flow is automatically invoked and chunks are created automatically based on other paramteres and may vary design
to design.
31
ValueChangeView Design Aware Chunking flow
Hash and NameMap
ds files FSDB
FILES
BLOCK CHUNK 1 BLOCK CHUNK 1
A.hash,
A.namemap FSDB Varidcode FSDB
vcv::instances_vcd
NAMEMAP namemap SIGNAL
A/B.hash, _data
PARSING JOB files READING JOB
A/B.namemap
BLOCK CHUNK 2 BLOCK CHUNK 2

A/C.hash,
A/C.namemap FSDB FSDB
Varidcode vcv::instances_vcd
NAMEMAP SIGNAL
namemap _data
A/B/E.hash, PARSING JOB READING JOB
files
A/B/E.namemap
FSDB
FILES
ValueChangeView User APIs
• Following APIs are supported to extract VCV information at user level
‐ vcv.get_coverage()
➢ Returns Overall FSDB/VCD annotation details on deisgn.
‐ vcv.get_attributes()
➢ Return FSDB/VCD data annotated on queried instance/net.
‐ vcv.get_stats()
➢ Returns FSDB/VCD parsing statistics
‐ vcv.get_time_span()
➢ Returns parse duration for each slice.
33
ValueChangeView API get_coverage
• vcv.get_coverage()
‐ It gives annotation/coverage information per instance.
‐ An instance is considered covered if either one of its output pins or net connected to it is covered.
‐ get_coverage(report_covered_instances=False, report_uncovered_instances=False, report_cell_type=None,
activity_coverage=False)
‐ ARGUMENTS
➢ activity_coverage : Generate coverage report of block whose instances contains some activity/waveform present.
(type=bool, default_value = true)
➢ report_covered_instances : Generate report file containing all the covered instances. (type=bool,
default_value=False)
➢ report_uncovered_instances : Generate report file containing all the uncovered instances. (type=bool,
➢ report_cell_type : List of cell type to include in report.If None all cell type are included i.e. ["comb", "icg", "macro",
"flop", "latch", "pg"] (type=list, default_value=None)
➢ report_per_annotation_type : Dumps breakup of covered instances per annotation type (pin/net) (type=bool,
➢ object_type : Result will be based on provided object type (type=str, default_value=None)
34
ValueChangeView API get_coverage
• vcv.get_coverage()
‐ vcv.get_coverage() example output
35
ValueChangeView API get_attributes
• vcv.get_attributes()
‐ Returns a dict of ValueChangeView attributes for the specified object.
‐ get_attributes(obj, limit_value_change_count=10, slice_name=None, only_data_types=None,
include_data_types=None)
‐ ARGUMENTS
➢ obj : Instance or Net object (type=object, required=True)
➢ limit_value_change_count : Maximum number of value changes to return per signal (type=object,
default_value=10, constraint="int > 0 or None")
➢ slice_name : Returns value change information for slice with specified name, if no slice_name is specified,
attributes are returned for all slices (type=str, default_value=None)
➢ only_data_types : Result will only contain these data types (type=list_of(str), default_value=None, constraint="list
of strings, one of ['fall_toggle_count', 'initial_value', 'logic_signal', 'map_type', 'one_probability',
'rise_toggle_count']")
➢ include_data_types : Result will contain default data types plus these (type=list_of(str), default_value=None,
constraint="list of strings, one of ['fall_toggle_count', 'initial_value', 'logic_signal', 'map_type', 'one_probability',
'rise_toggle_count']")
36
ValueChangeView API get_attributes
• vcv.get_attributes()
‐ Valid data_types and their descriptions:
➢ 'fall_toggle_count' : Number of fall toggles on Instance/Net object)
➢ 'initial_value' : Initial value for waveform on Instance/Net object
➢ 'logic_signal' : Full logic waveform on Instance/Net object
➢ 'map_type' : Type of FSDB to design mapping done for Instance/Net object
➢ 'one_probability' : Fraction of total time for which toggle value one is present on Instance/Net object
➢ 'rise_toggle_count' : Number of rise toggles on Instance/Net object
‐ By default these data_types will be included: ['fall_toggle_count', 'rise_toggle_count'].
37
VCV stats
• Background
>> vcv.get_stats()
38
ValueChangeView debug_settings
• VCV has debug capabilities that can be used directly to extract more data in order to root
cause various issues.
• Debug UI
‐ vcv = db.create_value_change_view(design_view=dv, vcd_files=vcd_files, …,
debug_settings=debug_settings)
‐ ‘debug_settings’ is a dict that can have following valid keys :
➢ debug_mode’ - overall 5 types of modes, detailed in nextslides.
➢ dump_value_changes’ - List (of objects (inst/net)) for which all annotated value changes should be dumped while
parsing itself.
➢ ‘dump_var_idcodes’ - bool, to dump which var_idcode is mapped to which inst/net, and runtime while loading
value changes for each var_idcode
➢ ‘fsdb_load_signals_details’ - bool, to dump messages related to fsdb signal loading, used to check runtime
memory during verdi API calls.
39
ValueChangeView debug settings
• debug_mode – Under debug_settings provided as – debug_settings = { 'debug_mode' : <> }
‐ 'vcv_namemap' - Used to check FSDB signal, it’s mapped instance/net and the type of mapping ( auto,
name map file etc).
➢ Other messages gives information of mapped instance pin with FSDB Signals. (signal,pin_id)
‐ 'vcv_namemap_matched_signals' - This is used to limit messages only to signals that got matched.
Can be used to keep debug log size in check
40
• debug_mode – Under debug_settings provided as – debug_settings = { 'debug_mode' : <> }
‐ 'vcv_rtl_name_map_file' - Exclusively for namemap file data processing related debug. Shows
message for namemapping mapping type.
‐ 'all'- It is used to dump all the information dumped by other mentioned options in addition to some
other relevant data.
41
• debug_mode –
‐ 'vcv_signal_annotation' - It is used to dump various containers used in VCV. Containers are
VCVSingleContainer, VCVQueryDataContainer and ActivityDistributionContainer.
➢ To fetch the result for VCVSingleContainer use the following command -
▪ grep 'RTL PY' latest.gp/Worker* | awk -F'PY ' '{print $2}' | sort > rtl_py
▪ grep 'GATE PY' latest.gp/Worker* | awk -F'PY ' '{print $2}' | sort > gate_py
➢ To fetch the result for VCVQueryDataContainer use the following command -

▪ grep 'RTL_Q_PY' latest.gp/Worker* | awk -F'PY ' '{print $2}' | sort > rtl_q_py
▪ grep 'GATE_Q_PY' latest.gp/Worker* | awk -F'PY ' '{print $2}' | sort > gate_q_py
42
• dump_var_idcodes : debug_settings = { 'dump_var_idcodes' : True/False }
‐ Boolean set to TRUE to dump which var_idcode is mapped to which inst/net, and runtime while loading value changes
for each var_idcode. Default val FALSE.
‐ To dump use the following – grep 'inst/net:' latest.gp/Worker*
• dump_value_changes:debug_settings = { 'dump_value_changes' : [] }
‐ Dumps data of mapped var_idcode with inst/net provided and value_changes for those var_idcodes while parsing.
‐ To dump use the following - grep 'inst/net:' latest.gp/Worker*
‐ To dump use the following - grep 'varid:' latest.gp/Worker*
43
• fsdb_load_signals_details -debug_settings = { 'fsdb_load_signals_details' : True/False }
‐ bool, to dump messages related to fsdb signal loading, used to check runtime memory during verdi API
calls.
‐ var_idcodes ( signal_ids ) which will be read in this job are printed below ( as from var_idcode and last
var_idcode).
‐ Sample message below.
44
• debug_fsdb_chunks
‐ Debug_settings = {'debug_fsdb_chunks' : {'time_chunk' : <>, 'signal_chunk' : <>}}
‐ Used for re-launching one specific chunk, and skipping everything else.
‐ Useful for debug, only 1-2 workers are required for rerunning one chunk only.
‐ For this, we need to find the work job details. Worst job can be tracked through SCLogAnalyzer utility.
‐ After we have the worst vcv job, grep "read_vcv_slice_for_chunk" in that worker. From this message note down the
'time_chunk_index' and 'signal_chunk_index'
‐ To get information on the total chunks created for that slice grep "FSDB chunks created" in logs.
‐ Time/signal chunk index can also be obtained using the slice name. Internally the slice name is appended with time
and signal chunk index. Eg
➢ Slice_name.2.3 => time_chunk_index = 2; signal_chunk_index = 3
➢ Slice_name.2 => time/signal_chunk_index = 2
45
• debug_fsdb_chunks
‐ Case 1 : Only time-based chunking is involved
‐ Case 2 : Only signal-based chunking is onvolved
‐ Case 3 : Both time and signal based chunking is involved
46
Chunked Parser – Difference in stats
• Background
‐ VCV Chunking can show different vcv stats based on chunking parameters
➢ This is expected
• Default Tool behavior

‐ // Why ?
47
VCV Partitioning of data
• Background
‐ Graph based
‐ XP based
• Default Tool behavior
‐ …
48
Sample Cases – VCV Debug
49
Debug [1] Large memory usage
• Issue
‐ One of my vcv jobs is taking very large memory. How to root cause ?
‐ My vcv job is taking 100 GB memory. Could this be reduced ?
• Possible Causes
‐ Very large FSDB file
➢ Sometime FSDB generated from Scn gives issues in parsing
‐ Some other settings related issue.
• Debug Steps // Overview of how to debug
1. Check overall resources, FSDB parameters ( size etc )
2. Check other parameters related to FSDB parsing as mentioned in next section and get back to
RD with the data.
• Details on Debug // Details on how to debug
50
‐ Design related info – num instances, blocks, approx idea of size of blocks ( large blocks ? )
‐ FSDB related info
➢ FSDB size in GB.
➢ fsdbdebug utility can be used for following. (fsdbdebug -info <fsdb_file>)
▪ minimum xtag :
▪ maximum xtag :
▪ scope creation cnt :
▪ var creation cnt :
▪ session count :
‐ Check VCV input
➢ How many FSDB files provided ? How many slices ? Input start, stop time/tick of slices.
51
‐ Check if this run has FSDB chunking parameters used.
➢ Grep "FSDB chunks created" in all Workers. Snapshot below. It will inform us about chunks created per slice.
52
‐ Need to open Worker that exhibited large memory usage – Let's call it Worker1.log
‐ Command name to look for - read_vcd_file_v1 (pre 2021R1) / _read_vcv_slice_for_chunk
(2021R1 Onwards)
‐ Host related info
➢ Check message - "Machine Specs" ( snapshot below for reference )
➢ Next lines would contain ( Note them )
▪ MemTotal
▪ MemFree
▪ SwapTotal
▪ SwapFree
▪ Cpu cores
▪ Processor
53
‐ read_vcd_file_v1 (pre 2021R1)/_read_vcv_slice_for_chunk(2021R1 onwards) related data in
Worker1.log
➢ Memory/runtime stamp at start of command read_vcd_file_v1 (pre 2021R1)
➢ Memory/runtime stamp at start of command read_vcv_slice_for_chunk (2021R1 onwards)
➢ Memory/runtime stamp at message- Reading FSDB names 1
➢ This command will read either one type of the ds files –

➢ PRE r21_R2 -> dv::instance_names.<> or dv::net_names.<>
➢ Post r21_R2 -> vcv::<>.block_name*
54
‐ read_vcd_file_v1 (pre-2021-R1)/_read_vcv_slice_for_chunk (2021R1 onwards) related data in
Worker1.log
➢ Grep all such read_from_ds_file statements (in current command only) and collect. Sample snapshot below -
➢ Pre R21_R2
➢ Post r21_R2
➢ Memory/runtime stamp at message- Reading FSDB signals
➢ Memory/runtime stamp at message – Done Reading FSDB signals

➢ Message – VCV Annotation statistics
55
‐ Contention related info during executing read_vcd_file_v1 (pre 2021R1)/
_read_vcv_slice_for_chunk (2021R1 onwards) in Worker1.log
➢ Check if host is swapping due to possible resource contention.
➢ Messages to check in Worker1.log while executing read_vcd_file_v1 (pre 2021R1) / _read_vcv_slice_for_chunk (2021R1 Onwards)
➢ Please check if lot of these messages are dumped and "swap_used" is increasing ?
➢ If yes, high run time is caused by swapping host.
56
Debug [2] No FSDB coverage on instance/net
• Issue
‐ No FSDB coverage on instance/net, What should I do ?
• Possible Causes
‐ Matching signal not present in FSDB either.
‐ Name Mapping issue ?
‐ Double check on FSDB signal, and VCV debug messages to make sure this is not expected and is a name mapping issue.
‐ Check signal viewer, Does a matching signal to Instance/net exists in signal viewer ?
‐ If yes, rerun VCV with following option
➢ options['value_change_options'].debug_mode = 'vcv_namemap'
➢ vcv =
db.create_value_change_view(dv,vcd_files=vcv_files,.., options=options, debug_signals=[CMRegex("Instance/net_partial
_name*")])
➢ Check following messages in Worker logs
▪ VCV NAMEMAP DEBUG
57
Debug [3] VCV Chunking – Run stuck/crashed
• Issue
‐ My VCV chunking run has unexpected outcome ( long runtime, job stuck etc )
• Possible Causes
‐ Host swapping
‐ Tool issue ?
‐ Resource contention
‐ Setup issues
‐ High number of shadow cell blocks.
‐ More optimized FSDB chunking settings can be used.
• Debug Process// Overview of how to debug
‐ For the purposes of debugging following data needs to be collected :
➢ Resource Configuration
➢ VCV specific information
➢ Worst read_vcd_file_v1 (pre 2021R1) / _read_vcv_slice_for_chunk (2021R1 onwards) command related data.
➢ Worst _create_namemap_for_block command related data.
➢ Rerun of worst job.
58
• Resource Configuration
‐ Total number of machines/hosts used:
‐ General specifications of these machine, following can be checked in the Worker logs.(Configuration is
generally same for all the machines).
‐ Total Number of workers launched

‐ Average workers per machine
59
• VCV and design Specific Information
‐ Time_based_chunks and signal_based_chunks :
➢ Settings = { ‘namemap’ : {‘time_based_chunks’ : <>, ‘signal_based_chunks’ : <>}}
➢ vcv = create_value_change_view(dv, vcd_files=vcv_files, settings=settings)
‐ Options[‘value_change_options’].num_fsdb_api_threads (if provided)
‐ FSDB file size
‐ RHSC Build used
‐ Using Verdi –fsdbdebug –info <fsdb_fie>
‐ Number of blocks in design.
‐ Number of xp partitions.
‐ Number of shadow cells.
60
• Worst “read_vcd_file_v1” (pre 2021R1) / “_read_vcv_slice_for_chunk”
(2021R1 onwards) command related data
‐ Use SCLogAnalyzer/scheduler GUI for getting worst job
‐ Worst job might mean:
➢ Incomplete/stuck job
➢ Crashed job
➢ Job taking longer runtime than expected
‐ Open worker log for the worst job, gather the following:
➢ Host name
➢ Memory, runtime stamp and slice_name “read_vcd_file_v1”(pre 2021R1) / “_read_vcv_slice_for_chunk” (2021R1 onwards)
command started
▪ Pre 2021R1 ->
▪ 2021R1 Onwards ->
61
➢ Start tick:, Org Start tick:, Stop tick:, Start chunk Signal count:, Stop chunk signal count and Memory runtime stamp at message-
Reading FSDB names 1
➢ Memory/runtime stamp at message- Done Reading FSDB signals and next line after that containing ‘Bits’ ‘Rise’ ‘Fall’ info
➢ Job taking longer runtime than expected
62
‐ Please check the above data for 1-2 completed jobs in addition to the worst job for reference
purpose
‐ Contention related data
➢ Check if the host is swapping due to possible resource contention.
➢ Messages to check while executing worst read_vcd_file_v1 (pre 2021R1) /_read_vcv_slice_for_chunk (2021R1 onwards) job in this
worker - “swap_used”
➢ Memory, runtime stamp and slice_name “read_vcd_file_v1” (pre 2021R1) / “_read_vcv_slice_for_chunk “(2021R1 onwards)
command started
➢ To get an idea of why host is swapping
▪ Check how many workers are launched on that host.
▪ Approx idea of memory occupied by other workers
63
• Rerun of the worst job
‐ VCV has capability of relaunching only the job that we are debugging ( worst job ).
‐ We need to find time_chunk and signal_chunk id for worst job and launch VCV with steps mentioned below.
‐ This way we can switch off everything else and check true runtime of worst job.
‐ Since only one job would be launched, a smaller number of workers (2-3) would be required if design view is
imported from previous runs (recommended).
‐ check which chunking options are used in this run.
➢ Vcv.get_options() can be checked, ex.
‐ check ‘slice_name’ of worst job, provided in read_vcd_file_v1 (pre 2021R1) / _read_vcv_slice_for_chunk

command, ex.
➢ Pre 2021R1
➢ 2021R1 onwards
64
‐ VCV has capability of relaunching only the job that we are debugging ( worst job ).
‐ we need to find time_chunk_id and signal_chunk_id for this job
‐ (whichever applicable) for worst job, it can be obtained using ‘slice_name’
‐ if only time_based_chunks is used in value_change_options
➢ time_chunk_id can be obtained by checking the number appended to ‘slice_name’ at end, ex -
➢ ‘slice_name’ : ‘slice.2’ => time_chunk_id = 2
➢ ‘slice_name’ : ‘slice.2.3’ => time_chunk_id = 3
➢ rerun vcv with following argument
‐ if only time_based_chunks is used in value_change_options

➢ signal_chunk_id can be obtained by checking the number appended to ‘slice_name’ at end, ex -
➢ ‘slice_name’ : ‘slice.2’ => signal_chunk_id = 2
➢ ‘slice_name’ : ‘slice.2.3’ => signal_chunk_id = 3
65
‐ if both time_based_chunks and signal_based_chunks are used in value_change_options
➢ time_chunk_id and signal_chunk_id can be obtained by checking the number appended to ‘slice_name’ at end, ex -
➢ slice.2.3 => time_chunk_id = 2, signal_chunk_id = 3
➢ slice.2.3.4=> time_chunk_id = 3, signal_chunk_id = 4
‐ this will launch only the worst job, please check for its new parameters as mentioned in 3) and use them
for conclusion on further change in chunk settings.
‐ This feature is available from 27/09/2019 master build onwards
‐ For R3.Beta1, old UI can be used where “debug_fsdb_chunks” can be passed directly to vcv as an argument
as follows
66
‐ vcv.get_options() => time_based_chunks = ? signal_based_chunks = ?
‐ Is worker throwing error in following command – vcvm.read_vcd_file_v1 (pre 2021R1) /
_read_vcv_slice_for_chunk (2021R1 Onwards) ?
‐ If yes gather following ( from Worker log, starting from "Command started: vcvm.read_vcd_file_v1“ (pre
2021R1) / “Command started: vcvm._read_vcv_slice_for_chunk” (2021R1 onwards) )
➢ 'slice_name':
➢ File Version.....:
➢ DBG<0> Min X............:
➢ DBG<0> Max X............:
➢ DBG<0> Unique Var Count.:
➢ DBG<0> Total Var Count..:
➢ Following messages with time and memory stamps
▪ Reading FSDB names 1
▪ Reading FSDB signals
▪ Done Reading FSDB signals
▪ VCV annotation statistics:
➢ Approximate peak memory during the job.
➢ Last lines from Worker log containing following - mem_used: mem_free: swap_used: swap_free:
67
Debug [4] Large runtime
• Issue
‐ One of my vcv jobs (read_vcd_file_v1 [pre 2021R1] / _read_vcv_slice_for_chunk [2021R1 Onwards]) is
taking very long to complete ?
‐ One of my vcv namemap creation job (_create_namemap_for_block) is taking too long to complete
• Possible Causes
‐ Host swapping
‐ Some issue in input settings ( unexpected preamble or instances entry? )
‐ Some underlying issue in processing.
‐ High number of shadow cell blocks.
‐ Verdi related issue in FSDB reading [Check Debug[9]]
‐ We need to collect some data (more details below) to check if host was swapping.
‐ If yes, a re-run can be fired.
‐ If no, we need to get runtime of some stages in FSDB reading and get back to RD with data mentioned in
detail below.
68
‐ FSDB/Design file related info
➢ FSDB size in GB.
➢ fsdbdebug utility can be used for following. (fsdbdebug -info <fsdb_file>)
▪ minimum xtag :
▪ maximum xtag :
▪ scope creation cnt :
▪ var creation cnt :
▪ session count :
➢ Number of blocks, xp_partitions and shadow cells in the design.
‐ Open Worker log for Worker that executed target slow read_vcd_file_v1 (pre 2021R1) /
_read_vcv_slice_for_chunks (2021r1 Onwards) job for below mentioned information. Let's call it
Worker1.log
➢ Check message - "Machine Specs"
➢ Next lines would contain ( Note them )
▪ cpu_cores
▪ MemTotal
▪ MemFree
▪ SwapTotal
▪ SwapFree
69
70
‐ SCLogAnalyzer output
➢ Run SCLogAnalyzer with command name "read_vcd_file_v1“ (pre 2021R1) / “_read_vcv_slice_for_chunk” (2021R1 Onwards), get
back with similar data as shown in snapshot below.
71
‐ read_vcd_file_v1 (pre 2021R1) / _read_vcv_slice_for_chunk (2021R1 Onwards) related data in
Worker1.log
➢ Memory/runtime stamp at start of command read_vcd_file_v1 (pre 2021R1) / _read_vcv_slice_for_chunk (2021R1 Onwards)
➢ Pre 2021R1 - >
➢ 2021R1 Onwards ->
➢ Memory/runtime stamp at message- Reading FSDB names 1
➢ Memory/runtime stamp at message- Reading FSDB signals
➢ Memory/runtime stamp at message – Done Reading FSDB signals

➢ Message – VCV Annotation statistics
72
‐ Contention related info during executing read_vcd_file_v1 (pre 2021R1) /
_read_vcv_slice_for_chunk (2021R1 Onwards) in Worker1.log
➢ Check if host is swapping due to possible resource contention.
➢ Messages to check in Worker1.log while executing read_vcd_file_v1 (pre 2021R1) / _read_vcv_slice_for_chunk (2021R1 Onwards)
73
Debug [4] Large runtime (non basic/advance namemapping flow)
• Issue
• my vcv namemap creation job (_create_namemap_for_block) is taking too long to complete.
• Possible Causes
• Number of instances for worst job is very large
• High number of blocks .
• We need to get runtime of some stages in namemapping creation and get back to RD with
data mentioned in detail below -
 Worst runtime job . We can get the worst job (_create_namemap_for_block) using SCLogAnalyzer.
 Time stamp between the vcv namemap creation process by getting the following ->
 Grep "begin create_namemap" from Worker*.log
 Grep "finished: vcvm._create_namemap_done" *.log
### Please refer slide no. 25 or this link for non basic name mapping flow implementation - LINK
74
Debug [4] Large runtime (non basic/advance namemapping flow)
• Issue
• my vcv parsing job (_read_vcv_slice_for_chunk) is taking too long to complete.
• Possible Causes
• High runtime in selective loading of ds files during namemapping phase.
• High runtime during searching for signal mapping.
• Please follow basic steps need for debugging high runtime issue in parsing job mentioned from
slide 63-68.
• For worst job , please grep the timestamp for following Debug messages ->
• Grep "Done reading FSDB names" and "Done FSDB name mapping" in Worker logs. If high runtime is due to the
before mentioned namemapping phase, please check the following things -
• In worst job , If we are seeing a lot of time is gone loading vcv::<>.block_name* ds files (selective loading issue) , then use the
following debug setting for manually setting off the dynamic loading of ds file/ loading data in one go -
• Debug_settings = {'namemap': 'load_all_data' : True}, }
• In worst job, if we are seeing a lot of time is comsumed by overall FSDB signals processing/mapping distributed evenly then
there is a possibility that it is due the searching algorithm used for mapping signal key. To confirm the same we need to set off
the searching phase. Please use the following debug setting to do so ->
• Debug_settings = {'namemap': 'lookup' : False}, }
75
Debug [5] Incomplete run / Crash
• Issue
‐ VCV jobs ended midway without any message
• Possible Causes
‐ Host was swapping
1. Check host health
76
Debug [5] Low Coverage
• Issue
‐ vcv.get_coverage returns very low value
➢ If vcv.get_coverage() is giving low coverage as expected you can follow some debug steps to find out reason for low coverage.
• Possible Causes
‐ Mapping issues
➢ There is a possibility that mapping was not properly done.
• Debug Steps Use

‐ vcv.get_coverage(report_uncovered_instances=True)
➢ This will give coverage report with reporting of uncovered instances for a design .
➢ This will give you the idea about instances which you were expected to covered.
➢ Once you find any such instance you can further debug .
77
• Debug Steps // Overview of how to debug (continue )
‐ Once you have doubtful instances, use vcv.get_attributes() this will give you the attributes details
of instance if mapped.
➢ If it gives you attributes details, then there is issue in vcv.get_coverage() code.
➢ If it returns None then get_coverage() is OK and the particular instance might not be mapped.
➢ Please refer slide 22-23 for more information regarding vcv.get_attributes.
78
• Debug Steps // Overview of how to debug (continue )
‐ But still you can further debug and verify it by creating vcv with debug_mode on .
➢ debug_settings = { 'debug_mode' : 'vcv_namemap' }
➢ vcv = db.create_value_change_view(design_view=dv, vcd_files=vcd_files, …, debug_settings=debug_settings)
➢ This will dump FSDB signals and the instance/net matched to it in Worker logs for all FSDB signals.
➢ Grep 'VCV NAEMAP DEBUG:' in Worker logs, sample output below, "fsdb symbol" is signal from FSDB and "Matched Name" is
Instance name which got mapped to it.
➢ If debug messages contain instance and corresponding signal, then vcv.get_coverage has bug, otherwise signal is not mapped at
all, get to the RD team which VCV NAMEMAP DEBUG messages for that signal/
➢ Please refer slide 33-34 for more information about this slide.
79
Debug [6] Logic Signal annotation debug
• Issue
‐ I suspect logic signal annotated for an instance/net is not correct.
• Possible Causes
‐ Bug in annotation flow provided that FSDB input value changes were as expected.
1. Check FSDB value changes first using vcv debug_settings.
2. Most of the cases are explained by 1 itself. If not, revert to RD with data obtained in 1 and full
logic_signal.
‐ Let's say net in question has id <net_id>, use following debug settings and rerun.
➢ debug_settings = {'dump_value_changes' : [net_id] }
➢ vcv = db.create_value_change_view(dv, ....., debug_settings=debug_settings)
➢ If only net has issues, not instance, no need to use annotation_type : 'all'. (use 'net' instead)
➢ 'dump_value_changes' is a list that can take multiple net_ids or instance_ids and dump debug data for
all of them.
80
Debug [6] Logic Signal annotation debug

‐ In worker logs find FSDB wf_id associated with net_id.
‐ Find all value changes read from FSDB for this wf_id. (In same worker log as above)
‐ Value changes present in FSDB are printed in message 'wf:' 'value', 'current_tick'
‐ VCV is adding event for a FSDB value change or not is reflected in message 'add_event wf:'
‐ Above should be consistent with 'logic_signal', if not revert to RD.
‐ Last step is to check whether FSDB input vaue changes read are consistent with verdi.
‐ Use following fsdbdebug utility command to cross check : fsdbdebug -vc -vidcode <code> fsdb_fname
➢ <code> is "varid: " reflected in above debug messages.
81
Debug [7] Namemap file mapping debug
• Issue
‐ Instance/net entry in namemap file is not mapped at all or it is mapped using auto namemap flow.
• Possible Causes
‐ Input settings of namemap file related keys is not correct.
• Next Steps
‐ Ensure correct input settings, refer slide 15, 16, 17.
‐ Rerun with debug settings related to namemap file processing (Details in next slide)
‐ Grep out data in worker logs related to following ( Details in next slide )
➢ Processed namemap file entries
➢ Processed FSDB signal name which is to be mapped.
➢ Actual instance/net name in design which is supposed to be mapped with the signal.
‐ Get back to RD with above data (snapshots and details in next slide).
82
Debug [7] Namemap file mapping debug
‐ Ensure usage of correct settings and inputs for namemap_file (Ref Slide-15)
‐ For getting the debug information, launch the vcv with following debug settings
debug_settings = {‘debug_mode’ : ‘all/vcv_namemap’}
‐ This will print the messages with key ‘VCV NAMEMAPPING FILE DEBUG’. It will give you information on how
namemap_file entries are being processed.
‐ If a signal and def instance pair mentioned in namemapping file was found in fsdb/vcd and design, a “PAIR” message
will be printed else “ENTRY IGNORED” will be printed. (Gate_name = def instance; Rtl_name = signal name)
‐ If a mapping has been successful based on the namemapping file, we will have a ‘VCV NAMEMAP DEBUG’ statement
‘from namemapping file’ for that signal
83
Debug[8] Auto Chunking related Debug
• Issue
‐ Less than expected signal based chunks
• Possible Causes
‐ number of vars in FSDB less than the threshold vars for chunking
‐ Manual chunking settings provided
‐ Multiple slice input provided [Refer Slide 87]
‐ Check setup for manual chunking input settings like
➢ Settings = {'signal_based_chunks' : <>}
‐ Check vars present in FSDB
➢ This can be checked by checking the vcv.get_stats() output for the slice. [22_R2 onwards]
➢ Or we can look up for the key "Total Var Count" in worker logs
84
• Issue
‐ Less than expected time based chunks
• Possible Causes
‐ Parsing duration too small for chunking.
‐ No sessions in the given parsing duration.
‐ FSDB only has one sessions.
‐ Manual chunking provided.
‐ Multiple slice input provided [Refer slide]
‐ Second pass VCV in auto_time slicing flow
‐ Check total sessions in FSDB
‐ Check sessions in FSDB parsing duration
‐ Check setup for manual chunking and auto slicing mode
85
‐ Check chunking details for a slice by grepping "FSDB chunks created" in worker logs
‐ To check the total sessions in FSDB grep "Total fsdb session count"
‐ To check total sessions in parsing duration grep "Total FSDB sessions:"
‐ Number of time chunks cannot exceed the number of available sessions in the parsing duration.
If it happens, we might get lesser number of time chunks created than expected.
‐ Time chunks are not made in second pass VCV for auto_time slicing flow, instead auto slices are
created at this stage. Hence zero time chunks will be reported.
‐ If multiple slices are involved, we have to maintain same chunking mode across all input slices.
Which might also affect the number of time chunks created. [Refer next slide for details]
86
• Issue
‐ Auto chunking parameters different from expectation for multi slice input
• Possible Causes
‐ For better application, VCV internally tries to maintain chunking mode consistent among all input
time slices.
‐ Chunking getting disabled as one of the slice provided was from .vcd
‐ Get and compare actual and applied chunking parameters. For doing this grep "FSDB chunks
created".
87
• Issue
‐ Auto chunking parameters different from expectation for multi slice input
• Possible Causes
‐ For better application, VCV internally tries to maintain chunking mode consistent among all input
time slices.
‐ Chunking getting disabled as one of the slice provided was from .vcd
‐ Get and compare actual and applied chunking parameters. For doing this grep "FSDB chunks
created".
88
‐ Case 1 : atleast one of the slice has no time chunks upon auto chunking
➢ To maintain consistency on chunking mode across slices, in this case time-based chunking is disabled for all other slices as well,
before applying. Which means slices with computed time chunks, will be overiiden and time chunking will be disabled on them as
well.
‐ Case 2 : atleast one of the slice has signal based chunks upon auto chunking
➢ To maintain consistency on chunking mode across slices, in this case signal-based chunking is applied for all other slices as
well, before applying. Which means slices with no signal chunks, will be overidden and atleast two signal chunks are applied to
them as well.
‐ Case 3 : atleast one of the slice comes from .vcd file

➢ As there is no support for time based or signal based chunking for .vcd files. Hence chunking is disabled for the slices coming from
vcd files.
➢ Therefore, to maintain consistency on chunking mode, both time based or signal based chunking will be disabled for all other
slices as well, irrespective of FSDB or vcd.
89
Debug[9] FSDB Verdi related debug
• Issue
‐ VCV is stuck or having significantly large runtime.
‐ Value changes not getting read properly inside vcv
• Possible Causes
‐ It is verdi internal issue.
‐ Invalid/corrupt FSDB
‐ Inconsistency in verdi versions between FSDB file and RHSC
• Debug Steps Use
‐ Regenerating the FSDB
‐ Making sure the file and RHSC are of the same Verdi version.
‐ Loading and reading the FSDB through Verdi demo utility.
90
• Details on debug
‐ Make sure FSDB file version and RHSC verdi version matches.
➢ RHSC verdi version across all releases can be found here Value Change View Wiki
‐ Check if the FSDB in invalid or corrupted
➢ Look out for the following warning in the worker logs
➢ If such warning is found, regenerate the FSDB. One way to do this, is to convert the FSDB to vcd then convert back to FSDB using
the appropriate Verdi version.
91
‐ We first need to narrow it down if it is Verdi being the culprit for high runtime while reading
signals.
‐ For that we need to launch the worst runtime job (Debug[3] Slide 63), with the following debug
settings
➢ debug_settings = {'debug_fsdb_chunks': {'time_chunk': <worst_time_chunk_id>, 'signal_chunk': <worst signal chunk id>},
'value_changes_processing' : False}
➢ This should not require much worker, 1-2 would be enough.
➢ This will make sure VCV just reads FSDB signals does not process it further, hence if the run gets stuck here as well, then we can
conclude that verdi is taking long time to read FSDB signals.
➢ Once it is concluded that high runtime is caused by verdi reading the FSDB signals. We can confirm this by running and reading the
FSDB using Verdi outside the RHSC environment. This can be done by running the verdi demo utility provided by RD.
‐ For running the verdi demo utility we need the following information
➢ FSDB in-house
➢ Var id range to be read (start var id – stop var id) in worst job.
➢ Parsing duration (start tick – stop tick) in worst job
92
‐ Using the Verdi demo utility
➢ Untar the demo utility provided by RD.
➢ This will create run directory containing "fsdb_reader" exuctable and README file. Go through the README for sample outputs
and instructions.
➢ set LD_LIBRARY_PATH to verdi lib inside RHSC release build path or customer verdi area.
➢ After that run the following command in your shell
▪ fsdb_reader <path_to_FSDB_FILE> <start_tick> <stop_tick> <start_varid> <stop_varid>
➢ To get the required start_tick and stop_tick, look for "Start tick" and "Stop tick" keys in the Worker log containing single chunk
rerun.
➢ For getting the var_id range -
▪ Use single chunk rerun setup with "value_changes_processing" : False.
▪ Add following to debug_settings - 'fsdb_load_signals_details' : True, and rerun.
▪ debug_settings = {'debug_fsdb_chunks': {'time_chunk': <worst_time_chunk_id>, 'signal_chunk': <worst signal chunk
id>}, 'value_changes_processing' : False, 'fsdb_load_signals_details' : True}
▪ Look for messages pasted in snapshot above in Worker log, once they are dumped, kill the run and use the values. E.g. for above sample message
you can use var id range as 1 -> 58241.
93
94
95
96

RH-SC Valuechangeview RD Slides: Ansys Confidential and Proprietary

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

RH-SC Valuechangeview RD Slides: Ansys Confidential and Proprietary

Uploaded by

Copyright:

Available Formats

RH-SC ValueChangeView

ANSYS Confidential and Proprietary

• ValueChangeView annotates input FSDB/VCD file data to design.

Instance cell type ( seq, Instance types

6 © 2016 ANSYS, Inc. Ma rch 13, 2022

FSDB Read FSDB vcv::nets_vcd_data

7 © 2016 ANSYS, Inc. Ma rch 13, 2022

• Create vcv with design view

• ValueChangeView is created based on DesignView

‐ vcv = db.create_value_change_view(design_view=dv, vcd_files=vcd_files, settings=settings,

• Corresponding to these entries

• Create VCV with rtl_namemapping_rules

‐ vcv = db.create_value_change_view(design_view=dv, vcd_files=vcd_files, settings=settings, options=options)

• "settings" argument is used to provide many control flags to vcv.

• “annotation_type” in settings, under settings provided as :

• “namemap” in settings, under settings provided as :

• “convert_x” in settings, under settings provided as :

Create_namemap_f A/C.hash, A/C.hash,

• VCV Ds File Contension Issue

BLOCK CHUNK 2 BLOCK CHUNK 2

➢ To fetch the result for VCVQueryDataContainer use the following command -

‐ To dump use the following - grep 'varid:' latest.gp/Worker*

‐ Case 2 : Only signal-based chunking is onvolved

‐ Case 3 : Both time and signal based chunking is involved

• Default Tool behavior

➢ Memory/runtime stamp at start of command read_vcv_slice_for_chunk (2021R1 onwards)

➢ Memory/runtime stamp at message- Reading FSDB names 1

➢ This command will read either one type of the ds files –

➢ Memory/runtime stamp at message- Reading FSDB signals

➢ Memory/runtime stamp at message – Done Reading FSDB signals

‐ Total Number of workers launched

▪ 2021R1 Onwards ->

➢ Job taking longer runtime than expected

‐ check ‘slice_name’ of worst job, provided in read_vcd_file_v1 (pre 2021R1) / _read_vcv_slice_for_chunk

‐ if only time_based_chunks is used in value_change_options

➢ 2021R1 Onwards ->

➢ Memory/runtime stamp at message- Reading FSDB names 1

➢ Memory/runtime stamp at message- Reading FSDB signals

➢ Memory/runtime stamp at message – Done Reading FSDB signals

• Debug Steps Use

➢ Please refer slide 22-23 for more information regarding vcv.get_attributes.

• Details on Debug // Details on how to debug

‐ To check total sessions in parsing duration grep "Total FSDB sessions:"

• Details on Debug // Details on how to debug

‐ Case 3 : atleast one of the slice comes from .vcd file

You might also like