Direct entity instantiation...

Discussion in 'VHDL' started by Brian Drummond, Oct 28, 2011.

  1. I have traditionally used components rather than directly instantiating
    entities, mostly out of habit, (or should I say, following established
    precedent :)

    But now that I actually try direct instantiation, I am finding
    surprises...

    Simple example below ... I am instantiating two entities A_comp and
    B_comp from two component libraries A and B - one by component
    instantiation, the other directly. (Each entity asserts on elaboration,
    so that I can see it in synthesis or simulation)

    A (the component) just works (in Modelsim Actel Edition, 6.6) though I
    would have expected a Use clause or embedded configuration to be
    required. The library clause alone is enough to find it.
    Xilinx XST, alarmingly, doesn't even need that ! (Some magic in the
    project files finds it instead)

    B (the entity) can only be instantiated from library Work, not the
    library it is supposed to be in (and for this exercise, it has been
    compiled into both)

    Modelsim reports : "Illegal expanded name prefix" at b
    and "Cannot find expanded name b.b_comp" even though b_comp is in library
    B, and it has no trouble finding a.a_comp.

    Is this expected behaviour, that the only valid library for direct
    instantiation is "work"? And if so, why? It doesn't seem normal for the
    VHDL language to single out one specific library name like this...

    - Brian


    entity Toplevel is
    end Toplevel;

    library A;
    library B;

    --use A.all;
    --use B.all;

    architecture Behavioral of Toplevel is

    component A_comp
    end component;

    begin

    A : A_comp;

    B : entity B.B_comp(Behavioral);
    B2 : entity work.B_comp(Behavioral);

    end Behavioral;

    --------------------------
    entity A_comp is
    end A_comp;

    architecture Behavioral of A_comp is

    function AA return boolean is
    begin
    assert false report "AA called" severity warning;
    return True;
    end function AA;

    constant AAA : boolean := AA;

    begin
    end Behavioral;

    --------------------------

    entity B_comp is
    end B_comp;

    architecture Behavioral of B_comp is

    function BB return boolean is
    begin
    assert false report "BB called" severity warning;
    return True;
    end function BB;

    constant BBB : boolean := BB;

    begin
    end Behavioral;
    --------------------------
    Brian Drummond, Oct 28, 2011
    #1
    1. Advertising

  2. Brian Drummond

    Guest Guest

    Brian Drummond <> wrote:
    > Is this expected behaviour, that the only valid library for direct
    > instantiation is "work"? And if so, why? It doesn't seem normal for the
    > VHDL language to single out one specific library name like this...


    No, i wouldn't expect that. In your example, there seems to be a name
    conflict. If you change

    > B : entity B.B_comp(Behavioral);


    to

    > B1 : entity B.B_comp(Behavioral);


    it'll work. At least for me :) (Modelsim Altera Starter Edition 6.6d)

    Don't know why this doesn't happen for A, though.

    Enrik
    Guest, Oct 28, 2011
    #2
    1. Advertising

  3. On Sat, 29 Oct 2011 11:56:50 +0100, Alan Fitch wrote:

    > On 28/10/11 21:16, wrote:
    >> Brian Drummond <> wrote:
    >>> Is this expected behaviour, that the only valid library for direct
    >>> instantiation is "work"? And if so, why? It doesn't seem normal for
    >>> the VHDL language to single out one specific library name like this...

    >>
    >> No, i wouldn't expect that. In your example, there seems to be a name
    >> conflict. If you change
    >>
    >>> B : entity B.B_comp(Behavioral);
    >>> B1 : entity B.B_comp(Behavioral);

    >>
    >> it'll work. At least for me :) (

    > Hi Brian,
    > as Enrik says there is a name conflict for B.

    ....
    > So the label B is hiding the library B, because label B is declared in
    > an enclosing scope.


    Thanks guys!
    Don't know why I didn't see that myself. It does clear one layer of
    confusion so that I can go on and look at the real problem.

    Step 1) Find problems with a real design and vendor tools...
    Step 2) Create a simple test case that fails in a different but vaguely
    similar way, (THIS is where I introduced the name conflict)
    Step 3) Find that the test case also fails in Modelsim
    Step 4) Post to Usenet, exposing a basic beginner mistake to the world...

    Now I can move on to Step 5... looking for the real problem.

    > Regarding the second case, I think (!) the visibility is as follows:
    > (all references to 1076-2002).

    ....
    >
    > So because the implicit specification appears before the label A: has
    > been declared, the library A is not hidden.


    Thank you!

    - Brian
    Brian Drummond, Oct 29, 2011
    #3
  4. On Sat, 29 Oct 2011 11:46:51 +0000, Brian Drummond wrote:

    > On Sat, 29 Oct 2011 11:56:50 +0100, Alan Fitch wrote:
    >
    >> On 28/10/11 21:16, wrote:


    >>> No, i wouldn't expect that. In your example, there seems to be a name
    >>> conflict.

    ....
    >> So the label B is hiding the library B, because label B is declared in
    >> an enclosing scope.


    > Don't know why I didn't see that myself. It does clear one layer of
    > confusion so that I can go on and look at the real problem.


    Which turned out to be a different name conflict, but also hiding the
    library. Thanks for providing the extra eyes...

    I've been spoiled by the Gnat Ada compiler, which is uncannily good at
    diagnostics : after "Cannot find name ..." types of errors, it prints a
    list of likely candidates with the reason they are hidden or not uniquely
    resolved...

    - Brian
    Brian Drummond, Oct 30, 2011
    #4
  5. Brian Drummond wrote:

    > On Sat, 29 Oct 2011 11:46:51 +0000, Brian Drummond wrote:
    >
    >> On Sat, 29 Oct 2011 11:56:50 +0100, Alan Fitch wrote:
    >>
    >>> On 28/10/11 21:16, wrote:

    >
    >>>> No, i wouldn't expect that. In your example, there seems to be a name
    >>>> conflict.

    > ...
    >>> So the label B is hiding the library B, because label B is declared in
    >>> an enclosing scope.

    >
    >> Don't know why I didn't see that myself. It does clear one layer of
    >> confusion so that I can go on and look at the real problem.

    >
    > Which turned out to be a different name conflict, but also hiding the
    > library. Thanks for providing the extra eyes...
    >
    > I've been spoiled by the Gnat Ada compiler, which is uncannily good at
    > diagnostics : after "Cannot find name ..." types of errors, it prints a
    > list of likely candidates with the reason they are hidden or not uniquely
    > resolved...


    Yep, the error messages by ModelSim/QuestaSim leaves quite a bit to be
    desired in the clarity department.

    A year ago I entered a service request to get a more clear message for
    the 'No feasible entries for subprogram "<name>"' error. Below is my
    complete SR text. The answer was:

    Unfortunately, the ER was turned down by Questa Engineering.
    Suggested using one of the linting tools: Leda, HDLint, nLint or SureLint.

    Sigh....

    I have no idea if these tools would produce a better error message in my
    case..

    The reasons for turning down my SR are:
    -criticality of the issue,
    -the number of customers reporting the issue,
    -the resources involved in making the change,
    -strategic product direction.

    Of course, we all can do something about the second point.


    Anyhow, here is the text of my service request:

    One of the most dreaded error messages that exists when analyzing VHDL
    with vcom is the message 'No feasible entries for subprogram "<name>"'.

    Even for seasoned VHDL programmers it is sometime daunting to solve such
    an error. Let alone the time it takes for a novice VHDL programmer to
    solve such an error.

    The reason why it can be daunting to solve such an error, is that vcom
    does not give any additional information as of why there are no feasible
    entries. Or even what the entries are that have been considered before
    deaclaring it an error.

    So what I would like to suggest is to enhance the error message with
    more information, and possibly the reason for the error. Ideally, this
    should give the user enough information to solve the problem in no time.
    I hope what I proposes is technically feasible.

    As an example, take the following piece of code:

    LIBRARY ieee;
    USE ieee.std_logic_1164.ALL;

    PACKAGE my_pkg IS
    PROCEDURE my_proc (ch: natural; n: natural );
    PROCEDURE my_proc (ch: natural; n: std_logic_vector );
    PROCEDURE my_proc (ch: natural; n: std_ulogic );
    END PACKAGE my_pkg;

    PACKAGE BODY my_pkg IS
    PROCEDURE my_proc (ch: natural; n: natural ) IS
    BEGIN
    END PROCEDURE my_proc;

    PROCEDURE my_proc (ch: natural; n: std_logic_vector ) IS
    BEGIN
    END PROCEDURE my_proc;

    PROCEDURE my_proc (ch: natural; n: std_ulogic ) IS
    BEGIN
    END PROCEDURE my_proc;
    END PACKAGE BODY my_pkg;

    ENTITY e IS
    END ENTITY e;

    USE work.my_pkg.ALL;

    -- LIBRARY ieee;
    -- USE ieee.std_logic_1164.ALL; -- Missing!

    ARCHITECTURE a OF e IS
    BEGIN
    doit: PROCESS IS
    BEGIN
    my_proc(123, '0'); -- Type mismatch due to std_(u)logic is not
    visible
    my_proc(123, nn => 0); -- Wrong formal parameter name
    WAIT;
    END PROCESS doit;
    END ARCHITECTURE a;


    Current vcom errors:

    ** Error: no_feasible_entries.vhd(36): No feasible entries for
    subprogram "my_proc".
    ** Error: no_feasible_entries.vhd(37): No feasible entries for
    subprogram "my_proc".
    ** Error: no_feasible_entries.vhd(40): VHDL Compiler exiting

    The first call of my_proc is not OK, because std_(u)logic is not
    visible. Therefore, the actual for the second parameter is only
    interpreted as a character or bit. It took me more than five minutes
    before I figured out that USE clause with std_logic_1164 was missing and
    that that was the culprit. The not so experienced user who made this
    error was stumped for much much longer.

    The second call of my_proc is not OK, because the name of a formal is
    not correct. Also this situation can be daunting at times.

    That's why I would like to propose a much more verbose error message.
    Something along these lines:

    ** Error: no_feasible_entries.vhd(36): No feasible entries for
    subprogram "my_proc".

    Visible declaration of subprogram "my_proc":
    work.my_pkg.my_proc(constant ch: in [natural]; constant n: in [natual]);
    work.my_pkg.my_proc(constant ch: in [natural]; constant n: in
    [std_logic_vector]);
    work.my_pkg.my_proc(constant ch: in [natural]; constant n: in
    [std_ulogic]);

    Possible interpretation of subprogram call:
    work.my_pkg.my_proc(ch => [natural constant]; n => [character constant]);
    work.my_pkg.my_proc(ch => [natural constant]; n => [bit constant]);

    Matched parameter(s) : ch
    Unmatched parameter : n (type error)

    ** Error: no_feasible_entries.vhd(37): No feasible entries for
    subprogram "my_proc".

    Visible declaration of subprogram "my_proc":
    work.my_pkg.my_proc(constant ch: in [natural]; constant n: in [natual]);
    work.my_pkg.my_proc(constant ch: in [natural]; constant n: in
    [std_logic_vector]);
    work.my_pkg.my_proc(constant ch: in [natural]; constant n: in
    [std_ulogic]);

    Possible interpretation of subprogram call:
    work.my_pkg.my_proc(ch => [natural constant]; nn => [character constant]);
    work.my_pkg.my_proc(ch => [natural constant]; nn => [bit constant]);
    work.my_pkg.my_proc(ch => [natural constant]; nn => [std_ulogic
    constant]); (assuming missing USE clause is present)

    Matched parameter(s) : ch
    Unmatched parameter : nn (no such name)
    Missing parameter(s) : n

    So first of all I would like to know what declarations of the subprogram
    are visible. Secondly, I would like to know what possible
    interpretations there are for my subprogram call. Finally, it would be
    very usefull to have an overview of matched, unmatched and missing
    parameters, given the visible declarations and the possible
    interpretations of the call.

    --
    Paul Uiterlinden
    www.aimvalley.nl
    e-mail addres: remove the not.
    Paul Uiterlinden, Oct 31, 2011
    #5
    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. valentin tihomirov

    direct instantiation, libraries

    valentin tihomirov, Apr 23, 2004, in forum: VHDL
    Replies:
    6
    Views:
    1,870
    valentin tihomirov
    Apr 26, 2004
  2. Rick Jackson
    Replies:
    8
    Views:
    2,683
    Rolf Eike Beer
    Dec 2, 2005
  3. Replies:
    1
    Views:
    562
    Salt_Peter
    Dec 25, 2006
  4. very_hdl
    Replies:
    0
    Views:
    443
    very_hdl
    Jul 3, 2008
  5. markla
    Replies:
    1
    Views:
    533
    Steven Cheng
    Oct 6, 2008
Loading...

Share This Page