[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:26:51 BST 2019
--- 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)
these are *really* clear to me. the vertical alignment seems to do something
that breaks the (mild) dyslexia.
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
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
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.
More information about the libre-riscv-dev