How to specify SGDC / CDC constraints?

Before running Spyglass CDC flow, we need to provide some inputs to Spyglass. One of the most important inputs is SGDC constraints. Usually, in SGDC constraints, designers are required to specify:

  1. Current design, to limit the scope of CDC check
  2. List of source clocks and generated clocks
  3. List of valid abstract port / input constraints. Designers can derive these constraints from SDC such as “set_input_delay
  4. List of valid output constraints. Designers can derive these constraints from SDC such as “set_output_delay
  5. List of valid clock groups constraints. Designers can derive these constraints from SDC such as “set_clock_group”. Unlike STA, CDC flow by default assumes all clocks are asynchronous to each other, and it will attempt perform CDC check against all clock pairs. Designers shall use “set_clock_groups” to specify which clock pair is synchronous, thus CDC check is not required for such clock pair.

Continue reading → How to specify SGDC / CDC constraints?

What to check before running synthesis?

We discussed a general DC synthesis flow in previous post, and there are several things we need to check before actually running “compile_ultra”:

  1. Design should be fully read in by DC, and there shall be no black boxes or missing libraries
  2. Review linting issues, for example, no unexpected undriven inputs and outputs without loading, no bit width mismatch, no wire loop, no combo loop, etc.
  3. The SDC needs to be loaded correctly by DC, for example, use “report_timing_requirements -ignored” to check for invalid exceptions
  4. The SDC needs to be complete, for example, there is no missing clock, no un-clocked registers, no unconstrained ports, etc. Use “check_timing” command to check the completeness of SDC
  5. Optionally, designers can direct DC not to use ULVT / ELVT cells. This leaves more timing margin in place and route

Designers should check all listed items above, in order to get good synthesis results.

In some companies, such checks are performed automatically, and any error or warning will be captured in dashboards.

How to set mutually exclusive synchronous clock design constraints?

If there exists mutually exclusive synchronous clocks in the design, designers have several ways to specify the exclusivity of the clocks:

set_case_analysis
set_false_path
set_clock_groups -logically_exclusive
set_clock_groups -physically_exclusive

“set_case_analysis” is the most straightforward way, and it constrains which clock will propagate through. However, it leads to different timing modes, and increases tool total runtime.

For false paths or “exclusive” clock paths, DC will not optimize timing for them, and STA will not check timing for them either.

“set_false_path” is usually not preferred, since it can introduce undesired timing exceptions. False path still impacts the SI analysis.

“set_clock_groups” is the most recommended one, but there are some differences between “-logically_exclusive” and “-physically_exclusive”. “-physically exclusive” does not consider SI effect, while “-logically_exclusive” does.

Continue reading → How to set mutually exclusive synchronous clock design constraints?

How to set generated clock design constraints in Post-CTS run?

We discussed how to set multi-synchronous-clock design constraints, and we will look at how to define clock propagated through sequential logic or macros.

For clocks propagated through sequential logic or macros such as PLL, we need to define generated clocks. The first step, is to define the master clock or the source clock of the generated clock:

Continue reading → How to set generated clock design constraints in Post-CTS run?

How to set generated clock design constraints in Pre-CTS run?

We discussed how to set multi-synchronous-clock design constraints, and we will look at how to define clock propagated through sequential logic or macros.

For clocks propagated through sequential logic or macros such as PLL, we need to define generated clocks. The first step, is to define the master clock or the source clock of the generated clock:

Continue reading → How to set generated clock design constraints in Pre-CTS run?

How to set multi-synchronous clock design constraints?

We have covered single-clock design constraints for Pre-CTS run and Post-CTS run. In this post, we will look at a more interesting scenario: constraining multi-synchronous-clock design.

How to Constrain Multiple Clock Input Delay?

Let’s assume, the design uses clock “CLKC” with period of 2ns, and the register driving the inputs of the design uses clock “CLKB” with period 3ns. Both “CLKC” and “CLKB” are divided from the same reference clock.

Thus we can define “CLKC” as master clock and “CLKB” as virtual clock to the design, and set input delay accordingly.

Continue reading → How to set multi-synchronous clock design constraints?

How to set interface constraints for single-clock design in Pre-CTS run?

Specifying only clock constraints is not enough for timing analysis. STA tool needs to understand the timing information with each input or output port. Note, there are slight differences about how to set interface constraints in Post-CTS run, and we will cover those in another post.

How to Specify Input / Output Delay?

The following example shows how to specify input port delay as if the input port is driven by a register.

The following example shows how to specify output port delay as if the output port drives a register.

Continue reading → How to set interface constraints for single-clock design in Pre-CTS run?