VHDL Issue Number:      1089
Classification:         Language Deficiencies and Modeling Problems
Language Version:       VHDL-93
Summary:                Visibility problem with components and USE clauses
Related Issues:         0048
Relevant LRM Sections:  1.3.2, 5.2.2, 10.3, 10.4, 10.5
Key Words and Phrases:  Entity aspect, default binding indication, visibility
Current Status:         Submitted
-----------------------
Date Submitted:         1994/05/17
Author of Submission:   Charles Swart
Author's Affiliation:   Mentor Graphics Corporation
Author's Post Address:  8005 S.W. Boeckman Road
                        Wilsonville, OR 97070-7777
Author's Phone Number:  (503) 685-1332
Author's Fax Number:    (503) 685-1268
Author's Net Address:   chuck_swart@mentorg.com
-----------------------
Date Analyzed:          TBD
Author of Analysis:     TBD
Revision Number:        $Revision: 1.4 $
Date Last Revised:      $Date: 1995/05/15 20:07:17 $


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

  Default binding is intended to map a component to an entity with the
same name. However, the visibility rules for VHDL prevent components
and entities with the same name from being directly visible
simultaneously. This problem has been solved in VHDL-93 for components
declared in blocks. However, the problem still remains for components
in packages, where direct visibility is achieved by means of USE
clauses.

   For example, consider the following code fragment:


package P is
    component E is
        ...
    end component;
end package P;

entity E is
    ...
end E;

use Work.E;
use Work.P.E;
entity Top is
end Top

architecture Structure of Top is
begin
    label1: E; -- default binding doesn't work here.
end Structure;

   This code doesn't work on conforming implementations because E is
not visible at the point of component instantiation.

   There is a language-compatible solution to the problem. 
Remove the

   use Work.P.E;

clause, and replace

    label1: E;

with 

    label1: Work.P.E; 

   However, this solution is unnatural and many designers feel that
the above case should be legal as written. Moreover, many tools have
adopted non-standard solutions to make examples like this work. Many
of these non-standard extensions were no doubt added because of the
known inconsistency in VHDL-87 described by IR 0048, but the plethora
of extensions has created a portability nightmare.

   One extension in particular deserves mention. At least one
implementation solves the problem by removing

    use Work.E;

   Then, when doing default binding, all referenced libraries are
searched for an appropriately named entity. For implementations like
this, some notion of library search rules is needed.


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

   Change the visibility rules so that entities and components are not
homographs. Thus, they can both be directly visible at the same time.
Since components and entities are never used in the same context,
there should be no significant difficulty for the analyzer to
determine which name is intended.

   A similar situation already exists in Ada, from which VHDL's scope
and visibility rules were derived. Ada has a concept called a task
entry.  Entry calls are syntactically identical to procedure
calls. However, entries and procedures with the same name are not
considered homographs: Context is used to distinguish an entry call
from a procedure call with the same name. (See "The Ada Compiler
Validation Capability Implementor's Guide", December, 1986, page
8-47).

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


VASG-ISAC Recommendation for IEEE Std 1076-1993
-----------------------------------------------
TBD


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