[Librecores Discussion] pinmux gsoc2018 proposal

Luke Kenneth Casson Leighton lkcl at lkcl.net
Wed Jan 24 07:58:07 CET 2018


On Tue, Jan 23, 2018 at 4:59 PM, Ouabache Designworks
<z3qmtr45 at gmail.com> wrote:


> On Tue, Jan 23, 2018 at 6:16 AM, Luke Kenneth Casson Leighton
> <lkcl at lkcl.net> wrote:
>>
>> http://rhombus-tech.net/riscv/shakti/m_class/gsoc2018/
>>
>> wrote up draft proposal
>> _______________________________________________
>> Discussion mailing list
>> Discussion at lists.librecores.org
>> https://lists.librecores.org/listinfo/discussion
>
>
>
> Some additional considerations:

 hi john these are all superb.

> Glitchless muxing::    Pads must never glitch when switched.

 ah!  good point.

> 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?

> 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?


> Jtag mode:: Boundary scan must test mission mode signals going to pad

 ok this i would say would be again out of scope for this
_particlular_ task... unless the student chose to actually implement
JTAG.

 paying attention to JTAG is however a task that *i* will have to do,
and so have been looking at that.

 reset should result in the pinmux being set to a pre-set that allows
JTAG to be routed, in the particular design that i have in mind, as
follows, see http://rhombus-tech.net/riscv/shakti/m_class/pinouts/
pins 126 and 127:

 * JTAG_SEL=0, TEST=0 after RESET select pins 10-13 Mux=3, 52-55 Mux=0
 * JTAG_SEL=1, TEST=0 after RESET select pins 52-55 Mux=3, 10-13 Mux=0
 * JTAG_SEL=x, TEST=1 after RESET select pins 10-13 Mux=0 52-55 Mux=0
and enable boundary scan test mode.

in this way even JTAG can be on the pinmux - it's an extremely common
technique that's deployed across multiple SoCs and embedded
processors... i just don't know precisely and exactly how it's
implemented internally, i just know "it can be done".

l.


More information about the Discussion mailing list