«

Hi,

I have small problems understanding what the 1076-1993
Ch. 4.3.2.2/490

"The type of the actual (after applying the conversion function
or type conversion. if present in the actual part) must be the
same as the type of the corresponding formal, if the mode of the
formal is IN, INOUT, or LINKAGE, and if the actual is not open.
Similarly, if the mode of the formal is OUT, INOUT, BUFFER, or
LINKAGE, and if the actual is not open, then the type of the
formal (after applying the conversion function or type
conversion, if present in the formal part) must be the same as
the corresponding actual."

really means. Take a look of the following code example. Should
it compile or not. Traditionally simulators have compiled it,
but now I have found one that does not compile it. And the
vendor says that the code is invalid.

The problem comes to what does the "corresponding actual"
in the standard text mean. Is it the actual before or after
the type conversion?

--ram.vhd---
LIBRARY ieee;
USE ieee.std_logic_1164.ALL;
USE ieee.numeric_std.ALL;

ENTITY ram IS
PORT(
d: IN std_logic_vector(35 DOWNTO 0));
END;

ARCHITECTURE ram_arch OF ram IS
BEGIN
END;
---toplevel.vhd--------
LIBRARY ieee;
USE ieee.std_logic_1164.ALL;
USE ieee.numeric_std.ALL;

ENTITY dut_top IS
END;

ARCHITECTURE dut_bench_arch OF dut_top IS

SIGNAL data : unsigned(35 DOWNTO 0);

COMPONENT ram
PORT (
d : INOUT std_logic_vector(35 DOWNTO 0));
END COMPONENT;
BEGIN

test:ram
PORT MAP (
d => std_logic_vector(data));
END;


Regards,
--Kim

On Oct 13, 1:16*pm, Kim Enkovaara <kim.enkova...@iki.fi> wrote:
> Hi,
>
> I have small problems understanding what the 1076-1993
> Ch. 4.3.2.2/490
>
> "The type of the actual (after applying the conversion function
> or type conversion. if present in the actual part) must be the
> same as the type of the corresponding formal, if the mode of the
> formal is IN, INOUT, or LINKAGE, and if the actual is not open.
> Similarly, if the mode of the formal is OUT, INOUT, BUFFER, or
> LINKAGE, and if the actual is not open, then the type of the
> formal (after applying the conversion function or type
> conversion, if present in the formal part) must be the same as
> the corresponding actual."
>
> really means. Take a look of the following code example. Should
> it compile or not. Traditionally simulators have compiled it,
> but now I have found one that does not compile it. And the
> vendor says that the code is invalid.
>
> The problem comes to what does the "corresponding actual"
> in the standard text mean. Is it the actual before or after
> the type conversion?
>
> --ram.vhd---
> LIBRARY ieee;
> USE ieee.std_logic_1164.ALL;
> USE ieee.numeric_std.ALL;
>
> ENTITY ram IS
> * *PORT(
> * * *d: IN std_logic_vector(35 DOWNTO 0));
> END;
>
> ARCHITECTURE ram_arch OF ram IS
> BEGIN
> END;
> ---toplevel.vhd--------
> LIBRARY ieee;
> USE ieee.std_logic_1164.ALL;
> USE ieee.numeric_std.ALL;
>
> ENTITY dut_top IS
> END;
>
> ARCHITECTURE dut_bench_arch OF dut_top IS
>
> * *SIGNAL data : unsigned(35 DOWNTO 0);
>
> * *COMPONENT ram
> * * *PORT (
> * * * *d : INOUT std_logic_vector(35 DOWNTO 0));
> * *END COMPONENT;
> * *BEGIN
>
> * * *test:ram
> * * * *PORT MAP (
> * * * * *d => std_logic_vector(data));
> END;
>
> Regards,
> --Kim

For me issue is not with type conversion. It is with component
declaration. In entity declaration Port is IN
while component decln port type is INOUT..
What is the actual error messga??
And answer for ur qn is "It is actual after type conversion".
regards

On Oct 13, 1:16*pm, Kim Enkovaara <kim.enkova...@iki.fi> wrote:
> Hi,
>
> I have small problems understanding what the 1076-1993
> Ch. 4.3.2.2/490
>
> "The type of the actual (after applying the conversion function
> or type conversion. if present in the actual part) must be the
> same as the type of the corresponding formal, if the mode of the
> formal is IN, INOUT, or LINKAGE, and if the actual is not open.
> Similarly, if the mode of the formal is OUT, INOUT, BUFFER, or
> LINKAGE, and if the actual is not open, then the type of the
> formal (after applying the conversion function or type
> conversion, if present in the formal part) must be the same as
> the corresponding actual."
>
> really means. Take a look of the following code example. Should
> it compile or not. Traditionally simulators have compiled it,
> but now I have found one that does not compile it. And the
> vendor says that the code is invalid.
>
> The problem comes to what does the "corresponding actual"
> in the standard text mean. Is it the actual before or after
> the type conversion?
>
> --ram.vhd---
> LIBRARY ieee;
> USE ieee.std_logic_1164.ALL;
> USE ieee.numeric_std.ALL;
>
> ENTITY ram IS
> * *PORT(
> * * *d: IN std_logic_vector(35 DOWNTO 0));
> END;
>
> ARCHITECTURE ram_arch OF ram IS
> BEGIN
> END;
> ---toplevel.vhd--------
> LIBRARY ieee;
> USE ieee.std_logic_1164.ALL;
> USE ieee.numeric_std.ALL;
>
> ENTITY dut_top IS
> END;
>
> ARCHITECTURE dut_bench_arch OF dut_top IS
>
> * *SIGNAL data : unsigned(35 DOWNTO 0);
>
> * *COMPONENT ram
> * * *PORT (
> * * * *d : INOUT std_logic_vector(35 DOWNTO 0));
> * *END COMPONENT;
> * *BEGIN
>
> * * *test:ram
> * * * *PORT MAP (
> * * * * *d => std_logic_vector(data));
> END;
>
> Regards,
> --Kim

I tried to compile your code and realised you need to use -v93 (with
cadence) -93 with mentor. Below is error
message from cadence when i didnot use -v93.
================================================== ============================
Formal ports of mode out and inout must be connected to signals.
The indicated actual in a port map is not a signal. Examples:
component C
port (X: in integer;
Y: out integer);
end component;
signal R, S: INTEGER;

L1: C port map (R, S); -- legal
L2: C port map (2, S); -- legal in VHDL-93
only
-- This is supported feature of the vhdl language with
-v93 command line option only

L3: C port map (2, 2); -- illegal
================================================== =================================================

When i tried with declaring intermediate signal data1
and data1 <= std_logic_vector(data);
and then data1 used as actual without any conversion it works in both -
v87 and -v93.
I am trying to find what is return type of STD_LOGIC_VECTOR casting.

Hi,

> For me issue is not with type conversion. It is with component
> declaration. In entity declaration Port is IN
> while component decln port type is INOUT..
> What is the actual error messga??
> And answer for ur qn is "It is actual after type conversion".

That was just a typo in the example, sorry for that. For some reason
it went trough the compiler (possibly because the type checking was
before).

The error is.
** Error: toplevel.vhd(26): (vcom-1291) Formal "d" type
"ieee.std_logic_1164.std_logic_vector" does not match the actual
expression type "ieee.numeric_std.unsigned".

This is a new error in 6.4a version. This code has compiled
since 5.6 version. It is a snippet from much larger design.

--Kim

Kim Enkovaara wrote:
> ENTITY ram IS
> PORT(
> d: IN std_logic_vector(35 DOWNTO 0));

This should be INOUT, this was just a typo in the example I made
from bigger example that had other signals also. The question remains
the same.

--Kim

Kim

> "The type of the actual (after applying the conversion function
> or type conversion. if present in the actual part) must be the
> same as the type of the corresponding formal, if the mode of the
> formal is IN, INOUT, or LINKAGE, and if the actual is not open.
> Similarly, if the mode of the formal is OUT, INOUT, BUFFER, or
> LINKAGE, and if the actual is not open, then the type of the
> formal (after applying the conversion function or type
> conversion, if present in the formal part) must be the same as
> the corresponding actual."
>
> really means. Take a look of the following code example. Should
> it compile or not. Traditionally simulators have compiled it,
> but now I have found one that does not compile it. And the
> vendor says that the code is invalid.
>
> The problem comes to what does the "corresponding actual"
> in the standard text mean. Is it the actual before or after
> the type conversion?

> COMPONENT ram
> PORT (
> d : INOUT std_logic_vector(35 DOWNTO 0));
> END COMPONENT;
> BEGIN
>
> test:ram
> PORT MAP (
> d => std_logic_vector(data));

Since it's an inout, you need type conversion in both directions:

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

I think that's the only thing that's wrong.
--
Jonathan Bromley

Kim Enkovaara wrote:

> I have small problems understanding what the 1076-1993
> Ch. 4.3.2.2/490 really means.
> Take a look of the following code example. Should
> it compile or not. Traditionally simulators have compiled it,
> but now I have found one that does not compile it. And the
> vendor says that the code is invalid.

I don't know if it should,
but it does compile and elaborate without error
for modelsim SE 6.2a and for quartus 7.2,
with your original and corrected versions,
and with Jonathan's version.
Quartus does warn about the lack of logic,
but has no problem with the instance.

-- Mike Treseler

Mike Treseler wrote:
> I don't know if it should,
> but it does compile and elaborate without error
> for modelsim SE 6.2a and for quartus 7.2,

I was also unsure how this should work in tools,
that is the reason I asked. The code has gone trough
various tools that consider the code to be just fine.
For example Precision, Synplify, Modelsim upto 6.4,
and few code checking tools accept the code without
the type conversion to both directions. New Synopsys
DC requires the conversion. This seems to be gray
area in the tool implementations.


--Kim

On Oct 14, 1:25*am, Kim Enkovaara <kim.enkova...@iki.fi> wrote:
> Mike Treseler wrote:
> > I don't know if it should,
> > but it does compile and elaborate without error
> > for modelsim SE 6.2a and for quartus 7.2,
>
> I was also unsure how this should work in tools,
> that is the reason I asked. The code has gone trough
> various tools that consider the code to be just fine.
> For example Precision, Synplify, Modelsim upto 6.4,
> and few code checking tools accept the code without
> the type conversion to both directions. New Synopsys
> DC requires the conversion. This seems to be gray
> area in the tool implementations.
>
> --Kim

From the VASG web site (link below)...

If you're experiencing a problem, issue, ambiguity or inconsistent
treatment of VHDL by different vendors which may be due to a language
issue, please fill out and submit the following issue report form. You
may also use the issue report form to submit language enhancement
requests.

When you submit your bug report, it will be entered into our database
for tracking purposes. After an initial assessment by the Issues
Screening and Analysis Committee (ISAC), the resolution of the problem
will be assigned to an ISAC member, or forwarded to another
appropriate VASG committee for analysis and review.

http://www.eda-stds.org/vasg/bugrep.htm

Yours would seem to fit the definition of an ambiguity as well as
inconsistent treatment. Post the results you get.

Kevin Jennings

On Oct 13, 8:59 pm, s...@oxfordbromley.plus.com wrote:

> > "The type of the actual (after applying the conversion function
> > or type conversion. if present in the actual part) must be the
> > same as the type of the corresponding formal, if the mode of the
> > formal is IN, INOUT, or LINKAGE, and if the actual is not open.
> > Similarly, if the mode of the formal is OUT, INOUT, BUFFER, or
> > LINKAGE, and if the actual is not open, then the type of the
> > formal (after applying the conversion function or type
> > conversion, if present in the formal part) must be the same as
> > the corresponding actual."

> Since it's an inout, you need type conversion in both directions:
>
> PORT MAP (unsigned(d) => std_logic_vector(Data));
>
> I think that's the only thing that's wrong.
> --
> Jonathan Bromley

Jonathan's comment is supported by the LRM, in 4.3.2.2, the third
preceding paragraph and the preceding paragraph to the above quoted
paragraph:

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 .)

...

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.

Type conversions support data flow either from the actual to the
formal or vice versa, but not both.