Forum: GHDL A possible case of inadequate type checking in ghdl on association list elements of mode inout

See: VHDL standard question (VHDL 93 chapter 4.3.2.2) - comp.lang.vhdl
http://groups.google.com/group/comp.lang.vhdl/browse_frm/thread/3a06ec79adbf1e9c?hl=en

In this case its a matter of using an inout mode on a port declaration, 
and
assigning an actual of a different type through type conversion.  The 
LRM
mentions that type conversion only affects unidirectional data flow. 
The
implication is that for different but closely related types for a formal 
and
actual in a port association list of a component instantiation of mode
inout, type declaration should be performed on both the actual and the
formal to effect bidirectional connectivity without error.

Taking the example files in first comp.lang.vhdl thread posting, 
correcting
the entity port declaration in ram.vhd from

     d: IN std_logic_vector(35 DOWNTO 0));  -- this was erroneous in the
                                            --  provided example and
                                            --  corrected in a 
subsequent
                                            -- post.

to
     d: INOUT std_logic_vector(35 DOWNTO 0));

and analyzing, both ram.vhd and toplevel.vhd, followed by elaborating
dut_top using ghdl does not yield an error.

Type conversion is required because the formal d and the actual data are
declared as two separate types, d as above,  a std_logic vector and data 
as
an UNSIGNED type declared in ieee.numeric_std.    They are closely 
related
types and have compatible constraints.

4.3.2.2, Association lists, specifically states that type conversion is
either for data flow from the actual to the formal, or from the formal 
to
the actual.  And by deduction, not both.

4.3.2.2 paragraph 12:

"Alternatively, the formal part of a named element association may be in 
the
form of a type conversion, where the expression to be converted is the
formal designator itself, if and only if the mode of the formal is
out,inout, buffer, or linkage, and if the actual is not open. In this 
case,
the base type denoted by the type mark must be the same as the base type 
of
the corresponding actual. Such a type conversion provides for type
conversion in the event that data flows from the formal to the actual. 
It is
an error if the type of the formal is not closely related to the type of 
the
actual. (See  7.3.5  .)"

and paragraph 15:

"Alternatively, the actual part of a (named or positional) element
association may be in the form of a type conversion, where the 
expression to
be type converted is the actual designator itself, if and only if the 
mode
of the formal is in, inout, or linkage, and if the actual is not open. 
In
this case, the base type denoted by the type mark must be the same as 
the
base type of the corresponding formal. Such a type conversion provides 
for
type conversion in the event that data flows from the actual to the 
formal.
It is an error if the type of the actual is not closely related to the 
type
of the formal."

Jonathan Bromley commented to the affect that the association element 
for
the port map association list should look like this:

   PORT MAP (unsigned(d) => std_logic_vector(Data));

which provides for data flow in both directions.

This has surfaced from the use of Modelsim 6.4a and also shows up in a 
late
version of the Synopsys Design Compiler where type conversion of only 
one of
the formal or actual parameters of the association element resulted in 
an error.

These are not tested in the ieee validation suite released in '96, see
/src/ch04/sc03/sb02/ss02/p012 and /src/ch04/sc03/sb02/ss02/p015.

The above paragraphs are preserved in P1076-2006 D3.0, 4.4.6.2 
Association
lists, which means they are probably there in 2008, as well.

There's a general lack of visibility into the Accellera VHDL 
standardization
effort by third parties, implying the lack of visibility on how and why 
the
problem and type checking has shown up only recently.