Question to resolved signals, transport delay

Guest
Just a short question to the VHDL experts.
Assume we have the following TestBench

-------

library IEEE;
use IEEE.std_logic_1164.all;

entity TestBench is
end TestBench;

architecture behaviour of TestBench is

signal test : STD_LOGIC := '0';

begin
test <= transport '1' after 3 ns;
test <= transport '0' after 5 ns;
end behaviour;

------

Now which output wave-form is expected for "test" ?

I thought it should be:

0 at 0 ns (initial value because of declaration)
1 at 3 ns (first signal assignment becomes active).
X at 5 ns (two drivers '1' and '0', resolved to 'X').

But running it through a VHDL simulator gave

0 at 0 ns
X at 3 ns
X at 5 ns

Now I'm not at all sure why that happens and what the correct waveform
is for the "test" signal according to the VHDL2000 language reference.
Is this a bug in the VHDL simulator or what ?

Any comments ?

so long
lundril
 
Hi lundril,

lundril@gmx.de writes:

architecture behaviour of TestBench is

signal test : STD_LOGIC := '0';

begin
test <= transport '1' after 3 ns;
test <= transport '0' after 5 ns;
end behaviour;

[results in]

0 at 0 ns
X at 3 ns
X at 5 ns
Click to expand...
Every signal driver performs the following steps upon execution:

- Delete all currently scheduled events

- Add own waveform

This means that since both drivers get executed at time 0, depending
on execution order, they will overwrite each other's scheduled event
list. It happens that both drivers "agree" on a value up until
t=3ns. So everything is fine up to that time. What happens after that
is not determined and results in an undefined value.

Hope that helps,
Marcus
 
The two assignments to signal 'test' get evaluated concurrently so it's
like having two outputs driving the same signal at the same time. As
long as the two outputs are the same things look good, when they differ
you have problems...which is when the simulator is saying that they are
'X' (because one of the equations is trying to drive it to '0', the
other to '1'.)

To get the behaviour that I suspect you were looking for you need to
embed those two lines in a process and probably add some wait
statements. Changes shown below

architecture behaviour of TestBench is
signal test : STD_LOGIC := '0';

begin
process
begin
test <= transport '1' after 3 ns;
wait for 3 ns;
test <= transport '0' after 5 ns;
wait for 5 ns;
end process;
end behaviour

Alternatively, maybe you had intended for 'test' to go to '1' at t=3ns,
and then 2 ns later (at t=5 ns) have it go back to '0'. If that's the
case, then you need to simply have the following

architecture behaviour of TestBench is
signal test : STD_LOGIC := '0';
begin
test <= transport '1' after 3 ns, '0' after 5 ns;
end behaviour

Not sure exactly what you're looking for it to do, but probably one of
these two will get you moving in the correct direction. The basic
problem with your code that is causing the 'X' is having two concurrent
statements assigning to the same signal.

KJ
 
Hello KJ,
Hello Marcus,

thanks for your input. Basically I don't try to do anything useful;
I just try to understand the real insides of the VHDL driver model.

So with the code I gave I expected the waveform
0 ns => wSig = 0
3 ns => wSig = 1
5 ns => wSig = X

As far as I understand the X should be the result from the resolution
function of
STD_LOGIC which basically says that if a signal is driven by two
sources with
'1' and '0', then the resulting signal is 'X'.

(As far as I understand the VHDL spec, the second signal assignment is
completely independent from the first signal assignemt. So it doesn't
"delete"
anything from the signal waveform.
A deletion only happens if you do something like this:
-------------
signal clk : STD_LOGIC := '0';
signal aaa: STD_LOGIC;
signal bbb: STD_LOGIC;
begin
clk <= not clk after 5 ns;
aaa <= clk after 8 ns; -- will stay "U", because we don't use
"transport".
bbb <= transport clk after 8 ns; -- will be like clk only 8 ns
delayed.
-------------
)

Now what I don't understand is why I get the 'X' already at 3 ns.
So what I get is
0 ns => wSig = 0
3 ns => wSig = X
5 ns => wSig = X

I don't understand why at 3 ns I get a "X". I read the VHDL spec in
more detail
now, an I gather that at 3 ns there is only one source active
(the first signal assignment) and so the simulator shouldn't output a
"X", but a "1".
(I tested this with ModelSim 6.0c, Altera Edition, with
ActiveHDL-6.2 and ActiveHDL-7.1, and all of these give "X" after 3
ns.)

What's even stranger: I modified the code to the following:

--------------------------
library IEEE;
use IEEE.std_logic_1164.all;

entity TestBench is
end TestBench;

architecture behaviour of TestBench is

signal test : STD_LOGIC := 'Z';

begin
test <= transport '1' after 3 ns;
test <= transport '0' after 5 ns;
end behaviour;
---------------------------------------------------

Now I get in ActiveHDL 6.2/ 7.1 and Modelsim 6.0c:

0 ns => test = Z
3 ns => test = 1
5 ns => test = X

So this is what I would expect: At "0 ns" only the initialization value
is driven; this
gives "Z". At 3 ns '1' is driven which results in '1', At 5 ns '0' and
'1' are driven
which results in 'X'.

So to me this seems like the simulator somehow interprets the
initialization
value as driver. So the X after 3 ns in the original code comes from
the
fact that the driver was initialized with "0" and then when the '1' is
driven
the "0" from the initialization collides with the '1' from the "after
3ns" assignment.

For me that still sounds like the simulator doesn't behave according to
the VHDL
specification...

so long
lundril
 
Arg, okay I found the paragraph which explains this:

The

signal test : STD_LOGIC := '0';

means that '0' is a defaulft value for any driver of test. This means
that

test <= transport '1' after 3 ns;
test <= transport '0' after 5 ns;


is translated into

test <= transport '0', '1' after 3 ns; -- '0' because of default
expression
test <= transport '0', '0' after 5 ns;

So after 3 ns there are actually two active drivers; one which drives
'0' and one which drives '1'.

so this explains the problem.

so long
lundril
 
lundril@gmx.de wrote:
Arg, okay I found the paragraph which explains this:
.. . .
So after 3 ns there are actually two active drivers; one which drives
'0' and one which drives '1'.
Click to expand...
There two active drivers at time zero also.
The resolution function determines the value.
Whenever one drives '1' and the other drives '0'
the result is 'X'.

-- Mike Treseler
 
Marcus Harnisch <marcus.harnisch@gmx.net> writes:
Every signal driver performs the following steps upon execution:

- Delete all currently scheduled events

- Add own waveform
[...]
Click to expand...
Which was, as you correctly pointed out, lundril, utter rubbish. What
I described is valid only for consecutive assignments.

Sorry about that,
Marcus
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top