Xilinx中的xapp1052理解

    xapp1052是xilinx官方给出的一个有关DMA数据传输的样例，用于PC端和FPGA端之间的DMA数据传输。首先需要说的是，xapp1052并不是一个完整的DMA数据传输的终端硬件设计，这在下面会有详细解释。

    首先说一下xapp1052模块的组成结构：顶层模块是xilinx_pci_exp_ep，在顶层模块中包含pci_exp_64b_app和bmd_design两个模块，其中pci_exp_64b_app就是我们要介绍的重点，而bmd_design则是实现PCIE协议的底层模块。

    下面就详细说一下pci_exp_64b_app的模块结构：

     pci_exp_64b_app

     |

     |__BMD

           |

           |__BMD_EP

           |     |

           |     |__BMD_EP_MEM_ACCESS

           |     |     |_BMD_EP_MEM

           |     |

           |     |__BMD_RX_ENGINE

           |     |__BMD_TX_ENGINE

                 |     |__BMD_INTR_CTRL

                 |

           |     |__BMD_GEN2

           |     |__BMD_RD_THROTTLE

           |

           |__BMD_TO_CTRL

           |__BMD_CFG_CTRL

    1，BMD_RX_ENGINE的设计：这个模块的作用就是接受来自PC的TLP包(trn_rd[63:0])，并根据不同的情况对包进行拆解，首先根据trn_rd[62:56]位判断包的类型，如果是32位地址读请求(BMD_MEM_RD32_FMT_TYPE)，那么就转到32位读对应的状态(BMD_64_RX_MEM_RD32_QW1)；如果是32位地址写请求(BMD_MEM_WR32_FMT_TYPE)，那么久转到32位写对应的状态(BMD_64_RX_MEM_WR32_QW1)；如果是不带数据的完成类型(BMD_CPL_FMT_TYPE)，那么就转到完成请求对应的状态(BMD_64_RX_CPL_QW1)；如果是带数据的完成类型(BMD_CPLD_FMT_TYPE)，那么就转到带数据完成对应的状态(BMD_64_RX_CPLD_QW1)。

    上面是状态机的第一次过渡，下面看状态的第二次过渡，在状态是BMD_MEM_RD32_FMT_QW1时，这个时候TLP包的第二个DWORD已经传来，从第二个DWORD中可以得到读请求的地址addr_o，这个地址时输入到memory模块下用于读出对应地址下的数据的；然后过渡到下一个状态(BMD_64_RX_MEM_32_WT)，在这个状态下，RX模块会一直检测从TX返回的compl_done_i信号，当读请求申请的对应地址下的数据由TX发送出去时，compl_done_i信号就为1，这个时候RX就会返回到RST状态。当状态是BMD_MEM_WR32_FMT_QW1时，这个时候RX也接受到了TLP包的第二个DWORD，从这个DWORD中可以拆分出地址(addr_o)和要写的数据(wr_data_o)，同时在这个状态写使能值为有效(we_en_o)，然后过渡到下一个状态(BMD_64_RX_MEM_WR32_WT)，在这一个状态，RX会一直检测从memory模块出来的信号(wr_busy_i)是不是为0，如果为0，说明写操作完成，RX回到RST状态。当状态是BMD_64_RX_CPL_QW1的时候，说明这是一个不带数据的完成，其他并没有什么操作。当状态是BMD_64_RX_CPLD_QW1时，说明这是一个带数据的完成，为什么完成信号要携带数据呢，原因就是为了检验传输的数据是否正确，在这个状态下以及它的过渡状态中，RX会一次检测传输到PC端的数据和设备内存的数据是否相同，如果不相同，说明数据传输失败，返回失败传输信号(cpld_malformed)。

    从上面的描述可以看出，BMD中的RX是不支持连续的写数据的（往设备内存写数据），所以往设备内存写数据的DMA操作，xapp1052是不支持的，那么这里发送和接收的数据到底是什么呢，其实这里RX并不是要发送和接收存储数据，而是发送和接收配置数据，即DMA的配置数据。

    2，BMD_TX_ENGINE的设计：这个模块是往PC端发送TLP包(trn_td[63:0])，这个模块是xapp1052DMA的核心模块，它包含DMA控制器的所有操作，当然这里只是发送端的DMA控制器。TX要解决的问题就是要在不同的情况下发送对应的TLP包。

    第一种情况：发送带数据的完成TLP，这是TX最优先处理的(这一点不是很确定，个人感觉xapp1052写的有点问题)。首先在RST状态会产生一个带数据类型的包头。然后过渡到下一个状态：BMD_64_TX_CPLD_QW1。在这个状态里要发送TLP的第二个DWORD，主要包含地址和数据，然后进入下一个状态(BMD_64_TX_CPLD_QW1)。

    第二种情况：开启DMA发送操作，在mwr_start_i和cfg_bm_en有效的情况下，开始发送TLP的包头，DMA的包头也只是一个普通的写数据请求；在DMA发送模式下，有几个参数是特别重要的：要发送的TLP数目、每个TLP中包含的数据长度、每个TLP对应PC端的起始写入地址。进入下一个状态(BMD_64_TX_MWR_QW1)的时候，TX首先会根据已经发送的TLP包的个数来计算PC端写入的起始地址(tmwr_addr)，根据计算出的起始地址发送TLP的第二个DWORD，然后进入下一个状态：BMD_64_TX_MWR_QWN。在这个状态中，TX首先会判断一个TLP包中的数据长度是多少，如果是1，则在发送下一个DWORD之后，TX会进入RST状态；如果是2，则下一个DWORD会包含两个数据，但是同样在发送完下一个DWORD之后，TX会进入RST状态，在进入RST状态之前，TX又会判断当前发送的TLP数目是否已经等于预先设定的数，如果相等，则会返回mwr_done_o信号；如果当前数据长度大于2，那么在发完下一个DWORD的时候，TX还会继续发送数据，知道余下的数据长度小于2。这就是TX的发送DMA操作，但是现在有一个问题就是在每个TLP中的数据长度大于2的时候，发向PC端的地址该由谁控制累加呢，这在TX模块中并没有体现，这里我猜测是在PC端地址会由相应的模块控制自动累加。还有这里的TX的DMA其实也是有一定问题的，DMA发送的数据不是由内存读取出来的，而是一个始终不变的数，虽然表面上看是由内存中读取出来的，说明xapp1052的TX的DMA设计也只是存粹验证一下DMA控制器的正确性，数据的来源xapp1052却并没有涉及