[Librecores Discussion] pinmux gsoc2018 proposal
Luke Kenneth Casson Leighton
lkcl at lkcl.net
Wed Jan 24 23:39:47 CET 2018
hi john aka ouabache, just wanted to say i'm really delighted to have
your input here.
On Wed, Jan 24, 2018 at 5:00 PM, Ouabache Designworks
<z3qmtr45 at gmail.com> wrote:
>> > Request/Grant handshake:: Multiple requests can occur at the same time
>> > and
>> > control goes to the highest priority.
>> requests? you mean that people could mis-configure the pinmux and
>> allocate two functions to the exact same pin? whether it be input
>> *or* output?
>> i would define that to be "out of scope" i.e. a programmer error but
>> there should definitely be no chance of damage to the ASIC if
>> someone's dumb enough to try it.
>> or did you mean something else?
> This is why firmware engineers hate it when hardware engineers design the
> memory maps.
ok so i've seen quite a lot of pinmux memory maps, from STM32Fs to
ATSAMs to Allwinner A20 and A64s, to Rockchip RK3xxx series, TI OMAPs,
Freescale iMXns, Intel PXAs, they all tend to have a consistent theme.
> A hardware engineer is likely to create one set of control status registers
> to control all the pin
> muxing control lines from one place.
ok one key difference i have noted is that in some cases - i think it
was the Intel PXA270s - was that pin status registers were grouped in
pairs. at the time i thought this was really odd, what the heck would
you make only *two* pins side-by-side so that the code for programming
them was really damn awkward, not a straighforward GPIO_READ_BIT(x) =
1<<x or anything like that but a REALLY painful set of & and |
am i correct in thinking, what you're saying is, then, that when it
comes to de-multiplexing the hardware address it's a heck of a lot
less gates than the "standard" way of doing things (bit_offset = 1<<x)
is that right?
or am i still missing the point?
> The firmware engineer now has to manage this as a shared resource to ensure
> that the 50 or so
> different functions trying to change the muxing do not mess each other up.
i don't believe i am following you and i defintely want to understand.
> The firmware engineer would rather you distribute the pin mux control to
> each of the pad sources.
do you know of an example (with a suitable Technical Reference
Manual) that illustrates exactly what you would consider to be an
ideal set of control status registers?
this would help me to understand exactly where you're coming from.
> So if you had a Uart that could be muxed out then that uart had a Pin_Req
> bit in its control register
> that firmware could set when it wanted to use that uart. The pin muxing
> would look at all the different
> requests for each pad and issue a grant to the highest priority request. The
> uart would not send or receive
> unless it had received a grant.
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"
* 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
now, inputs, clearly, if someone is silly enough to mux one pad to
multiple inputs, so what, big deal, a UART RX and a MOSI pin get
activated, both UART and SPI get terribly confused, but so what.
outputs... *now* we have a problem. *ON CHIP*, a UART (Open Drain)
RX tries to drive the pin low, whilst a MISO (Push-Push) pin tries to
drive it high... now we're in trouble, the gates are effectively
short-circuited and it'll cause a lot of damage if we're not careful.
mixture of inputs and outputs, the inputs are ok ("ok" as in "won't
get damaged"), as long as there's only one output. when you have one
or *more* outputs, that's when the problems start.
so what would you suggest would be a way to protect outputs, in a way
that *at the same time* does not result in significant latency added?
can a priority-based mux be done with only 2 gates worth of latency?
would adding low-power drivers do the trick? or, is there some kind
of gate driver - bear in mind some functions will be OD and some will
be Push-Push - that doesn't mind conflict / clashes? surely this is
something that's been solved, already, somewhere :)
or, how about simply generating some logic (which is easy enough to
do) that prevents and prohibits certain combinations of patterns from
being programmed into the registers? that would have the advantage of
not introducing gate delay yet still protect the functions.
>> > Fast path for main function:: The pads main function is the most
>> > important
>> > signal but it only controls the pad when no one
>> > else wants it. You want it one mux level from the pad and must not have
>> > to
>> > go through a bunch of muxes.
>> yehyeh absolutely... or are you referring to how the mux is
>> implemented? i.e. if it's a 4-way mux it should not be done as a
>> cascade of 2 layers of 2-way crossbars but should be done as 4
>> separate AND/NAND gates with selection(s) of NOTs or straight inputs,
>> is that what you're referring to?
> If you implement this as a straight cascaded priority mux then the main
> has to traverse a number number of muxes before connecting to the pad.
> when the main function is in control and give it a fast path to the pad
all functions will be "main" or do you mean "main" as in "the one
that's currently connected"?
if it's absolutely necessary to use a cascaded priority mux, some of
the functions will definitely not be high-speed: UART is a max of
around 2.5mbits/sec, I2C 400khz, but SPI is 25mhz and SD/MMC 4.0 is
what... 50mhz? 100mhz? RGB/TTL can go as high as 300mhz for 1080p60,
and i also have a use-case for FlexBus / ATI / AT / SDRAM
> Be real careful with JTAG since it has to work even when nothing else on the
> works. Arm did a JTAG interface that worked great if your system clock was
> running but
> if it wasn't then your JTAG was useless and you couldn't debug why your
> system clock
> didn't work.
> You design your clocksys so that a JTAG command can force it to use the jtag
> clock for
> the system clock to help debug .
ok that's extremely good advice, i'll remember that.
More information about the Discussion