[libre-riscv-dev] Migen Conversions and Update

[lkcl]

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

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


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

 :)

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

 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.



> 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
 (c) are we going with 6600-style scoreboards?

> Happy new year!

 you too :)