\usepackage{graphics}
\usepackage{pstricks}
-\title{SIMD}
+\title{Pin Multiplexer}
\author{Rishabh Jain}
\author{Luke Kenneth Casson Leighton}
\begin{center}
\huge{Pin Multiplexer}\\
\vspace{32pt}
- \Large{(Auto-generating documentation and resources for a Pinmux)}\\
+ \Large{Auto-generating documentation, code \\
+ and resources for a Pinmux}\\
\vspace{24pt}
\Large{[proposed for] Chennai 9th RISC-V Workshop}\\
\vspace{16pt}
}
+\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 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
+ \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.
+ \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 far less costly and the chip more desirable\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}
+ \end{itemize}
+}
+
+
+\frame{\frametitle{Associated Extras}
+
+ \begin{itemize}
+ \item Design Specification
+ \item Scenario analysis (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}
+ }
+ \\
+ (i.e. it would be insanely costly to do them by hand)
+ \end{center}
+
+}
+
+\frame{\frametitle{Reduce workload, reduce duplication, reduce risk and cost}
+
+ \begin{itemize}
+ \item Auto-generate everything: documentation, code, libraries etc.
+ \vspace{10pt}
+ \item Standardise: similar to PLIC, propose GPIO and Pinmux
+ \vspace{10pt}
+ \item Standardise format of configuration registers
+ \vspace{10pt}
+ \item Add support for multiple code formats: Chisel3 (SiFive IOF),
+ BSV (Bluespec), Verilog, VHDL, MyHDL.
+ \vspace{10pt}
+ \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}
+ \end{itemize}
+}
+
+\frame{\frametitle{Muxer cases to handle}
+
+ \begin{itemize}
+ \item Many FN outputs to Many Pins: no problem\\
+ (weird configuration by end-user, but no damage to ASIC)\vspace{6pt}
+ \item One Pin to Many FN inputs: no problem\\
+ (weird configuration by end-user, but no damage to ASIC)\vspace{6pt}
+ \item Many Pins to One FN input: {\bf Priority Mux needed}\\
+ No priority mux: Pin1 = HI, Pin0 = LO, ASIC is damaged\vspace{6pt}
+ \item Some FNs (I2C\_SDA, SD\_D0..3) are I/O Buses\\
+ Bi-directional control of the Pin must be handed to the
+ FN\vspace{6pt}
+ \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:
+ \begin{itemize}
+ \item Output-Enable (aka Input disable): switches pad to In or Out
+ \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:
+ \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
+ \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{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{In/Out muxing, direction control}
+ \begin{center}
+ \includegraphics[height=2.5in]{reg_gpio_fn_ctrl.jpg}\\
+ {\bf Note: function can control I/O direction}
+ \end{center}
+}
+
+
+\frame{\frametitle{Simplified I/O pad Block Diagram}
+ \begin{center}
+ \includegraphics[height=2.5in]{reg_gpio_pinblock.jpg}\\
+ {\bf 3 wires: IN, OUT, OUTEN (also = !INEN) }
+ \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 Mux Wiring}
+ \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{Summary}
\begin{itemize}
projects / libreriscv.git / blobdiff