pinmux/pinmux_chennai_2018.tex

   1 \documentclass[slidestop]{beamer}
   2 \usepackage{beamerthemesplit}
   3 \usepackage{graphics}
   4 \usepackage{pstricks}
   5
   6 \title{Pin Multiplexer}
   7 \author{Rishabh Jain}
   8 \author{Luke Kenneth Casson Leighton}
   9
  10
  11 \begin{document}
  12
  13 \frame{
  14    \begin{center}
  15     \huge{Pin Multiplexer}\\
  16     \vspace{32pt}
  17     \Large{Auto-generating documentation, code \\
  18                         and resources for a Pinmux}\\
  19     \vspace{24pt}
  20     \Large{[proposed for] Chennai 9th RISC-V Workshop}\\
  21     \vspace{16pt}
  22     \large{\today}
  23   \end{center}
  24 }
  25
  26
  27 \frame{\frametitle{Credits and Acknowledgements}
  28
  29  \begin{itemize}
  30    \item TODO\vspace{10pt}
  31   \end{itemize}
  32 }
  33
  34
  35 \frame{\frametitle{Glossary}
  36
  37  \begin{itemize}
  38    \item GPIO: general-purpose reconfigureable I/O (Input/Output).
  39    \item Pin: an I/O pad.  May be driven (input) or may drive (output).
  40    \item FN: term for a single-wire "function", such as UART\_TX,
  41              I2C\_SDA, SDMMC\_D0 etc.  may be an input, output or both
  42                  (bi-directional case: two wires are always allocated, one
  43                   for input to the function and one for output from the function).
  44    \item Bus: a group of bi-directional functions (SDMMC D0 to D3)
  45          where the direction is ganged and under the Bus's control
  46    \item Input Priority Muxer: a multiplexer with N selector
  47                  wires and N associated inputs.  The lowest (highest?) indexed
  48                  "selector" enabled results in its
  49                  input being routed to the output.
  50    \item Output Demuxer: a one-to-many "redirector" where a single
  51              input is "routed" to any one output, based
  52              on a selector.
  53   \end{itemize}
  54 }
  55
  56
  57 \frame{\frametitle{Why, How and What is a Pinmux?}
  58
  59  \begin{itemize}
  60    \item Why? To save cost, increase yield, and to target multiple
  61          markets with the same design, thereby increasing uptake
  62          and consequently taking advantage of volume pricing.\vspace{4pt}
  63          \\
  64          Summary: it's all about making more money!\vspace{4pt}
  65    \item How? By multiplexing many more functions (100 to 1,200) than there
  66          are actual available pins (48 to 500), the required chip package
  67              is far less costly and the chip more desirable\vspace{4pt}
  68    \item What? A many-to-many dynamically-configureable router of
  69          I/O functions to I/O pins\vspace{4pt}
  70    \item \bf{Note: actual muxing is deceptively simple, but like
  71          a DRAM cell it's actually about the ancillaries / extras}
  72   \end{itemize}
  73 }
  74
  75
  76 \frame{\frametitle{Associated Extras}
  77
  78  \begin{itemize}
  79    \item Design Specification
  80    \item Scenario analysis (whether the chip will fit "markets")
  81    \item Documentation: Summary sheet, Technical Reference Manual.
  82    \item Test suites
  83    \item Control Interface (AXI4 / Wishbone / TileLink / other)
  84    \item Simulation
  85    \item Linux kernel drivers, DTB, libopencm3, Arduino libraries etc.
  86   \end{itemize}
  87  Example context:
  88  \begin{itemize}
  89    \item Shakti M-Class has 160 pins with a 99.5\% full 4-way mux
  90    \item Almost 640-way routing, 6 "scenarios" (7th TBD),
  91          100+ page Manual needed,
  92          \bf{17,500 lines of auto-generated code}
  93   \end{itemize}
  94 }
  95
  96
  97 \frame{
  98   \vspace{30pt}
  99   \begin{center}
 100     {\Huge
 101                    ALL of these\vspace{20pt}\\
 102                    can be\vspace{20pt}\\
 103                    auto-generated\vspace{30pt}
 104         }
 105         \\
 106         (from the Design Specification, after Scenario Analysis)
 107   \end{center}
 108
 109 }
 110
 111 \frame{\frametitle{Reduce workload, reduce duplication, reduce risk and cost}
 112
 113  \begin{itemize}
 114    \item Auto-generate everything: documentation, code, libraries etc.
 115              \vspace{10pt}
 116    \item Standardise: similar to PLIC, propose GPIO and Pinmux\\
 117              saves engineering effort, design effort and much more
 118              \vspace{10pt}
 119    \item Standardise format of configuration registers:
 120              saves code duplication effort (multiple software environments)
 121                  \vspace{10pt}
 122    \item Add support for multiple code formats: Chisel3 (SiFive IOF),
 123              BSV (Bluespec), Verilog, VHDL, MyHDL.
 124                  \vspace{10pt}
 125    \item Multiple auto-generated code-formats permits cross-validation:\\
 126              auto-generated test suite in one HDL can validate a muxer
 127              generated for a different target HDL.
 128                  \vspace{10pt}
 129   \end{itemize}
 130 }
 131
 132
 133 \frame{\frametitle{Design Spec and Scenario Analysis}
 134
 135  \begin{itemize}
 136    \item Analyse the target markets that the chip will sell in\\
 137              (multiple markets increases sales volume, reduces chip cost)
 138              \vspace{4pt}
 139    \item Create a formal (python-based) specification for the pinmux
 140              \vspace{4pt}
 141    \item Add scenarios then check that they meet the requirements\\
 142              { \bf (before spending money on hardware engineers!) }
 143              \vspace{4pt}
 144    \item Scenarios represent target markets: ICs to be connected\\
 145          (GPS, NAND IC, WIFI etc.  May require draft schematics
 146          drawn up, or client-supplied schematics analysed).
 147                  \vspace{4pt}
 148    \item Analyse the scenarios: if pins are missing, alter and repeat.\\
 149                  \vspace{4pt}
 150    \item Eventually the pinmux meets all requirements...\\
 151              { \bf without spending USD \$5-50m to find out it doesn't!}
 152   \end{itemize}
 153 }
 154
 155
 156 \frame{\frametitle{Muxer cases to handle (One/Many to One/Many) etc.}
 157
 158  \begin{itemize}
 159    \item One FN outputs to Many Pins: no problem\\
 160              (weird configuration by end-user, but no damage to ASIC)
 161    \item One Pin to Many FN inputs: no problem\\
 162          (weird configuration by end-user, but no damage to ASIC)
 163    \item Many Pins to One FN input: {\bf Priority Mux needed}\\
 164              No priority mux: Pin1 = HI, Pin0 = LO, ASIC is damaged
 165    \item Many FN outputs simultaneously to one Pin: {\bf does not occur}\\
 166              (not desirable and not possible, as part of the pinmux design)
 167    \item Some FNs (I2C\_SDA, SD\_D0..3) are I/O Buses\\
 168              Bi-directional control of the Pin must be handed to the
 169              FN
 170    \item Nice to have: Bus sets pintype, signal strength etc.\\
 171              e.g. selecting SD/MMC doesn't need manual pin-config.\\
 172              \bf{caveat: get that wrong and the ASIC can't be sold}
 173   \end{itemize}
 174 }
 175
 176
 177 \frame{\frametitle{Pin Configuration, input and output}
 178
 179  In/out: {\bf Note: these all require multiplexing }
 180  \begin{itemize}
 181    \item Output-Enable (aka Input disable): switches pad to In or Out
 182    \item Output (actually an input wire controlling pin's level, HI/LO)
 183    \item Input (actually an output wire set based on pin's driven level)
 184  \end{itemize}
 185  Characteristics: {\bf Note: these do not require multiplexing }
 186  \begin{itemize}
 187    \item Output current level: 10mA / 20mA / 30mA / 40mA
 188    \item Input hysteresis: low / middle / high. Stops signal noise
 189    \item Pin characteristics: CMOS Push-Push / Open-Drain
 190    \item Pull-up enable: built-in 10k (50k?) resistor
 191    \item Pull-down enable: built-in 10k (50k?) resistor
 192    \item Muxing and IRQ Edge-detection not part of the I/O pin
 193   \end{itemize}
 194 }
 195
 196
 197 \frame{\frametitle{Standard GPIO 4-way in/out Mux and I/O pad}
 198  \begin{center}
 199   \includegraphics[height=2.5in]{../shakti/m_class/mygpiomux.jpg}\\
 200   {\bf 4-in, 4-out, pullup/down, hysteresis, edge-detection (EINT)}
 201  \end{center}
 202 }
 203
 204 \frame{\frametitle{Separating Pin Configuration, input and output}
 205
 206  \begin{itemize}
 207    \item Standard Mux design {\bf cannot deal with many-to-one inputs}\\
 208              (SiFive IOF source code from Freedom U310 cannot, either)
 209              \vspace{4pt}
 210    \item I/O pad configuration conflated with In-Muxer conflated with
 211                  Out-Muxer conflated with GPIO conflated with EINT.
 212                      \vspace{4pt}
 213  \end{itemize}
 214    {\bf IMPORTANT to separate all of these out:
 215                      \vspace{4pt}}
 216  \begin{itemize}
 217    \item EINTs to be totally separate FNs. managed by RISC-V PLIC\\
 218          (If every GPIO was an EINT it would mean 100+ IRQs)
 219                      \vspace{4pt}
 220    \item GPIO In/Out/Direction treated just like any other FN\\
 221              (but happen to have AXI4 - or other - memory-mapping)
 222                      \vspace{4pt}
 223    \item Pad configuration separated and given one-to-one Registers\\
 224              (SRAMs set by AXI4 to control mux, pullup, current etc.)
 225  \end{itemize}
 226 }
 227
 228 \frame{\frametitle{Register-to-pad "control" settings}
 229  \begin{center}
 230   \includegraphics[height=2.5in]{reg_gpio_cap_ctrl.jpg}\\
 231   {\bf pullup/down, hysteresis, current, edge-detection}
 232  \end{center}
 233 }
 234
 235
 236 \frame{\frametitle{In/Out muxing, direction control: GPIO just a FN}
 237  \begin{center}
 238   \includegraphics[height=2.5in]{reg_gpio_fn_ctrl.jpg}\\
 239   {\bf Note: function can control I/O direction (bus)}
 240  \end{center}
 241 }
 242
 243
 244 \frame{\frametitle{Direction Control: Function not bi-directional (bus)}
 245  \begin{center}
 246   \includegraphics[height=2.5in]{reg_gpio_fn_ctrl2.jpg}\\
 247   Note: Function {\bf does not} control I/O direction
 248  \end{center}
 249 }
 250
 251
 252 \frame{\frametitle{GPIO (only): Simplified I/O pad Diagram (FN only)}
 253  \begin{center}
 254   \includegraphics[height=2.5in]{reg_gpio_pinblock.jpg}\\
 255   {\bf 3 wires: IN, OUT, OUTEN (also = !INEN) }
 256  \end{center}
 257 }
 258
 259
 260 \frame{\frametitle{Output (and OUTEN) Wiring. 2 pins, 2 GPIO, 2 Fns}
 261  \begin{center}
 262   \includegraphics[height=2.5in]{reg_gpio_out_wiring.jpg}\\
 263   {\bf Reg0 for Pin0, Reg1 for Pin1, Output and OUTEN same mux }
 264  \end{center}
 265 }
 266
 267
 268 \frame{\frametitle{Input Selection and Priority Muxing}
 269  \begin{center}
 270   \includegraphics[height=0.75in]{reg_gpio_comparator.jpg}\\
 271   {\bf Muxer enables input selection}\\
 272   \vspace{10pt}
 273   \includegraphics[height=1.25in]{reg_gpio_in_prioritymux.jpg}\\
 274   {\bf However multiple inputs must be prioritised }
 275  \end{center}
 276 }
 277
 278
 279 \frame{\frametitle{Input Mux Wiring}
 280  \begin{center}
 281   \includegraphics[height=2.5in]{reg_gpio_in_wiring.jpg}\\
 282   {\bf Pin Mux selection vals NOT same as FN selection vals}
 283  \end{center}
 284 }
 285
 286
 287 \frame{\frametitle{Summary}
 288
 289  \begin{itemize}
 290    \item TODO
 291   \end{itemize}
 292 }
 293
 294
 295 \frame{
 296   \begin{center}
 297     {\Huge The end\vspace{20pt}\\
 298                    Thank you\vspace{20pt}\\
 299                    Questions?\vspace{20pt}
 300         }
 301   \end{center}
 302
 303   \begin{itemize}
 304         \item http://libre-riscv.org/shakti/m\_class/pinmux/
 305   \end{itemize}
 306 }
 307
 308
 309 \end{document}