[libre-riscv-dev] HDL selection

[Jacob Lifshay]

On Tue, Nov 20, 2018, 04:28 lkcl <lkcl at libre-riscv.org wrote:

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

>
> > > (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?
>
=/= is used because != can't be overloaded in Scala since != is reserved
for comparing references.

>
> > > (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??
>
Rust uses var.1
Scala uses var._1 probably because a tuple is just a compiler-generated
class and the members have to follow Java's naming conventions since Scala
compiles to Java bytecode.

>
> > > (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.
>
Not really, because Chisel is really just Scala that uses the Chisel
libraries. Scala probably won't let ? : be overloaded.

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

Jacob

>