[Libre-soc-dev] nmigen tutorials etc.
Luke Kenneth Casson Leighton
lkcl at lkcl.net
Thu Oct 14 15:26:23 BST 2021
On Thu, Oct 14, 2021 at 12:59 PM Andrey Miroshnikov
<andrey at technepisteme.xyz> wrote:
> Searched web.archive.org, could not find these as they were not backed
> up by the wayback machine:
> It's probably not critical, as I did find similar equivalents.
> 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?
now you're getting it. exactly right.
where the "context" is created by a compile-time switch that goes
into issuer_verilog.py as a command-line option.
> >> 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,
nope. 3 bits you're thinking in binary. illustrated here with a 32-bit example
with 3 partition bits.
* 3 partition bits divides an otherwise "normal" Signal into 3+1=FOUR partitions
* 7 partition bits divides an otherwise "normal" Signal into 7+1=EIGHT
> > 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...
exactly, and you could make mistakes or transcription errors.
in 200 lines of highly detailed tables with 15 columns.
where any one of those results being wrong results in catastrophic
consequences such as (if used in an Engine Controller) the engine
seizing up or going into reverse when the driver is on a motorway
> 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.
it is however a level of abstraction that can result in a significant cost
burden (i.e.: having to explain it)
however given in this particular case that we can use python to *filter out*
both rows *and columns*, creating quite literally completely different
PowerDecoder() instances suitable for "satellite" decoding and thus save
massively on both development time and gate count, it's worth the risk.
in case you missed that: yes, you can pass in a filter function on
PowerDecoder for example:
return row['FunctionUnit'] == 'ALU'
this will, obviously, *only* give you a PowerDecoder which is capable of
recognising - and decoding - all and any instructions related to the ALU
pipeline and no others.
this results in a dedicated "satellite" PowerDecoder *specifically* for
use by the ALU pipeline, wihch is only say 500 gates *NOT* 8,000
> Are we able to reuse the formal verification done at python level for
> the synthesised SOC?
if by that you mean, "if we do formal verification at the python level
(using symbiyosys via nmigen) will the HDL that goes into an SoC
be considered "formally verified"" then the answer is: of course.
> > 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.
this was 1991 so it's been massively updated since then. looks like
it's up to the 4th edition:
> Added. Realised only after watching your recent OpenPOWER course video
> that you can select the hierarchy to view with "show".
yes. type "show" press space press tab twice.
More information about the Libre-soc-dev