Module interfaces 

Interfaces and protocol

The public wire types live in [rhdl_ed25519_types]. The top-level ready/valid wrapper is [rhdl_ed25519_controller_types::Ed25519CoreIn] and [rhdl_ed25519_controller_types::Ed25519CoreOut].

Command channel

[rhdl_ed25519_types::Ed25519Command] contains:

Field	Meaning
op	derive, sign, verify, or clear-key operation
flags	cached-key use and strict-verification controls
msg_len	exact logical message length in bytes
secret_key	RFC 8032 32-byte seed; meaningful for derive/cold sign
public_key	compressed Edwards-Y public key; meaningful for verify/cached sign
signature	`R

A command transfers only when command_valid && command_ready. The producer must hold the command stable while valid is asserted and ready is deasserted. The core accepts one operation at a time on the compatibility path.

Message channel

[rhdl_ed25519_types::MessageWord] is a 64-bit little-lane-order data word:

• data[8*i +: 8] is byte lane i.
• keep[i] == 1 marks lane i valid.
• last marks the final transferred word of the requested pass.

A word transfers only when message_valid && message_ready. keep must be a contiguous low-bit mask (0x01, 0x03, …, 0xff) for a partial final word. The number of valid bytes and placement of last must agree with msg_len and the current pass request. Violations become ERROR_STREAM_FRAMING.

Zero-length messages do not require a data word. The hash engine still creates the correct SHA-512 padding block in hardware.

Pass-request channel

[rhdl_ed25519_types::PassRequest] tells the transport which section of the message is needed:

Field	Meaning
valid	a replay/external segment is requested
pass	logical pass identifier
offset	first message byte requested
len	number of bytes requested

The transport must preserve byte order across multipart slices. It must not insert a separator, length field, or prehash. Multipart signing is exactly the signature of the concatenated byte sequence.

Result channel

[rhdl_ed25519_types::Ed25519Result] remains valid until result_valid && result_ready. It carries:

• ok, public_key, and signature operation results;
• a dedicated hardware error code;
• cycle_count measured by the core;
• stream_bytes, the logical bytes fed to hashing;
• external_read_bytes, bytes requested from the transport.

Counters are part of the behavioral contract and benchmark instrumentation. Do not derive HBM/DDR traffic from stream_bytes; bus traffic also includes command/result records, line padding, and mover behavior.

Error codes

Code	Condition
ERROR_INVALID_OP	unsupported operation encoding
ERROR_STREAM_FRAMING	message length, keep, or last mismatch
ERROR_MISSING_KEY	cached-key sign requested without a valid cache
ERROR_MALFORMED_POINT	public key or R does not decode canonically
ERROR_NON_CANONICAL_SCALAR	signature S >= l
ERROR_SMALL_ORDER	decoded point is small order
ERROR_VERIFY_EQUATION	strict verification equation does not hold

Software adapter

[rhdl_ed25519_api::Ed25519Hardware] is the driver/simulator boundary. Its signing and verifying key wrappers implement Dalek’s signature traits, so software can change transports without changing application-level signing code. The transport implementation remains responsible for driving the exact wire protocol above.