Conceptual render: an FPGA board beside an NVMe SSD, with a holographic drive outline above it.

Example project · UC 08

Break your storage stack on purpose.

An example project that presents a configurable NVMe device to the host, backed by DDR4, with controlled delays and error responses for testing how storage software recovers.

Conceptual illustration

The problem

Real SSDs rarely fail on cue.

Storage software has to handle slow commands, timeouts and error responses correctly, but reproducing those conditions with real drives is slow and unreliable. A programmable NVMe target lets you create each fault deliberately and watch how the host responds.

OutcomeA configurable NVMe target with delay and error injection and a command event log.
TargetKCU116 in the Remote FPGA Lab, or any AMD board with PCIe and DDR4

The prompt

The simple prompt
Build an NVMe device emulator to test my storage software. Present a configurable DDR4-backed namespace, introduce controlled command delays and selected error responses, and log how the host handles timeouts and recovery.

An example request. Compatibility and availability are confirmed for each selected configuration.

ArchitectureConceptual

A simple conceptual architecture.

Programmable NVMe Device EmulatorConceptual block diagram · not a delivered netlist
ExternalReusable IPGenerated logic
Good to know. DDR4 is volatile, so namespace contents are lost at power-off. This is a test target, not a persistent SSD.

IP needed

What SIGPT would assemble.

Selected from 140+ 3rd-party FPGA-proven IPs.

PCIe & high-speed connectivityPCIe controller IP
NVMe & storageNVMe device controller IP
DDR memory interfacesDDR4 controller IP as namespace store
Generated logicDelay and error injector, namespace configuration, command log

Validation steps

How it would be proven on hardware.

Board validation is its own milestone, separate from bitfile generation. Any results are measured on your setup, and none are shown here.

No board? Use the Remote FPGA Lab. Ask for a custom lab setup with the interfaces this design needs, or prove the core logic on a bare lab board, available 24/7 from $5/hr, then license it for FPGA production or take the ASIC path. Remote Lab →
  1. Install the board in the host and program the bitfile.
  2. Confirm the host discovers the NVMe device and namespace.
  3. Enable selected command delays and error responses.
  4. Review the command log for host timeouts, retries and recovery.
  5. Compare behaviour with the agreed test plan.

Start from this prompt. Make it yours.

We’ll prefill your request with this use case. Edit it to match your requirements.