[libre-riscv-dev] Possible nMigen Milestone?

Luke Kenneth Casson Leighton lkcl at lkcl.net
Tue Jan 7 03:15:48 GMT 2020


On 1/7/20, whygee at f-cpu.org <whygee at f-cpu.org> wrote:
> On 2020-01-07 02:55, Luke Kenneth Casson Leighton wrote:
>> the cycle time on e.g. FPDIV is around 2 sim clocks per second, and
>> the partitioned INT multiplier is around the same.
>>
>> that's *without* the partitioning, and without even linking any of
>> this together into an actual processor.
>>
>> *combine* the partitioned INT mul code into say FPMUL or FPMAC and we
>> could well be looking at seconds to tens of seconds per sim-clock
>> tick.
>>
>> the simulation times, without some kind of drastic performance
>> increase, are going to be awful :)  so i am veeery glaad you and
>> whitequark have been working on this.  it'll just be around the right
>> time, too.
>
> How large is this design ???

20,000 lines of OO python code... so far.  that's just the FPU.
multiple inheritance will massively distort (under-exaggerate) that.

> So far my methodology is to use pure VHDL.
> Staying with only one langage (and a potent one)
> that uses LLVM/GCC optimisation backends,
> a clean and flat programming (instead of
> russian dolls) has proven quite efficient for me...

think through the following requirements and estimate how much code
would need to be written in VHDL

* partitionable MUL, ADD and other primitives which dynamically, per
pipelined operation, can perform an 8x8 SIMD MUL on one clock cycle,
followed by a 4x16 SIMD MUL on the next, followed by a 1x64-bit MUL on
the next, *without* having separate SIMD ALUs for each MUL

* dynamic length-adjustable pipelines which, on the flip of a switch,
double the length and thus allow double the pipeline speed


> I could test kilovectors per second and I didn't
> even push much (I could have saved time by ...
> not restarting GHLD for every damned vector
> AND using all 4 cores)

does it rely on simulator primitives such as "add" and "mul"?  we
actually have to *implement* "add" and "mul" at a low level, in order
to meet the above requirements.

l.



More information about the libre-riscv-dev mailing list