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: VASG-Approved Superseded By: ------------------------ Date Submitted: 27 September 2007 Date Analyzed: 15 March 2008 Author of Analysis: Peter Ashenden Revision Number: 3 Date Last Revised: 23 May 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. 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. With regard to execution of vhpiCbResume callbacks, the VHPI Task Force recommended that the callback 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. In that case, the corresponding re-suspension is also obviated. The rationale for the vhpiCbResume callback, as explained by members of the VHPI Task Force, is to support debugging applications. The callback is not intended to be used for foreign models, back annotation, or for affecting the behavior of a model. The vhpiCbResume callback allows a debugger to gain control immediately prior to evaluation of the condition in a wait statement. The debugger can then examine the state of the information model, step through evaluation of the condition, and so on. While optimizations that obviate resumption inhibit full observability of wait statement execution, this is seen as an acceptable compromize between performance and utility. An analogy is drawn with software debuggers, which work with both unoptimized and optimized code and are found to be useful in both scenarios. A similar case, addressing optimization, already exists in the specification of the vhpiCbStmt callback. 19.2.3.1 of 1076c-2007 contains the following: A tool may perform optimizations that render an object representing a statement inaccessible. It is an error if the handle in the obj member of the registration callback data structure refers to such an object. A tool may perform optimizations that alter the order of execution of statements in a statement part. A VHPI program that depends on the order of execution of vhpiStmt callbacks associated with statements whose execution order is so altered is erroneous. Given this precedent, allowing the triggering of vhpiCbResume and vhpiCbSuspend callbacks to be obviated by optimizations is consistent. Statements similar to that quoted above from 19.2.3.1 should be added to 19.2.3.2 and 19.2.3.3. 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. To the end of 19.2.3.2, add the following paragraph: An implementation may optimize execution of a wait statement in such a way as to obviate some or all resumptions and repeated suspensions 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 VHPI program that depends on triggering of vhpiCbResume callbacks for resumptions so obviated is erroneous. To the end of 19.2.3.3, add the following paragraph: An implementation may optimize execution of a wait statement in such a way as to obviate some or all resumptions and repeated suspensions 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 VHPI program that depends on triggering of vhpiCbSuspend callbacks for repeated suspensions so obviated is erroneous.