Electronic – ASIC timing constraints via SDC: How to correctly specify a multiplexed clock

clockconstraintssdctiming

Introduction

Having found multiple, sometimes conflicting or incomplete information on the internet and in some training classes about how to create timing constraints in SDC format correctly, I'd like to ask the EE community for help with some general clock generating structures I have encountered.

I know that there are differences on how one would implement a certain functionality on an ASIC or FPGA (I have worked with both), but I think there should be a general, correct way to constrain the timing of a given structure, independent of the underlying technology – please let me know if I'm wrong on that.

There are also some differences between different tools for implementation and timing analysis of different vendors (despite Synopsys offering a SDC parser source code), but I hope that they are mainly a syntax issue which can be looked up in the documentation.

Question

This is about the following clock multiplexer structure, which is part of the clkgen module which is again part of a larger design:
Clock multiplexer schematic

While the ext_clk input is assumed to be generated externally to the design (entering through an input pin), the clk0 and clk4 signals are also generated and used by the clkgen module (see my related ripple clock question for details) and have associated clock constraints named baseclk and div4clk, respectively.

The question is how to specify the constraints such that the timing analyser

Treats cpu_clk as a multiplexed clock which can be either one of the source clocks (fast_clk or slow_clk or ext_clk), taking the delays through the different AND and OR gates into account
While at the same time not cutting the paths between the source clocks which are used elsewhere in the design.

While the simplest case of an on-chip clock multiplexer seems to require just the set_clock_groups SDC statement:

set_clock_groups -logically_exclusive -group {baseclk} -group {div4clk} -group {ext_clk}

…in the given structure, this is complicated by the fact that clk0 (via the fast_clk output) and clk4 (via slow_clk) are still used in the design, even if cpu_clk is configured to be ext_clk when only use_ext is asserted.

As described here, the set_clock_groups command as above would cause the following:

This command is equivalent to calling set_false_path from each clock
in every group to each clock in every other group and vice versa

…which would be incorrect, since the other clocks are still used elsewhere.

Additional Information

The use_clk0, use_clk4 and use_ext inputs are generated in such a way that only one of them is high at any given time. While this could be used to stop all clocks if all use_* inputs are low, the focus of this question is on the clock multiplexing property of this structure.

The X2 instance (a simple buffer) in the schematic is just a place-holder to highlight the issue of automatic place&route tools being usually free to place buffers anywhere (such as between the and_cpu_1/z and or_cpu1/in2 pins). Ideally, the timing constraints should be unaffected by that.

Best Answer

Define divide by 1 clocks on the and_* nets and declare them to be physically exclusive. Cadence RTL compiler handles the situation correctly by generating 3 timing paths for registers clocked by cpu_clk (one path each for one clock). Registers directly driven by clk0, clk4 and clk_ext have their own timing arcs.

create_generated_clock -source [get_ports clk0] \
-divide_by 1 -name and_clk0    [get_pins and_cpu_1/Y]

create_generated_clock -source [get_ports clk4] \
-divide_by 1 -name and_clk4    [get_pins and_cpu_2/Y]

create_generated_clock -source [get_ports clk_ext] \
-divide_by 1 -name and_clk_ext [get_pins and_cpu_ext1/Y]

set_clock_groups \
-physically_exclusive \
-group [get_clocks and_clk0] \
-group [get_clocks and_clk4] \
-group [get_clocks and_clk_ext]

Related Solutions

Electronic – timing constraint for bus synchronizer circuits

I don't have experience with Quartus, so treat this as general advice.

When working on paths between clock domains, timing tools expand the clocks to the least common multiple of their periods and select the closest pair of edges.

For paths from a 36 MHz clock (27.777 ns) to a 100 MHz clock (10 ns), if I did my quick calculations correctly, the closest pair of rising edges is 138.888 ns on the source clock and 140 ns on the destination clock. That's effectively a 900 MHz constraint for those paths! Depending on rounding (or for clocks with no relationship), it could come out worse than that.

There are at least three ways to write constraints for this structure. I am going to call the clocks fast_clk and slow_clk as I think that's clearer for illustration.

Option 1: disable timing with set_false_path

The easiest solution is to use set_false_path to disable timing between the clocks:

set_false_path -from [get_clocks fast_clk] -to [get_clocks slow_clk]
set_false_path -from [get_clocks slow_clk] -to [get_clocks fast_clk]

This is not strictly correct, since there are timing requirements for the synchronizer to work correctly. If the physical implementation delays the data too much relative to the control signal, then the synchronizer will not work. However, since there isn't any logic on the path, it's unlikely that the timing constraint will be violated. set_false_path is commonly used for this kind of structure, even in ASICs, where the effort vs. risk tradeoff for low-probability failures is more cautious than for FPGAs.

Option 2: relax the constraint with set_multicycle_path

You can allow additional time for certain paths with set_multicycle_path. It is more common to use multicycle paths with closely related clocks (e.g. interacting 1X and 2X clocks), but it will work here if the tool supports it sufficiently.

set_multicycle_path 2 -from [get_clocks slow_clk] -to [get_clocks fast_clk] -end -setup
set_multicycle_path 1 -from [get_clocks slow_clk] -to [get_clocks fast_clk] -end -hold

The default edge relationship for setup is single cycle, i.e. set_multicycle_path 1. These commands allow one more cycle of the endpoint clock (-end) for setup paths. The -hold adjustment with a number one less than the setup constraint is almost always needed when setting multi cycle paths, for more see below.

To constrain paths in the other direction similarly (relaxing the constraint by one period of the faster clock), change -end to -start:

set_multicycle_path 2 -from [get_clocks fast_clk] -to [get_clocks slow_clk] -start -setup
set_multicycle_path 1 -from [get_clocks fast_clk] -to [get_clocks slow_clk] -start -hold

Option 3: specify requirement directly with set_max_delay

This is similar to the effect of set_multicycle_path but saves having to think through the edge relationships and the effect on hold constraints.

set_max_delay 10 -from [get_clocks fast_clk] -to [get_clocks slow_clk]
set_max_delay 10 -from [get_clocks slow_clk] -to [get_clocks fast_clk]

You may want to pair this with set_min_delay for hold checks, or leave the default hold check in place. You may also be able to do set_false_path -hold to disable hold checks, if your tool supports it.

Gory details of edge selection for multi-cycle paths

To understand the hold adjustment that gets paired with each setup adjustment, consider this simple example with a 3:2 relationship. Each digit represents a rising clock edge:

1     2     3
4   5   6   7

The default setup check uses edges 2 and 6. The default hold check uses edges 1 and 4.

Applying a multi-cycle constraint of 2 with -end adjusts the default setup and hold checks to use the next edge after what they were originally using, meaning the setup check now uses edges 2 and 7 and the hold check uses edges 1 and 5. For two clocks at the same frequency, this adjustment makes sense — each data launch corresponds with one data capture, and if the capture edge is moved out by one, the hold check should also move out by one. This kind of constraint might make sense for two branches of a single clock if one of the branches has a large delay. However, for the situation here, a hold check using edges 1 and 5 isn't desirable, since the only way to fix it is to add an entire clock cycle of delay on the path.

The multi-cycle hold constraint of 1 (for hold, the default is 0) adjusts the edge of the destination clock uesd for hold checks backwards by one edge. The combination of 2-cycle setup MCP and 1-cycle hold MCP constraints will result in a setup check using edges 2 and 7, and a hold check using edges 1 and 4.

Electronic – Does it always make sense to constrain an I/O port

Well, it does make sense to apply meaningful constraints if you actually care about timing and it does matter. How to constrain it heavily depends on your design. Thankfully, Altera has tons of examples for different cases.

But if you don't care at all then the best way to go is to mark that path as a false path so that Time Quest is happy and synthesizer does not hang for hours trying to route your design in order to meet timing requirements that you don't really have. That you can do with set_false_path command. For example:

set_false_path -from * -to [get_ports { output_port }]

(where output_port is a module's top level port assigned to a pin)

If Time Quest gives you a diagnostics that not every output port has a delay, you may want to add some dummy delay as well, like this:

set_output_delay -clock [get_clocks src_clk] 2 [get_ports { output_port }]

For a more practical example, you can check out this SDC file for this top-level module, the path to led_n is market as false path there since I pretty much don't care about timing from my logic to the LEDs.

Hope it helps.