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{Saving time and money for SoC / EC designers\\
21 in the RISC-V Ecosystem and beyond
}\\
23 \Large{[proposed for
] Chennai
9th RISC-V Workshop
}\\
30 \frame{\frametitle{Credits and Acknowledgements
}
33 \item TODO
\vspace{10pt
}
38 \frame{\frametitle{Glossary
}
41 \item GPIO: general-purpose reconfigureable I/O (Input/Output).
42 \item Pin: an I/O pad. May be driven (input) or may drive (output).
43 \item FN: term for a single-wire "function", such as UART
\_TX,
44 I2C
\_SDA, SDMMC
\_D0 etc. may be an input, output or both
45 (bi-directional case: two wires are
{\it always
} allocated, one
46 for input to the function and one for output from the function).
47 \item Bus: a group of bi-directional functions (SDMMC D0 to D3)
48 where the direction is ganged and
{\it under the Bus's control
}
49 \item Input Priority Muxer: a multiplexer with N selector
50 wires and N associated inputs. The lowest (highest?) indexed
51 "selector" enabled results in its
52 input being routed to the output.
53 \item Output Muxer: a many-to-one "redirector" where any one
54 input is "routed" to the output, based on a selector "address".
59 \frame{\frametitle{Why, How and What is a Pinmux?
}
62 \item Why? To save cost, increase yield, and to target multiple
63 markets with the same design, thereby increasing uptake
64 and consequently taking advantage of volume pricing.
\vspace{4pt
}
66 Summary: it's all about making more money!
\vspace{4pt
}
67 \item How? By multiplexing many more functions (
100 to
1,
200) than there
68 are actual available pins (
48 to
500), the required chip package
69 is far less costly and the chip more desirable
\vspace{4pt
}
70 \item What? A many-to-many dynamically-configureable router of
71 I/O functions to I/O pins
73 \bf{Note: actual muxing is deceptively simple, but like a DRAM cell
74 it's actually about the extras (routing, docs, specs etc).\\
75 Just as DRAM Cell != DDR3/
4, Muxer Cell != Pinmux
}
79 \frame{\frametitle{What options are available (at time of writing)?
[1]}
82 {\bf Commercial licensed
}:
86 \item Flexibility: unknown.
87 \item Language: unknown.
88 \item Capability for auto-generation of Docs: unknown.
89 \item Capability for auto-generation of ancillary resources: unknown.
90 \item Suitability for wide range of systems: unknown.
92 \item Suitability for saving RISC-V ecosystem money:
{\bf NONE
}
93 \item Suitability for collaboration:
{\bf ZERO
} (i.e. don't bother)
96 Commercial licensees are isolated and cut off from the benefits
97 and resources of the Libre world. Translation: USD \$
200k+ NREs.
101 \frame{\frametitle{What options are available (at time of writing)?
[2]}
104 {\bf SiFive IOF (Freedom E310, Unleashed U540)
}:
108 \item Flexibility: not so good.
109 \item Language: chisel3.
110 \item Capability for auto-generation of Docs: none.
111 \item Capability for auto-generation of ancillary resources: partial.
112 \item Suitability for wide range of systems: not so good.
114 \item Suitability for saving RISC-V ecosystem money:
{\bf Low
}\\
115 \item Suitability for collaboration:
{\bf GOOD
} (but: written in Chisel3)
118 Using SiFive IOF has Libre benefits, but it's incomplete and
119 harder to find Chisel3 programmers (than e.g. for python).
123 \frame{\frametitle{What options are available (at time of writing)?
[3]}
128 None. No suitable
\vspace{20pt
}\\
129 Libre-licensed
\vspace{20pt
}\\
130 pinmux exists
\vspace{20pt
}
133 (which is really weird, given how there's so many libre UART,
134 SPI and other peripheral libraries, even libre-licensed PCIe and
135 SATA PHYs and even USB3 Pipe, hence the reason for this initiative)
141 \frame{\frametitle{Associated Extras
}
144 \item Design Specification (what markets to target)
145 \item Scenario analysis (
{\bf whether
} the chip will fit "markets")
146 \item Documentation: Summary sheet, Technical Reference Manual.
148 \item Control Interface (AXI4 / Wishbone / TileLink / other)
150 \item Linux kernel drivers, DTB, libopencm3, Arduino libraries etc.
154 \item Shakti M-Class has
160 pins with a
99.5\% full
4-way mux
155 \item Almost
640-way routing,
6 "scenarios" (
7th TBD),
156 100+ page Manual needed,
157 \bf{17,
500 lines of auto-generated code
}
166 ALL of these
\vspace{20pt
}\\
167 can be
\vspace{20pt
}\\
168 auto-generated
\vspace{30pt
}
171 (from the Design Specification, after Scenario Analysis)
177 \frame{\frametitle{Example:
7 banks,
4-way mux,
160 pins
}
179 \includegraphics[height=
1.5in
]{example_pinmux.jpg
}\\
180 7 "banks" with separate VCC. Each no more than
32 bits
183 \item { \bf 17,
500 lines of auto-generated HDL (and climbing)
}
184 \item { \bf 12,
500 lines of auto-generated Summary/Analysis
}
185 \item Technical Reference Manual expected to be
100+ pages
190 \frame{\frametitle{Reduce workload, reduce duplication, reduce risk and cost
}
193 \item Auto-generate everything: documentation, code, libraries etc.
195 \item Standardise: similar to PLIC, propose GPIO and Pinmux\\
196 saves engineering effort, design effort and much more
198 \item Standardise format of configuration registers:
199 saves code duplication effort (multiple software environments)
201 \item Add support for multiple code formats: Chisel3 (SiFive IOF),
202 BSV (Bluespec), Verilog, VHDL, MyHDL.
204 \item Multiple auto-generated code-formats permits cross-validation:\\
205 auto-generated test suite in one HDL can validate a muxer
206 generated for a different target HDL.
212 \frame{\frametitle{Design Spec and Scenario Analysis
}
215 \item Analyse the target markets (scenarios) that the chip will sell in\\
216 (multiple markets increases sales volume, reduces chip cost)
218 \item Scenarios represent target markets: ICs to be connected\\
219 (GPS, NAND IC, WIFI etc. May require prototype schematics
220 drawn up, or client-supplied schematics analysed).
222 \item Create a formal (python-based) specification for the pinmux
224 \item Add scenarios (in python), check that they meet requirements\\
225 { \bf (before spending money on hardware engineers!)
}
227 \item Analyse the scenarios: if pins are missing, alter and repeat.\\
229 \item Eventually the pinmux meets all requirements...\\
230 { \bf without spending USD \$
5-
50m to find out it doesn't!
}
236 \frame{\frametitle{Muxer cases to handle (One/Many to One/Many) etc.
}
239 \item One FN outputs to Many Pins: no problem\\
240 (weird configuration by end-user, but no damage to ASIC)
241 \item One Pin to Many FN inputs: no problem\\
242 (weird configuration by end-user, but no damage to ASIC)
243 \item Many Pins to One FN input:
{\bf Priority Mux needed
}\\
244 No priority mux: Pin1 = HI, Pin0 = LO, ASIC is damaged
245 \item Many FN outputs simultaneously to one Pin:
{\bf does not occur
}\\
246 (not desirable and not possible, as part of the pinmux design)
247 \item Some FNs (I2C
\_SDA, SD
\_D0.
.3) are I/O Buses\\
248 Bi-directional control of the Pin must be handed to the
250 \item Nice to have: Bus sets pintype, signal strength etc.\\
251 e.g. selecting SD/MMC doesn't need manual pin-config.\\
252 \bf{caveat: get that wrong and the ASIC can't be sold
}
257 \frame{\frametitle{Pin Configuration, input and output
}
259 In/out:
{\bf Note: these all require multiplexing
}
261 \item Output-Enable (aka Input disable): switches pad to In or Out
262 \item Output (actually an input wire controlling pin's level, HI/LO)
263 \item Input (actually an output wire set based on pin's driven level)
265 Characteristics:
{\bf Note: these do not require multiplexing
}
267 \item Output current level:
10mA /
20mA /
30mA /
40mA
268 \item Input hysteresis: low / middle / high. Stops signal noise
269 \item Pin characteristics: CMOS Push-Push / Open-Drain
270 \item Pull-up enable: built-in
10k (
50k?) resistor
271 \item Pull-down enable: built-in
10k (
50k?) resistor
272 \item Muxing and IRQ Edge-detection not part of the I/O pin
273 \item Other? (impedance? not normally part of commercial pinmux)
278 \frame{\frametitle{Standard GPIO
4-way in/out Mux and I/O pad
}
280 \includegraphics[height=
2.5in
]{../shakti/m_class/mygpiomux.jpg
}\\
281 {\bf 4-in,
4-out, pullup/down, hysteresis, edge-detection (EINT)
}
285 \frame{\frametitle{Separating Pin Configuration, input and output
}
288 \item Standard Mux design
{\bf cannot deal with many-to-one inputs
}\\
289 (SiFive IOF source code from Freedom U310 cannot, either)
291 \item I/O pad configuration conflated with In-Muxer conflated with
292 Out-Muxer conflated with GPIO conflated with EINT.
295 {\bf IMPORTANT to separate all of these out:
298 \item EINTs to be totally separate FNs. managed by RISC-V PLIC\\
299 (If every GPIO was an EINT it would mean
100+ IRQs)
301 \item GPIO In/Out/Direction treated just like any other FN\\
302 (but happen to have AXI4 - or other - memory-mapping)
304 \item Pad configuration separated and given one-to-one Registers\\
305 (SRAMs set by AXI4 to control mux, pullup, current etc.)
309 \frame{\frametitle{Register-to-pad "control" settings
}
311 \includegraphics[height=
2.5in
]{reg_gpio_cap_ctrl.jpg
}\\
312 {\bf pullup/down, hysteresis, current, edge-detection
}
317 \frame{\frametitle{GPIO (only): Simplified I/O pad Diagram (FN only)
}
319 \includegraphics[height=
2.5in
]{reg_gpio_pinblock.jpg
}\\
320 {\bf 3 wires: IN, OUT, OUTEN (also = !INEN)
}
325 \frame{\frametitle{Output Muxer (very simple)
}
327 \includegraphics[height=
1.1in
]{reg_gpio_out_mux.jpg
}\\
328 {\bf Ouput Muxer using
2-bit address selection
}\\
331 \item Very straightforward (deceptively so, like SRAM cells)
332 \item Used in both OUT routing and Direction-control routing\\
333 (same address for each, connected to same FNs)
334 \item More complex pinmux will have
3-bit addressing (
8 FNs)\\
335 (Note: not all outputs will be connected, depends on pinmux)
340 \frame{\frametitle{In/Out muxing, direction control: GPIO just a FN
}
342 \includegraphics[height=
2.5in
]{reg_gpio_fn_ctrl.jpg
}\\
343 {\bf Note: function can control I/O direction (bus)
}
348 \frame{\frametitle{Direction Control: Function not bi-directional (bus)
}
350 \includegraphics[height=
2.5in
]{reg_gpio_fn_ctrl2.jpg
}\\
351 Note: Function
{\bf does not
} control I/O direction
356 \frame{\frametitle{Output (and OUTEN) Wiring.
2 pins,
2 GPIO,
2 Fns
}
358 \includegraphics[height=
2.5in
]{reg_gpio_out_wiring.jpg
}\\
359 {\bf Reg0 for Pin0, Reg1 for Pin1, Output and OUTEN same mux
}
364 \frame{\frametitle{Input Selection and Priority Muxing
}
366 \includegraphics[height=
0.75in
]{reg_gpio_comparator.jpg
}\\
367 {\bf Muxer enables input selection
}\\
369 \includegraphics[height=
1.25in
]{reg_gpio_in_prioritymux.jpg
}\\
370 {\bf However multiple inputs must be prioritised
}
375 \frame{\frametitle{Input Priority-Mux Wiring: very different from Out-Mux
}
377 \includegraphics[height=
2.5in
]{reg_gpio_in_wiring.jpg
}\\
378 {\bf Pin Mux selection vals NOT same as FN selection vals
}
383 \frame{\frametitle{Input Priority-Mux Wiring
}
386 \item In-Muxer selection number (
0,
1,
2,
3) obviously has to match
387 with Out-Muxer order (otherwise a bi-directional FN
388 needs different Mux-register settings for
389 selecting either IN or OUT)
391 \item Priority-mux selection values do not actually matter,
392 and have nothing to do with the actual Muxer settings.
394 \item GPIO FN's input muxer is nothing more than an AND gate\\
395 (you never route more than one pin to one GPIO)
397 \item Any other FN with only
1:
1 on its IN also just an AND gate \\
398 (this just always happens to be true for GPIO)
400 \item Not all FNs have input capability: clearly they will not
401 be included in the In-Muxing.
406 \frame{\frametitle{Summary
}
409 \item Value of Libre/Open pimux dramatically underestimated\\
410 (and does not presently exist: SiFive's IOF not suitable as-is)\\
411 {\bf Only current option: license a commercial Pinmux
}
412 \item Actual muxing (like SRAM cells) is deceptively simple
413 \item Actual pinmuxes are enormous: auto-generation essential
414 \item HDLs completely unsuited to auto-generation task\\
415 (TRM, docs):
{\bf Modern OO language needed i.e. python
}
416 \item Scenario Analysis / Verification and auto-generation of
417 different HDLs far easier in a Modern OO language\\
418 (better libraries, more developers)
419 \item Standardisation for RISC-V saves implementors from huge
420 duplication cost (HDL, firmware, docs, maintenance)
421 \item { \bf Ultimately it's about saving money and reducing risk
}
428 {\Huge The end
\vspace{20pt
}\\
429 Thank you
\vspace{20pt
}\\
430 Questions?
\vspace{20pt
}
435 \item http://libre-riscv.org/shakti/m
\_class/pinmux/