Fetch stage

The fetch stage mainly do the following things:

  1. Calculates the next PC for the upcoming instruction.
  2. Accesses IMEM to retrieve the instruction bytecode.

It can be decomposed into combinators as follows (code):

Input and Output

The IO interface type of the fetch stage is as follows:

Ingress

This is the first stage, it does not take any ingress interface.

Egress

It returns an egress interface with type I<VrH<FetEP, DecR>, { Dep::Demanding }>.

Each of FetEP and DecR is defined as a struct with the following fields:

FetEP (in fetch.rs):

  • imem_resp: IMEM response which contains the address (PC) and the data (inst bytecode).

DecR (in decode.rs):

  • redirect: Represents the redirection PC when the control hazard occurs.

Behavior

Each combinator do the following things:

Computes the next PC (M0-M2)

M0 (source_drop):

  • Receives the IMEM response and redirection PC as resolver from the later modules:
    • The IMEM response comes from M2. It contains the current PC and inst bytecode.
    • The redirection PC comes from the execute stage and the memory stage.
  • Forwards the IMEM response and redirection PC to the payload to compute the next PC.

M1 (filter_map):

  • Computes the next PC based on the incoming payload:
    • If a redirection PC is provided, jump to it.
    • Otherwise, proceed to the next sequential address (current PC + 4).

M2 (reg_fwd_with_init):

  • Creates a pipelined stage before accessing IMEM by storing the next PC in a register.
  • When the circuit is reset, it is initialized with the designated start address (START_ADDR).

Accesses IMEM (M3)

M3 (map + comb + map):

  • Constructs the IMEM request with map combinator.
  • Accesses the external IMEM module to fetch the instruction bytecode with comb combinator.
    • We use an asynchronous memory for memory, it provide the response in the same cycle.
    • We used attach_resolver module combinator to attach additional resolver to the IMEM.
  • Deconstructs the IMEM response with map combinator.

Discards on misprediction (M4-M5)

M4 (map_resolver_drop_with_p):

  • Attaches the IMEM response to the resolver signal for the next PC calculation.
  • Turns on the ready signal when control hazard occurs to extract the payload from M2.
    • This allows discarding invalid PC stored in the M2.

M5 (filter_map_drop_with_r_inner):

  • Filters out the payload when the redirection happens.