Language Change Specification for

Process(all) Should Not Include Signals in Subprograms

LCS Number:	LCS-2016-I18
Version:	1
Date:	05-Feb-2017
Status:
Author:	Rob Gaddi
Email:	Main.RobGaddi - 2017-02-06
Source Doc:	ProcessAllIncudesAllReachableSubprograms
Summary:	Remove the requirement for the (all) sensitivity list to be able to analyze subprograms for implicit signals.

Voting Results: Cast your votes here

Yes:

1. Rob Gaddi - 2017-02-06 - ver 1
2. Martin Thompson - 2017-02-06 - ver 1
   No:
3. Patrick Lehmann - 2017-03-07 - ver 1

4. Kevin Jennings - 2017-03-12 - Ver 1. This is a change to 'fix' a non-existent problem

   Abstain:
5. Jim Lewis - 2017-03-06 - not convinced this is a necessary change.

Details of Language Change:

Key:

• Existing LRM text is shown in BLACK font
• Additional LRM text is shown in RED and underlined
• Deleted LRM text is shown in RED with strike-through

Section 11.3

Bottom page 171

It is an errorerroneous 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 errorerroneous 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.

Comments

I think this is a bad idea. Switching from error state to erroneous state is not a good idea without a strong reason, as it makes the tool weaker and may create portability issues. An elaborator knows the whole design, so it is able to detect such a violation.

-- Tristan Gingold - 2017-02-06

Tristan, the elaborator knows the whole design, but is that the type of analysis that's currently being performed, or would that be an additional ask for implementors? You'd have to flag something like:

package pkg:
  function pkg_function:
    implicit_references: [signal: pkg_signal, ...]

entity foo:
  architecture bar:
    process state_machine:
      uses: [pkg.pkg_function, ...]
      sensitivity_all : true

And handle all that at elaboration time just to throw an error that says you would have liked to catch that conflict at compile time, but you didn't have all the information yet. I know it's technically possible, but, at least in engines you know about, is any of that infrastructure in place yet?

-- Rob Gaddi - 2017-02-08

I think the original proposal is outdated. There is no indication from other vendors that they can't generate this exact error. Furthermore, some vendors and developers indicate that they solved the problem.

-- Patrick Lehmann - 2017-03-07