[libre-riscv-dev] Migen Conversions and Update

[Jacob Lifshay]

On Tue, Jan 1, 2019, 22:51 lkcl <lkcl at libre-riscv.org wrote:

> On Wed, Jan 2, 2019 at 5:14 AM Daniel Benusovich
> <flyingmonkeys1996 at gmail.com> wrote:
>
> > Good evening!
>
>  eeevening
>
> > I have been silent for while but not in vain!
>
>  :)
>
> > I have gotten a much better hold on Verilog, Python, and Migen in
> > the past couple months.
>
>  ahh, verycool.
>
> > An arduous task indeed as I have never used Verilog before and very
> sparingly Python.
>
>  it's fuuun.  really.  writing in one language to output another.
>
> > Anyways I have done my best to port over Jacob's ALU first
> > as a test run.
>
>  niice.  got them.  style-wise: the character limit for pep8 is
> line-length of 80.  this is *really* important (to me) as i pack
> *eight* 80x65 xterms on one virtual window (the one with both firefox
> and chrome on the RHS), and *TWELVE* 80x65 xterms on most other
> virtual windows.
>
>  this to get the absolute max number of edit sessions possible
> on-screen, in order to see *all* related functions under
> investigation.
>
> >  I have attached the files (I know the mailing list wont have them but I
> will put in some choice snippets for the curious bits).
> >
> > I found that Migen does its best to keep things clean when converting
> from python to verilog and while some conversion are perfect the syntax can
> be a bit odd.
>
>  yes.  ah btw, i discovered a couple of things since:
>
>  (1) migen can't do unsigned shift left/right, only ASL / ASR (<<< and
> >>>)... so we need to use nmigen
>
I think adding lsl/lsr to migen should be pretty easy (not having looked at
the source).

>
>  (2) nmigen is a *LOT* cleaner.  it has a much clearer syntax "with"
> for Case and or If statements, and its output uses yosys.
>
> > For example, the ternary operation ( a ? b : c) is replicated via a
> function Mux(a, b, c) which I found quite odd as that is not mentioned
> anywhere. I only found out after converting it over in despair.
>
>  :)  yeahh the problem is that everything has to be a python function:
> there is no ternary operator in python, it's done syntactically:
>
>  x = 5 if (y > 3) else 2
>
> which is a pain in the ass.  for "standard" operations - add, mul,
> compare etc - python has class-based functions __add__, __mul__,
> __gt__, __ge__ etc. which will be called whenever the corresponding
> python operator is used.
>
> 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 there parameters, the ternary op does not).

>
>
> > The bigger problem is that I have not yet found a way to convert
> > functions from python to verilog.
>
>  ah.  yes.  the only "dividing" point is verilog modules.  if you use
> yosys "show" on the verilog file, you'll find that's actually not a
> problem.  the use of verilog functions i found to be a major blocker
> to readability and understandability of the graphviz graph.
>
> >  The functions are executed (in python) and the result is then converted
> into verilog.
>
>  yes.  basically the functions create an Abstract Syntax Tree (AST),
> in-memory.  that's recursively "walked" by a generator-function,
> which... spits out verilog quite literally with simple "print"
> statements.
>
>  welcome to language translation! :)
>
>  nmigen uses yosys to do that task.
>
> >> Example.py
> >> def add(a,b):
> >>     return a + b
> >>
> >> //Various garbage here
> >> ...
> >> a.eq(add(0,1))
> >> //More various garbage here
> >> ...
> >>
> >> results in
> >> Example.v
> >> assign a = 1
> >
> >
> > which was not my dream! Functionality is provided to get around it but
> it is not nearly as pretty.
>
>  yosys output (from nmigen) is cleaner.
>
> > This physically hurt me as Jacob's function was much prettier to look at
> (in Verilog).
>
Entirely manual formatting (Xilinx ISE is awful for editing verilog).

>
>  :)
>
> > It seems to be hard without breaking into additional modules
> > (which is fine but I wanted to keep it to the same file count).
>
>  don't worry about it.
>
> > In addition, i have not discovered a way to convert 'X' through
> > as a default value (forgive my ignorance) if it is possible at all.
>
the default case shouldn't be reachable. I just had it because the compiler
complained.

>
>  i generally found that if the migen team left something out, there's
> a damn good reason for it.
>
> > A couple nice things after all the bad is no need to declare inputs or
> outputs!
>
>  yeah i liked that.  it's only when you get to call it (as a verilog
> module) that you need to declare the inputs and outputs of what you
> are *calling*.
>
> > It is all nicely handled which is a nice change of pace.
>
>  ta-daaa :)
>
> > After creating a module it can be easily referenced like any
> > python object which is also very helpful as referencing internal
> > signals and wires is a breeze.
>
>  now you know why i am advocating it.  also, what's really *really*
> cute: the python code can, at runtime, pass in *different* parameters,
> which *CHANGES* the resultant AST, *WITHOUT* having stupid, stupid
> #ifdef and other ridiculousness.
>
>  also, you can pass in *groups* of wires - as class instances.  so all
> the Hell of having verilog declarations that get larger and larger,
> gathering more and more bus wires, until the top module has 700+
> signal wires and is impossible to understand let alone debug... all
> that's gone.
>

grouping and decent compile time code generation are what would change
verilog from an ok (sort-of) language to a great language. Also, getting
rid of the multiple ways to assign variables with subtly different
incompatible semantics.

>
>
>
> > I will continue to work on the conversion unless something else comes up.
>
>  well.. i tell you what... have you heard of cocotb?
>
> > Do let me know if anything needs to be done coding: the instructions,
> > scoreboard, or implementation of Tomusulo's algorithm you are talking
> > about in the mailing list and google discussion.
>
>  there's been a lot over the past few weeks, this is the latest:
>  https://groups.google.com/forum/#!topic/comp.arch/8pAGuX6UBu0
>
>  i *really* like the CDC 6600, particularly the enhancements that
> mitch alsup made.  i must send you his unpublished book chapters:
> we're free to use them as long as we give mitch credit.
>
>
> > If you could send me some references I would be happy to take a jab it.
>
>  well, before we go ahead, we need to make a decision (you, me, jacob)
> - as the project is being run on "unanimous" decision-making lines.
> things to decide:
>
>  (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).

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.

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

>
> > Happy new year!
>
>  you too :)
>
Happy 2019 to all!

Jacob