Module overview 

Source status, elaboration hierarchy, dataflow, and build boundaries.

Backend Overview and Source Status

What the active backend implements

The current fast path implements two operations around a cached key:

1. Load a 32-byte seed, compute SHA512(seed), clamp the secret scalar a, retain the nonce prefix, compute [a]B, and cache the encoded public key A.
2. For each 64-byte message M, compute r, R, k, and S entirely in hardware:

r = reduce_l(SHA512(prefix || M))
R = encode([r]B)
k = reduce_l(SHA512(R || A || M))
S = r + k*a mod l
signature = R || S

The top-level scoreboard allows different requests to occupy different workers at once. A request is represented by a context index and pending bits rather than by one monolithic per-request state machine.

Active cryptographic source set

The following files are necessary for the current fast64_cached_sign_core elaboration:

File	Role
fast64_cached_sign_core.sv	Context scoreboard, key cache, block builders, queues, worker arbitration, and signature retirement
sha512_compress_pool4.sv	Two-port allocator and return combiner around the SHA workers
sha512_compress_3phase.sv	One iterative SHA-512 compression worker
scalar_arithmetic_dsp_pipe.sv	DSP-folded reduction, wide multiplication, and modular multiply-add
multicomb_mul_stream.sv	Four-multiplier signed multi-comb fixed-base engine
multicomb_lookup_rom.sv	Constant-pattern multi-comb table scan and XPM ROM leaves
radix51_field_mul_pipe.sv	Active II=1 field multiplier
radix17_field_addsub_pipe.sv	Active modular add/subtract pipeline; the name is historical
point_compress_pair_stream.sv	Pair batch inversion and four physical compression ways

scalar_arithmetic_2phase.sv is still listed by current packaging and OOC scripts, but no module from it is instantiated by the active cached core. It is a retained serial reference/prototype, not a resource contributor in the reported hierarchy.

Active memory images

multicomb_lookup_rom.sv consumes exactly these active initialization files:

assets/multicomb_t8_n4_s8/comb_scan_bank00.mem
assets/multicomb_t8_n4_s8/comb_scan_bank01.mem
assets/multicomb_t8_n4_s8/comb_scan_bank02.mem
assets/multicomb_t8_n4_s8/comb_scan_bank03.mem

Each file contains one of four low-candidate-bit banks. The memory address is formed only from the public comb block and public scan group. The secret candidate selects data after every group has been read.

Optional deployment and benchmark source

File	Role
fast64_cached_sign_io_kernel.sv	Vitis RTL kernel shell with AXI-Lite control and four AXI memory masters
fast64_cached_sign_benchmark_engine.sv	On-chip deterministic request generator and XOR checksum collector
fast64_benchmark_kernel.sv	AXI-Lite wrapper around the cached benchmark engine

The AXI shell does not alter Ed25519 arithmetic. It moves one 512-bit message beat per request, one 512-bit signature beat per result, one key beat during key loading, and one summary beat per command.

Retained predecessor and probe files

These files are documented because they remain in the fast directories and can otherwise be mistaken for the current datapath:

File	Status
radix17_field_mul_pipe.sv	Predecessor 15-limb field multiplier; replaced by radix-51 in the active hierarchy
basepoint_lookup_rom.sv	Predecessor radix-16 table lookup using eight radix17_bank*.mem images
radix16_recode_stream.sv	Predecessor balanced radix-16 recoder
fixed_base_mul_stream.sv	Predecessor single-multiplier radix-16 point engine
point_compress_stream.sv	Predecessor single-point compressor
fast64_sign_core.sv	Predecessor per-request/cold signer with an opportunistic key cache
fast64_sign_benchmark_engine.sv	Benchmark source for the predecessor signer
scalar_signing_cluster_dsp	OOC resource probe inside scalar_arithmetic_dsp_pipe.sv

The directory assets/multicomb_t6_n4_s11 and its comb_bank00.mem through comb_bank31.mem files are retained generated assets but are not referenced by the current RTL. The eight radix17_bank0.mem through radix17_bank7.mem files are used only by basepoint_lookup_rom.sv.

Explicitly outside this manual

rhdl_ed25519_kernel.sv is the AXI wrapper for the separate RHDL compatibility core. It does not elaborate fast64_cached_sign_core and is not part of the SystemVerilog fast rewrite. Testbenches under bench/rhdl/tb drive public interfaces but do not synthesize into the kernel.

Context and queue topology

Storage or worker	Capacity	Purpose
Signing contexts	64	Retain message, tag, r, k, encoded R, and pending bits
Point contexts	16	Interleave scalar multiplications around field-multiplier latency
SHA workers	4	Compress seed, nonce, and two challenge blocks
SHA block builders	2	Assemble one 1024-bit block over sixteen cycles
Nonce digest FIFOs	2 x 32	Decouple the two SHA return ports from the nonce reducer
Challenge digest FIFOs	2 x 32	Decouple the two SHA return ports from the challenge reducer
Projective point FIFO	32	Decouple point multiplication from pair compression
Compression ways	4 x 4 contexts	Keep inversion state and operand muxes local
Per-way codec result FIFO	4	Absorb bursty inversion-chain completions
AXI completion FIFO	64	Hold one-cycle core output pulses until memory writes retire

Handshake and completion ordering

The core accepts a message only on valid_in && ready_in. A result is a one-cycle valid_out pulse with no output backpressure. Results may be out of input order. tag_in is retained and returned as tag_out so the caller can associate the signature with its message.

Within the core, pending bits express dependencies:

nonce_hash_pending
  -> nonce digest FIFO -> reducer_r
  -> point_r_pending -> point FIFO
  -> pair codec -> challenge0_pending
  -> saved SHA state -> challenge1_pending
  -> challenge digest FIFO -> reducer_k
  -> muladd_pending -> valid_out

Resource ownership

For the current matching-source U280 optimized OOC core report, the direct children are:

Child	LUTs	FFs	RAMB36	DSP48E2
Top-level context/control	10,126	8,096	0	0
Four-worker SHA pool	18,489	12,088	4	48
Nonce reducer	2,722	11,982	0	626
Challenge reducer	2,844	11,987	0	626
Fixed-base point engine	82,095	84,605	352	2,116
Four-way point codec	84,295	67,702	0	2,092
Scalar multiply-add	2,253	23,343	0	1,237
Raw direct-row sum	202,824	219,803	356	6,745
Adjusted top-level total	202,344	219,803	356	6,745

Vivado combines 480 LUTs across hierarchy boundaries, so the adjusted top-level LUT total is smaller than the raw direct-row sum. Other resource columns sum exactly. These figures come from optimized OOC synthesis at a 200 MHz request; they are not placed utilization.

Placement and revision boundary

Physical implementation exists only for the immediately preceding builder-pipeline revision:

• its standalone core is fully routed and closes setup at 199 MHz with 248,852 LUTs, 237,472 FFs, 356 RAMB36s, and 3,376 DSPs;
• its full U280 platform is fully placed and routed but misses setup by 1.836 ns, so Vitis emits no bitstream or xclbin;
• the current source uses 6,745 DSPs and has only focused RTL plus optimized OOC evidence, where WNS is +0.520 ns at 200 MHz.

The predecessor checksum package does not identify the current source: seven active RTL files and the host source have changed. Never combine the current 198.509-cycle simulation interval with predecessor placement and call the result a routed or hardware measurement. The placement reports remain valuable for diagnosing platform congestion, especially the point-state-to-DSP path, but current-source placement is still required.