Output Arbitration - STMicroelectronics SPC572L series Reference Manual

RM0400
When a stall condition is detected, the NAR can do one thing. If the client stalls, then the
NAR must complete the current stalled message to continue operating. This scenario is
termed a stall error. On a stall error, the NAR injects a dummy message beat into the
message stream after the last valid beat of data received from the stalled client. The dummy
message is a single beat injected at the output of the receive queue into the main queue.
The MSEO bits of the data payload are set to 2b11 regardless of the previous Nexus state.
This forces the dummy message into the End Message state. When the NAR injects a
dummy message, it also generates an error message to notify the user what has happened.
Injecting a dummy message is an intrusive act, which alters the data stream from the client.
If a stalled client is thought likely to recover cleanly, it might be advisable to suppress stall
errors to prevent the data stream from being corrupted. This can be done by setting the SED
bit of the configuration register, which carries the risk of a truly dead client causing the NAR
to hang. Otherwise, the default operation is for the NAR to inject the dummy message and
then monitor the client for signs of recovery. If the client does come back online, the NAR
attempts to wait until it sees an end-of-message boundary before capturing new data. At
best, if the client recovers smoothly, only the interrupted message is lost; if the client does
not recover smoothly, it might not be possible for the client and NAR to get back in sync in
terms of their Nexus states, which would lead to nothing but garbled data coming out. For
this reason, it is also possible to prevent the NAR from trying to recover from a stall error, by
setting the SRD bit of the NAR_CR. If the SRD bit is set, a stalled client is not allowed to
recover until the SRD bit is unset or the NAR is reset.
65.5.6

Output arbitration

The NAR allows two output ports to be active at the same time. This feature is only available
on the BD NAR. Typically, this feature is only useful if one of the ports is used to service
messages of a specific type and/or messages from a particular client, while the other port
supports all the rest of the message traffic. For example, the NAR could be set up to send
in-circuit trace (ICT) traffic out the HBDP and to reserve the trace memory bus port for all
other Nexus messages.
If two output ports are enabled, one of them must be designated as the Message Select Port
(MSP). The MSP is the destination for those messages that satisfy a set of user-defined
requirements as to the source and type of message. All other traffic is sent to the other
enabled port. Ports are enabled by setting the port enable bits in the BD NAR_CR. The MSP
is designated by setting bits [10–9] and ALT is designated by setting bits [7–6]. Once the
MSP has been specified, other bits in the NAR_CR, along with the Source Filter Register
(NAR_SFR) and Type Filter Register (NAR_TFR), are used to determine which messages
go to the MSP and which do not. These facilities can be used to build a logical expression
that can filter messages based on up to four types and/or four sources.
The NAR_SFR can be programmed with up to four source codes, while the NAR_TFR can
hold up to four message-type codes. Each filter also includes an enable bit to turn it on or
off. A source match occurs if a messages source code matches one of the source filters or
(if the SFI bit is set) if it does not match any of the source filters. Similarly, a type match
occurs if a messages type code matches one of the type filters or (if the TFI bit is set) if it
does not match any of the type filters. Finally, the ACC bit of the NAR_SFR determines
when both source and type filters are used, whether the two are ANDed together (ACC = 0)
DocID027809 Rev 4
Nexus Aurora Router (NAR)
1893/2058
1908