[Libre-soc-dev] nmigen tutorials etc.

[Andrey Miroshnikov]

On 10/10/2021 21:38, Luke Kenneth Casson Leighton wrote:
>>> actually you can still get many of them by using archive.org
>> Great idea! I'll check to see what I replaced and find the equivalent
>> archive.org links.
> 
> i think i did that for lambdaconcept tutorials already, somewhere.
> http://libre-soc.org/resources/ ?

Searched web.archive.org, could not find these as they were not backed 
up by the wayback machine:
https://github.com/lawrie/ulx3s-nmigen-examples38
https://github.com/icebreaker-fpga/icebreaker-nmigen-examples24
https://github.com/kbob/nmigen-examples19

It's probably not critical, as I did find similar equivalents.


>>> the alternatives - which i describe in detail here - are absolutely
>>> flat-out bat-s*** insane.
>>> https://libre-soc.org/3d_gpu/architecture/dynamic_simd/
>> Gave it a read. Now I finally have an idea of what PartionedSignal is
>> meant to do. With a signal example it made much more sense.
> 
> you see why it's completely bast-hit sinane to try to do a batch
> if elif-elif-elif-elif cases in the actual ALU?
> 
> imagine you have 600 lines of ALU code (something really complex).
> now duplicate that 4 times.
> 
> or, worse, try to do explicit gate-level optimisation, where in the
> ALU you explictly design-in the low-level SIMD "partitions" > actually right there, in the ALU.
> By using PartionedSignal in the ALU, aren't you going to get HDL with 
those partitions built-in? Or is the plan to have a configuration 
parameter for synthesising either normal, or SIMD-partitioned version?

> 
>> Parallel bit groups that can be operated on separately, or combined
>> together if no partitions are enabled.
> 
> yes.  now it turns out (and it was Jacob who came up with this
> concept, first) that you can do tricks for e.g. "add" by having
> partition bits actually *in* the underlying add: a 64-bit add becomes
> a 64+7 bit add, and you use carry roll-over to get it to *look*
> like they're "real" partitions.

What do you need 7 bits for? I'm guessing you only need perhaps 3 bits 
if you want 8 partitions, so are the others for carry?
> 
>>> https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/decoder/power_decoder.py;hb=HEAD
>>>
>> Had a brief look at the code, nMigen did start pretty far down, most of
>> the start is data structure setup.
> 
> ridiculous, isn't it? 99% of it is python.  you actually have to look
> *really hard*
> to find actual nmigen AST.
> 
> if this were a "normal" industry-standard project, the ISA decoder would
> have been written out explicitly "by hand", wouldn't it?
> in the actual "language" of the project, yeh?
> 
> like this:
> 
> https://github.com/antonblanchard/microwatt/blob/master/decode1.vhdl
Ah yes, don't you like all of those repeated entries? Doing that by hand 
(even with copy-paste) sounds like great fun...

> i went, "oo that looks like a CSV file, let's *make* it a CSV file and
> then it can be machine-read elsewhere"
Sounds like a sane thing to do. I think data re-organisation in general 
seems to be difficult for a lot of disciplines, apart from software 
engineers. For example, instead of seeing that ISA decoder as a table 
that could be manipulated in whichever way, seeing it only as a VHDL 
constant array.

> i cannot count the number of Dilbert cartoons i've read on this theme...
> Comedy is the best way to pass along the truth eh?

> with the SIMD thing we'll reaaaallly have to do a walk-through of the
> resultant HDL because it risks expanding out of control.
> 
Are we able to reuse the formal verification done at python level for 
the synthesised SOC?

> i remember someone doing operator-overloads in c++ (pointers,
> casts), and wondering why their code wasn't running very fast,
> and a more senior engineer taking them through it in a debugger,
> single-stepping down the chain of overloads, dozens of levels...
> Ah, someone OOP'd too hard? Hahaha

>> C++ still terrifies me a little. Almost like Javascript and Java, C++'s
>> abstract concepts have almost nothing to do with C, and with each
>> release they seem to pile up more and more.
> 
> sigh. i loved c++ when it was Bjarne Strousup's 2nd Edition book.
A Tour of C++, Second Edition? I'll put that on my reading list.

> the templating libraries have gotten waaay out of hand since then.
> 
>> Didn't the first C++
>> compilers take a really long time before they became viable?
> 
> my first exposure to c++ was i think borland's compiler.  1992.
So much history in computing, so little time...
https://en.wikipedia.org/wiki/Borland

>> Do you mean add the mail archive link to the tutorial page?
> 
> yes.  usually we do a "links" section bullet-points at the top.
Added.

> 
>>   > and one about the reason why to use "show top"
>> And as for "show top" do you want an explanation ("block diagram is
>> useful for visualising the internal architecture and compare with
>> code...etc.")?
> 
> if *you* think it would be helpful - to you - and to others - then yes.
Added. Realised only after watching your recent OpenPOWER course video 
that you can select the hierarchy to view with "show".