[libre-riscv-dev] HDL selection

[lkcl]

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.

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

 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

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

l.