TopLCS2016_I18 < P1076

P1076 Web>Vhdl2019CollectedRequirements>ProcessAllIncudesAllReachableSubprograms>TopLCS2016_I18 (2017-03-16, BrentHahoe) (raw view)EditAttach
---+ Language Change Specification for
---+ Process(all) Should Not Include Signals in Subprograms

<table border="1" cellpadding="0" cellspacing="0" id="table1" rules="all"> <tbody> <tr> <td bgcolor="#ffffff" valign="top"> *LCS Number:* </td> <td bgcolor="#ffffff" valign="top">LCS-2016-I18</td> </tr> <tr> <td bgcolor="#edf4f9" valign="top"> *Version:* </td> <td bgcolor="#edf4f9" valign="top">1</td> </tr> <tr> <td bgcolor="#ffffff" valign="top"> *Date:* </td> <td bgcolor="#ffffff" valign="top">05-Feb-2017</td> </tr> <tr> <td bgcolor="#edf4f9" valign="top"> *Status:* </td> <td bgcolor="#edf4f9" valign="top"> </td> </tr> <tr> <td bgcolor="#ffffff" valign="top"> *Author:* </td> <td bgcolor="#ffffff" valign="top">Rob Gaddi</td> </tr> <tr> <td bgcolor="#edf4f9" valign="top"> *Email:* </td> <td bgcolor="#edf4f9" valign="top"> [[http://www.eda-twiki.org/cgi-bin/view.cgi/Main/RobGaddi][Main.RobGaddi - 2017-02-06]]</td> </tr> <tr> <td bgcolor="#ffffff" valign="top"> *Source Doc:* </td> <td bgcolor="#ffffff" valign="top"> ProcessAllIncudesAllReachableSubprograms </td> </tr> <tr> <td bgcolor="#edf4f9" valign="top"> *Summary:* </td> <td bgcolor="#edf4f9" valign="top">Remove the requirement for the (all) sensitivity list to be able to analyze subprograms for implicit signals.<br /><br /></td> </tr> </tbody> </table>
---++ Voting Results: Cast your votes here

 Yes:
   1 %USERSIG{RobGaddi - 2017-02-06}% - ver 1
   1 %USERSIG{MartinThompson - 2017-02-06}% - ver 1 <p> </p>
 No:
   1 %USERSIG{PatrickLehmann - 2017-03-07}% - ver 1
   1 <p>%USERSIG{KevinJennings - 2017-03-12}% - Ver 1. This is a change to 'fix' a non-existent problem</p>
 Abstain:
   1 %USERSIG{JimLewis - 2017-03-06}% - not convinced this is a necessary change. <p> </p> <p> </p>

<sticky>
---++ Details of Language Change:

 Key:
   * Existing LRM text is shown in BLACK font
   * Additional LRM text is shown in %RED%<u>RED and underlined</u>%ENDCOLOR%
   * Deleted LRM text is shown in %RED%<del>RED with strike-through</del>%ENDCOLOR% <p> </p>
---+++ Section 11.3
---++++ Bottom page 171

 It is %RED%<del>an error</del><u>erroneous</u>%ENDCOLOR% 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 %RED%<del>an error</del><u>erroneous</u>%ENDCOLOR% 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</sticky>

 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.

 -- %BUBBLESIG{TristanGingold - 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:

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

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

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?

-- %BUBBLESIG{RobGaddi - 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.

-- %BUBBLESIG{PatrickLehmann - 2017-03-07}%

%COMMENT%
Topic revision: r10 - 2017-03-16 - 11:00:42 - BrentHahoe
P1076