Here are the attached files. Chuck -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. VHDL Issue Number: 2122 Language_Version VHDL-2002 Classification Language Modeling Enhancement or Deficiency Summary Protected method has implied object parameter? Relevant_LRM_Sections 3.5.1 Protected type declarations 2.4.2 Signatures Related_Issues Key_Words_and_Phrases protected type method signature overload resolution Authors_Name James Unterburger Authors_Phone_Number 503-685-0860 Authors_Fax_Number Authors_Email_Address jamesu@model.com Authors_Affiliation Mentor Graphics Authors_Address1 8005 SW Boeckman Rd. Authors_Address2 Wilsonville, OR 97070 Authors_Address3 Current Status: Submitted Superseded By: ------------------------ Date Submitted: 7 September 2007 Date Analyzed: Author of Analysis: Revision Number: 0 Date Last Revised: Description of Problem ---------------------- In discussing methods, the text states "In addition to the (implied) object of the protected type operated on by the subprogram, additional parameters may be explicitly specified in the formal parameter list of the subprogram declaration of the subprogram". The word "additional" suggests that the protected type object to be operated on is somehow an implied formal to the subprogram. Also, the fact that nested protected types are legal suggests that there are actually N implied objects being operated on where N is the nesting level of where the method is. Do the implied objects/formals come into play for overloaded subprogram resolution? Do their (protected) type names appear in the signature of the subprogram? In the following example, which "foo" is called when elaborating the "v2" object? package pkg is function foo(x : string :: "PKG") return string; type prot is protected function foo(x : string := "PROT") return string; end protected; end; package body pkg is type prot is protected body constant v : string(1 to 5) := "Hello"; function foo(x : string := "PROT") return string is begin return v & x; end; variable v2 : string(1 to 5) := foo; variable ccc : string(1 to 10) := foo'path_name; end protected body; function foo(x : string := "PKG") return string is begin return "PKG " & x; end; end; Proposed Resolution ------------------- VASG-ISAC Analysis & Rationale ------------------------------ TBD VASG-ISAC Recommendation for IEEE Std 1076-2002 ----------------------------------------------- TBD VASG-ISAC Recommendation for Future Revisions --------------------------------------------- TBD 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: Submitted Superseded By: ------------------------ Date Submitted: 27 September 2007 Date Analyzed: Author of Analysis: Revision Number: 0 Date Last Revised: 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 ------------------------------ TBD VASG-ISAC Recommendation for IEEE Std 1076-2002 ----------------------------------------------- TBD VASG-ISAC Recommendation for Future Revisions --------------------------------------------- TBD 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: Submitted Superseded By: ------------------------ Date Submitted: 27 September 2007 Date Analyzed: Author of Analysis: Revision Number: 0 Date Last Revised: 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 ------------------------------ TBD VASG-ISAC Recommendation for IEEE Std 1076-2002 ----------------------------------------------- TBD VASG-ISAC Recommendation for Future Revisions --------------------------------------------- TBDReceived on Fri Oct 5 11:11:44 2007
This archive was generated by hypermail 2.1.8 : Fri Oct 05 2007 - 11:11:45 PDT