Visibility of enumeration literals under use clauses

Consider a package, P, that declares:

type enum is (alpha, beta, gamma, omega);

In an architecture, we make enum directly visible by

use work.P.enum;

Question: Are the enumeration literals, alpha, beta, etc. also
directly visible?
I seems that NCSIM says no and ModelSim and Synplify say yes.

-biau

biau@altavista.com

wrote:
> Consider a package, P, that declares:
>
> type enum is (alpha, beta, gamma, omega);
>
> In an architecture, we make enum directly visible by
>
> use work.P.enum;
>
> Question: Are the enumeration literals, alpha, beta, etc. also
> directly visible?
> I seems that NCSIM says no and ModelSim and Synplify say yes.

Interesting, I confirm what you see (NCSIM and ModelSim). I don't have
the LRM here, so I can't look it up.

Of course if you use "use work.p.all", then it will work in all simulators.

Paul.

Paul Uiterlinden

I would be interesting to now if the LRM takes a clear position.
Is there an LRM expert who could comment?

biau@altavista.com

[ ... does: ]

use work.P.enum;

[ make only "enum" visible, or does it make all the enumeration members
visible? ]

> I would be interesting to now if the LRM takes a clear position.
> Is there an LRM expert who could comment?

I don't claim to be an expert at interpreting the VHDL LRM, but the
relevant section appears to be 10.4.

At least going by:

http://www.csee.umbc.edu/help/VHDL/p...76_Chap_10.pdf

(which I should point out is NOT a current or approved standard), 10.4
says:

-> A use clause achieves direct visibility of declarations that are
-> visible by selection.
->
-> use_clause ::=
-> use selected_name { , selected_name } ;
->
-> Each selected name in a use clause identifies one or more
-> declarations that will potentially become directly visible.

It then goes on to talk about the situations that determine whether the
declaration really becomes visible or not.

The bottom line, however, is that it seems consistent on one point: if
the the use clause makes anything visible at all, what it makes visible
is the entire declaration of that name, not just the name itself. In
the case of an enumeration, all of the enumeration literals should
become visible along with the name of the enumeration itself.

> Question: Are the enumeration literals, alpha, beta, etc. also
> directly visible?
> I seems that NCSIM says no and ModelSim and Synplify say yes.

I'd say NCSIM is wrong and ModelSim and Synplify are right (assuming
what I'm reading is accurate).

--
Later,
Jerry.

The universe is a figment of its own imagination.

Jerry Coffin

Hi,
If I understand you correctly, the following code should NOT compile
properly - is that right?

package p is
type t is (alpha, beta);
end package p;
entity e is
end entity e;
library work;
use work.p.t;
architecture rtl of e is
signal alpha : bit; -- "alpha" is re-used??
signal t1 : t;
begin -- architecture rtl
end architecture rtl;

Thanks,
Sri

--
Srinivasan Venkataramanan
Co-Author: SystemVerilog Assertions Handbook, http://www.abv-sva.org
Co-Author: Using PSL/SUGAR for Formal and Dynamic Verification 2nd Edition.
http://www.noveldv.com
I own my words and not my employer, unless specifically mentioned
<> wrote in message
news: ups.com...
> Consider a package, P, that declares:
>
> type enum is (alpha, beta, gamma, omega);
>
> In an architecture, we make enum directly visible by
>
> use work.P.enum;
>
> Question: Are the enumeration literals, alpha, beta, etc. also
> directly visible?
> I seems that NCSIM says no and ModelSim and Synplify say yes.
>
> -biau
>

Srinivasan Venkataramanan

Sri,

I did Investigations A, B, C, D and E, below, and made some
conslusions. Tools used were ModelSim 5.7e, Synplify Pro 7.7.1, NC-SIM
5.10 and XST 6.2i.


INVESTIGATION A

As written, your code compiles without error messages in ModelSim,
Synplify Pro and NC-SIM but gets errors in XST. XST complains about an
entity without ports (an unrelated issue), so I added ports, i.e.,

package p is
type t is (alpha, beta);
end package p;
entity e is port (a: in bit; z: out bit);
end entity e;
library work;
use work.p.t;
architecture rtl of e is
signal alpha : bit; -- "alpha" is re-used??
signal t1 : t;
begin -- architecture rtl
z <= a;
end architecture rtl;

and got these results from the tools:
--
ModelSim - no error message
Synplify - no error message
XST - no error message
NC-SIM - no error message



INVESTIGATION B

Now, if the "signal t1 : t;" line is modified to "signal t1 : t :=
alpha;"
(i.e. an actual reference to one of the enumeration literals)

package p is
type t is (alpha, beta);
end package p;
entity e is port (a: in bit; z: out bit);
end entity e;
library work;
use work.p.t;
architecture rtl of e is
signal alpha : bit; -- "alpha" is re-used??
signal t1 : t := alpha;
begin -- architecture rtl
z <= a;
end architecture rtl;

then we get from the various tools:
--
ModelSim - "Type error in variable alpha. Needed type t."
Synplify - "Expression does not match type t"
XST - "Type of t1 is incompatible with type of alpha."
NC-SIM - "expecting an expression of type T [4.3.1.2]"


INVESTIGATION C

Below is a version that is analogous to the case that prompted my
original post.

package p is
type t is (alpha, beta);
end package p;
entity e is port (a: in bit; z: out bit);
end entity e;
library work;
use work.p;
use work.p.t;
architecture rtl of e is
signal t1 : t := alpha;
begin -- architecture rtl
z <= a;
end architecture rtl;

The results for the tools are:
--
ModelSim - no error message
Synplify - no error message
XST - no error message
NC-SIM - "identifier (ALPHA) is not declared [10.3]"


INVESTIGATION D

Notice that Investigation C has a superfluous "use work.p;" clause. If
this clause is removed, i.e.,

package p is
type t is (alpha, beta);
end package p;
entity e is port (a: in bit; z: out bit);
end entity e;
library work;
use work.p.t;
architecture rtl of e is
signal t1 : t := alpha;
begin -- architecture rtl
z <= a;
end architecture rtl;

then, surprisingly, the behavior of Synplify and XST changes and
error messages are reported:
--
ModelSim - no error message
Synplify - "No identifier "alpha" in scope"
XST - "Undefined symbol 'alpha'"
NC-SIM - "identifier (ALPHA) is not declared [10.3]"


INVESTIGATION E

Attempting to make the enumeration literal, alpha, directly visible
through a USE clause, i.e.,

package p is
type t is (alpha, beta);
end package p;
entity e is port (a: in bit; z: out bit);
end entity e;
library work;
use work.p.t;
use work.p.alpha;
architecture rtl of e is
signal t1 : t := alpha;
begin -- architecture rtl
z <= a;
end architecture rtl;

gave these results:
--
ModelSim - no error message
Synplify - no error message
XST - no error message
NC-SIM - no error message


CONCLUSIONS

Some conclusions reached -- but reasoned contrasting viewpoints would
be welcome, as would results for other tools:

(1) Since your original code (Investigation A) didn't "stress" the VHDL
analysis by referring to a packaged enumeration literal, it probably
didn't test what you had in mind. In the case of ModelSim, even though
ModelSim considers the enumeration literal alpha to be directly
visible, the local declaration overrides. For the other tools, it isn't
considered directly visible and, since it is not referenced, causes
no complications.

(2) XST does unneccesary error checking (even potentially
counter-productive) in not allowing an entity with an empty port list.

(3) XST and Synplify are wrong to make an enumeration literal declared
in a package directly visible by simply making the package visible.

(4) In the end, it is unclear whether ModelSim or NC-Sim is correct
with respect to Investigations C and D. Jerry Coffin's interpretation
of the LRM--i.e. that declarations are made visible, not just the name
being declared--sides with ModelSim and I have sympathy for this
viewpoint, but is this an area where the LRM is not sufficiently clear?

(5) All four investigated tools consider an enumeration literal to be a
package object that can be made visible through a USE clause
(Investigation E).

biau

biau@altavista.com

wrote:

[ ... ]

> (4) In the end, it is unclear whether ModelSim or NC-Sim is correct
> with respect to Investigations C and D. Jerry Coffin's interpretation
> of the LRM--i.e. that declarations are made visible, not just the
name
> being declared--sides with ModelSim and I have sympathy for this
> viewpoint, but is this an area where the LRM is not sufficiently
clear?

Given the divergence in implementations, I think it's safe to say that
clarification would be a _very_ good thing.

--
Later,
Jerry.

The universe is a figment of its own imagination.

Jerry Coffin

On 25 Jan 2005 09:08:02 -0800, "Jerry Coffin"
<> wrote:
[ ... ]

>> (4) In the end, it is unclear whether ModelSim or NC-Sim is correct
>> with respect to Investigations C and D. Jerry Coffin's interpretation
>> of the LRM--i.e. that declarations are made visible, not just the
>name
>> being declared--sides with ModelSim and I have sympathy for this
>> viewpoint, but is this an area where the LRM is not sufficiently
>clear?
>
>Given the divergence in implementations, I think it's safe to say that
>clarification would be a _very_ good thing.

The 1076-2002 standard is pretty unambiguous; in section 10.4 it
states clearly that if you "use" a simple name then ONLY that name's
declaration is made visible. In fact it says "declaration(s)", but
this relates to the fact that a subprogram name can have many
overloaded declarations. This confirms what I have understood
for some time - I must've read it in a book somewhere.

Consequently, an implementation that imports enumeration literals
"for free" along with the type name is non-compliant. I was not
aware that ModelSim did this. It doesn't appear to be one of the
language rules that ModelSim allows you to relax by tweaking its
modelsim.ini file.

It's interesting that there has recently been a lot of discussion
in the SystemVerilog standardisation working groups about exactly
this point. I can't remember just now what the final decision
was, but it caused some animated debate.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL, Verilog, SystemC, Perl, Tcl/Tk, Verification, Project Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, BH24 1AW, UK
Tel: +44 (0)1425 471223 mail:
Fax: +44 (0)1425 471573 Web: http://www.doulos.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

Jonathan Bromley

[In fact it says "declaration(s)", but this relates to the fact that a
subprogram name can have many overloaded declarations.]

This "massaging" of the term "declaration"--a nuance that is likely not
explicit in the LRM--is in itself an argument that the LRM is not clear
on the point. That two conscientious companies reached different
conclusions is another.

biau@altavista.com

Jonathan Bromley wrote:

[ ... ]

> The 1076-2002 standard is pretty unambiguous; in section 10.4 it
> states clearly that if you "use" a simple name then ONLY that name's
> declaration is made visible.

Yes, it's so unambiguous that even though you seem to be quite
intelligent, you're interpreting it completely incorrectly.

The standard does not say that only that name is made visible -- it
says that the _declaration_ is made visible. An enumeration
declaration, however, can create more than one name: specifically, it
creates the name of the enumeration type itself, AND it can also create
an arbitrary number of enumeration literals.

If your interpretation was taken as correct, then even within the scope
of the enumeration declaration, the names of the enumeration literals
would not be visible -- the standard seems to use the same terms to
decribe the visibility of a declaration whether because it is in scope
or because it has been use'd.

--
Later,
Jerry.

The universe is a figment of its own imagination.

Jerry Coffin