Visibility of enumeration literals under use clauses

Discussion in 'VHDL' started by biau@altavista.com, Jan 19, 2005.

  1. Guest

    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
     
    , Jan 19, 2005
    #1
    1. Advertising

  2. 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, Jan 20, 2005
    #2
    1. Advertising

  3. Guest

    I would be interesting to now if the LRM takes a clear position.
    Is there an LRM expert who could comment?
     
    , Jan 20, 2005
    #3
  4. Jerry Coffin Guest

    [ ... 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.
     
    Jerry Coffin, Jan 20, 2005
    #4
  5. 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:...
    > 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, Jan 21, 2005
    #5
  6. Guest

    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
     
    , Jan 24, 2005
    #6
  7. Jerry Coffin Guest

    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, Jan 25, 2005
    #7
  8. 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, Jan 25, 2005
    #8
  9. Guest

    [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.
     
    , Jan 28, 2005
    #9
  10. Jerry Coffin Guest

    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, Jan 29, 2005
    #10
  11. On 29 Jan 2005 13:34:26 -0800, "Jerry Coffin"
    <> 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:
    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, Jan 31, 2005
    #11
  12. Jerry Coffin Guest

    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.
     
    Jerry Coffin, Jan 31, 2005
    #12
  13. Chuck Swart Guest

    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.




    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.
    >
     
    Chuck Swart, Jan 31, 2005
    #13
  14. On 31 Jan 2005 10:19:18 -0800, "Jerry Coffin"
    <> 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:
    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, Jan 31, 2005
    #14
  15. On Mon, 31 Jan 2005 10:31:20 -0800, Chuck Swart <>
    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:
    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, Jan 31, 2005
    #15
  16. Jerry Coffin Guest

    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.
     
    Jerry Coffin, Feb 1, 2005
    #16
    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. John Goche
    Replies:
    8
    Views:
    16,571
  2. Diez B. Roggisch

    for what are for/while else clauses

    Diez B. Roggisch, Nov 14, 2003, in forum: Python
    Replies:
    32
    Views:
    829
    Michele Simionato
    Nov 28, 2003
  3. Fredrik Lundh

    Re: for what are for/while else clauses

    Fredrik Lundh, Nov 18, 2003, in forum: Python
    Replies:
    1
    Views:
    339
    Georgy Pruss
    Nov 18, 2003
  4. Jyotirmoy Bhattacharya

    nested list comprehension and if clauses

    Jyotirmoy Bhattacharya, Jun 28, 2007, in forum: Python
    Replies:
    5
    Views:
    331
    Jyotirmoy Bhattacharya
    Jun 28, 2007
  5. puvit82
    Replies:
    4
    Views:
    779
    puvit82
    Feb 1, 2008
Loading...

Share This Page