alter slide order
[libreriscv.git] / pinmux / pinmux_chennai_2018.tex
index d9d5a2dc234a7bdb52e6ecc4f06ed2faab0a4ee5..9850363eb382fa57f609e374effaa285b82f6e3a 100644 (file)
@@ -16,6 +16,9 @@
     \vspace{32pt}
     \Large{Auto-generating documentation, code \\
                        and resources for a Pinmux}\\
+    \vspace{16pt}
+    \Large{Saving time and money for SoC designers\\
+                   in the RISC-V Ecosystem and beyond}\\
     \vspace{24pt}
     \Large{[proposed for] Chennai 9th RISC-V Workshop}\\
     \vspace{16pt}
  \begin{itemize}
    \item Auto-generate everything: documentation, code, libraries etc.
             \vspace{10pt}
-   \item Standardise: similar to PLIC, propose GPIO and Pinmux
+   \item Standardise: similar to PLIC, propose GPIO and Pinmux\\
+            saves engineering effort, design effort and much more
             \vspace{10pt}
    \item Standardise format of configuration registers:
             saves code duplication effort (multiple software environments)
             { \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 preliminary schematics
+         (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...\\
-            { \bf without spending USD \$5m to \$50m to find out }
+            { \bf without spending USD \$5-50m to find out it doesn't!}
   \end{itemize}
 }
 
 }
 
 
+\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) }
+ \end{center}
+}
+
+
 \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}
+  {\bf Note: function can control I/O direction (bus)}
  \end{center}
 }
 
 
-\frame{\frametitle{GPIO (only): Simplified I/O pad Diagram (FN only)}
+\frame{\frametitle{Direction Control: Function not bi-directional (bus)}
  \begin{center}
-  \includegraphics[height=2.5in]{reg_gpio_pinblock.jpg}\\
-  {\bf 3 wires: IN, OUT, OUTEN (also = !INEN) }
+  \includegraphics[height=2.5in]{reg_gpio_fn_ctrl2.jpg}\\
+  Note: Function {\bf does not} control I/O direction
  \end{center}
 }
 
 }
 
 
-\frame{\frametitle{Input Mux Wiring}
+\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}
 }
 
 
+\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 In also 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}