[libre-riscv-dev] Migen Conversions and Update

[Luke Kenneth Casson Leighton]

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

On Wed, Jan 2, 2019 at 11:46 AM Jacob Lifshay <programmerjake at gmail.com> wrote:

> I think adding lsl/lsr to migen should be pretty easy (not having looked at
> the source).

 i'd say it's abouuuut.... 2 hours work: the question is, do we *want*
to?  nmigen is an awful lot cleaner, and doesn't have the issue.

> > there just... doesn't happen to be an __ternary__ over-ride, which is
> > a significant oversight.
> >
> I personally think not having an overridable ternary operator is part of
> good language design because it reduces unexpectedness (functions evaluate
> all their parameters, the ternary op does not).

 iinteresting... hmmm... now i'm curious to know if the same thing
happens with python __and__ overrides....

> the default case shouldn't be reachable. I just had it because the compiler
> complained.

what i've seen auto-generated is that the last case *is* listed as the default.

> grouping and decent compile time code generation are what would change
> verilog from an ok (sort-of) language to a great language.

 Bluespec added something half-way decent.

> >  (a) do we like migen enough to go with it?
> >  (b) do we use nmigen instead
> >
> I'll let you decide between these, since both of them seem to have
> everything I want (or can be easily extended to)

 after seeing nmigen, the way it does case and if statements:

      with If(bool_test):
          self.sync += eq(blah)

it's *really* clean.  hypothetically, migen could be retro-fitted with that.

> I have a small preference for using a statically-typed language I'm
> familiar with, like C++ or Rust rather than a duck-typed language that I
> have no sizable experience with (Python), but I'll be fine.

 we're really really not going to need some of the more obscure
dynamic features of python.  the absolute, absolute critical thing in
python is: unit tests.

 absolutely, absolutely essential.

> >  (c) are we going with 6600-style scoreboards?
> >
> I'm worried about the power used by 256 register lines in the scoreboard
> using more power and area than tomasulo's algorithm's cams. Adding register
> virtualization layers makes me start to think that maybe tomasulo's
> algorithm or just implementing a scoreboard using 8-bit cams would be
> better. I do like having centralized control either way.

 the virtualisation redirection level is really quite straightforward:
all unary encoded, and i worked out a way to not need a massive number
of Function Units.

 one of the issues with the Tomasulo algorithm is that it's a little
harder to get it to do multi-issue.  you need to "mark" instructions
as belonging to one of (4?) groups, then, once all hazards are free,
you *still* have to wait until all four instructions complete.  *only
then* can the 4 instructions (together) be committed.

 6600-style scoreboards: you literally throw multiple entries per
clock at the Function Units, the FUs themselves preserve the
dependency chain by way of "write hazards", and let the logic have at
it.

l.