Question to resolved signals, transport delay

Discussion in 'VHDL' started by lundril@gmx.de, May 6, 2006.

  1. 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
    , May 6, 2006
    #1
    1. Advertising

  2. Hi lundril,

    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


    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
    Marcus Harnisch, May 8, 2006
    #2
    1. Advertising

  3. KJ Guest

    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
    KJ, May 8, 2006
    #3
  4. Guest

    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
    , May 8, 2006
    #4
  5. Guest

    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
    , May 8, 2006
    #5
  6. 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'.


    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
    Mike Treseler, May 8, 2006
    #6
  7. Marcus Harnisch <> writes:
    > Every signal driver performs the following steps upon execution:
    >
    > - Delete all currently scheduled events
    >
    > - Add own waveform
    > [...]


    Which was, as you correctly pointed out, lundril, utter rubbish. What
    I described is valid only for consecutive assignments.

    Sorry about that,
    Marcus
    Marcus Harnisch, May 9, 2006
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Ingmar Seifert

    Delay of control signals

    Ingmar Seifert, Aug 18, 2003, in forum: VHDL
    Replies:
    0
    Views:
    1,200
    Ingmar Seifert
    Aug 18, 2003
  2. =?ISO-8859-1?Q?Dominik_Fr=F6hlich?=

    Resolved Signals

    =?ISO-8859-1?Q?Dominik_Fr=F6hlich?=, Feb 9, 2004, in forum: VHDL
    Replies:
    1
    Views:
    592
    Tim Hubberstey
    Feb 9, 2004
  3. kitcha
    Replies:
    3
    Views:
    2,955
    Charles Bailey
    Nov 24, 2005
  4. Lori McDonald
    Replies:
    0
    Views:
    5,735
    Lori McDonald
    Feb 16, 2004
  5. surpriya.7
    Replies:
    2
    Views:
    1,625
    surpriya.7
    Mar 25, 2009
Loading...

Share This Page