Files
FPGA-Neural-Datasheet/files/docs/datasheet/v2-en/chapters/10-hardware.tex
T
micheleandClaude Sonnet 5 d8ccc9d494 docs: datasheet addendum for two-flash programming architecture + FPGA_DATA_READY
Adds a real, dated section to ch.10 (Hardware and board) covering the
two-independent-flash architecture (neural-network data vs. boot
bitstream), the ESP32<->ECP5 JTAG-only link, and the real CABGA381
ball assignments (JTAG/PROGRAMN/INITN/DONE/CFG[2:0]/MSPI dedicated
pins), matching decisions.log DEC-0041.

Also closes ch.7's (Host interface) own long-standing "still needed"
list: the physical transport (spi_host_bridge.v) and the completion-
notification path (FPGA_DATA_READY) it used to flag as missing are
both now real -- described with the same system-idle-detector formula
implemented in the RTL.

Compiled clean (44 pages, 0 errors).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013xXuuRUWZScuo1DeYJxs3v
2026-09-07 13:11:12 +02:00

318 lines
15 KiB
TeX

\chapter{Hardware and board}
\label{ch:hw}
\section{Unchanged from V1}
V2 targets the identical board and component set as V1: Lattice ECP5
\code{LFE5U-45F-8BG381C} ($-8$, CABGA381), ISSI
\code{IS66WVE4M16EBLL-70BLI} PSRAM (64\,Mb, 4M$\times$16), same 16\,MHz
reference oscillator. The real PSRAM controller
(\code{psram\_controller.v}) and its byte$\leftrightarrow$word adapter
(\code{memory\_interface.v}) are reused byte-for-byte, unmodified, from
\code{hardware/v1/} throughout every V2 milestone --- their real,
already-verified electrical/timing requirements and page-mode behavior
are unchanged, because the controller itself was never touched.
\begin{fnnote}[Real ball assignment: defer to V1's own chapter]
V1's own hardware chapter documents a real, \code{iodb.json}-verified,
place\&route-confirmed ball assignment for every PSRAM signal
(\code{psram\_a}, \code{psram\_dq}, \code{psram\_ce\_n/oe\_n/we\_n/
lb\_n/ub\_n/zz\_n}). Since V2's own \code{neural\_multiprocessor.v}
drives these signals through the identical, unmodified controller, that
same real ball assignment applies unchanged if V2 is deployed on the
same physical board --- it is not repeated here to avoid maintaining two
copies of the same real data; see the V1 datasheet directly.
\end{fnnote}
\section{What V2 has not yet placed on real hardware}
As stated in ch.~\ref{ch:host}, V2's own node-registration bus has no
physical pin assignment in this revision --- every V2 characterization
to date used either a Verilator testbench or an unconstrained
(\code{--lpf-allow-unconstrained}) synthesis top-level. A real deployment
would need:
\begin{itemize}
\item A physical host transport for the registration bus (ch.~\ref{ch:host}).
\item A real, constrained \code{nextpnr-ecp5} place\&route run
producing a genuine \code{.lpf}/ball assignment for
\code{neural\_multiprocessor.v}'s own top-level pins, analogous to
V1's own \code{tools/pinout/gen\_lpf.py} flow.
\item Re-verification that the real Fmax numbers in ch.~\ref{ch:impl2}
(obtained unconstrained) hold once real pin locations are fixed ---
pin placement can itself affect routing and therefore Fmax.
\end{itemize}
\section{Power supply, oscillator, configuration}
Unchanged from V1: same board-level power sequencing, same oscillator,
same JTAG/config-SPI boot path (fixed-function dedicated pins, outside
RTL scope). No V2-specific hardware change was made or is required
beyond the (not yet placed) registration-bus transport above.
\section{SDRAM upgrade addendum (2026-09-07) --- current, authoritative
board state}
\label{sec:sdram-addendum}
\begin{fnwarn}[This section supersedes the PSRAM description above for
the current hardware baseline]
The sections above describe an earlier V2 milestone that still reused
V1's own PSRAM chain unconstrained. The project has since made a
closed architectural decision (real \code{decisions.log} DEC-0034) to
replace external memory with a single SDR SDRAM device, and has since
upgraded that device's capacity and re-verified real, constrained
place\&route timing. This section is the current, real, measured state
--- see \code{hardware/v2/docs/MEMORY\_UPGRADE\_64MB\_N8.md} in the
repository for the full investigation.
\end{fnwarn}
\subsection{Memory device}
\textbf{Alliance Memory AS4C32M16SB-7BIN} --- 512\,Mbit (64\,MByte) SDR
SDRAM, organized 4 banks $\times$ 8M words $\times$ 16 bits, 54-ball
FBGA package (8$\times$8$\times$1.2\,mm max), $-40$ to $85^{\circ}$C
industrial, $-7$ speed grade (143\,MHz max). VDD/VDDQ 3.3\,V $\pm$0.3\,V.
Single-ended \code{CLK} --- \textbf{no \code{CLK\_N}}, this is SDR, not
DDR, SDRAM. Real distributor availability confirmed: DigiKey product
11613071, 568 units in stock, \$31.12/unit (qty 1), 16-week
manufacturer lead time.
\subsection{Complete AS4C32M16SB-7BIN ball assignment}
From the manufacturer's own \code{-7BIN}-specific datasheet (Alliance
Memory, Rev.\,1.4, June 2024, Figure~1.1 --- the real TFBGA ball
diagram, not inferred from the TSOP-II \code{-7TIN} pinout).
\begin{fnnote}[Address / Bank]
A0=H7, A1=H8, A2=J8, A3=J7, A4=J3, A5=J2, A6=H3, A7=H2, A8=H1, A9=G3,
A10/AP=H9, A11=G2, A12=G1, BA0=G7, BA1=G8.
\end{fnnote}
\begin{fnnote}[Data / Masks]
DQ0=A8, DQ1=B9, DQ2=B8, DQ3=C9, DQ4=C8, DQ5=D9, DQ6=D8, DQ7=E9, DQ8=E1,
DQ9=D2, DQ10=D1, DQ11=C2, DQ12=C1, DQ13=B2, DQ14=B1, DQ15=A2, LDQM=E8,
UDQM=F1.
\end{fnnote}
\begin{fnnote}[Control / Power]
CLK=F2, CKE=F3, CS\#=G9, RAS\#=F8, CAS\#=F7, WE\#=F9. VDD=\{A9,E7,J9\},
VSS=\{A1,E3,J1\}, VDDQ=\{A7,B3,C7,D3\}, VSSQ=\{A3,B7,C3,D7\}, NC=E2.
\end{fnnote}
\subsection{FPGA $\leftrightarrow$ SDRAM mapping (real, LPF-verified)}
From \code{hardware/v2/constraints/v2\_board\_top.lpf} (45/45 unique
FPGA balls, no duplicates, LFE5U-45F-8BG381 rev.\,3.0 CSV-verified).
\begin{fnnote}[FPGA ball $\to$ SDRAM ball, by signal group]
\code{sdram\_a[0..12]}: D5,D3,F4,E5,E3,F5,A2,B1,C2,C1,D2,D1,F1 $\to$
A0..A12 (H7,H8,J8,J7,J3,J2,H3,H2,H1,G3,H9,G2,G1). \code{sdram\_ba[0:1]}:
E4,C3 $\to$ BA0,BA1 (G7,G8). \code{sdram\_dq[0..15]}:
E1,G5,H3,J5,K3,K2,H1,J1,K1,K4,L4,L5,M5,M4,N4,N5 $\to$ DQ0..DQ15.
\code{sdram\_dqm[0:1]}: P5,N3 $\to$ LDQM,UDQM. Control:
\code{sdram\_cke/cs\_n/ras\_n/cas\_n/we\_n}: B5,C5,C4,A3,B3 $\to$
CKE,CS\#,RAS\#,CAS\#,WE\#.
\end{fnnote}
\subsection{Real, measured clock closure (nextpnr-ecp5, 8 seeds/config)}
\begin{tabularx}{\textwidth}{L{4.0cm} C{1.6cm} C{2.2cm} X}
\toprule
\rowh \thd{Configuration} & \thd{Pass} & \thd{Worst Fmax} & \thd{Notes} \\
\midrule
N\_SLOTS=4 @ 64\,MHz & 8/8 & 66.58\,MHz & Production baseline, GO \\
\rowa N\_SLOTS=8 @ 64\,MHz & 5/8 & 60.12\,MHz & Open, not production-frozen \\
N\_SLOTS=4/8 @ 80\,MHz & 0/8 & --- & NO-GO, genuine \code{ecppll}-regenerated PLL \\
\bottomrule
\end{tabularx}
Real, measured after the ERR-0029 weight-cache hit-index optimization
(serial priority scan $\to$ flat one-hot compare); see
\code{hardware/v2/logs/errors.log} and \code{decisions.log} DEC-0040.
\section{Power supply design (2026-09-07) --- verified against the real
Lattice hardware checklist}
\label{sec:power-addendum}
\begin{fnwarn}[Supersedes the generic \S3 stub above]
The ``Power supply, oscillator, configuration'' section earlier in
this chapter only said ``unchanged from V1'' without real design data.
This section replaces that stub with the actual rail topology, sized
against the real, primary-source Lattice and TI documents below --- not
estimated.
\end{fnwarn}
\subsection{Rail topology}
Three rails, one simplification from the original V1 reference design:
\textbf{no separate buck regulator for the 3.3\,V I/O rail} --- the
board's own external input is specified as \textbf{3.3\,V}, so
\code{VCCIO}, the SDRAM (VDD/VDDQ, 3.3\,V per its own datasheet), and
the flash (3.3\,V) are fed directly from the board input. A buck
targeting 3.3\,V output from a 3.3\,V input would run at 100\% duty
cycle permanently --- zero regulation margin, no benefit over a direct
connection.
\begin{tabularx}{\textwidth}{L{2.6cm} L{2.0cm} L{3.2cm} X}
\toprule
\rowh \thd{Rail} & \thd{Value} & \thd{Source} & \thd{Feeds} \\
\midrule
I/O & 3.3\,V & Direct board input & FPGA \code{VCCIO0--8}, SDRAM VDD/VDDQ, SPI flash, PMOD \\
\rowa Core & 1.1\,V & TLV62568 (buck), from the 3.3\,V rail & FPGA \code{VCC} \\
Auxiliary & 2.5\,V & TLV73325 (LDO), from the 3.3\,V rail & FPGA \code{VCCAUX} \\
\bottomrule
\end{tabularx}
\subsection{Power-up sequencing --- real Lattice requirement, verified
compliant}
Per Lattice's own \emph{ECP5 and ECP5-5G Hardware Checklist}
(FPGA-TN-02038-2.0, July 2024), \S4: \emph{``\code{VCCIO} supplies
should be powered up before or together with the \code{VCC} and
\code{VCCAUX} supplies.''} The same document's \S2 adds: all three
monitored rails must rise \textbf{monotonically}, and the on-chip
Power-On-Reset de-asserts only once \code{VCC}$\geq$0.9\,V,
\code{VCCAUX}$\geq$2.0\,V, and \code{VCCIO8}$\geq$0.95\,V are all
simultaneously satisfied --- device initialization waits for whichever
of the three is slowest.
This board's topology satisfies the requirement \textbf{by construction},
with no sequencer IC needed: \code{VCCIO} (3.3\,V) is a direct,
unregulated connection to the board input, so it rises first/fastest,
strictly before the two regulated rails (Core, Aux) can even begin
their own soft-start ramps --- ``before or together with'' is met on
every possible power-up transient, not just the typical case.
\subsection{Decoupling --- real Lattice-recommended values (not a
generic ``one cap per pin'' guess)}
Per FPGA-TN-02038-2.0 Table~3.1 (\S3.1), applied per-rail:
\begin{tabularx}{\textwidth}{L{2.0cm} L{5.0cm} X}
\toprule
\rowh \thd{Rail} & \thd{Filter} & \thd{Notes} \\
\midrule
\code{VCC} & 10\,\textmu F $\times$3 (bulk) $+$ 100\,nF per pin & Core, 1.1\,V \\
\rowa \code{VCCAUX} & 120\,$\Omega$ ferrite bead $+$ 10\,\textmu F $+$
100\,nF per pin & 2.5\,V; \textbf{new part not in the earlier power
tree draft} --- a ferrite bead in series was missing before this
verification pass \\
\code{VCCIO[0--8]} & 10\,\textmu F $+$ 100\,nF per pin (per bank in
use) & 1\textmu F acceptable on unused banks; 22\,\textmu F (or a
second 10\,\textmu F) on banks with heavy output loading \\
\bottomrule
\end{tabularx}
Capacitor selection, also per the same document: X5R/X7R dielectric
(avoid Y5V/Z5U), voltage rating $\geq$80\% above the rail's maximum ---
for the 3.3\,V rail this means a \textbf{6.3\,V minimum} rating, not
the bare 3.3\,V-rated parts sometimes used to save cost. All ground
pins tie to the board's ground plane (no star grounding on this
family).
\subsection{Regulator component values (real, computed from datasheet
constants)}
\textbf{TLV62568} (core, 1.1\,V): input range 2.5--5.5\,V (3.3\,V
input has full margin); feedback reference \code{VFB}$=0.6$\,V
(typical, per TI SLVSD89B). Output set via
$V_{OUT}=V_{FB}\left(1+\frac{R1}{R2}\right)$: choosing
\textbf{R1$=$100\,k$\Omega$, R2$=$120\,k$\Omega$} gives
$0.6\times(1+100/120)=1.1$\,V exactly. Per TI's own typical
application circuit: C1$=$4.7\,\textmu F on \code{VIN}, L1$=$2.2\,
\textmu H inductor, C2$=$10\,\textmu F on \code{VOUT}.
\textbf{TLV73325} (auxiliary, 2.5\,V fixed-output LDO): input range
1.4--5.5\,V (per TI SBVS221, real datasheet), dropout 125\,mV at
300\,mA --- far above this rail's $\sim$10\,mA real load, so dropout is
not a concern at 3.3\,V input. Capacitor-free architecture (stable
without external caps at the regulator itself); the 10\,\textmu F$+$
100\,nF on \code{VCCAUX} above are the FPGA-side filter from
FPGA-TN-02038, not regulator-stability caps, and are still required.
\begin{fnnote}[Open item carried from \S3 above]
The 16\,MHz reference oscillator's exact manufacturer part number is
not yet specified in this document (only ``16\,MHz'' as a frequency
requirement) --- flagged, not invented, pending the schematic capture
the user is preparing separately.
\end{fnnote}
\subsection{Power tree}
\begin{center}
\begin{tikzpicture}[node distance=10mm and 14mm,font=\footnotesize]
\node[fnblockD,minimum width=30mm,minimum height=11mm] (in){Board input\\3.3\,V};
\node[fnblock,below left=14mm and -6mm of in,minimum width=32mm,minimum height=13mm] (u3){TLV62568 (buck)\\R1/R2 $\to$ 1.1\,V};
\node[fnblockT,below right=14mm and -6mm of in,minimum width=32mm,minimum height=13mm] (u5){TLV73325 (LDO)\\fixed 2.5\,V};
\node[fnblockA,right=30mm of in,minimum width=26mm,minimum height=11mm] (io){\code{VCCIO0--8}\\3.3\,V direct};
\node[fnreg,below=8mm of io,minimum width=26mm] (sd){SDRAM VDD/VDDQ};
\node[fnreg,below=6mm of sd,minimum width=26mm] (fl){SPI flash \code{VCC}};
\node[fnblock,below=18mm of u3,minimum width=30mm,minimum height=11mm] (core){FPGA \code{VCC}\\1.1\,V core};
\node[fnblockT,below=18mm of u5,minimum width=30mm,minimum height=11mm] (aux){FPGA \code{VCCAUX}\\2.5\,V};
\draw[fnbus] (in) -- (io);
\draw[fnarrow] (io) -- (sd);
\draw[fnarrow] (io) -- (fl);
\draw[fnbus] (in) -- (u3);
\draw[fnbus] (in) -- (u5);
\draw[fnbus] (u3) -- node[fnlbl,right]{10\textmu F$\times$3 + 100nF/pin} (core);
\draw[fnbus] (u5) -- node[fnlbl,right]{120$\Omega$ FB + 10\textmu F + 100nF/pin} (aux);
\end{tikzpicture}
\end{center}
\begin{center}
{\scriptsize Power tree, direct 3.3\,V I/O rail (no redundant buck), verified against
FPGA-TN-02038-2.0 \S3--4. Full schematic capture (BOM, connectors,
FPGA--RAM/FLASH and PROG sections) pending separately.}
\end{center}
\section{Programming architecture (2026-09-07) --- two independent
flash devices, ESP32 over JTAG only}
\label{sec:prog-addendum}
\begin{fnwarn}[Real, closed design -- not a placeholder]
Converged after evaluating and rejecting a single-shared-flash and an
SSPI-every-boot alternative (see \code{decisions.log} DEC-0041 for the
full comparison). This is the current, real architecture.
\end{fnwarn}
\subsection{Two physically separate flash chips}
\begin{itemize}
\item \textbf{Flash \#1} --- neural-network weights/graph data.
V1's own real subsystem (\code{flash\_copy\_engine.v}/
\code{flash\_slot\_manager.v}), 4 ordinary GPIO balls. V1's own
real balls (\code{flash\_sclk}=E3, \code{flash\_mosi}=D3,
\code{flash\_miso}=D5, \code{flash\_cs\_n}=E4) are \textbf{not}
reusable in V2 --- confirmed conflict, all four already carry
V2's own SDRAM bus. New balls reserved (bank~7, 3.3\,V):
\code{flash\_sclk}=B2, \code{flash\_mosi}=E2,
\code{flash\_miso}=F2, \code{flash\_cs\_n}=F3. \textbf{Not yet
in the LPF} --- the RTL port does not exist in
\code{fpga\_neural\_v2\_top.v} yet (a real, separate, open
integration task).
\item \textbf{Flash \#2} --- boot bitstream only. Connects
exclusively to the ECP5's own dedicated sysCONFIG pins, Master
SPI mode, auto-boots every power-up, zero ESP32 involvement in
normal operation.
\end{itemize}
\subsection{ESP32 $\leftrightarrow$ ECP5: JTAG only}
Neither ESP32-S3 nor ESP32-C6 has a hardware JTAG \emph{master}
peripheral (verified against Espressif's own documentation): their
native ``USB Serial/JTAG Controller'' lets an external host debug the
ESP32 itself --- the wrong direction for driving the ECP5. TCK/TMS/
TDI/TDO are therefore bit-banged from ordinary ESP32 GPIO, standard
practice. ESP32 updates flash~\#2 by commanding the ECP5's own
internal sysCONFIG engine to bridge JTAG writes through to the
external flash (real Lattice mechanism, FPGA-TN-02038-2.0 Figure~6.3,
``Programming external Flash via JTAG'') --- ESP32 never drives
flash~\#2's own SPI pins directly, zero bus contention by
construction.
\subsection{Real ball assignments (CABGA381)}
From the official Lattice pinout CSV (\code{FPGA-SC-02034-3-0-
ECP5U-45-Pinout.csv} rev.\,3.0) cross-checked against Project
Trellis's \code{iodb.json}.
\begin{fnnote}[JTAG (bank 40/TAP) --- to ESP32]
TCK=T5, TMS=U5, TDI=R5, TDO=V4.
\end{fnnote}
\begin{fnnote}[Dedicated config (bank 8) --- to ESP32]
PROGRAMN=W3, INITN=V3, DONE=Y3.
\end{fnnote}
\begin{fnnote}[CFG{[}2:0{]} (bank 8) --- board jumpers/0$\Omega$, NOT to ESP32]
For MSPI, CFG[2:0]$=$[0,1,0] read MSB-first: CFG\_2(R4)$=$GND,
CFG\_1(T4)$=$pull-up 1--10\,k$\Omega$ to VCCIO8, CFG\_0(U4)$=$GND.
\end{fnnote}
\begin{fnnote}[MSPI dedicated/dual-function pins to flash \#2 (bank 8) --- NOT to ESP32]
MCLK/CCLK=U3, CSSPIN=R2 (dual w/ HOLDN/DI/BUSY/CEN), D0/MOSI=W2,
D1/MISO=V2.
\end{fnnote}
Confirmed real and safe (Lattice FPGA-TN-02039-2.3 sysCONFIG User
Guide, \S6.1.2): once User Mode is reached, the MSPI dedicated pins
tristate with a weak pull-up, so they never contend with another
driver on the same net --- not load-bearing for this specific
two-chip architecture (flash \#1/\#2 are physically separate), but
confirms the mechanism is real should a future revision ever share a
single chip.