[libre-riscv-dev] HDL selection

[lkcl]

On Sun, Nov 18, 2018 at 8:25 PM Jacob Lifshay <programmerjake at gmail.com> wrote:
>
> On Sat, Nov 17, 2018, 06:08 Luke Kenneth Casson Leighton <lkcl at lkcl.net
> wrote:
>
> > RocketCore.scala: register file.
> >
> > https://github.com/freechipsproject/rocket-chip/blob/master/src/main/scala/rocket/RocketCore.scala
> >
> > (1) what on earth is canRead being set to false? that permanently
> > stops read from working!
> >
> I think that's to enforce that read declarations have to come before write
> declarations. Not sure why they are doing that.

 so it's part of the compiler, not an actual variable??  it's like an
__intrinsic__ in gcc or something.

> > (2) what on earth is a "=/=" operator?
> >
> Inequality operator for generated code:
> https://github.com/freechipsproject/chisel3/wiki/Builtin-Operators

 what on earth?? why is it not "!=" or "!==" or even "<>" which has
been the convention for inequality operators for what... 40+ years?

> > (3) what's an _2?
> >
> second element of a tuple

ah. i've seen this weirdness before, in bluespec.  why don't they just
use [] just like every standard programming language in existence??

> > (4) where are all the comments that are normally expected to be on
> > source code files, explaining the parameters and the purpose of the
> > class?
> >
> Missing; they probably figured it was obvious from the code:

 and that's by far and above one of my biggest concerns.  code
comments are absolutely essential for maintenance and understanding: i
trained as a software engineer, i'm used to certain standards from
software libre projects.

 this one's really the kicker for me: no comments means it's weeks if
not months just to understand the code.

> > (5) what order are the parameters to "Mux"? what kind of "Mux" is it?
> >
> 2-input mux: Mux(a, b, c) is the generated code version of C's a ? b : c
> https://github.com/freechipsproject/chisel3/wiki/Builtin-Operators

 they  _could_ have added that to the language, however in this case
it's reasonably intuitive.  i kinda guessed from the name "Mux" it
might be something like that.

 anyway: overall, chisel3, or more to the point, this particular
codebase (rocket-chip) is out.

 my primary concern is: if we are going to be doing heavy
modifications to the core, it has to be understandable, readable, and
maintainable.  rocket-chip is the total opposite.

 one thing, though: when compiled down to verilog, it might be
worthwhile to e.g. use the chisel3 compiler to auto-generate some
tilelink-aware smp-coherent caches, for example, which would save a
lot of hassle.

 the difference being, there: we absolutely do not need to make any
*modifications* to the chisel3 source code of the cache (or tilelink).


> > the key about litex (migen): *massive* incrreases in efficiency of the
> > auto-generated Verilog source.  far, far less resources utilised.
> >
> I don't litex is any better/worse than chisel for resource utilization,
> it's just that they are both better than the IP that comes with Vivado,
> which is particularly terrible.

 ah :)

>  Note that I haven't tested anything personally though.

 well, bunnie huang's pretty clued-up.

l.