X-Git-Url: https://git.libre-soc.org/?a=blobdiff_plain;f=pinmux%2Fpinmux_chennai_2018.tex;h=9ca9d640097afe76668327b8faddc0ef1f282e20;hb=cef4af88f051b63ef62edf77d25b6bd094781153;hp=2d487a8084bf4a0a26ca595721d44cd72b02dde9;hpb=4361e89c08f0f8837e5e60ff784f212041796dde;p=libreriscv.git diff --git a/pinmux/pinmux_chennai_2018.tex b/pinmux/pinmux_chennai_2018.tex index 2d487a808..9ca9d6400 100644 --- a/pinmux/pinmux_chennai_2018.tex +++ b/pinmux/pinmux_chennai_2018.tex @@ -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} @@ -39,17 +42,16 @@ \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 Bus: a group of bi-directional functions (SDMMC D0 to D3) - where the direction is ganged and under the Bus's control + 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 output, based - on a selector. + \item Output Muxer: a many-to-one "redirector" where any one + input is "routed" to the output, based on a selector "address". \end{itemize} } @@ -64,20 +66,83 @@ 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 (AXI4 / Wishbone / TileLink / other) @@ -108,24 +173,40 @@ } + +\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. - \vspace{10pt} + \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{10pt} + \vspace{4pt} \item Standardise format of configuration registers: saves code duplication effort (multiple software environments) - \vspace{10pt} + \vspace{4pt} \item Add support for multiple code formats: Chisel3 (SiFive IOF), BSV (Bluespec), Verilog, VHDL, MyHDL. - \vspace{10pt} + \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{10pt} + \vspace{4pt} \end{itemize} } @@ -133,18 +214,18 @@ \frame{\frametitle{Design Spec and Scenario Analysis} \begin{itemize} - \item Analyse the target markets that the chip will sell in\\ + \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 then check that they meet the requirements\\ + \item Add scenarios (in python), check that they meet requirements\\ { \bf (before spending money on hardware engineers!) } \vspace{4pt} - \item Scenarios represent target markets: ICs to be connected\\ - (GPS, NAND IC, WIFI etc. May require draft schematics - drawn up, or client-supplied schematics analysed). - \vspace{4pt} \item Analyse the scenarios: if pins are missing, alter and repeat.\\ \vspace{4pt} \item Eventually the pinmux meets all requirements...\\ @@ -153,17 +234,18 @@ } + \frame{\frametitle{Muxer cases to handle (One/Many to One/Many) etc.} \begin{itemize} - \item One FN outputs to Many Pins: no problem\\ + \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 Pins to One FN input: {\bf Priority Mux needed}\\ - No priority mux: Pin1 = HI, Pin0 = LO, ASIC is damaged \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 @@ -178,7 +260,7 @@ In/out: {\bf Note: these all require multiplexing } \begin{itemize} - \item Output-Enable (aka Input disable): switches pad to In or Out + \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} @@ -190,6 +272,7 @@ \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} } @@ -205,7 +288,7 @@ \begin{itemize} \item Standard Mux design {\bf cannot deal with many-to-one inputs}\\ - (SiFive IOF source code from Freedom U310 cannot, either) + (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. @@ -233,18 +316,47 @@ } +\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{GPIO (only): Simplified I/O pad Diagram (FN only)} +\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} } @@ -268,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} @@ -276,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} }