Module planner 

Ed25519 components for the chip planner (rhdl_fpga_planner).

Ed25519Sign and Ed25519Verify wrap crate::frontier’s sizing so the Ed25519 modules sit next to DSig and the SHA-512 line in one TUI, each with its own power and knobs:

Knob	Values
Modules	specialized (routed fix9 blocks, preferred memory layouts) / as built (2023.2 synthesis of 15/11/3/1)
SHA-512	shared line / own rings
Verify mode (verify only)	known-key / strict / batch
Block ratio	auto (best mix) / manual: keep the three weights below
FB (or verify) machine, SHA ring, scalar ring weight	1–32 each; the ratio in manual mode
Batch compress	auto / on (a compress machine) / off (each machine inverts and encodes; model)

Memory placement (specialized table): every block starts in its preferred layout (machine banks in UltraRAM). When the share’s URAM runs out, replicated machines move one at a time to their block-RAM layout (MachineMemory::BRAM_BANKS), the one fallback the RTL builds; the plan detail says how many (“3 of 9 machines in block RAM”) and the uram_machines flag builds exactly that (ED25519_URAM_MACHINES). Nothing else moves: when block RAM runs out too, the plan holds fewer machines.

Cores. A module is 1 to MAX_CORES identical cores, each in an equal part of the share, because one core’s credit pool caps it.

With the shared line a module has no SHA rings: it pays a client port (crate::frontier::SHA_CLIENT_LUT) and demands "sha512 blocks" (three per signature, two per verification), which the planner checks against the line’s supply.

Sha512Estimate stands in for the SHA-512 line component of rhdl_sha512_pipelined (DSig’s) in builds without it: an allowance taken out of the budget (the SHA part of the LUT split), up to 432k LUTs and 20 DSPs, whose throughput is modeled from its LUTs.

Modules

ubft

Ed25519 as uBFT’s service (crate::ubft::UbftEd25519, feature ubft): the signer and the verifier of UbftEd25519<1, NV> as two uBFT modules ([Component::ubft]), planned only in Mode::UbftEd25519, beside the replica ([rhdl_fpga_planner::ubft::UbftReplica]).

Structs

Ed25519Sign

The Ed25519 signing module as a chip-planner component. Its plan is the best frontier::plan_sign_with build for the share it is given.

Ed25519Verify

The Ed25519 verification module as a chip-planner component. Its plan is the best frontier::plan_verify_with build for the share and mode.

Sha512Estimate

Stand-in for the SHA-512 line (rhdl_sha512_pipelined’s component replaces it): auto-sized to demand by default (at least one 5.5k-LUT folded core), or by hand 0–432k LUTs and 0–20 DSPs.

ShapeKnobs

The shape controls every Ed25519 module has: a ratio mode, three weights and batch compression.

Constants

LINE_BLOCK_CYCLES

One SHA-512 block’s round trip on the shared line for an idle core, in cycles: the 82-cycle line plus dispatch and return. Fitted to the isolated native runs of 2026-10-19 (signer 8,0,2,1: 224 per block over the model without the line; verifier 6,0,1,1: 190).

MAX_CORES

Most identical cores one module may be built from.

SHA_ESTIMATE_MAX_LUT

Largest LUT allowance of the estimate’s knob, the same as the real line’s (ten pipelines’ worth, 432k LUT, about 11.6 blocks per clock).

SHA_ESTIMATE_MIN_LUT

The smallest line the estimate builds: one 2-stage folded core (rhdl_sha512_pipelined::folded, ~5.5k LUT by Yosys).

SMALL_SIGNER_LATENCY

Measured single-request latency of the small signer in cycles.

Functions

sign_latency_cycles

Idle latency of one signature in cycles (model): the nonce block, a scalar job, the fixed-base walk on a 32-context barrel (one bundle per 32 cycles), the compress machine’s flush wait and its batch program on a 64-context barrel, the two challenge blocks and two scalar jobs. With own_sha the module’s SHA rings take ~81 cycles per block; on the shared line each block takes LINE_BLOCK_CYCLES (dispatch, the line, the return). Measured isolated (fix13, 8,0,2,1 on the line): 40,446 cycles against 40,406 from this model. The fused small core measured 22,240 cycles for one request (it has no compress machine, so this batch-compress model is not directly comparable).

verify_latency_cycles

Idle latency of one verification in cycles (model): the two challenge blocks, one scalar job, the verify program on a 32-context barrel, and the compress machine as for signing. Measured isolated (fix13, 6,0,1,1 on the line): 52,350 cycles against 52,392 from this model.