Refer to Figure 7-3, DMDLOAD_REQ is an output signal from the APPS FPGA to the DLPC964 Controller.

Once the Aurora Block Data transfer is complete, the APPS FPGA user logics must assert DMDLOAD_REQ to signal the end of a DMD block to the DLPC964 Controller and trigger the DLPC964 Controller to carry out the operation encoded in the Block Control Word.

Guidelines for asserting the DMDLOAD_REQ signal and sending the Block Control Word:

• APPS FPGA user logics must wait for the block data transfer to complete on all four Aurora data channels before asserting DMDLOAD_REQ. Asserting DMDLOAD_REQ before completion of the Aurora block data transfer can result in data not being properly loaded to the DMD. The APPS FPGA must take into account that the four Aurora data channel interfaces may not be fully synchronous to one another, thus data completion may not happen at the exact same clock cycle. Therefore, the APPS FPGA must monitor and ensure the Aurora block data transfer is completed on all four channels before asserting DMDLOAD_REQ.
• DMDLOAD_REQ may be asserted immediately after completing an Aurora block transfer as long as the 300ns DMDLOAD_REQ setup time is met (refer to Section 7.3.1.3 for more details).
• Apps user logics must assert DMDLOAD_REQ for the current block before initiating the transmission of the next new DMD block data. In other words, every block must start with a Block Control Word packet and end with DMDLOAD_REQ assertion.
• DMDLOAD_REQ is still required for operations that do not involve block data transfer (such as block-clear or block-set operation), and must still meet the required 300ns setup time (refer to Section 7.3.1.3 for more details).
• Refer to Figure 7-5. In most cases, after the APPS FPGA user logic has completed the transfer of the current data block, it may find that the DLPC964 Controller is still loading the previous block to the DMD (i.e. BLKLOADZ is low). If this occurs, the APPS FPGA can still assert DMDLOAD_REQ while BLKLOADZ is low. The DLPC964 Controller will detect and store the DMDLOAD_REQ request and perform the data load as soon as the transfer of the previous data block is complete.
• The DLPC964 Controller has two data-block buffers - one for receiving the incoming Aurora data block from the APPS FPGA, and the other for holding the previous data block for streaming out to the DMD. Care must be taken by the APPS FPGA to avoid overrunning these two buffers. Refer to Figure 7-5. After completing the current Aurora data transfer of block data and asserting the DMDLOAD_REQ signal, the APPS FPGA must wait for the de-assertion of BLKLOADZ by the DLPC964 Controller (i.e. BLKLOADZ transition from low to high) before starting the next block data transfer. De-assertion of BLKLOADZ indicates that the DLPC964 Controller has completed the DMD data loading operation for previous block, and a data buffer is freed up for accepting a new data block from the Aurora interface. The buffer will be overrun and data will be incorrectly loaded to the DMD if the APPS FPGA does not synchronize the Aurora block data transfer with BLKLOADZ signal de-assertion.
• It is not necessary for the APPS FPGA to immediately assert DMDLOAD_REQ after sending a DMD data block. The APPS FPGA may send the DLPC964 Controller a DMD data block and then delay the assertion of DMDLOAD_REQ until the system is ready for the DMD be loaded. Figure 7-6 describes this operation.

Figure 7-5 End of Block DMDLOAD_REQ Assertion Followed by New Block Control Word Waveform.

1. APPS FPGA user logic asserts DMDLOAD_REQ immediately after the completion of current block data transmission on all four Aurora data interfaces.
2. DLPC964 Controller de-asserts BLKLOADZ, indicating completion of the data loading operation for the previous DMD block.
3. APPS FPGA user logics detects the de-assertion of BLKLOADZ and sends a new Block Control Word on Aurora Channel 0 User-K Port for the next block data.
4. APPS FPGA user logics sending data for next block.
5. BLKLOADZ is asserted low by the DLPC964 Controller, indicating the data loading operation for current block triggered by DMDLOAD_REQ occurred at 1.

Figure 7-6 DMDLOAD_REQ Delayed Assertion Waveform.

1. APPS FPGA finishes sending the last block data (block 15) of the current pattern and asserts DMDLOAD_REQ to instruct the DLPC964 Controller to carry out the data load operation.
2. DLPC964 Controller loads data to block 15, triggered by DMDLOAD_REQ from 1.
3. APPS FPGA sends the first block (block 0) of data for the next pattern over the Aurora data interfaces while the DLPC964 Controller is loading block 15 of the current pattern.
4. DLPC964 de-asserts BLKLOADZ after completing the data load for block 15 of the current pattern. APPS FPGA detects the BLKLOADZ de-assertion (because the last block data of the current pattern has been loaded on to DMD) and issues an MCP_START signal for global block MCP operation. Notice that the DLPC964 Controller asserted the MCP0_ACTIVE signal to communicate that the MCP mirror operation in process.
5. APPS FPGA delays the assertion of DMDLOAD_REQ for block 0 of next pattern due to the requirement of meeting the mirror settling time.
6. APPS FPGA sends the Block Control Word for block 1 of the next pattern after the assertion of DMDLOAD_REQ for block 0.
7. DLPC964 Controller asserts BLKLOADZ to indicate that the DMD data loading operation was triggered by DMDLOAD_REQ from 5.