CTS Design Tips: How can wiring engineers fully "control" clock signals?

In digital circuit design, a clock signal is a signal that oscillates between high and low states and determines the performance of the circuit. In applications, logic may be triggered on the rising edge, the falling edge, or both. Since there are many cases of overflowing a given clock domain, it is necessary to insert a buffer tree to adequately drive the logic. Clock trees usually come with delay, skew, minimum power, and signal integrity requirements that routing engineers must meet.

When a circuit is transferred from a front-end designer to a back-end layout engineer, the clock overview and diagrams can be considered the most critical information that must be communicated. Over the years, hours, days, and even weeks of design work have been wasted due to miscommunication, requiring a full re-synthesis including the clock tree.

Prior to routing, use excellent clocks for synthesis and timing constraints. Constrained clock definitions may appear at the top pad or pin of a module; may appear at the output of a macro such as a delay-locked loop (DLL) or phase-locked loop (PLL); or appear as a generated clock on a divide register. These clock definitions may or may not be areas where routing engineers need to define clock tree roots to obtain optimal delays and balance skew between different operating modes. High-level communication of information between the front-end process and routing engineers around this information, as well as understanding how routing engineers use this information, will greatly optimize the CTS process of the physical design flow.

Design Tips for Effective CTS

Some of the following tips have been used in the industry for many years, but based on experience over the past few years, it is still worth repeating.

Use medium to high strength drivers for the clock tree root. This allows the clock tree to have an appropriate starting point. However, do not use the highest driver strength in the library, which can be used in subsequent designs if signal integrity (SI) analysis or variation on chip (VOC) analysis does not reveal problems.

If the clock divide register and its synchronization register are to be operated in separate test modes, ensure that they are driven specifically by the multiplexing logic. This allows the addition of delays at the inputs in test mode without affecting all other registers driven by the clocks generated in this functional mode.

The (divide-by) registers are not balanced with any downstream registers. The smaller number of registers in the green domain will result in a much faster clock speed than in the purple domain.

Figure 1 Register Clock Divide Register Figure 2 shows the multiplexing mechanism that makes it possible for each bank of downstream registers and divide registers to have a very small clock through one input of the multiplexer and a balanced clock through the other input of the multiplexer.

Figure 2 Downlink register and division register multiplexing mechanism

If needed, insert dedicated reset drivers. In some cases, several registers will be used to synchronize reset. Those registers may not need to be balanced by the same register. In Figure 3, since a centralized strategy is not used, the software will try to balance the blue registers after the gating logic, while each pink register is included in the reset synchronization logic.

Figure 3. Register after balanced gating logic

This situation is easily handled during routing if they are separated from other registers in their own dedicated drivers. Figure 4 shows how placeholder or exclusion buffers can be inserted and easily identified during the design hand-off communication process, allowing the routing engineer to know where balance problems may occur.

Figure 4 Inserting and easily identifying placeholders or exclude buffers

Provide more clock diagrams and extensive clock profiles than expected. When the pre-process design is ready to provide a netlist for routing, they are already very familiar with the design and clock requirements. In some cases, the initial CTS design will indicate situations where the ideal values ​​used in the pre-routing timing constraints are not achievable in the actual physical design. If an accurate clock diagram and netlist handoff with information about the clocking philosophy are provided, the problem causing this situation can be identified faster.

An overall diagram or a diagram that represents all the clocks in the design (including gating logic) is very useful. This can be either a drawing software, a diagram generated using software such as a schematic capture tool, or even a hand-drawn diagram saved as a PDF document or faxed to a layout engineer. This diagram is worth a thousand words during multiple phone calls or email exchanges trying to get the clock formats straight.

Because the diagrams can be complex and cumbersome, they need to be documented with the generated clocks, details of any clock gating or multiplexing patterns, and explanations of skew balance and delay requirements. These details are needed for each mode of operation because each mode must be accounted for during clock tree insertion. Registers may end up providing balance for functional mode, but can be wildly unbalanced in test mode if we are not careful.

If the clock uses a DLL or other macro or it passes through gating logic, these details are necessary. It is possible to synthesize and balance with those types of macros if necessary. For gating logic, if there is a situation where a pin is connected with one pattern, but other pins of the same cell are connected with another pattern, the routing tool will identify this as a "reconvergent clock". Although the routing tool can solve these problems, a better solution may be to force the tool to look at this pin instead of other pins during timing insertion. CTS in Industry Software Tools

Industry software follows the designer's specifications and guidelines to drive clock tree synthesis with powerful tools. Information from the previous process related to clock tree root insertion points, delays, skewness and transition targets, as well as detailed information for gated logic, through registers and cross-domain relationships can be directly ported to the CTS tool. The routing engineer will then make their own judgments on the type of buffer to use, optimize iterations and routing requirements such as spacing, screens and metal layers.

Before inserting the clock tree, routing can be used to ensure that the endpoints intended for balancing exist. Gating logic, branches excluded from the clock tree root, IO endpoints, and reconvergence instances can also be prompted and evaluated.

The clock tree may consist of only buffer cells or a series of inverters. Most technologies today have special clock buffer and clock inversion cells that provide balanced rise and fall times to help ensure that the duty cycle is not compromised. Other requirements may also be incorporated, such as the maximum fan-out of the level or individual clock cells in the clock tree.

in conclusion

In addition to all the factors discussed above, the routing engineer will most likely try clock gating-aware placement, clock routing guidelines, and floorplan adjustments. CTS replacement is usually run with minimal adjustments to skew, delay, and transition targets. Trial and error helps provide excellent coordination. If the previous process understands how CTS works and the clock structure is communicated at the beginning, the routing engineer will be able to take over the task more easily. Time originally planned for CTS in the schedule can be used to fine-tune and improve "your clock" instead of simply trying to insert it into "my routing."