X-Git-Url: https://git.libre-soc.org/?a=blobdiff_plain;f=pinmux%2Fpinmux_chennai_2018.tex;h=9ca9d640097afe76668327b8faddc0ef1f282e20;hb=5db1e01205aa69eb06cb7f219b9a9884360d4013;hp=76ee65c877e5e3edd8f84051e01f6af38855b4b6;hpb=88d3bd178fc53a30a2120fe2897d6dcc114f9d66;p=libreriscv.git diff --git a/pinmux/pinmux_chennai_2018.tex b/pinmux/pinmux_chennai_2018.tex index 76ee65c87..9ca9d6400 100644 --- a/pinmux/pinmux_chennai_2018.tex +++ b/pinmux/pinmux_chennai_2018.tex @@ -3,7 +3,7 @@ \usepackage{graphics} \usepackage{pstricks} -\title{SIMD} +\title{Pin Multiplexer} \author{Rishabh Jain} \author{Luke Kenneth Casson Leighton} @@ -16,6 +16,9 @@ \vspace{32pt} \Large{Auto-generating documentation, code \\ and resources for a Pinmux}\\ + \vspace{16pt} + \Large{Saving time and money for SoC / EC designers\\ + in the RISC-V Ecosystem and beyond}\\ \vspace{24pt} \Large{[proposed for] Chennai 9th RISC-V Workshop}\\ \vspace{16pt} @@ -35,19 +38,20 @@ \frame{\frametitle{Glossary} \begin{itemize} + \item GPIO: general-purpose reconfigureable I/O (Input/Output). \item Pin: an I/O pad. May be driven (input) or may drive (output). \item FN: term for a single-wire "function", such as UART\_TX, I2C\_SDA, SDMMC\_D0 etc. may be an input, output or both - (bi-directional case: two wires are always allocated, one + (bi-directional case: two wires are {\it always} allocated, one for input to the function and one for output from the function). - \item Input Priority Muxer: a multiplexer that has N selector - wires and N inputs, where the lowest (or highest) indexed - "selector" that is enabled results in its corresponding + \item Bus: a group of bi-directional functions (SDMMC D0 to D3) + where the direction is ganged and {\it under the Bus's control} + \item Input Priority Muxer: a multiplexer with N selector + wires and N associated inputs. The lowest (highest?) indexed + "selector" enabled results in its input being routed to the output. - \item Output Demuxer: a one-to-many "redirector" where a single - input is "routed" to any one of a number of outputs, based - on a selection address. - \item GPIO: general-purpose reconfigureable I/O (Input/Output). + \item Output Muxer: a many-to-one "redirector" where any one + input is "routed" to the output, based on a selector "address". \end{itemize} } @@ -62,25 +66,88 @@ Summary: it's all about making more money!\vspace{4pt} \item How? By multiplexing many more functions (100 to 1,200) than there are actual available pins (48 to 500), the required chip package - is far less costly and the chip more desirable\vspace{4pt} + is cheaper, smaller, and more versatile\vspace{4pt} \item What? A many-to-many dynamically-configureable router of - I/O functions to I/O pins\vspace{4pt} - \item \bf{Note: actual muxing is deceptively simple, but like - a DRAM cell it's actually about the ancillaries / extras} + I/O functions to I/O pins + \end{itemize} + \bf{Note: actual muxing is deceptively simple, but like a DRAM cell + it's actually about the extras (routing, docs, specs etc).\\ + Just as DRAM Cell != DDR3/4, Muxer Cell != Pinmux} +} + + +\frame{\frametitle{What options are available (at time of writing)? [1]} + + \vspace{6pt} + {\bf Commercial licensed}: + \vspace{4pt} + \begin{itemize} + \item Cost: unknown (and ultimately doesn't matter) + \item Flexibility: unknown (NDAs required in order to find out) + \item Language: unknown (NDAs required in order to find out) + \item Capability for auto-generation of Docs: unknown. + \item Capability for auto-generation of ancillary resources: unknown. + \item Suitability for wide range of systems: unknown. + \vspace{4pt} + \item Suitability for saving RISC-V ecosystem money: {\bf NONE } + \item Suitability for collaboration: {\bf ZERO} (prohibitive licensing) \end{itemize} + \vspace{6pt} + Commercial licensees are isolated and cut off from the benefits + and resources of the Libre world. Translation: USD \$200k+ NREs. +} + + +\frame{\frametitle{What options are available (at time of writing)? [2]} + + \vspace{6pt} + {\bf SiFive IOF (Freedom E310, Unleashed U540)}: + \vspace{4pt} + \begin{itemize} + \item License: Good! + \item Flexibility: not so good. + \item Language: chisel3. + \item Capability for auto-generation of Docs: none. + \item Capability for auto-generation of ancillary resources: partial. + \item Suitability for wide range of systems: not so good. + \vspace{4pt} + \item Suitability for saving RISC-V ecosystem money: {\bf Low }\\ + \item Suitability for collaboration: {\bf GOOD} (but: written in Chisel3) + \end{itemize} + \vspace{6pt} + Using SiFive IOF has Libre benefits, but it's incomplete and + harder to find Chisel3 programmers (than e.g. for python). +} + + +\frame{\frametitle{What options are available (at time of writing)? [3]} + + \vspace{10pt} + \begin{center} + {\Huge + None. No suitable\vspace{20pt}\\ + Libre-licensed\vspace{20pt}\\ + pinmux exists\vspace{20pt} + } + \\ + (which is really weird, given how there's so many libre UART, + SPI and other peripheral libraries, even libre-licensed PCIe and + SATA PHYs and even USB3 Pipe. Hence the reason for this initiative) + \end{center} + } \frame{\frametitle{Associated Extras} \begin{itemize} - \item Design Specification - \item Scenario analysis (whether the chip will fit "markets") + \item Design Specification ({\bf what} markets to target) + \item Scenario analysis ({\bf whether} the chip will fit "markets") \item Documentation: Summary sheet, Technical Reference Manual. \item Test suites - \item Control Interface + \item Control Interface (AXI4 / Wishbone / TileLink / other) \item Simulation - \item Linux kernel drivers, DTB, libopencm3, Arduino + \item Linux kernel drivers, DTB, libopencm3, Arduino libraries etc. \end{itemize} Example context: \begin{itemize} @@ -101,24 +168,111 @@ auto-generated\vspace{30pt} } \\ - (translation: it would be insanely costly to do them by hand) + (from the Design Specification, after Scenario Analysis) \end{center} } -\frame{\frametitle{Muxer cases to handle} + +\frame{\frametitle{Example: 7 banks, 4-way mux, 160 pins} + \begin{center} + \includegraphics[height=1.5in]{example_pinmux.jpg}\\ + 7 "banks" with separate VCC. Each no more than 32 bits + \end{center} + \begin{itemize} + \item { \bf 17,500 lines of auto-generated HDL (and climbing)} + \item { \bf 12,500 lines of auto-generated Summary/Analysis} + \item Technical Reference Manual expected to be 100+ pages + \end{itemize} +} + + +\frame{\frametitle{Reduce workload, reduce duplication, reduce risk and cost} + + \begin{itemize} + \item Auto-generate everything: documentation, code, libraries etc.\\ + (including device-tree files, FreeBSD / Linux / RTOS kernel + drivers, Arduino, libopencm3 and other EC firmware libraries) + \vspace{4pt} + \item Standardise: similar to PLIC, propose GPIO and Pinmux\\ + saves engineering effort, design effort and much more + \vspace{4pt} + \item Standardise format of configuration registers: + saves code duplication effort (multiple software environments) + \vspace{4pt} + \item Add support for multiple code formats: Chisel3 (SiFive IOF), + BSV (Bluespec), Verilog, VHDL, MyHDL. + \vspace{4pt} + \item Multiple auto-generated code-formats permits cross-validation:\\ + auto-generated test suite in one HDL can validate a muxer + generated for a different target HDL. + \vspace{4pt} + \end{itemize} +} + + +\frame{\frametitle{Design Spec and Scenario Analysis} + + \begin{itemize} + \item Analyse the target markets (scenarios) that the chip will sell in\\ + (multiple markets increases sales volume, reduces chip cost) + \vspace{4pt} + \item Scenarios represent target markets: ICs to be connected\\ + (GPS, NAND IC, WIFI etc. May require prototype schematics + drawn up, or client-supplied schematics analysed). + \vspace{4pt} + \item Create a formal (python-based) specification for the pinmux + \vspace{4pt} + \item Add scenarios (in python), check that they meet requirements\\ + { \bf (before spending money on hardware engineers!) } + \vspace{4pt} + \item Analyse the scenarios: if pins are missing, alter and repeat.\\ + \vspace{4pt} + \item Eventually the pinmux meets all requirements...\\ + { \bf without spending USD \$5-50m to find out it doesn't!} + \end{itemize} +} + + + +\frame{\frametitle{Muxer cases to handle (One/Many to One/Many) etc.} \begin{itemize} - \item Many FN outputs to Many Pins: no problem\\ - (weird configuration by end-user, but no damage to ASIC)\vspace{10pt} + \item One FN output to Many Pins: no problem\\ + (weird configuration by end-user, but no damage to ASIC) \item One Pin to Many FN inputs: no problem\\ - (weird configuration by end-user, but no damage to ASIC)\vspace{10pt} + (weird configuration by end-user, but no damage to ASIC) + \item Many FN outputs simultaneously to one Pin: {\bf does not occur}\\ + (not desirable and not possible, as part of the pinmux design) \item Many Pins to One FN input: {\bf Priority Mux needed}\\ - No priority mux: Pin1 = HI, Pin0 = LO, ASIC is damaged\vspace{10pt} + No priority mux: Pin1=HI, Pin0=LO and ASIC is destroyed \item Some FNs (I2C\_SDA, SD\_D0..3) are I/O Buses\\ Bi-directional control of the Pin must be handed to the - FN\vspace{10pt} - \item TODO\vspace{10pt} + FN + \item Nice to have: Bus sets pintype, signal strength etc.\\ + e.g. selecting SD/MMC doesn't need manual pin-config.\\ + \bf{caveat: get that wrong and the ASIC can't be sold} + \end{itemize} +} + + +\frame{\frametitle{Pin Configuration, input and output} + + In/out: {\bf Note: these all require multiplexing } + \begin{itemize} + \item Output-Enable (aka Input disable): switches pad to Out or In + \item Output (actually an input wire controlling pin's level, HI/LO) + \item Input (actually an output wire set based on pin's driven level) + \end{itemize} + Characteristics: {\bf Note: these do not require multiplexing } + \begin{itemize} + \item Output current level: 10mA / 20mA / 30mA / 40mA + \item Input hysteresis: low / middle / high. Stops signal noise + \item Pin characteristics: CMOS Push-Push / Open-Drain + \item Pull-up enable: built-in 10k (50k?) resistor + \item Pull-down enable: built-in 10k (50k?) resistor + \item Muxing and IRQ Edge-detection not part of the I/O pin + \item Other? (impedance? not normally part of commercial pinmux) \end{itemize} } @@ -130,6 +284,29 @@ \end{center} } +\frame{\frametitle{Separating Pin Configuration, input and output} + + \begin{itemize} + \item Standard Mux design {\bf cannot deal with many-to-one inputs}\\ + (SiFive IOF source code from Freedom E310 cannot, either) + \vspace{4pt} + \item I/O pad configuration conflated with In-Muxer conflated with + Out-Muxer conflated with GPIO conflated with EINT. + \vspace{4pt} + \end{itemize} + {\bf IMPORTANT to separate all of these out: + \vspace{4pt}} + \begin{itemize} + \item EINTs to be totally separate FNs. managed by RISC-V PLIC\\ + (If every GPIO was an EINT it would mean 100+ IRQs) + \vspace{4pt} + \item GPIO In/Out/Direction treated just like any other FN\\ + (but happen to have AXI4 - or other - memory-mapping) + \vspace{4pt} + \item Pad configuration separated and given one-to-one Registers\\ + (SRAMs set by AXI4 to control mux, pullup, current etc.) + \end{itemize} +} \frame{\frametitle{Register-to-pad "control" settings} \begin{center} @@ -139,18 +316,47 @@ } -\frame{\frametitle{In/Out muxing, direction control} +\frame{\frametitle{GPIO (only): Simplified I/O pad Diagram (FN only)} + \begin{center} + \includegraphics[height=1.3in]{reg_gpio_pinblock.jpg} + \end{center} + \begin{itemize} + \item GPIO In/Out/Direction is just another FN (effectively) + \item 3 wires: IN, OUT, OUTEN (=INEN\#) + \item FN however may be output-only (UART\_TX), input-only (UART\_RX) + or bi-directional (I2C\_SDA) and Bus-controlled. + \item GPIO is definitely bi-directional and under Register control + \end{itemize} +} + + +\frame{\frametitle{Output Muxer (very simple)} + \begin{center} + \includegraphics[height=1.1in]{reg_gpio_out_mux.jpg}\\ + {\bf Output Muxer using 2-bit address selection}\\ + \end{center} + \begin{itemize} + \item Very straightforward (deceptively so, like SRAM cells) + \item Used in both OUT routing and Direction-control routing\\ + (same address for each, connected to same FNs) + \item More complex pinmux will have 3-bit addressing (8 FNs)\\ + (Note: not all outputs will be connected, depends on pinmux) + \end{itemize} +} + + +\frame{\frametitle{In/Out muxing, direction control: GPIO just a FN} \begin{center} \includegraphics[height=2.5in]{reg_gpio_fn_ctrl.jpg}\\ - {\bf Note: function can control I/O direction} + {\bf Note: function can control I/O direction (bus)} \end{center} } -\frame{\frametitle{Simplified I/O pad Block Diagram} +\frame{\frametitle{Direction Control: Function not bi-directional (bus)} \begin{center} - \includegraphics[height=2.5in]{reg_gpio_pinblock.jpg}\\ - {\bf 3 wires: IN, OUT, OUTEN (also = !INEN) } + \includegraphics[height=2.5in]{reg_gpio_fn_ctrl2.jpg}\\ + Note: Function {\bf does not} control I/O direction \end{center} } @@ -174,7 +380,7 @@ } -\frame{\frametitle{Input Mux Wiring} +\frame{\frametitle{Input Priority-Mux Wiring: very different from Out-Mux} \begin{center} \includegraphics[height=2.5in]{reg_gpio_in_wiring.jpg}\\ {\bf Pin Mux selection vals NOT same as FN selection vals} @@ -182,10 +388,45 @@ } +\frame{\frametitle{Input Priority-Mux Wiring} + + \begin{itemize} + \item In-Muxer selection number (0,1,2,3) obviously has to match + with Out-Muxer order (otherwise a bi-directional FN + needs different Mux-register settings for + selecting either IN or OUT) + \vspace{6pt} + \item Priority-mux selection values do not actually matter, + and have nothing to do with the actual Muxer settings. + \vspace{6pt} + \item GPIO FN's input muxer is nothing more than an AND gate\\ + (you never route more than one pin to one GPIO) + \vspace{6pt} + \item Any other FN with only 1:1 on its IN also just an AND gate \\ + (this just always happens to be true for GPIO) + \vspace{6pt} + \item Not all FNs have input capability: clearly they will not + be included in the In-Muxing. + \end{itemize} +} + + \frame{\frametitle{Summary} \begin{itemize} - \item TODO + \item Value of Libre/Open pimux dramatically underestimated\\ + (and does not presently exist: SiFive's IOF not suitable as-is)\\ + {\bf Only current option: license a commercial Pinmux } + \item Actual muxing (like SRAM cells) is deceptively simple + \item Actual pinmuxes are enormous: auto-generation essential + \item HDLs completely unsuited to auto-generation task\\ + (TRM, docs): {\bf Modern OO language needed i.e. python} + \item Scenario Analysis / Verification and auto-generation of + different HDLs far easier in a Modern OO language\\ + (better libraries, more developers) + \item Standardisation for RISC-V saves implementors from huge + duplication cost (HDL, firmware, docs, maintenance) + \item { \bf Ultimately it's about saving money and reducing risk } \end{itemize} }