X-Git-Url: https://git.libre-soc.org/?a=blobdiff_plain;ds=sidebyside;f=pinmux%2Fpinmux_chennai_2018.tex;h=9ca9d640097afe76668327b8faddc0ef1f282e20;hb=62918721dc0acd36c5913e02aaf657dd1150f4b2;hp=8e27f1377193e95b6e4b5c454c9c565e711b3718;hpb=a6539730cb95fcda0c95ac950a9ad9e8f74642d4;p=libreriscv.git diff --git a/pinmux/pinmux_chennai_2018.tex b/pinmux/pinmux_chennai_2018.tex index 8e27f1377..9ca9d6400 100644 --- a/pinmux/pinmux_chennai_2018.tex +++ b/pinmux/pinmux_chennai_2018.tex @@ -42,16 +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 {\bf 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 {\bf 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 Muxer: a many-to-one "redirector" where any one - output "routed" to the input, based on a selector "address". + input is "routed" to the output, based on a selector "address". \end{itemize} } @@ -66,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) @@ -110,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} } @@ -135,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...\\ @@ -156,29 +235,17 @@ -\frame{\frametitle{Example: 7 banks, 4-way mux, 160 pins} - \begin{center} - \includegraphics[height=1.7in]{example_pinmux.jpg} - \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{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 @@ -193,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} @@ -221,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. @@ -251,16 +318,22 @@ \frame{\frametitle{GPIO (only): Simplified I/O pad Diagram (FN only)} \begin{center} - \includegraphics[height=2.5in]{reg_gpio_pinblock.jpg}\\ - {\bf 3 wires: IN, OUT, OUTEN (also = !INEN) } + \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 Ouput Muxer using 2-bit address selection}\\ + {\bf Output Muxer using 2-bit address selection}\\ \end{center} \begin{itemize} \item Very straightforward (deceptively so, like SRAM cells) @@ -329,7 +402,7 @@ \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 In also an AND gate \\ + \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 @@ -341,19 +414,18 @@ \frame{\frametitle{Summary} \begin{itemize} - \item Actual muxing, like SRAM cells, is deceptively simple - \vspace{10pt} + \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 - \vspace{10pt} \item HDLs completely unsuited to auto-generation task\\ - (TRM, docs): { \bf Modern OO language features needed} - \vspace{10pt} - \item Verification and auto-generation of different HDLs far - easier in a Modern OO language - \vspace{10pt} + (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) - \vspace{10pt} \item { \bf Ultimately it's about saving money and reducing risk } \end{itemize} }