Data Reception And Arbitration - STMicroelectronics SPC572L series Reference Manual

Nexus Aurora Router (NAR)
Operation
If multiple output ports are enabled, route messages from top of queue to appropriate output
Output Arbitration port based on message type or source. If split queue is used, outputs can run
simultaneously, with each sub-queue communicating directly with a port.
Data going out the Aurora or trace memory bus ports must be translated into the correct
Translation
format prior to transmission.
Enabling the NAR and one or more output ports without setting the communication-disable
bit puts the NAR into transmit mode.
65.5.3

Data reception and arbitration

The NAR supports 2 clients. Each client has a dedicated input port on the NAR and
communicates with its associated input port via a dedicated data bus. A data transmission
must consist of an integer number of 32-bit Nexus words (32-bit word is called a beat). The
number of beats varies from client to client. The number of beats (Bn) for each client are
described in the Calibration and Debug configuration chapter which describes how the
modules are configured.
There are two types of clients supported at NAR client interface. The client types have their
own protocols to send Nexus messages. The only common parameter is the Nexus word
size (beat). One Nexus word consists of 30 Message Data Out (MDO) bits plus two
Message Start/End Out (MSEO) control bits. Internally, the NAR converts all client interfaces
to a common interface. To achieve this, the NAR instantiates interface level gaskets that
handle the protocol conversion and clock domain transfer.
When new data is available in the core, it is transferred over to the asynchronous gasket in
the internal NAR clock domain. The gasket then asserts enough data valids to fill internal
receive queue, using a receive queue available signal to track available space in the
associated queue, under the assumption that the receive queue available signal is initialized
with the size of the queue. If the internal arbiter consumes any of its queued entries, it
responds with a data accept signal, which increments the receive queue available signal
and allows the gasket to send the next piece of data. Under certain circumstances, like
receive queue reallocation, it is possible for the internal arbiter to send out surplus data
accept signals such that the receive queue available signal can become larger than the size
of the queue. If the receive queues are sized correctly, when NAR is actively servicing a
particular client, then asserted data accept signals allow the client to continually stream data
until the NAR switches to a new client. The data tracking at the gasket assures that it never
sends more data than the receive queue can accept and inactive queues are always full and
ready for when they are switched to.
The client gaskets must always be in sync with the internal logic of NAR in terms of the
number of available entries in each receive queue. For this reason, the internal NPC and its
client gaskets need to be reset by the same signal. Any soft-reset of the NAR (via the
SRESET configuration bit) is communicated to all gaskets and used to reset every thing
inside it.
Each input port has a dedicated receive queue with a minimum of two entries, where an
entry is wide enough to store an entire Bn × 32 data word (where 32 is the number of bits in
the Nexus word or the beat). The receive queue can be made larger to allow the NAR to
continue transmitting during switches from one client to another in a pipelined environment.
1890/2058
Table 1062. NAR transmit operations(Continued)
DocID027809 Rev 4
Description
RM0400