Module fpga_and_benchmarks 

FPGA build and benchmarking

U280 resource context

The current fast-path project budget is 260,000 LUTs, 520,000 registers, and 9,000 DSPs. Block RAM is also tracked even though it is not part of that three-number budget; table banking can consume BRAM through width fragmentation.

The compatibility OOC report constrained to 300 MHz records:

Resource	Used
LUTs	237,294
registers	94,129
DSPs	800
block-RAM tiles	6
WNS	negative; timing constraint not met

This result shows that the feature-complete serial architecture fits in raw device capacity but leaves too little LUT headroom for a high-throughput Vitis kernel and misses the required throughput by a wide margin.

Build stages

Use these stages in order:

1. export RHDL-generated Verilog;
2. run Icarus/Verilator tests on the exported top;
3. synthesize arithmetic primitives OOC;
4. synthesize the complete fast core OOC;
5. package the core behind the common 512-bit AXI shell;
6. link HBM and DDR xclbins;
7. run full implementation and inspect timing/DRCs;
8. execute the physical U280 benchmark.

The Vitis shell and host runner live under bench/. Vivado scripts and stored reports live under tools/vivado and reports/generated.

Traffic accounting

Record at least four different byte counts:

Counter	Includes
logical message bytes	bytes hashed by Ed25519 passes
AXI kernel bytes	command/message reads and result/counter writes
HBM/DDR bytes	actual memory-controller traffic where available
PCIe bytes	host/device transfers

For a single fixed-64 cold signature, the ideal message payload is read once by a specialized fast path. The host ABI and AXI line width still add command and result traffic. Report both payload efficiency and absolute bandwidth.

Fair AMD comparison

The AMD Vitis Security Ed25519 kernel and RHDL kernel must be compared with:

• the same U280, platform, XRT, Vitis/Vivado, target clock, and memory type;
• the same deterministic seeds and 64-byte messages;
• equivalent 512-bit movers and bank placement;
• the same batches, warmups, and measured runs;
• kernel-only and end-to-end timing boundaries;
• Dalek validation outside timing;
• separately built xclbins if co-location would distort resources/timing.

Measure cold sign, warm/cached sign when both APIs permit it, key derivation, and verification. Do not compare a pre-expanded AMD input with a cold-seed RHDL operation without labeling the semantic difference.

Required result fields

CSV/JSON benchmark output should contain:

• implementation and operation;
• message length and batch size;
• target and achieved clock;
• total/kernel latency, p50, and p95;
• operations/second and message throughput;
• AXI beats/bytes and pass count;
• HBM/DDR and PCIe bytes;
• LUTs, registers, BRAMs, URAMs, and DSPs;
• WNS and tool/platform versions;
• vector count and validation failures;
• artifact/source checksums.

Interpreting throughput

For a pipelined signer:

steady-state signatures/s = achieved_clock_hz / measured_initiation_interval

Do not divide by single-signature latency when many contexts overlap. Also do not infer the initiation interval from a primitive’s II; measure retirement at the complete signature output under sustained input.

The final pass condition is at least 200,000 complete cold 64-byte signatures per second with p95 reporting, correct outputs, post-route timing closure, and resource use within budget.