[Libre-soc-dev] Massive EU Grant (up to 26 million) deadline 21st Oct

[lkcl]

On October 17, 2021 9:59:03 AM UTC, Jacob Lifshay <programmerjake at gmail.com> wrote:

>neat! hopefully that pll isn't the cpu clock,

heck no

> otherwise anyone who can
>see
>the packets your sending over the network (or introspect cpu timing
>some
>other way) is essentially given a built-in awesome emi detector, making
>it
>easy to detect whatever secret data (AES keys anyone?) you're
>processing.

yehyeh, it'd need to be a special mode or privileged.

>>
>> sounds like the idea I came up
>> > with for meltdown/spectre-proof (for timing/cache/etc.
>side-channels --
>> > *not* for power side-channels) speculative execution:
>> > https://bugs.libre-soc.org/show_bug.cgi?id=209
>> >
>>
>> it's close enough so yes.
>>
>> bear in mind we'll still be under time pressure and have chosen
>> the Scoreboard system due to its power consumption saving, so
>> the "Shadow/Cancellation" system will need to be part of that.
>>
>
>the meltdown/spectre-proof idea is applicable to that microarchitecture
>too, it applies to nearly any out-of-order microarchitecture.

indeed.  however the crucial thing of this application is: it is for TRL 2/3.  look it up.  tying in to existing designs is critical.

>I do want to have a traditional register-renaming microarchitecture as
>one
>of the demo cpu's supported microarchitectures --

already discussed (list, comp.arch) last year.  you must have missed it.

>The register-renaming microarchitecture shouldn't be too hard to
>implement
>(I've already thought through a lot of it),

i discussed it with Mitch Alsup on comp.arch and wrote out a diagram for it.  some time last year.

essentially it is the exact same dual FU-REGS plus FU-FU twin DM Matrices used for RaW/WaR hazards(ironically) but now it is:

* REALREGS-RENAMEDREGS in the 1st matrix
* RENAMED-RENAMED in the 2nd

the other difference, which is crucial but tiny, is the flow ("decision driver") for WaW DMs is inverted from RaW/WaR DMs.

it also neatly solves the problem of us having too many real regs (128+128+128)

i can't recall immediately the details.  don't ask, i have too much going on.

> I'd guess a few weeks for
>the
>register-renaming/scheduler

nooo chance.  jacob: we've established already that you suck at estimating fully-planned project timescales :)

> -- the rest should be able to be shared
>with
>the 6600-based design.
>
>a demo of a decent portion of the register-renaming/scheduling
>algorithm:
>https://ftp.libre-soc.org/power-cpu-sim/

multi-issue needs to be included.  this throws a massive spanner into the works of most designs. including Tomasulo and anything based on it. Multi-ported CAMs for the ROB and it quickly goes downhill from there.

2.5 years ago Mitch showed me how Scoreboard DMs can be made multi-issue by using unary (one bit per "thing") which means you can set multiple bits per clock (ta-daaa) and by introducing transitive relationships.

l.