[libre-riscv-dev] Migen Conversions and Update

[Jacob Lifshay]

On Wed, Jan 2, 2019, 17:04 Luke Kenneth Casson Leighton <lkcl at lkcl.net
wrote:

> Ok Daniel so would you like to take a look at nmigen, the code is quite
> small, output v. tidy, you need latest yosys from git master. I really love
> the "with" statement, see nmigen examples, ah we need to check that it can
> generate a regfile, in migen there is a "memory.py" example which does all
> the right things, including multiporting, passthrough of writes to reads,
> and byte level write enable lines, i am unsure if that has been ported over
> yet.
>
> Jacob, about virtual regs table. VRegs table does not have to be unary, it
> can be binary. However as unary it is automatically the "enable" lines on
> each individual reg file memory cell, which is really nice.
>
I think we're going to be hard pressed to get a sram without an attached
decoder since all the HDLs I'm aware of only support a binary address for
memory blocks.

>
> Hypothetically this would mean independent simultaneous writes or reads to
> each reg entry in one clock, however in practice it would mean 128 64bit
> data buses and we aint doing that :)
>
> If binary then that binary address has to be decoded inside the regfile
> "box" itself. The unary matrix VReg to RealReg does away with that, so less
> gates.
>
> Also size of table not so bad as it is split to 4 banks and each 128 regs
> get their own muxes. Remember, muxes are on src but not on dest.
>
> Mitch Alsup did point out that line driving of 128 gates results in
> significant latency, however our target is 800mhz certainly not 2 to 3 ghz,
> also as it is driving unary encoders (128 mutually exclusive latches, only
> 1 of those may ever be set at any given time) it is really not as bad as it
> initially looks.
>
I would really like to try to design for being able to run at >1GHz so that
we can run at higher clock speeds for less power critical applications, for
short performance bursts, and for non-gpu execution, especially if the gpu
is going to also be the cpu.
I think 1.5GHz or 2GHz is a good target for max clock speed when ignoring
power.

>
> I hope :)
>
>
>
>
> --
> ---
> crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
> _______________________________________________
> libre-riscv-dev mailing list
> libre-riscv-dev at lists.libre-riscv.org
> http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev
>