-------------BEGINNING OF IR----------------

VHDL Issue Number:      2042

Language_Version:       VHDL-2002
Classification:         Language Definition Problem
Summary:                Architecture as a block causes problems
Relevant_LRM_Sections:  1.2 Architecture bodies, 
                        9.6.1 Instantiation of a component, 
                        9.6.2 Instantiation of a design entity, 
                        10.1 Declarative region, 
                        12.4.3 Component instantiation statements
    
Related_Issues: 
Key_Words_and_Phrases:  entity, architecture, block, visibility
Authors_Name:           Chuck Swart
Authors_Phone_Number:   503.685.0846
Authors_Fax_Number:     503.685.0921
Authors_Email_Address:  cswart@model.com
Authors_Affiliation:    Model Technology
Authors_Address1:       8005 SW Boeckman Road
Authors_Address2:       Wilsonville, OR 97070
Authors_Address3:   

Current Status:         VASG-Approved

Superseded By:

------------------------
Date Submitted:         01 October 2004
Date Analyzed:          Commenced 19-Oct-04
Author of Analysis:     Peter Ashenden
Revision Number:        0.6
Date Last Revised:      20 July 2005

Description of Problem
----------------------

In versions of VHDL before VHDL-2002, entities and their corresponding
architectures form a single declarative region. In VHDL-2002, the
architecture body forms a block contained within the block
corresponding to the entity. Although this change clears up some
subtle visibility issues, in my opinion, it creates more new problems
than it solves.

First, the new interpretation changes visibility rules. Some code
which was previously legal now becomes illegal, and vice
versa. Admittedly, these cases are rather esoteric.

Second, Since almost every design has a new block, pathnames are
different. (This change appears to not have been reflected in the
description of path name attributes.) As a consequence, virtually all
pathnames are incompatible between VHDL-2002 and previous
versions. This change causes problems with other tools which use VHDL
pathnames, especially pathnames in SDF and, probably, the generic
InstancePath in VITAL.

These serious incompatibilities are not worth the small benefits
gained by the new interpretation of an architecture as a nested block
within its entity.
    

Proposed Resolution
-------------------

Revert to previous VHDL-2002 rules in which architectures are an
extension of their corresponding entities.

VASG-ISAC Analysis & Rationale
------------------------------

VHDL-2002 changed the rules relating to declaration of architectures
to resolve issues relating to visibility of entity and architecture
names.  The LCS identifying the issue is LCS-3 for VHDL-2002
(hereafter referred to as LCS-2002-3).  Analysis of the issue
identified a number of related issues that needed to be addressed
concurrently.  An archive of email discussions tracing development of
the solution is available from the author of this analysis and forms
useful background for the current issue.

However, it appears that the proposed changes did not get wide
enough circulation, as significant disapproval has subsequently
arisen.  (See the thread "Issues with VHDL name attributes" on the
vhdl-200x email list.)  The consensus appears to be in favour of
reverting to the pre-2002 model of architectures forming a
discontiguous extension of the entity declarative region.

In reverting to that model, it is not sufficient simply to undo the
LRM changes made in the 2002 revision, as that would reinstate the
issues those changes attempted to solve.  Rather, alternate changes
need to be made that address those issues while reverting to the old
model.

An important aspect addressed by LCS-2002-3 is the introduction of
root and library declarative regions.  These address the issues
associated with visibility of primary unit names, and should remain in
the LRM.

A review of requirements from the LCS-2002-3 discussion (see message
dated 01-Jul-1999 from Ashenden in the email archive) included the
following:

    For the following model:

      entity E is
        port (P : ...);
      end entity E;

      architecture A of E is
        constant C : ...;
        ...
      begin
        ...
      end architecture A;

    Within the entity and the architecture, we should be able to use
    the names

      Work.E and E to refer to the entity
      Work.E.P and E.P to refer to the port

    Within the architecture only, we should be able to use the name

      A.C to refer to the constant

    We should not be able to use the names

      Work.E.C or E.C to refer to the constant
      A.P to refer to the port

    Furthermore, we agreed that it would be highly desirable to allow

      architecture E of E

    since a number of designers use such architecture names in practice.
    Also, it seems reasonable to allow it, since the set of architecture
    names for a given entity intuitively form a subsidiary name space of
    the entity.

That message also presented a diagram showing proposed nesting of
declarative regions and the a case analysis of legal and illegal
names.

A revised nesting of declarative regions, keeping the current LRM's
model of an outer declarative region but making the architecture
declarative part a continuation of the entity declarative region, can
be illustrated as follows:

    +--ODR------------------------+ 
    |                             |  \
    |   +--DEDR---------------+   |   \
    |   |                     |   |    entity design unit
    |   |                     |   |   /
    |   |                     |   |  /
    + - + - - - - - - - - - - + - + 
    |   |                 |   |  \
    |   |                 |   |   \
    |   |                 |   |    architecture design unit
    |   +---------------------+   |   /
    |                         |  /
    +-----------------------------+

Here, the entity and architecture declarative parts jointly form a
design entity declarative region (DEDR), which is logically nested
within the outer declarative region (ODR).  For each library, there is
also a library declarative region (LDR), in which the design entities
are logically nested.  This includes a library design unit for WORK
(LDR-W).

Referring back to the example entity E and architecture A of E:

The entity should be a declaration that occurs immediately within the
ODR while it and corresponding architecture bodies are analyzed.
Visibility of the entity name should be determined by the normal
visibility rules.

The entity is also declared immediately within the LDR of the library
into which it is analyzed.  Again, visibility of the entity name
should be determined by the normal visibility rules.

The entity name denotes the design entity.  Within the entity
declaration, declarations in the entity declarative part should be
visible.

A question to consider is whether the entity name should denote the
entire DEDR, or whether it should denote only that part of the DEDR
corresponding to the entity declarative part.  The VHDL-93 LRM defined
an equivalent-block structure for instantiation of design entities, in
which an instance of a design entity is elaborated to a block
statement with the entity name as the label, and the combined entity
and architecture declarative and statement parts as the block
declarative and statement parts.  In the block statement so
elaborated, the entity name corresponds to the entire declarative
region formed by the block.  To be consistent with this model, the
entity name should denote the entire DEDR.  However, when analyzing an
entity declaration, only the part of the DEDR corresponding to the
entity declarative part is available.

A consequence of the above rules is that, within A, we can refer to C
as Work.E.C and E.C, even though C is declared within A.  However, we
can rationalize this by considering that the declarative part of A
extends that of E to form the DEDR, and so C becomes a declaration of
E by extension.

The architecture should be a declaration, so that rules pertaining to
names can be applied, but special cases need to be made in the scope
and visibility rules to deal with the fact that an architecture name
is subordinate to the corresponding entity.

The architecture should not be declared immediately within the ODR or
a LDR.  If it were, special rules would have to apply to permit it to
be the same as the entity name, and overload resolution would have to
be extended to disambiguate between like entity and architecture
names.

Rather, we would consider the architecture to be declared in no
declarative region.  We would identify all of the cases where an
architecture name can be referenced.  In those places that are
currently subsumed as a reference to a named entity, we would make a
special case for architecture names (eg, in attribute specifications).
In other places, we would make sure we explicitly refer to an
architecture name as a special kind of name, rather than as a declared
name, a declaration, or a name that denotes a named entity.

We turn now to the question of whether an architecture name should
denote the entire DEDR (effectively forming an alias for the entity
name), or whether it should denote only that part of the DEDR
corresponding to the architecture's declarative part.

Case a) architecture name denotes entire DEDR

   Within A, we could refer to P as Work.E.P, E.P, A.P and P; and to C
   as Work.E.C, E.C, A.C and C.

   Being able to refer to A.P within A appears strange, since P is
   declared as part of the entity declaration.  Menchini, in the email
   archive, indicated that the intention in VHDL-93 was not to allow
   such referencing.

Case b) architecture name denotes only architecture declarative part

   Within A, we could refer to P as Work.E.P, E.P and P, but not A.P;
   and we could refer to C as Work.E.C, E.C, A.C and C.

   This approach is closer to intuitions, and accords with the
   intention for VHDL-93 as indicated by Menchini in the email
   archive.  It is the approach recommended by the author of this
   analysis.

With this approach give, we now consider implications for and
architecture with the same name as its corresponding entity, that is,
architecture E of E.  Assume that this architecture also declare
constant C as before.

In order to make this legal, the scope and visibility rules would need
to specify that the architecture name hides the entity name in those
places where the architecture name is in scope and visible.  Then,
within architecture E, we could refer to P as Work.E.P and P, but not
E.P, the last because the prefix E would denote the architecture
instead of the entity; and we could refer to C as Work.E.C, E.C and C,
with the prefix of E.C being interpreted as the architecture name.

Now consider architecture P of E, with E declaring port P as before.
This would be illegal in VHDL-2002, since port P and architecture P
would be homographs in the same declarative region.  In the approach
suggested here, the architecture name P is not declared in the DEDR,
and so may be of the same name as a declaration in the entity.
However, within the architecture, the architecture name would hide the
entity's declaration.  Hence, within architecture P, could refer to
port P as Work.E.P and E.P, but not P.

VASG-ISAC Recommendation for IEEE Std 1076-2002
-----------------------------------------------

Interpret IEEE Std 1076-2002 as though amended with the corrections
identified for future revisions.

VASG-ISAC Recommendation for Future Revisions
---------------------------------------------

Identify specific changes to revert to the pre-2002 rules for
architecture names, as described in the analysis, with architecture
names denoting only architecture declarative parts.  Implement those
changes as part of the next revision to the standard.


-------------END OF IR----------------