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.
_______________________________________________
Ghdl-discuss mailing list
[email protected]
https://mail.gna.org/listinfo/ghdl-discuss
