[Libre-soc-dev] in-order core hazard detection working
Luke Kenneth Casson Leighton
lkcl at lkcl.net
Tue Nov 23 14:37:35 GMT 2021
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Tue, Nov 23, 2021 at 6:09 AM Jacob Lifshay <programmerjake at gmail.com> wrote:
> which is waay harder than just demonstrating that a particular instruction
> sequence doesn't have issues -- you have to find all possible ways it might
> be broken and construct a set of instruction sequences that collectively
> cover all of them...
sigh, yes. found one that breaks, already.
> a formal proof might be the easiest way to to that, cuz
> that way you don't need to manually come up with all possibly bad
> instruction sequences.
annoyingly, there's no way of doing Past(arbitrary_number_of_cycles)
at least not in the "free" version, you have to use Past(Past(Past(Past(...))))
or Past(n_cycles=fixed_constant) which gets very tedious very quickly
> One alternate way, that doesn't actually prove it's good, but can probably
> quickly find places where you messed up (if any) is to just try random
> instruction sequences.
yes, this is how the microwatt 0.bin 1.bin 2.bin etc. tests were created,
Anton found (or wrote) a random-power-isa-instruction-generator
i used these programs in the original side-by-side comparisons
of microwatt-libresoc, last year.
the issue there is that to properly test hazard detection, you have to stop
and take periodic random snapshots but let the engine settle in between,
and re-run the test multiple times, stopping at different points.
even an in-order system may *commit* out-of-order. in-order is
not actually strictly defined as "instruction *completion* is in-order":
in-order is defined as "instructions are *issued* in-order and if
there is a 100% probability that they *can* complete then they
*will* complete (commit), but *NOT* necessarily *commit*
in-order"
to make the results say of a long-running DIV unit complete
BEFORE a short-running ADD unit that was issued AFTER
the DIV unit (even if there were zero dependencies) actually
requires even more detection logic.
sigh.
l.
More information about the Libre-soc-dev
mailing list