Monolithic and UltraScale+ SSI Devices - 3.1 English

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.

Figure 1. Monitor Interface Transmit Protocol

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.

Figure 2. Monitor Interface Receive Protocol

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.

Figure 3. Peripheral Sending Error Injection Command Through Monitor RX Interface

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.

Figure 4. SEM Controller Receiving Error Injection Command from Peripheral Successfully