[libre-riscv-dev] [Bug 64] data handling / io control / data routing API needed

bugzilla-daemon at libre-riscv.org bugzilla-daemon at libre-riscv.org
Sat Apr 27 20:38:01 BST 2019


--- Comment #22 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jacob Lifshay from comment #8)

> > * Data.eq not Data.assign is better, although just "eq" is preferred
> >   (which can be used as "from import library import data" then
> > "data.eq(...)")
> I'm using Data as a place to stash lots of Data-related static functions. We
> can switch to a module if you like.

 temporarily nmoperator.py (would like it to be e.g. nmutils.operator)


 amazingly, only 3 or 4 actual functions are needed.  eq, shape and cat
 are three key functions:

 * eq is obvious [at least, if nmigen's eq is understood, it's obvious]

 * shape and cat are needed in order to flatten data down and back out
   to and from a straight signal.

 shape and cat get used inside the FIFOControl object (which in turn
 uses that excellent Queue module that you wrote).

 shape() is used to find out, from the *recursively-iterable*
 thing-of-Value-derivatives, what size of Signal() would be needed to store it
 (as a sequence of bits)

 cat() is used to flatten() and *de*-flatten() the incoming and outgoing
 hierarchy-of-Value-derivatives so that ONLY ONE Queue object is needed.

 without cat() and shape() it would be an awful mess-of-code, analysing
 the data and recursively allocating (*and connecting up*) a massive suite
 of Queue objects.

 this prospect was so dreadful that i added the two extra functions to the
 data-handling API.

 if it wasn't for that, the data-handling API would *literally* be one


You are receiving this mail because:
You are on the CC list for the bug.

More information about the libre-riscv-dev mailing list