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