The Sensitivity List for Process(all) Should Not Include Signals in All Reachable Subprograms

Proposal Details

  • Who Updates:main.CliffordWalinsky
  • Date Proposed:2013-11-12
  • Date Last Updated:2013-11-12
  • Bugzilla Reference: 287

Current Situation

1076-2008, section 11.3 "Process statement" describes rules for inferring the set of signals that a process(all) concurrent process is sensitive to. The section also describes situations where a design is in error for referring to signals outside the static scope of the design unit containing the process(all) block:

"It is an error if a process statement with the reserved word all as its process sensitivity list is the parent of a subprogram declared in a design unit other than that containing the process statement, and the subprogram reads an explicitly declared signal that is not a formal signal parameter or member of a formal signal parameter of the subprogram or of any of its parents. Similarly, it is an error if such a subprogram reads an implicit signal whose explicit ancestor is not a formal signal parameter or member of a formal parameter of the subprogram or of any of its parents."

This error is quite difficult for a compiler to detect, since it requires analysis of package bodies, which may not be in existence at the time a process(all) block is compiled. Simulation-time detection of this error will be incomplete, since a package subprogram reachable from a process(all) block that references a signal may not be called; even if not called, the design is deemed to be erroneous, because the process(all) block will not be sensitive to the subprogram's signal.

Requirement

We propose that, since determination of the error situation for subprograms outside the semantic scope of the design unit containing a process(all) block requires extensive analysis across design units, the requirement should be dropped from the LRM. That is, signals of subprograms called from a process(all) block will be added to the block's sensitivity list only if the subprograms reside within the same design unit as the process(all) block.

Implementation details

Compilers will need to incorporate analysis of subprograms that reside within the same design unit as process(all) blocks to determine the set of signals that the subprograms reference. Analysis across design units will not be necessary, however.

Code Examples

Use Cases

Arguments FOR

It's not clear that compiler vendors currently detect the error situation described in the LRM. Removal of this requirement would have little actual impact, but would bring compilers closer to conformance. The requirement itself violates the implicit requirement for opacity of package bodies. Because of the LRM's requirement, the erroneous nature of a design depends crucially on how subprograms within package bodies are written. Sensitivity to signals on the part of subprograms should be made explicit by including the signals within subprogram parameter lists.

Arguments AGAINST

General Comments

-- JimLewis - 2014-11-11 Don't go too far though. You seem to have left off signals that are inputs on the subprogram interface. We have a proposal for implicitly mapping ports and parameters. I would want these on the process sensitivity list. I am not sure how important this is though as my planned use of this feature is in processes with wait statements.

Supporters

Add your signature here to indicate your support for the proposal

Topic revision: r4 - 2020-02-17 - 15:34:36 - JimLewis
 
Copyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback