[Librecores Discussion] pinmux gsoc2018 proposal

Luke Kenneth Casson Leighton lkcl at lkcl.net
Sat Jan 27 23:38:28 CET 2018


On Wed, Jan 24, 2018 at 10:39 PM, Luke Kenneth Casson Leighton
<lkcl at lkcl.net> wrote:

>  ok so i was thinkng more along the lines of a straight keyboard-style
> matrix.  functions on rows, pinmux on columns.  this would be naive
> but perhaps very very simple.  there are three cases where "clashes"
> would occur.
>
>  * two or more inputs mux to the same pad
>  * two or more *outputs* mux to the same pad
>  * a mixture of input(s) and output(s) mux to the same pad

 ok so i previously assessed multiple outputs to be a problem, but...
um.. actually... outputs are one-to-many so actually they are in the
same category as inputs!

 as in, i completely misunderstood.

 two or more outputs muxed to the same pad means that they go
*through* the same multiplexer... and thus all 3 (or 7) outputs *not*
selected to go through to the pad will in fact be completely ignored.

 likewise from the perspective of a function which is selected to be
outputted to multiple pads, you simply do not care about this: it's a
bit odd but will cause NO damage to the SoC.

 so i believe that for all cases, there is nothing special that needs
to be created: no priority muxes.

 also i was mistaken in believing that a keyboard-style matrix would
be needed, you just simply route multiple wires from each function to
each relevant I/O mux input (or output).

 oh wait... there's one more special case to consider, it's when a
function is a "broadcaster" i.e. has both input *and* output
capabilties / requirements.  such as I2C SDA, which can be pulled by
either end.

 damn, that complicates things, doesn't it? :)  might take me another
couple days to think that one through.  maybe even draw it at the gate
level.  love to hear peoples' thoughts here.

l.


More information about the Discussion mailing list