A custom PCIe Gen4 x16 controller,
in seven agent-days.
On an FPGA whose built-in PCIe controller stops at Gen3, Melten’s agents built a custom Gen4 x16 controller. An encrypted NVMe drive demonstrates it: 28.4 GB/s reads with 128 KiB transfers, and Linux boot on a standard PC. The campaign took about seven days of agent time.
For customers, this demonstrates custom interfaces beyond the FPGA’s built-in controller, with application-specific functions integrated into the data path. The campaign extended Melten’s existing NVMe design and added PCIe, encryption and search IP as building blocks for future customer projects.
- 28.4 GB/s
- Encrypted sequential reads, using 128 KiB transfers
- 98.8%
- Of the modeled Gen4 x16 payload ceiling for those encrypted reads
- 34.6 GB/s
- Search across 512 GiB of unencrypted data, performed inside the drive
- 7.3 days
- Of agent time, from campaign start to independent closure of all seven outcomes
The result in brief
Whole new PCIe controller.
A custom PCIe controller and 16-lane digital PHY control, using the FPGA’s existing GTY transceivers. It held 16 GT/s on all 16 lanes in every judged session.
Fully encrypted NVMe.
Inline XTS-AES-256 delivered 28.4 GB/s with 128 KiB sequential reads and 4.49 million 4 KiB random reads per second.
High-performance on-drive search engine.
Four engines, one beside each memory channel, scan all 512 GiB of unencrypted data at 34.6 GB/s and return only the matches. The host reads nothing.
Boots Linux from our drive.
A standard PC’s firmware found the drive at Gen4 x16 and booted Linux from its encrypted contents.
The whole drive in one FPGA design,
from the PCIe lanes to the memory.
We set the goal high: a drive that fills a full PCIe Gen4 x16 link with every block encrypted. Melten’s agents wrote every block in walnut below.
Host PC
A standard desktop PC. Its UEFI firmware and Linux see an ordinary NVMe drive.
16 transceivers
Existing AMD GTY SerDes hardware, configured in PCIe mode at up to 16 GT/s.
16-lane digital PHY control
Power-up and resets, rate changes from 2.5 to 16 GT/s, lane alignment and clocking.
PCIe controller
Every protocol layer above the PHY, on a 1024-bit, 250 MHz datapath.
NVMe controller
Melten’s NVMe controller from an earlier campaign, widened from 512 to 1024 bits, with new commands for encryption keys and search. Its DMA engines are open source.
Inline XTS-AES-256
Eight AES pipelines per direction encrypt every block between the host and the memory.
4 DDR4 channels
512 GiB of storage, behind the FPGA’s memory controllers.
4 search engines
One beside each memory channel, scanning in parallel.
The design spans the chip’s three dies. The PHY sits beside the transceivers, the rest of the PCIe controller on the next die, and encryption on the third.
The chip’s built-in PCIe stops at Gen3,
so the agents built their own Gen4 x16 controller.
The built-in PCIe controller is limited to Gen3, but the FPGA’s existing GTY transceivers can operate at Gen4’s 16 GT/s. The agents reused that physical hardware and implemented the PCIe controller and digital PHY control in programmable logic.
AMD’s standard PHY IP supports Gen4 only up to eight lanes. The custom digital control handles resets, rate changes, lane alignment and clocking across sixteen lanes, alongside the controller’s link training and equalization.2
BittWare specifies the XUP-P3R’s host interface as Gen3 x16. The Gen4 x16 link here is our controller’s result, demonstrated on the tested board and PC.2
Controller layers, implementation and checks
| Layer | What it does | RTL | How it was proven |
|---|---|---|---|
| 16-lane digital PHY control | Drives the existing GTY transceivers in PCIe mode: power-up and reset sequencing, rate changes from 2.5 to 16 GT/s, lane alignment and clocking | 3,733 lines | The first Gen4 x16 link, a 4-hour soak with zero errors, and every judged session at 16.0 GT/s x16 |
| Logical PHY and link training | Lane de-skew, scrambling and framing; link training with equalization in all four phases at 8 and 16 GT/s; recovery | 5,141 lines | Every equalization phase, timeout and fallback in simulation; equalization reported complete by the PC’s root port |
| Data link layer | Acknowledgements, replay of lost or corrupted packets, and flow-control credits, including PCIe 4.0’s scaled credits | 2,249 lines | Injected corrupted and cut packets, replay-timer expiries, sequence rollover and credit stalls |
| Transaction layer | Requests and completions, 10-bit tags, completion timeouts, error responses, function reset | 1,411 lines | Error and timeout cases in simulation; 28.36 GB/s on the board |
| Configuration space | What firmware and the OS look for: power management, MSI-X, PCIe, AER, the 16 GT/s physical layer, lane margining | 426 lines | Enumerated by the PC’s UEFI firmware and Linux at 16.0 GT/s x16 |
| Core and clocking | Joins the layers on a 1024-bit, 250 MHz user clock that holds through every rate change | 1,431 lines | The same board sessions |
Line counts are the final image’s controller and digital PHY sources, without generated tables. AMD’s transceiver wizard configures the existing hard GTY SerDes; the agents wrote the controller and digital control around them.
Twice the bandwidth, with no loss of efficiency
On the same FPGA, the same NVMe design ran earlier on the FPGA’s built-in Gen3 x16 PCIe block, AMD’s hardened IP. Our controller runs the link at twice the rate and turns the same share of it into drive reads, so read bandwidth doubles. Single-I/O read latency is 6.24 µs on both, ours with encryption added.
Cross-checked against another implementation.
The controller was tested against a separately written root-port model in simulation, then against a real PC. The simulation model implements its own physical layer, link training, equalization and data link layer.
Reusable IP,
for the next customer design.
The campaign added interface, encryption, search and verification blocks to Melten’s IP, while extending its existing NVMe controller. These provide building blocks for future projects, with the demonstrated scope shown below.
| IP block | What it enables | Demonstrated scope |
|---|---|---|
| PCIe Gen4 x16 controller | A custom host interface beyond the FPGA’s built-in Gen3 controller | Gen4 x16 operation with a real PC, carrying encrypted NVMe reads at 28.36 GB/s |
| 16-lane digital PHY control | Use of the existing GTY transceivers across sixteen lanes, with rate changes, resets, alignment and clocking | 16 GT/s x16 on the tested UltraScale+ board; a four-hour link-only soak before drive integration |
| PCIe root-port model | A simulation counterpart for controller development and regression testing | Link training, equalization and data-link behavior exercised in controller simulations |
| Inline XTS-AES-256 engine | Encryption integrated into the storage data path | Standards test vectors in simulation and a cross-check against Linux XTS-AES on the board |
| On-drive search engine | Exact and masked pattern searches near the data, returning matches to the host | 1–32-byte patterns on unencrypted data; 34.6 GB/s across 512 GiB, with results checked against software |
| NVMe controller, extended | Reuse of Melten’s storage controller, widened to 1024 bits with encryption-key and search commands | UEFI discovery, Linux I/O and encrypted boot on a standard PC |
A board failure,
diagnosed and resolved.
The agents carried the design through a failure that appeared on real hardware, reproduced its cause, and verified the repair.
From failed writes to a verified repair.
The first drive image failed writes on the board. The agents reproduced the failure that afternoon in simulation of the routed netlist and traced a synthesis/simulation divergence to a per-slot status array. They changed the implementation, added a netlist check to signoff, and verified full-capacity writes with zero errors on the repaired image.
How we know it works.
Recorded board sessions and simulation runs checked the complete system, with each result tied to the image and design it tested.
Encrypted boot and recovery.
A standard PC’s UEFI firmware booted Linux from the encrypted drive at Gen4 x16. The link recovered and the drive verified after the tested warm reboot, cold power cycle, controller reset, function reset and hot reset.
Gen4 x16 through the tests.
A four-hour link-only soak completed with zero errors or retraining before drive integration. Later judged board sessions recorded zero uncorrectable errors at both ends; a 1.4-hour full-load interval also recorded zero correctable errors.
Cross-checked results.
Full-capacity writes and readback were verified across four tested access sizes. Encryption was checked against NIST and IEEE test vectors in simulation and against the Linux kernel’s XTS-AES implementation on the board.
98.8% of the modeled read ceiling,
with encryption on.
Judged board sessions on the acceptance image, against targets frozen from the link’s measured rates before any drive image existed.3
Throughput, in GB/s
Higher is better. Each tick marks the target frozen before measurement; the walnut line marks the Gen4 x16 link’s raw rate, 31.5 GB/s each way. Search runs inside the drive, so it isn’t limited by the link.
| Measure | Frozen target | Measured | Efficiency | Result |
|---|---|---|---|---|
| 128 KiB sequential reads | ≥ 27.17 GB/s | 28.36 GB/s | 98.8% of the modeled ceiling | Met |
| 128 KiB sequential writes, CPU-written buffers | ≥ 9.11 GB/s | 12.14 GB/s | Limited by the PC | Met |
| 128 KiB sequential writes, static buffers | ≥ 27.07 GB/s | 17.93 GB/s | 62.6% of the modeled ceiling | Not met |
| 4 KiB random reads | ≥ 3.98M IOPS | 4.49M IOPS | At the PC’s measured limit | Met |
| 4 KiB random writes | ≥ 2.00M IOPS | 2.67M IOPS | At the PC’s measured limit | Met |
| Single 4 KiB read, interrupts / polled | ≤ 7.02 / 4.62 µs | 6.24 / 3.89 µs | — | Met |
| Single 4 KiB write, interrupts / polled | ≤ 7.91 / 5.51 µs | 7.39 / 4.90 µs | — | Met |
| Whole-drive search, 512 GiB | ≥ 31.59 GB/s | 34.58 GB/s | 98.5% of the memory’s predicted rate | Met |
Encryption was on for every measure except search, which runs on unencrypted data. The modeled ceiling is the payload rate the Gen4 x16 link can carry for each workload after packet, framing and link-management overhead, using the PC’s measured completion sizes.3 Random reads and writes, and writes from CPU-written buffers, reach the PC’s own limit, not the drive’s.
Search correctness. The drive’s match counts and offsets agreed with a host software reference that read and searched all 512 GiB, including patterns planted at the tested boundaries. The 34.58 GB/s search result is for unencrypted data.
Human direction,
agent execution.
People set the goal, approved the plan and targets, and made scope decisions. Agents performed architecture, RTL, verification, builds, board sessions, diagnosis and evidence assembly.
Through Melten’s Silicon Design Factory, people could steer the work while each accepted claim remained tied to its image, design commit and board session. Performance targets were frozen from link measurements before the first drive image. Independent review checked the evidence before closure.
Campaign milestones
- Day 0Campaign startedFrom a reviewed high-level plan.
- Day 0.06First controller commitLink training and framing reached 16 GT/s in simulation.
- Day 1.0Architecture setThe controller split at the PHY boundary across three dies.
- Day 3.3First 16 GT/s link to a real PCEight lanes, with the vendor’s PHY as a positive control.
- Day 4.7First Gen4 x16 linkWith custom 16-lane digital PHY control on the existing GTY hardware; a 4-hour zero-error soak followed.
- Day 5.2Link-only DMA reference measuredEvery performance target frozen from the link’s measured rates.
- Day 5.7First drive image timing-closedWrites then failed on the board; the cause, in synthesis, was found within hours.
- Day 6.5The fix proven on siliconFull-capacity writes verified with zero errors.
- Day 6.9Judged board sessions completeIntegrity, performance, search and encrypted boot.
- Day 7.3All seven outcomes closedIndependent review accepted the final evidence.
Under the hood.
A host-attached NVMe drive on an off-the-shelf FPGA card, combining existing GTY transceivers with custom digital PHY control, PCIe, encryption and search logic.
- Hardware
- BittWare XUP-P3R with an AMD Virtex UltraScale+ VU9P and four DDR4 channels providing the 512 GiB storage namespace.
- PCIe
- The agents’ Gen4 x16 controller on 16 GTY transceivers in their PCIe mode, cut at the PIPE boundary across dies, with a 1024-bit datapath at 250 MHz.
- Configuration space
- PM, MSI-X, PCIe, AER, Secondary PCIe, Data Link Feature, Physical Layer 16.0 GT/s and Lane Margining capabilities.
- Encryption
- Inline XTS-AES-256 with one register stage per AES round. At queue depth 1 it adds 90 ns per 4 KiB read and 428 ns per write.4
- Search
- On-drive pattern search across the 512 GiB namespace, for exact and masked patterns of 1 to 32 bytes, on unencrypted data.
- Implementation
- 57.3% of LUTs, 32.4% of block RAM and 20.6% of registers. Signoff at WNS +0.008 ns and WHS +0.009 ns.
Additional verification and bring-up details
- Simulation
- 535 cases ran in final acceptance across the controller and drive, alongside the controller’s 161 tests and routed-netlist simulation.
- Interrupted writes
- Writes interrupted mid-flight leave every block entirely old or entirely new.
- Encryption fault check
- A planted bit flip garbled exactly one 16-byte block.
- Boot environment
- The PC’s UEFI firmware booted Ubuntu Server 24.04 from the encrypted drive; firmware settings were left as found.
- Link bring-up
- The initial raw-transceiver PHY never left reset. The agents brought the controller up at 16 GT/s using AMD’s eight-lane PHY, then implemented sixteen-lane digital control using the GTY transceivers’ PCIe mode.
- From our survey of open-source PCIe stacks and commercial soft controllers, using their repositories, product pages and press releases, as of October 18, 2026. Open-source stacks had shown at most Gen1 in hardware. Published commercial results on UltraScale+ devices reached Gen4 x8 or Gen3 x16.
- AMD’s PCIe overview identifies the PCIE4 integrated block’s Gen3 limit. AMD PG239 lists Gen4 at 16 GT/s for its UltraScale+ PHY IP, up to x8. BittWare’s XUP-P3R specifications list a Gen3 x16 host interface. The reported Gen4 x16 board result uses Melten’s custom controller and digital PHY control with the existing GTY hardware.
- The performance figures are medians of judged fio runs on the acceptance image. Three references have different meanings: the Gen4 x16 raw link rate is 31.5 GB/s per direction before packet and link-management overhead; the modeled payload ceiling for 128 KiB reads is 28.71 GB/s after that overhead at the PC’s measured completion sizes; and the measured link-only DMA reference is 28.60 GB/s card to host and 28.50 GB/s host to card on the earlier probe image. The encrypted drive’s 28.36 GB/s with 128 KiB reads is 98.8% of the modeled read ceiling. Its separate 2 MiB write workload reached 28.2 GB/s. Sequential targets were frozen at 0.95× the probe rates, and IOPS targets at 0.90× the binding bound.
- Encryption’s cost was measured in simulation at the device boundary, from doorbell to completion at queue depth 1. The latency figures in the results table were measured on the board.