# delays

[gurvin]

hi,
i've a question regarding delays......
1)
let's say i've a signal sig1 high for 2 clocks and a signal sig2 which
is delayed version of sig1 ie
always @(posedge clk)
sig2 <= sig1;
now i would like to know the behaviour when i add delays to them on
LHS and RHS side....i mean
1)always @(posedge clk)
#2 sig2 <= sig1;
2)always @(posedge clk)
sig2 <= #2 sig1;

2) i tried this one also....
always @(negedge clk)
sig2 <= sig1;

and sig1 is generated from a task like
task
....
....
@(negedge clk);
#2 sig1 = 1'b1;
@(posedge clk);
#2;
#2 sig1 = 1'b0;

end
half clk period is 4ns....
in this sig2 is always 0 although sig1 is generated properly..
is this something related to event scheduling or ???

thx!

 

[Chris F Clark]

If you want a delyed version of another signal write a one-line
statement that does exactly that. Do not write always blocks with
sensitivities or anything complicated. Simply write:

wire clk2 = #2 clk1; // clk2 has the same value as clk1 had 2
// time-units ago.

If you don't want your declaration and assignment written in 1 statement,
write it as below:

// Same semantics as above 1 line statement.
wire clk2; // Note that you want clk2 declared as a wire and not a reg.
assign clk2 = #2 clk1; // clk2 has the same value as clk1 had 2
// time-units ago.

Hope this helps,
-Chris

*****************************************************************************
Chris Clark Internet : compres@world.std.com
Compiler Resources, Inc. Web Site : http://world.std.com/~compres
19 Bronte Way #33M voice : (508) 435-5016
Marlboro, MA 01752 USA fax : (508) 251-2347 (24 hours)
------------------------------------------------------------------------------

 

[Steven Sharp]

guruvin@yahoo.com (gurvin) wrote in message news:<a0c72cdd.0401081603.35150041@posting.google.com>...

1)
let's say i've a signal sig1 high for 2 clocks and a signal sig2 which
is delayed version of sig1 ie
always @(posedge clk)
sig2 <= sig1;

That is not what I would describe as a delayed version of sig1. It is
not delayed by a fixed time from sig1, but is delayed until the next
posedge of clk. But if sig1 is also updated on an edge of clk, sig2
might be described as being delayed by one clock from sig1. I just
want to make sure we have this clear.

now i would like to know the behaviour when i add delays to them on
LHS and RHS side....i mean
1)always @(posedge clk)
#2 sig2 <= sig1;

This is not a delay on sig2. It is a delay in the execution of the
following part of the always block. This has some of the same effect
of delaying sig2, but there are definite differences.

One of them is that you now have a hold-time requirement on sig1,
because the always block will not be reading the value of sig1 until
after the #2. Another one is that if you get another posedge of clk
while the always block is waiting for the #2, it will get ignored.
While the always block is waiting at the #2, it is not waiting at the
@(posedge clk).

2)always @(posedge clk)
sig2 <= #2 sig1;

This is a delay on the assignment of sig2. It samples sig1 when the
assignment is first executed, before the #2, so it does not require
any hold time. And the eventual assignment of the value is delayed
by the #2, but that does not block the always block from continuing
to execute and go back to waiting on the @(posedge clk) and being
triggered by another quick clock edge (which is why it is called a
nonblocking assignment).

2) i tried this one also....
always @(negedge clk)
sig2 <= sig1;

and sig1 is generated from a task like
task
....
....
@(negedge clk);
#2 sig1 = 1'b1;
@(posedge clk);
#2;
#2 sig1 = 1'b0;

end
half clk period is 4ns....
in this sig2 is always 0 although sig1 is generated properly..
is this something related to event scheduling or ???

If the half-period is 4ns (and your timescale is set so that is #4)
then you have created a race condition here. You are changing the
value of sig1 at 4ns after a posedge of clk, which is exactly the
same time that the negedge of clk is occurring. This means that
you could end up sampling either the old or new value of sig1. The
result is indeterminate.

The use of two consecutive #2 delays versus a single #4 delay could
affect the relative order of the updating of sig1 and the negedge of
clk, by affecting the order that these two events end up in the queue.
This may behave in a determinate manner in a particular simulator, but
behave differently in different simulators or with other changes in
the design. That is why it is indeterminate in the language.

If you updated sig1 using a nonblocking assignment, then it would
become determinate, since sig1 would be updated after the normal
events were processed, including the negedge of clk (assuming that
the generation of clk does not involve any nonblocking assignments).