[Librecores Discussion] pinmux gsoc2018 proposal

Ouabache Designworks z3qmtr45 at gmail.com
Wed Jan 24 18:00:54 CET 2018


On Tue, Jan 23, 2018 at 10:58 PM, Luke Kenneth Casson Leighton <
lkcl at lkcl.net> wrote:

> 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?
>
>
This is why firmware engineers hate it when hardware engineers design the
memory maps.
A hardware engineer is likely  to create one set of control status
registers to control all the pin
muxing control lines from one place.

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.

The firmware engineer would rather you distribute the pin mux control to
each of the pad sources.

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.

It makes the firmware engineers job a lot easier.






> > 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
function
has to traverse a number number of muxes before connecting to the pad.
Detect
when the main function is in control and give it a fast path to the pad






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

Be real careful with JTAG since it has to work even when nothing else on
the chip
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 .


John Eaton






> _______________________________________________
> Discussion mailing list
> Discussion at lists.librecores.org
> https://lists.librecores.org/listinfo/discussion
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.librecores.org/pipermail/discussion/attachments/20180124/5f1b31dc/attachment.html>


More information about the Discussion mailing list