Module fast_path 

Fixed-64 high-throughput path

Objective and acceptance meaning

The optimization target is sustained cold signing of 64-byte messages on an AMD Alveo U280:

Constraint	Limit/goal
completed signatures	200,000 per second
LUTs	at most 260,000
DSPs	at most 9,000
registers	at most 520,000

At 300 MHz, 200,000 signatures/second permits an initiation interval of 1,500 cycles/signature. This is a throughput interval: one signature may have much greater latency if many independent contexts are in flight.

Acceptance requires post-route timing closure and real U280 execution. A cycle model or OOC primitive report is an engineering gate, not final proof.

Why the compatibility core cannot simply be replicated

The current compatibility core takes 90,928 simulated core cycles for a 64-byte sign. Its recorded U280 OOC result uses 237,294 LUTs, 94,129 registers, 800 DSPs, and 6 block-RAM tiles, while missing the 300 MHz constraint slightly. One instance therefore provides only a few thousand signatures/second, and the LUT budget does not permit enough replicas.

The fast design changes the backend from serialized operation latency to interleaved throughput.

DSP field pipeline

The radix-17 field multiplier accepts one product every cycle and returns it after a fixed pipeline latency. Its 15 by 15 limb product matrix maps naturally to 225 DSP multipliers; additional DSPs handle wrapped coefficients and timing stages. Context tags travel beside operands/results.

The recorded pre-integration OOC evidence for one field pipeline is 2,469 LUTs, 6,041 registers, 240 DSPs, no BRAM, and positive slack at a 300 MHz constraint. That report predates later canonicalization edits and must be regenerated before it is cited as current-source evidence.

Fixed-base radix-16 baseline

Dalek’s fixed-base layout has 32 windows and eight magnitudes per window. A balanced radix-16 multiplication performs 64 mixed additions and four doublings. With the point formulas used by this design, that is approximately:

64 * 7 + 4 * 8 = 480 field products/squares

Independent point contexts hide the field pipeline latency. A scheduler may issue one ready field operation per cycle while other contexts wait for dependencies.

The table lookup has measured OOC evidence of 3,505 LUTs, 827 registers, 88 block-RAM tiles, no DSPs, and positive slack at a 300 MHz constraint.

Signed multi-comb option

Signed multi-comb changes the fixed-base schedule. Parameterize it by:

• n: independent comb blocks;
• t: teeth per table entry;
• s: spacing/number of execution columns;
• coverage requirement n * t * s >= 255.

The table contains n * 2^(t-1) signed-combination points. Execution performs n*s mixed additions and s-1 doublings. A candidate (n=4, t=6, s=11) covers 264 bits and costs:

44 mixed additions + 10 doublings
44 * 7 + 10 * 8 = 388 field products/squares

That is about 19% fewer field products than the radix-16 baseline. The cost is a 32-way constant-pattern selector and more severe physical BRAM banking. A multi-comb implementation is worthwhile only if synthesis confirms that the selector, routing, and block-RAM footprint improve whole-signer throughput within the LUT budget.

Secret table indices must still be scanned: all 2^(t-1) magnitude banks are read at the same public comb address, then selected in logic. Direct secret-indexed BRAM reads are not acceptable.

SHA-512 capacity

A cold signature over a fixed 64-byte message requires exactly four SHA-512 compression blocks:

1. SHA512(seed) uses one block;
2. SHA512(prefix || M) is 96 bytes and uses one block;
3. SHA512(R || A || M) is 128 bytes and uses two blocks.

The compatibility compressor consumes 466 cycles per block, so one instance cannot sustain the 1,500-cycle signature interval. The fast path needs either two current compressors or a more deeply pipelined/fewer-phase compressor. Fixed block assembly should bypass byte-at-a-time loading while still constructing padding and lengths in RTL.

Whole-signer scheduler

A complete fast signer needs tagged context storage and these services:

ingress -> seed hash -> scalar clamp/reduce -> A fixed-base multiply
        -> nonce hash -> reduce r -> R fixed-base multiply
        -> A/R compression -> challenge hash -> reduce k
        -> r + k*a mod l -> ordered result

The scheduler must support dependency-driven issue, preserve output order, retain every 64-byte message until the challenge hash, and zeroize a context after retirement. No primitive may meet its local II while starving another service enough to violate the whole-signer interval.

Current readiness

Implemented/measured today:

• compatibility end-to-end signing and strict verification simulation;
• radix-17 field multiplier RTL/model/tests and an OOC report;
• checked radix-16 basepoint assets and constant-pattern lookup OOC report;
• fixed-base scheduler/point RTL under integration.

Still required for a final throughput claim:

• end-to-end fast scalar multiplication and point-compression differential tests;
• pipelined scalar reduction/multiply-add;
• fixed-block SHA subsystem;
• tagged multi-context signer and AXI shell;
• post-route U280 timing/resource closure;
• sustained hardware run with Dalek validation.