Introduction to delay modeling

Preface

Delay modeling is covered by Verilog quite extensively. In terms of blocks, delays can be modeled on any level from single gates to the top of a hierarchy. That is thanks to the language which allows to define simple delays such as found in basic gates as well as lumped delays which are an overall effect of more complex combinational constructs. There are even conditional delays which are useful for circuits with multiplexed outputs. In terms of logic, delays of all states are fully modeled i.e. not only rise and fall times, but also switch-off transition. Delays can also be defined as worst, best and typical cases. This is a very powerful tool for design for manufacturability.

To give a simple introduction to the world of delays, the foregoing paragraphs discuss usage of predefined gate delays.

The concept of delay

A delay, as used in Verilog, is a number of time units it takes to receive a response of a circuit. In a simple forward combinational circuit this is a time it takes to obtain a change on an output when an input is altered. If a system is clocked then the clock is not counted as a source of delay. Let's say a synchronous circuit is triggered by a positive clock transition; `the delay' is then the time it takes for the circuit to change its outputs from the time the clock line is set high rather then a time it takes to change the outputs since data lines altered. To word it differently, delays in Verilog are defined as in asynchronouse circuits.

Here is a diagram showing a relationship between real world signals and how they are represented in a Verilog script.

Types of delays

There are three basic types of delay which can be used:

the time it takes to set an output high (t_rise); this applies to a transition which may start from any (`0', `1', `X' or `Z') state
the time it takes to set an output low (t_fall); similarly, applies to transitions which begin in any state.
and finaly, the time it takes to cut-off a buffer (t_off).

The above is presented in a graphical form here. The t_on on the picture is not specified - why? - because it is already described by the t_rise and t_fall; when an output is expected to come out of the hi-Z state it will take either `t_rise' or `t_fall' units of time dependengly on what level it is supposed to reach. That is opposite to what happens when a buffer cuts-off, in which case, regardless of a starting condition, it takes `t_off' time units.

Syntax follows the below template:

gate_type #(t_rise, t_fall, t_off) gate_name (par1, par2, ...)

For example:

and #(1, 3) g1 (o1, i1, i2);

nor #(2) g2 (o2, i3, i4);

bufif #(3, 4, 6) g3 (o3, i5, i6);

The above parameters are specified in sequence and if a cut-off time is to be specified the fall time cannot be omitted. The previously mentioned mechanism of `Z->X' and `X->Z' transitions is ilustrated in this simple example. One more interesting transition is a move of an input from a defined logic state i.e. either `0' or `1' to an `X' (don't care). In such case, the shortest of the two times - t_fall, t_rise- is used. For an inverse case (`X'->`0'|`1') the longer delay is used.

Minimum, typical & default values

Each of the parameters discussed above can be additionaly specified at their minimum, default and maximum values. As mentioned in the preface, this is very important when desinging for manufacturability.

For those of you who prefer diagrams, here is a little one which attempts to visualise how a delay may vary.

The syntax to specify those parameters is shown below:

gate_type #(t_rise-min:t_rise-default:t_rise-max,

t_fall-min:t_fall-default:t_fall-max,

t_off-min: t_off-default: t_off-max) gate_name (par1, par2, ...)

And again, let's illustrate it with an example:

and #(1:2:3, 1:3:4) g1 (o1, i1, i2);

bufif #(3, 2:4:6, 7:6:9) g2 (o1, i1, i2);

As you may have noticed it is not required to specify all parameters for all delays, however, if you decide to specify t_rise as min:def:max values you must specify them all i.e. you cannot skip minimum value and give only default and maximum.

Notice the cut-off time of the gate g2; the minimum time does not have to be less then the default time, similarly, neither the default has to be less then the maximum. Of course, it is not logical to make a minimum value greater then a default, but it may be very useful for tracking down race or other ill conditions.

In order to make verilog take into account the additional parameters it has to invoked with one of the optional switches, either +maxdelays or +mindelays, for instance:

localserver> verilog +maxdelays my_simulation.v

Try the same example, but rewritten to include different delays.