Module sha_client 

Port to a shared SHA-512 pipeline.

The shared line (rhdl_sha512_pipelined) is either the full pipeline, which takes a block every cycle with a fixed latency, or a folded core, which takes a block when its ready is high (S / 80 blocks per clock) and returns it 82 cycles after it enters its ring. Both return blocks in the order they took them, and the arbiter relies on nothing else. Several modules share it through a ShaArbiter; each module talks to the arbiter through a ShaClient, which offers exactly the interface of a ShaRing (ShaRingIn/ShaRingOut), so a core can swap its rings for one client.

 core ──ShaRingIn──> ShaClient ──PipeIn/grant──> ShaArbiter ──> pipeline
 core <─ShaRingOut── ShaClient <──PipeOut──────  ShaArbiter <── pipeline

Client

• Credits. The line cannot hold a result, so every block in flight must have room waiting at its client. A client holds CLIENT_CREDITS credits, one per entry of its result FIFO; issuing a block takes one, and the core taking a digest returns one.
• Two-block jobs. A job with second_pad (a 128-byte message, as in the challenge H(R || A || M)) comes back from its first block marked first; the client resubmits the constant padding block with that state as the chain, ahead of new jobs. The entry’s credit carries over.
• Order. The pipeline returns blocks in order, so a small ring of first flags, written at issue and read at return, tells the two kinds apart; tags pass through untouched.

Arbiter

Round-robin over the clients’ requests (each client’s request depends only on its registers), granting only while the line’s ready input is high. Results are routed by a FIFO of client numbers written at issue and read when a result returns (the line keeps order), so the pipeline’s tag stays the client’s own and the line’s latency may vary.

Combinational paths

A client’s req and ring outputs come from its registers only. The arbiter’s grants and result routing are combinational from those requests and from the pipeline’s output. So the client -> arbiter -> client path that the grant takes in one cycle contains no loop, and the request to the pipeline also depends only on registers.

Structs

ArbiterIn

Inputs of ShaArbiter.

ArbiterOut

Outputs of ShaArbiter.

PipeIn

One block for the pipeline (field for field rhdl_sha512_pipelined::ShaIn).

PipeOut

One finished block (field for field rhdl_sha512_pipelined::ShaOut).

ShaArbiter

Round-robin arbiter of up to 16 clients onto one pipeline.

ShaClient

Client of the shared SHA-512 pipeline, with a ring’s interface.

ShaClientIn

Inputs of ShaClient.

ShaClientOut

Outputs of ShaClient.

SharedShaIn

Inputs of SharedShaPort.

SharedShaOut

Outputs of SharedShaPort.

SharedShaPort

N clients and their arbiter: everything between N modules and one shared SHA-512 pipeline.

Constants

CLIENT_CREDITS

Jobs a client may have issued and not yet drained, which is also the depth of its result FIFO.

PIPE_LATENCY

Cycles from a request entering the pipeline to its result (rhdl_sha512_pipelined::LATENCY).

Functions

idle_pipe_in

An idle request (no block, all fields zero).

idle_pipe_out

No result (all fields zero).

sha_arbiter_kernel

State transition for ShaArbiter.

sha_client_kernel

State transition for ShaClient.

shared_sha_port_kernel

Wiring for SharedShaPort.