Module architecture 

Architecture

One-page view

The compatibility implementation is a command sequencer around five services:

                        +----------------------+
command + message ----> | Ed25519Core          | ----> result
                        |                      |
                        |  HashFeeder + SHA512 |
                        |  ScalarEngine        |
                        |  ScalarMulController |
                        |  PointCodecController|
                        |  PointOpController   |
                        +----------------------+
                                  |
                         shared field multipliers

[rhdl_ed25519_top::Ed25519Core] owns the registers and child engines. [rhdl_ed25519_transition::next_state_kernel] decides which high-level phase runs next. The commands, registers, and result crates keep input generation, retained state, and result formation separate from transition logic.

This partitioning is deliberate. Smaller RHDL kernels are easier to compile, simulate, inspect in generated Verilog, and synthesize than one enormous combinational transition function.

Cold signing dependency graph

For a seed sk and message M, Ed25519 signing follows RFC 8032:

SHA512(sk) -----------------> clamp -> a -------> [a]B -> encode -> A
    |
    +-----------------------> prefix

SHA512(prefix || M) --------> reduce mod l -> r -> [r]B -> encode -> R

SHA512(R || A || M) --------> reduce mod l -> k

S = r + k*a mod l
signature = R || S

The implementation never asks the host for a, prefix, r, R, or k. The command carries the seed and message length; the message arrives through the ready/valid stream.

Cold signing derives and stores the expanded key while executing. A later cached-key signing command can reuse a, prefix, and A. ClearKey invalidates and zeroizes that cached state.

Strict verification dependency graph

Given public key A, signature R || S, and message M:

canonical(S) ?
decode(A) -> reject malformed/small-order A
decode(R) -> reject malformed/small-order R
SHA512(R || A || M) -> reduce mod l -> k
[S]B and [k]A
compare encoded([S]B - [k]A) with R

The top-level controller reports distinct errors for non-canonical S, malformed points, small-order points, message framing, missing cached key, and equation failure. These are hardware result codes, not Rust exceptions.

Arithmetic hierarchy

Ed25519 operation
  -> SHA-512 / scalar modulo l / Edwards-point operation
     -> field add, subtract, multiply, square, invert
        -> bounded limbs, multiply-accumulate, carry, reduction

The compatibility field representation is Dalek’s ten-limb radix-2^25.5 layout. Edwards points use extended coordinates (X:Y:Z:T). Point addition uses cached Niels forms to reduce the number of field operations. Compression performs inversion and emits Edwards-Y with the sign bit of affine x.

The fast field prototype uses fifteen radix-2^17 limbs and a deeply pipelined DSP implementation. It is intentionally a separate backend so the compatibility path remains available while performance work proceeds.

Message locality

The hash feeder owns a 4 KiB byte cache. During signing, the first hash pass consumes and caches the message. The challenge pass replays the cached prefix and only requests bytes beyond offset 4096 from the surrounding transport.

For a message of N bytes, the intended signing input traffic before bus-line padding is:

N + max(N - 4096, 0)

Verification requires one message pass. The cache is local BRAM; there is no external scratch buffer and no HBM/DDR access from an arithmetic engine.

Compatibility and fast-path boundary

The fixed-64 path is optimized for a different operating point: many independent cold signatures, each with a 64-byte message. It can retain many contexts, schedule independent field products through an initiation-interval one multiplier, and use a fixed-base table for both [a]B and [r]B.

It must still produce exactly the same R || S bytes as the compatibility core and pinned Dalek. Until that path passes end-to-end differential tests and U280 execution, the compatibility core is the authoritative hardware design.