add new slide
[libreriscv.git] / pinmux / pinmux_chennai_2018.tex
index 37826be6ac81530371e0b5b04fadc6831c598511..f3f8a19664520fc718c28813d0bef7ad9163865f 100644 (file)
             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 Input Priority Muxer: a multiplexer that has N selector
+   \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 inputs, where the lowest (or highest) indexed
-                "selector" that is enabled results in its corresponding
+                "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 of a number of outputs, based
-            on a selection address.
+            input is "routed" to any one output, based
+            on a selector.
    \item GPIO: general-purpose reconfigureable I/O (Input/Output).
   \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}
+       }
+       \\
+       (translation: it would be insanely costly to do them by hand)
+  \end{center}
+  
+}
+
 \frame{\frametitle{Muxer cases to handle}
 
  \begin{itemize}
    \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{10pt}
-   \item TODO\vspace{10pt}
+   \item Nice to have: Bus sets pintype, signal strength etc.\vspace{10pt}
   \end{itemize}
 }