Dispatch
- Version: V2R2
- Status: OK
- Date: 2025/01/20
- commit: xxx
Explanation of Terms
| Abbreviation | Full Name | Description |
|---|---|---|
| - | renameIn | uop information input to the rename module |
| - | fromRename | uop information after being registered (pipelined) after output from the rename module |
| - | toRenameAllFire | Signal indicating all uops have been dispatched |
| - | enqRob | Signal passed to the rob, registered (pipelined) in the ctrlblock before entering the rob |
| - | IQValidNumVec | Number of instructions corresponding to each Exu in the IQ |
| - | toIssueQueues | Uop information dispatched to all IQs |
| - | XXBusyTable | Register file status table |
| - | wbPregsXX | Write-back register file information, used to update BusyTable |
| - | wakeUpXX | Fast wakeup information, used for speculative BusyTable updates |
| - | og0Cancel | Indicates that this uop is canceled in the og0 stage |
| - | ldCancel | Indicates that a memory access uop is canceled when executing to the s3 stage (s0-s3) |
| - | fromMem | Signals from memory access, including the number of lsq commits and cancels |
| - | toMem | Signals sent to memory access, including lsqEnqIO |
Submodule List
| Submodule | Description |
|---|---|
| XXBusyTable | Register file status table, including 5 types: Int (Integer), Fp (Floating Point), Vec (Vector, excluding V0), V0 (Vector V0), Vl (vcsr's vl) |
| rcTagTable | Tag table for the integer register cache (register file cache) |
| lsqEnqCtrl | Module controlling the pointers for entering the load/store queue |
Design Specifications
- Supports dispatching uops to all IQs according to a load balancing strategy.
- Supports updating and maintaining the BusyTable and writing to srcState during dispatch.
- Supports updating and maintaining the pointers for entering the lsq and writing to lqidx sqidx during dispatch.
- Supports blocking uops based on sequential order.
- Supports masking instructions with exceptions when dispatching to IQs.
Functionality
The Dispatch module includes the BusyTables for each register file, rcTagTable, and lsqEnqCtrl. It updates the BusyTable and rcTagTable based on register file write-back, fast wakeup, og0Cancel, and ldCancel signals. The lsqEnqCtrl module controls the enqueue pointers lqidx/sqidx for the load/store queue. When the lsq capacity is insufficient, it pulls down io_enq_CanAccept to block dispatch.
In each clock cycle, the Dispatch module dispatches up to 6 uops after renaming to the various IQs. When all pending uops are dispatched, the handshake signal toRenameAllFire is asserted. Upon receiving the handshake signal, the rename module updates the next group of uops for the Dispatch module.
In each clock cycle, the Dispatch module counts the number of instructions corresponding to each Exu within each IQ. For each type of fu, a load comparison is performed among the IQs containing all Exus for that fu. A dispatch strategy is generated strictly based on the load order, stored in registers.
The Dispatch module collects the input signals of rename and the registered (pipelined) output signals. Based on the fuType in the input signals, it calculates the number of uops with the same fu as the current uop (with an index smaller than itself) among the preceding uops. It then looks up the target IQ based on two pieces of information: the type of the fu and the number of preceding uops with the same fu type. Dispatch is performed according to the IQ load from lowest to highest. The first instruction of that fu type is dispatched to the IQ with the lowest load, the second to the IQ with the second-lowest load, and so on.
The Dispatch module receives control signals from various modules to block instruction dispatch. The main reasons for blocking include: the target IQ is not ready, the number of instructions dispatched to the same IQ exceeds the IQ's entry capacity, the rob cannot accept instructions, the lsq cannot accept instructions, a preceding instruction needs to blockBackward, or the current instruction itself or a preceding instruction needs to waitForward. When blocking occurs, it is done sequentially. If an instruction is blocked, all subsequent instructions are also blocked. Once blocking occurs, toRenameAllFire is pulled down, and the dispatch of the next group of instructions must wait until the blocked instructions are dispatched.
The Dispatch module masks out (sets the valid signal sent to the IQ low) certain exceptional instructions, preventing them from being dispatched to the IQ. This includes instructions with decoding exceptions or those that have been tagged with singleStep.
Overall Design
Overall Block Diagram
Interface List
See interface document
Module Design
Level 2 Module BusyTable
Functionality
The BusyTable module is responsible for recording the busy status of the register file. During dispatch, the psrc is used to read the BusyTable to get the ready status of the source operands.
Each register file corresponds to one BusyTable module. The number of entries in the BusyTable is consistent with the register file, initialized to 0 (idle state). When an instruction is renamed, the corresponding pdest information is input via allocPregs, changing the corresponding entry from 0 to 1. The BusyTable also receives speculative wakeup signals wakeUpXX. When woken up, the corresponding entry changes from 1 to 0. Speculatively woken-up instructions might be canceled, which is signaled via og0Cancel, changing the corresponding entry from 0 to 1 (this might be in the same cycle as wakeup, with higher priority than wakeup). If it is the integer BusyTable, it also needs to respond to ldCancel.
The number of read ports for the BusyTable module is determined by the number of corresponding register operands required by an instruction according to the instruction set definition, multiplied by the issue width. For example, with 6-wide issue, the integer BusyTable has 2 * 6 = 12 read ports, floating-point and vector have 18 each, and V0 and Vl have 6 each.
Overall Block Diagram
Interface List
See interface document
Level 2 Module rcTagTable
Functionality
rcTagTable is the tag for the integer register file cache. It is very similar to the integer BusyTable module and also has 12 read ports.
Interface List
See interface document
Level 2 Module lsqEnqCtrl
The lsqEnqCtrl module is responsible for maintaining the pointers for entering the lsq and sending uops to the lsq. It maintains the pointers based on each instruction's needAlloc (2 bits, low bit high indicates needing to enter the load queue, high bit high indicates needing to enter the store queue) and numLsElem (number of entries needed). When io_enq_iqAccept is high (indicating the uop is accepted by the IQ), it is sent to the lsq.
Interface List
See interface document