1 \documentclass[slidestop
]{beamer
}
2 \usepackage{beamerthemesplit
}
6 \title{Pin Multiplexer
}
8 \author{Luke Kenneth Casson Leighton
}
15 \huge{Pin Multiplexer
}\\
17 \Large{Auto-generating documentation, code \\
18 and resources for a Pinmux
}\\
20 \Large{[proposed for
] Chennai
9th RISC-V Workshop
}\\
27 \frame{\frametitle{Credits and Acknowledgements
}
30 \item TODO
\vspace{10pt
}
35 \frame{\frametitle{Glossary
}
38 \item GPIO: general-purpose reconfigureable I/O (Input/Output).
39 \item Pin: an I/O pad. May be driven (input) or may drive (output).
40 \item FN: term for a single-wire "function", such as UART
\_TX,
41 I2C
\_SDA, SDMMC
\_D0 etc. may be an input, output or both
42 (bi-directional case: two wires are always allocated, one
43 for input to the function and one for output from the function).
44 \item Bus: a group of bi-directional functions (SDMMC D0 to D3)
45 where the direction is ganged and under the Bus's control
46 \item Input Priority Muxer: a multiplexer with N selector
47 wires and N associated inputs. The lowest (highest?) indexed
48 "selector" enabled results in its
49 input being routed to the output.
50 \item Output Demuxer: a one-to-many "redirector" where a single
51 input is "routed" to any one output, based
57 \frame{\frametitle{Why, How and What is a Pinmux?
}
60 \item Why? To save cost, increase yield, and to target multiple
61 markets with the same design, thereby increasing uptake
62 and consequently taking advantage of volume pricing.
\vspace{4pt
}
64 Summary: it's all about making more money!
\vspace{4pt
}
65 \item How? By multiplexing many more functions (
100 to
1,
200) than there
66 are actual available pins (
48 to
500), the required chip package
67 is far less costly and the chip more desirable
\vspace{4pt
}
68 \item What? A many-to-many dynamically-configureable router of
69 I/O functions to I/O pins
\vspace{4pt
}
70 \item \bf{Note: actual muxing is deceptively simple, but like
71 a DRAM cell it's actually about the ancillaries / extras
}
76 \frame{\frametitle{Associated Extras
}
79 \item Design Specification
80 \item Scenario analysis (whether the chip will fit "markets")
81 \item Documentation: Summary sheet, Technical Reference Manual.
83 \item Control Interface (AXI4 / Wishbone / TileLink / other)
85 \item Linux kernel drivers, DTB, libopencm3, Arduino libraries etc.
89 \item Shakti M-Class has
160 pins with a
99.5\% full
4-way mux
90 \item Almost
640-way routing,
6 "scenarios" (
7th TBD),
91 100+ page Manual needed,
92 \bf{17,
500 lines of auto-generated code
}
101 ALL of these
\vspace{20pt
}\\
102 can be
\vspace{20pt
}\\
103 auto-generated
\vspace{30pt
}
106 (i.e. it would be insanely costly to do them by hand)
111 \frame{\frametitle{Reduce workload, reduce duplication, reduce risk and cost
}
114 \item Auto-generate everything: documentation, code, libraries etc.
116 \item Standardise: similar to PLIC, propose GPIO and Pinmux
118 \item Standardise format of configuration registers:
119 saves code duplication effort (multiple software environments)
121 \item Add support for multiple code formats: Chisel3 (SiFive IOF),
122 BSV (Bluespec), Verilog, VHDL, MyHDL.
124 \item Multiple auto-generated code-formats permits cross-validation:\\
125 auto-generated test suite in one HDL can validate a muxer
126 generated for a different target HDL.
131 \frame{\frametitle{Muxer cases to handle (One/Many to One/Many) etc.
}
134 \item One FN outputs to Many Pins: no problem\\
135 (weird configuration by end-user, but no damage to ASIC)
136 \item One Pin to Many FN inputs: no problem\\
137 (weird configuration by end-user, but no damage to ASIC)
138 \item Many Pins to One FN input:
{\bf Priority Mux needed
}\\
139 No priority mux: Pin1 = HI, Pin0 = LO, ASIC is damaged
140 \item Many FN outputs simultaneously to one Pin:
{\bf does not occur
}\\
141 (not desirable and not possible, as part of the pinmux design)
142 \item Some FNs (I2C
\_SDA, SD
\_D0.
.3) are I/O Buses\\
143 Bi-directional control of the Pin must be handed to the
145 \item Nice to have: Bus sets pintype, signal strength etc.\\
146 e.g. selecting SD/MMC doesn't need manual pin-config.\\
147 \bf{caveat: get that wrong and the ASIC can't be sold
}
152 \frame{\frametitle{Pin Configuration, input and output
}
154 In/out:
{\bf Note: these all require multiplexing
}
156 \item Output-Enable (aka Input disable): switches pad to In or Out
157 \item Output (actually an input wire controlling pin's level, HI/LO)
158 \item Input (actually an output wire set based on pin's driven level)
160 Characteristics:
{\bf Note: these do not require multiplexing
}
162 \item Output current level:
10mA /
20mA /
30mA /
40mA
163 \item Input hysteresis: low / middle / high. Stops signal noise
164 \item Pin characteristics: CMOS Push-Push / Open-Drain
165 \item Pull-up enable: built-in
10k (
50k?) resistor
166 \item Pull-down enable: built-in
10k (
50k?) resistor
167 \item Muxing and IRQ Edge-detection not part of the I/O pin
172 \frame{\frametitle{Standard GPIO
4-way in/out Mux and I/O pad
}
174 \includegraphics[height=
2.5in
]{../shakti/m_class/mygpiomux.jpg
}\\
175 {\bf 4-in,
4-out, pullup/down, hysteresis, edge-detection (EINT)
}
179 \frame{\frametitle{Pin Configuration, input and output
}
182 \item Standard Mux design
{\bf cannot deal with many-to-one inputs
}\\
183 (SiFive IOF source code from Freedom U310 cannot, either)
185 \item I/O pad configuration conflated with Muxer conflated with GPIO
188 \item Need to separate all of these out
190 \item EINTs to be separate FNs (managed by RISC-V PLIC)
192 \item GPIO In/Out/Direction treated just like any other FN
194 \item Pad configuration separated and given one-to-one Registers
198 \frame{\frametitle{Register-to-pad "control" settings
}
200 \includegraphics[height=
2.5in
]{reg_gpio_cap_ctrl.jpg
}\\
201 {\bf pullup/down, hysteresis, current, edge-detection
}
206 \frame{\frametitle{In/Out muxing, direction control
}
208 \includegraphics[height=
2.5in
]{reg_gpio_fn_ctrl.jpg
}\\
209 {\bf Note: function can control I/O direction
}
214 \frame{\frametitle{Simplified I/O pad Block Diagram
}
216 \includegraphics[height=
2.5in
]{reg_gpio_pinblock.jpg
}\\
217 {\bf 3 wires: IN, OUT, OUTEN (also = !INEN)
}
222 \frame{\frametitle{Output (and OUTEN) Wiring.
2 pins,
2 GPIO,
2 Fns
}
224 \includegraphics[height=
2.5in
]{reg_gpio_out_wiring.jpg
}\\
225 {\bf Reg0 for Pin0, Reg1 for Pin1, Output and OUTEN same mux
}
230 \frame{\frametitle{Input Selection and Priority Muxing
}
232 \includegraphics[height=
0.75in
]{reg_gpio_comparator.jpg
}\\
233 {\bf Muxer enables input selection
}\\
235 \includegraphics[height=
1.25in
]{reg_gpio_in_prioritymux.jpg
}\\
236 {\bf However multiple inputs must be prioritised
}
241 \frame{\frametitle{Input Mux Wiring
}
243 \includegraphics[height=
2.5in
]{reg_gpio_in_wiring.jpg
}\\
244 {\bf Pin Mux selection vals NOT same as FN selection vals
}
249 \frame{\frametitle{Summary
}
259 {\Huge The end
\vspace{20pt
}\\
260 Thank you
\vspace{20pt
}\\
261 Questions?
\vspace{20pt
}
266 \item http://libre-riscv.org/shakti/m
\_class/pinmux/