THE VLSI HOMEPAGE

A Practical Guide to VLSI Design and Verification..

On chip variation and CRPR

Posted in Static Timing Analysis by Nigam on the September 27th, 2007

Static timing analysis in a chip is largely dependent on Process, Temperature and Voltage variations (PVT), the cell delays and interconnect delays vary largely with these factors. Hence it is necessary to run timing analysis in both worst and best case operating conditions and ensure we meet setup/hold requirements for the chip.

For worst case corners, we specify the chip running at high temperature, low voltage and a slow process (high cap). For best case corner, the voltage is high, temperature is low and a fast process (low cap). Setup is more problematic in slow corner because of larger cell/interconnect delays and hold is more problematic in the fast corner.

Another factor that needs to be considered during timing analysis is on-chip variation (OCV). On a single chip, there can be variations for two exactly similar gates due to other variables during manufacturing process. This variation can be anywhere between 8-12% and needs to be included in timing analysis for a more accurate and foolproof picture.

To add OCV analysis in Synopsys Primetime, we use timing derate factor for min/max cases (8-12%) as shown below. This specifies that the min paths can be faster than the max paths by 40% !

set_timing_derate –min 0.8 –max 1.2

Next, we use the “on_chip_variation” switch as shown below to enable OCV

set_operating_conditions -analysis_type on_chip_variation

However, if you look at the reports carefully, you will notice that Primetime is overtly pessimistic i.e. if there is a common branch of clock tree between launch and capture flops, Primetime varies this clock tree delay depending on OCV (for example, for setup analysis, it will slow down the common clock tree branch delay for launch flop and will fasten the same branch to capture flop!)

To counter this, Clock Reconvergence Pessimism Removal (CRPR) feature is added in Primetime. CRPR is enabled by using the command below

set timing_remove_clock_reconvergence_pessimism true

By enabling this feature, Primetime looks at the common logic in clock and data path, removes the difference between their max and min delays thus projecting a more realistic picture.

For more details on OCV and CRPR, please refer to the paper at the link below.

On Chip Variation Analysis

 

 

 

Sphere: Related Content

Input and Output Delays in Primetime

Posted in Static Timing Analysis by Nigam on the September 15th, 2007

Following the review of setup and hold time analysis in previous post, we will now cover timing analysis at the primary pins of the chip. The IO pins are constrained using input and output delays. We will look at an example to constrain IOs in a design using Synopsys Primetime, the widely used static timing analysis tool.

Input and Output delays in Primetime

Input and Output constraints for a chip

In the figure above, we have RXD (the data) being clocked by RXC (period = 8ns), both being primary inputs to the chip. The input specification for this interface in our chip is 4 ns setup and 1 ns hold. The RXC input clock is clock tree buffered and clocks an output flop. The TXD and TXC are primary outputs of the chip and the output specification is a max delay of 5 ns and min delay of 1 ns.

In primetime, the set_input_delay command specifies the data arrival time at the port with respect to a clock. The set_output_delay command specifies the data required time at the port with respect to a clock.

We need to define the clock at the input using create_clock and make it a propagated clock so that primetime can propagate the input through all the buffers to the external TXC output.

create_clock -name rxc -period 8 -waveform “0 4″ [get_ports RXC]
set_propagated_clock [get_clocks rxc]

To constrain the RXD input wrt RXC clock for setup, we define the maximum external delay allowable (i.e. period - setup requirement = 8 - 3 = 5 ns)

set_input_delay 5 -max -clock [get_clocks rxc] [get_clocks rxc]

For the hold constraint, we specify the hold requirement as is.

set_input_delay 1 -min -clock [get_clocks rxc] [get_clocks rxc]

For output constraints, we need to create a generated clock source at the output pin TXC. This is necessary since without this generated clock the latency of the TXC clock source is discarded which is incorrect.

create_generated_clock -name txc -source [get_ports RXC] -divide_by 1 [get_ports TXC]

The output port TXD is constrained with delays external to the chip i.e.

set_output_delay 3 -max -clock [get_clocks txc] [get_ports TXD]
set_output_delay -1 -min -clock [get_clocks txc] [get_ports TXD]

Note the negative sign for min output delay, this is because a larger hold requirement means that you must specify a more negative output delay. If you apply the hold requirement as a positive amount, the constraint will be incorrectly relaxed by double that amount. This could cause the hold check to pass when there is really a violation.

Always be careful while defining input/output constraints and check the reports to ensure that the IOs are constrained correctly.

Sphere: Related Content

Setup and Hold times

Posted in Static Timing Analysis by Nigam on the September 13th, 2007

Many designers are familiar with setup and hold time definitions - however, few can identify correctly the launch and capture edges and the slack/violation between two flops during timing analysis. In this post, we will cover setup/hold times in a design with clear examples.

Setup time is defined as the minimum amount of time BEFORE the clock’s active edge by which the data must be stable for it to be latched correctly. Any violation in this minimum required time causes incorrect data to be captured and is known as setup violation.

Hold time is defined as the minimum amount of time AFTER the clock’s active edge during which the data must be stable. Any violation in this required time causes incorrect data to be latched and is known as hold violation.

The setup time in a design determines the maximum frequency at which the chip can run without any timing failures. Factors affecting the setup analysis are the clock period Tclk, Clock to Q propagation delay of the launch flop Tck->q, negative clock skew Tskew, required setup time of the capture flop Tfs and combinational logic delay Tcomb between the two flops being timed. The following condition must be satisfied.

Tfs <= Tclk – Tck->q – Tskew – Tcomb

Hold analysis depends on the Tck->q, combinational logic delay, the clock skew and the hold time requirement Tfh of the capture flop. It is independent of the frequency of the clock. The condition below must be satisfied.

Tck->q + Tskew + Tcomb >= Tfh

Consider the figure below depicting a flop to flop path in the same domain with some combinational logic between them. We will now calculate the setup and hold time slacks in the design based on the given timing parameters.

Setup and Hold time Illustration

Setup and Hold time illustration - Full cycle transfer

For setup checks in single cycle paths, the clock edges that are relevant is shown in the Figure above. The data required time for the capture flop B to meet setup is

Data Required time = (Clock Period + Clock Insertion Delay + Clock Skew - Setup time of the flop) = 8 + 2 + 0.25 -0.1 = 10.15 ns

The data arrival time from the launch flop is

Data Arrival time = (Clock Insertion Delay + CK->Q Delay of the launch flop + Combinational logic Delay) = 2 + 0.1 + 5 = 7.1 ns.

Setup slack is

Setup Margin = Data Required Time - Data Arrival Time = 10.15 - 7.10 = 3.05 ns

 

Similarly for hold checks assuming the hold time requirement of the flop B is 100 ps, the data expected time is

Data expected time = (Clock Insertion Delay + Clock skew + Hold time requirement of flop) = 2 + 0.25 +0.1 = 2.35 ns.

So the hold time slack is

Hold Margin = Data Arrival time - Data expected time = 7.10 - 2.35 = 4.85 ns

Consider the case where the clock to flop B is inverted (or that the flop is negative edge trigerred). In this particular case, the relevant edges for setup/hold are as shown in the figure below.

Setup and Hold Illustration - 2

Setup and Hold time illustration - Half cycle transfer

 

In this scenario, the setup margin considering all the other parameters to be the same is

Data Required time = (half_clock_period + clock insertion delay + Ck->Q delay of flop A - Setup time required for flop B) = 4 + 2 + 0.25 -0.1 = 6.15 ns

Since the Data Arrival time remains the same, there is a setup violation of

Setup violation = 6.15 ns - 7.10 ns = -1.05 ns

There is no hold violation since the data arrival time remains the time but the data expected time is any time after (Clock skew + Hold time requirement of flop B)

Data expected time = 0.25 + 0.1 = 0.35 ns

Hold Margin = 7.10 - 0.35 = 6.75 ns

All clear now ? We will cover IO constraints next.

Sphere: Related Content


Close
E-mail It