Direct entity instantiation...

[Brian Drummond]

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;
--------------------------

 

[Guest]

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

 

[Brian Drummond]

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]

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

 

[Paul Uiterlinden]

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.