[libre-riscv-dev] HDL selection

[lkcl]

On Wed, Nov 21, 2018 at 5:01 AM Jacob Lifshay <programmerjake at gmail.com> wrote:
>
> Ok, lets use Migen then. I guess this is my chance to go from a beginner to
> intermediate level Python programmer.

 starting from good examples is really important, and this is one:
  https://github.com/m-labs/migen/blob/master/migen/genlib/coding.py

 in particular, the layout on the comments (docstring), really *really*
 important to document the parameters, and the purpose of the
 function.

 except it's generally bad practice to use "import *", so we need to
 fix that.

 also i use autopep8 with options "-a -a -a --experimental" as it's
 going to be really important to keep to coding standards, and autopep8
 deals with that automatically.

 these may sound like mundane things, they're really not: they're
 critical to ensuring that the code is readable and maintainable.

 also if you use vim i recommend these in ~/.vimrc:

syntax on
set ts=4
set sw=4
set expandtab

i don't know how to set that to be conditional, detecting the python
filetype, apologies.

> >  i realise this is a pretty major decision, to basically start from
> > scratch for the cpu, which is why i thought it might be a good idea to
> > do a conversion of the rv32 cpu you did (just the cpu, that is).
> > https://github.com/programmerjake/rv32
>
> So, for the conversion, should we start now, or later?

 i cloned rv32 on git.libre-riscv.org as i'm taking a short break
 from spike-sv to see how this goes.

> >  it's really small, i can't quite get over the fact that the main core
> > of the alu is only 9 lines! :)
> >  https://github.com/programmerjake/rv32/blob/master/cpu_alu.v
> >
> >  so, i figured if we do a very quick conversion of those verilog files
> > to migen, we'll have a pretty good idea really quickly if it's going
> > to be a viable way to develop a full RV64GC-SV processor.
> >
> Note that rv32 may be too small to adequately test Migen's equivalent of
> C++ templates, which I think will end up being really useful for the final
> processor as it will allow us to quickly change things like functional-unit
> counts, register port counts, and SIMD ALU widths. All three of those would
> most likely be nearly impossible to change in a Verilog-only implementation
> without a giant macro mess since it would drastically change Verilog Module
> interfaces throughout the processor.

 absolutely.  well, let's get familiar with the basics first, then work out
 some further experiments.

> >
> >  note, i'm not recommending we *use* rv32 as the basis for the
> > processor, just as a learning / evaluation exercise.  and, second, i'm
> > definitely not recommending we go all-out and do absolutely everything
> > in migen.  given that chisel3 compiles down to verilog, i believe we
> > can get away with interfacing to the rocket-chip coherent caches, for
> > example, which will save a ton of time.
> >
> I agree, however we may have to modify the rocket-chip caches to have a
> wider interface (probably 128-bit or 256-bit) so we can load and store
> vectors without taking 1 clock-cycle/element. If that becomes too involved,
> we may decide to implement our own cache instead.

 good point.  if we go for 4-wide SIMD it'll be doing 4x the LD/STs.
we'll need to see if the GPU workload is computation intensive or
memory intensive.

l.