At this point we will have to go into some more detail about timing. During different stages of the de-sign flow, we have slightly different timing constraints (Refer to the following figure for the differences in the three stages).
a) synthesis initially the design does not contain any pads. The input delay tideland the output delay todel should contain the contribution of the input tinpadand output toutpadpads.
b) pre-CTS during placement and routing phase, all required I/O pads and drivers will be present.
At this stage there is no clock tree present. The timing should be adjusted, as at this moment the input delay tideland output delay todel no longer include the pad delays.
c) post-CTS once the clock tree is inserted, the timing will change slightly again. Due to the clock insertion delay tdi the internal clock will be slightly offset when compared to the external clock.
At the input, the data travelling towards the first flip-flop inside the chip, will have more time, since this flip-flop will be trigerred by a clock signal that has been delayed by tdi. At the output however, the data that is coming from the chip will be launched with the internal clock, but will have to be sampled by the external clock. Consequently there will be less time for this signal.
It should now be clear why it might be desirable to set constraints on the clock insertion delay property by specifying minimum and maximum values in the chip.ctstch file by MinDelay and MaxDelay parameters. The clock insertion delay can play an important part in the I/O delay. You may want to keep the insertion delay within certain limits to ensure proper I/O timing.
Design tools have different mechanisms to deal with these three different cases. The simple solution is to use multiple constraint files for different stages. However, both SYNOPSYS DESIGN COMPILER
and CADENCE SOC ENCOUNTER accept several parameters to deal with this problem automati-cally. In the following we will discuss on how CADENCE SOC ENCOUNTER calculates delays in the presence and absence of clock tree. The following table summarizes the most important settings:
timing analysis mode clock propagation mode clock latency (setAnalysisMode) (set propagated clock) (set clock latency)
-noSkew forced ideal no effect
-skew -noClockTree forced ideal SDCs in effect -skew -clockTree SDCs in effecta SDCs in effectb
a still ideal mode unless set propagated clock is set
b set clock latency command is overridden by overlapping set propagated clock constraints
The timing analysis mode is automatically updated by CADENCE SOC ENCOUNTER to match the design stage, i.e. before clock tree insertion it is set to ’-skew -noClockTree’ and afterwards to
’-skew -ClockTree’. The analysis mode can also be changed manually with the setAnalysisMode command.
The two synopsys design constraints (SDC) set_propagated_clock and set_clock_latency are usually specified by the designer in the chip.sdc file. Furthermore, CTS tries to add a
set_propagated_clock constraint on-the-fly (in memory), which can cause a number of prob-lems:
• This constraint will only be added if the AutoCTSRootPin pin/port in chip.ctstch and the clock waveform source pin/port (from the create_clock command in chip.sdc) are perfectly identi-cal, i.e. not port vs. instance pin etc.
• This constraint is never written to your chip.sdc file, so if you reload that file the constraint is lost.
• Before CTS, only a pointer to your constraints file is saved along with the database. Now, if a constraint was added by CTS, all loaded constraints (including the new one) will be saved along with the database to a new file (*.pt). Restoring this database will then load this new constraints file instead of the one in encounter/src/ that you might have expected.
Note: As soon as you manually (re-)load a constraints file, the behavior is reverted to the normal one.
Now, as can be seen from the table above, to get the actual timing of the buffers/inverters on the clock tree instead of ideal mode, setting both ’-skew -ClockTree’and set_propagated_clock is required. Also note that set_propagated_clock gets overridden for all pre-CTS design stages and could therefore be set right from the start (as already mentioned earlier).
In ideal mode, the clock tree insertion delay is zero unless the set_clock_latency command is used to specify a different number, preferably close to the delay of the real tree (that is still to be inserted). While this ”placeholder” delay has the advantage that the I/O timing doesn’t change between pre-CTS and post-CTS phases, it renders timing reports more intransparent and is not handled exactly the same across different tools. Therefore, do not use this command unless you know what you are doing.
In conclusion, it is recommended to include set_propagated_clock right from the start,not use set_clock_latencyand load modified timing constraints after CTS only if required, i.e. when the I/O timing numbers (set_input_delay, set_output_delay) need to be adjusted to account for the actual clock tree29. For this training we will modify and reload the constraints30.
29 For slower clock speeds and/or uncritical I/O timing this is often not required.
30 It might be more convenient to keep a separate post-CTS constraint file rather than changing the numbers back and fourth when redoing the flow.
tinpad toutpad
todel tidel
Tclk
tin2reg treg2reg treg2out
tdi
tin2reg treg2reg treg2out
Tclk Tclk
tin2reg treg2reg treg2out
Tclk Tclk
The previous figure illustrates all three stages in some detail. Whereever possible the same naming conventions as the textbook have been used31
31 Refer to page 235 “How to formulate timing constraints”, and page 346 “How to achieve friendly input/output timing ” for more on this topic
Student Task 31:
• Copy your timing constraints file to filter_chip_postCTS.sdc and then modify the I/O timing constraints to account for the insertion delay of the actual clock tree, make sure that the clock is set to PROPAGATED MODE and load the constraints (Timing →Load \ Timing Constraint ...a)
• Run timing analysis (make sure to select POST-CTS as design stage).
• Examine the reports timingReports/chip postCTS*. You should now see the real timing on the clock network.
• If you have violations, run a POST-CTS (!) optimization with default settings. This should fix all violations.
• Save the entire design.
a Currently loaded constraints will be purged before the new ones get loaded.