VHDL Issue Number:      2026

Language_Version:       VHDL-2002
Classification:         Language Modeling Enhancement or Deficiency
Summary:                Upward propagating parameters
Relevant_LRM_Sections:  12.* Elaboration and others
Related_Issues: 
Key_Words_and_Phrases:  Generic parameter elaboration
Authors_Name:           Jonas Nilsson
Authors_Phone_Number:   +46 (0)70 688 1687
Authors_Fax_Number: 
Authors_Email_Address:  jonas@hardi.se
Authors_Affiliation:    HARDI Electronics AB
Authors_Address1:       Dalbyvagen 22
Authors_Address2:       SE 224 60 LUND
Authors_Address3:       SWEDEN

Current Status:         Forwarded

Superseded By:

------------------------
Date Submitted:         26 March 103
Date Analyzed:          1-Nov-04
Author of Analysis:     Peter Ashenden
Revision Number:        2
Date Last Revised:      07 January 2005

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

The ability for a child (module instance) to influence it's parent
during elaboration through a static parameter is meaningful in many
cases. For instance, a child may inform its parent of its latency or
I/O bus width, which could cause the parent to modify its behaviour
accordingly, declare appropriate signals/constants or choose to
instantiate appropriate architectures of other modules depending on
this value.
     
This feature has implications on the notion of "staticness" of
expressions. It would implicate that parents cannot be fully
elaborated before their children are. Some restrictions on the
parameter mechanism would be needed to avoid circular references, but
in the best case, no restrictions should be given except that circular
references are not allowed.
     
Using these parameters in simulation/modeling is beneficial if it
controls the elaboration of the design. If the only reason is to
affect the parent's behavior, then ordinary OUT signals would be
enough for a simulator. But a synthesis tool could probably benefit
from this usage of parameters as well, since it would know about the
"staticness" of the signal.
     
 
Proposed Resolution
-------------------

GENERICs of mode OUT is one solution, but it is limited. With current
visibility rules, the value passed out can not be calculated by a
function declared in the ENTITY or architecture, for instance.  Forcing
OUT generics to be placed before input generics in the code could
reduce the possibility of circular references, but would prevent the
child to modify the parameter in response to different values of input
parameters. This is not really a good solution.
     
Another solution is a kind of ATTRIBUTES placed on the ENTITY or
ARCHITECTURE.  Their values can be calculated and assigned during
elaboration of the child, using functions/constants declared in the
child and parameters passed into the entity.  Current visibility rules
allows instance labels to be used in the declarative part of the
parent, which could allow the attribute to be used there, similar to:

     CONSTANT numberOfCycles:
     NATURAL := i1.ent(arc)'NoOfCycles;
     
The drawback of this attribute mechanism (or similar), is that
circular references are difficult to prevent.
     
 
VASG-ISAC Analysis & Rationale
------------------------------

The VHDL-200x SC received the same feature request and referred it to
the VHDL-200x Modeling and Productivity group.  See the archives for
the vhdl-200x-sc list ("New Issue" thread, 23-24 April 2004) and the
vhdl-200x-mp list ("New Issue" and "Out-mode generics" threads, 24-30
April 2004).


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

No change.


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

To be determined by the VHDL-200x Modeling and Productivity group.


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