auto-generated\vspace{30pt}
}
\\
- (i.e. it would be insanely costly to do them by hand)
+ (from the Design Specification, after Scenario Analysis)
\end{center}
}
\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
+ \item Standardise format of configuration registers:
+ saves code duplication effort (multiple software environments)
\vspace{10pt}
\item Add support for multiple code formats: Chisel3 (SiFive IOF),
BSV (Bluespec), Verilog, VHDL, MyHDL.
\end{itemize}
}
-\frame{\frametitle{Muxer cases to handle}
+
+\frame{\frametitle{Design Spec and Scenario Analysis}
\begin{itemize}
- \item Many FN outputs to Many Pins: no problem\\
- (weird configuration by end-user, but no damage to ASIC)\vspace{6pt}
+ \item Analyse the target markets that the chip will sell in\\
+ (multiple markets increases sales volume, reduces chip cost)
+ \vspace{4pt}
+ \item Create a formal (python-based) specification for the pinmux
+ \vspace{4pt}
+ \item Add scenarios then check that they meet the requirements\\
+ { \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 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 \$5-50m to find out it doesn't!}
+ \end{itemize}
+}
+
+
+\frame{\frametitle{Muxer cases to handle (One/Many to One/Many) etc.}
+
+ \begin{itemize}
+ \item One FN outputs to Many Pins: no problem\\
+ (weird configuration by end-user, but no damage to ASIC)
\item One Pin to Many FN inputs: no problem\\
- (weird configuration by end-user, but no damage to ASIC)\vspace{6pt}
+ (weird configuration by end-user, but no damage to ASIC)
\item Many Pins to One FN input: {\bf Priority Mux needed}\\
- No priority mux: Pin1 = HI, Pin0 = LO, ASIC is damaged\vspace{6pt}
+ No priority mux: Pin1 = HI, Pin0 = LO, ASIC is damaged
+ \item Many FN outputs simultaneously to one Pin: {\bf does not occur}\\
+ (not desirable and not possible, as part of the pinmux design)
\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}
+ FN
\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}
\frame{\frametitle{Pin Configuration, input and output}
- In/out:
+ In/out: {\bf Note: these all require multiplexing }
\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:
+ Characteristics: {\bf Note: these do not require multiplexing }
\begin{itemize}
\item Output current level: 10mA / 20mA / 30mA / 40mA
\item Input hysteresis: low / middle / high. Stops signal noise
\end{center}
}
+\frame{\frametitle{Separating Pin Configuration, input and output}
+
+ \begin{itemize}
+ \item Standard Mux design {\bf cannot deal with many-to-one inputs}\\
+ (SiFive IOF source code from Freedom U310 cannot, either)
+ \vspace{4pt}
+ \item I/O pad configuration conflated with In-Muxer conflated with
+ Out-Muxer conflated with GPIO conflated with EINT.
+ \vspace{4pt}
+ \end{itemize}
+ {\bf IMPORTANT to separate all of these out:
+ \vspace{4pt}}
+ \begin{itemize}
+ \item EINTs to be totally separate FNs. managed by RISC-V PLIC\\
+ (If every GPIO was an EINT it would mean 100+ IRQs)
+ \vspace{4pt}
+ \item GPIO In/Out/Direction treated just like any other FN\\
+ (but happen to have AXI4 - or other - memory-mapping)
+ \vspace{4pt}
+ \item Pad configuration separated and given one-to-one Registers\\
+ (SRAMs set by AXI4 to control mux, pullup, current etc.)
+ \end{itemize}
+}
\frame{\frametitle{Register-to-pad "control" settings}
\begin{center}
}
-\frame{\frametitle{In/Out muxing, direction control}
+\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{Direction Control: Function not bi-directional (bus)}
+ \begin{center}
+ \includegraphics[height=2.5in]{reg_gpio_fn_ctrl2.jpg}\\
+ Note: Function {\bf does not} control I/O direction
\end{center}
}
-\frame{\frametitle{Simplified I/O pad Block Diagram}
+\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) }