[libre-riscv-dev] HDL selection

[Jacob Lifshay]

On Tue, Nov 20, 2018 at 5:17 PM lkcl <lkcl at libre-riscv.org> wrote:

> On Wed, Nov 21, 2018 at 12:35 AM Jacob Lifshay <programmerjake at gmail.com>
> wrote:
> >
> > On Tue, Nov 20, 2018 at 3:47 PM lkcl <lkcl at libre-riscv.org> wrote:
> >
> > > On Tue, Nov 20, 2018 at 10:34 PM Jacob Lifshay <
> programmerjake at gmail.com>
> > > wrote:
> > > >
> > > > On Tue, Nov 20, 2018, 04:28 lkcl <lkcl at libre-riscv.org wrote:
> > >
> > > > >  so it's part of the compiler, not an actual variable??  it's like
> an
> > > > > __intrinsic__ in gcc or something.
> > > > >
> > > > It is an actual Scala variable. You can think of Chisel as a Scala
> > > library
> > > > that generates Verilog from the Chisel AST, which is built by
> compiling
> > > and
> > > > running the Chisel code as a Scala executable. This is similar to how
> > > > SystemC is really just C++ that is using the SystemC libraries.
> > >
> > >  so essentially, chisel3 is a hack.  it wasn't thought through:
> > > someone encountered (or knew about) scala, and went "that'll save some
> > > time" as opposed to, "if we were to write a logical, obvious, clean
> > > and useful HDL that was easy to learn, and fixed many of the problems
> > > of the past and brought HDL up to modern OO software development
> > > practices and standards, what would we do?"
> > >
> > I disagree. Scala is a well known programming language outside of the HDL
> > field, and, from what I can tell, if you already know Scala, Chisel is
> > really simple to get started with (assuming you also know how HDLs work).
>
>  i'm at a significant disadvantage here: my experience with HDLs is
> extremely limited.  i'm used to gate-level design, which i'm fine with
> (long story).  i've spent a few months doing basic verilog, i'm just
> about getting used to it.
>
>  with three things to learn: (a) chisel (b) scala (c) HDL it's just
> too much.  plus, see below.
>
Yeah, I found Chisel to be utterly opaque when I first encountered it. I
found that reading the Chisel cheatsheet to be helpful:
https://chisel.eecs.berkeley.edu/2.2.0/chisel-cheatsheet.pdf (not sure if
that's the right link)

>
> > From what I can tell, Chisel is actually very similar in design to Migen
> in
> > that both of them are programs that use a HDL library to build an AST for
> > the HDL at runtime and the only major difference is that Migen is written
> > in Python and Chisel is written in Scala.
>
>  interesting.
>
> > Also, you can use the same OO capabilities and existing infrastructure
> for
> > Scala with Chisel. It's just more difficult for someone who doesn't
> already
> > know Scala as Scala has quite a few operators set aside for overloading
> > (like =/= and ===), with no default definition (from what I can tell).
> > Scala has to also deal with the limitations of compiling to JVM bytecode,
> > influencing the object model, naming, and other portions.
>
>  interesting.   and all things that are guaranteed to trip at least me up.
>
>  here's the thing: as a *really* experienced python programmer, i've
> done python AST work on two different projects (a python to javascript
> compiler was one of them) if there are any bugs in the migen compiler,
> or if we need any augmentations or enhancements, i have full
> confidence i'll be able to do that.
>
Ok, lets use Migen then. I guess this is my chance to go from a beginner to
intermediate level Python programmer.

>
>  with scala, chisel, and java?  not a chance.


> > Note that I am a Scala newbie, so I probably got some things incorrect.
>
>  no problem.
>
>  well, i took the liberty of looking up "scala language popularity"
> and interestingly this came up:
>
> https://www.infoworld.com/article/3270626/python/python-scala-climb-the-ranks-of-language-popularity.html
>
>  scala *just* barely made it into the top 20 with 0.8% popularity,
> where python has just overtaken java for the first time at 22.8%.
>
>  that means that the chances of us finding (or being able to hire)
> scala programmers is extremely low.  1 in 120 programmers have looked
> up tutorials on it, where that number is over 1 in 5 for python.
>
>  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?

>
>
>  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.

>
>  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.

Jacob