CDC CONSTRAINTS -2

• Perform the following steps for this flow:

Step 1 – Check Design Coverage and Extract Domain Information
Step 2 – Validate Abstract Views
Step 3 – Check Consistency, Clean Clock Definition, and Delay Constraints
Step 4 – Check Timing Exceptions Structurally
Step 5 – Remove Redundancy and Achieve Better Retargeting (Optional)
CHECK DESIGN COVERAGE AND EXTRACT DOMAIN INFORMATION

• Enables to compute the design coverage and identify uncovered design objects, such as ports and registers
that have not been constrained.
• In addition, domain information is extracted from the SDC commands.
• The extracted information is checked for consistency with the SGDC domain information. You can identify
conflicting clock domain classifications in the SDC file.
• An SGDC file is generated containing the clock_group information inferred from the SDC constraints, which
can be used for further analysis.
• The generated clocks corresponding to source clocks are reported in a tabular format.
• Prerequisites
Since domains are extracted based on set_false_path,set_clock_group, and set_clock_uncertainty
constraints,violation messages from previous steps for these constraints need to becleaned up before executing
the step.
• Executing the Step
Run the sdc_audit goal in the Console GUI by entering the followingcommand:
spyglass -project [Link] -goal rtl_handoff/constraints/sdc_audit
 VALIDATE ABSTRACT VIEWS

During the SoC integration the integrator may choose to use the complete block definition or use the
abstract view generated during block-level runs.
• If an abstract view of the block is used, this step must be run to ensure that the block-level assumption
for constraints used during abstract creation match the SoC-level constraints.
For example, for the clock frequency, the case analysis assumed during the block-level run must match
the chip-level requirements.
• Prerequisites
Block-level abstract view has been created.
• Executing the Step
Run the sdc_abstract_validate goal in the Console GUI by entering the following command:
spyglass -project [Link] -goal rtl_handoff/constraints/sdc_abstract_validate
• Exit Criteria
1. There should be no inconsistency between top-level and block-level constraints.
2. If inconsistencies are identified, the block may have to be rerun to create a new abstract. Alternatively,
the abstract view may have to iscarded and the flow m ust be run with the RTL view of the block .
CHECK CONSISTENCY, CLEAN CLOCK DEFINITION, AND
DELAY CONSTRAINTS

• The objective of this step is to detect the inconsistencies in the specification of clocks and generated clocks
and to perform basic checks on overwritten and conflicting constraints.
• Without clean clock definition, other constraint validation and exception verification is ineffective.
• Overwritten and conflicting constraints may capture the design intent incorrectly.
• This step also detects the inconsistencies in specification of input/output delays, clock latency, and clock
uncertainty.
• Such inconsistencies not only produce incorrect synthesis or static timing analysis results, they can
potentially allow these tools to assume a greater slack than available.
• This translates to insufficient or incomplete optimization by synthesis, which directly affects the QoR.
• Finally, this step checks that all combinational paths are constrained correctly.
• If a combination path is unconstrained or incorrectly constrained, implementation tools do not perform timing
checks on these paths. As a result, the operation of a device at any specified speed cannot be guaranteed
CHECK CONSISTENCY, CLEAN CLOCK DEFINITION, AND DELAY
CONSTRAINTS

• Prerequisites
• At this stage, all the design files must have passed the tests performed in the setup phase. For details, refer to
the Run Sanity Checks on Inputs section.
• Executing the Step
• Run the sdc_check goal in the Console GUI by entering the following command:

spyglass -project [Link] -goal rtl_handoff/constraints/ sdc_check

EXIT CRITERIA

1. All conflicting constraints should be cleaned up.

2. All overwritten constraints should be reconciled or justified.
3. All clock definition issues should be cleaned up. There should be no undefined clocks or clocks with incorrect
sources or clocks with inappropriate characteristics.
4. All delay values must be positive numbers.
5. All input and output delays must be associated with the correct clocks.
6. Input/Output delays must meet the slack requirement.
7. All combinational paths must be constrained.
8. The delay numbers must be valid and meet the slack requirements.
9. After cleaning up reported issues, the step should be rerun to ensure that all rules in this step exit with zero
violations.
CHECK TIMING EXCEPTIONS STRUCTURALLY

• Executing the Step

Run the sdc_exception_struct goal in the Console GUI by entering the following command:

spyglass -project [Link] -goal rtl_handoff/constraints/sdc_exception_struct

REMOVE REDUNDANCY AND ACHIEVE BETTER RETARGETING
(OPTIONAL)

• Executing the Step

• Use the sdc_redundancy goal in the Console GUI by entering the following command:

spyglass -project [Link] -goal rtl_handoff/constraints/ sdc_redundancy

SOC METHODOLOGY USING ABSTRACTION

• Constraints at the block boundary do have an impact at the SoC level.

• At the SoC level, the top-level SDC constraints should match the boundary conditions of the block.

• For example, suppose there is a clock applied with a period of 10 at the SoC level. This clock is connected to
a block port, Port A. At the SoC level, it is important to ensure that there is a similar clock with a period of 10
defined in the block level SDC.
• This methodology is valid only for structural SpyGlass Constraints checks, such as SDC checks, equivalence,
and mode coverage. However, it is not valid for false path and MCP verification.
GENERATING AN ABSTRACT VIEW IN SPYGLASS CONSTRAINTS

• run the sdc_abstract goal.

• After specifying the above inputs to SpyGlass, run the sdc_abstract goal.
• When the goal run is complete, SpyGlass generates the following SGDC file that represents the abstract view
of the block:
• abstract_port -ports in -connected_inst "\top.f1 " -inst_pin D -inst_master RTL_FD -path_logic buf -scope
const –mode reference
• abstract_port -ports in -connected_inst "\top.f4 " -inst_pin D -inst_master RTL_FD -path_logic buf -scope
const –mode reference
• abstract_port -ports out1 -connected_inst "\top.f1 “ -inst_pin Q -inst_master RTL_FD -path_logic buf -scope
const -mode reference
• abstract_port -ports out1 -connected_inst "\top.f4 “ -inst_pin Q -inst_master RTL_FD -path_logic buf -scope
const -mode reference
• abstract_port -ports clk1 -connected_inst "\top.f1 “ -inst_pin CP -inst_master RTL_FD -path_logic buf -scope
const -mode reference
• abstract_port -ports clk2 -connected_inst "\top.f4 “ -inst_pin CP -inst_master RTL_FD -path_logic inv -scope
const -mode reference
VALIDATING BLOCK ASSUMPTIONS IN SPYGLASS CONSTRAINTS

• run the sdc_abstract_validate goal.

• During the goal run, constraints-specific validation is performed pertaining to clocks, set_case_analysis, and IO
delay. These checks are
• Clock Checks
Clock defined at the top-level reaching to the block boundary and no clock is present in [Link]. Refer to the
Example below for more information on this check.
Clock is present in both [Link] as well as [Link] but clock characteristics are not same.
Case Analysis Checks
set_case_analysis is given at top level reaching to the block boundary and no set_case_analysis is mentioned in
[Link]
set_case_analysis is present in both [Link] and [Link] but they are not same.
IO Delay Checks
set_input_delay/set_output_delay is mentioned at a point in [Link] but no delay value is reaching from top level
or vice versa.
• set_input_delay at block level is less than set_input_delay reaching from top level.
• set_output_delay at block level is less than set_output_delay reaching from top level.
EXAMPLE - VALIDATING BLOCK ASSUMPTIONS IN SPYGLASS
CONSTRAINTS
• Illustrates a clock check by validating the imported SGDC file, block1_abstract.sgdc, with the
specified top SDC file, [Link].

• //test.v
module top( in1, clk1, clk2, out1, out2 );
input in1;
input clk1, clk2;
output out1, out2;
wire w;
block1 b(.in(in1), .clk(clk1), .out(out1));
endmodule

module block1( in, clk, out);

input in, clk;
output out;
FD1 f1( .D(in), .CP(clk), .Q(out) );
endmodule
• //[Link]
current_design top
sdc_data -file [Link] -mode reference
sgdc -import block1 block1_abstract.sgdc
block -name block1
current_design block1
sdc_data -file [Link] -mode reference

Here, the sgdc -import constraint for the current design top specifies to import the abstract view of block1 in the
current design top.
Suppose the abstract_port constraints specified in the block1_abstract.sgdc file are as
follows:

• // block1_abstract.sgdc
current_design block1
abstract_port -ports in -connected_inst "\block1.f1 "
-inst_pin D -inst_master RTL_FD -path_logic buf -scope const -mode reference
abstract_port -ports out -connected_inst "\block1.f1 "
-inst_pin Q -inst_master RTL_FD -path_logic buf -scope const -mode reference
abstract_port -ports clk -connected_inst "\block1.f1 "
-inst_pin CP -inst_master RTL_FD -path_logic buf -scope const -mode reference
• Clock is specified for "top" only as:

• //[Link]

• create_clock -name clk1 -period 10 [get_ports clk1]

• To validate, run the sdc_abstract_validate goal.

• After the sdc_abstract_validate goal is run, a Warning message is reported because the clock constraint is
defined for top only. However, you should also define this constraint for the clk port of the block.
USING THE ABSTRACT VIEW IN SPYGLASS CONSTRAINTS

• //[Link]
• current_design top
• sdc_data -file [Link] -mode reference
• sgdc -import block1 block1_abstract.sgdc
• block -name block1
• current_design block1
• sdc_data -file [Link] -mode reference
DEBUGGING REPORTS

• -tcdecompile
• Setting the -tcdecompile parameter generates a file called TCdecompiledInfo that contains the expanded
interpretation of the constraints as applied by the SpyGlass Constraints solution.
• This is very useful in debugging situations when you need to determine how constraints are being expanded.
You can set this parameter in the Console GUI or Tcl by using the following command:
set_parameter tcdecompile 'yes‘
• The generated file is also useful to understand where the constraints file had a problem and if the SDC file is not
read in successfully. The TCdecompiledInfo file shows exactly how each of the Tcl variables was defined or how
they were interpreted. You can view this file from the following location:
spyglass_reports/constraints/TCdecompiledInfo
• An excerpt of the TcdecompiledInfo file is as follows:
#[Link]@@28@@
sg_set_ideal_network port_pin_list {A1/in1}
#[Link]@@29@@
• The -tc_ignored_commands parameter specifies the file containing the list of SDC commands to be ignored
by the SDCPARSE rule.
• The file contains one command per line, which should be ignored. You should only specify the SDC
commands that are currently not supported by SpyGlass so that there are no invalid command errors while
parsing the SDC files.
• You can set this parameter in the Console GUI or Tcl by using the following command:
• set_parameter tc_ignored_commands '<file-name>'
• During the parsing, all other constraints that are ignored are written to a file called tc_unparsed_command in
the $CWD/ <vdb-name>_reports/constraints
directory.
• The corresponding report file named tc_unparsed_commands.rpt is created in the current working directory
and can also be accessed from the Report Menu of the Console GUI.
• The Show_Case_Analysis rule should always be run the the Console GUI.

• This rule shows, as a schematic, how set_case_analysis propagates in the design.

• This is very useful when several case analysis settings result in blocking certain timing paths.
• Applying waivers during preprocessing: When you do not want to view the constraints issues reported in a
block that you do not want to analyze, apply a waiver on the block before analysis.
• Applying waivers during post-processing: As you analyze the reported violation and you perform proper
analysis on it, apply a waiveron it.
• You can ‘waive’ rules/messages during analysis:
In a file or design unit, by using waivers
waive –file src/top.v –rule Clk_Gen01
Waive an instance of a message by using waivers
waive –file src/top.v -msg “Clock ‘clk’ doesn’t have a clock constraint”
Waiving a group of messages through regular expression (‘regexp’)
waive -du "top" -regexp -msg ".* is not driven by a register"
Waivers are useful, when there are methodology-based violations in the SDC that may not be applicable. As a
practice, we do not recommend the use of waivers.