Issue Queue Design

[aarongchan]

The addition of an Issue Queue unit will allow users to define Issue Queue topology of which execution units are mapped to a certain Issue Queue. The current implementation has a one to one relationship, where each execution unit has it's own issue queue (ExecutePipe is really the issue queue), and there is no way to map multiple execution units to one issue queue.
Proposed Implementation:

IssueQueue Design

• IssueQueue should handle receiving instructions from dispatch and issuing instructions to their respective issue queue.
• Arbitration would be to issue to the issue queue that has the fewest instructions in a queue.
• Arbitration also needed to send instruction to first available ALU mapped to a certain issue queue
• Example flow:
  • Dispatch sends instruction
  • IssueQueue -> getInstsFromDispatch_() pulls instruction, checks if sources are ready, if so calls issueInsts_() -> issueInsts_() gets the issue queue with the least amount of instructions, lets say integer_issue_queue_0 is least filled, is inserted into queue -> arbitrate_alu() where we have alu0 as busy, but alu1 is not busy, so we send it there -> ExecutePipe's prepExecute_() function is called, sets status to scheduled, marks the ALU as busy.
• Each Execution unit would still have an ExecutionPipe attached that handles any setting of statuses.

Questions:

• For ExecutePipe, we would still keep that as a one to one mapping on each execution unit, but what should it's functionality be, given a lot of it's current functions are being moved to IssueQueue?
  • Currently I'm thinking of moving getInstsFromDispatch_() and issueInst_() to IssueQueue, so that would leave completeInst_() and flushInst_() in ExecutePipe (should we be moving those over to IssueQueue as well?). My thoughts are to rewrite issueInst_() to handle arbitration logic of which issue queue we should allocate to, so when we say an instruction is "issued", it is placed in an issue queue, but not scheduled to be executed (which the current implementation of issueInst_() does.
• The kicking off of "Execution" that issueInst_() currently does should be moved to ExecutePipe, but do we then have an event triggered when an entry is inserted into an issueQueue to issue to a specific ALU (arbitrate_alu() as described in above example flow)? If no ALUs are ready, we then schedule a callback?

[ghost]

Your separation of work between the issue queue and the execution pipe is right on target. When you initialize the execution components in Execute.cpp's factory, you will be creating the IssueQueues and the ExecutePipe instances. Then, by using the extensions from the topology yaml files, you will bolt IssueQueues to the ExecutePipes.

The IsssueQueues will be cognizant of target pipes it supports, but may not know which ExecutePipe assigned to it supports that pipe. You can create a map of instruction pipe target -> 1+ ExecutePipe OR you can round-robin walk the assigned pipes for which one can take the given instruction.

Here's an example of how you can do this...

Start with a new YAML description that is based on the pipe types found in the arch yamls:

top.cpu.core0.extension.core_extensions:
  execution_topology:
     alu_pipes: 
        [[int], [int], [mul]]
     br_pipes:
        [[br]]
    # etc...

What you can assume from the above layout:

1. There are ALU and BR pipes
2. There are 3 ALU pipes and 1 BR pipe
3. There might be 1 IssueQueue per pipe or 1 IssueQueue per unit type (ALU, BR) -- those are different parameters

You need to come up with a different set of YAML parameters that dictate IQ -> Pipe associativity. I'll leave that up to you. 😉

In Execute.cpp, two methods:

... onConfiguring(...)
{
     // Comb through the YAML file and setup X IssueQueues and Y Pipe ResourceTreeNodes
}

// NEW METHOD
... onBindLate(...) 
{
    // Connect the issue queues to the pipes:
    uint32_t alu_iq = 0;
    for(auto iq : alu_issue_queues) {
        iq->setExecutePipes(alu_ex_pipes[alu_iq++]);
    }
}

At this point, each IssueQueue has direct access to the public API for the ExecutePipe. The IQ can now do this:

void IssueQueue::sendReadyInsts_()
{
    // ....
    for (auto inst : ready_queue_) {
        for (auto ex_pipe : ex_pipes_) {
            if(ex_pipe->canAccept(inst)) {
               ex_pipe->execute(inst);
               break;
            }
        }
    }
}

There are other ways to do this. Think "best performance" when you implement this.

[aarongchan]

@klingaard,
Regarding flushing for the new Issue Queue design, should the logic be as follows:

1. An ExecutePipe receives a flush and cancels any completing instructions or issued instructions already in ExecutePipe
2. Send a signal to the IssueQueue with the flushing criteria, pop any instructions from Issue Queue that are newer than flushing instruction criteria
3. Loop through all ExecutePipes mapped to that Issue Queue, cancel any instructions newer than flushing instruction

[aarongchan]

@klingaard,
I'm attempting to rewrite the dispatch tests to account for insertion if issue queue and add testing for it as well. I'm running into an assert in the ScoreBoard that triggers when the issue queues are trying to reset their scoreboard view, similar to what is being done in ExecutePipe. This seems to be due to the DispatchSim test not being a full simulation where we initialize a core node, as we are just initializing everything straight from top such as top.rename instead of top.cpu.core0.rename in the test yamls.

1. How should I go about adding a core node in DispatchSim, so that the scoreboard views is able to find the master scoreboard accordingly?
2. Should I just be testing with a full simulation run instead? I see the benefit of the current unit testing when possible, as it's easier to test at a finer granularity. However, given the addition of issue queue, the complexity between dispatch/issue queue/executepipe is more complicated now and to test requires connecting everything together.

[klingaard]

You should be able create a master scoreboard in the main DispatchSim and attach it to the top node. To look for the scoreboard, you can look for it by tag.

Sparta has this hardcoded? Not good. This should change.