X-Git-Url: https://git.libre-soc.org/?a=blobdiff_plain;f=pinmux%2Fpinmux_chennai_2018.tex;h=9ca9d640097afe76668327b8faddc0ef1f282e20;hb=74eb0159fa2188f5220e145de0e15a7faf2fee87;hp=94b9320a4c60e1ad2e7e998aa4838673fbbf50f0;hpb=cacefd0a29d565575c5bf3db21e21c1bbba668bb;p=libreriscv.git diff --git a/pinmux/pinmux_chennai_2018.tex b/pinmux/pinmux_chennai_2018.tex index 94b9320a4..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} @@ -32,6 +35,248 @@ } +\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 {\it always} allocated, one + for input to the function and one for output from the function). + \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 Muxer: a many-to-one "redirector" where any one + input is "routed" to the output, based on a selector "address". + \end{itemize} +} + + +\frame{\frametitle{Why, How and What is a Pinmux?} + + \begin{itemize} + \item Why? To save cost, increase yield, and to target multiple + markets with the same design, thereby increasing uptake + and consequently taking advantage of volume pricing.\vspace{4pt} + \\ + 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 cheaper, smaller, and more versatile\vspace{4pt} + \item What? A many-to-many dynamically-configureable router of + 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 ({\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 (AXI4 / Wishbone / TileLink / other) + \item Simulation + \item Linux kernel drivers, DTB, libopencm3, Arduino libraries etc. + \end{itemize} + Example context: + \begin{itemize} + \item Shakti M-Class has 160 pins with a 99.5\% full 4-way mux + \item Almost 640-way routing, 6 "scenarios" (7th TBD), + 100+ page Manual needed, + \bf{17,500 lines of auto-generated code} + \end{itemize} +} + + +\frame{ + \vspace{30pt} + \begin{center} + {\Huge + ALL of these\vspace{20pt}\\ + can be\vspace{20pt}\\ + auto-generated\vspace{30pt} + } + \\ + (from the Design Specification, after Scenario Analysis) + \end{center} + +} + + +\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 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) + \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 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 + \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} +} + + \frame{\frametitle{Standard GPIO 4-way in/out Mux and I/O pad} \begin{center} \includegraphics[height=2.5in]{../shakti/m_class/mygpiomux.jpg}\\ @@ -39,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} @@ -48,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} } @@ -83,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} @@ -91,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} }