add slides

[libreriscv.git] / pinmux / pinmux_chennai_2018.tex

\documentclass[slidestop]{beamer}
\usepackage{beamerthemesplit}
\usepackage{graphics}
\usepackage{pstricks}

\title{Pin Multiplexer}
\author{Rishabh Jain}
\author{Luke Kenneth Casson Leighton}


\begin{document}

\frame{
   \begin{center}
    \huge{Pin Multiplexer}\\
    \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}
    \large{\today}
  \end{center}
}


\frame{\frametitle{Credits and Acknowledgements}

 \begin{itemize}
   \item TODO\vspace{10pt}
  \end{itemize}
}


\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}\\
  {\bf 4-in, 4-out, pullup/down, hysteresis, edge-detection (EINT)}
 \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}
  \includegraphics[height=2.5in]{reg_gpio_cap_ctrl.jpg}\\
  {\bf pullup/down, hysteresis, current, edge-detection}
 \end{center}
}


\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 (bus)}
 \end{center}
}


\frame{\frametitle{Direction Control: Function not bi-directional (bus)}
 \begin{center}
  \includegraphics[height=2.5in]{reg_gpio_fn_ctrl2.jpg}\\
  Note: Function {\bf does not} control I/O direction
 \end{center}
}


\frame{\frametitle{Output (and OUTEN) Wiring. 2 pins, 2 GPIO, 2 Fns}
 \begin{center}
  \includegraphics[height=2.5in]{reg_gpio_out_wiring.jpg}\\
  {\bf Reg0 for Pin0, Reg1 for Pin1, Output and OUTEN same mux }
 \end{center}
}


\frame{\frametitle{Input Selection and Priority Muxing}
 \begin{center}
  \includegraphics[height=0.75in]{reg_gpio_comparator.jpg}\\
  {\bf Muxer enables input selection}\\
  \vspace{10pt}
  \includegraphics[height=1.25in]{reg_gpio_in_prioritymux.jpg}\\
  {\bf However multiple inputs must be prioritised }
 \end{center}
}


\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}
 \end{center}
}


\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 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}
}


\frame{
  \begin{center}
    {\Huge The end\vspace{20pt}\\
                   Thank you\vspace{20pt}\\
                   Questions?\vspace{20pt}
        }
  \end{center}
  
  \begin{itemize}
        \item http://libre-riscv.org/shakti/m\_class/pinmux/
  \end{itemize}
}


\end{document}