Model topology design

[ghost]

The Olympia model started with a flat pipeline structure consisting of a single FPU, ALU, BR, and LSU. Dispatching to these units was handled in a large switch statement in Dispatch.cpp, but obviously this static implementation is not extensible.

Some Requirements

To enable a more dynamic approach to pipeline topologies, Dispatch must be changed to be agnostic to the topology and simply attempt to push as many instructions through as possible. Some rules:

1. Dispatching will continue to be the last in-order point in the simulator
2. Dispatch will pull the oldest instruction from its queue and attempt to dispatch it to a generic Dispatcher
3. If the Dispatcher can take the instruction, Dispatch will continue. If the Dispatcher cannot take the instruction, Dispatch will stall and wait for that Dispatcher to "wake it up" once its capable to accept another instruction

A Simple Design

Using a Sparta extension, Dispatch will create Dispatchers that will handle a given TargetUnit specified in an instruction via the architectural JSON ISA files that are supplied to Mavis.

Dispatcher

A Dispatcher will be the conduit between Dispatch and the target Execute pipe for any given instruction. The Dispatcher will

1. Handle credits from the Execute pipe
2. Provide flow control to Dispatch, pushing back on Dispatch if it cannot take the given instruction
3. Wake up Dispatch if it denied dispatching in the past and is now able to accept new instructions

Execute

An Execute unit will be extended to handle instructions from Dispatch. Once issue #2 is complete, this class will handle ready vs non-ready instructions for execution. This class will pick the oldest, ready instruction from an internal sparse array (sparta::Array) and mark itself "busy" (for now). In the future, pipeline can be added. When the instruction is finished (based on latency information in the Mavis JSON files), the instruction will be removed from the internal issue queue and a credit returned to dispatch's dispatcher.

Execute units will be created by an ExecutionUnit factory that will use the topology file to build the layout.

YAML Topology Definition

First thoughts on a YAML file for this design:

top.cpu.extension.pipe_topology:
    num_alu: 4
    num_fpu: 2
    num_br:  1
    num_lsu: 1

Using this information, Dispatch can create 8 Dispatchers. The ExecutionFactory can create 4 Execute units to handle ALU instructions, 2 units for FPU, and 1 for BR. The LSU can be created in main simulation.

After the simulation is created, the binding code can use this topology information to bind the Dispatchers to the Execute pipes.

[ghost]

Re-thinking the topology extension, this might make more sense:

top.extension.core_extensions:
  execution_topology:
    [["alu", "4"].
     ["fpu", "2"],
     ["br",  "1"]]

This would read:

• There are 4 ALUs Execute units to be instantiated.
• There will be 1 Dispatcher instantiated that will service 4 ALUs

I don't think the LSU should be a part of this at this time.

[ghost]

Step 1: Add a Dispatch tester that can handle dynamic execution topologies: PR #17 complete

[egieske]

How should the Dispatch unit interface with a Load Store Execute unit that can accept more than one Inst per cycle? Some possibilities:

1. Separate Dispatchers and corresponding LS DataInPorts, one per LS instruction, but then the credits from the single LS issue queue must be coordinated among more than one LS Dispatcher.
2. Use a derived class of Dispatcher that places a InstGroup on the DataOutPort for LS.
3. Change all Dispatchers & DataOutPorts to send InstGroup, which in non-LS uses would be 1 element vectors and would require changes to the non-LS execute DataInPort handlers.

[klingaard]

I like the third approach. This make the model very flexible, allowing multiple instructions to be dispatched to each type of IssueQueue.

For those unfamiliar with the Dispatch design, the Dispatch Unit contains 1..* Dispatcher classes. Each Dispatcher is responsible to send exactly 1 instruction per cycle to exactly 1 IssueQueue (the IssueQueue will exist once @aarongchan separates them out -- they are currently in the ExecutePipe).

After the proposed change (third approach), the Dispatcher will collect 1..N instructions to dispatch (programmed via parameters) to its attached IssueQueue. This will be an InstGroup of instructions.

Suggestion on implementation:

1. The Dispatcher will create a new InstGroup when it receives the first instruction to dispatch and cache it
2. The Dispatcher will immediately send that InstGroup to its assigned port even if it's "not done."
3. When more instructions are dispatched in the same cycle, the Dispatcher will just add them to the already cached InstGroup
4. At the end of the cycle (or beginning of the next one), that InstGroupPtr will be nullptr'ed