[libre-riscv-dev] outstanding commit pending counters (for multi issue)

[Luke Kenneth Casson Leighton]

http://bugs.libre-riscv.org/show_bug.cgi?id=92

Mitch, hi,

I think I have a solution, however I believe it may make the priority
pickers redundant or at least they need to be replaced.

Assume 4 multi issue.
Assume 4 regfile write ports.
Create 4 "in-ordering" shadows (aka WaW shadows)
On issue, assign round-robin a shadow down each "stripe".
Create a second round robin detector which identifies in each cycle those
"stripes" that are in-order ready to retire (commit)

Thus, up to 4 commits will be detected per cycle, in-order, and the
execution time down each "stripe" is irrelevant.

Where the priority picker becomes irrelevant is because on each stripe, the
retirement shadow is ALREADY holding FUs such that ONLY ONE FU in each
stripe is permitted to raise its "Writable" flag.

We can even safely assign each stripe a regfile port, and I believe that if
we latch that regfile port number (which is also the roundrobin index at
issue time) into the FU itself, that index will pop out the end, on retire,
we *know* the retirement roundrobin can only pick non-clashing port-indices.

Therefore, the priority picker's entire reason for existing is superceded.
Only for the writing side, mind you.

Does that sound logical and reasonable, if a little hair-raising? Or did I
miss something?

What I have not yet thought through is what if the number of regfile write
ports does not match the issue count.  Perhaps this is as simple as, the
round robin inserter does not have to be the same modulo as the round robin
retirer, it is just that the port# index has to match the size of the
retirer size.

Thoughts appreciated.

L.



-- 
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68