\vspace{32pt}
\Large{Auto-generating documentation, code \\
and resources for a Pinmux}\\
+ \vspace{16pt}
+ \Large{Saving time and money for SoC / EC designers\\
+ in the RISC-V Ecosystem and beyond}\\
\vspace{24pt}
\Large{[proposed for] Chennai 9th RISC-V Workshop}\\
\vspace{16pt}
\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
+ (bi-directional case: two wires are {\bf 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
+ where the direction is ganged and {\bf 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.
+ \item Output Muxer: a many-to-one "redirector" where any one
+ output "routed" to the input, based on a selector "address".
\end{itemize}
}
\frame{\frametitle{Associated Extras}
\begin{itemize}
- \item Design Specification
- \item Scenario analysis (whether the chip will fit "markets")
+ \item Design Specification (what markets to target)
+ \item Scenario analysis ({\bf whether} the chip will fit "markets")
\item Documentation: Summary sheet, Technical Reference Manual.
\item Test suites
\item Control Interface (AXI4 / Wishbone / TileLink / other)
}
+\frame{\frametitle{Example: 7 banks, 4-way mux, 160 pins}
+ \begin{center}
+ \includegraphics[height=1.7in]{example_pinmux.jpg}
+ \end{center}
+ \begin{itemize}
+ \item { \bf 17,500 lines of auto-generated HDL (and climbing)}
+ \item { \bf 12,500 lines of auto-generated Summary/Analysis}
+ \item Technical Reference Manual expected to be 100+ pages
+ \end{itemize}
+}
+
+
\frame{
\vspace{30pt}
\begin{center}
}
+
\frame{\frametitle{Muxer cases to handle (One/Many to One/Many) etc.}
\begin{itemize}
\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
+ \item Other? (impedance? not normally part of commercial pinmux)
\end{itemize}
}
}
+\frame{\frametitle{Output Muxer (very simple)}
+ \begin{center}
+ \includegraphics[height=1.1in]{reg_gpio_out_mux.jpg}\\
+ {\bf Ouput Muxer using 2-bit address selection}\\
+ \end{center}
+ \begin{itemize}
+ \item Very straightforward (deceptively so, like SRAM cells)
+ \item Used in both OUT routing and Direction-control routing\\
+ (same address for each, connected to same FNs)
+ \item More complex pinmux will have 3-bit addressing (8 FNs)\\
+ (Note: not all outputs will be connected, depends on pinmux)
+ \end{itemize}
+}
+
+
\frame{\frametitle{In/Out muxing, direction control: GPIO just a FN}
\begin{center}
\includegraphics[height=2.5in]{reg_gpio_fn_ctrl.jpg}\\
\frame{\frametitle{Summary}
\begin{itemize}
- \item TODO
+ \item Actual muxing, like SRAM cells, is deceptively simple
+ \vspace{10pt}
+ \item Actual pinmuxes are enormous: auto-generation essential
+ \vspace{10pt}
+ \item HDLs completely unsuited to auto-generation task\\
+ (TRM, docs): { \bf Modern OO language features needed}
+ \vspace{10pt}
+ \item Scenario Analysis / Verification and auto-generation of
+ different HDLs far easier in a Modern OO language
+ \vspace{10pt}
+ \item Standardisation for RISC-V saves implementors from huge
+ duplication cost (HDL, firmware, docs, maintenance)
+ \vspace{10pt}
+ \item { \bf Ultimately it's about saving money and reducing risk }
\end{itemize}
}