Simulation behavior for TestBench and UUT

[V.]

At the top test bench level, I have something like this:

PROCESS(clk, rst)
BEGIN
IF (rst = '1') THEN
mytmp <= '1';
ELSIF RISING_EDGE(clk) THEN
IF (busy = '1') THEN
mytmp <= '0';
END IF;
END IF;
END PROCESS;

At the top level, mytmp signal goes low on the same rising edge as my clock.

--

I then repeat this code within my UUT (still instantiated by same testbench), but now mytmp signal goes low on the following rising edge clock after busy is asserted.

I am sure I am missing something very elementary here, could someone help me out?


Thanks.

 

[V.]

On Tuesday, October 21, 2014 9:05:29 AM UTC-5, Gabor Sz wrote:

V. wrote:

At the top test bench level, I have something like this:



PROCESS(clk, rst)

BEGIN

IF (rst = '1') THEN

mytmp <= '1';

ELSIF RISING_EDGE(clk) THEN

IF (busy = '1') THEN

mytmp <= '0';

END IF;

END IF;

END PROCESS;



At the top level, mytmp signal goes low on the same rising edge as my clock.



--



I then repeat this code within my UUT (still instantiated by same testbench), but now mytmp signal goes low on the following rising edge clock after busy is asserted.



I am sure I am missing something very elementary here, could someone help me out?





Thanks.



You say "the same rising edge as my clock" which doesn't say anything

to me. Do you mean that in the test bench there is no delay from the

assertion of "busy" to "mytmp" going low? How is busy driven in the

test bench? How is it driven in the UUT? My guess is that one has

a simple time-based driver and the other gets it (after a delta delay)

from an edge-triggered process.



--

Gabor

On Tuesday, October 21, 2014 9:05:29 AM UTC-5, Gabor Sz wrote:

V. wrote:

At the top test bench level, I have something like this:



PROCESS(clk, rst)

BEGIN

IF (rst = '1') THEN

mytmp <= '1';

ELSIF RISING_EDGE(clk) THEN

IF (busy = '1') THEN

mytmp <= '0';

END IF;

END IF;

END PROCESS;



At the top level, mytmp signal goes low on the same rising edge as my clock.



--



I then repeat this code within my UUT (still instantiated by same testbench), but now mytmp signal goes low on the following rising edge clock after busy is asserted.



I am sure I am missing something very elementary here, could someone help me out?





Thanks.



You say "the same rising edge as my clock" which doesn't say anything

to me. Do you mean that in the test bench there is no delay from the

assertion of "busy" to "mytmp" going low? How is busy driven in the

test bench? How is it driven in the UUT? My guess is that one has

a simple time-based driver and the other gets it (after a delta delay)

from an edge-triggered process.



--

Gabor

On Tuesday, October 21, 2014 9:05:29 AM UTC-5, Gabor Sz wrote:

V. wrote:

At the top test bench level, I have something like this:



PROCESS(clk, rst)

BEGIN

IF (rst = '1') THEN

mytmp <= '1';

ELSIF RISING_EDGE(clk) THEN

IF (busy = '1') THEN

mytmp <= '0';

END IF;

END IF;

END PROCESS;



At the top level, mytmp signal goes low on the same rising edge as my clock.



--



I then repeat this code within my UUT (still instantiated by same testbench), but now mytmp signal goes low on the following rising edge clock after busy is asserted.



I am sure I am missing something very elementary here, could someone help me out?





Thanks.



You say "the same rising edge as my clock" which doesn't say anything

to me. Do you mean that in the test bench there is no delay from the

assertion of "busy" to "mytmp" going low? How is busy driven in the

test bench? How is it driven in the UUT? My guess is that one has

a simple time-based driver and the other gets it (after a delta delay)

from an edge-triggered process.



--

Gabor

Sorry , I had meant to say:
"At the top level, mytmp signal goes low on the same rising edge as busy".

As you say, there is no delay from the assertion of "busy" to "mytmp" going low.

---

Busy is generated by UUT (via clocked process), and sent out as an output to the testbench. It is essentially the same signal.

The clk signal is also generated internally by UUT, and sent out to testbench. I'm using Modelsim as my simulator if it makes a difference.

 

[GaborSzakacs]

V. wrote:

At the top test bench level, I have something like this:

PROCESS(clk, rst)
BEGIN
IF (rst = '1') THEN
mytmp <= '1';
ELSIF RISING_EDGE(clk) THEN
IF (busy = '1') THEN
mytmp <= '0';
END IF;
END IF;
END PROCESS;

At the top level, mytmp signal goes low on the same rising edge as my clock.

--

I then repeat this code within my UUT (still instantiated by same testbench), but now mytmp signal goes low on the following rising edge clock after busy is asserted.

I am sure I am missing something very elementary here, could someone help me out?


Thanks.

You say "the same rising edge as my clock" which doesn't say anything
to me. Do you mean that in the test bench there is no delay from the
assertion of "busy" to "mytmp" going low? How is busy driven in the
test bench? How is it driven in the UUT? My guess is that one has
a simple time-based driver and the other gets it (after a delta delay)
from an edge-triggered process.

--
Gabor

 

[KJ]

On Tuesday, October 21, 2014 9:47:11 AM UTC-4, V. wrote:

At the top test bench level, I have something like this:

PROCESS(clk, rst)
BEGIN
IF (rst = '1') THEN
mytmp <= '1';
ELSIF RISING_EDGE(clk) THEN
IF (busy = '1') THEN
mytmp <= '0';
END IF;
END IF;
END PROCESS;

At the top level, mytmp signal goes low on the same rising edge as my clock.


I then repeat this code within my UUT (still instantiated by same testbench),
but now mytmp signal goes low on the following rising edge clock after busy
is asserted.

I am sure I am missing something very elementary here, could someone help me out?

What you're missing is that when your testbench code hits the line 'IF (busy = '1') THEN...' the rising edge of the clock has already occurred and the subsequent assignment to 'mytmp' will not occur until one simulation delta after the rising edge of the clock. Now consider the UUT. If 'mytmp' does not change until after the rising edge of the clock then really it won't be looked at again until the NEXT rising edge. In order to see this more clearly, simply change the assignment to 'mytmp' to include some non-zero delay like this 'mytmp <= '0' after 2 ns;'. Your testbench and UUT will respond identically based on what you described.

But before you go thinking that you somehow need to curse simulation deltas realize that what you're describing in the code you posted is a form of a flip flop where 'busy' is an input. The 'D' input to a flip flop always switches on the previous clock cycle relative to the 'Q' output of that flip flop. There is nothing inherently wrong here unless the protocol of your signals is that 'mytmp' should occur on the same clock cycle as 'busy'. If that's the case, then 'mytmp' should be a concurrent statement, not inside a clocked process.

Kevin Jennings

 

[GaborSzakacs]

V. wrote:

Sorry , I had meant to say:
"At the top level, mytmp signal goes low on the same rising edge as busy".

As you say, there is no delay from the assertion of "busy" to "mytmp" going low.

---

Busy is generated by UUT (via clocked process), and sent out as an output to the testbench. It is essentially the same signal.

The clk signal is also generated internally by UUT, and sent out to testbench. I'm using Modelsim as my simulator if it makes a difference.

Then you need to see how the UUT generates the clock going back to the
test bench. If the clock and the busy signal are generated at the same
time, then you have in effect a race condition. If your UUT is supposed
to drive this (in real hardware) to another device that requires setup
and hold time with respect to the generated clock, you need to fix your
design that there is some real delay in the busy output.

--
Gabor

 

[Nicolas Matringe]

Le 21/10/2014 16:46, V. a ĂŠcrit :
[loads of snipped useless lines]

Sorry , I had meant to say:
"At the top level, mytmp signal goes low on the same rising edge as busy".

As you say, there is no delay from the assertion of "busy" to "mytmp" going low.

Did you really need to quote the whole thread (with added blank lines,
courtesy of this piece of sh*t that's Google groups) just to add these
three lines ?

Nicolas