LRM question: What is the correct interpretation of an inout signalwith a default value that is lef

Discussion in 'VHDL' started by KJ, Oct 31, 2008.

  1. KJ

    KJ Guest

    If an entity
    - Has an inout port that specifies a default value
    - When instantiated, the inout port is left open
    - Inside the architecture for that entity that inout signal gets used
    for something that affects some other entity output.

    Per the LRM, what would be the correct result? Posted below is sample
    code where the inout signal is 'Some_Sig1' in the entity 'Foo' which
    is given a default value of '1'. Inside the architecture, 'Some_Sig1'
    is used to generate another output as

    Some_Out2 <= Some_Inp1 and Some_Sig1;

    where Some_Inp is an input. My interpretation is that since
    'Some_Sig1' has no drivers inside the architecture, the specified
    default value of '1' would apply and therefore the above statement
    would reduce to

    Some_Out2 <= Some_Inp1;

    Simulation with Modelsim 6.4 seems to agree with that interpretation,
    two synthesis tools give two completely different results.

    From the VHDL FAQ archives is expression

    "B.58 default expression: A default value that is used for a formal
    generic, port, or parameter if the interface object is unassociated. A
    default expression is also used to provide an initial value for
    signals and their drivers. (§, §"

    From Ashenden's "The Designer's Guide to VHDL" Chapter 5, page 148

    "If a port of mode inout is left open, the value used internally by
    the entity (the effective value) is the value that it drives on to the

    Both of these seem to support my interpretation that the signal
    'Some_Sig1', from the perspective of the entity (entity Foo in my code
    below) should, when used, have a value of '1' if one interprets a
    default value on an inout to be a potential "driver on to the port".
    Is there something else in the LRM that I'm missing that would counter
    that interpretation? I'm working with one of the synthesis vendors to
    get the correct interpretation where they are currently incorrectly
    erroring out.

    ---- Start of sample code
    library ieee;
    use ieee.std_logic_1164.all;
    entity Foo is
    Some_Sig1: inout std_ulogic := '1';
    Some_Inp1: in std_ulogic;
    Some_Inp2: in std_ulogic;
    Some_Out2: out std_ulogic);
    end Foo;
    architecture RTL of Foo is
    -- Some_Sig1 <= '0';
    Some_Out2 <= Some_Inp1 and Some_Sig1;
    end RTL;

    library ieee;
    use ieee.std_logic_1164.all;

    entity Foo_Top is
    Some_Inp1: in std_ulogic;
    Some_Inp2: in std_ulogic;
    Some_Out2: out std_ulogic);
    end Foo_Top;
    architecture RTL of Foo_Top is
    The_Foo : entity work.Foo
    port map(
    Some_Sig1 => open,
    Some_Inp1 => Some_Inp1,
    Some_Inp2 => Some_Inp2,
    Some_Out2 => Some_Out2);
    end RTL;
    ---- End of sample code
    KJ, Oct 31, 2008
    1. Advertisements

  2. KJ

    kennheinrich Guest


    Here's my take, referencing the 2002 edition LRM.

    Some_Sig1 is an "interface object declaration" which declares a
    signal. It is a formal port of the entity foo. After elaboration,
    this signal has NO SOURCES. No sources means no drivers (since you're
    not assigning to it) and no sources which are ports of lower-level
    attached components. Since the port is unconnected (associated with
    kwd OPEN) there will be none of the usual up-and-down iteration in the
    kernel simulation cycle as the driving and effective values of a long
    chain of nets is computed.

    Some_sig1 satisfies the definition on page 173/sec 12.6.2 of a "basic

    "A basic signal is a signal that has all of the following properties:
    — It is either a scalar signal or a resolved signal (see
    — It is not a subelement of a resolved signal
    — Is not an implicit signal of the form S'Stable(T), S'Quiet(T), or
    S'Transaction (see 14.1)
    — It is not an implicit signal GUARD (see 9.1).
    Basic signals are those that determine the driving values for all
    other signals."

    Since it has no sources, the definition of "driving value" is the
    first bullet point on the same page:

    "The driving value of any basic signal S is determined as follows:
    — If S has no source, then the driving value of S is given by the
    default value associated with S (see"

    The default value from sec is defined as the default
    expression :

    "For a signal declared to be of a scalar subtype, the value of the
    default expression is the default value of the signal."

    So now we know that the official "driving value" of some_sig1 is the
    default expresison which is a std_ulogic '1'.

    From sec 12.6 "Execution of a model", we have

    "For a scalar signal S, the effective value of S is determined in the
    following manner:
    — If S is a signal declared by a signal declaration, a port of mode
    buffer, or an unconnected port of
    mode inout, then the effective value of S is the same as the driving
    value of S."

    So now we know that the "effective value" is also '1'.

    BTW, there's also a note in sec page 77
    "2—Although a default expression can appear in an interface element
    that declares a (local or formal) port, such a default
    expression is not interpreted as the value of an implicit association
    element for that port. Instead, the value of the expression
    is used to determine the effective value of that port during
    simulation if the port is left unconnected (see 12.6.2)."

    So my analysis so far is confirmed in two ways :)

    So what the heck is an "effective value", and what is it good for?
    From sec 12.6.2:

    "The effective value of a given signal is the value obtainable by
    evaluating a reference to the signal within an expression. The driving
    value and the effective value of a signal are not always the same,
    especially when resolution functions and
    conversion functions or type conversions are involved in the
    propagation of signal values."

    So now we know that any evaluation of a reference to some_sig1 in an
    expression will return a '1'. This is exactly what you're doing in
    your assignment

    Some_Out2 <= Some_Inp1 and Some_Sig1;

    Since there are no sources to the signal, and no connections through
    association elements, this signal constitutes the entire net, and
    nothing ever affects the net, so no updates are ever performed on it
    and no other computation ever has to be performed with it. It stays
    '1' forever.

    So IMHO, if a synthesis vendor says it should be anything other than
    '1', I'd like to see his counter-justification!

    Hope this helps,

    - Kenn
    kennheinrich, Oct 31, 2008
    1. Advertisements

  3. KJ

    KJ Guest

    On Oct 31, 10:36 am, wrote:

    Thanks for your detailed analysis, counting myself and you, Peter A's
    book and the anonymous VHDL archives I've now got more than enough for
    a 'movement' (from the song Alice's Restaurant) here.
    Well, one synthesis tool decided that 'Some_Out2' should always be '0'
    and the other bombed out with an error. I've got a service request in
    with the one that is erroring out and they're working on it so it
    looks like I'll soon be opening one with the other one. I don't think
    either will come up with any counter-justification, they'll just fix
    the bug in their tool thus improving both tools for all eventually
    (albeit for a rather obscure thing).

    Kevin Jennings
    KJ, Oct 31, 2008
    1. Advertisements

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.