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) ]

[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
[in]tigger_time*[5] (simulation only) simulation time in which to raise own event to bypass waiting for event

Return Data

[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

[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

[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

Add Example Usage

Notes and Warnings

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.

See also


event_index: natural
transition_state: integer
signal next_state_rec: out NSR
state_reg_rec: in SRR
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