Interface Dependencies - 1.1 English

Each block is input through the data input interface (DIN) over a number of cycles. The amount of data transferred on each cycle is set by a separate data stream (DIN_WORDS) where a value is given per transaction on DIN. If this does not need to be changed, then there is an option to tie this off in the Vivado® IDE. The output is generated in a similar way on the DOUT output stream, and similarly, the amount of data transferred is specified on the input data stream, DOUT_WORDS. If the number of words is fixed, then the core optional support logic ties this input off.

For each data block, a single input is required on the control (CTRL) input stream, specifying key block specific parameters, such as block size. One control word (transaction) is required for each data block, and data input stalls until the relevant control word is available. When decoded (or encoded in the case of LDPC), the output data is provided on DOUT along with a status word on the status (STATUS) output interface.

All AXI4-Stream interfaces contain valid and ready handshakes for flow control. Blocking either output (by deasserting ready) ultimately stops decoding and, when the input buffer is full, prevents further input. The following figure summarizes the data dependencies of the SD-FEC core. This shows that data input on DIN is dependent on CTRL and DIN_WORDS, and output on DOUT is dependent on DOUT_WORDS. However, note that there exists latency (in cycles) between the input of the CTRL and the associated input of DIN_WORDS and DIN input being accepted. The latency is dependent on the mode in which the SD-FEC core operates. In 5G mode, if the code is not already downloaded, latency in cycles is shown in the Download Latency table. The cycles are taken by the support logic in generating and downloading code parameters to the SD-FEC core internal memory; however, if the code parameters already reside in the SD-FEC core, the number of cycles is small and the exact amount varies depending on the clock speed difference between s_axi_aclk and s_axis_ctrl_aclk. In other modes when the code parameters are to be downloaded externally, CTRL is applied after the code download is complete. In these modes, the latency between CTRL and the associated DIN/DIN_WORDS is a small number of cycles.

Likewise, there are a small number of cycles of latency between DIN_WORDS and DIN. If the latency on DIN is to be minimized then the input of CTRL and DIN_WORDS should be provided in advance. Similarly, on the output, DOUT_WORDS (if required) should be driven as soon as possible to avoid any latency on DOUT. Also, as shown in the following figure, there are shallow buffers on the interfaces that allow a small amount of data to be input on DIN and DOUT_WORDS before associated block control is provided on CTRL. This data is not processed by the SD-FEC core until the latter is available. Further implications of these buffers are:DIN input can start at the same time as CTRL and DIN_WORDS are applied, and several CTRL and DIN_WORDS transactions can be input in advance of their associated DIN packets.

When using the SD-FEC core, one simple approach to maximize throughput is to apply all inputs as quickly as the AXI4-Stream interface handshake allows, and to accept output as soon as it is ready. Alternatively, if throughput is to be controlled, then only the CTRL input can be regulated to the correct data block throughput rate while the other interfaces operate as previously described - that is, they are regulated by the SD-FEC core itself.