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}
+ is cheaper, smaller, and more versatile\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}
+ I/O functions to I/O pins
\end{itemize}
+ \bf{Note: actual muxing is deceptively simple, but like a DRAM cell
+ it's actually about the extras (routing, docs, specs etc).\\
+ Just as DRAM Cell != DDR3/4, Muxer Cell != Pinmux}
}
{\bf Commercial licensed}:
\vspace{4pt}
\begin{itemize}
- \item Cost: unknown.
- \item Flexibility: unknown.
- \item Language: unknown.
+ \item Cost: unknown (and ultimately doesn't matter)
+ \item Flexibility: unknown (NDAs required in order to find out)
+ \item Language: unknown (NDAs required in order to find out)
\item Capability for auto-generation of Docs: unknown.
\item Capability for auto-generation of ancillary resources: unknown.
\item Suitability for wide range of systems: unknown.
\vspace{4pt}
\item Suitability for saving RISC-V ecosystem money: {\bf NONE }
- \item Suitability for collaboration: {\bf ZERO} (i.e. don't bother)
+ \item Suitability for collaboration: {\bf ZERO} (prohibitive licensing)
\end{itemize}
\vspace{6pt}
Commercial licensees are isolated and cut off from the benefits
\\
(which is really weird, given how there's so many libre UART,
SPI and other peripheral libraries, even libre-licensed PCIe and
- SATA PHYs and even USB3 Pipe, hence the reason for this initiative)
+ SATA PHYs and even USB3 Pipe. Hence the reason for this initiative)
\end{center}
}
\frame{\frametitle{Associated Extras}
\begin{itemize}
- \item Design Specification (what markets to target)
+ \item Design Specification ({\bf what} markets to target)
\item Scenario analysis ({\bf whether} the chip will fit "markets")
\item Documentation: Summary sheet, Technical Reference Manual.
\item Test suites
\frame{\frametitle{Reduce workload, reduce duplication, reduce risk and cost}
\begin{itemize}
- \item Auto-generate everything: documentation, code, libraries etc.
- \vspace{10pt}
+ \item Auto-generate everything: documentation, code, libraries etc.\\
+ (including device-tree files, FreeBSD / Linux / RTOS kernel
+ drivers, Arduino, libopencm3 and other EC firmware libraries)
+ \vspace{4pt}
\item Standardise: similar to PLIC, propose GPIO and Pinmux\\
saves engineering effort, design effort and much more
- \vspace{10pt}
+ \vspace{4pt}
\item Standardise format of configuration registers:
saves code duplication effort (multiple software environments)
- \vspace{10pt}
+ \vspace{4pt}
\item Add support for multiple code formats: Chisel3 (SiFive IOF),
BSV (Bluespec), Verilog, VHDL, MyHDL.
- \vspace{10pt}
+ \vspace{4pt}
\item Multiple auto-generated code-formats permits cross-validation:\\
auto-generated test suite in one HDL can validate a muxer
generated for a different target HDL.
- \vspace{10pt}
+ \vspace{4pt}
\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\\
+ \item One FN output 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)
- \item Many Pins to One FN input: {\bf Priority Mux needed}\\
- 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 Many Pins to One FN input: {\bf Priority Mux needed}\\
+ No priority mux: Pin1=HI, Pin0=LO and ASIC is destroyed
\item Some FNs (I2C\_SDA, SD\_D0..3) are I/O Buses\\
Bi-directional control of the Pin must be handed to the
FN
In/out: {\bf Note: these all require multiplexing }
\begin{itemize}
- \item Output-Enable (aka Input disable): switches pad to In or Out
+ \item Output-Enable (aka Input disable): switches pad to Out or In
\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}
\begin{itemize}
\item Standard Mux design {\bf cannot deal with many-to-one inputs}\\
- (SiFive IOF source code from Freedom U310 cannot, either)
+ (SiFive IOF source code from Freedom E310 cannot, either)
\vspace{4pt}
\item I/O pad configuration conflated with In-Muxer conflated with
Out-Muxer conflated with GPIO conflated with EINT.
\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) }
+ \includegraphics[height=1.3in]{reg_gpio_pinblock.jpg}
\end{center}
+ \begin{itemize}
+ \item GPIO In/Out/Direction is just another FN (effectively)
+ \item 3 wires: IN, OUT, OUTEN (=INEN\#)
+ \item FN however may be output-only (UART\_TX), input-only (UART\_RX)
+ or bi-directional (I2C\_SDA) and Bus-controlled.
+ \item GPIO is definitely bi-directional and under Register control
+ \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}\\
+ {\bf Output Muxer using 2-bit address selection}\\
\end{center}
\begin{itemize}
\item Very straightforward (deceptively so, like SRAM cells)
projects / libreriscv.git / blobdiff