[libre-riscv-dev] [Bug 92] Implement in order instruction retire refcounting

[Luke Kenneth Casson Leighton]

Can anyone think of an algorithm here?

We need a way in which, using only single bits, a *batch* of operations can
be detected as being allowed to "commit", where they may complete (generate
results) in an arbitrary time.

My current thoughts are to have two sets of bits. One that is striped
across banks (described below), and the other creates dependencies
*between* banks.

Only when the shadow in the last intra-bank stripe is dropped is one
dependency *between* banks dropped.

It is kinda like doing a counter where if there were 4 banks we would have
LSB bits 0 and 1 representing the stripe 0 1 2 or 3, and bits 2 and above
would be the dependencies *between* banks.

Does that make any sense, and are there any other alternatives?

L.


On Thursday, June 6, 2019, <bugzilla-daemon at libre-riscv.org> wrote:

> http://bugs.libre-riscv.org/show_bug.cgi?id=92
>
> --- Comment #1 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
> The proposed idea has a problem: the counter compares are effectively CAM
> compares. Multiple AND gates to check that the high bits are nonzero.
>
> This for every single FU, it is just too expensive.
>
> An alternative idea is to preallocate, at instruction issue time, the
> register
> write port to which the instruction will commit its result.
>
> This by having a separate set of shadows for the write ports.
>
> This unfortunately has the side effect of reducing parallelism as the
> instructions may complete well before each other, and, if allowed to
> commit via
> another port, clearly would allow forward progress that was otherwise
> missed.
>
> Hopefully operand forwarding will mitigate this somewhat.
>
> There must be better alternatives.
>
> Perhaps even whilst the allocations are not to ports per se, they may be at
> least identification of "candidates for selection to commit to any port".
>
> Or, perhaps, it is not a problem after all. Instruction order is to be
> preserved. If one shadow bank is not ready, allowing another to commit
> would
> mean getting out of order.
>
> Needs more thought.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
> _______________________________________________
> libre-riscv-dev mailing list
> libre-riscv-dev at lists.libre-riscv.org
> http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev
>


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