A multi-cycle path (MCP) is a fundamental concept in digital circuit design, particularly crucial for Static Timing Analysis (STA). It addresses scenarios where data propagation across a logic path inherently requires more than one clock cycle to complete. Understanding MCPs is key to optimizing design performance and avoiding unnecessary complexity.
What is a Multi-Cycle Path?
In standard Static Timing Analysis, the assumption is that data launched from a flip-flop (FF) on one clock edge must be stable and captured by the next FF on the very next active clock edge. This is known as a single-cycle path.
However, certain combinational logic blocks within a design, such as complex arithmetic units or state machines, may naturally require multiple clock cycles to compute and stabilize their outputs. A multi-cycle path is a data path explicitly defined as taking longer than one clock cycle to propagate data from its source register to its destination register.
Why Use Multi-Cycle Paths?
The primary purpose of defining multi-cycle paths is to prevent over-constraining the design. If STA tools treat paths that naturally take multiple cycles as single-cycle paths, it leads to:
- Aggressive Optimization: The STA tool will try to meet the unrealistic single-cycle timing requirement. This can result in designs with larger area, higher power consumption, and increased complexity, as the tool tries to speed up logic that is fundamentally slow.
- Increased Design Effort: Designers may spend significant time and resources trying to meet an impossible timing target.
By correctly identifying and constraining multi-cycle paths, designers can:
* Optimize performance: Allow the logic to execute at its natural pace without artificial constraints.
* Improve efficiency: Reduce area and power by avoiding unnecessary optimizations.
* Ensure timing accuracy: Accurately reflect the design's behavior for STA.
Declaring Multi-Cycle Paths with SDC (set_multicycle_path)
In Synopsys Design Constraints (SDC), the set_multicycle_path command is used to inform the STA tool about these longer paths. This command overrides the default single-cycle assumption.
The basic syntax is:
set_multicycle_path <cycles> [-setup] [-hold] -from <start_point> -to <end_point>
<cycles>: The number of clock cycles the path is allowed to take.-setup: Specifies that the constraint applies to the setup time check. This is the most common usage.-hold: Specifies that the constraint applies to the hold time check.-from: The source point of the path (e.g., a register output).-to: The destination point of the path (e.g., a register input).
Example:
To specify that a path from reg_a/Q to reg_b/D takes 3 clock cycles for the setup check:
set_multicycle_path 3 -setup -from reg_a/Q -to reg_b/D
Impact on Setup and Hold Checks:
- Setup Check: When you specify
set_multicycle_path 3 -setup, the data launched from reg_a/Q at clock edge 0 is expected to be captured by reg_b/D at clock edge 3 (instead of the default edge 1).
- Hold Check: By default, if only
-setup is specified for a multi-cycle path, the hold check is often adjusted as well. A common default behavior is for the hold check to occur one clock cycle before the new setup check. In the 3-cycle example, the default hold check might be against data launched at cycle 0 and captured at cycle 2.
However, for many designs, it is critical that the hold time is met at the current capture edge (i.e., the same edge the data is intended to be captured by after the multi-cycle delay). This is achieved by explicitly setting a multi-cycle path for hold:
sdc
set_multicycle_path 3 -setup -from reg_a/Q -to reg_b/D
set_multicycle_path 0 -hold -from reg_a/Q -to reg_b/D
The 0 -hold constraint ensures that the data launched at cycle 0 must still be stable at cycle 0's capture edge (for the destination register), preventing glitches from being captured.
Clock Differences and SDC Declarations
When dealing with multi-cycle paths that span different clock domains or involve clocks with different periods, the interpretation of <cycles> becomes critical.
- Unequal Clock Periods: If the launch and capture clocks have different periods, simply stating a number of cycles might not accurately reflect the total time. For example, if a path takes 3 cycles of a fast clock and the destination clock is slow, the actual time available might be different.
-start and -end Options: To handle this, SDC provides -start and -end options.
set_multicycle_path <cycles> -setup -start -from ... -to ...: This constraint is relative to the launch clock edge. The STA tool checks if the data is stable cycles launch clock periods after it was launched.set_multicycle_path <cycles> -setup -end -from ... -to ...: This constraint is relative to the capture clock edge. The STA tool checks if the data arrives cycles capture clock periods before it is captured.
- Combined Usage: Often, a combination is used:
sdc
# Path takes 2 cycles of clock_fast, and destination is clock_slow
# Data launched on clock_fast edge T
# Setup check on clock_slow edge T + 2*clock_fast_period
set_multicycle_path 2 -setup -from [get_cells reg_a] -to [get_cells reg_b]
# If -start or -end is not specified, it is assumed to be relative to the capture clock.
# Example using explicit end:
set_multicycle_path 2 -setup -end -from [get_cells reg_a] -to [get_cells reg_b]
# Example using explicit start (less common for multi-cycle paths involving CDC):
# set_multicycle_path 2 -setup -start -from [get_cells reg_a] -to [get_cells reg_b]
The most common scenario for multi-cycle paths is when the number of clock cycles of the capture clock is specified, ensuring that the data arrives sufficiently in advance of the capture event.
While SDC doesn't have a single "default format" in the same way a file format might, there are common conventions and best practices:
- File Extension: SDC files typically have a
.sdc extension.
- Comments: Comments start with
#.
- Scope: Constraints can be applied globally or scoped to specific hierarchies, nets, or pins using options like
-object, -hierarchy, or by specifying paths in -from/-to.
- Clock Definitions: SDC often begins with clock definitions using
create_clock and create_generated_clock commands.
- Timing Exceptions: After clocks are defined, timing exceptions like
set_multicycle_path, set_false_path, set_max_delay, and set_min_delay are declared.
- Input/Output Delays:
set_input_delay and set_output_delay are used for I/O ports.
- Units: Time units are defined using
set_units, but they are usually implicit based on the clock period.
- Hierarchy: Constraints often target specific parts of the design hierarchy, e.g.,
set_multicycle_path ... -from [get_cells my_module/reg_a] ....
References
댓글
댓글 쓰기