VHDL Issue Number: 1064 Classification: Language Definition Problem Language Version: VHDL-93 Summary: Passiveness of processes is not analysis-time computable. Related Issues: Supersedes 0077 (Andy Tsay) Relevant LRM Sections: 1.1.3, 9.2 Key Words and Phrases: Passive process, structure attribute Current Status: Analyzed 1076-1993 Disposition: N/A Disposition Rationale: N/A Superseded By: N/A ----------------------- Date Submitted: 1989/02/10 Author of Submission: Doug Dunlop Author's Affiliation: Intermetrics, Inc. Author's Post Address: 4733 Bethesda Ave #415 Bethesda, MD 20814 Author's Phone Number: (301) 657-3775 Author's Fax Number: Author's Net Address: dunlop@inmet.inmet.com ----------------------- Date Analyzed: 1994/07/27 Author of Analysis: Andy Tsay (Fintronic USA) Revision Number: $Revision: 1.6 $ Date Last Revised: $Date: 1995/05/15 21:26:37 $ Description of Problem ---------------------- The original analysis of the issue by Doug Dunlop is forwarded as follows. A process is legal in the statement part of an entity declaration only if the process is passive (LRM 1.1.3, LRM 9.2). This involves inspecting the bodies of subprograms called by the process which, in general, cannot be done at analysis time. Note also that passiveness of processes is used in the definition of the 'STRUCTURE attribute. Proposed Resolution ------------------- TBD VASG-ISAC Analysis & Rationale ------------------------------ The problem here is somewhat deeper than stated above. A passive process as presently defined need not be truly "passive" in the conventional sense of the term. Consider the following VHDL entity e is procedure p(signal s : out bit) is begin null; end p; begin process begin p(g); -- pass global resolved signal g to p wait; end process; end e; This process is a passive process with the present LRM wording, yet it has an associated driver. The value of this driver is given by the default rules for signal values. If S is a resolved signal, this value is passed as a source to the resolution function for S, and thus, in general, contributes to the value of the resolved signal. Towards the issue as presented in the original problem statement, is it necessary that passive processes be detectable at analysis time? While not essential, there are arguments in favor of making passive processes detectable at analysis time provided there is no loss in expressive power for the user. It is an implementation burden to identify passive processes at elaboration time. It seems undesirable to have to postpone, in general, the detection of the "non-passive process in entity" error until elaboration time. Finally, it would be appealing if there could be an intermediate-form attribute to identify passive processes; such an attribute would not be possible, in general, if passive processes were not analysis-time detectable. How could the definition of a passive process be modified so as to be more accurate and so that passive processes could be more easily detected? If the LRM 9.2 sentence A process statement is said to be a *passive process* if neither the process itself, nor any procedure of which the process is a parent, contains a signal assignment. had been written A process statement is said to be a *passive process* if it has no associated drivers (see Sections 2.1.1.2 and 9.2.1). both goals would be accomplished. A process meeting this revised definition of a passive process would be truly passive, i.e., would not affect in any way the simulation-time signal activity. This revised definition also makes the detection of a passive process a task that can always be performed at analysis time. The only difference between the two definitions of a passive process are rather pathological cases where INOUT or OUT mode signal parameters are not updated (either via signal assignment or subprogram call) within the subprogram (as in the above example). VASG-ISAC Recommendation for IEEE Std 1076-1993 ----------------------------------------------- Assume the slightly-modified definition of a passive process given above. Incorporate the revised definition in the LRM. VASG-ISAC Recommendation for Future Revisions --------------------------------------------- TBD ======================================================================== At the request of the 92 language design team we revisited this IR. The text above this point had originally been written and approved by the VASG in July, 1990. New VASG-ISAC Recommendation for Future Revisions ------------------------------------------------- There are two issues with the above proposal 1) It is not compile time calculable. 2) It defines a process that contains the stmt s(0 to -1) <= null; As passive, even though this does contain a "signal assignment" (although it is a stupid one). Instead, we decided to go with the original LRM approach which was to define passiveness as a function of whether process contains a signal assignment or a call to a procedure that contains one. The proposed rewording would look something like this: A passive process is a process that does not contain any signal assignments (including assignments made within procedures declared local to the process) and does not call a procedure with a signal parameter of mode out or inout. This wording is sufficient to determine if a process is passive during analysis because a procedure can only assign to either signal parameters of mode out or inout or to signals that are global to the procedure. The assignment to these "global" signals is only legal if the procedure is declared within a process. The paragraph of section 8.3.1 (just above the note): If a given procedure is declared by a declarative item that is not contained within a process statement, and a signal assignment statement appears in that procedure, then the target of the assignment statement must be a formal parameter of the given procedure or of a parent of that procedure, or an aggregate of such formal parameters.