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

[bugzilla-daemon at libre-riscv.org]

http://bugs.libre-riscv.org/show_bug.cgi?id=64

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

> > * the name "EntryPort" begins with the letter E, and so does "ExitPort".
> >   this is problematic from a clarity perspective in later usage
> >   (see below)
> I wanted to pick a name pair other than input/output to avoid confusion with
> the signal directions.
> What about ingress/egress, from/to, upstream/downstream, or next/previous?

 from/to - from is a python keyword. ingress/egress too pretentious .. :)
 upstream/downstream ok, next/previous is ok.

> Or do you think input/output will be fine?

 i am horribly confused by input/output, because the direction of
 each of ready/valid is different and opposite for input/ingress/from/upstream
 compared to output/egress/to/downstream/next.

 p and n are sufficiently radically different letters from o and i that the
 four combinations are abundantly clear.

 (basically, i have a very mild form of dyslexia)

 p.ready_i
 p.valid_o
 n.ready_o
 n.valid_i

 these are *really* clear to me.  the vertical alignment seems to do something
 that breaks the (mild) dyslexia.


 i.ready_i
 i.valid_o
 o.ready_o
 o.valid_i

 i have absolutely *no* idea what's going on.  which one's input? what's the
 output? which one is for ready to the output? which output?  is that output
 from the stage? or is it output from the signal...

 total utter confusion.

 similarly with connect_to_entry and connect_to_exit.  both beginning with "e"
 and both having "to" and "from", i can stare at the piece of code for ten
 to twenty minutes and not understand it.

 the use of a totally different word ("connect_in") and the inclusion of
 an underscore (on the one that's *not* supposed to be used to connect
 stage-to-stage) is sufficient to indicate "this is a private function"
 and the logic/letter-based dyslexia is broken.


> > * use of Data.assign for ready_in/out and valid_in/out, they should just
> >   be an eq.
> They can't be a member function because Record.eq doesn't work (the
> simulator doesn't handle it),

 i was referring only to ready_in/out and valid_in/out, not Data in/out.
 ready_in/out are pure signals (not Data), and therefore eq works fine.
 (i.e. it's just Signal.eq, not Data.eq and not Record.eq)


> though I guess we could reassign Record.eq to
> a custom function that does work. 

 whilst Record has been "fixed", i will be absolutely bluntly honest: i am
 not happy to be beholden to the way that nmigen's development is being
 handled.

 we are at the mercy of not just whether they *decide* to fix a problem,
 even more than that, the main developer has expressed a clear and
 unequivocable hatred of python, a disregard for standard python
 conventions that have taken over twenty years to establish, and expects
 *python* to fix its "problems" rather than understand that not following
 its long-established conventions has massive detrimental knock-on effects
 on its users.

 i was extremely shocked to be told, on mentioning the (many) dangers of
 use of python wildcard imports, "python should not have been designed to
 be problematic, they should go fix that, it's not my problem".


 the global eq(), shape() and cat() functions (now moved to nmobject.py
 pending a decision) are under *our* control.

 Record.eq is not.

 i have already had to add workarounds into both eq() and cat() that
 take into consideration both bugs in nmigen and intransigence in its
 key developer.

 we cannot have our entire project at the mercy of a team that is overloaded
 and does not understand or respect python conventions, and who have
 demonstrated an irrational and pathological unwillingness to listen.

 this said despite the fact that nmigen is otherwise extremely good,
 and, i believe, worth sticking with.

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