Next meeting: Thursday, March 20, 2008, 8 pm Pacific Daylight time. (Friday, March 21, 2008, 3 am GMT) Telecon info (same as always) US 800-637-5822 Other +1 647-723-3937 Access Code 6850821 1. Open Bugzilla issues: 192 NEW Subtype problems for out-mode signal parameters 193 NEW Sensitivity of concurrent procedure call with out-mode si... 206 REOP What exactly does FINISH do? Can it be used? 207 NEW Input values for STOP Note: we have tentatively agreed to prohibit reading of OUT mode signal parameters as a solution to 192 and 193. We have agreed to defer discussion of 206 and 207 until after LRM approval. 2. New ISAC Issues: None; 3. Open ISAC Issues: 2123 Analyzed Peter Process resumption and callbacks 2124 Analyzed Peter Ordering of process execution and callbacks 2126 Analyzed Chuck Concatenation ambiguity Please review these, if possible, before the meeting. We will try to resolve them at the meeting. I have made very minor edits to 2123 and 2124. 4. Migration of pre-2002 IRs to Bugzilla: Suspended until Accellera/IEEE process completed on current version of LRM. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. VHDL Issue Number: 2123 Language_Version IEEE Draft VHDL-2007 (VHDL + VHPI) Classification Language Definition Problem Summary Process resumption and callbacks Relevant_LRM_Sections 8.1, 12.6.2 Related_Issues Key_Words_and_Phrases process resumption, VHPI callback Authors_Name Peter Ashenden Authors_Phone_Number +61 8 7127 0078 Authors_Fax_Number Authors_Email_Address peter@ashenden.com.au Authors_Affiliation Authors_Address1 Authors_Address2 Authors_Address3 Current Status: analyzed Superseded By: ------------------------ Date Submitted: 27 September 2007 Date Analyzed: 15 March 2008 Author of Analysis: Peter Ashenden Revision Number: 1 Date Last Revised: 15 March 2008 Description of Problem ---------------------- The LRM is unclear about precisely when a process is said to resume. This affects when certain VHPI callbacks are triggered. At issue is whether a process that is suspended on a wait statement with an until clause is said to resume only when the condition is true, or whether is also resumes in order to test the condition. In 8.1, there is a paragraph: The suspended process can also resume as a result of an event occurring on any signal in the sensitivity set of the wait statement. If such an event occurs, the condition in the condition clause is evaluated. If the value of the condition is TRUE, the process will resume. If the value of the condition is FALSE, the process will resuspend. Such resuspension does not involve the recalculation of the timeout interval. This is unclear. On the one hand, it specifies that when an event occurs, the condition is evaluated, and if TRUE, the process resumes. On the other hand, it says that if the condition is FALSE, the process resuspends. For it to resuspend, it presumably must have unsuspendend, namely, resumed. So this could be interpreted as saying the process resumes in order to test the condition. In 12.6.2, there is the text: ... The occurrence of an event will cause the resumption and subsequent execution of certain processes during the simulation cycle in which the event occurs, if and only if those processes are currently sensitive to the signal on which the event has occurred. This could be interpreted as saying the processes resume upon events, regardless of any conditions in wait statements being true or false. That would be consistent with the second interpretation of the quoted paragraph from 8.1. In previous versions of VHDL, the distinction between the two interpretations was not apparent. An implementation could optimize evaluation of conditions in wait statements to avoid a full process resumption. However, in 1076c later, the difference is exposed. In 12.6.4.2 of 1076c, step a) substep 3) specifies: For each nonpostponed process P that has resumed in the current simulation cycle, each registered and enabled vhpiCbResume callback associated with P is executed. Thus, depending on whether a process with a false condition is interpreted as having resumed or not, the callback will or will not be executed. Proposed Resolution ------------------- It is not clear from the LRM which of the two interpretations is correct. Rather, is a matter of requirements analysis. The VHPI Task Force needs to consider the issue and recommend which interpretation is preferred. Based on their recommendation, the quoted sections can be revised to clarify the intent. VASG-ISAC Analysis & Rationale ------------------------------ The issue presented in this report originated in the Accellera VHDL-TC LRM-SC as part of issue #150 (see https://bugzilla.mentor.com/show_bug.cgi?id=150). It was not clear which of the two possible interpretations was correct or preferred. Rather, it was seen as a matter for requirements analysis, and so the issue was forwarded to the VHPI Task Force for advice. Their recommendation, together with some clarifying correspondence, is attached to the ISAC email at http://www.eda.org/isac/hm/0482.html. In summary, the VHPI Task Force recommended that a process be considered to resume from a wait statement when an event occurs on any of the signals in the sensitivity set of the wait statement. If the wait statement has a condition clause, the condition is evaluated. If the condition is false, the process suspends again, and will resume again on a subsequent event on any signal in the sensitivity set. With regard to execution of vhpiCbResume callbacks, the VHPI Task Force recommended that the call back be triggered upon process resumption as described in the preceding paragraph, with the caveat that an implementation be permitted to optimize evaluation of the wait statement's condition to obviate resumption when the condition would be false. The VHPI's recommendation was initially expressed in terms of the LRM remaining ambiguous as to whether a vhpiCbResume callback be triggered in the case of a wait condition evaluating to false. However, the ISAC prefers not to include ambiguous specifications in the LRM, as they can cause confusion among implementers and users, resulting in subsequent requests for interpretation. The preferred approach, where variation among implementations is permissible, is to specify the bounds of permissible variation explicitly. Following this approach, the ISAC prefers to revise the paragraph in 8.1 to clarify that a process is said to resume upon an event on any signal in the sensitivity set. If the wait statement includes a condition clause, the condition is evaluated upon resumption of the process, and if the result is FALSE, the process suspends again. To this is added a statement that an implementation is permitted to optimize execution of a wait statement in such a way as to obviate some or all resumptions of a process provided that, when an event occurs on any signal in the sensitivity set and that event would result in the condition evaluating to TRUE, the process does resume. A note should be included in 8.1 indicating that omission of process resumptions, as permitted, affects triggering of vhpiCbResume and vhpiCbSuspend callbacks. VASG-ISAC Recommendation for IEEE Std 1076c-2007 ----------------------------------------------- Interpret the standard as though the Recommendation for Future Revisions were incorporated. VASG-ISAC Recommendation for Future Revisions --------------------------------------------- In 8.1, change the paragraph The suspended process can also resume as a result of an event occurring on any signal in the sensitivity set of the wait statement. If such an event occurs, the condition in the condition clause is evaluated. If the value of the condition is TRUE, the process will resume. If the value of the condition is FALSE, the process will resuspend. Such resuspension does not involve the recalculation of the timeout interval. to the following: The suspended process also resumes as a result of an event occurring on any signal in the sensitivity set of the wait statement. If such an event occurs, the condition in the condition clause is evaluated. If the value of the condition is FALSE, the process will suspend again. Such repeated suspension does not involve the recalculation of the timeout interval. An implementation may optimize execution of a wait statement in such a way as to obviate some or all resumptions of the suspended process due to events on signals in the sensitivity set provided that, when an event occurs on any signal in the sensitivity set and that event would result in the condition in the condition clause evaluating to TRUE, the process does resume. In 8.1, add the following note: If an implementation optimizes execution of a wait statement by obviating certain process resumptions, the corresponding trigger events of vhpiCbResume and vhpiCbSuspend callbacks associated with the process do not occur. VHDL Issue Number: 2124 Language_Version IEEE Draft VHDL-2007 (VHDL + VHPI) Classification Language Definition Problem Summary Ordering of process execution and callbacks Relevant_LRM_Sections 12.6.4.2 Related_Issues Key_Words_and_Phrases process resumption, VHPI callback Authors_Name Peter Ashenden Authors_Phone_Number +61 8 7127 0078 Authors_Fax_Number Authors_Email_Address peter@ashenden.com.au Authors_Affiliation Authors_Address1 Authors_Address2 Authors_Address3 Current Status: Analyzed Superseded By: ------------------------ Date Submitted: 27 September 2007 Date Analyzed: 15 March 2008 Author of Analysis: Peter Ashenden Revision Number: 1 Date Last Revised: 15 March 2008 Description of Problem ---------------------- The LRM specifies an ordering of steps in the simulation cycle that may be overly restrictive. In 1076-2002, 12.6.4, process execution in the simulation cycle was specified as: d) For each process, P, if P is currently sensitive to a signal, S, and if an event has occurred on S in this simulation cycle, then P resumes. e) Each nonpostponed process that has resumed in the current simulation cycle is executed until it suspends. This allows interleaved execution of the resumed processes. In 1076c-2007, this was changed to incorporate execution of callbacks. The revised text in 12.6.4.2 is: 2) For each process, P, if P is currently sensitive to a signal, S, and if an event has occurred on S in this simulation cycle, then P resumes. 3) For each nonpostponed process P that has resumed in the current simulation cycle, each registered and enabled vhpiCbResume callback associated with P is executed. 4) Each nonpostponed process that has resumed in the current simulation cycle is executed until it suspends, and each registered and enabled vhpiCbTimeOut and vhpiCbRepTimeOut callback whose triggering condition is met is executed. 5) For each nonpostponed process P that has resumed in the current simulation cycle, each registered and enabled vhpiCbSuspend callback associated with P is executed. This specifies that all of the vhpiCbResume callbacks are executed, then the resumed processes and timeout callbacks are executed, then the vhpiCbSuspend callbacks are executed. The division into three steps constrains the available parallelism in a way that may not have been intended. Moreover, it may prevent certain optimizations of the way in which processes and callbacks are executed. An alternative and less constraining approach would be to allow interleaving of process and callback execution, provided, for each process that has resumed, any associated vhpiCbResume callback is executed before the process is executed and any associated vhpiCbSuspend callback is executed after the process suspends. Apart from the difference in potential parallelism between these two approaches, the difference may be exposed to the callback routines. As the LRM currently stands, the resumption callbacks are guaranteed that no processes or suspension callbacks have started execution. Similarly, the suspension callbacks are guaranteed that all resumption callbacks have completed and all processes have suspended. A VHPI program may be written in a way that depends on these assumptions. Should the ordering be relaxed, the assumptions would no longer hold. Proposed Resolution ------------------- Input is sought from the VHPI task force whether the relaxed ordering is permissible or desirable. If the VHPI task force recommends adoption of the relaxed ordering, the ISAC can revise the LRM to implement that intent. VASG-ISAC Analysis & Rationale ------------------------------ The issue presented in this report originated in the Accellera VHDL-TC LRM-SC as part of issue #150 (see https://bugzilla.mentor.com/show_bug.cgi?id=150). It was not clear whether the strict ordering implied by the current specification was intended, and so the issue was forwarded to the VHPI Task Force for advice. Their recommendation, together with some clarifying correspondence, is attached to the ISAC email at http://www.eda.org/isac/hm/0482.html. The recommendation is that the LRM be revised to allow the relaxed ordering. The relative ordering of processes and resume/suspend callbacks is specified in two places. First, in initialization (12.6.4.1 of D4.0), the relevant steps are: i) Each nonpostponed process in the model is executed until it suspends. Each registered and enabled vhpiCbSuspend callback associated with a nonpostponed process is executed. ... m) Each postponed process in the model is executed until it suspends. n) Each registered and enabled vhpiCbSuspend callback associated with a postponed process is executed. These steps can be revised as follows: i) For each nonpostponed process P in the model, the following actions occur in the indicated order: 1) The process executes until it suspends. 2) Each registered and enabled vhpiCbSuspend callback associated with P is executed. ... m) For each postponed process P in the model, the following actions occur in the indicated order: 1) The process executes until it suspends. 2) Each registered and enabled vhpiCbSuspend callback associated with P is executed. n) [old step o) renumbered] Second, in the simulation cycle (12.6.4.2 of D4.0), the relevant steps are: h) 2) For each process, P, if P is currently sensitive to a signal, S, and if an event has occurred on S in this simulation cycle, then P resumes. 3) For each nonpostponed process P that has resumed in the current simulation cycle, each registered and enabled vhpiCbResume callback associated with P is executed. 4) Each nonpostponed process that has resumed in the current simulation cycle is executed until it suspends, and each registered and enabled vhpiCbTimeOut and vhpiCbRepTimeOut callback whose triggering condition is met is executed. 5) For each nonpostponed process P that has resumed in the current simulation cycle, each registered and enabled vhpiCbSuspend callback associated with P is executed. Substeps 3) to 5) can be revised as follows: h) 3) For each nonpostponed process P that has resumed in the current simulation cycle, the following actions occur in the indicated order: -- Each registered and enabled vhpiCbResume callback associated with P is executed. -- The process executes until it suspends. -- Each registered and enabled vhpiCbSuspend callback associated with P is executed. 4) Each registered and enabled vhpiCbTimeOut and vhpiCbRepTimeOut callback whose triggering condition is met is executed. 5) [old step 6) renumbered] Further steps in the simulation cycle (12.6.4.2 of D4.0) for postponed processes are: j) 4) For each postponed process P, if P has resumed but has not been executed since its last resumption, then each registered and enabled vhpiCbResume callback associated with P is executed. 5) Each postponed process that has resumed but has not been executed since its last resumption is executed until it suspends. 6) For each postponed process P, if P has executed in the previous step, then each registered and enabled vhpiCbSuspend callback associated with P is executed. These steps can be revised as follows: j) 4) For each postponed process P, if P has resumed but has not been executed since its last resumption, the following actions occur in the indicated order: -- Each registered and enabled vhpiCbResume callback associated with P is executed. -- The process executes until it suspends. -- Each registered and enabled vhpiCbSuspend callback associated with P is executed. 5) [old step 7) renumbered] 6) [old step 8) renumbered] VASG-ISAC Recommendation for IEEE Std 1076-2002 ----------------------------------------------- Interpret the standard as though the Recommendation for Future Revisions were incorporated. VASG-ISAC Recommendation for Future Revisions --------------------------------------------- Revise 12.6.4.1 and 12.6.4.2 of P1076-2008/D4.0 as described in the preceding analysis.Received on Tue Mar 18 16:27:47 2008
This archive was generated by hypermail 2.1.8 : Tue Mar 18 2008 - 16:27:49 PDT