A Simple Scoreboard to Handle Register Dependency

[furuame]

This issue describes a simple Scoreboard designed for in-order cores, which have the following characteristics:

• Instructions are in-order picked
• Instruction queue doesn't have replay capability
  • Instruction is directly deallocated from instruction queue after it is picked
  • When a speculative load-to-use fails to execute, the core flushes the consumer and re-fetches the instruction stream

An in-order scheduler has to know when the results of on-the-fly instructions are ready to use. So they can determine whether the issuing instructions can get data via bypassing network.

This scoreboard can be just a list of counters, showing when the data of those registers become ready:

Registers	Cycles to Complete
x1	0 (Ready)
x2	3
...	...
x31	1

Major features

• void write(RegisterType reg, uint32_t cycle_to_write)
  • This method updates the scoreboard that the reg produces the result after cycle_to_write
• bool read(RegisterListType reg_list, uint32_t cycle_to_read)
  • This method checks whether those reading registers in reg_list are ready to use after cycle_to_read
• The Scoreboard is expected to automatically decrement non-zero counters

Unresolved

• Should it be a Sparta::Unit? Or just use others' event set?

[klingaard]

Could make it a Unit. Seems reasonable. That way the resource has stats, event sets, default loggers, etc.

Be interesting to see a diagram on how the delay mechanism works. I would assume that the user of this scoreboard would expect to do something like this:

Cycle 100
producer->write({10}, 1);  // Set register 10 ready 1 cycle from now (101)
if(consumer->read({10}, 1) {
    ev_issue->schedule(1);   // Register 10 is expected to be ready 1 cycle from now (101); schedule issuing
}

Cycle 101
void MyClass::issueInst() { /* fired */ }

But what happens if register 10 is not going to be ready on the next cycle? Do you go into a poll situation on register 10? That could get expensive...

What if read looked like:

bool read(RegisterListType reg_list, uint32_t cycle_to_read, 
          sparta::Scheduleable * event_to_schedule_when_ready);

[kayeoc279]

Or read can return when the reg_list will be ready?
uint32_t read(RegisterListType reg_list)

Registers	Cycles to Complete
x1	0 (Ready)
x2	3

ev_issue->schedule(consumer->read({0,1}) # should return 3

[furuame]

But what happens if register 10 is not going to be ready on the next cycle? Do you go into a poll situation on register 10? That could get expensive...

@klingaard Good point. I was thinking it might be not so expensive since it is for in-order use cases. Usually there is a unique instruction queue and limited issue (1/2/3-way) capability. I only need to check a few instructions every cycle and schedule issue event if there is any instruction in queue. But now it seems unnecessary.

Both designs (Knute's and @kayeoc279's) look reasonable to me.

[klingaard]

The issue with read returning an expected ready time is that it is variable and most likely unknown. What if the dependency is on a load that misses in the cache?