Clock Distribution Techniques

https://www.slideshare.net/KaushalPanchal1/clock-distribution-41503463

https://www.slideshare.net/vlsisyst/vlsi-academy-clock-tree-synthesis?next_slideshow=1

Clocking:

The clock distribution network is the metal and buffer network that distribute clock to all clocked segment.

A clock generator is a circuit that produces a timing signal for use in synchronizing a system's operation.

Primary challenges in clock distribution:

1. Need to support higher clock frequency based on the strong correlation between frequency and chip performance.
2. Process technology scaling allows higher level of integration and larger die size leading to higher clock loading and larger distances the clock network need to traverse.

Main factors effect clock distribution:

1. Skew:
1.  It is a phenomenon in synchronous circuits in which the clock signal arrives at different components at different times.
2. Clock skew is due to the unbalanced of the data.
3. Strategies to remove skew:
1. Locate all clock inputs close together; but it is difficult to implement in a large circuit.
2. Drive them from the same source & balance the delays.
2. Jitter: It is the cycle time variation of consecutive clock periods.
3. Power dissipation:
1. Clock node consumes more power than any other nodes on the chip.
2. Clock tree dissipate 40% of total power.

Clock Distribution Topologies:

1. Unconstrained Tree:
1. No constraints imposed on buffers and wires.
2. Used mostly by automatic tools in automatic synthesis flows.
3. Can be used for small blocks within large design.

2. Balanced Tree:
1. The length of interconnects is identical from the source node to the 2 destination nodes.
2. The primary delay difference among the clock signal paths is due to the variations of process parameters affection
1. Interconnect impedance
2. Characteristics of buffer
3. This structure is difficult to implement in practice due to:
1. Routing constraints
2. Different fan-out requirements.

3. Central Spine:
1. It is a specific implementation of a binary tree.
2. The clock can be transported in a balanced fashion across one dimension of the die with low structural skew.

4. Spines with matched branches:
1. An extension of the central spine structure can be realized by replacing the unconstrained end-of-distribution branches with delay matched routes.
2. The longest branch determines the delay from the output of the central spine to the end loads.

5. Grid:
1. The clock grid resembles a mesh with fully connected clock tracks in both dimensions and grid drivers located on all 4 sides.
2. Usually a custom implementation, simple to build
3. Insensitive to load changes
4. Dissipate more power.

6. Hybrid distribution:
1. It is the combination of all the topologies.
2. Common configurations are spine-grid distribution or tree-grid distribution
3. It employs a multilevel H-tree driving a common grid.

Exception Type Priority:

Exception Type Priority:The following pairs of timing exception types are not considered to be in conflict, so both
settings can be valid for a path:
• Two set_false_path settings
• set_min_delay and set_max_delay settings
• set_multicycle_path -setup and -hold settings
In case of conflicting exceptions for a particular path, the timing exception types have the
following order of priority, from highest to lowest:
1. set_false_path2. set_max_delay and set_min_delay3. set_multicycle_pathFor example, if you declare a path to be false and also set its maximum delay to some value,
the false path declaration has priority. The maximum delay setting is ignored. You can list
ignored timing exceptions by using the report_exceptions -ignored command.

Setting Maximum and Minimum Path Delays:

By default, PrimeTime calculates the maximum and minimum path delays by considering the clock edge times. To override the default maximum or minimum time with your own specific time value, use the set_max_delay or set_min_delay command.

For example, to set the maximum path delay between registers REGA and REGB to 12, use this command:

pt_shell> set_max_delay 12 -from [get_cells REGA] -to [get_cells REGB]

With this timing exception, PrimeTime ignores the clock relationships. A path delay between these registers that exceeds 12 time units minus the setup requirement of the endpoint register is reported as a timing violation. Similarly, to set the minimum path delay between registers REGA and REGB to 2, use this command:

pt_shell> set_min_delay 2.0 -from [get_cells REGA] -to [get_cells REGB]

Again, PrimeTime ignores the clock relationships. A path delay between these registers that is less than 2 time units plus the hold requirement of the endpoint register is reported as a timing violation. You can optionally specify that the delay value apply only to rising edges or only to falling edges at the endpoint.

Be sure to select a valid path startpoint with the -from or similar option and a valid path endpoint with the -to or similar option unless you want to override the paths checked by PrimeTime. If you specify an invalid startpoint or endpoint, PrimeTime performs the timing check exactly as specified and ignores the remaining valid portion of the timing path.

Applying such an exception on a clock path prevents propagation of the clock forward from the point where the exception is applied. PrimeTime issues a UITE-217 warning message when you specify an invalid startpoint or endpoint.

set_false_path vs set_disable_timing

What is false path?

A false path is a logic path that exists but should not be analyzed for timing. For example, a path can exist between two multiplexed logic blocks that are never selected at the same time, so that path is not valid for timing analysis.

For example, to declare a false path from pin FFB1/CP to pin FFB2/D:

pt_shell> set_false_path -from [get_pins FFB1/CP]  -to [get_pins FFB2/D]

Declaring a path to be false removes all timing constraints from the path. PrimeTime still

calculates the path delay, but does not report it to be an error, no matter how long or short

the delay.


What is set_disable_timing?

Setting a false path is a point-to-point timing exception. This is different from using the

set_false_path command, which disables timing analysis for a specified pin, cell, or

port. Using the set_disable_timing command removes the affected objects from timing

analysis, rather than removing the timing constraints from the paths.

When set_disable_timing is preferred to set_false_path?

If all paths through a pin are false, using set_disable_timing [get_pins pin_name] is more efficient than

using set_false_path -through [get_pins pin_name]. Because PT calculates path delay in case of set_false_path


Another example of a false path is a path between flip-flops belonging to two clock domains that are asynchronous with respect to each other.
To declare all paths between two clock domains to be false, you can use a set of two
commands such as the following:

pt_shell> set_false_path -from [get_clocks ck1] -to [get_clocks ck2]pt_shell> set_false_path -from [get_clocks ck2] -to [get_clocks ck1]

For efficiency, be sure to specify each clock by its clock name, not by the pin name (useget_clocks, not get_pins).

An alternative is to use the set_clock_groups command to exclude paths from consideration that are launched by one clock and captured by another. Although this has the same effect as declaring a false path between the two clocks, it is not considered a timing exception and is not reported by the report_exceptions command.