[libre-riscv-dev] Migen Conversions and Update

Jacob Lifshay programmerjake at gmail.com
Thu Jan 3 02:09:24 GMT 2019

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

> 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

> 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

More information about the libre-riscv-dev mailing list