VHDL PLI IR number: 01 Classification: Simulation modification of values VHDL PLI version: 0.1 Title: Immediate update of signal values Summary: Allow PLI to immediately change the value of a signal during a simulation cycle Related IRS: 02 Requestor Priority: Assigned Priority: Current Status: Open Date Submitted: 11/11/97 Key Words: simulation cycle, signal, driver Related sections in the LRM: 12.6 Author of Submission: Francoise Martinolle Author's Affiliation: Cadence Design Systems Author's Phone Number: [978] 446-6283 Author's Net Address: fm@cadence.com Date Assigned: 11/05/97 Description of Problem ---------------------- PLI should provide the ability to modify a signal value during the current simulation cycle. Rationale --------- Debuggers need the capability to update signal values during simulation. The update is often meant temporary and its effect meant to be immediately visible. A typical scenario could be that a user has detected that a signal value is wrong at a simulation cycle (the model does not perform the expected functionality), therefore he wants to set the signal to the correct value for this cycle. The user may want to change it before the cycle starts if he detected the error at this point or before the processes get executed. The user may want the processes that are sensitive to this signal to resume, or simply wants the signal value to be read as the effective value for any reference to that signal during process execution. Another possible scenario is that the signal with the wrong value is either a resolved signal or a port whose IN (resp. OUT) value is determined by a conversion of its actual (resp. formal) association. The signal value is computed from its contributors: drivers or sources. It should be possible for the user to set the signal to its correct value when the value is determined either during signal resolution or propagation phases. This value will get propagated to the connected ports or signals. Analysis --------- We recognize the following phases in a simulation cycle: 1. beginning of the cycle 2. signal updates and signal resolution 3. effective signal value propagation 4. process execution 5. postponed processes execution (if last delta cycle of a time slice) 6. end of cycle In the following the term signal refers to signals, ports and sub-program signal parameters. There are 3 value strengths: - weak This is just a normal simulation value; this value can be overwritten by other value updates either from PLI or from the VHDL simulator. - force for the current cycle only The signal is forced to this value for the current cycle. The value cannot be overwritten except by another force (force for the current cycle or force until release). Another force is an external force, made either through the user command line or through PLI. All external forces have the same priority, there is no way to determine where the force comes from. At the end of the current cycle this type of force degenerates to a weak value. That is, the value that was forced will still be in effect at the next cycle but will be a weak value allowing drivers or sources to overwrite it. - force until release; the signal value is frozen to this new value until the value is released. Any form of release (commandline, PLI) can release the signal value. A release will essentially release the lock, the value will not be forced anymore but will degenerates to a weak value that can be overwritten. It did not seem natural to restore the original value that the signal had before the force happened (which was the other proposed alternative). Notes: Some other simulators may use different terms such as lock, freeze, ----- and the definition of a force or release might be different from the one we propose. Both type of forces have equal strength and are stronger than a weak value. If multiple forces are applied to the same signal either at the same phase, at different phase of the same cycle or at different cycles, the later force wins. Each new force performs an implicit release of the previous force before applying the new value. This defines the resolution semantics when many updates of different strengths are applied concurrently or sequentially to the same signal during the same cycle. There are two types of situations for the immediate update of a signal value: 1. The user wants to deposit a value on the signal with no event creation. Description: ------------ The update just overwrites the effective value of the signal. No transaction, therefore no event is created therefore no propagation happens. This can occur during any phase, and the new value will be immediately deposited as the effective value. Only the force for this cycle mode is applicable. Any reference to the signal will evaluate to the new deposited value. The deposit does not trigger callbacks. Since the effective value has been changed by PLI, this might cause transactions posted for that signal to not create events. Portability: ------------ This is non portable: during process execution, the deposited value, will only be visible for the remaining processes. It also depends on how elaborators collapse or optimize connected signals. The deposited value is also visible to all signals of the alias ring of the modified signal. Collapsing or optimizations vary from simulator to simulator. However since this is to support debugging functionality, the user should be aware of the side effects or simulator behavior differences. Customer use: ------------- It seems that some users have asked for this functionality; even though a large majority have also asked for the other functionality described in the following paragraph. We recommend that the signal update value with no event be an optional feature of the PLI interface. 2. The user wants to update the value of the signal with explicit request for events to be created. Description: ------------ Can only occur at the beginning of the cycle. Only the force strength modes are applicable. The created event cannot be overwritten by the model. In a force for the current cycle only, the value degenerates to a weak value at the next cycle. In a force until release, the event is created once during the first cycle then the value holds as a forced value until it gets released. On the release, the value degenerates to a weak value that can be overwritten by the model. The reason for restricting it to the beginning of the cycle is only because it is a safe place to state that it is still time to create events. If we were going to allow it in other phases, we may have to repeat update and propagation, which would complicate the kernel task... On the immediate update, a new artificial transaction is created by the simulator kernel and an event is created if the new value is different from the previous value on this signal. As a consequence of the event, processes and callbacks will trigger in the current simulation cycle, the value is propagated in the model hierarchy and may cause events to be created for other signals. The signal new effective value becomes visible just before the process execution phase. Portability: ------------- Completely portable. Customer use: ------------- allows triggering of behavior when debugging in the current simulation delta cycle. With these 2 types of immediate update, PLI can change values of signals, ports or sub-program signal parameters. This includes GUARD signals. An immediate update of the drivers is not allowed. Driver values can only be changed for next cycle or future time. This is described in IR02. Direct update of implicit signals such as signal attributes is not permitted. In the second type of update with event creation, implicit signals such as signal attributes are updated in phase 2 as a result of the corresponding signals being updated, guarded signals assignments can be triggered as a result of the GUARD signal becoming true. In the following paragraphs, we describe the cases where the signal value can be immediately updated by PLI. Immediate updates change a signal's effective value, never a driving value. PLI can update the returned value of a resolution function or conversion function for a given signal during signal resolution or propagation phase. If the function is called during propagation, that value will be propagated down the hierarchy, but might be inconsistent with the higher ports or signals connected to the signal that is changed. PLI can update the signal effective value during any phase. This new effective value is visible during the process execution. If a PLI update with event is requested at the beginning of a cycle and the update changes the value of the signal, an event is created and processes sensitive to that signal will wake up in the current cycle. Propagation of that signal update may cause other events. The new signal value becomes visible just before processes execute. Special callback reasons will provide PLI hooks to perform PLI immediate updates: - at the beginning of a cycle (before phase 1 starts) cbBeginNextCycle - on the return statement of a resolution or conversion function called for a given signal either during resolution or propagation. cbRetFuncCall - cbValueChange when a signal changes value. The target signal of the PLI update can be identified by a hierarchical instantiated path name. Proposed Solution ------------------ Typically, immediate signal updates (value deposits without event creation) can occur anytime during a simulation cycle. The execution of PLI signal immediate updates can also be executed during the execution of callback functions of specific callback reasons. Signal updates with event creation must occur at the beginning of a simulation cycle. PLI supports two updates strength mode: - force a value for the current cycle only - force value until release A complete implementation solution for updating signal values via the PLI will be proposed after all other PLI update cases have been addressed (IR02: scheduling signal values) Recommendation -------------- PLI Immediate signal update without event creation is an optional feature of the PLI. Callbacks for resolution or conversion function execution are also optional. Recommendation for Future Revisions of Standard ----------------------------------------------- Special handling or differences with VHDL'87: ---------------------------------------------- none Function Prototype and Synopsis -------------------------------