SpyGlass® CDC Training

Challenges in Hierarchical Convergence

L2016.06-SP2-T0116

18th Jan 2017

© 2015 Synopsys, Inc.

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

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

© 2015 Synopsys, Inc.

Hierarchical Flow
• Complexity Continues to Follow Moore’s Law
– Need for faster turnaround time at SoC level Motivation
– Changes in one IP should not force full design Verification
• Distributed Teams
– Teams scattered around the world across multiple time zones
– Automation required to enable effective communication across teams
• Flat SoC Verification may Produce Too Many Violations to Review at Once
• Exhaustive Verification at IP Level
– Minimize verification at SoC level
• Reduce Turn Around Time to Verify Late Stage Design Changes

• Two Flows for Hierarchical CDC Verification

– Bottom-up Hierarchical Verification
Process
– Top-down Hierarchical Verification

© 2015 Synopsys, Inc. Synopsys Confidential Information

 Hierarchical SoC CDC Results
Runtime [Hrs] Memory GB # Violations

Flat Hier Flat Hier Flat Hier

Design Size #
[Gates] Blocks

Graphics chip 1.4 B 14 96 2 1300 100 >1M 346

Networking 155 M 12 20 0.5 300 30 6678 2
D-TV chip 110 M 26 33 1 400 50 1289 102
Mobile phone 100 M 9 8 0.5 200 40 1687 200

• Multiple Runs for Top Level Verification per Day

• Huge Productivity Gain Because of Reduced Number of Violations at Top Level

Divide-n-Conquer Approach to CDC Verification

© 2015 Synopsys, Inc. Synopsys Confidential Information
 Bottom-Up Hierarchical
• Enables IP-Based SoC Design Methodology TOP
• Block Level Ownership B3 B4
– Block level verification  Block is CDC clean
– CDC clean blocks  Abstract models
• Quick Validation of Constraints / Abstract Model Attributes
Among Blocks and Top Level
B1 B2
• Top Level Verification to Verify CDC Issues Across Blocks

• Known Limitation with abstract models:

– No Formal (Port information doesn’t contain
functionality)
– Some constraints are currently not verified.
– reset_filter_path (Used for RDC and Async Resets)
– Clock -period/-edge (Used in Formal).
– Source Qualifiers (Used to describe CDC control logic)

© 2015 Synopsys, Inc. Synopsys Confidential Information

What is a SpyGlass Abstract Model?

• An abstract model is:

– A text (sgdc) file extracted from the:
– RTL
– users inputs (Clocks, Resets, Ports, Constraints)
– generated outputs after running CDC.
– The abstraction is defined only on the ports of the module.
• The inputs on an abstract model form the “assumptions” that were used to generate the model.
– These “assumptions” will be “validated” in the context of the hierarchy to insure they are valid.
• The outputs are derived from the RTL and constraint propagation so that outputs can be verified
or validated against whatever these ports drive.

© 2015 Synopsys, Inc.

 Example of AUTOMATIC Block Abstraction

Input ports are Abstracted automatically

abstract_port –ports IN1 –clock C2

Clock –name C1 (User Defined)

Clock –name C2 (User Defined)

abstract_port –ports IN2 –clock C1

abstract_port –ports IN3 –clock C2

abstract_port –ports IN4 –clock SG_VCLK_1 –combo

no –combo_ifn C2

No abstract-port constraint required as no relation with

clock.

© 2015 Synopsys, Inc.

Example of AUTOMATIC Block Abstraction

Output ports are Abstracted automatically abstract_port –ports O1

–clock C2
-related_ports IN1

abstract_port –ports O2
–clock C2
–sync inactive –from C1 –to C2
–names “<>.sync1”

abstract_port –ports O3
–clock C2
–sync active –from C1 –to C2
–seq yes
–names “<>.sync2”

abstract_port – –ports O4
–clock C1
–combo yes –related_ports IN2
abstract_port –ports O4 –path_logic combo –related_ports
IN5
set_case_analysis -name foo -value 0
abstract_port -ports O5 -related_ports IN5 -path_logic combo

© 2015 Synopsys, Inc.

 What is inside of an abstract models?
• Breakdown/Contents of an abstract model file.
• How does it relate to specific checks in the validation
• Parameter section/missmatch.

#HEADER
abstract_file -version 5.1.0 -scope cdc #What Product can this abstract file be used with (cdc/lint/dft/etc.)
current_design "dstBlk" -param { DW=7 } #Used to only apply this abstract to a module that matches the parameters
##########################################################
# abstract_port constraints (FEED THROUGHS) # Used only for Clock/Domain Propagation
# clock constraints (OUTPUT CLOCKS) # Catch Missing Clocks or wrong domain clocks
# set_case_analysis constraints (OUTPUTS) # Catch Missing or wrong set_case_analysis
# reset constraints (OUTPUTS) # Catch missing or wrong –sync/-async -value
# quasi_static constraints (OUTPUTS) # Catch missing quasi_static
# abstract_port constraints (OTUPUTS CLOCKED) # Catch data ports on wrong domains, -sync, -combo mismatches
#Adding -combo no to abstract_port defined at input port # (Additional Informatiton for Inputs to catch combinational logic on inputs)
#If it invloves a synchronized control crossing #
# qualifier constraints (OUTPUTS) # Qualifier Missing
# virtual clock constraints (OUTPUTS) # Definition of NEW clocks inside of blocks
# cdc_attribute constraints (OUTPUTS) # cdc_attributes to get propagated
# define_reset_order constraints (OUTPUTS) # define_reset_order mismatches.
# Inferred abstract_port constraints (INPUTS) # Auto Inferred Abstract ports to catch ports on wrong domains –sync -combo
# block interface constraints (INPUTS/OUTPUTS) # SV block interfaces parameters and direction of ports
abstract_block_violation -name checkCMD_existence -sev ERROR -waived_count 19 -is_builtin #Violations reported/waived during block level
abstract_block_violation -name Ac_clockperiod01 -sev WARNING -count 2 #SoC owner can tell if the block was run clean.
block_file_decompiled_start #Input Constraints used to generate abstract model.
clock -name "dstBlk.dstBlk__ctlDt_clk" -tag SG_AUTO_TAG_2 -domain domain1 #Used
clock -name "dstBlk.cmnDst__clk" -tag SG_AUTO_TAG_1 -domain domain0
reset -name "dstBlk.cmnDst__reset" -value 1 -sync
reset -name "dstBlk.dstBlk__ctlDt_reset" -value 1 -sync
block_file_decompiled_end
© 2015 Synopsys, Inc.
Checks done during reading of an abstract model

dstBLK
Abstract was read

srcBLK
Abstract was NOT
read and was run
FLAT

The Reason srcBlk

was not used.

srcBlk was Dirty.

It had violations in it.

FATAL errors due to

using a parameters
that were wider than
© 2015 Synopsys, Inc. actual design..
Mapping CLK domains inside blocks to top level domains.

• All information inside of an abstract model is LOCAL to that block.

• There is not mapping between any names/clocks/domains/etc between block and clock.
– This is just like a module in Verilog.
– All information in a Verilog model is local to that model.
– In a Verilog Model when you create an instance, you have to specify the connections.
• In an abstract model, based on your connections, then clock/domain information gets mapped.
• A top Level clock called CLK1 connects to a module instance clock called CK.
– So Instance u1.u2.u2.CK gets mapped to top level clock CLK1
• A Block Level Data port is either inferred or an abstract_port constraints assigns it to the clock
domain defined in the abstract model.
• A Block Level Data port on a virtual clock is assigned to the top level clock driving it.
• All clock/domain mapping information is reported in the SGDC_abstract_mapping01 rule.
– This is unique to each instance of an abstract model.

© 2015 Synopsys, Inc.

 Block/SoC Clock Mapping done by Topology
• Essential to Block Top Connectivity Validation
– Reported by rule SGDC_abstract_mapping01
• Automatically infer correspondences between block and SoC clocks
– N Top clocks to be matched with M block clocks
– Some clocks may be internal to the block only, some clocks may exist in top only
– Conflicts may arise which will point to design/connectivity issue
• SpyGlass CDC will map top/block clocks with minimum conflicts

BlockPort Top Mapping c1 ca1

cb1
Clock ca1 Clock c1 ca2 CLK
GEN
Data ca2 Clock c2
Clock cb1 Virtual Clock X
vcc3
Clock cc2 Clock C2 c2 cc2 PLL
Clock cc1 C3
c3
cc1
© 2015 Synopsys, Inc.
 Virtual Clocks Interpretation
• A virtual clock is a clock which does not correspond to a block level input
port.
• Usage of virtual clocks
– Block assumption on “any clock” coming from the top (bottom up flow)
– If a block port is synchronized inside the block, define it with virtual clock
– During block validation checks, no domain mismatch is reported with such
data port
– Internal clock for a block (block abstraction)
– An internal clock of a block reaching an output port is considered as virtual
clock for the SoC
– External clock not reaching to a block (top down flow – dual of case 1)
– In top-down migration, if a flop clocked with an external clock reaches to a
block port, the constraint generated for a block port refers to a clock which
is non-existent for a block and hence, treated as virtual clock

© 2015 Synopsys, Inc.

 Mapping Virtual Clock
“Viewed from the block”, port P1 can
accept any clock domain
abstract_port –name P1 –clock vck1

P1 Vck1
Ck1

Ck2
P2 bck2

• Block clock bck2 is mapped to the top clock Ck2

• Block virtual clock Vck1 is mapped to the top clock Ck1

© 2015 Synopsys, Inc.

 Unmapped Virtual Clocks
“Viewed from the block”, port P1 &
P2 can accept any clock domain
abstract_port –name P1 –clock vck1
abstract_port –name P2 –clock vck1

P1 vck1

Ck1
P2 vck1

Ck3
P3 bck2
Ck2

• Block virtual clock vck1 cannot be mapped to the two different top
clocks Ck1 & Ck3
– Use different virtual clock name for proper mapping to the another top
clock
© 2015 Synopsys, Inc.
abstract_port –name P2 –clock vck12
SGDC_abstract_mapping01 Rule

• This is for the srcBlk. You can see each REAL clock constraint
• You can also see the bottom line is a “virtual” clock that was defined by an abstract_port –
clock constraint.
• The virtual clocks get mapped to the domain driving the port.

© 2015 Synopsys, Inc.

Workflow Definitions (Bottom Up vs. Top Down)

• Bottom up flow:
– Lower Level modules constraints are created and verified and then abstracted.
– These lower level abstracts are then instantiated in a higher level module and validated.
– Can be significant number of validation issues depending on block level’s understanding of SOC domains.

• Top Down Flop

– Top Level Constraints are “pushed” down to create block level constraints.
– The block level constraints are then used to verify the block and create an abstract.
– The lower level abstracts are then instantiated in a higher level module and validated.
– The number of validation issues are usually very small since the actual top level constraints are getting used to
so there are usually only a small number of validation issues.
– These get introduced when the user solves block level CDC issues by making changes or adding additional constraints.

© 2015 Synopsys, Inc.

Bottom Up Workflow

• Clocks and Resets are fundamental to good analysis.

• To converge on issues that could be caused by introduction of abstract models
– First run the block flat and insure the cdc_setup_check is clean.
– Then we will start adding abstract models and any new violations can be assumed to be related to the
abstract models.
– Abstract model might not capture clearly what the RTL did. (Clock Propagation in feed throughs)
– Abstract Model may not have been generated with correct RTL
– Abstract model’s Constraints may not have been correct.
– Problems with Parameterization
– Possible bugs in abstract models.

• During cdc_setup_check goal, we will limit ourselves to only the “Clock” and “Reset” checks.
– The other validation checks (data domain, case_analysis, quasi_static, combo logic) will considered in
the cdc_verify_struct goal

© 2015 Synopsys, Inc.

How IP generates an abstract model

• Generation
– The rule Ac_abstract01 generates the abstract model.
– It is contained in the cdc_verify_struct goal, so every time you run the goal the model is created.
– If there are NO Verilog module parameters defined in the project file, then the abstract model will
contain a line saying it was generated with the default Verilog parameters.
– If there were Verilog parameters defined in the project file, then the Verilog parameters will get added
to the abstract model so that it will automatically get used when the Verilog parameters match the
Verilog instance.

• Consumer of abstract model

– The sgdc –import constraint reads the abstract model.
– It get’s applied to all modules where the names match.
– If abstract was generated using “default parameters”, then it gets applied everywhere.
– If abstract used specific parameters, then it will only apply the matching model.

© 2015 Synopsys, Inc.

 How to read an abstract model
• This is done through an SGDC constraint called “sgdc –import block block.sgdc”
The syntax of the sgdc constraint is as follows:
Usage 1
sgdc -import <block-name> <SGDC-file>
-instance_list <instance-list>
-bbox_instance_list <instance-list>
• The default is to apply the block.sgdc to all instances of the block
– If the abstract model was generated using “default parameters”.
• If the abstract model was generated using parameters, then it can only be used on instances
that match the parameters.
• The –instance_list is only necessary if you want to apply a specific abstract to a specific
instance. This is done for modules where the set_case_analysis could change the behavior.
• The –bbox_instance_list will force the instance to be a bbox to avoid fatals or bad analysis.
– This allows for Instance Based Black Boxes (set_option stop) applies to modules.

© 2015 Synopsys, Inc.

Adding Abstracts and maintaining Setup Quality

• Due to the reduction of logic during abstraction and user assumptions could be wrong, their
can be errors in the block level runs.
• Most importantly are insure the clocks and resets are correct.
• Sometimes these problems are hard to resolve if ALL abstracts are introduced in a single run.
• Since you are only have access to the port level constraints it can be difficult to understand
why an output of block might be missing a clock or have multiple clocks on them.
• There are multiple ways to solve:
– You can tell SpyGlass to NOT blackbox when using the abstract models. This way a schematic is
available to trace signals. Unfortunatly the schematic is dead (there is no debug data) available
because only the schematic was left, but no analysis was done on it.
– Another way is by opening a separate GUI on the block that you have questions about. That way you
have full analysis of all the debug data.
• Another option to simplifying that the abstracts are not introducing problems is to only add 1 or
2 abstracts at a time. Resolve any clock or reset issues and then add more abstracts.

© 2015 Synopsys, Inc.

Checking Quality of Abstracts.

• Dammy, Are you talking about the Ac_abstract

© 2015 Synopsys, Inc.

Rule Ac_abstract_validation02: checks hierarchical blocks
• Rule is ONLY checking the “destination” block (inputs).
• Violation is reported at mismatches between TOP and BLOCK.
– Message doesn’t indicate where TOP level attribute comes from. You need schematic to see that.

© 2015 Synopsys, Inc.

 Validation Checks of abstract block inputs
Mismatch Check Bugs Found Possible Flat violations
Clock SoC connectivity issue or Missed CDC violations Synchronization, Glitch,
in block due to missing/erroneous clocks on Convergence
block ports.
Same Block Clock Domain Bad SoC connectivity or missed crossings due Synchronization, Glitch,
to bad block constraint Convergence
Case Analysis Wrong Mode (set_case_analysis) on block / Synchronization, Glitch,
Over constrained block  missed Violations in Convergence
blocks
Quasi static Missed Violations in Block if port is assumed Synchronization, Glitch,
quasi_static when in SoC it is not quasi_static Convergence
Data Path Domain SoC connectivity issue or missed Clock Domain Synchronization, Glitch,
Crossing (Top Level Domain is different than Convergence
block level domain)
Combo Check Common inter-block connectivity and design Glitch
issue
Qualifier Convergence missed in block or noise in blocks Synchronization, Convergence
due to missing synchronizer or wrong qualifier
on ports
Reset SoC connectivity issue or Missed Reset Checks Reset synchronization, glitch,
in blocks or inverted active reset values. convergence
Virtual Clocks SoC connectivity issue or Missed CDC’s across Synchronization, Glitch,
© 2015 Synopsys, Inc.
blocks when some top clocks not used in blocks Convergence
Clock Mismatch

• Problem Description
– Block verification for srcBlk missed declaring clock “my_hanging_clk_viol”
– Top Level missed declaring a top level clock on “my_missing_clk_vil”
• Results of Ac_abstract_validation02 Reports 2 violation
– srBlk is missing clock constraint on pin my_hanging_clk_viol
– srBlk is missiong top level clock constraint on pin my_missing_clk_viol
• Conclusion:
– If connectivity issue, SoC owner to fix, if block assumption is wrong, Block owner to fix

© 2015 Synopsys, Inc.

 Same Block Clock Domain Mismatch
• Problem Description
– Block owner of srcBlk incorrectly defined clocks my_clk_domain_mismatchA and B in the same
domain (synchronous)
– Or in the top the clocks are actually in different domains.
• Results of Ac_abstract_validation02
– Reports violation of “Same Block Clock Domain” type mismatch
• Conclusion
– Either SoC connectivity/constraint issue or block assumption problem

© 2015 Synopsys, Inc.

 Virtual Clock Mismatch
• Problem Description
– Virtual Clock Mapping ran into an issue
– 2 Block Level Ports with SAME virtual clock
connect to different top level clocks
• How to fix.
– Put Block Level virtual clock on unique domains.

#TOP Level SGDC #Block Level SGDC

abstract_port -ports input1 -clock clock1 abstract_port -ports in1 -clock VCLK
abstract_port -ports input2 -clock clock2 abstract_port -ports in2 -clock VCLK

© 2015 Synopsys, Inc.

Simple Data Synchronizer (Split 1)
• Port d_in of Block RX shows up as a data mismatch.
• Very Common because Crossing between blocks doesn’t require meeting timing
• Qualifier is in SAME block as destination.

abstract_port –ports d_in --clock rx_clk Either block could

d_out d_in
A1 be flat or abstracted
A1[7:0]
D1 and it should work
Mismatches with tx_clk?
Associate both ports with a VIRTUAL CLOCK either way.

SpyGlass will report

abstract_port –ports r_in -clock rx
differently
r_out r_in
depending on if
destination is flat or
req M1 S1 abstracted.

TX RX
rx_clk
tx_clk
© 2015 Synopsys, Inc.
Simple Data Synchronizer (Split 2) (No block level violations)
• Port d_in of Block RX shows up as a data mismatch.
• Yellow Clock can be completely independent clocks.
• Qualifier is in a different block, so it requires a qualifier constraint.
#abstract_port –ports d_in -clock rx_clk
#Mismatches with tx_clk!
#abstract_port –ports d_in –clock VCLK
d_out d_in
Either block could
A1 be flat or abstracted
A1[7:0]
D1 and it should work
either way.

SpyGlass will report

abstract_port –ports r_in -clock rx
differently
r_out r_in depending on if
#abstract_port –ports d_in -clock rx_clk destination is flat or
req M1 S1 #Qualifer Mismatch
abstracted.
abstract_port –ports r_in -clock rx_clk
-sync active –from VCLK –to rx_clk

TX RX
rx_clk
tx_clk
© 2015 Synopsys, Inc.
 Data Path Domain Mismatch (Clock Domain Crossings)
Correcting data domain at block
input
• Problem Description port and doing analysis again will
– Abstract Model has BLK_DATA on the BLK_CLKB domain. resolve the mis-match.
– But, it is driven by the TOP_CLKA domain.
– Either block owner assumed incorrectly or SoC connectivity problem TOP

• Solution TOP_DATA(TOP_CLKA)
BLK_DATA(BLK_CLKB)
FF1 FF2

– Block owner will fix and redo the block verification

– SoC owner will fix the connectivity issue TOP_CLKB
BLK_CLKB

– Or it is a real RTL bug. TOP_CLKA

BLK_CLKA

MYBLOCK

Modifying the connectivity of

block input port to correct clock
input at Top level will resolve this
mis-match

© 2015 Synopsys, Inc.

Combo Check Mismatch (Glitch Detection)

• Problem Description But at top level , combo is driving

BLK_DATA which casues combo
– Block is receiving async input and requirement is for the port to be, this
mis-match glitch safe
may result in glich
– Transmitter block or SoC is driving combo logic on port
TOP
• Conclusion
– SoC connectivity issue OR Transmit block issue will be isolated and addressed
SYNCHRONIZER

TOP_D
ATA BLK_DATA –
MYBLOCK
combo no

abstract_port –port BLK_DATA

-clock C1 –combo no

© 2015 Synopsys, Inc.

Case Analysis Mismatch

• Problem Description
– Block verification has incorrect mode-setup or the SoC setup is incorrect/inconsistent compared to the
block
• Example in Real Design
– MYBLOCK accidentally blocked real CDC issues due to constants blocking clock propagation
– MYBLOCK accidentally assumed wrong mode and picked wrong clocks
• Results of Flat Run
– Due to blocked state space block verification might be optimistic
OR
– SoC connectivity issue which can lead to illegal modes
• Results of Validation Run (Hier)
– 1 violation per over constrained port (block level had SCA, but top didn’t) space
– 1 violation per wrongly constrained port, block is in a different mode than SoC assumes

© 2015 Synopsys, Inc.

 Case Analysis Mismatch - Examples
Block input is tied to Data tied constant
constant
TOP
at block
D1 (C1)
U1
D1 = 0 O1
But top level input D Q O1

connected to block input

is not tied to constant C1 C1 F
CP
Top 1
C2 C2
set_case_analysis Wrong clock
–name SEL –value
1 selected at block
TOP
MYBLOC
U1
D1(C1) D1
D
O1
Q
O1 K
C1 C1
F
CP
C2 C2
1
SEL = 0
Block
SEL = 1
set_case_analysis –name SEL
MYBLO –value 0
© 2015 Synopsys, Inc.
 Quasi Static Mismatch quasi_static –name D1
• Problem Description TOP
– MYBLOCK WRONGLY assumed port as
quasi_static
No D1 (C3)
U1
D1 = quasi_staticD O1 O1
Q
quasi_static
• Example in Real Design
constraint C1 C1 F
C2 CP
– Block verification assumes 1 port as C2
1
quasi static, which is able to filter 100+
crossings
MYBLO
• Results of Flat Run CK
– 100+ crossings missed at block verification, will show up at top level making SoC verification noisy

• Results of Validation Run (Hier)

– 1 violation per wrongly constrained port (block level had quasi_static, but top didn’t)
– quasi_static always reduces state space and glitch checks

© 2015 Synopsys, Inc.

Reset Mismatch reset –name R –value 0 TOP

• Problem Description D1 (C1) D1 (C1)

U1 O1 O1
D Q
– TOP missed defining a reset
No reset constraint C1 C1 F
– SoC designer missed connecting reset used at top level CP
1
R (non-reset top-level port) R = Reset
• Example in Real Design
– Synchronous Reset NOT declared and participating in
1000+ crossings
MYBLO
• Results of Flat Run Reset –name R –value 0 TOP CK
– 1000+ reset violations due to missing resets or wrong D1 (C1) D1 (C1)
U1 O1 O1
D Q
values would be identified
reset –name R – C1 C1 F
CP
• Results of Validation Run (Hier) value 1 Active value mis-match
1
– One violation per reset port showing: Missing resets, R=1 R=0

Wrong type of reset, Wrong Value

MYBLO
© 2015 Synopsys, Inc.
CK
Lab1: Working with abstract Models and Mismatches

• 30 Minutes.
• In this lab you will see what mismatches look like and fix them and rerun.
• Some problems will problems in the block and others will be top level problems.
• All problems can be fixed by adding constraints.

© 2015 Synopsys, Inc.

Handling Parameterized Modules

• What and Why are parameterized modules problems?

• How does spyglass abstract models handle these?
• What about parameters that don’t affect the CDC analysis?

• The current_design in an SGDC file or abstract model has additional parameters

• If you want a model to apply to all models then use the following
-defparam or leaving it off implies it gets applied to ALL modules by that name.
• To apply a constraint file to a specific module defined by a set of parameters use the following
-param {PARAM1=X PARAM2=Y}
current_design BLOCK_NAME [ null | <-defparam> | -param {PARAM1=X PARAM2=Y]

© 2015 Synopsys, Inc.

 Parameterized Module Definition //SOC Level RTL
module soc (inputs,outputs);
• Parameterized modules are commonly used: FIFO #(.width(8), .depth(4)) u1();
FIFO #(.width(32), .depth(6)) u2();
– in both Verilog and VHDL //rtl code
• Allow user to change things like: endmodule

– Bus width’s
– Internal depth of registers arrays and fifo’s
//IP level RTL
– Functionality (sync vs. async). module FIFO (inputs, outputs);
parameter width=32;
– Reset (sync vs. async vs. non-resettable) parameter depth=16;
– Etc…. //rtl code
endmodule

d1 8 FIFO
u1 8
clk
1

d2 32 FIFO
3
clk2 u2 2
© 2015 Synopsys, Inc.
 Parameterized Modules

• Parameterized Modules effectively can change the hardware configuration.

– This can impact clocks, resets, port domains.
• SpyGlass can apply parameterized modules automatically to correct instances.
• Requires Defining the parameter values in the project file
• The _dnc_ value for a parameter means to use the parameter defined in the source code and
treat it as a “Do Not Care” when matching to an instance.

#IP Abstract File Generated if no parameters giving

#in project file:
IP Project File: current_design ip1 –defparam
#Overwriting default parameters
set_option param ip1.width=32
#Declaring a parameter “Do Not Care” #IP Abstract File Generated with parameters
#Used default parameter. #depth=_dnc_ is a “Do NOT Care” parameter
set_option dnc_param ip1.deptgh current_design ip1 –param {width=32 depth=_dnc_}
…
© 2015 Synopsys, Inc.
Parameterized Abstract Module flow 1

• Only the parameters that are different from the default specified in RTL need to be added to
project file.
• Flow is same an non-parameterized module.

Spyglass Abstract Parameterized

Input SGDC Project File
wth set_option Model creation Abstract
constraints- Models
parameterized param.

© 2015 Synopsys, Inc.

Parameterized Abstract Module flow 2

• Same module with many parameters but inputs don’t change.

• Some parameters don’t change the port/clock relationships
• A Common parameterized module such as a FIFO
– The input constraints can be writing in “Non Parameterized” form.
– Each unique project file can read the same constraints, but change the parameters.
– Unique abstracts get generated from same input constraints.

Input SGDC
constriants.
(Non- Spyglass Abstract
parameterized) RTL Model creation Parameterized

modules Abstradct
Models

© 2015 Synopsys, Inc.

How the abstract flow treats parameterized Modules

• When SpyGlass reads in an abstract module:

• abstract models contain “current_design” argument that scopes the constraints to the module.
• If the parameters have not been overwritten in the project file, then it will contain a “-defparam”
argument. This means it was generated using the default parameters.
current_design fifo –defparam
• If the project file contained parameters then it will get written as follows:
– current_design FIFO –param (WIDTH=8, DEPTH=4)
• SpyGlass will automatically apply the correct parameterized abstract model to the appropriate
instances.

• Priority is given to –param. If there is NO matching –param, then the –defparam abstract will
be used.

© 2015 Synopsys, Inc.

Things to watch out for using parameterized abstracts.

• If the “current_design” in the input SGDC file contains parameters

– If the project file also contains parameters and they don’t match, then the SGDC file will NOT be read.
– IF the project file doesn’t contain parameters then the RTL parameters are used and the still might not
get read.
• The Top Down Flow and Setup_port01/Clock_info15 automatically insert the parameter list
into its auto-generated SGDC files.
– These optionally should be hand edited and removed if they are not required.
• Bit blasting on constraints can cause fatals.
– If a 32 bit blasted bus, it instantiated using 16 bits, then bits 17-31 won’t exist, so you will get a fatal.

© 2015 Synopsys, Inc.

One thing to make this work easier.

• When creating input constraints for a parameterized block:

– Don’t use bit notation. Leave the bits off.
– abstract_port –ports Bus[7] –clock clk
– Replace with bus
– abstract_port –ports Bus –clock clk

• The abstract model created many times will contain bit blasted constraints
– Different behavior of different outputs.
• This is why you almost always need to generate a model for each unique set of parameters,
unless you know for sure that a parameter won’t change port width or behavior.
• Then use the “set_option dnc_param top.parameter option when generating the abstract.

© 2015 Synopsys, Inc.

Instance Based Abstraction

• Even though the module name is the same or parameters don’t change, it is possible for
different instances of the same module to have different input requirements.
– Different set_case_analysis
– This could cause different clocks to be applied
• SpyGlass can apply a specific abstracat model to a specific instance by adding an instance list
to the sgdc –import constraint

sgdc –import block block_abstract1.sgdc –instance_list u1

© 2015 Synopsys, Inc.

Top Down Workflow

• Top Level constraints can be used to propagate clocks/resets/set_case_analysis/quasi_static

constraints to any module.
• A file will be generated for each instance of the module.
– The constraints contained might be the same or different. SpyGlass does nothing to uniquify them.
• The constraints are then used to run cdc_verify_struct on a block
– This can be used to help IP owner generate constraints
– These can be used to divide and conquer a large IP.
• NOTE! Only boundary level constraints will get propagated to a module.
– Internal constraints (clocks, resets, set_case_analysis/quasi_static/etc) can be grepped from the top
level CKSGDCInfo.rpt. (grep for the “instance name” of constraints you are looking for)
• The following constraint can be added to any SGDC file that contains the module_name:
– You can do multiple exports at the same time.

sgdc –export module_name

© 2015 Synopsys, Inc.
Handling Late IP’s without collateral.

• Some IP’s arrive early and you receive collateral (abstract models) right away.
• Some IP’s arrive late in the design process so you don’t have abstract models.
• Can’t run flat because the design is too large or will take too long.

• You can generate a dirty abstract and help the IP owner by generating the IP level constraints
using the TOP down workflow.

• Use top down to generate constraints for late IP’s.

– These can also be used as hints to the IP owner.
• This will allow SoC to move forward faster, earlier and converge sooner.

© 2015 Synopsys, Inc.

LAB2: Parameterized module and
Generating Top-Down Constraints
• In this lab,
• Work with a parametrized module.
• You will generate constraints using the top down methodology for a module that is instantiated
twice.
• You will then import it into the specific instances to avoid mismatch problems

© 2015 Synopsys, Inc.

Release Information
• The following files can be found at the top-level of install directory:

SpyGlass_ReadMe.pdf

• Download and installation information

SpyGlass_ReleaseNotes.pdf

• What’s new in this release. Also contains the list of incidents Fixed in this release

SpyGlass_KPNS.pdf

• SpyGlass_KPNS.pdf: Known problems in this release and workarounds

© 2015 Synopsys, Inc.

Accessing the SpyGlass HTML Help Set
• You do not have to launch Atrenta Console or run SpyGlass to access the HTML help set

Console GUI
Launch Console and either
press the F1 keyboard key
or click Help > SpyGlass
Help menu item.

Linux Windows
Run the spyhelpviewer Copy the $SPYGLASS_HOME
utility from htmlhelp or doc directory to
the SPYGLASS_HOME/bin your local hard drive.
directory Run the index.html file.

SpyGlass
HTML/PDF
Help Set

© 2015 Synopsys, Inc.

Landing Page
The default web browser launches and the landing page is displayed

The Landing Page is designed to provide multiple points

Clk_Gen01b of entry to the information.

Next, let’s see how you can

browse the entire help set. Click To explore further, some topics have the
either the Contents tab or the Related Topics enabled.
For example, if you want to access
Show in Contents icon.
The topics have been specially selected Fields
GuideWare2.0 from across
of Use,the entire
click here.
help set. They may include:
Click Clk_Gen01b. Overview topics The relevant page appears on
the right page.
Just-in-time information
Alternatively, you can usePreceding
Search. For
information/knowledge
example, to search for information on the
Succeeding information/knowledge
Clk_Gen01b rule, type the Clk_Gen01b
The entire help set isAlternate ways of accomplishing the task
accessible.
keyword
The andresults
search click Go.
are low noise and
Related/Similar/Adjacent rules
displayed in order of relevance.

© 2015 Synopsys, Inc.