VHDL Issue Number:      0020
Classification:         Language Definition Problem
Language Version:       VHDL-87
Summary:                Restrictions on use of deferred constants are overly
                        restrictive.
Related Issues:         0008, 0059
Relevant LRM Sections:  2.2, 2.6, 4.3.1.1, 12.5
Key Words and Phrases:  Deferred Constant, Full Declaration, Package,
                        Package Body, Subprogram Body, Dynamic Elaboration
Current Status:         ISAC-Approved
1076-1993 Disposition:  Bugs Fixed, Enhancements Outstanding (No ISAC Issues)
Disposition Rationale:  Non-ISAC issues remaining.
Superseded By:          N/A
-----------------------
Date Submitted:         1989/02/23
Author of Submission:   Paul Menchini
Author's Affiliation:   CAD Language Systems, Inc.
Author's Post Address:  P.O. Box 13036
                        Research Triangle Park, NC  27709-3036
Author's Phone Number:  (919) 361-1913
Author's Fax Number:    
Author's Net Address:   mench@clsi.com
-----------------------
Date Analyzed:          1990/10/01
Author of Analysis:     Doug Dunlop
Revision Number:        $Revision: 1.6 $
Date Last Revised:      $Date: 1995/08/03 15:58:28 $


Description of Problem
----------------------
Consider the following VHDL design units:

   package P is
     constant C: Integer;      -- a deferred constant
     -- Place 1
   end P;

   package body P is
     -- Place 2

     procedure Proc is
       -- Place 3
     begin
       -- Place 4
     end Proc;

     constant C : Integer := 0;   -- the full declaration of the
                                  -- deferred constant
   end P;

The LRM states, in paragraph 5 of Section 2.6, that references to C prior to
its corresponding full declaration are allowed only under restricted
circumstances.  Specifically, a name denoting the deferred constant can be used
only "in the default expression for a local generic, local port, or formal
parameter."  Thus, Places 1 through 4 in the above example are treated
identically.  Since declarations appearing in Places 1 and 2 (except for those
mentioned in the LRM quotation) require the value of C when those declarations
are elaborated, the restriction is proper for these places.

This restriction is unnecessary in Places 3 and 4.  While the elaboration of
the subprogram body will occur prior to the elaboration of the full declaration
of C, the elaboration of the subprogram declarative part (Place 3) and the
execution of its statement part (Place 4) occur only when the subprogram is
invoked.  Thus, the restriction on the use of C in these places is unnecessary.


Proposed Resolution
-------------------
Modify the language of paragraph 5 of Section 2.6 to allow unrestricted
reference to deferred constants before the full declaration corresponding full
declaration when the reference occurs within a subprogram body.  Suggested
language for the first sentence of paragraph 5 of Section 2.6 is:

  "Within a package declaration that contains the declaration of a
   deferred constant, and within the body of that package, before
   the end of the corresponding full declaration, the use of a name
   that denotes the deferred constant is only allowed within a
   subprogram body, or in the default expression for a local
   generic, local port, or formal parameter."


VASG-ISAC Analysis & Rationale
------------------------------
The problem described above is accurate.  However, the suggested solution
does not treat adequately a case such as:

   package P is
     constant C: Integer;      -- a deferred constant
   end P;

   package body P is

     function Func return Integer is
       -- Place 3
     begin
       -- Place 4
     end Proc;

     constant K : Integer := Func;

     constant C : Integer := 0;   -- the full declaration of the
                                  -- deferred constant
   end P;

For a situation such as this, a use of a deferred constant in Places 3 or
4 will be erroneous because function Func is invoked prior to the elaboration
of the full declaration of the deferred constant. Rather than complicating
the proposed rule to disallow this case while allowing the original example,
we lean toward not do anything about this problem for now.  Yes it is true the
rules are technically overly restrictive but it does not seem this problem
arises often in practice.  In fact, it seems users typically supply the full
declaration of the deferred constant at the top of the package body; there
is simply no advantage to burying the full declaration well into the package
body.


VASG-ISAC Recommendation for IEEE Std 1076-1987
-----------------------------------------------
We suggest that VHDL world live with the current rules regarding
deferred constants since little or no hardship is imposed in practice.


VASG-ISAC Recommendation for Future Revisions
---------------------------------------------
If a simple enough rule could be found that would relax restrictions on the
use of deferred constants and still be safe, this should be considered.