The bus skew constraint is used to set a maximum skew requirement between several
asynchronous CDC paths. The bus skew is not the traditional clock skew associated with a
timing path. Instead, it corresponds to the largest capture time difference across all
the paths that are covered by a same set_bus_skew
constraint. The bus
skew requirement applies to both Fast and Slow corners, but it is not analyzed across
the corners.
The intent of the bus skew constraint is to limit the number of source clock edges that can launch a data and be captured by a single destination clock edge. The tolerance depends on the CDC synchronization scheme used for the constrained paths. The bus skew constraint is typically used for the following CDC topologies:
- Gray-coded bus transfer, such as in asynchronous FIFOs
- Multi-bit CDC implemented with CE, MUX, or MUX Hold circuitry
- Configuration registers
Although the set_bus_skew
command does not prevent a bus skew constraint
to be set on a safely timed synchronous CDC, such a constraint is not needed. The setup
and hold checks already ensure a safe transfer between two safely timed synchronous CDC
paths.
The CDC scenarios for bus skew constraints are:
- Asynchronous CDC covered with
set_clock_groups
- Asynchronous CDC entirely covered with
set_false_path
and/orset_max_delay -datapath_only
- Synchronous CDC paths covered with
set_false_path
and/orset_max_delay -datapath_only
The bus skew constraint is not a timing exception; rather, it is a timing assertion.
Therefore, it does not interfere with the timing exceptions
(set_clock_group
, set_false_path
,
set_max_delay
, set_max_delay -datapath_only
, and
set_multicycle_path
) and their precedence.
The bus skew constraint is only optimized by the route_design
command.
To report the set_bus_skew
constraints, use the
report_bus_skew
command from the command line or from the GUI. The bus skew constraints are not reported inside the Timing
Summary report (report_timing_summary).