[Libre-soc-bugs] [Bug 762] Peripheral Pin Muxing Development

[bugzilla-daemon at libre-soc.org]

https://bugs.libre-soc.org/show_bug.cgi?id=762

--- Comment #9 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Andrey Miroshnikov from comment #8)

> At the moment csrbus only connects the first byte of the data word. Is this
> how you expect it to be?

well, there are two schools of thought on that one.

1) each instance is one and only one IOpad.  you therefore have to
instantiate multiple GPIO instances

2) each instance deals with N IOpads, and has N as an argument, specifying
   the length of the array.

> Should I extend csrbus to store the full word
> (several gpio configs)?

if you go for option (2) then yes, of course.

option (1) would be very wasteful of IO memory address space because each
GPIO aka IOpad would need to be allocated to an entire Wishbone-wide line.
or some form of complicated Arbiter/Mapper would be needed
[which is actualy part of nmigen-soc but let's leave that alone for now,
because it's completely undocumented and almost impossible to understand
except by its original authors]

> > 
> > however you will need *another* layout which is the actual
> > wires-as-connected-directly-to-the-IOPad-Cell.  that one would
> > not have bank_sel, but would be more like:
> > 
> >          padlayout = (("oe", 1),
> >                       ("i", 1),
> >                       ("o", 1),
> >                       ("puen", 1),
> >                       ("pden", 1),
> >                     )
> What about ie? IOPad assume the GPIO is input if oe is low?

Chips4Makers IOpads, which is what we are targetting, do not have
an "input enable" flag on the public API.

however this is not a "deterrent" or an actual "problem": we will
need a "mapping" system anyway, if you recall.  but, for now, let's
*provide* an ie on the csrbus but *ignore* it as far as connecting
to padlayout is concerned.

sort that out later. get up and running first and increment later

> What do you mean by having the same types as IOTypes?

same [abstract / conceptual] object.  what Signals does a c4mjtag
Record of type "IOType.InTriOut" have?

> Do you mean the layout definition needs to have the '-'/'+'/etc. strings for
> each signal? Like ("oe", 1, '+')

you can work out the answer easily to that for yourself by examining
the source code.

how can the layout definition, Layout, understand that?  where in the
source code is there any evidence of the existence of an import
"from c4mjag import..." in nmigen?  that would create a recursive
import, wouldn't it?

> > but not right away, i suggest just keeping it straightforward and
> > simple, add options later
> Sure, I'll focus on what you mentioned already, plenty to do as is hahaha

:)

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