Modeling skew requirements for interfacing protocol signals in an SoC

Modeling skew requirements for interfacing protocol signals in an SoC

Technology News |
By eeNews Europe

A system on a chip (SoC) today consists of several different microprocessor subsystems, memories and support for I/O interfaces such as JTAG, Ethernet, DSPI, SENT etc for communication with the outside world – see Figure 1.

Fig. 1: SoC interfacing with the outside world through I/O protocols.

All these are universally accepted and have some timing requirements which may be in form of input/output delay requirements or special timing requirements (like transition and skew requirements for different signals), which need to be taken care of at the STA
end. In this article, we will be focusing on one of these – maximum and minimum skew between two signals.

Some of these protocols (like DDR) have requirement for a finite maximum skew (difference in delays) between the various signals of a bus. All data has to change within a very small timing window. On the contrary, minimum skew requirement is
generally specified to prevent the race condition between two signals. This is usually one sided; e.g. signal ‘a’ should follow ‘b’ after some finite time. Until recently, these skew requirements were modeled in a roundabout manner and had to be updated
regularly which adversely impacted the STA analysis time of each database as there were multiple iterations for IO constraints maturity. Also, the constrained signals’ timing may get deteriorated during optimization in the absence of constraints on these signals. There can be different ways of implementing this using multiple command combinations. Each has its own merits and demerits. Let’s look at three methods to achieve this purpose:

– Applying minimum/maximum delay constraints on data signals
– Modeling as input/output delays
– Applying setup/hold checks considering one of the data signals as reference signal

Applying minimum/maximum delay constraints

We can apply min and max delay constraints on data signals so that data changes only within a given window. This method can be used to constrain multiple signals for skew requirement as discussed below. We are essentially assuming these signals to
have some characteristic delay range, which is a pure assumption or based on prior experience. The EDA command to apply min/max delay is:

set_min_delay/set_max_delay <delay_value> signal

A data bus can be constrained to be within a specific window by constraining each bit signal with min and max delays (where max_delay > min_delay) – see Figure 2.

Fig. 2: Constraining signals to be within window by applying min/max delays.

set_min_delay <min_delay_value> data_bus[*]
set_max_delay <max_delay_value> data_bus[*]

The maximum skew requirement window will then be:

Max_skew_requirement = Max_delay_value – Min_delay_value

Similarly, the timing requirement for minimum skew can be justified by applying max_delay constraint to one signal (the one which is to occur first) and min_delay constraint to the other (the one which is to occur later – see Figure 3).

Fig. 3: Constraining signals for minimum skew by applying min/max delay constraints.

set_max_delay <smaller_value> signal_1
set_min_delay <larger_value> signal_2


Min_skew_requirement = Min_delay_value – Max_delay_value

The application of min/max delays offers some advantages, the uncertainty values applied on path don’t need to be taken into account and delays can be modified in any of the data signal path as long as the above conditions are met. This method, however, faces some limitations as it takes a couple of iterations to decide upon the values of the min-max delay.

Fig. 4: Constraining signals to be within window by applying input/output delays.

It is important to keep the values slightly pessimistic (compared to the expected optimized value of delay) in the first iteration so as to efficiently optimize the path delay as well. The values need to be updated as well after such iteration based on how much the tool was able to optimize the delay.

Also, the values need to be updated at regular intervals as we make transitions across the stages since delay values change. As delays of nets and cells scale across process, voltage and temperature variations, min/max path delays will be different
across these. We have to calculate scaling factors across corners and constrain these accordingly.

Constraining IOs by modeling input/output delays

 In this method, we define the relationship of interface signals with respect to some clock. We may use it to implicitly define skew requirement by defining input/output delays of different signals with respect to same clock such that they are constrained to have the required skew. Basically, by defining input and output delays, we are defining setup and hold timings of the signals in the SoC as seen from the outer world. The designer just needs to constrain these by defining valid and invalid windows. I/Os may be constrained in EDA tools using the following commands:

set_input_delay/set_output_delay <delay_value> port_name –min/-max

To constrain signals to be within a timing window (maximum skew requirement) using this technique, we need to define setup and hold checks (min and max input delays) for all signals with respect to the same clock such that all signals are allowed to change nowhere except the required window – as shown in Figure 4.

Considering both signals to be input signals,

max_input_delay = clock_period –setup_requirement
min_input_delay = hold_requirement

Under the condition

setup_check_for_signal1 + hold_check_for_signal2 <
clock_period &
setup_check_for_signal2 + hold_check_for_signal1 <

Similarly, we can constrain the signals for minimum skew requirement.
For this, following condition should be kept in mind (for signal1 to follow signal2 – see Figure 5):

Setup_check_for_signal1 + hold_check_for_signal2 >

We can, thus, write as shown below:

set_input_delay <max_input_delay> signal2 –max
set_input_delay <min_input_delay> signal1 –min

Fig. 5: Constraining signals for minimum skew by applying
input/output delays.

In a similar way, we can constrain the output signals too for skew requirement by applying output delays as we constrained by applying input delays in case of input signals.

If the data signals are constrained like this, the constraints can be applied at synthesis/implementation too as input/output delays are supported by all synthesis and implementation tools.  Manual iterations are very few. On the other hand, for defining
these checks, we need to have one reference clock. If we do not have a clock defined for the protocol, we cannot define these. Also, since regular setup and hold checks are also to be met, it becomes quite complex and confusing to calculate the amount of min and max delays to be applied.

Although the range of input and output setup times is fixed, there needs to be made some adjustments within this range, based upon the path delays and placement of the protocol logic inside the SoC. As in min/max delay, due to delay variations across PVTs, these checks need to be adjusted for different PVTs.

Applying setup/hold checks

The most effective way for constraining the signals with respect to maintaining a skew between them is to apply data checks between them. According to the definition of data-to-data check, it is applied between two signals, neither of which is a clock. Here, we can consider one of the signals as a reference and define other signal’s relationship with respect to it. The port having the reference signal becomes ‘reference port’ whereas the other port, i.e. the port which is constrained, becomes the ‘constrained port’. This method is different from the method described above in the sense that we do not need to define the reference data as a clock here.

Data check is similar to normal setup/hold check. An important difference is that data check is performed on the same edge as the launch flop (in normal setup check, capture edge is one edge away from launch edge). That is why, data to data checks are known as ‘zero cycle checks’.

A data-to-data check may be specified using ‘set_data_check’ command in EDA tools.

set_data_check –from <reference_port> -to <constrained_port> <value> -setup/-hold

To constrain the signals for minimum skew requirement, we can simply apply data-to-data setup check (to constrain reference port to come later) or data-to-data hold check (to constrain the reference signal to come earlier), since data-to-data
setup check is zero cycle – see Figure 6.

Fig. 6: Constraining signals for minimum skew requirement by applying data-to-data setup check.

To constrain the reference signal to come later,

set_data_check <skew_requirement> -from <reference_signal> -to <constrained_signal> -setup

To constrain the reference signal to come earlier,

set_data_check <skew_requirement> -from <reference_signal> – to <constrained_signal> -hold

On the contrary, to constrain the signals to be within a window, both setup and hold checks need to be applied – see Figure 7. Also, the values to be applied have to be negative. In addition, a multicycle of -1 for hold needs to be applied.

Fig. 7: Constraining signals to be within a window by applying
data-to-data checks.

The combination of commands to be applied is as follows:

set_data_check -<skew_requirement>/2 –from <reference_signal> -to <constrained_signal> -setup
set_data_check -<skew_requirement>/2 –from <reference_signal> -to <constrained_signal> -hold
set_multicycle_path -1 –to <constrained_port> –from <reference_port> -hold

Constraining the signals for skew requirement using data-to-data checks has several merits. As mentioned above, it is the simplest way to apply these types of constraints. Only relative skew between the signals matters while the signals themselves may have any value of delay. Unlike input/output delay method, there is no need for a clock to be present and the window requirement does not need to be updated across corners.
However, uncertainty and derate values need to be taken into account, if applied.

Though data-to-data checks provide a robust and efficient way to apply these constraints, still there is some scope of improvement. Like it does take into account the uncertainties and derate, whereas the requirements specified are without any
uncertainties and derates. So, we have to either make these windows larger taking into account uncertainties and derates; or we need to have support in EDA tools for path based derates and uncertainties.

About the authors

Hans Kumar Jain is Lead Design Engineer at Freescale Semiconductor India –

Gourav Kapoor and Babul Anunay also work at Freescale Semiconductor India as Design Engineers.

If you enjoyed this article, you will like the following ones: don't miss them by subscribing to :    eeNews on Google News


Linked Articles