Skip to main content

Module code_map

Module code_map 

Source
Expand description

§Code map

The workspace is split by hardware responsibility rather than by mathematical chapter. This table is the quickest route from a failing test or waveform to the owning crate.

§Public boundary and oracle

CrateResponsibilityStart with
[rhdl_ed25519_api]Dalek Signer, Verifier, MultipartSigner, and MultipartVerifier adapters over a hardware transportEd25519Hardware, HardwareSigningKey
[rhdl_ed25519_types]command, message, pass-request, result, operation, flag, and error encodingsEd25519Command, Ed25519Result
[rhdl_ed25519_model]pinned-Dalek reference behavior and RFC/vector helperssign, verify_strict, canonical_vectors

§Compatibility arithmetic

CrateResponsibilityImportant detail
rhdl_ed25519_sha512streaming SHA-512, padding, circular schedule, K ROMhashes actual bytes in RTL
rhdl_ed25519_hash_feederprefix insertion, message framing, 4 KiB replay cacheowns external-byte counters
rhdl_ed25519_fieldfield arithmetic modulo 2^255 - 19ten alternating 26/25-bit limbs
rhdl_ed25519_scalarscalar reduction/canonical checks modulo group order lnine 29-bit limbs internally
rhdl_ed25519_pointextended Edwards formulas and Niels conversionmicrocoded field-operation DAG
rhdl_ed25519_scalar_mulradix-16 scalar recoding and constant-pattern table scanbuilds eight point multiples on demand
rhdl_ed25519_point_codeccompression and decompression controllercoordinates inversion, square root, and canonical checks
rhdl_ed25519_point_codec_*decompression sub-kernels and shared typessplit to keep RHDL kernels tractable

[rhdl_ed25519_core] re-exports these arithmetic crates into the logical field, sha512, scalar, point, hash_feeder, and types namespaces. New code should generally depend on the owning crate for implementation and on the facade when assembling an engine.

§Compatibility control plane

CrateResponsibility
[rhdl_ed25519_controller_types]top-level input/output and state/status types
rhdl_ed25519_transitionpure next-state function
rhdl_ed25519_commandschild-engine command construction
rhdl_ed25519_registersretained cache/work/point register updates
rhdl_ed25519_resultresult and error formation
[rhdl_ed25519_top]child wiring, arbitration, and top-level synchronous design

When adding a state, update the state constant, transition, child command, register capture, result behavior, and tests together. Do not hide a state transition inside a register-update kernel.

§Fast fixed-64 path

CrateCurrent responsibilityStatus
[rhdl_ed25519_fast_field]radix-2^17, II=1 DSP field-multiply prototype and behavioral modelprimitive RTL and tests
[rhdl_ed25519_fast_fixed_base]generated Dalek fixed-base table assets, constant-pattern lookup, recoding/scheduler RTLintegration in progress
basepoint_table_genparse the pinned Dalek table and emit checked radix-17 ROM assetsdeterministic generation tool

The fast backend is deliberately not wired into [rhdl_ed25519_top] yet. Contributors should preserve that separation until the fast top signs and validates complete messages.

§Simulation, RTL, FPGA, and host code

PathResponsibility
rhdl_ed25519_simcycle simulation, trace generation, checksums, Verilog export
bench/rhdlVitis RTL kernel shell and AXI data movement
bench/hostcommon XRT host benchmark and result collection
bench/amdAMD Vitis Security comparison kernel
tools/vivadoout-of-context synthesis and implementation scripts
reports/generatedgenerated evidence; inspect provenance before citing

Generated Verilog and Vivado reports are evidence, not source. A source change invalidates a prior synthesis claim unless the report records and matches the new source checksum.