Core Facts
Provided with Core
Documentation	Reference Design Manual Demo Instruction Manual
Design File Formats	Encrypted File
Instantiation Templates	VHDL
Reference Designs & Application Notes	Vivado Project, See Reference Design Manual
Additional Items	Demo on VCK190
Support
Support Provided by Design Gateway Co., Ltd.

Design Gateway Co.,Ltd

E-mail: ip-sales@design-gateway.com

URL: design-gateway.com

Features

· NVMe host controller for access one NVMe SSD without CPU and external memory

· Two user interfaces (one-Write user and one-Read user) operating simultaneously

· Support six commands.

· User#0 (Main user): Identify, Shutdown, SMART, Flush, and Read command.

· User#1 (Sub user): Write command

· Support multiple Write and Read commands for 4Kbyte random access

· Configurable Command Depth of Write and Read command independently: 32, 64, 128, 256

· Buffer size (depends on Command Depth): 128Kbyte (32 Commands) – 1Mbyte (256 Commands)

· Simple user interface by using Data stream interface

· Supported NVMe device

· Base Class Code:01h (mass storage), Sub Class Code:08h (Non-volatile), and Programming Interface:02h (NVMHCI)

· MPSMIN (Memory Page Size Minimum): 0 (4 Kbyte)

· MQES (Maximum Queue Entries Supported) more than or equal to (2 x Command Depth -1)

· LBA unit: 512 bytes

· User clock frequency must be more than or equal to PCIe clock (250MHz for Gen4)

· PCIe Hard IP: Integrated Block for PCI Express from Xilinx (256-bit bus interface of 4-lane Gen4)

· Connect to one NVMe SSD directly (without PCIe switch)

· Available reference designs: VCK190 board with AB18-PCIeX16 adapter board

· Customized service for following features

· Additional NVMe commands

Table 1: Example Implementation Statistics (Versal)

Family

Example Device

U0/U1

Cmd Depth

Fmax

(MHz)

CLB

Regs

CLB

LUTs

Slice¹

BRAM

Tile

URAM

Design

Tools

Versal AI Core

XCVC1902-VSVA2197-2MP-E-S

375

8328

4398

1480

Vivado2022.1

256

370

8328

4526

1602

Notes: 1) Actual logic resource dependent on percentage of unrelated logic

Applications

Figure 1: rmNVMe IP Application

The FPGA can be utilized as the offload engine for the database server to access storage, NVMe SSD. In large-scale systems, multiple threads frequently access the database, leading to a high volume of read and write requests being sent to the CPU. The write data, which is usually of a large size, is stored in the main memory. The FPGA platform's PCIe engine provides an interface that allows the offload engine to receive command requests from the CPU and directly access the data in the main memory with high performance.

The File Offload Engine sends read and write requests to the rmNVMe IP via the Read Command Interface and Write Command Interface, respectively. All write data is transferred via the Write Data Interface and stored in the NVMe SSD. The read data from the NVMe SSD is returned to the File Offload Engine via the Read Data Interface and finally, returned to the thread through the main memory.

By utilizing this hardware system, the database can be accessed with high performance while requiring less CPU resources.

General Description

Figure 2: rmNVMe IP for Gen4 block diagram

rmNVMe IP for Gen4 implements the NVMe host controller to access NVMe SSD with random access and two-user function. Physical interface of NVMe SSD is PCIe which is handled by Integrated Block for PCI Express (PCIe hard IP) in Xilinx FPGA.

rmNVMe IP supports six NVMe commands, i.e., Identify, Shutdown, Write, Read, SMART, and Flush command with two user interfaces – User#0 I/F and User#1 I/F. User#0 I/F is the interface of NVM#0 module inside rmNVMe IP while User#1 I/F is the interface of NVM#1 module. NVM#0 (Main) supports many NVMe commands, i.e., Identify, Shutdown, Read, SMART, and Flush command. While NVM#1 (Sub) supports only Write command. The User#0 I/F and User#1 I/F consists of two interface groups. First is Control interface for transferring command and the parameters. Another is Data interface for transferring data when the command must have the data transferring.

Control interface uses the FIFO interface to support multiple Write/Read command requests from the user with parameter assignments. While the Data interface of Write/Read command uses Data stream interface, 256-bit data bus controlled by valid/ready/pause signal.

SMART and Flush command require the specific interface, called Custom command interface, which consists of Ctm I/F for Control path and Ctm RAM I/F for Data path. Furthermore, Identify command also has its own data interface, named Iden RAM I/F, as shown in Figure 2. All of these specific interfaces are integrated only in User#0 I/F.

Due to two user interfaces, while Write command is operating in NVM#1, some commands can be operating parallelly in NVM#0, i.e., Identify, Read, SMART, and Flush. However, there is one limitation about the parallel operation. Shutdown command must be executed after both NVM#0 and NVM#1 return back to be idle. Thus, NVM#0 must not be requested for Shutdown command while NVM#1 operates Write command.

During initialization process or running some commands, error signal may be asserted by rmNVMe IP if some abnormal conditions are found. The IP includes the error status to check the more details of error condition. To recover error status, rmNVMe IP and SSD must be reset.

rmNVMe IP includes asynchronous circuit to allow the user logic running in the individual clock domain, not PCIe clock. However, there is one limitation about clock frequency of user logic. Transmit packet to PCIe hard IP must be sent continuously until end of packet. Therefore, data must be valid every clock between start of packet and end of packet. To support this feature, user logic clock (Clk) frequency must be more than or equal to PCIe clock (PCIe clock) frequency which is 250 MHz for PCIe Gen4 to have the bandwidth of transmit logic higher than or equal to PCIe hard IP bandwidth.

The reference designs on FPGA evaluation boards are available for evaluation before purchasing.

Functional Description

Figure 3: Operation Flow of rmNVMe IP

The operation flow of rmNVMe IP is divided into three phases, i.e., Initialization, Command operation, and No operation, as shown in Figure 3. Firstly, the Initialization phase is handled by NVM#0. In this phase, NVM#1 merely waits until the end of Initialization. The Initialization step includes

1) NVM#0 waits until PCIe is ready by monitoring Linkup status from PCIe IP core.

2) NVM#0 begins the initialization process by setup PCIe registers and NVMe registers. If some errors are detected during setup process, NVM#0 changes the IP to the Inactive state.

After that, both user interfaces are idle and ready to receive command from user. The command can be requested by User#0 I/F and User#1 I/F parallelly. Furthermore, multiple Read commands (to NVM#0) and multiple Write commands (to NVM#1) can be requested until Cmd FIFOs are full. However, Shutdown command is exceptional because it needs to wait until both NVMe#0 and NVM#1 are Idle before sending this command request to User#0 I/F. After the shutdown is completed, both NVM#0 and NVM#1 change to the Inactive state. More details of each command operation flow in Command operation phase of NVM#0 and NVM#1 are shown in Figure 4.

The operation of NVMe#0 to support five commands is shown in the left side while the operation of NVM#1 to support Write command is shown in the right side.

Figure 4: Command Operation Flow of NVM#0 and NVM#1

NVMe#0

1) The 1^st command from user must be Identify command (U0Cmd=000b) to update LBASize (disk capacity).

2) The last command before power down the system must be Shutdown command (U0Cmd=001b). This command is recommended to guarantee SSD powered down in a good sequence and all Write data is stored the flash memory, not cache in the SSD. After Shutdown command is done, rmNVMe IP and SSD enter to the Inactive state and do not receive any commands until the IP is reset.

3) The data size of each Read command which is requested to NVM#0 (U0Cmd=011b) is fixed to 4K bytes. More than one Read command can be requested by the user until Cmd FIFO#0 is full. Therefore, step 3a) – 3b) of NVMe#0 can be repeated until all Read commands are executed.

a) The IP sends Read command to SSD.

b) The 4K-byte data of each Read command is transferred to the user at the same order as the Read command request. After finishing transferring each 4K-byte data, one Read command is flushed from Cmd FIFO. The new Read command from user can be requested if the Cmd FIFO is not full. When a new Read command exists in the Cmd FIFO, NVM#0 returns to step 3a) to process next Read command. After all Read data are completely transferred, Cmd FIFO is empty and the IP returns to Idle state.

4) For SMART command (U0Cmd=100b), 512-byte data is returned after the operation is done.

a) The IP sends Get Log Page command to read SMART/Health information from SSD.

b) 512-byte data is returned from the SSD. The IP forwards the data through Custom command RAM interface (CtmRamAddr=0x00 – 0x0F).

5) For Flush command (U0Cmd=110b), there is no data transferring during the operation.

a) The IP sends Flush command to SSD.

b) The IP waits until SSD returns status to complete the operation.

NVMe#1

1) Similar to Read command, the data size of each Write command is fixed as 4 Kbytes. The user sends the Write command request to NVM#1 by asserting U1CValid to 1b. While NVM#1 is operating a Write command, user can request new Write commands until Cmd FIFO#1 is full. NVM#1 repeats step 1a) – 1c) until all Write commands are executed.

a) The IP waits until 4K-byte Write data is sent by user.

b) The IP sends Write command to SSD.

c) After the SSD returns the successful status for each Write command, one Write command is flushed from Cmd FIFO. The new Write command from user can be requested if the Cmd FIFO is not full. When a new Write command exists in the Cmd FIFO, NVM#1 returns to step 1a). After all Write commands are completely operated, Cmd FIFO is empty and the IP returns to Idle state.

2) After Shutdown command is done by NVM#0, rmNVMe IP and SSD enter to the Inactive state and do not receive any commands until the IP is reset.

To design NVMe host controller supporting multiple users and random access, rmNVMe IP for Gen4 implements two protocols, i.e., NVMe protocol for interfacing with user and PCIe protocol for interfacing with PCIe hard IP. Therefore, the hardware inside rmNVMe IP is divided to two groups – NVMe and PCIe. More details of each hardware module are described as follows.

NVMe

rmNVMe IP supports six commands s, i.e., Identify, Write, Read, SMART, Flush, and Shutdown command which can be arranged to two groups, i.e., Single-mode command and Multiple-mode command. There are four Single-mode commands, i.e., Identify, SMART, Flush, and Shutdown. All Single-mode commands are supported only in NVM#0 through User#0 I/F. When user sends Single-mode command request to NVM#0 via Cmd FIFO#0 interface, command ready signal in User#0 I/F is de-asserted to block the next command request from the user until the previous command is done. While there are two Multiple-mode commands - Write command and Read command. The maximum Read commands that can be requested to NVM#0 is configured by User#0 Command Depth parameter. While the maximum Write commands that can be requested to NVM#1 is configured by User#1 Command Depth parameter. The order of the data transferring via Data stream I/F is the same as the order of the Write/Read command that sent to Cmd FIFO (Control I/F). Moreover, data transfer size of one Write/Read command is fixed as 4 Kbytes, so the Data Buffer size of NVM#0 and NVM#1 is equal to 4 Kbytes x Command Depth parameter. For example, 128-Kbyte buffer is used to support 32 Commands and 1-Mbyte buffer is used to support 256 Commands.

To implement NVMe protocol, NVM#0 and NVM#1 block are designed to have five submodules, i.e., Host Controller, Cmd FIFO, Command Handler, Data Buffer, and Data Controller. However, submodule features and complexity between NVM#0 and NVM#1 are not exactly identical because of different user command support. The details of each submodule are described as follows.

· Host Controller

Host Controller is the main controller of rmNVMe IP that is designed inside each NVMe module. The module operation is split into two phases. First is the Initialization phase which is once run after the system is boot up for setting NVMe register inside the SSD. The initialization is operated only in Host Controller#0 as described early in Figure 3. After finishing the Initialization phase, the next phase is the Command operation phase.

To operate the command, Host controller must handle with Command Handler. When the command needs to transfer data such as Write, Read, SMART and Identify command, Host Controller must also handle with Data Controller. The order of each packet type returned from the SSD is monitored by Host controller. The status value in the received packet is decoded to confirm that the command is finished normally or some errors are found. The error status is returned to the user when some errors are detected by Host Controller.

· Cmd FIFO

The maximum number of Multiple-mode commands can be configured by Command Depth parameters (C0Depth and C1Depth – the input parameters of rmNVMe IP as shown in Table 3). The Command Depth can be set by four values, i.e., 32, 64, 128, and 256 to define the depth of Cmd FIFO#0 and Cmd FIFO#1 inside rmNVMe IP.

Cmd FIFO#0 and Cmd FIFO#1 are applied to store the address of Read command and Write command, respectively, for operating as Multiple-mode command. If the user needs to send Single-mode command to NVMe#0, the user must wait until Cmd FIFO#0 is empty.

· Command Handler

This module creates command packet and decodes the status packet returned from the SSD after each command is done. The parameters within the command packet are set by the internal registers when the command is Identify, Shutdown, Write, or Read command. When the command is SMART or Flush command, the parameters are set via 512-bit Custom command interface, called Custom submission queue entry which is defined by 16 DWORDs (1 DWORD = 32-bit).

The status of each command is returned via Completion queue entry. There are three outputs for user to monitor the status extracted from Completion queue entry, i.e., 16-bit Admin completion status when running Identify or Shutdown command, 32-bit IO completion status when running Write or Read command, and 128-bit Custom completion status defined by 4 DWORDs when running SMART of Flush command.

· Data Buffer

Two Data Buffers are applied in rmNVMeIP, Data Buffer#0 and Data Buffer#1. Both Data Buffers are implemented by URAM. Data Buffer#0 integrated in NVM#0 stores the raw data of Read command while Data Buffer#1 integrated in NVM#1 stores the raw data of Write command. Data Buffer stores data transferring between UserLogic and the SSD. The size of Data Buffer is related to Command Depth parameter because each Write/Read command requires 4Kbyte buffer size, as shown in Table 2.

Table 2: Data Buffer size of each Command Depth value

Command Depth	Data Buffer size
32 commands	128 Kbyte
64 commands	256 Kbyte
128 commands	512 Kbyte
256 commands	1 Mbyte

· Data Controller

This module is operated when the command must transfer the data, i.e., Identify, SMART, Write, and Read command. There are three data interfaces for transferring with the SSD, i.e., Data stream interface with Data Buffer when running Write or Read command, Custom command RAM interface when running SMART command, or Identify interface when running Identify command.

The data controller must allocate 4Kbyte size for transferring the data per Write/Read command. Also, the Data controller must handle the order of 4Kbyte data transferred with the user to be similar to the order of the Write/Read Command from user.

PCIe

The PCIe standard is the outstanding low-layer protocol for very high-speed application. The NVMe standard is the protocol which is run over PCIe protocol. In the initialization process, NVMe layer is setup after finishing PCIe layer setup. Two modules are designed to support PCIe protocol – PCIeCtrl and AsyncCtrl. More details of each module are described as follows.

· PCIeCtrl

In initialization process, PCIeCtrl sets up PCIe environment of SSD via CFG interface. After that, PCIe packet is created or decoded via 256-bit Tx/Rx AXI4-Stream. The command packet and the data packet from NVMe module are converted to be PCIe packet by PCIeCtrl. On the other hand, the received PCIe packet is decoded and converted to be NVMe packet for NVMe module by this module.

· AsyncCtrl

AsyncCtrl includes asynchronous registers and buffers to support clock domain crossing. Most logics in rmNVMe IP run on user clock domain while PCIe hard IP runs on PCIe clock domain. AXI4-stream interface of PCIe hard IP must transfer data of each packet continuously. Therefore, the user interface bandwidth must be greater than or equal to the PCIe interface bandwidth by setting User clock frequency at higher than or equal to PCIe clock frequency.

User Logic

This module could be designed by using small state machine to send the commands with assigning the parameters for each command. The rmNVMe IP supports multiple Write/Read command, so user can send the command to Control interface (Cmd FIFO) and transfer the data by Stream interface (valid/ready signal) individually. While the data output of SMART command and Identify command can be mapped to simple dual port RAM with byte enable. All data interfaces are 256-bit interface. The returned data size of Identify command is 8-Kbyte while the returned data size of SMART command is 512-byte.

Integrated Block for PCI Express

Some UltraScale+ devices and Versal devices have Integrated Block for PCI Express (PCIe hard IP) to operate PCIe Gen4 protocol, called PCIe4C and PL PCIE4. To connect with rmNVMe IP, PCIe4C or PL PCIE4 is configured to be 4-lane PCIe Gen4 by using 256-bit data interface. Each rmNVMe IP uses one PCIe hard IP for controlling one NVMe Gen4 SSD. Therefore, the maximum number of SSDs connecting to one FPGA device is limited by the number of PCIe hard IPs in FPGA device.

The IP wizard on Xilinx tool to generate PCIe hard IP when selecting UltraScale+ and Versal device are different. On UltraScale+ device, the user uses one IP wizard to generate the PCIe hard IP integrating with the transceiver. On Versal device, the user needs to call two IP wizards to generate PCIe hard IP and the Transceiver individually.

More details of PCIe hard IP are described in following document

PG213: UltraScale+ Devices Integrated Block for PCI Express

https://www.xilinx.com/products/intellectual-property/pcie4-ultrascale-plus.html#documentation

PG343: Versal ACAP Integrated Block for PCI Express

https://www.xilinx.com/products/intellectual-property/pcie-versal.html#documentation

Figure 5: PCI4C Integrated Block for PCI Express

Core I/O Signals

Descriptions of all signal I/O are provided in Table 3 – Table 5.

Table 3: Core Parameters

Name

Value

Description

U0CDep

5-8

Command Queue Depth of NVM#0. Valid value is 5 - 8. Command Queue Depth = 2^U0Dep.

5: 32 commands, 6: 64 commands, 7: 128 commands, 8: 256 commands.

U1CDep

5-8

Command Queue Depth of NVM#1. Valid value is 5 - 8. Command Queue Depth = 2^U1Dep.

5: 32 commands, 6: 64 commands, 7: 128 commands, 8: 256 commands.

Table 4: User logic I/O Signals (Synchronous to Clk signal)

Signal	Dir	Description
Control Interface of rmNVMe IP for Gen4
RstB	In	Synchronous reset signal. Active low. De-assert to ‘1’ when Clk signal is stable.
Clk	In	User clock for running rmNVMe IP. The frequency must be more than or equal to PCIeClk which is output from PCIe hard IP (250 MHz for PCIe Gen4).
U0Cmd[2:0]	In	User Command of User#0 I/F. Valid when U0CValid=’1’. 000b: Identify, 001b: Shutdown, 011b: Read SSD, 100b: SMART, 110b: Flush, Others: Reserved Note: User cannot change to run other commands when NVM#0 is busy. User must wait until the current command is finished (U0Busy=’0’).
U0Addr[47:0]	In	Start address of User#0 I/F to read SSD in 512-byte unit. Valid when U0CValid=’1’. This value must be less than LBASize which is the SSD capacity. Note: U0Addr[2:0] is ignored for 4-Kbyte alignment.
U0CValid	In	Command valid. Assert to ‘1’ to send new command to NVM#0. When command is Single mode (Identify, Shutdown, SMART, and Flush), U0CReady is de-asserted to ‘0’ after the user asserts U0CValid. For Read command, user can assert U0CValid for sending the next Read command until U0CReady is de-asserted to ’0’.
U0CReady	Out	Asserted to ‘1’ to indicate that NVM#0 is ready to receive command.
U0Busy	Out	User#0 busy status. Asserted to ‘1’ when NVM#0 is operating command of User#0 I/F.
U0CCnt[8:0]	Out	Remaining count of Read command stored in the Cmd FIFO#0. Valid from 0 to User#0 Command Depth. This signal is ignored for Single-mode command. For example, when User#0 Command Depth = 32, U0CCnt is in range 0 to 32.
U0CId[7:0]	Out	Read Command ID that is fed to Cmd FIFO#0. Valid when U0CValid=’1’. The value is in range 0 to (User#0 Command Depth – 1). It is used to match with U0DId to refer the command number which is currently transferred in Read Data stream interface of User#0 I/F. Also, it is used to match with error ID of U0IOCompStatus[23:16]. This signal is ignored for Single-mode command. For example, when User#0 Command Depth = 32, U0CId is in range 0 to 31.
U1Addr[47:0]	In	Start address of User#1 I/F to Write SSD in 512-byte unit. Valid when U1CValid=’1’. This value must be less than LBASize which is the SSD capacity. Note: U1Addr[2:0] is ignored for 4-Kbyte alignment.
U1CValid	In	Command valid. Asserted to ‘1’ to send new Write command to NVM#1. User can assert U1CValid for sending next Write command until U1CReady is de-asserted to ’0’.
U1CReady	Out	Asserted to ‘1’ to indicate that NVM#1 is ready to receive Write command.
U1Busy	Out	User#1 busy status. Asserted to ‘1’ when NVM#1 is operating Write command of User#1 I/F.

Signal	Dir	Description
Control Interface of rmNVMe IP for Gen4
U1CCnt[8:0]	Out	Remaining count of Write command stored in Cmd FIFO#1. Valid from 0 to User#1 Command Depth. For example, when User#1 Command Depth = 32, U1CCnt is in range 0 to 32.
U1CId[7:0]	Out	Write Command ID that is fed to Cmd FIFO#1. Valid when U1CValid=’1’. The value is in range 0 to (User#1 Command Depth – 1). It is used to match with U1DId to refer the command number which is currently transferred in Write Data stream interface of User#1 I/F. Also, it is used to match with error ID of U1IOCompStatus[23:16]. For example, when User#1 Command Depth = 32, U1CId is in range 0 to 31
LBASize[47:0]	Out	Total capacity of SSD in 512-byte unit and always aligned to 4 KB unit. This value is valid after Identify command is done. So, Identify command must be the first command requested by the user to update LBASize value before running other commands. Default value after boot up is 0.
U0-1Error	Out	Error flag. Asserted to ‘1’ when U0-U1ErrorType is not equal to 0. The flag can be cleared by asserting RstB to ‘0’.
U0ErrorType[31:0]	Out	[0] – Error when PCIe class code is not correct. [1] – Error from CAP (Controller capabilities) register which may be caused from - MPSMIN (Memory Page Size Minimum) is not equal to 0. - NVM command set flag (bit 37 of CAP register) is not set to 1. - DSTRD (Doorbell Stride) is not 0. - MQES (Maximum Queue Entries Supported) is less than (2 x User#0 Command Depth - 1) or (2 x User#1 Command Depth - 1). More details of each register can be checked from NVMeCAPReg signal [2] – Error when Admin completion entry is not received until timeout. [3] – Error when status register in Admin completion entry is not 0 or phase tag/command ID is invalid. Please see more details from U0AdmCompStatus signal. [4] – Error when IO completion entry of NVM#0 is not received until timeout. [5] – Error when status register in IO completion entry of NVM#0 is not 0 or phase tag is invalid. Please see more details from U0IOCompStatus signal. [6] – Error from unsupported LBA unit (LBA unit is not equal to 512-byte). [7] – Error when the number of queues that SSD supports is less than 2. [8] – Error when receiving TLP packet with incorrect size [9] – Error when PCIe hard IP detects Error correction code (ECC) error from the internal buffer Bit[15:10] are mapped to Uncorrectable Error Status Register [10] – Mapped to Unsupported Request Error Status (bit[20]) [11] – Mapped to Completer Abort Status (bit[15]) [12] – Mapped to Unexpected Completion Status (bit[16]) [13] – Mapped to Completion Timeout Status (bit[14]) [14] – Mapped to Poisoned TLP Received Status (bit[12]) [15] – Mapped to ECRC Error Status (bit[19]) [23:16] - Reserved Bit[30:24] are also mapped to Uncorrectable Error Status Register [24] – Mapped to Data Link Protocol Error Status (bit[4]) [25] – Mapped to Surprise Down Error Status (bit[5]) [26] – Mapped to Receiver Overflow Status (bit[17]) [27] – Mapped to Flow Control Protocol Error Status (bit[13]) [28] – Mapped to Uncorrectable Internal Error Status (bit[22]) [29] – Mapped to Malformed TLP Status (bit[18])

Signal	Dir		Description
Control Interface of rmNVMe IP for Gen4
U0ErrorType[31:0]	Out		[30] – Mapped to ACS Violation Status (bit[21]) [31] – Reserved Note: Timeout period of bit[4] is set from TimeOutSet input.
U1ErrorType[31:0]	Out		[3:0] – Reserved [4] – Error when IO completion entry of NVM#1 is not received until timeout. [5] – Error when status register in IO completion entry of NVM#1 is not 0 or phase tag is invalid. Please see more details from U1IOCompStatus signal. [31:6] – Reserved Note: Timeout period of bit[4] is set from TimeOutSet input.
Data Stream Interface of rmNVMe IP for Gen4
U0DId[7:0]	Out		Show User#0 Command ID (U0CId) which currently transfers data on Read Data stream interface while operating Read commands. Valid when U0RdValid=’1’. The value is in range 0 to (User#0 Command Depth – 1).
U0RdData[255:0]	Out		User#0 Read data from SSD returned in Read command. Valid when U0RdValid =’1’.
U0RdValid	Out		User#0 Read data valid that is asserted to ‘1’ to transfer U0RdData. The user can pause transmission by asserting U0RdPause to ‘1’. After that, U0RdValid is de-asserted to ‘0’ within 4 clock cycles.
U0RdPause	In		Asserted to ‘1’ to pause U0RdData transmission by de-asserting U0RdValid to ‘0’ within 4 clock cycles.
U1DId[7:0]	Out		Show User#1 Command ID (U0CId) which currently transfers data on Write Data stream interface while operating Write commands. Valid when U1WrValid=’1’. The value is in range 0 to (User#1 Command Depth – 1).
U1WrData[255:0]	In		Write data to SSD in User#1 I/F. Valid when U1WrValid=’1’.
U1WrValid	In		Asserted to ‘1’ to write data to NVM#1 for Write command. Write data can be transferred before sending Write command (U1CValid).
U1WrReady	Out		Asserted to ‘1’ when NVM#1 accepts the write data (U1WrData).
U1WrCnt[15:0]	Out		Total data count of Write data stored in Data Buffer#1 in 256-bit unit. The value is in range 0 to 128 x (User#1 Command Depth).
rmNVMe IP for Gen4 Interface
IPVesion[31:0]	Out	IP version number
U0TestPin[47:0], U1TestPin[15:0]	Out	Reserved to be IP Test point.
TimeOutSet[31:0]	In	Timeout value to wait completion from SSD. Time unit is equal to 1/(Clk frequency). When TimeOutSet is set to 0, Timeout is disabled.
U0AdmCompStatus[15:0]	Out	Status output from Admin Completion Entry [0] – Set to ‘1’ when Phase tag or Command ID in Admin Completion Entry is invalid. [15:1] – Status field value of Admin Completion Entry
U0IOCompStatus[31:0]	Out	Status output from IO Completion Entry [0] – Set to ‘1’ when Phase tag in IO Completion Entry in NVM#0 is invalid. [15:1] – Status field value of IO Completion Entry in NVM#0 is invalid. [23:16] – Command ID of IO Completion Entry in NVM#0, referred to U0CId [31:24] – Reserved

Signal		Dir			Description
rmNVMe IP for Gen4 Interface
U1IOCompStatus[31:0]		Out		Status output from IO Completion Entry [0] – Set to ‘1’ when Phase tag in IO Completion Entry in NVM#1 is invalid. [15:1] – Status field value of IO Completion Entry in NVM#1 is invalid. [23:16] – Command ID of IO Completion Entry in NVM#1, referred to U1CId [31: 24] – Reserved
NVMeCAPReg[31:0]		Out		The parameter value of the NVMe capability register when U0ErrorType[1] is asserted to ‘1’. [15:0] – MQES (Maximum Queue Entries Supported) [19:16] – DSTRD (Doorbell Stride) [20] – NVM command set flag [24:21] – MPSMIN (Memory Page Size Minimum) [31:25] – Undefined
Identify Interface (for User#0)
IdenWrEn		Out		Asserted to ‘1’ for sending data output from Identify command.
IdenWrDWEn[7:0]		Out		Dword (32-bit) enable of IdenWrData. Valid when IdenWrEn=’1’. ‘1’: This Dword data is valid, ‘0’: This Dword data is not available. Bit[0], [1], …, [7] corresponds to IdenWrData[31:0], [63:32], .., [255:224], respectively.
IdenWrAddr[7:0]		Out		Index of IdenWrData in 256-bit unit. Valid when IdenWrEn=’1’. Bit[7]=’0’: 0x00-0x7F is 4Kbyte Identify controller data, Bit[7]=’1’: 0x80-0xFF is 4Kbyte Identify namespace data.
IdenWrData[255:0]		Out		4Kbyte Identify controller data or Identify namespace data. Valid when IdenWrEn=’1’.
Custom interface (for User#0)
CtmSubmDW0[31:0] – CtmSubmDW15[31:0]	In		16 Dwords of Submission queue entry for SMART/Flush command. DW0: Command Dword0, DW1: Command Dword1, …, and DW15: Command Dword15. Valid when U0CValid=’1’ and U0Cmd=100b (SMART) or 110b (Flush).
CtmCompDW0[31:0] – CtmCompDW3[31:0]	Out		4 Dwords of Completion queue entry output from SMART/Flush command. DW0: Completion Dword0, DW1: Completion Dword1, …, and DW3: Completion Dword3
CtmRamWrEn	Out		Asserted to ‘1’ for sending data output from Custom command such as SMART command.
CtmRamWrDWEn[7:0]	Out		Dword (32-bit) enable of CtmRamWrData. Valid when CtmRamWrEn=’1’. ‘1’: this dword data is valid, ‘0’: this dword data is not available. Bit[0], [1], [2], …, [7] correspond to CtmRamWrData[31:0], [63:32], …, [255:224], respectively.
CtmRamAddr[7:0]	Out		Index of CtmRamWrData when SMART data is received. Valid when CtmRamWrEn=’1’. (Optional) Index to request data input from CtmRamRdData for customized Custom commands.
CtmRamWrData[255:0]	Out		512-byte data output from SMART command. Valid when CtmRamWrEn=’1’.
CtmRamRdData[255:0]	In		(Optional) Data input for customized Custom commands.

Table 5: Physical I/O Signals for PCIe Gen4 Hard IP (Synchronous to PCIeClk)

Signal	Dir	Description
PCIe Gen4 hard IP
PCIeRstB	In	Synchronous reset signal. Active low. De-asserted to ‘1’ when PCIe hard IP is not in reset state.
PCIeClk	In	Clock output from PCIe hard IP (250 MHz for PCIe Gen4).
PCIeLinkup	In	Asserted to ‘1’ when PCIe hard IP is linked up.

Signal	Dir	Description
Configuration Management Interface
PCIeCfgDone	In	Read/Write operation complete. Assert for 1 cycle when the operation completes.
PCIeCfgRdEn	Out	Read enable. Asserted to ‘1’ for a read operation.
PCIeCfgRdData[31:0]	In	Read data. Valid when PCIeCfgDone is asserted to ‘1’.
PCIeCfgWrEn	Out	Write enable. Asserted to ‘1’ for a write operation.
PCIeCfgWrData[31:0]	Out	Write data which is used to configure the Configuration and Management registers.
PCIeCfgByteEn[3:0]	Out	Byte enable for write data, where bit[0],[1],[2], and [3] corresponds to PCIeCfgWrData[7:0], [15:8], [23:16], and [31:24] respectively
PCIeCfgAddr[9:0]	Out	Read/Write Address.
Requester Request Interface
PCIeMtTxData[255:0]	Out	Requester request data bus.
PCIeMtTxKeep[7:0]	Out	Bit [i] indicates that Dword [i] of PCIeMtTxData contains valid data; i=0-7.
PCIeMtTxLast	Out	Asserted this signal in the last cycle of a TLP to indicate the end of the packet.
PCIeMtTxReady[3:0]	In	Assert to accept data. Data is transferred when both PCIeMtTxValid and PCIeMtTxReady are asserted in the same cycle.
PCIeMtTxUser[61:0]	Out	Requester request user data. Valid when PCIeMtTxValid is high.
PCIeMtTxValid	Out	Asserted to drive valid data on PCIeMtTxData bus. rmNVMe IP keeps the valid signal asserted during the transfer of packet.
Completer Request Interface
PCIeMtRxData[255:0]	In	Received data from PCIe hard IP.
PCIeMtRxKeep[7:0]	In	Bit [i] indicates that Dword [i] of PCIeMtRxData contains valid data; i=0-7.
PCIeMtRxLast	In	Assert this signal in the last beat of a packet to indicate the end of the packet.
PCIeMtRxReady	Out	Indicates that rmNVMe IP is ready to accept data.
PCIeMtRxUser[74:0]	In	Sideband information for the TLP being transferred. Valid when PCIeMtRxValid is high.
PCIeMtRxValid	In	Assert when PCIe hard IP drives valid data on PCIeMtRxData bus. PCIe hard IP keeps the valid signal asserted during the transfer of packet.
Completer Completion Interface
PCIeSlTxData[255:0]	Out	Completion data from rmNVMe IP.
PCIeSlTxKeep[7:0]	Out	Bit [i] indicates that Dword [i] of PCIeSlTxData contains valid data; i=0-7.
PCIeSlTxLast	Out	Asserted this signal in the last cycle of a packet to indicate the end of the packet.
PCIeSlTxReady[3:0]	In	Indicates that PCIe hard IP is ready to accept data.
PCIeSlTxUser[32:0]	Out	Sideband information for the TLP being transferred. Valid when PCIeSlTxValid is high.
PCIeSlTxValid	Out	Asserted to drive valid data on PCIeSlTxData bus. rmNVMe IP keeps the valid signal asserted during the transfer of a packet.
Requester Completion Interface
PCIeSlRxData[255:0]	In	Received data from PCIe hard IP.
PCIeSlRxKeep[7:0]	In	Bit [i] indicates that Dword [i] of PCIeSlRxData contains valid data; i=0-7.
PCIeSlRxLast	In	Assert this signal in the last beat of a packet to indicate the end of the packet.
PCIeSlRxReady	Out	Indicates that rmNVMe IP is ready to accept data.
PCIeSlRxUser[87:0]	In	Sideband information for the TLP being transferred. Valid when PCIeSlRxValid is high.
PCIeSlRxValid	In	Assert when PCIe hard IP drives valid data on PCIeSlRxData bus. PCIe hard IP keeps the valid signal asserted during the transfer of packet.

Timing Diagram

Initialization

Figure 6: Timing diagram during initialization process

The step of the initialization process is as follows.

1) Wait until Clk is stable and then de-asserts RstB to ‘1’ to start IP initialization.

2) PCIe hard IP de-asserts PCIeRstB to ‘1’ after finishing PCIe reset sequence. PCIe hard IP is ready to transfer data with the application layer.

3) PCIe hard IP asserts PCIeLinkup to ‘1’ after LTSSM state of PCIe hard IP is L0 state. After that, rmNVMe IP starts initialization process.

4) After finishing the initialization process, rmNVMe IP de-asserts U0Busy and U1Busy to ‘0’. Also, U0CReady and U1CReady are asserted to ‘1’ for receiving the new command from user.

After finishing above sequences, rmNVMe IP is ready to receive the command from user.

Control interface (Single mode)

rmNVMe IP supports two command types – Single mode and Multiple mode. The Single-mode command is supported by User#0 I/F only because User#1 I/F supports only Write command which is Multiple-mode command. The Single-mode command can be requested when NVM#0 is Idle (U0Busy=’0’ and U0CReady=’1’). After that, User#0 I/F cannot receive the new command request until the requested Single-mode command operation is done.

Figure 7: Single-mode command timing diagram

Figure 7 shows timing diagram when running Single-mode command (Identify, Shutdown, SMART, and Flush) in NVM#0.

1) Before sending the new command to the NVM#0, user must check U0Busy=’0’ and U0CReady=’1’ to confirm that NVM#0 of rmNVMe IP is Idle. After that, assert U0CValid to ‘1’ for one clock cycle along with valid U0Cmd and the parameters which depend on the command.

Note: For SMART and Flush command, the parameters are CtmSubmDW0-DW15.

For Identify and Shutdown command, no parameter is required.

2) NVM#0 asserts U0Busy to ‘1’ after receiving the new command request and starts the command operation. Also, U0CReady is de-asserted to ‘0’ to block the new command request.

3) After finishing command operation, U0Busy is de-asserted to ‘0’ and U0CReady is re-asserted to ‘1’. However, U0Busy is de-asserted to ‘0’ but U0CReady is de-asserted to ‘0’ when Shutdown is completely operated. No more command can be requrested from the user.

Note: In case of Single-mode command, U0Busy is de-asserted to ‘0’ after U0CReady is asserted for 1 clock cycle to show the command operation is done. User can send new command after de-assertion of U0Busy.

Control interface (Multiple mode)

There are two Multiple-mode commands that can be requested by the user, i.e., Read command by User#0 I/F and Write command by User#1 I/F. Comparing to Single-mode command, the user can send more command requests by asserting U0CValid/U1CVaild to ‘1’ if U0CReady/U1CReady is asserted to ‘1’. It does not need to wait until U0Busy/U1Busy is de-asserted to ‘0’, like Single-mode command. The maximum number of Read command and Write command can be configured individually by U0CDep and U1CDep. The details of Control interface for sending the command are described as follows.

Figure 8: Multiple-mode command timing diagram by User#0 I/F

Since the timing diagram to send Read command request on User#0 I/F and Write command request on User#1 I/F are similar, Figure 8 shows timing diagram of User#0 I/F when NVM#0 of rmNVMe IP running Read command (Multiple-mode command) with assigning U0CDep = 5 (maximum 32 commands).

1) If the previous command is not Read command, user must confirm that NVM#0 is Idle (U0Busy=’0’) and Cmd FIFO#0 is ready (U0CReady=’1’). Next, send Read command (U0Cmd=011b) to NVM#0 by asserting U0CValid to ‘1’ for one clock cycle along with the valid U0Addr.

2) NVM#0 starts the command operation with asserting U0Busy to ‘1’. Meanwhile, U0CCnt and U0CId are up-counted for indicating the number of commands in Cmd FIFO#0 and the next command ID, respectively.

3) As long as Cmd FIFO#0 is not full (U0CCnt is less than 32 or U0CReady=’1’), user can request Read command with the new address value. U0Cmd must be always set to Read command when asserting U0CValid to ’1’ but the NVM#0 is busy (U0Busy=’1’). The wrong operation will be happened if user assigns different value of U0Cmd while U0Busy=’1’.

4) After Cmd FIFO#0 is full (U0CCnt = User#0 Command Depth), U0CReady is de-asserted to ‘0’. NVM#0 does not accept more command request from the user. All inputs for the new command request need to hold the same value until U0CReady is re-asserted again.

5) After some Read commands are done, Cmd FIFO#0 is not full (U0CCnt < User#0 Command Depth) and U0CReady is re-asserted. If the new command is still requested, it will be accepted by NVM#0.

6) When NVM#0 of rmNVMe IP finishes all of the command request, U0Busy is de-asserted to ‘0’. NVM#0 returns back to the Idle status. Now NVM#0 is ready to receive the new command which can be Single-mode command.

Note: User#1 I/F supports only Write command, so there is no U1Cmd input signal for requesting the Write command to NVM#1.

Control interface (Parallel command)

Figure 9: Control interface when running command parallelly

Figure 9 shows Control interfaces of two user interfaces when NVM#0 and NVM#1 operate the command parallelly. Both User#0 I/F and User#1 I/F have particular control signals to operate user command. Thus, Identify, SMART, Flush, and Read command in NVM#0 can be operated parallelly with Write command in NVM#1. However, Shutdown command is an exemption for this parallel mode.

Read Data stream interface

Read Data stream interface of rmNVMe IP is available in User#0 I/F for transferring data of Read command. The control signals of Read Data stream interface are valid and pause signal.

Figure 10: Read Data stream interface

1) After NVM#0 receives the 4 KB data of the current command ID from SSD, it forwards the 4 KB data to the user by asserting U0RdValid to ‘1’ along with valid U0RdData. To transfer 4 KB data, U0RdValid is asserted to ‘1’ for 128 clock cycles continuously if U0RdPause is always de-asserted to ‘0’.

2) After finishing transferring each 4 KB data, U0DId is up-counted to show the command ID of the next 4 KB data that will be transferred.

Note: When the Command Depth = 32, U0DId is in range 0 to 31.

3) The next 4 KB data is transferred after the SSD returns the 4KB data, similar to step 1).

4) When user is not ready to receive read data, user can assert U0RdPause to ‘1’. After that, NVM#0 pauses transferring data by de-asserting U0RdValid to ‘0’ within 4 clock cycles.

5) When user is ready to receive read data by de-asserting U0RdPause to ‘0’, NVM#0 re-asserts U0RdValid to ‘1’ within 4 clock cycles to continue transferring the data.

Write Data stream interface

Similar to Read command, Write Data stream interface in User#1 I/F for transferring data of Write command operates independently from Control interface. User can prepare Write data into Data Buffer#1 before or after sending Write command request. Figure 11 shows timing diagram in Write command which configures User#1 Command Depth to 5 (Maximum 32 commands).

Figure 11: Write Data stream interface

1) User confirm that NVM#1 is ready to receive data by monitoring U1WrReady=’1’ or U1WrCnt < 128xUser#1 Command Depth (4096). After that, user asserts U1WrValid along with valid U1WrData to transfer 256-bit data. There are two status signals to be flow control signals for Write command - U1WrReady and U1WrCnt. U1WrCnt is recommended for burst data transferring while U1WrReady is applied for non-burst data transferring.

2) After finishing 4K-byte data (data size of each Write command), U1DId is up-counted to show the command ID of the next 4K-byte data transferred on the Write Data stream interface (U1WrData).

3) When the user is not ready to send data, U1WrValid can be de-asserted to ‘0’ to pause transferring data.

4) When the Data Buffer#1 is full (U1WrCnt is equal to 128xUser#1Command Depth or 4096), U1WrReady is de-asserted to ‘0’. Therefore, NVM#1 cannot accept the new data from the user. U1WrData and U1WrValid must hold the same value until U1WrReady is re-asserted to ‘1’.

5) If the previous Write command is complete, the Data Buffer gets 4 KB free space. After that, U1WrCnt is decreased by 4 KB and U1WrReady is re-asserted to ‘1’. The data for the next command can be accepted by NVM#1.

Data stream interface (Parallel data)

Figure 12: Data stream interface when transferring Read and Write parallelly

Similar to Control interface, Read Data stream interface for NVM#0 and Write Data stream interface for NVM#1 operate independently. Thus, as shown in Figure 12, Read data can be returned from NVM#0 while user sends Write data to NVM#1 parallelly.

IdenCtrl/IdenName

It is recommended to send Identify command to the IP as the first command after system boots up. This command updates total capacity (LBASize) which is the necessary information of SSD for calculating the valid range of the address (U0-1Addr) in Read or Write command. U0Addr/U1Addr in Read/Write command must be less than LBASize of the SSD.

Figure 13: Identify command timing diagram

The details when running Identify command are shown as follows.

1) Send the request of Identify command to NVM#0 of the IP (U0Cmd=000b and U0CValid=’1’).

2) The IP asserts U0Busy to ‘1’ after running the command. Meanwhile, U0CReady is de-asserted to ‘0’ to ignore the new command request from the user until the current command is completed.

3) 4096-byte Identify controller data is returned to user. IdenWrAddr is equal to 0-127 with asserting IdenWrEn. IdenWrData, and IdenWrDWEn are valid at the same clock as IdenWrEn=’1’.

4) Similar to Identify controller data, 4096-byte Identify namespace data is returned but IdenWrAddr is equal to 128-255. IdenWrAddr[7] can be applied to check the data type which is Identify controller data or Identify namespace data.

5) After finishing the Identify command operation, U0Busy is de-asserted to ‘0’ along with valid LBASize. Also, U0CReady is re-asserted to ‘1’ to receive the new command from the user.

Note: U0Busy is de-asserted to ‘0’ after U0CReady is asserted for 1 clock cycle to show the operation is complete.

Figure 14: IdenWrDWEn timing diagram

IdenWrDWEn is 8-bit signal to be valid signal of 32-bit data. Some SSDs do not return 4K-byte Identify controller data and Identify namespace data continuously, but it returns only one Dword (32-bit) at a time. Therefore, one bit of IdenWrDWEn is asserted to ‘1’ in the write cycle to write 32-bit data, as shown in Figure 14. IdenWrDWEn[0], [1], …, [7] corresponds to IdenWrData[31:0], [63:32], …, [255:224], respectively.

Shutdown

Shutdown command is recommended to send as the last command before the system is powered down. When Shutdown command is issued, SSD flushes the data from the internal cache to flash memory. After Shutdown command is done, rmNVMe IP and SSD are inactive until the system is powered down.

Note: If the SSD is powered down without Shutdown command, the total count of unsafe shutdowns (returned data of SMART command) is increased.

Figure 15: Shutdown command timing diagram

The details when running Shutdown command is shown as follows.

1) Before sending the Shutdown command request, both NVM#0 and NVM#1 must be Idle state (U0Busy=’0’, U1Busy=’0’, and U0CReady=’1’). To send Shutdown command, user asserts U0CValid to ‘1’ with U0Cmd =001b.

2) After Shutdown command is received, U0Busy is asserted to ‘1’ and both U0CReady and are de-asserted to ‘0’.

3) After Shutdown command operation is done, U0Busy is de-asserted to ‘0’. However, U0CReady and U1CReady are still equal to ‘0’ because the IP does not receive any command afterwards.

SMART

SMART command is the command to check the SSD health. After sending SMART command, 512-byte health information is returned from the SSD. SMART command loads the parameters from CtmSubmDW0-DW15 signals on Custom command interface. User sets 16-Dword data as constant value for SMART command. After that, the SMART data is returned via CtmRAM port as shown in Figure 16.

Figure 16: SMART command timing diagram

The details when running SMART command is shown as follows.

1) Before sending the command request, NVM#0 of the IP must be ready to receive command (U0Busy=’0’ and U0CReady=’1’). Then, asserts U0CValid with U0Cmd=100b and valid CtmSubmDW0-DW15 which must be set by following value for SMART command.

CtmSubmDW0 = 0x0000_0002

CtmSubmDW1 = 0xFFFF_FFFF

CtmSubmDW2 – CtmSubmDW5 = 0x0000_0000

CtmSubmDW6 = 0x2000_0000

CtmSubmDW7 – CtmSubmDW9 = 0x0000_0000

CtmSubmDW10 = 0x007F_0002

CtmSubmDW11 – CtmSubmDW15 = 0x0000_0000

2) NVM#0 accepts SMART command by asserting U0Busy to ‘1’ and de-asserting U0CReady to ‘0’.

3) 512-byte SMART data is returned on CtmRamWrData signal with asserting CtmRamWrEn to ‘1’. CtmRamAddr is equal to 0-31 to be data index of 512-byte data. When CtmRamAddr=0, byte0-15 of SMART data is valid on CtmRamWrData. CtmRamWrDWEn is Dword enable for each 32-bit CtmRamWrData. If CtmRamWrDWEn=FFh, all 256-bit of CtmRamWrData are valid.

4) After SMART command operation is finished, U0Busy is de-asserted to ‘0’ and U0CReady is asserted to ‘1’ to receive the next command.

Note: U0Busy is de-asserted to ‘0’ after U0CReady is asserted for 1 clock cycle to show the operation is complete.

Figure 17: CtmRamWrDWEn timing diagram

Similar to Identify command, some SSDs do not return 512-byte data continuously but returns only one Dword (32-bit) at a time. Therefore, one bit of CtmRamWrDWEn is asserted to ‘1’ in the write cycle to be the valid signal of 32-bit CtmRamWrData. CtmRamWrDWEn[0], [1], …, [7] corresponds to CtmRamWrData[31:0], [63:32], …, [255:224], respectively.

Flush

Most SSDs accelerate write performance by storing write data to cache before flushing to the flash memory by the SSD controller. If power is down unexpectedly, the data in the cache may be lost and not stored the flash memory. Flush command is the command to force the SSD controller to flush data from the cache. After sending Flush command, all data in previous Write command can be guaranteed.

Figure 18: Flush command timing diagram

The details for running Flush command are shown as follows.

CtmSubmDW0 = 0x0000_0000

CtmSubmDW1 = 0x0000_0001

CtmSubmDW2 – CtmSubmDW15 = 0x0000_0000

2) NVM#0 accepts Flush command by asserting U0Busy to ‘1’ and de-asserting U0CReady to ‘0’.

3) After finishing Flush command operation, U0Busy is de-asserted to ‘0’ and U0CReady is asserted to ‘1’ to receive the next command.

Note: U0Busy is de-asserted to ‘0’ after U0CReady is asserted for 1 clock cycle to show the operation is complete.

Error

Figure 19: Error flag timing diagram

When the error is found while running initialization process or operating some commands, U0Error or U1Error flag is asserted to ‘1’. U0/U1ErrorType is read to check the occurred error type. For User#0 I/F, NVMeCAPReg, U0AdmCompStatus, and U0IOCompStatus are valid for monitoring error details after U0Error is asserted to ‘1’. Similarly, U1IOCompStatus is valid for monitoring error details on User#1 I/F after U1Error is asserted to ‘1’.

When the error is found while running initialization process, it is recommended to read NVMeCAPReg to check capability of NVMe SSD. When the error is found while operating the command, it is recommended to read U0AdmCompStatus or U0/U1IOCompStatus.

When bit[3] of U0ErrorType is asserted, read U0AdmCompStatus to check more details.
When bit[5] of U0/U1ErrorType is asserted, read U0/U1IOCompStatus to check more details.

U0Error and U1Error flag are cleared by RstB signal only. After the failure is solved, RstB is asserted to ‘0’ to clear the error flags.

Verification Methods

The rmNVMe IP Core for Gen4 functionality was verified by simulation and also proved on real board design by using VCK190 evaluation board.

Recommended Design Experience

Experience design engineers with a knowledge of Vivado Tools should easily integrate this IP into their design.

Ordering Information

This product is available directly from Design Gateway Co., Ltd. Please contact Design Gateway Co., Ltd. For pricing and additional information about this product using the contact information on the front page of this datasheet.

Revision History

Revision	Date	Description
1.0	3-Feb-2023	Initial Release