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

[KJ]

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
http://www.vhdl.org/comp.lang.vhdl/FAQ4.html#default 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. (§4.3.1.2, §4.3.2.2)"

From Ashenden's "The Designer's Guide to VHDL" Chapter 5, page 148
http://books.google.com/books?id=77...&hl=en&sa=X&oi=book_result&resnum=6&ct=result

"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
port"

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.

KJ
---- Start of sample code
library ieee;
use ieee.std_logic_1164.all;
entity Foo is
port(
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
begin
-- Some_Sig1 <= '0';
Some_Out2 <= Some_Inp1 and Some_Sig1;
end RTL;

library ieee;
use ieee.std_logic_1164.all;

entity Foo_Top is
port(
Some_Inp1: in std_ulogic;
Some_Inp2: in std_ulogic;
Some_Out2: out std_ulogic);
end Foo_Top;
architecture RTL of Foo_Top is
begin
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

 

[kennheinrich]

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 ishttp://www.vhdl.org/comp.lang.vhdl/FAQ4.html#default%20expression

"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. (§4.3.1.2, §4.3.2.2)"

From Ashenden's "The Designer's Guide to VHDL" Chapter 5, page 148http://books.google.com/books?id=77Oe9yT-VSUC&pg=PA148&lpg=PA148&dq=V...

"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
port"

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.

KJ
---- Start of sample code
library ieee;
use ieee.std_logic_1164.all;
entity Foo is
port(
    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
begin
--    Some_Sig1   <= '0';
    Some_Out2   <= Some_Inp1 and Some_Sig1;
end RTL;

library ieee;
use ieee.std_logic_1164.all;

entity Foo_Top is
port(
    Some_Inp1:      in      std_ulogic;
    Some_Inp2:      in      std_ulogic;
    Some_Out2:      out     std_ulogic);
end Foo_Top;
architecture RTL of Foo_Top is
begin
    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

Kevin,

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
signal":

"A basic signal is a signal that has all of the following properties:
— It is either a scalar signal or a resolved signal (see 4.3.1.2)
— 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
4.3.1.2)."

The default value from sec 4.3.1.2 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 4.3.2.2 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

 

[KJ]

On Oct 31, 10:36 am, (e-mail address removed) wrote:
Kenn,

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.

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

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