If an interface other than SPI bus is needed, the EXT shim can be replaced with an alternate function. For example, the EXT shim could be replaced with a parallel flash memory controller or other scheme for inter-process communication. When replacing the EXT shim with an alternate function, it becomes critical to understand the behavior of the Controller Fetch Interface.
For an overview of the signals, Fetch Interface . The byte transfer protocols for the Fetch Interface are identical to those of the Monitor Interface.
This 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.
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.
It is the responsibility of the peripheral receiving the data to correctly track its buffer availability and report 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.
This 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.
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.
It is the responsibility of the peripheral providing the data to correctly track its buffer status and report it through fetch_rxempty . In the cycle after the peripheral samples fetch_rxread High, it must assert fetch_rxempty if the data written completely fills the buffer.
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.
During the initialization state, the controller purges the receive buffer by reading and discarding data until it is empty. It then performs two more reads. Reads with an empty buffer condition are decoded as a reset signal. The controller assumes the reset signal initializes the transmit buffer and therefore does not wait for the transmit buffer to empty, as it has no way to observe this condition.
The data exchanged is binary and represents a command-response pair. The controller transmits a 6-byte command sequence to initiate a data fetch. 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]
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. For additional information about the organization of the data in the address space, see External Memory Programming File .