Expressions In Sensitivity List
Recommendation: Reject
Proposal Information
- Who Updates:
- Date Last Updated
- Priority:
- Complexity:
- Focus: Performance
Requirement Summary & Rationale
Proposal here
Arguments For
Add your signature here to indicate your support for the proposal
Arguments Against
Add your signature here to indicate your do not support for the proposal
From Jan 31, 2013 meeting
- Isn't a compiler smart enough to extract this anyway - especially if it can handle process (all).
- Recommend reject
--
DavidKoontz - 2013-02-01
It's worth asking how you get a performance increase from doing this. A process waiting on an event executes at some deterministic address (after BEGIN). Expressions in sensitivity lists would quit if the expression doesn't evaluate true. Interestingly enough the example show in the proposal has no difference in execution time (performance). You could imagine there might be some case of economy of scale by creating implicit signals for the results of expressions, that limited by the scope and visibility of any signals used (such as a perfectly flat clock tree) in those expressions, the amount of economy of scale doing so is limited. This would be implementation dependent and wouldn't be something the standard should support directly.
CPU performance increases in higher, balanced bandwidths and larger caches since the proposal in 2003 would likely dwarf any performance increases do this and likely other proposed performance changes.
General Comments
Email Reflector Comments
From: Peter Flake (Thu Jan 03 2013 - 09:48:21 PST)
Perf 2: Expressions in the sensitivity list
The question here is: when is the expression evaluated? If it is evaluated at the update phase, then some of the signals may not yet have been updated. If it is at the evaluation phase, then it is just like running a process. The only worthwhile case is a posedge or negedge on a scalar signal, which can be correctly evaluated at the update phase.
From: Brent Hayhoe (Mon Jan 21 2013 - 13:09:26 PST)
PERF-02 Expressions in the sensitivity list
I have a feeling I have seen this suggested before, but cannot remember where or when.
The suggestion then was to add predefined attributes that return a toggling signal in a similar manner to 'TRANSACTION. The suggestions were 'EDGE, 'RISING_EDGE and 'FALLING_EDGE.
Whilst these sound sensible, they would have to be defined on a type by type or package basis in order to actually define what change(s) constitute a particular edge.
Topic revision: r4 - 2020-02-17 - 15:34:29 -
JimLewis