VHDL Issue Number: 2028 Language_Version: VHDL-2002 Classification: Language Definition Problem Summary: Clarify simulation cycle Relevant_LRM_Sections: Related_Issues: Key_Words_and_Phrases: Authors_Name: paul (mencini ?) Authors_Phone_Number: Authors_Fax_Number: Authors_Email_Address: Authors_Affiliation: Authors_Address1: Authors_Address2: Authors_Address3: Current Status: VASG-Approved Superseded By: ------------------------ Date Submitted: 29 May 2003 Date Analyzed: 20-Oct-04 Author of Analysis: Peter Ashenden Revision Number: 4 Date Last Revised: 03 February 2006 Description of Problem ---------------------- I've uncovered a new issue related to the simulation cycle, which I think entails no semantic changes to the language, but would simplify and clarify the LRM. I want to "read it into the record," and if FT wants to take it up, we can easily implement it in the next round of LRM changes. The Issue: The first, second and third steps of initialization and steps b and c of the simulation cycle discuss the updating of signals. Paraphrasing, the steps are, and in order: * Update explicit signals * Update implicit signals Note 4 (which contains a typo--it says the second and third steps of initialization) discusses the long-known issue that, strictly speaking, the LRM is inconsistent in this area. The problem can be illustrated by considering an in mode port S1, which is associated with S2'Stable. S1 (an explicit signal) cannot be updated until S2'Stable is updated, which in turn cannot be updated until S2 is updated. However, all three must be updated in the same simulation cycle when S2 has an event on it. This need is inconsistent with the step ordering described above. In either 93 or 02 (I can't remember which) we made explicit the long-implicit notion of nets. However, we failed to carry this notion into initialization and the simulation cycle. I propose that we complete that effort. To do so, we need to 1. define the notion of an "active net," which is quite simply, any net with an active signal in it. 2. and, we can replace the two steps described above with (for initialization): * Update every net and (for the simulation cycle): * Update every active net 3. eliminate Note 4. Note from Steve Bailey: This seems reasonable to me. But, I'm not absolutely sure as the synopsis leaves some details out. A net is a collection of drivers, signals, conversion functions and resolution functions that connect different processes. It seems to me that there are two steps: 1. Drivers are updated. (The existing "each active explicit signal is updated" step.) 2. Nets are updated. But, your synopsis only mentions the 2nd step. It seems to me that step 1 is important as without any driver updating (maturing of events) then there would be no activity so it must be covered. Proposed Resolution ------------------- TBD VASG-ISAC Analysis & Rationale ------------------------------ The submitter identifies a lack of completeness in the specification of signal update in the LRM and suggests how the LRM may be improved to make it more complete. However, the specfication of signal update and model execution is made more complex with the introduction of the VHPI. The main change to signal update results from a need to accommodate deposit and force operations, including deposit/propagate and force/propagate, on drivers and signals. The idea of the operations are: - A deposit simply updates the value. It is done immediately. - A deposit/propagate updates the value and causes update of the net. The operation is done during the signal update phase of the next simulation cycle. - A force causes the value to be set to a given value and not be changed by subsequent updates. It is done immediately. - A force/propagate causes a force to occur and update of the net. The operation is done during the signal update phase of the next simulation cycle. - A release stops the effect of a force. The value is subsequently updated normally. In the case of a driver, it is the current value of the driver that is updated. In the case of a signal other than a port of mode out or inout, it is the effective value that is update. For a port of mode out, it is the driving value that is updated. For a port of mode inout, each of the effective or driving values can be updated. Previously, the current value of a driver was just the value of the first transaction on its projected output waveform. In order to accommodate depositing and forcing a driver, the LRM is revised to specify that the kernel has a variable for the current value of a driver. If a transaction matures and the variable is not forced, the new maturing transaction value is used to update the variable. The driver is active when it gets a new value either from a maturing transaction or from a deposit or force operation. In the case of signals, previously, the kernel just had a variable for the current value, and that was updated with the effective value after the effective value was computed. To deal with deposit and force operations, the LRM now says that the kernel has two variables for a signal: one for the driving value and one for the current value. A signal is active if any of its sources are active or if a deposit/propagate or force/propagate has to be done on the signal. In that case, the driving and effective values for the signal are calculated (taking into account forcing and depositing values), then the driving-value variable is updated with the calculated driving value and the current-value variable is updated with the effective value variable. The remaining revision is that signal update for signals on a net is specified to occur only when drivers or signals on the net are active. (Compare with previously, where update is specified to occur on every simulation cycle.) This accommodates triggering callbacks at relevant times for drivers and signals on the net. In the previous LRM, it was not clear whether signals referenced in a guard expression were part of a net that included the GUARD signal. In the revised LRM, a note is included to say that they are, since activity on drivers of the referenced signals causes the GUARD signal to be active and hence the net containing GUARD to be active. Since net update is triggered by driver activity, when the referenced signal's driver is active, we want update to propagate via GUARD signals to nets that include the GUARD signals. Returning now to the substance of this IR, the proposed revised text for the initialization phase is: c) The driving value and the effective value of each explicitly declared signal are computed, and the variables representing the driving value and current value of the signal are set to the driving value and effective value, respectively. The current value is assumed to have been the value of the signal for an infinite length of time prior to the start of simulation. If a force or deposit was scheduled for any driver or signal, the force or deposit is no longer scheduled for the driver or signal. d) The value of each implicit signal of the form S'Stable(T) or S'Quiet(T) is set to True. The value of each implicit signal of the form S'Delayed(T) is set to the initial value of its prefix, S. e) The value of each implicit GUARD signal is set to the result of evaluating the corresponding guard expression. and for the simulation cycle: c) Each active driver in the model is updated, then each active explicit signal in the model is updated. (Events may occur on signals as a result.) If a force or deposit was scheduled for any driver or signal, the force or deposit is no longer scheduled for driver or signal. d) Each implicit signal in the model is updated. (Events may occur on signals as a result.) and for the note: 3 - Steps c), d) and e) of the initialization phase and steps c) and d) of the simulation cycle may occur in interleaved fashion. This interleaving may occur because the implicit signal GUARD may be used as the prefix of another implicit signal; moreover, implicit signals may be associated as actuals with explicit signals, making the value of an explicit signal a function of an implicit signal. The revised step c) of the simulation cycle addresses the issue raised by Steve in the IR, that drivers must be updated first. However, it still leaves the interleaving of update of signals unspecified. The explicitly specify interleaving of signal update, we need to deal with differences between initialization and the simulation cycle. During initialization, drivers are first initialized, then explicit and implicit signals are updated based on the partial order of dependency. During a simulation cycle, active drivers are first updated, then active signals are updated based on the partial order of dependency. The dependence relation is defined in 12.6.3 for implicit signals depending on other signals. However, it would need to be extended for formal ports dependent on associated actuals that are implicit signals. Taking this into account, we could refine the specification along the lines suggested by the IR author. Steps c), d) and e) of the initialization phase could be replaced by c) The signals in the model are updated as follows in an order such that if a given signal R depends on the current value of another signal S, then the current value of S is updated prior to the updating of the current value of R. -- Each explicitly declared signal is updated. The current value is assumed to have been the value of the signal for an infinite length of time prior to the start of simulation. -- The value of each implicit signal of the form S'Stable(T) or S'Quiet(T) is set to True. The value of each implicit signal of the form S'Delayed(T) is set to the initial value of its prefix, S. -- The value of each implicit GUARD signal is set to the result of evaluating the corresponding guard expression. Then, if a force or deposit was scheduled for any driver or signal, the force or deposit is no longer scheduled for the driver or signal. Steps c) and d) of the simulation cycle could be replaced by c) Each active driver in the model is updated. If a force or deposit was scheduled for any driver, the force or deposit is no longer scheduled for the driver. d) Each signal on each net that includes active drivers is updated in an order that is consistent with the dependency relation between signals (see 12.6.3). (Events may occur on signals as a result.) If a force or deposit was scheduled for any signal, the force or deposit is no longer scheduled for the signal. The note could then be deleted. VASG-ISAC Recommendation for IEEE Std 1076-2002 ----------------------------------------------- No change. VASG-ISAC Recommendation for Future Revisions --------------------------------------------- Incorporate the changes described in the analysis. -------------END OF IR----------------