\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 {\bf always} allocated, one
+ (bi-directional case: two wires are {\it 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 {\bf under the Bus's control}
+ where the direction is ganged and {\it 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 Muxer: a many-to-one "redirector" where any one
- output "routed" to the input, based on a selector "address".
+ input is "routed" to the output, based on a selector "address".
\end{itemize}
}
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}
+}
+
+
+\frame{\frametitle{What options are available (at time of writing)? [1]}
+
+ \vspace{6pt}
+ {\bf Commercial licensed}:
+ \vspace{4pt}
+ \begin{itemize}
+ \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} (prohibitive licensing)
+ \end{itemize}
+ \vspace{6pt}
+ Commercial licensees are isolated and cut off from the benefits
+ and resources of the Libre world. Translation: USD \$200k+ NREs.
+}
+
+
+\frame{\frametitle{What options are available (at time of writing)? [2]}
+
+ \vspace{6pt}
+ {\bf SiFive IOF (Freedom E310, Unleashed U540)}:
+ \vspace{4pt}
+ \begin{itemize}
+ \item License: Good!
+ \item Flexibility: not so good.
+ \item Language: chisel3.
+ \item Capability for auto-generation of Docs: none.
+ \item Capability for auto-generation of ancillary resources: partial.
+ \item Suitability for wide range of systems: not so good.
+ \vspace{4pt}
+ \item Suitability for saving RISC-V ecosystem money: {\bf Low }\\
+ \item Suitability for collaboration: {\bf GOOD} (but: written in Chisel3)
+ \end{itemize}
+ \vspace{6pt}
+ Using SiFive IOF has Libre benefits, but it's incomplete and
+ harder to find Chisel3 programmers (than e.g. for python).
+}
+
+
+\frame{\frametitle{What options are available (at time of writing)? [3]}
+
+ \vspace{10pt}
+ \begin{center}
+ {\Huge
+ None. No suitable\vspace{20pt}\\
+ Libre-licensed\vspace{20pt}\\
+ pinmux exists\vspace{20pt}
+ }
+ \\
+ (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)
+ \end{center}
+
}
\frame{\frametitle{Associated Extras}
\begin{itemize}
- \item Design Specification
- \item Scenario analysis (whether the chip will fit "markets")
+ \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
\item Control Interface (AXI4 / Wishbone / TileLink / other)
}
+
+\frame{\frametitle{Example: 7 banks, 4-way mux, 160 pins}
+ \begin{center}
+ \includegraphics[height=1.5in]{example_pinmux.jpg}\\
+ 7 "banks" with separate VCC. Each no more than 32 bits
+ \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{\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{Design Spec and Scenario Analysis}
\begin{itemize}
- \item Analyse the target markets that the chip will sell in\\
+ \item Analyse the target markets (scenarios) that the chip will sell in\\
(multiple markets increases sales volume, reduces chip cost)
\vspace{4pt}
+ \item Scenarios represent target markets: ICs to be connected\\
+ (GPS, NAND IC, WIFI etc. May require prototype schematics
+ drawn up, or client-supplied schematics analysed).
+ \vspace{4pt}
\item Create a formal (python-based) specification for the pinmux
\vspace{4pt}
- \item Add scenarios then check that they meet the requirements\\
+ \item Add scenarios (in python), check that they meet 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...\\
-\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{\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}
\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}
}
\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)
\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 \\
+ \item Any other FN with only 1:1 on its IN also just 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
\frame{\frametitle{Summary}
\begin{itemize}
- \item TODO
+ \item Value of Libre/Open pimux dramatically underestimated\\
+ (and does not presently exist: SiFive's IOF not suitable as-is)\\
+ {\bf Only current option: license a commercial Pinmux }
+ \item Actual muxing (like SRAM cells) is deceptively simple
+ \item Actual pinmuxes are enormous: auto-generation essential
+ \item HDLs completely unsuited to auto-generation task\\
+ (TRM, docs): {\bf Modern OO language needed i.e. python}
+ \item Scenario Analysis / Verification and auto-generation of
+ different HDLs far easier in a Modern OO language\\
+ (better libraries, more developers)
+ \item Standardisation for RISC-V saves implementors from huge
+ duplication cost (HDL, firmware, docs, maintenance)
+ \item { \bf Ultimately it's about saving money and reducing risk }
\end{itemize}
}
projects / libreriscv.git / blobdiff