PRP Fetch Manager Module - 2.0 English

NVMe Target Controller LogiCORE IP Product Guide (PG329)
Document ID
PG329
Release Date
2020-12-04
Version
2.0 English

This module manages the fetching of additional PRP entries from the host by programming the descriptor on the QDMA H2C bypass interface. The NVMe TC IP supports PRPs and fetches all PRPs required for complete data transfer specified in the NVMe command. These PRPs are then pushed on the ddr_m_axi interface to the PRP memory location as provided by the parameter C_SGL_PRP_BUF_BA. PRP memory location of each UID holds PRPs and 128-bit PRP fetch information.

The NVMe TC fetches the maximum possible PRPs (or 2*(C_NUM_PRPS_PER_INDX – 1) PRPs) in initial fetch and provides pending PRP fetch requirement in 128-bit PRP fetch information , as shown in the following table, to the hardware application layer. Additional PRP request and response is done on sgl_prp_req_axis and sgl_prp_fill_m_axis interfaces respectively. The application must trigger additional PRP fetch by providing PRP fetch information on the sgl_prp_req_axis interface. The NVMe TC fetches additional PRPs and HW application is intimated on sgl_prp_fill_m_axis. NVMe TC implements two buffers in order to store PRPs. Let’s call them ping and pong buffers. First set of PRPs are filled in the ping buffer and NVMe command is delivered to the application. On receiving the trigger for the remaining PRPs, the NVMe TC fetches and stores additional PRPs in the pong buffer. TC switches between the ping and pong buffers alternatively for every PRP fetch request from the application. The application can hide additional PRP fetch latency by triggering PRP fetch before processing the current PRP set. Last PRP information is embedded in the PRP fetch information provided along with each PRP set. The application should stop trigger for additional fetch once last the PRP information is decoded in the PRP fetch information. The PRP fetch manager module detects invalid PRP offset error and sets appropriate error status along with command information to the hardware application.

Table 1. PRP Header Information
Bitwidth Field Size (Bits) Description
[31:0] Data_size_rem 32 Remaining data size to be fetched
[92:32] Host_addr 61 Host address [63:3] for additional PRP fetch.
[94] Sgl_or_prp 1 0 – PRPs are used for this command.
[106:95] prp_index 12 PRP Buffer Index
[107] ping_or_pong 1
  • 0 – Ping Buffer
  • 1 – Pong Buffer
[117:108] No_of_desc_rem 9 Number of PRP descriptors remaining in the current PRP list.
[123:118] Error_Code 6 PRP error code
[127:124] Valid_entries 4 Number of valid entries in current PRP Buffer Index. Valid vValuesareis 0 to 2*(C_NUM_PRPS_PER_INDX)-1
  1. In the current release, only the PRP buffer addressing is supported by the design.
  2. C_NUM_PRPS_PER_INDX is automatically derived from a Vivado build based on user configured MDTS values.

The response for the next set of PRP fetch is provided on the sgl_prp_fill_m_axis interface in the format given in the following table.

Table 2. PRP Fill Descriptor information
Bitwidth Field Size (Bits) Description
[11:0] prp_index 12 PRP Buffer Index
[12] Ping_or_pong 1
  • 0 – Ping Buffer
  • 1 – Pong Buffer
[15:13] Reserved 3 Reserved