The following figure illustrates the protocol used
on the transmit portion of the Monitor Interface. When the controller wants to transmit a byte
of data, it first samples the monitor_txfull signal to
determine if the transmit buffer is capable of accepting a byte of data. Provided that monitor_txfull is Low, the controller transmits the byte of data by
applying the data to monitor_txdata[7:0] and asserting monitor_txwrite for a single clock cycle.
The controller can perform burst writes by
applying a data sequence to monitor_txdata[7:0] and asserting
monitor_txwrite for multiple cycles. However, the
controller observes monitor_txfull so that it never over-runs
the transmit buffer.
The peripheral receiving the data is responsible
for tracking its correct buffer availability and reporting it through monitor_txfull. In the cycle after the peripheral samples monitor_txwrite High, it must assert monitor_txfull if the data written completely fills the buffer.
Further, the peripheral must only assert monitor_txfull in response to monitor_txwrite from the controller. Under no circumstances can the peripheral
assert monitor_txfull based on events internal to the
peripheral. This requirement exists because the controller can sample monitor_txfull several cycles in advance of performing a write.
While monitor_txfull is asserted by the peripheral, the controller stalls if it is
waiting to transmit additional data. This can have negative side effects on the error
mitigation performance of the controller. For example, if a correction takes place, the
controller successfully corrects (or handles) the error and sends a status report. If the
entire message cannot be accepted by the peripheral, the controller stalls, preventing it from
returning to the Observation state. Therefore, a custom peripheral must have an adequate
balance of buffer depth and data consumption rate.
The following figure illustrates the protocol
used on the receive portion of the Monitor Interface. When the controller wants to receive a
byte of data, it first samples the monitor_rxempty signal to
determine if the receive buffer is providing a byte of data. Provided that monitor_rxempty is Low, the controller receives the byte of data
from monitor_rxdata[7:0] and acknowledges reception by
asserting monitor_rxread for a single clock cycle.
The controller can perform burst reads by
obtaining a data sequence from monitor_rxdata[7:0] and
asserting monitor_rxread for multiple cycles. However, the
controller observes monitor_rxempty so that it never
under-runs the receive buffer.
The peripheral providing the data is responsible
for tracking its buffer status and reporting it through monitor_rxempty. In the cycle after the peripheral samples monitor_rxread High, it must assert monitor_rxempty if the buffer is empty.
Further, the peripheral must only assert monitor_rxempty in response to monitor_rxread from the controller. Under no circumstances can the peripheral
assert monitor_rxempty based on events internal to the
peripheral. This requirement exists because the controller can sample monitor_rxempty several cycles in advance of performing a read.
The format of the data sent and received on the Monitor Interface is byte-stream ASCII codes. Each ASCII code is represented by one byte of data. All transactions are one byte at a time.
SEM core reads on the monitor interface when
rxempty is high. Two pulses are seen on the monitor_rxread due to two times reset sequence (Two reads are done,
to cover corner case of one data showing up between flow control read, test, and issuance of
reset read.) Customer can either mask the errors or can feed the FIFO with two bytes that do
not do anything.
For example to send the error injection command
on N C0000007A4, the peripheral indicates data is ready by
setting monitor_rxempty to Low and presenting the N ASCII code (x4E ) first,
followed by a " " or space (space = x20 ), followed by C
(x43) and so on, with 4 (x34 ) being the last ASCII code sent on the monitor RX interface. The following
figure illustrates this transaction.
After the controller receives the command, it
echoes (sends back) the command to the peripheral through the monitor TX interface. Echoing
the command back signals to the peripheral that the controller has accepted the command and is
ready to accept the next command. This is also indicated by setting monitor_txfull to Low. The following figure illustrates this transaction.