Top level output keeps showing undefined XXX in simulation

Discussion in 'VHDL' started by Jaco Naude, Nov 26, 2008.

  1. Jaco Naude

    Jaco Naude Guest

    Hi there,

    I hope someone on this group can explain the reason for what I'm
    seeing, for me it does not make any sense...

    I have an output port that is defined like this, (other ports and
    signals left out for simplicity sake):

    entity darv_leaf_node is
    Port( s_response : out response_bus );

    where response bus is a record defined like this:

    type response_control is
    record
    valid : std_logic;
    status : status_type;
    end record;

    type response_bus is
    record
    data : std_logic_vector(31 downto 0);
    control : response_control;
    end record;

    In the architecture of darv_leaf node I declare an internal/
    intermediate signal as follows:

    signal s_response_internal : response_bus;

    and I have a process assigning different values to
    s_response_internal. All I want to do is assign the output port,
    s_response to the signal. This worked fine until I made some changes
    to the design which are as far as I can see totally unrelated to this
    output port. The process is shown below:

    process (clk, rst_n)
    begin
    if (clk'event and clk = '1') then
    if (rst_n = '0') then
    s_response.data <= (others => '0');
    s_response.control.valid <= '0';
    s_response.control.status <= startup;
    else
    s_response <= s_response_internal;
    end if;
    end if;
    end process;

    The s_response simulation shows that only the .control.status bits
    change correctly, the other bits (.data and .control.valid) are
    staying X's for the complete duration of the simulation. Thus, it is
    not even initialized properly during reset. s_response_internal's bits
    are correct in simulation.

    I'm doing a ModelSim PE simulation and there are lots of other places
    where the same bus types work fine, thus the package inclusion is not
    the problem.

    Any ideas would be much appreciated, that's if I haven't gone grazy
    before getting any responses :).

    Thanks,
    Jaco
    Jaco Naude, Nov 26, 2008
    #1
    1. Advertising

  2. Jaco Naude

    Tricky Guest

    On 26 Nov, 07:52, Jaco Naude <> wrote:
    > Hi there,
    >
    > I hope someone on this group can explain the reason for what I'm
    > seeing, for me it does not make any sense...
    >
    > I have an output port that is defined like this, (other ports and
    > signals left out for simplicity sake):
    >
    > entity darv_leaf_node is
    >    Port( s_response  : out response_bus );
    >
    > where response bus is a record defined like this:
    >
    >         type response_control is
    >          record
    >                   valid         : std_logic;
    >                   status                : status_type;
    >          end record;
    >
    >         type response_bus is
    >          record
    >                   data                  : std_logic_vector(31 downto 0);
    >                   control         : response_control;
    >          end record;
    >
    > In the architecture of darv_leaf node I declare an internal/
    > intermediate signal as follows:
    >
    > signal s_response_internal                                      : response_bus;
    >
    > and I have a process assigning different values to
    > s_response_internal. All I want to do is assign the output port,
    > s_response to the signal. This worked fine until I made some changes
    > to the design which are as far as I can see totally unrelated to this
    > output port. The process is shown below:
    >
    > process (clk, rst_n)
    > begin
    >         if (clk'event and clk = '1') then
    >                 if (rst_n = '0') then
    >                         s_response.data <= (others => '0');
    >                         s_response.control.valid <= '0';
    >                         s_response.control.status <= startup;
    >                 else
    >                         s_response <= s_response_internal;
    >                 end if;
    >         end if;
    > end process;
    >
    > The s_response simulation shows that only the .control.status bits
    > change correctly, the other bits (.data and .control.valid) are
    > staying X's for the complete duration of the simulation. Thus, it is
    > not even initialized properly during reset. s_response_internal's bits
    > are correct in simulation.
    >
    > I'm doing a ModelSim PE simulation and there are lots of other places
    > where the same bus types work fine, thus the package inclusion is not
    > the problem.
    >
    > Any ideas would be much appreciated, that's if I haven't gone grazy
    > before getting any responses :).
    >
    > Thanks,
    > Jaco


    'X's show that you are driving the same signal from two different
    sources. Normally the fix for this is to either declare the signals
    (status and valid) as std_ulogic so they are picked up in the
    compiler, or just search through your code for a second assignment.
    Like you said, it worked fine until you made some changes.

    I notice you have put the rst_n in the sensitivity list, but you've
    made it a synchronous reset. Were you expecting for an asynch reset
    behaviour (hence your not getting a proper reset)?

    Another point to note: Synthesisors tend not to like anything other
    than std_(u)logic(_vector) for the top level ports. If this isnt
    intended as the top (ie pin) level, then there should be no problem.
    Tricky, Nov 26, 2008
    #2
    1. Advertising

  3. Jaco Naude

    Tricky Guest


    >
    > Another point to note: Synthesisors tend not to like anything other
    > than std_(u)logic(_vector) for the top level ports. If this isnt
    > intended as the top (ie pin) level, then there should be no problem.


    Actually, I kind of lie. Its not that it doesnt like them, its just
    constraining an enumerated type is impossible.
    Tricky, Nov 26, 2008
    #3
  4. Jaco Naude

    Jaco Naude Guest

    On Nov 26, 11:14 am, Tricky <> wrote:
    > > Another point to note: Synthesisors tend not to like anything other
    > > than std_(u)logic(_vector) for the top level ports. If this isnt
    > > intended as the top (ie pin) level, then there should be no problem.

    >
    > Actually, I kind of lie. Its not that it doesnt like them, its just
    > constraining an enumerated type is impossible.


    Thanks for the response. It is indeed multiple drives, don't know how
    I didn't pick it up after staring at the code. Well, it works now,
    thanks.

    My title was not entirely correct, this block is the top level of this
    part of the design but the there is a top level higher up in the
    hierarchy with proper inputs and outputs. Thanks for the input in any
    way.

    In regard with the reset, I can just as well take it out, since the
    reset should be synchronous all the time. I think I put it in there
    while trying to get the X's away.

    Thanks again for the help,
    All the best.
    Jaco
    Jaco Naude, Nov 26, 2008
    #4
  5. Promoting unresolved logic (Re: Top level output keeps showing undefinedXXX in simulation)

    Jaco Naude submitted:

    |---------------------------------------------------------------------|
    |"[..] |


    | |


    |Thanks for the response. It is indeed multiple drives, don't know how|


    |I didn't pick it up after staring at the code. Well, it works now, |


    |thanks. |


    | |


    |[..]" |
    |---------------------------------------------------------------------|

    I have been trying unsuccessfully to convince someone to use
    std_ulogic and std_ulogic_vector instead of std_logic and
    std_logic_vector. I mentioned
    WWW.VHDL.org/comp.lang.vhdl/FAQ1.html#std_ulogic
    to him and he conceded that simulations could be better with
    std_ulogic and std_ulogic_vector but any time this was investigated to
    cause a bug for us the bug was not or the bugs were not caused by using
    resolved logic instead of unresolved logic.

    Reasons he gave for staying with resolved logic is that synthesizers
    would reject multiple drivers and third parties support resolved logic
    instead of unresolved logic.

    It is not important enough to persist at him, but could anyone advise
    me as to how I could be more persuasive?

    With kind regards,
    Colin Paul Gloster
    Paul Cole Gloster, Nov 26, 2008
    #5
  6. Re: Promoting unresolved logic (Re: Top level output keeps showingundefined XXX in simulation)

    Paul Cole Gloster wrote:

    > It is not important enough to persist at him, but could anyone advise
    > me as to how I could be more persuasive?


    Unsolicited advice is rarely used, persuasive or otherwise.
    If I am a paying customer, I can insist, but this
    would likely cost me more time than fixing up the
    types myself.

    -- Mike Treseler
    Mike Treseler, Nov 27, 2008
    #6
    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. Åukasz Ligowski

    "xxx.has_key(a)" vs "a in xxx"

    Åukasz Ligowski, Oct 30, 2008, in forum: Python
    Replies:
    0
    Views:
    274
    Åukasz Ligowski
    Oct 30, 2008
  2. Replies:
    0
    Views:
    974
  3. Bert Leu

    value of type "xxx" cannot be converted to "xxx"

    Bert Leu, Jun 5, 2007, in forum: ASP .Net Web Services
    Replies:
    2
    Views:
    275
    Jesse Houwing
    Jun 6, 2007
  4. Richard Lionheart
    Replies:
    4
    Views:
    272
    Richard Lionheart
    May 5, 2004
  5. Iñaki Baz Castillo
    Replies:
    5
    Views:
    141
    Iñaki Baz Castillo
    Mar 30, 2008
Loading...

Share This Page