When writing testbench, do I need to add some time for the i

[Ray]

say in the fool.v, i have signal a0 goes through a flipflop:
always @(posedge clk) begin
a1 <= a0;
end

in the testbench, when I use modelsim
I found the a1 didn't get delay, if my tb.v is like this:

initial begin
clk = 1;
a0 = 4'h0;
end
always #5 clk = ~clk;

initial begin
#10 a0 = 4'hf;
end

I found the a1 will be 4'hf at time 10 ns. But I would like it to be
4'hf at time 20 ns. The results are not consistent. When I have this
simple module simulated, a1 is 4'hf at time 20 ns. But when I included
this module into a very large module (instantiate this module from the
large module), then I found a1 is 4'hf at time 10 ns.

So I changed the tb.v to

initial begin
#11 a0 = 4'hf;
end

I delayed the a0 signal by 1 ns to avoid to change the value at the
exact time of posedge clk. Then this time I found both results are
correct. I'm just curious I didn't have this problem before. Why I got
this problem this time? Do you have similar experience? How to
simulate with flipflops? Thanks! -Ray

 

[Jonathan Bromley]

On Wed, 21 Nov 2007 00:26:43 -0800 (PST), Ray
<changjian.gao@gmail.com> wrote:

[...]

I delayed the a0 signal by 1 ns to avoid to change the value at the
exact time of posedge clk. Then this time I found both results are
correct. I'm just curious I didn't have this problem before. Why I got
this problem this time? Do you have similar experience?

Would you regard it as sensible to change the value of a *real*
flip-flop's input at exactly the same time as you trigger its
clock? Or would you, like me, think of that as a setup/hold
violation?

I'm just curious you think it might even be sensible.

BTW, you don't need a time delay. Nonblocking assignment
would be sufficient:

initial begin
clock = 0;
D <= 0;
#5 clock = 1; // flipflop will see D==0
D <= 1; // change occurs just *after* clock,
// too late for flipflop to see it
#5 clock = 0;
#5 clock = 1; // on this edge, flipflop will see D==1
D <= <something else>;
...
end

--
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.

 

[glen herrmannsfeldt]

Jonathan Bromley wrote:

(snip)

Would you regard it as sensible to change the value of a *real*
flip-flop's input at exactly the same time as you trigger its
clock? Or would you, like me, think of that as a setup/hold
violation?

If it had 0ns hold time...

I'm just curious you think it might even be sensible.

I remember digital electronics lab from many years ago, learning
that the 7474 had a positive hold time, but the 74LS74 had 0ns
hold time. We would make T ff's wiring Qbar to the D input.
(Maybe 0.1ns of wire.)

I believe 0ns hold time is usual for FPGAs.

(They delay the clock enough to make it work.)

-- glen

 

[Jonathan Bromley]

On Wed, 21 Nov 2007 19:06:22 -0800,
glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:

Would you regard it as sensible to change the value of a *real*
flip-flop's input at exactly the same time as you trigger its
clock? Or would you, like me, think of that as a setup/hold
violation?

If it had 0ns hold time...

Yes, but the point is that even 0ns hold time on a FF
would be insufficient guarantee if the data transition
were to occur at *exactly* the same instant as the clock.
Zero hold time, combined with causality (FFs can't possibly
begin to change their output until at least the time of
the clock edge) and an assumption of zero-skew clock
distribution, makes it possible to specify a zero
*minimum* clock-to-output delay on the FFs. Vendors
rightly hate specifying non-zero minimum delay times,
because process and design changes that in other respects
are improvements may breach the minimum delays.

Your direct Q->D connection works (for me too) because
not only does the FF have a specified zero hold time,
but Q exhibits at least *some* delay after each clock.
That's why I pointed out to the OP that he could have
used nonblocking assignment to his stimulus, while using
blocking assignment to the clock. That's why RTL
works at all.
--
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.