VHDL standard question (VHDL 93 chapter 4.3.2.2)

K

Kim Enkovaara

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
 
S

sandeep

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
Click to expand...

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
 
S

sandeep

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
Click to expand...

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

Kim Enkovaara

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".
Click to expand...

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
 
K

Kim Enkovaara

Kim said:
ENTITY ram IS
PORT(
d: IN std_logic_vector(35 DOWNTO 0));
Click to expand...

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
 
G

Guest

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?
Click to expand...
COMPONENT ram
PORT (
d : INOUT std_logic_vector(35 DOWNTO 0));
END COMPONENT;
BEGIN

test:ram
PORT MAP (
d => std_logic_vector(data));
Click to expand...

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

Mike Treseler

Kim said:
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.
Click to expand...

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
 
K

Kim Enkovaara

Mike said:
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,
Click to expand...

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
 
K

KJ

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
Click to expand...

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
 
D

diogratia

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.
Click to expand...

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.
 

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. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

pls help me ; vhdl; 0
Multiplication VHDL 4
Illegal sequential statement (VHDL) 0
VHDL Subtraction two’s complement 0
VHDL program error 2
2 JK Circuit in VHDL 0
How to use ufixed when it involves multiplication a number of times?(VHDL question) 0
erreur VHDL 3

Members online

No members online now.
Total: 55 (members: 1, guests: 54)
Robots: 411

Forum statistics

Threads
473,994
Messages
2,570,223
Members
46,813
Latest member
lawrwtwinkle111

Latest Threads

Top