Hardware Reference Manual 49
Intel® IXP2800 Network Processor
Technical Description
2.3.9 Event Signals
Event Signals are used to coordinate a program with completion of external events. For example,
when a Microengine executes an instruction to an external unit to read data (which will be written
into a Transfer_In register), the program must insure that it does not try to use the data until the
external unit has written it. This time is not deterministic due to queuing delays and other
uncertainty in the external units (for example, DRAM refresh). There is no hardware mechanism to
flag that a register write is pending, and then prevent the program from using it. Instead the
coordination is under software control, with hardware support.
In the instructions that use external units (i.e., SRAM, DRAM, etc.) there are fields that direct the
external unit to supply an indication (called an Event Signal) that the command has been
completed. There are 15 Event Signals per Context that can be used, and Local CSRs per Context
to track which Event Signals are pending and which have been returned. The Event Signals can be
used to move a Context from Sleep state to Ready state, or alternatively, the program can test and
branch on the status of Event Signals.
Event Signals can be set in nine different ways.
1. When data is written into S_TRANSFER_IN registers
2. When data is written into D_TRANSFER_IN registers
3. When data is taken from S_TRANSFER_OUT registers
4. When data is taken from D_TRANSFER_OUT registers
5. By a write to INTERTHREAD_SIGNAL register
6. By a write from Previous Neighbor Microengine to NEXT_NEIGHBOR_SIGNAL
7. By a write from Next Neighbor Microengine to PREVIOUS_NEIGHBOR_SIGNAL
8. By a write to SAME_ME_SIGNAL Local CSR
9. By Internal Timer
Any or all Event Signals can be set by any of the above sources.
When a Context goes to the Sleep state (executes a ctx_arb instruction, or an instruction with
ctx_swap token), it specifies which Event Signal(s) it requires to be put in Ready state.
The ctx_arb instruction also specifies if the logical AND or logical OR of the Event Signal(s) is
needed to put the Context into Ready state.
When all of the Context’s Event Signals arrive, the Context goes to Ready state, and then
eventually to Executing state. In the case where the Event Signal is linked to moving data into or
out of Transfer registers (numbers 1 through 4 in the list above), the code can safely use the
Transfer register as the first instruction (for example, using a Transfer_In register as a source
operand will get the new read data). The same is true when the Event Signal is tested for branches
(br_=signal or br_!signal instructions).
The ctx_arb instruction, CTX_SIG_EVENTS, and ACTIVE_CTX_WAKEUP_#_EVENTS
Local CSR descriptions provide details.