[libre-riscv-dev] HDL selection

[Luke Kenneth Casson Leighton]

On Fri, Nov 16, 2018 at 10:40 PM Jacob Lifshay <programmerjake at gmail.com> wrote:
>
> On Fri, Nov 16, 2018, 14:16 Luke Kenneth Casson Leighton <lkcl at lkcl.net
> wrote:
>
> > ---
> > crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
> >
> > On Fri, Nov 16, 2018 at 8:28 PM Jacob Lifshay <programmerjake at gmail.com>
> > wrote:
> > >
> > > Ok. I did find https://m-labs.hk/migen/manual/index.html
> > > which I like better than MyHDL as it has a cleaner separation between
> > > python and the embedded HDL.
> >
> >  let's talk on-list, migen i found had issues as well.
> >
> I haven't looked particularly closely at either of them, however I think
> that having a separate AST for the HDL is better because it allows for
> easier differentiation between the HDL and the surrounding programming
> language, even if it's more verbose. It also doesn't artificially limit
> what can be used in the surrounding programming language.

 true.  i investigated both of them, for the pinmux code.  myhdl,
surprisingly, felt more natural and clean, despite having limitations
on what you can and can't do.  migen looked... messy, yet, you can
still use proper OO which you absolutely cannot do in myhdl.

 however... we have a bigger issue: there aren't any RV64GC SMP
pre-existing implementations.

> >
> > > I did try to use Chisel before but I couldn't get it to run, Java issues.

 i have these, it seems to work ok:
ii  openjdk-8-jdk-headless:amd64                     8u151-b12-1
                      amd64        OpenJDK Development Kit (JDK)
(headless)
ii  openjdk-8-jre:amd64                              8u151-b12-1
                      amd64        OpenJDK Java runtime, using Hotspot
JIT
ii  openjdk-8-jre-headless:amd64                     8u151-b12-1
                      amd64        OpenJDK Java runtime, using Hotspot
JIT (headless)

 i have never liked java: i said that since 1993 around the time it
came out, i never used it: first time i used it in 2008 it was
everything i expected it to be.

 fortunately, thank god, chisel is written in scala, so no need to
actually write java code.


> >  sounds about right.  if tackling chisel let's get a chroot (schroot)
> > set up and make sure the build env is completely replicateable.
> >
> I prefer docker images over schroot as that is even more replicable and
> probably more familiar to a lot of people as well as not needing
> installation on most CI platforms. I already have docker build files in
> kazan: https://salsa.debian.org/Kazan-team/kazan/blob/master/Dockerfile
> Additionally, GitLab allows custom docker images stored alongside the repo,
> so they don't have to be fully rebuilt every time.

 i know it makes sense - i guess i kinda feel like "if it ain't
debian" it feels like being disloyal a bit, i know that may sound odd
:)  let's see how it works out.


 the bigger issue is: i really really don't feel comfortable doing a
complete from-scratch, ground-up redesign: it goes against the grain
of everything i've learned, and the lesson is: start from a known-good
(fully working, existing) position, and modify incrementally on a
rapid cycle.

 with the requirements being SMP RV64GC, the majority of these are
wiped out as they're almost exclusively RV32.   BOOM is off the list
as it's RV64G.
 https://riscv.org/risc-v-cores/

 basically it looks like it's rocket-chip, lowRISC, or the freedom
core.  they're all the basic same thing, and the big advantage is:
there will always be work being done on them, keeping them up-to-date.

 currently the priv-spec is up to 1.11, and the majority of the rest
of the cores i see on that list are as far back as 1.9.  Algol which
is in MyHDL is 1.7.

https://github.com/lowRISC/lowrisc-chip - this one is capable of
running debian, and it's RV64GC.  being able to run debian: quite a
big deal!

l.