VHDL standard question (VHDL 93 chapter 4.3.2.2)

Discussion in 'VHDL' started by Kim Enkovaara, Oct 13, 2008.

  1. 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
     
    Kim Enkovaara, Oct 13, 2008
    #1
    1. Advertising

  2. Kim Enkovaara

    sandeep Guest

    On Oct 13, 1:16 pm, Kim Enkovaara <> 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
     
    sandeep, Oct 13, 2008
    #2
    1. Advertising

  3. Kim Enkovaara

    sandeep Guest

    On Oct 13, 1:16 pm, Kim Enkovaara <> 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.
     
    sandeep, Oct 13, 2008
    #3
  4. 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, Oct 13, 2008
    #4
  5. 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 Enkovaara, Oct 13, 2008
    #5
  6. Kim Enkovaara

    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?


    > 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
     
    , Oct 13, 2008
    #6
  7. 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, Oct 13, 2008
    #7
  8. 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
     
    Kim Enkovaara, Oct 14, 2008
    #8
  9. Kim Enkovaara

    KJ Guest

    On Oct 14, 1:25 am, Kim Enkovaara <> 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
     
    KJ, Oct 14, 2008
    #9
  10. Kim Enkovaara

    diogratia Guest

    On Oct 13, 8:59 pm, 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.
     
    diogratia, Oct 16, 2008
    #10
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Herrcho
    Replies:
    6
    Views:
    475
    Peter Pichler
    Feb 20, 2004
  2. Peter Hansen
    Replies:
    2
    Views:
    922
    yaipa h.
    Jun 27, 2003
  3. Jim Lewis
    Replies:
    0
    Views:
    901
    Jim Lewis
    Oct 13, 2006
  4. Jim Barlow
    Replies:
    5
    Views:
    405
    Jim Barlow
    Mar 13, 2008
  5. Aryeh M. Friedman
    Replies:
    34
    Views:
    605
    Aryeh M. Friedman
    Jan 7, 2013
Loading...

Share This Page