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

 

Brian Drummond <brian@shapes.demon.co.uk> 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

 

[Alan Fitch]

On 28/10/11 21:16, enrik@starfleet.inka.de wrote:

Brian Drummond <brian@shapes.demon.co.uk> 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

Hi Brian,
as Enrik says there is a name conflict for B. The 2002 standard says

"All concurrent statements may be labeled. Such labels are implicitly
declared at the beginning of the declarative part of the innermost
enclosing entity declaration, architecture body, block statement, or
generate statement."

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

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

1. Section 5, specifications, says

"A specification always relates to named entities that already exist;
thus a given specification must either follow or (in certain cases) be
contained within the declaration of the entity to which it relates.
Furthermore, a specification must always appear either immediately
within the same declarative part as that in which the declaration of the
named entity appears, or (in the case of specifications that relate to
design units or the interface objects of design units, subprograms, or
block statements) immediately within the declarative part associated
with the declaration of the design unit, subprogram body, or block
statement."

which means a configuration specification for a component must appear in
the declarative region associated with the declaration of the component.
So in your case, the component A_Comp is declared in the entity,
therefore a configuration specification appears in the entity
declarative region.

2. In 5.2.2 it is specified that there is a default binding indication
if a component instance is not explicitly bound (which would appear in
the entity declarative region). That default binding indication binds a
visible entity declaration, which includes the case

"c) An entity declaration denoted by “L.C”, where L is the target
library and C is the simple name of the instantiated component. The
target library is the library logical name of the library containing the
design unit in which the component C is declared."

which applies in your case.

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

regards
Alan

--
Alan Fitch

 

[Brian Drummond]

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

On 28/10/11 21:16, enrik@starfleet.inka.de wrote:
Brian Drummond <brian@shapes.demon.co.uk> 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]

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, enrik@starfleet.inka.de 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

 

[Paul Uiterlinden]

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, enrik@starfleet.inka.de 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.