The REGISTER_FOR_EVENT and the FIRE_EVENT APIs are complementary procedure calls which are meant to be utilized in tandem. One application module uses the FIRE_EVENT procedure call to request that the framework module fire an event on event_index, while another application module calls the REGISTER_FOR_EVENT procedure call to schedule a state machine transition if and when event number event_index is received. In addition, the caller of FIRE_EVENT can also request to transition to state transition_state after any application module receives the fired event. This acknowledgment type behavior can be used as a form of synchronization between application modules, without the need to write any additional code.
When compared to other framework communication schemes, event firing can be viewed as a broadcast mechanism. Whereas, WRITE_FIFO_DATA can be viewed as a data path mechanism and the SHARED_REGISTER procedure can be viewed as a control path mechanism. The REGISTER_FOR_EVENT and FIRE_EVENT APIs also provide better semantics than using a SHARED_REGISTER procedure call when only a notification is needed and there is no need to pass data. In addition, firing events has the advantage of explicitly tying a change in the system state to a change in a state machine state.
Example API Call(s):
REGISTER_FOR_EVENT( 0, st_sync, next_state_rec, state_reg_rec );
Call Data [ 5 parameters (4 mandatory) ]
- Parameters
-
[in] event_index [1] framework event number [in] transition_state [2] state to transition to after receiving an event or an acknowledgement of reception of an event [out] next_state_rec [3] [in] state_reg_rec [4] [in] tigger_time* [5] (simulation only) simulation time in which to raise own event to bypass waiting for event
Return Data
- Parameters
-
[in] state_reg_rec(M).event_vector(N) [1] [std_logic] value asserted by from framework when an application module requests an event
Command Reference
Voice and Hotkey Commands:
- See also
- Register For Event Commands
Command Parameter Mapping
- Parameters
-
[in] event_index [2] f"index <integer>" [in] transition_state [3] "go to [state] (<state>|<integer>)" [in] trigger_time_option* [5] "(trigger time| timeout) (<timing function>)"
Command Return Data
- Parameters
-
[in] state_reg_rec(M).event_vector(N) [1] [std_logic] "event <integer>"
Voice/HotKey Command Sequence
| Voice Command | HotKey Sequence |
|---|---|
| "register for event one" | rfe1 |
| "go to state received" | goto st_received |
Usage Example
- Todo:
- Add Example Usage
Notes and Warnings
- Note
- 1) If a high number of events are needed (greater than 4) within a single application module, it is recommended to place some events on another resource index.
2) If the caller of FIRE_EVENT transitions due to an acknowledgement, that transition will occur 2 clock cycles after the reception of the event. Whereas the transition for application module that called REGISTER_FOR_EVENT will occur 1 clock cycles after the reception of the event.
3) The REGISTER_FOR_EVENT procedure call also allows a non-synthesizable trigger_time_option parameter that can be used for simulation purposes. This optional parameter takes a VHDL time type as an input value and specifies the simulation time to trigger a bypass for waiting for an event. The use case for this non-synthesizable option occurs frequently when writing a testbench. The optional parameter exists for convenience and by simply removing the optional parameter, the design would become synthesizable once again.
Procedures | |
| REGISTER_FOR_EVENT( event_index: natural transition_state: integer signal next_state_rec: out NSR state_reg_rec: in SRR ) | |
| REGISTER_FOR_EVENT( event_index: natural transition_state: integer signal next_state_rec: out NSR_ARRAY state_reg_rec: in SRR_ARRAY ) | |
| overloaded for array interface and trigger after sim time | |