wait statement.

  • Thread starter [LinuxFc4]GaLaKtIkUs™
  • Start date
L

[LinuxFc4]GaLaKtIkUs™

Guest
Hi!
can some one give me a clear explanation of the wait statement.
Why trying to execute an instance of this module is wrong ? the
simulator stops at the first positive clock edge.

module level_sens_latch (q, d, clock);
output reg q;
input d,clock;
always wait (clock) q = d;
endmodule // level_sens_latch

Thanks for help.
 
[LinuxFc4]GaLaKtIkUs™ wrote:
Hi!
can some one give me a clear explanation of the wait statement.
Why trying to execute an instance of this module is wrong ? the
simulator stops at the first positive clock edge.

module level_sens_latch (q, d, clock);
output reg q;
input d,clock;
always wait (clock) q = d;
endmodule // level_sens_latch

Thanks for help.
Click to expand...
This is what's wrong:

always wait (clock) q=d;

as soon as clock becomes high, q=d is evaluated. What follows is that
the simulator goes back to the top of the alway block, since there's no
timing delay inserted. Now evaluate wait(clock) - oh, clock is still
high, so do q=d again. It's an infinite loop. One way to resolve this
infinite loop is to insert real timing delays after q=d, such as this:

always
begin
wait (clock);
q = d;
#(CLK_PERIOD/1.9);
end

But that might not be what you really want. Why don't you tell me what
you are trying to design? Is this supposed to be a behavrial model of a
level-sensitive latch?
 
Yes ... it's simply a level-sensitive latch !!!
I modified my model as this :
module level_sens_latch (q, d, clock);
output reg q;
input d,clock;
always
begin
wait (clock) q = d;
#1;
end
endmodule // level_sens_latch

it seems to work fine.

Please explain me how you code and how my new code is executed by the
simultor.
 
I found the solution:
CITATION FROM (VERILOG HDL:A GUIDE FOR DIGITAL DESIGN AND SYNTHESIS by
Samir Palnitkar)- A forever loop is typically used in conjunction with
timing control constructs. If timing control constructs are not used,
the Verilog simulator would execute this statement infinitely without
advancing simulation time and the rest of the design would never be
executed - END OF CITATION.

[LinuxFc4]GaLaKtIkUs™ wrote:
Hi!
can some one give me a clear explanation of the wait statement.
Why trying to execute an instance of this module is wrong ? the
simulator stops at the first positive clock edge.

module level_sens_latch (q, d, clock);
output reg q;
input d,clock;
always wait (clock) q = d;
endmodule // level_sens_latch

Thanks for help.
Click to expand...
 
[LinuxFc4]GaLaKtIkUs™ wrote:
Yes ... it's simply a level-sensitive latch !!!
I modified my model as this :
module level_sens_latch (q, d, clock);
output reg q;
input d,clock;
always
begin
wait (clock) q = d;
#1;
end
endmodule // level_sens_latch

it seems to work fine.

Please explain me how you code and how my new code is executed by the
simultor.
Click to expand...
That might work, but you are confined to a timing resolution of 1 unit.
If q changes within the 1 unit of time of waiting, d won't get the changes.
Perhaps this is what you wanted:

always @ (q)
if (clock) d=q;

clock is essentially an enable signal to the latch.
 
Jason Zheng wrote:

always @ (q)
if (clock) d=q;

clock is essentially an enable signal to the latch.
why should I put q in the sensitivity list ??
Click to expand...
perhaps you meant :
always @ (d)
if (clock) q=d;

In the book cited above, the was an exercise which asked to model a
level-sensitive latch using the wait statement.

Jason Zheng wrote:
That might work, but you are confined to a timing resolution of 1 unit.
If q changes within the 1 unit of time of waiting, d won't get the changes.
Click to expand...
Newbie question: are there times < 1 unit in the simulator ?
 
[LinuxFc4]GaLaKtIkUs™ wrote:
Jason Zheng wrote:


always @ (q)
if (clock) d=q;

clock is essentially an enable signal to the latch.

why should I put q in the sensitivity list ??
perhaps you meant :
always @ (d)
if (clock) q=d;
Click to expand...
You are right, I got them backwards.

<<snip>>

Newbie question: are there times < 1 unit in the simulator ?
Click to expand...
Suppose you have specified your timescale like this:

`timescale 1ns/100ps

then you can do #0.1 to advance 100ps instead of 1ns
 
"Jason Zheng" <xin.zheng@jpl.nasa.gov> wrote in message news:deic4k$gqk$1@nntp1.jpl.nasa.gov...
GaLaKtIkUs™ wrote:
Jason Zheng wrote:


always @ (q)
if (clock) d=q;

clock is essentially an enable signal to the latch.

why should I put q in the sensitivity list ??
perhaps you meant :
always @ (d)
if (clock) q=d;

You are right, I got them backwards.
Click to expand...
Actually, since a 'latch' has combinational behavior, you probably will want to put the 'clock' on the sens list too :

always @ (d or clock)
if (clock) q = d ;

otherwize you will get simulation/synthesis differences
 
I know that !!
But the exercise imposed the use of a wait statement !!
Thanks for interest !!
 
Jason Zheng wrote:
Newbie question: are there times < 1 unit in the simulator ?

Suppose you have specified your timescale like this:

`timescale 1ns/100ps

then you can do #0.1 to advance 100ps instead of 1ns
Than it would be interestin to do that:
Click to expand...

module level_sens_latch (q, d, clock);
`timescale 1ns/100ps
output reg q;
input d,clock;
always
begin
wait (clock) q = d;
#`timescale;
end
endmodule // level_sens_latch
 
[LinuxFc4]GaLaKtIkUs™ wrote:
Than it would be interestin to do that:

module level_sens_latch (q, d, clock);
`timescale 1ns/100ps
output reg q;
input d,clock;
always
begin
wait (clock) q = d;
#`timescale;
end
endmodule // level_sens_latch
Click to expand...
Have you tried to compile this code? I'm not sure if #`timescale is
valid syntax.
 
Actually, since a 'latch' has combinational behavior, you probably will want to put the 'clock' on the sens list too :

always @ (d or clock)
if (clock) q = d ;

otherwize you will get simulation/synthesis differences
Click to expand...
Point taken, but this a behaviral model, not RTL, so it will never be
synthesized.
 
Jason Zheng wrote:
otherwize you will get simulation/synthesis differences

Point taken, but this a behaviral model, not RTL, so it will never be
synthesized.
Click to expand...
In this case, "simulation/synthesis differences" is a euphemism for
"wrong simulation behavior". If you don't include the enable in the
sensitivity, then when the data changes while the enable is false, the
output will not update when the enable goes true and the latch becomes
transparent. Since this is incorrect behavior for a transparent latch,
this is not a correct behavioral model for a transparent latch.
 
This would be very inefficient to simulate. When the latch was
transparent, the always block would be evaluated again and again,
looping and re-evaluating once for each #1 of simulation time. With a
properly written model, the always block will only be evaluated when
one of the inputs changes so the output could actually change.
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top