In any design, the most critical part of synthesis is the clock description. There are always issues concerning the pre and post-layout definitions.
Traditionally in the past, big buffers were placed at the source of the clock to drive the full clock network. Thick clock spines were used in the layout for even distribution of clock network delays and to minimize clock skews. Although this method sufficed for sub-micron technologies, it is miserably failing in the VDSM realms. The interconnect RC’s currently account for a major part of total delay. This is mainly due to the increase in resistance of the shrinking metal widths. It is difficult, if not impossible to model clocks using the traditional approach.
With the arrival of complex layout tools, capable of synthesizing clock trees, the traditional method has changed dramatically. Since, layout tools have the cell placement information, they are best equipped to synthesize the clock trees. It is therefore necessary to describe clocks in DC, such that it imitates the clock delays and skews of the final layout.
For reasons explained above, it is best to estimate the clock tree latency and skew during the pre-layout phase. To do this, use the following commands:
dc_shell-t> create_clock –period 40 –waveform {0 20}C LK
dc_shell-t> set_clock_latency 2.5 CLK
dc_shell-t> set_clock_uncertainty –setup 0.5 –hold 0.25 CLK
dc_shell -t> set_clock_transition 0.1 CLK
dc_shell -t> set_dont_touch_network CLK
dc_shell -t> set_drive 0 CLK
For the above example, a delay of 2.5 ns is specified as the overall latency for the clock signal CLK. In addition, the set_clock_uncertainty command approximates the clock skew. One can specify different numbers for the setup and hold time uncertainties by using –setup and –hold options as exemplified above.
Furthermore, specification of clock transition is essential. This restricts the max transition value of the clock signal. The delay through a cell is affected by the slope of the signal at its input pin and the capacitive loading present at the output pin. The clock network generally feeds large endpoints. This means, that although the clock latency value is fixed, the input transition time of the clock signal to the endpoint gates will still be slow. This results in DC calculating unrealistic delays (for the endpoint gates), even though in reality, the post-routed clock tree ensures fast transition times.
Defining clocks after layout is relatively easy, since the user does not need to worry about the clock latency and skews. They are determined by the quality of the routed clock tree.
Some layout tools provide direct interface to DC. This provides a smooth mechanism for taking the routed netlist consisting of clock tree, back to DC. If this information is not present, then the user should extract the clock latency and the skew information from the layout tool. Using the pre-layout approach, this information can be used to define the clock latency and clock skew, as described before. If however, the netlist can be ported to DC, then the following commands may be used to define the clocks. For example:
dc_shell-t> create_clock -period 40 -waveform [list 0 20] CLK
dc_shell-t> set_propagated_clock CLK
dc_shell-t> set_clock_uncertainty -setup 0.25 -hold 0.05 CLK
dc_shell-t>set_dont_touch_network CLK
dc_shell-t> set_drive 0 CLK
Notice the absence of the set_clock_latency command and the inclusion of set_propagated_clock command. Since, we now have the clock tree inserted in the netlist, the user should propagate the clock instead of fixing it to a certain value. Similarly, the set_clock_transition command is no longer required, since DC will now calculate the input transition value of the clock network, based on the clock tree. In addition, a small clock uncertainty value may also be defined. This ensures a robust design that will function taking
into account a wider process variance.
Some companies do not possess their own layout tools, but they rely on outside vendors to perform the layout. This situation of course varies from one company to the other. If the vendor provides the user, the post-routed netlist containing the clock tree, then the above method can be utilized. In some instances, instead of providing the post-routed netlist, the vendor only supplies the SDF file containing point-to-point timing for the entire clock network (and the design). In such a case, the user only needs to define the clock for the original netlist and back-annotate the SDF to the original netlist without propagating the clock. The clock skews and delays will be determined from the SDF file, when performing static timing analysis.
