Modelling propagation delay

[Kenneth Brun Nielsen]

A quick question from a newbie:

I have a signal toggling every 5'th time unit. How can I delay that
signal with more than 5 time units?

Eg. in the following example, I want to skew the SCK signal (read from
file) with 9 units. In my simulator (Icarus), this does not work as
intented. I assume, that the reason is, that the delay is longer than
the toggling frequency(?):

"""""""""
module test_tb;

reg MOSI, SCK, SS;

integer fd;
integer r,cycleNo;

reg SCKi;
reg SSi;
reg MOSIi;

initial
fd = $fopen("vectors.txt","r");
while (!$feof(fd))
begin
r = $fscanf(fd, " %1b %1b %1b\n",SSi,MOSIi,SCKi);
@ cycleNo;
end //while
$finish
end //module

always #5 cycleNo = cycleNo+1;

always @ (SSi) #4 SS = SSi;
always @ (MOSIi) #4 MOSI = MOSIi;
always @ (SCKi) #9 SCK = SCKi;

endmodule
"""""""

Any suggestions?

 

[Jonathan Bromley]

On Tue, 30 Jun 2009 03:21:02 -0700 (PDT), Kenneth Brun Nielsen wrote:

A quick question from a newbie:

I have a signal toggling every 5'th time unit. How can I delay that
signal with more than 5 time units?

Eg. in the following example, I want to skew the SCK signal (read from
file) with 9 units. In my simulator (Icarus), this does not work as
intented. I assume, that the reason is, that the delay is longer than
the toggling frequency(?):

Right.

always @ (SCKi) #9 SCK = SCKi;

When SCKi toggles for the first time - let's say
that happens at time 10 - the #9 time delay begins.
You don't get back to the @(SCKi) until time 19.
By that time, the second transition on SCKi has
been and gone, and you don't respond to it.
You *will* see the third transition, at time 20.
So I guess SCK follows the first transition and
then gets stuck?

You have two choices:

(1) Use a continuous assignment with a delay on it.

assign #9 SCK = SCKi; // SCK must be a wire, of course

This introduces an "inertial delay". Pulses shorter than
9 time units will be ignored. Pulses longer than 9 time
units will be delayed by 9 time units. The effect is
very similar to that of a 9 time unit RC delay.
Probably not what you want here; if SCKi is toggling
every 5 time units, you'll see no output on SCK.

(2) Use nonblocking intra-assignment delay:

always @(SCKi) SCK <= #9 SCKi;

This is a "transport delay". Every transition on SCKi
will be faithfully reproduced 9 time units later on SCK.
The effect is the same as a 9 time unit delay line.
The nonblocking assignment does not delay execution of
the code - it merely postpones the update on SCK.
Consequently, execution can get back to the @(SCKi)
event control immediately and you don't miss any of
the action. You then end up with more than one
postponed update on SCK. All these postponed updates
will take effect at their appointed times.

Option (2) is great for modeling pure time delay.
Its one big disadvantage is that it gives you
no way of cancelling or rescinding the scheduled
future updates on the output signal. If that's
OK for you, then it's the right solution.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[Kenneth Brun Nielsen]

On 30 Jun., 15:05, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:

On Tue, 30 Jun 2009 03:21:02 -0700 (PDT), Kenneth Brun Nielsen wrote:

When SCKi toggles for the first time - let's say
that happens at time 10 - the #9 time delay begins.
You don't get back to the @(SCKi) until time 19.
By that time, the second transition on SCKi has
been and gone, and you don't respond to it.
You *will* see the third transition, at time 20.
So I guess SCK follows the first transition and
then gets stuck?

Exactly.

(2) Use nonblocking intra-assignment delay:

   always @(SCKi) SCK <= #9 SCKi;

This is a "transport delay".  Every transition on SCKi
will be faithfully reproduced 9 time units later on SCK.
The effect is the same as a 9 time unit delay line.
The nonblocking assignment does not delay execution of
the code - it merely postpones the update on SCK.  
Consequently, execution can get back to the @(SCKi)
event control immediately and you don't miss any of
the action.  You then end up with more than one
postponed update on SCK.  All these postponed updates
will take effect at their appointed times.

Option (2) is great for modeling pure time delay.
Its one big disadvantage is that it gives you
no way of cancelling or rescinding the scheduled
future updates on the output signal.  If that's
OK for you, then it's the right solution.

Option (2) is perfect. Thanks for the solution and the detailed
explanations.

Best regards,
Kenneth