SDC
SDC
User Guide
RTG4 FPGA Timing Constraints
(Classic Constraint Flow)
Libero SoC v11.8 SP4
Microsemi makes no warranty, representation, or guarantee regarding the information contained herein or the
suitability of its products and services for any particular purpose, nor does Microsemi assume any liability
whatsoever arising out of the application or use of any product or circuit. The products sold hereunder and any
other products sold by Microsemi have been subject to limited testing and should not be used in conjunction with
mission-critical equipment or applications. Any performance specifications are believed to be reliable but are not
verified, and Buyer must conduct and complete all performance and other testing of the products, alone and
together with, or installed in, any end-products. Buyer shall not rely on any data and performance specifications or
Microsemi Headquarters parameters provided by Microsemi. It is the Buyer’s responsibility to independently determine suitability of any
One Enterprise, Aliso Viejo, products and to test and verify the same. The information provided by Microsemi hereunder is provided “as is,
CA 92656 USA where is” and with all faults, and the entire risk associated with such information is entirely with the Buyer.
Within the USA: +1 (800) 713-4113 Microsemi does not grant, explicitly or implicitly, to any party any patent rights, licenses, or any other IP rights,
whether with regard to such information itself or anything described by such information. Information provided in
Outside the USA: +1 (949) 380-6100
this document is proprietary to Microsemi, and Microsemi reserves the right to make any changes to the
Sales: +1 (949) 380-6136
information in this document or to any products and services at any time without notice.
Fax: +1 (949) 215-4996
Email: [email protected]
www.microsemi.com About Microsemi
©2018 Microsemi, a wholly owned Microsemi, a wholly owned subsidiary of Microchip Technology Inc. (Nasdaq: MCHP), offers a comprehensive
subsidiary of Microchip Technology Inc. All portfolio of semiconductor and system solutions for aerospace & defense, communications, data center and
industrial markets. Products include high-performance and radiation-hardened analog mixed-signal integrated
rights reserved. Microsemi and the
circuits, FPGAs, SoCs and ASICs; power management products; timing and synchronization devices and precise
Microsemi logo are registered trademarks of
time solutions, setting the world's standard for time; voice processing devices; RF solutions; discrete components;
Microsemi Corporation. All other trademarks enterprise storage and communication solutions, security technologies and scalable anti-tamper products;
and service marks are the property of their Ethernet solutions; Power-over-Ethernet ICs and midspans; as well as custom design capabilities and services.
respective owners. Learn more at www.microsemi.com.
5-02-00603-2/07.18.
Table of Contents
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Revision 2.0 3
Introduction
In designing FPGA synchronous digital designs, from design entry to physical implementation, rarely do
you achieve the required timing performance of the design without iteration. You often must go through
numerous iterations of the design cycle—HDL design capture, synthesis, physical implementation
(Place and Route) and Timing Analysis—to achieve timing closure.
Setting Timing Constraints and performing Timing Analysis are the two most important steps in design
iterations towards timing closure.
For RTG4 designs, Microsemi recommends setting timing constraints for both synthesis and place and
route steps. You must first set the timing assertion constraints; see "Timing Assertions" on page 7.
If timing performance is not met in the first iteration, consider setting additional and more advanced
timing constraints in the second and subsequent iterations. See "Timing Exceptions" on page 8.
Revision 2.0 4
1 – Using Synopsys Design Constraints
The Synopsys® Design Constraint (SDC) is a Tcl-based format used by Synopsys tools to specify the
design intent and timing constraints. Microsemi supports a variation of the SDC format for constraints
management.
You can use the following types of SDC commands when creating SDC constraints for RTG4 designs:
• Object Access
• Timing Assertions
• Timing Exceptions
Object Access
SDC timing constraints apply to specific design objects. Table 1-1 summarizes the object access
commands supported by SmartTime (the Microsemi static timing analysis tool incorporated with the
place and route tools). Refer to the SmartTime online help for more information.
Table 1-1 • Object Access Commands Supported by SmartTime
Design Object Command(s)
Cells / Instances get_cells
Clocks get_clocks
Nets get_nets
Pins get_pins
Ports get_ports, all_inputs, all_outputs
Registers all_registers
Revision 2.0 5
Wild Card Characters
Table 1-2 lists the wild card characters available for use in SDC commands.
Table 1-2 • Object Access Commands Supported by SmartTime
Wild Card Function
\ Interprets the next character literally
* Matches any string
Note: The matching function requires that you add a backslash (\) before each slash in the pin names in
case the slash does not denote the hierarchy in your design.
SmartTime software defaults to the use of '/' as a design hierarchy separator and ":" as the pin separator
character.
For example: [get_pins {top_level/blockA/instance123:my_pin}]
Notice that '/' is the hierarchy separator used to indicate that 'instance123' is present in the design
hierarchy below top_level ' blockA. The ":" pin separator identifies 'my_pin' on 'instance123'.
Comments
You can add comments to an SDC file by preceding the comment line with a pound sign (#).
# This is a comment line
Timing Assertions
Timing assertions are intended to capture your design timing requirements.
They include the following SDC commands:
• Clock Period/Frequency
– create_clock
– create_generated_clock
• Input / Output Delay
– set_input_delay
– set_output_delay
– set_external_check
– set_clock_to_output
• Clock-to-clock Uncertainty
– set_clock_uncertainty
Revision 2.0 6
• Clock Source Latency
– set_clock_latency
Refer to "Timing Constraints and Design Flow" on page 9 for the Timing Assertion SDC commands
Synplify Pro and SmartTime support.
Timing Exceptions
Use timing exceptions to identify design paths that require the default single cycle timing relationships to
be overridden. SDC commands for timing exceptions include:
• False path
– set_false_path
• Multicycle path
– set_multicycle_path
• Maximum delay path
– set_max_delay
• Minimum delay path
– set_min_delay
• Disabled timing arcs
– set_disable_timing
7 Revision 2.0
2 – Timing Constraints and Design Flow
This chapter describes where to specify timing constraints and perform timing analysis in the Libero
design flow (Figure 2-1). Microsemi recommends that you supply Synplify Pro and SmartTime with
adequate and complete timing constraints. Also, you must review the timing reports from both Synplify
Pro and SmartTime to ensure that the design has been constrained properly and is meeting the timing
goals.
Libero tools (Timing Driven Place and Route and SmartTime) support a subset of Synopsys SDC timing
constraints relevant for FPGA designs.
Microsemi recommends that you create two sets of timing constraints in the Libero flow:
• FDC timing constraints for synthesis with Synplify Pro.
• SDC timing constraints for the Libero Timing Driven Place and Route and SmartTime phases.
Overview
Synplify Pro supports the FPGA Design Constraints (FDC) format. The FDC format includes:
• A subset of the Synopsys SDC standard for timing constraints
• Legacy timing constraint format supported by Synplify Pro
Revision 2.0 8
You can provide timing constraints to Synplify Pro by:
• Importing the timing constraint file(s) into the Libero project. Identify the timing constraint file(s) to
be passed to Synplify Pro in Libero GUI. Right click the file(s) and choose Use for Synthesis. For
details about importing timing constraints in the Libero GUI, refer to the Libero online help.
• Creating the timing constraints using the SCOPE (Synthesis Constraints Optimization
Environment) GUI available in Synplify Pro software. Constraints created using SCOPE are
saved to a constraints file using the FDC format.
9 Revision 2.0
Note: The backslash "\" character is part of Tcl syntax. It breaks a long single command into multiple
lines.
Note: Synplify Pro software defaults to the use of '.' (period) as the hierarchy separator for timing
constraints. Use the set_hierarchy_separator command in the FDC file to redefine the hierarchy
separator character. For example:set_hierarchy_separator {/}
The divide_by and multiply_by factors are derived from the PLL diagram displayed on the 'Advanced' tab
of the fabric CCC configurator. Synplify Pro software defaults to 100 MHz required clock frequency for all
clocks missing a timing constraint.
# output delays
set_output_delay -clock [get_clocks clk_core]\
-max 3.0 \
[get_ports {data_bus_out_clk_core*}]
Constraint Checker
Microsemi recommends that you validate FDC or timing constraints after you import or create them. This
is especially important if the timing constraints file is imported.
Synplify Pro provides a constraint checker utility that you can use to validate the SDC timing constraints.
The constraint checker is accessible from the project menu (Run > Constraint Check) inside the
Synplify Pro GUI. It generates a constraint check report (*_cck.rpt) with details about any issues with
timing constraints. The summary section should indicate that no issues were found with the timing
constraints.
Use the constraint checker report to fix mistakes related to incorrect syntax or object names.
For details about the Synplify Pro Constraint Checker, refer to the Synplify Pro for Microsemi User Guide.
Revision 2.0 10
Microsemi recommends that you go through one pass of the entire design flow including Timing
Driven Place and Route before adding timing exceptions for synthesis. You can then use the
more accurate post place and route timing analysis report to determine required constraints.
Clock, Input and Output Delay constraints are the minimum set of required timing constraints for all
designs. Some designs may require additional timing constraints known as timing exceptions. For
example:
• False Paths (set_false_path),
• Multicycle Paths (set_multicycle_path)
• Maximum Path Delay (set_max_delay)
You can use timing exceptions to identify design paths that require the default single cycle timing
relationships to be overridden. You must guide the synthesis tool optimizations by identifying design
paths that:
• Do not have a timing relationship (set_false_path)
• Have a timing relationship that is not a single cycle (set_multicycle_path or set_max_delay)
Precedence
To resolve timing constraint conflicts when multiple timing exceptions are applied to the same design
object, the following precedence rules apply:
set_disable_timing takes precedence over all other timing exception constraints.
False Path constraint takes precedence over Maximum Path Delay/Minimum Path Delay or Multicycle
Path constraint.
Maximum Path Delay/Minimum Path Delay constraint takes precedence over Multicycle Path constraint.
11 R ev i sio n 2 . 0
it in the Libero SoC Editor View pane. Scroll down to the section entitled START OF TIMING REPORT
(Figure 2-2).
Timing Exceptions
If the post-synthesis timing analysis reports that the design does not meet timing specifications for clock
speed or I/O delays, Microsemi recommends that you use timing exceptions to help synthesis.
Microsemi recommends that you go through one pass of the entire design flow, including Timing Driven
Place and Route, before adding timing exceptions for synthesis. You can then use the more accurate
post place and route timing analysis report to determine required constraints.
Use false path timing constraints to identify specific design paths that do not propagate logic level
changes and should not be considered during timing analysis. The synthesis tool ignores design paths
identified using this constraint for logic and mapping optimizations.
Use Multicycle Path, False Path and Maximum Path Delay timing constraints to identify design paths that
have a timing relationship different from the default single cycle relationship. The synthesis tool uses the
new relationship for optimizations.
Multicycle Path and False Path constraints typically result in relaxing the original single clock cycle timing
requirement. The Maximum Path Delay constraint can result in relaxing or tightening the original timing
requirement based on the time value specified by the user.
Revision 2.0 12
FDC Examples
# False Path
set_false_path -from [get_ports uart_ctrl]
# Multicycle Path
set_multicycle_path 4 -to [get_ports {I2C*}]
13 R ev i sio n 2 . 0
Before entering any constraints, first compile the design in Synplify Pro (Run > Compile Only).
Performing compile inside Synplify Pro pre-populates SCOPE with object names. This could save you
time and effort entering object names.
Clock Constraints
There are two types of clock constraints: create_clock and create_generated_clock. SCOPE has two
separate tabs for these two constraints.
Use the Clocks tab to identify the clock sources (create_clock). Refer to Figure 2-4.
Revision 2.0 14
Use the Generated Clocks tab to identify the generated clocks (create_generated_clock) in the design.
Refer to Figure 2-5.
Constraint Checker
To check the constraints entered so far, click on the Check Constraints button on the menu bar. Synplify
Pro generates a clock constraint check report (*_cck.rpt). The summary should indicate that no issues
are found with the timing constraints.
15 R ev i sio n 2 . 0
Constraint checker is also accessible from the Project menu (Project > Run > Constraint Check).
Exceptions
Some designs require additional timing constraints known as timing exceptions, such as:
• set_false_path
• set_max_delay
• set_multicycle_path
To enter timing exceptions in SCOPE navigate to the Delay Paths tab. After saving the file, from the File
menu choose Close to return to the Project view.
Limitations
• The forward annotated SDC file from Synplify Pro does not include any set_clock_latency
constraints present in the original user SDC file.
• Synplify Pro does not automatically generate clock constraints for oscillators or CCC instances.
You must supply accurate clock constraints (create_clock, create_generated_clock) to Synplify
Pro. These constraints are then forward annotated in the *_sdc.sdc file.
Revision 2.0 16
Figure 2-7 • SDC File for Compile
17 R ev i sio n 2 . 0
For details on the options and arguments of the SDC commands, refer to the SmartTime online help.
Invoke the Constraint Wizard from SmartTime (Tool > Constraint Wizard).
The Constraint Wizard enables you to add constraints in the following order:
1. Overall clock constraint
2. Overall I/O constraint
3. Specific clock constraints
4. Generated clock constraints
5. Specific input constraints
6. Specific output constraints
Use the Overall constraint tabs to set default constraints for clocks and I/Os.
The default constraints can be overridden by the Specific constraints for clocks and I/Os.
Clock Constraints
Use the Specific clock and Generated clock constraint tabs for:
• Oscillators used as clock sources.
• Fabric CCC outputs used as generated clocks
Revision 2.0 18
• Clocks from other sources
I/O Constraints
Use the Overall I/O constraint tab to set default constraints for all input and output ports in the design.
The default I/O constraints can be overridden in the Specific input and Specific output constraint tabs for
selected ports.
For details about the Constraint Wizard, refer to the SmartTime online help.
Constraint Coverage
It is important to generate a Constraints Coverage Report (Figure 2-9), because the timing report only
analyzes timing performance for design paths with timing constraints. Timing paths without timing
constraints may have timing violations and are not be reported. Invoke the Constraint Coverage report
from SmartTime Analyzer (Tools > Reports > Constraint Coverage).
19 R ev i sio n 2 . 0
Design paths or objects with missing constraints are listed under Enhancement Suggestions. Review
each suggestion and supply appropriate constraints to ensure that all design paths have timing
constraints.
For details about the Constraint Coverage Report, refer to the SmartTime online help.
Revision 2.0 20
SmartTime Constraints Editor
The SmartTime Constraints Editor is a tool that enables you to create, view and edit all design timing
constraints. Constraints supplied through the constraints wizard or SDC files are available for editing in
the SmartTime Constraints Editor.
Use the Constraints Wizard to easily provide basic timing constraints for clocks and I/O ports. For
advanced timing constraints such as timing exceptions use the Constraints Editor.
Timing Exceptions
Based on the complexity of the design, timing exceptions may be required. Timing exceptions are timing
constraints set on specific paths in the design. For example:
• set_false_path
• set_max_delay
• set_multicycle_path
Providing these constraints requires knowledge of the data paths in the design and their timing
requirements. By default, SmartTime uses a single clock cycle to analyze any timing path that has a
clock constraint set on it. Timing exceptions are used to override the default clock constraint for the
design path.
For details about the Timing Exceptions, refer to the SmartTime online help.
Note: Based on the severity of timing violations, it may also be necessary to provide timing exception
constraints to the synthesis software. To provide timing exception constraints to the synthesis
software, include these constraints in the FDC file being provided to Synplify Pro.
Limitations
• The placer currently supports the following constraints:
– create_clock
– create_generated_clock
– set_clock_latency
21 R ev i sio n 2 . 0
– set_input_delay
– set_output_delay
– set_max_delay
– set_false_path
• The following constraints are not supported by the placer:
– set_clock_uncertainty
– set_multicycle_path
– set_min_delay
• The placer does not support inter-clock domain timing. The placer optimizes clocks within their
domain, but not between domains. To enable placer optimizations for inter-clock domain paths,
use the set_max_delay constraint. This is described in the next section.
• The placer does not include the clock generation path in the arrival/require time calculation when
set_max_delay constraint is used.
Revision 2.0 22
3. Enter set_max_delay constraints for design paths that cross clock domains (Figure 2-11).
4. Use the second set of constraints (cloned scenario) exclusively for TDPR. Right-click Cloned
scenario and choose Use for TDPR (Figure 2-12).
For details about the set_max_delay constraint, refer to the SmartTime online help.
23 R ev i sio n 2 . 0
3 – Constraints for RTG4 IP Blocks
This chapter describes the constraint requirements for the following blocks:
• Oscillators
• Fabric Clock Conditioning Circuits (CCC)
• High Speed Serial Interface (SERDES)
Oscillators
The oscillator has only one output CLKOUT of 50 MHz. The output can only be connected to the CCC
configurator.
The following constraints will work for an oscillator with RCOSC_50MHZ_0 as instance name. The RC
oscillator is configured for 50 MHz.
create_clock -name osc_50MHz -period 20 \
[get_pins { RCOSC_50MHZ_0.CLKOUT}]
Revision 2.0 24
RTG4 Fabric Clock Conditioning Circuit (CCC)
CCCs are used to multiply, divide or delay clocks. Their effect is best described using generated clocks.
25 R ev i sio n 2 . 0
create_clock -name CLK3_PADP -period 10 [get_pins {RTG4FCCC_0.CLK3_PADP}]
The RTG4 FPGA Datasheet (DS0131) CCC specification lists the max clock output period jitter for each
CCC output. For example, a 100MHz CCC output clock will have a max output clock jitter equal to: max
(80, +/- 1% x 1/Fout_ccc) ps = +/- 100 ps. Similarly, a 50MHz CCC output clock will have +/- 0.01 *
20,000ps = +/- 200 ps of clock jitter.
For these scenarios, and others where a clock signal with a known amount of jitter is used to clock the
design, it is important to account for this jitter during Static Timing Analysis in SmartTime.
To tell SmartTime about the existence of short-term peak-to-peak clock jitter, clock source latency
constraints should be used. For example, to specify a clock jitter of +/- 100 ps on a clock named
'RTG4FCCC_0/GL0', use the constraints below:
set_clock_latency -source -early -0.1 { RTG4FCCC_0/GL0 }
set_clock_latency -source -late 0.1 { RTG4FCCC_0/GL0 }
Revision 2.0 26
For a peak-to-peak jitter, the -early is negative since the jitter is specified as a +/- time value. This
makes the -early and -late constraints different numbers, thus requiring two lines in the SDC to
capture the jitter.
The default SmartTime analysis will show the clock source latency applied to the Max Delay setup time
analysis. This occurs because the typical setup time check is performed at the next capture clock edge.
This means that jitter between the launch edge and capture edge can affect the calculation. For worst-
case calculations, the data will be treated as if it were launched late due to the launch clock edge plus
positive jitter. In contrast, data capture will occur at the next clock edge which will be assumed as early
due to the negative jitter value. The required time calculation will assume the capture clock occurs 1
clock period later minus the negative portion of the jitter constraint.
However, the SmartTime Min Delay hold time analysis will not typically show the clock jitter for a single
clock domain if the clock requirement is 0 ns. When the required calculation shows a clock requirement
of 0 ns, it means that the data arrival time and the required hold time are calculated relative to the same
clock edge, and thus there is no jitter to account for when looking at only 1 clock edge.
Clock source latency constraints will also be factored into inter-clock domain analysis to create the worst-
case launch to capture window for the setup and hold checks on the clock domain crossing. Max delay
analysis will use late launch and early capture, while min-delay analysis will use early launch and late
capture edges for the two respective clock domains.
27 R ev i sio n 2 . 0
• XAUI_MMD_MDC as the MDIO interface clock
• XAUI_RX_CLK_IN - Received data is synchronized in the flywheel FIFO to this clock
• XAUI_TX_CLK_OUT - Transmitted data is sampled with a synchronized clock if clock
compensation is enabled. XAUI_TX_CLK_OUT must be connected to XAUI_FB_CLK to enable
clock compensation.
REFCLK_P, APB_S_PCLK, XAUI_MMD_MDC and XAUI_RX_CLK_IN clocks must be defined at their
source.
XAUI_TX_CLK_OUT clock may be defined on the GL0/GL1 output ports of the SERDESIF block. The
example below creates these clocks for both NPSS and PCIE SERDES blocks.
PCIE SERDES
create_clock -name { gl_clocks2 } \
-period 6.400 \
[get_pins {PCIE_SERDES_IF_0.SERDESIF_INST.GL*}]
PCIE SERDES
create_clock -name { gl_clocks2 } \
-period 6.400 \
[get_pins {PCIE_SERDES_IF_0/SERDESIF_INST/INST_PCIE_IP:GL*}
Revision 2.0 28