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

 

[Paul Uiterlinden]

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.

 

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

 

[Jerry Coffin]

[ ... 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/p1076/P1076_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.

 

[Srinivasan Venkataramanan]

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
<biau@altavista.com> wrote in message
news:1106177893.381927.48150@z14g2000cwz.googlegroups.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

 

[Jerry Coffin]

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.

 

[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.

 

[Jerry Coffin]

Jonathan Bromley wrote:

[ ... ]

See section 3.1.1, describing what's going on
in an "enumeration type definition", i.e. the parenthesised list
of enumeration literals that forms part of an enumeration type
declaration:

Each enumeration literal is the declaration of the
corresponding enumeration literal

In other words, when you write something like

type T is (A,B,C,D);

you have in fact written several distinct declarations - one
for the type name and one for each literal name.

I've seen it, but I'm still convinced that you're reading it
incorrectly. In 4.1 we see that the type_definition is _part of_ the
type declaration. In 3.1.1 we find that the enumeration literal
declarations are, in turn, parts of the type definition.

The enumeration declaration as a whole is made visible. This does not
mean the declaration minus some parts is made visible, but that _all_
the parts are made visible, including whatever enumeration literal
declarations it may contain.

--
Later,
Jerry.

The universe is a figment of its own imagination.

 

[Jonathan Bromley]

On 31 Jan 2005 10:19:18 -0800, "Jerry Coffin"
<jcoffin@taeus.com> wrote:

I've seen it, but I'm still convinced that you're reading it
incorrectly. In 4.1 we see that the type_definition is _part of_ the
type declaration. In 3.1.1 we find that the enumeration literal
declarations are, in turn, parts of the type definition.

I don't dispute for a moment that the literals are part of the
*syntax* of the type declaration. That ain't the point.
For an enumeration type, 3.1.1 clearly states that each
of the literals is its own declaration, which solves at
a stroke the problem you outlined in the previous post
(how does the type declaration make the literal names
visible? It doesn't - the literals are declared separately
as part of the same piece of syntax).

The enumeration declaration as a whole is made visible.

I agree that the LRM gets a bit bogged down in overloaded
terminology around this stuff - for example, in the fragment of
3.1.1 that I quoted, the phrase "enumeration literal" appears
twice without qualification or explanation. In this case,
the context clearly requires its first appearance to mean
"the name as it appears in the definition" whereas the
second appearance means "the object denoted by the enumeration
literal". There may well be other places where things are not
quite so clear. Despite these difficulties, I really don't see
where you find your authority for your statement above.

This does not
mean the declaration minus some parts is made visible, but that _all_
the parts are made visible, including whatever enumeration literal
declarations it may contain.

Again, I don't see a clear pathway from the LRM text *as a whole*
to that statement. But I also concede that "my" interpretation
is not blindingly obvious from the LRM text. "My" in quotes
because I'm far from alone in seeing it!
--
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:jonathan.bromley@doulos.com
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.

 

[Jerry Coffin]

Jonathan Bromley wrote:

[ ... ]

I don't dispute for a moment that the literals are part of the
*syntax* of the type declaration. That ain't the point.

What's the point of the syntax, if not to describe the language?

In any case, I've just seen Mr. Swart's post, which seems to render our
continuing on the subject more or less pointless.

--
Later,
Jerry.

The universe is a figment of its own imagination.

 

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

 

[Jonathan Bromley]

On 25 Jan 2005 09:08:02 -0800, "Jerry Coffin"
<jcoffin@taeus.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.

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:jonathan.bromley@doulos.com
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.

 

[Jerry Coffin]

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.

 

[Jonathan Bromley]

On 29 Jan 2005 13:34:26 -0800, "Jerry Coffin"
<jcoffin@taeus.com> 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.

Not so fast! Plaudit and brickbat both delivered
much too hastily here

The standard does not say that only that name is made visible -- it
says that the _declaration_ is made visible.
[by a use clause such as "use lib.pkg.typename;"]

Correct.

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.

Incorrect. The enumeration literals are "created" [sic] by their
own declarations. See section 3.1.1, describing what's going on
in an "enumeration type definition", i.e. the parenthesised list
of enumeration literals that forms part of an enumeration type
declaration:

Each enumeration literal is the declaration of the
corresponding enumeration literal

In other words, when you write something like

type T is (A,B,C,D);

you have in fact written several distinct declarations - one
for the type name and one for each literal name.

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.

You had me very worried when you wrote this, because it seems so
reasonable. But once again, on *very* close reading of the LRM
we find that its authors were extremely careful to tie everything
together. They were, arguably, less successful in making it easy
to find the answer to a single specific question by a
straightforward reading of the apparently relevant section; you
generally have to read stuff from all over the LRM because each
section of the manual does so much work in providing definitions
and context for subsequent sections. So I can't claim I have
a complete definitive solution here.

Not long after 1076-1987 was published, an additional document
of "Interpretations" was also released to clarify some tricky
issues in the LRM. I am fairly sure that this issue was one
of those raised in that interpretations document, but I can't
track down a copy right now. Maybe someone else can recall
whether it addressed this problem?
--
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:jonathan.bromley@doulos.com
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.

 

[Chuck Swart]

My name is Chuck Swart and I am the chair
of the VHDL ISAC (Issue Screening and Analysis Committee).
The role of this committee is to resolve technical issues with the
VHDL LRM.

The question of visibility of enumeration literals under use clauses
along with visibility of the predefined operators has been reported
as IR (Issue Report) 2058: Does USE of type name make operators and
literals visible?

You can follow the progress of this and other open issues by going to
eda.org and clicking on "isac". The committee encourages you to use the
"Bugs and Enhancements" form to submit issues like this.




biau@altavista.com wrote:

[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.

 

[Jonathan Bromley]

On Mon, 31 Jan 2005 10:31:20 -0800, Chuck Swart <cswart@model.com>
wrote:

My name is Chuck Swart and I am the chair
of the VHDL ISAC (Issue Screening and Analysis Committee).
The role of this committee is to resolve technical issues with the
VHDL LRM.

The question of visibility of enumeration literals under use clauses
along with visibility of the predefined operators has been reported
as IR (Issue Report) 2058: Does USE of type name make operators and
literals visible?

Thanks!
--
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:jonathan.bromley@doulos.com
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.