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.