Fetch Interface Signaling and Protocol - 3.1 English - PG187

This appendix describes the Fetch Interface which is used to provide the SEM controller a frame of essential bits data to use for classifying errors. It is only needed when the classification feature of the SEM controller is enabled. It also provides helpful information for you to replace the SPI flash master helper block with an alternate function like a parallel flash memory controller.

For AMD UltraScale™ SSI devices, the example design SPI flash master demonstrates how to manage a single SPI flash with the Fetch interfaces of multiple SLR. For all others, the example SPI flash master manages a single SPI flash with a single fetch interface.

The following figure illustrates the protocol used on the transmit portion of the Fetch Interface. When the controller wants to transmit a byte of data, it first samples the fetch_txfull signal to determine if the transmit buffer is capable of accepting a byte of data. Provided that fetch_txfull is Low, the controller transmits the byte of data by applying the data to fetch_txdata[7:0] and asserting fetch_txwrite for a single clock cycle.

Figure 1. Fetch Interface Transmit Protocol

The controller can perform burst writes by applying a data sequence to fetch_txdata[7:0] and asserting fetch_txwrite for multiple cycles. However, the controller observes fetch_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 fetch_txfull. In the cycle after the peripheral samples fetch_txwrite High, it must assert fetch_txfull if the data written completely fills the buffer.

Further, the peripheral must only assert fetch_txfull in response to fetch_txwrite from the controller. Under no circumstances can the peripheral assert fetch_txfull based on events internal to the peripheral. This requirement exists because the controller can sample fetch_txfull several cycles in advance of performing a write.

While fetch_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.

The following figure illustrates the protocol used on the receive portion of the Fetch Interface. When the controller wants to receive a byte of data, it first samples the fetch_rxempty signal to determine if the receive buffer is providing a byte of data. Provided that fetch_rxempty is Low, the controller receives the byte of data from fetch_rxdata[7:0] and acknowledges reception by asserting fetch_rxread for a single clock cycle.

Figure 2. Fetch Interface Receive Protocol

The controller can perform burst reads by obtaining a data sequence from fetch_rxdata[7:0] and asserting fetch_rxread for multiple cycles. However, the controller observes fetch_rxempty so that it never under-runs the receive buffer.

The peripheral providing the data is responsible for tracking its correct buffer status and reporting it through fetch_rxempty. In the cycle after the peripheral samples fetch_rxread High, it must assert fetch_rxempty if the data buffer is empty.

Further, the peripheral must only assert fetch_rxempty in response to fetch_rxread from the controller. Under no circumstances can the peripheral assert fetch_rxempty based on events internal to the peripheral. This requirement exists because the controller can sample fetch_rxempty several cycles in advance of performing a read.

The data exchanged is binary and represents a command-response pair. The data format is little endian. For data[7:0], 0 is the LSB and 7 is the MSB. For a 32-bit word Byte 0 is the least significant byte, and Byte 3 is the most significant byte. The controller uses the Fetch Interface to send commands and to read the classification data from external memory during the classification state (status_classification = 1). All addresses are byte addresses, and all transactions are one byte at a time.

The controller transmits a 6-byte command sequence to initiate a data fetch using fetch_tx interface. The command sequence is:

• Byte 1: ADD[31:24]
• Byte 2: ADD[23:16]
• Byte 3: ADD[15:8]
• Byte 4: ADD[7:0]
• Byte 5: LEN[15:8]
• Byte 6: LEN[7:0]

The ADD field is the address, and LEN field represents the number of bytes of data the controller expects to receive from the peripheral. In general, the command type is "read LEN bytes starting at ADD address." The ADD field value that the controller provides is dependent on the classification base pointer that is defined by the user. See Fetch Interface.

The following figure illustrates this command sequence.

Figure 3. SEM Controller Sending Commands to Peripheral

In response, the peripheral must fetch LEN[15:0] bytes of data starting from address ADD[31:0] and return this data to the controller. After the controller has issued a command, the peripheral must fulfill the command with the exact number of requested bytes on the fetch_rx interface. The following figure illustrates transaction with the LEN field equals 4.

Figure 4. Peripheral Returning Data to SEM Controller