PRISM-1

Download original file

This is the original TeX manuscript source. Use the paper’s PDF for typeset equations.

Included manuscript sections

• datasheet_table.tex

Read the typeset paper

1 \documentclass[11pt,oneside,openany]{book}
2 \pdfinfoomitdate=1
3 \pdfsuppressptexinfo=15
4 \pdftrailerid{}
5 \usepackage[letterpaper,margin=0.78in]{geometry}
6 \usepackage[T1]{fontenc}
7 \usepackage[utf8]{inputenc}
8 \usepackage{lmodern,microtype}
9 \usepackage{amsmath,amssymb,amsthm,mathtools}
10 \usepackage{graphicx,booktabs,longtable,tabularx,array,multicol}
11 \usepackage{xcolor,float,placeins,enumitem,listings,fancyhdr,hyperref}
12 \usepackage{ragged2e}
13 \usepackage{titlesec}
14 \definecolor{Ink}{HTML}{17202A}
15 \definecolor{Blue}{HTML}{2E86AB}
16 \definecolor{Teal}{HTML}{2A9D8F}
17 \definecolor{PaleBlue}{HTML}{E8F1F5}
18 \definecolor{PaleTeal}{HTML}{E8F4F1}
19 \definecolor{PaleGold}{HTML}{FCF3D8}
20 \definecolor{PaleGray}{HTML}{F3F4F6}
21 \color{Ink}
22 \hypersetup{
23   colorlinks=true,
24   linkcolor=Blue,
25   urlcolor=Blue,
26   citecolor=Blue,
27   hypertexnames=false,
28   pdftitle={Komorebi PRISM-1: Final Mixed-Representation Architecture Specification},
29   pdfauthor={Komorebi P.},
30   pdfsubject={Packet-programmable mixed-representation processor for projector-resolved computation, CUDA-compatible Packet IR, PMR-GEMM, exact reconstruction, and local refinement},
31   pdfcreator={},pdfproducer={}
32 }
33 \pagestyle{fancy}
34 \fancyhf{}
35 \fancyfoot[L]{\scriptsize Komorebi PRISM-1}
36 \fancyfoot[R]{\scriptsize \thepage}
37 \renewcommand{\headrulewidth}{0pt}
38 \setlength{\parindent}{0pt}
39 \setlength{\parskip}{5pt}
40 \setlength{\emergencystretch}{2em}
41 \raggedbottom
42 \titleclass{\chapter}{straight}
43 \titleformat{\chapter}[hang]
44   {\normalfont\huge\bfseries\color{Ink}}
45   {\thechapter}
46   {0.75em}
47   {}
48 \titlespacing*{\chapter}{0pt}{2.2ex plus 0.5ex minus 0.2ex}{1.2ex}
49 \graphicspath{{figures/}}
50 \setlist[itemize]{leftmargin=1.35em,itemsep=2pt,topsep=3pt}
51 \setlist[enumerate]{leftmargin=1.55em,itemsep=3pt,topsep=3pt}
52 \newcolumntype{Y}{>{\RaggedRight\arraybackslash}X}
53 \newcolumntype{L}[1]{>{\RaggedRight\arraybackslash}p{#1}}
54 \newtheorem{definition}{Definition}[chapter]
55 \newtheorem{theorem}[definition]{Theorem}
56 \newtheorem{proposition}[definition]{Proposition}
57 \newtheorem{corollary}[definition]{Corollary}
58 \newtheorem{certificate}[definition]{Certificate}
59 \theoremstyle{remark}
60 \newtheorem{remark}[definition]{Remark}
61 \newtheorem{boundary}[definition]{Boundary}
62 \newcommand{\Pcal}{\mathcal P}
63 \newcommand{\Acal}{\mathcal A}
64 \newcommand{\Scal}{\mathcal S}
65 \newcommand{\Rcal}{\mathcal R}
66 \newcommand{\Tcal}{\mathcal T}
67 \newcommand{\norm}[1]{\left\lVert #1\right\rVert}
68 \newcommand{\Callout}[1]{\noindent\colorbox{PaleBlue}{\parbox{0.965\linewidth}{\vspace{3pt}\small\RaggedRight #1\par\vspace{3pt}}}}
69 \lstset{
70   basicstyle=\ttfamily\scriptsize,
71   breaklines=true,
72   showstringspaces=false,
73   frame=single,
74   columns=fullflexible,
75   tabsize=2
76 }
77 \begin{document}
78 
79 \begin{titlepage}
80 \centering
81 \vspace*{0.55in}
82 {\Large\color{Blue}\bfseries PROJECTOR-RESOLVED SEED CALCULUS\par}
83 \vspace{0.20in}
84 {\Huge\bfseries Komorebi PRISM-1\par}
85 \vspace{0.10in}
86 {\LARGE\bfseries A Packet-Programmable Mixed-Representation Processor\par}
87 \vspace{0.18in}
88 {\Large CUDA-like packet execution, PMR--GEMM, transform atlases, structured operators, edge recovery, and certified reconstruction\par}
89 \vspace{0.45in}
90 \includegraphics[width=0.92\linewidth,height=3.7in,keepaspectratio]{01_package_architecture.pdf}
91 \vfill
92 {\Large Komorebi P.\par}
93 \vspace{0.24in}
94 {\large Final updated architecture, programming model, CUDA compatibility path, compiler contract, verification plan, and executable model\par}
95 \end{titlepage}
96 
97 \frontmatter
98 \clearpage
99 \chapter*{Abstract}
100 \addcontentsline{toc}{chapter}{Abstract}
101 Komorebi PRISM-1 is a programmable chiplet accelerator for computations whose useful form is known before execution. Its native objects are packet graphs, transform plans, block operators, low-rank factors, Kronecker products, sparse factor chains, refinement trees, small algebraic systems, and reconstruction certificates. A dense array is one possible representation. The architecture never requires one to exist.
102 
103 The final reference design contains four compute chiplets, 64 Packet Streaming Multiprocessors, 256 packet execution groups, configurable transform engines, resident small solvers, exact arithmetic support, 192 MiB of on-package SRAM, and four HBM4 stacks. Each Packet Streaming Multiprocessor schedules packet warps across four execution groups and a shared scratchpad. The execution model is CUDA-like in its hierarchy and programmability, but it keeps atlas identity, parent-child relations, output contracts, precision weights, and certificate state visible to hardware.
104 
105 The compiler begins with Packet IR and chooses among explicit dense, block, block-sparse, low-rank, block-diagonal-plus-low-rank, Kronecker, sparse-chain, transform-domain, and packet-graph plans. PMR--GEMM supplies the recursive mixed-representation planner. The same Packet IR can lower to a CUDA compatibility backend or to PRISM. Earlier CUDA implementations already establish the software path through grouped matrix kernels, CUDA Graph replay, asynchronous transfers, FFT and sparse libraries, compressed products, Woodbury solves, and packetwise mixed precision.
106 
107 The paper specifies the package, Packet Streaming Multiprocessor, memory hierarchy, network, command format, compiler, output contracts, certificate protocol, performance accounting, FPGA path, and verification plan. Existing CUDA measurements are kept separate from PRISM architecture estimates. Representation gain, kernel gain, architecture gain, and amortization are reported as different quantities. The design remains an architecture specification. It is not fabricated silicon and it does not claim measured PRISM frequency, power, or throughput.
108 
109 \clearpage
110 \chapter*{Status and scope}
111 \addcontentsline{toc}{chapter}{Status and scope}
112 This is the final updated architecture draft. The packet types, Packet IR, output contracts, command groups, Packet Streaming Multiprocessor boundary, memory hierarchy, compiler routes, error-budget rules, CUDA compatibility path, and verification ladder are specified. Circuit timing, SRAM banking, NoC virtual channels, floorplanning, hardened interface IP, and process-node choices remain implementation work.
113 
114 The package baseline uses public interfaces that are available or specified at the time of this draft. UCIe 3.0 includes 48 and 64 GT/s die-to-die classes. PCIe 7.0 specifies 128 GT/s. Micron lists 36 GB HBM4 in high-volume production with bandwidth above 2.8 TB/s per stack. The management cores use the ratified RISC-V vector programming model. These facts establish a plausible component baseline. They do not validate the PRISM microarchitecture.
115 
116 \Callout{PRISM-1 does not preserve a dense matrix. It preserves the mathematical output contract. A packet program may remain a factor graph, transform plan, sparse chain, low-rank correction, or executable operator from beginning to end.}
117 
118 \clearpage
119 \chapter*{Executive summary}
120 \addcontentsline{toc}{chapter}{Executive summary}
121 The design is built around seven practical decisions.
122 \begin{enumerate}
123 \item Keep representation visible from the calculus front end to the command queue.
124 \item Treat a dense array as an optional leaf or requested output, not as mandatory machine state.
125 \item Use one Packet IR for the CUDA backend and the PRISM backend.
126 \item Schedule packet warps on programmable Packet Streaming Multiprocessors.
127 \item Keep factors, transform plans, and packet graphs resident whenever later stages can consume them directly.
128 \item Keep exact archives separate from compact predictive states.
129 \item Make residuals and error bounds part of the commit path.
130 \end{enumerate}
131 
132 The software basis already exists. On the recorded RTX 3070 Ti Laptop GPU, an equal-block packet operator was measured at $0.046032$ ms and ran $14.8919\times$ faster than its matched device-resident dense GPU row. A BDLR packet path with CUDA Graph replay was measured at $0.079872$ ms and ran $10.9355\times$ faster than the matched dense GPU row. Graph replay improved the same packet representation by about $1.218\times$. A compressed BDLR product took $0.1582$ ms, while materializing the output took $0.5073$ ms. These measurements show that the calculus can already execute on CUDA without preserving a dense matrix.
133 
134 PRISM addresses the work left after the representation has already improved. Its likely advantages come from resident factor reuse, packet gather and scatter, transform-to-solver handoff, grouped small-block dispatch, local refinement, deterministic graph replay, and certificate accumulation. The architecture model estimates gains of $2.96\times$ for the resident edge-recovery chain, $1.64\times$ for a fused multi-atlas path, and $1.42\times$ for a shape-batched Bayesian portfolio. Those are architecture estimates. They are not silicon measurements.
135 
136 The earlier $37.8\times$ dense-route comparison is retained only as a total route model. It combines a better representation with a different architecture. It is not reported as a PRISM-over-CUDA architecture gain.
137 
138 \clearpage
139 \tableofcontents
140 \clearpage
141 \listoffigures
142 
143 \clearpage
144 \mainmatter
145 \chapter{Design brief}
146 
147 \section{The design problem}
148 Many computations begin with structure that disappears before hardware sees the job. A block operator becomes one dense matrix. A Fourier or wavelet atlas becomes an unnamed array. A parent packet and its children become unrelated buffers. A low-rank correction is materialized even when every later stage could have consumed its factors.
149 
150 PRISM-1 keeps those relations explicit. The architecture is useful only when that choice saves arithmetic, storage, data movement, or scheduling work. The compiler is allowed to decline the packet path.
151 
152 \section{Required behavior}
153 \begin{longtable}{L{0.25\linewidth}L{0.66\linewidth}}
154 \toprule
155 Requirement & Meaning \\
156 \midrule
157 \endfirsthead
158 \toprule
159 Requirement & Meaning \\
160 \midrule
161 \endhead
162 Exact packet synthesis & A declared complete packet family must reconstruct the original object within the stated numerical format \\
163 Typed transfer & Every operator edge retains its source packet, destination packet, shape, rank, precision, and sensitivity \\
164 Local refinement & Replacing one parent by a child graph must not force unrelated tasks to be regenerated \\
165 Representation preservation & Block, sparse, low-rank, Kronecker, factor-chain, transform, and packet-graph forms remain executable without an explicit full array \\
166 Provisional execution & Results that require a certificate remain hidden from downstream work until the check passes \\
167 Deterministic replay & Selected graph regions can use fixed reductions and stable descriptors for reproducible reruns \\
168 Graceful rejection & Work with weak structure is routed to the CUDA backend, a general-purpose path, or a generic leaf \\
169 \bottomrule
170 \end{longtable}
171 
172 \section{Design rules}
173 \begin{enumerate}
174 \item The mathematical object and its storage representation are not assumed to be the same thing.
175 \item A packet descriptor is part of the architectural state, not debugging metadata.
176 \item An application result, a factor graph, a transform plan, and an explicit array are different output contracts.
177 \item A numerical result is not committed merely because the kernel finished.
178 \item A failed certificate should identify the local graph region that needs replay or refinement.
179 \item The first prototype should preserve the final command and descriptor formats even if it implements fewer engines.
180 \end{enumerate}
181 
182 \begin{figure}[H]
183 \centering
184 \includegraphics[width=0.98\linewidth]{24_packet_lifecycle.pdf}
185 \caption{One packet command from archive to commit. The provisional state prevents an unchecked result from becoming visible to downstream work.}
186 \end{figure}
187 
188 \begin{figure}[H]
189 \centering
190 \includegraphics[width=0.94\linewidth]{25_workload_router.pdf}
191 \caption{The compiler is expected to route weakly structured work away from the packet path.}
192 \end{figure}
193 
194 \section{What this design does not promise}
195 PRISM-1 is not a universal replacement for a GPU or CPU. It does not claim a better asymptotic exponent for generic dense linear algebra. It does not claim that every operator has a useful structured representation. It does not treat modeled roofline numbers as measured performance. Its case rests on workloads where structure is real, reusable, and large enough to amortize descriptor, planning, and scheduling cost.
196 
197 \chapter{Why this chip exists}
198 
199 \section{The representation is part of the computation}
200 A conventional accelerator usually receives a tensor after the representation has already been chosen. It may execute that tensor well and still miss the simpler object underneath it. The operator may be block diagonal, block sparse, low rank, generated by a transform, or recoverable from a much smaller packet graph.
201 
202 Projector-resolved computation starts before that flattening step. Let
203 \[
204 X=\bigoplus_{\alpha\in I}X_\alpha,
205 \qquad
206 P_\alpha P_\beta=\delta_{\alpha\beta}P_\alpha,
207 \qquad
208 \sum_{\alpha\in I}P_\alpha=I.
209 \]
210 For an operator $T:X\to X$, the native objects are the transfer blocks
211 \[
212 T_{\beta\alpha}=P_\beta T P_\alpha.
213 \]
214 The complete operator is reconstructed by
215 \[
216 \boxed{T=\sum_{\alpha,\beta}T_{\beta\alpha}.}
217 \]
218 The zero pattern, block shapes, rank structure, parent-child relations, and packet sensitivities are part of the problem. PRISM-1 carries them into the execution model instead of asking software to rediscover them after every kernel boundary.
219 
220 \section{The target workload}
221 The design focuses on operations that recur throughout the calculus:
222 \begin{itemize}
223 \item residue and phase projectors
224 \item polyphase extraction and interleaving
225 \item Fourier, cosine, Hadamard, and wavelet atlases
226 \item packet-tree refinement and coarsening
227 \item block-diagonal and block-sparse transfers
228 \item block diagonal plus low rank operators
229 \item exact compressed products and Woodbury solves
230 \item small Hankel, QR, SVD, root, and Vandermonde problems
231 \item nonlinear packet interactions and memory kernels
232 \item conjugate Bayesian regression and posterior mixtures
233 \item exact modular, CRT, and valuation operations
234 \item residual and error-bound certificates
235 \end{itemize}
236 
237 \begin{figure}[H]
238 \centering
239 \includegraphics[width=0.98\linewidth]{03_calculus_pipeline.pdf}
240 \caption{The seed-calculus operations become a hardware pipeline without losing their mathematical type.}
241 \end{figure}
242 
243 \section{What the chip is not}
244 PRISM-1 should not be used simply because a packet description exists. A generic dense matrix with no reusable structure may run better through a conventional library path. A tiny one-off transform may not amortize descriptor setup. A graph that changes completely at every step may not benefit from replay. The compiler should reject or reroute those cases.
245 
246 \section{No dense preservation requirement}
247 The architecture does not begin with a dense matrix and try to compress it after the fact. It begins with a typed operator. That operator may be represented as
248 \[
249 \boxed{
250 \begin{aligned}
251 \mathfrak R=\{&\text{explicit array},\ \text{block},\ \text{block sparse},\ \text{low rank},\ \text{BDLR},\\
252 &\text{Kronecker},\ \text{sparse chain},\ \text{transform plan},\ \text{packet graph}\}.
253 \end{aligned}
254 }
255 \]
256 A dense representation is useful when no better form exists or when a downstream user explicitly asks for every entry. It is not a state that the chip must preserve.
257 
258 \begin{figure}[H]
259 \centering
260 \includegraphics[width=0.97\linewidth]{38_mixed_representation_space.pdf}
261 \caption{One operator may have several executable representations. The explicit array is one optional leaf.}
262 \end{figure}
263 
264 \section{CUDA-like execution hierarchy}
265 CUDA made heterogeneous arithmetic programmable through a hierarchy of lanes, warps, blocks, grids, and memories. PRISM uses an analogous execution hierarchy while retaining the mathematical structure that CUDA kernels normally receive only through software conventions:
266 \[
267 \boxed{
268 \text{lane}
269 \longrightarrow
270 \text{packet warp}
271 \longrightarrow
272 \text{execution group}
273 \longrightarrow
274 \text{Packet Streaming Multiprocessor}
275 \longrightarrow
276 \text{packet graph}.
277 }
278 \]
279 A packet warp may invoke a matrix group, vector lanes, a transform engine, a small solver, exact arithmetic, or a memory operator. The representation router chooses the form declared by Packet IR. Several forms may appear in one graph.
280 
281 \section{The CUDA implementation is the software foundation}
282 The packet algorithms already run on CUDA. Equal blocks are stacked and sent to grouped or batched matrix kernels. BDLR application uses a block batch followed by two low-rank contractions. Repeated graphs use CUDA Graph replay. Fourier and sparse stages use established libraries. The runtime keeps factors resident when the output contract allows it.
283 
284 This matters for the chip design. PRISM is not a replacement for the CUDA algorithms. It is a hardware target for the same Packet IR. The CUDA backend remains the development platform, portability path, and matched comparison.
285 
286 \begin{figure}[H]
287 \centering
288 \includegraphics[width=0.94\linewidth]{40_shared_packet_ir.pdf}
289 \caption{The CUDA and PRISM backends execute the same Packet IR and preserve the same output contracts.}
290 \end{figure}
291 
292 \chapter{Mixed-representation execution}
293 
294 \section{Output contracts}
295 A computation is not defined only by the numerical entries of a hypothetical matrix. The caller also specifies what must be returned. PRISM uses five principal contracts:
296 \begin{enumerate}
297 \item apply an operator to one or more vectors
298 \item return a compressed operator
299 \item return a factor or packet graph
300 \item return a transform plan
301 \item return every entry of an explicit array
302 \end{enumerate}
303 Only the fifth contract forces materialization.
304 
305 \begin{figure}[H]
306 \centering
307 \includegraphics[width=0.96\linewidth]{42_output_contracts.pdf}
308 \caption{Materialization is required only when the requested output is the explicit full array.}
309 \end{figure}
310 
311 \section{Compatible middle bases}
312 The intermediate basis is part of the optimization. For any invertible $S$,
313 \[
314 AB=(AS)(S^{-1}B).
315 \]
316 Suppose
317 \[
318 A=L D_A S^{-1},
319 \qquad
320 B=S D_B R.
321 \]
322 Then
323 \[
324 \boxed{AB=L(D_AD_B)R.}
325 \]
326 When $L$, $S$, and $R$ have fast application and $D_A$, $D_B$ are block diagonal, the product inherits the blockwise cost plus the transform costs. Fourier diagonalization of circulants, simultaneous diagonalization, symmetry sectors, and tensor factorizations are instances of the same rule.
327 
328 \section{Sparse chains and transform plans}
329 A matrix may be dense as an array and cheap as an operator. If
330 \[
331 A=F_LF_{L-1}\cdots F_1
332 \]
333 and each factor has $O(n)$ nonzero entries, then applying $A$ costs $O(nL)$. If $L=O(\log n)$, the cost is $O(n\log n)$. FFT and butterfly operators fit this pattern. PRISM stores the factor chain and executes it. It does not store the dense array represented by the chain.
334 
335 \section{PMR--GEMM}
336 Packet Mixed-Representation GEMM is the compiler planner for operator products. It accepts the operator pair, tolerance, output contract, candidate transforms, and packet tree. At each node it may use a generic leaf, a low-rank contraction, a Kronecker identity, a sparse factor chain, a transform-domain rule, or a recursive split.
337 
338 For a fixed candidate tree, each choice $o$ has a local cost $c(o)$, a local error $e(o)$, and zero or more children. The planner evaluates
339 \[
340 J(v)=\min_{o\in\mathcal O_v}
341 \left[
342  c(o)+\lambda e(o)^2+
343  \sum_{u\in\operatorname{child}(o)}J(u)
344 \right].
345 \]
346 Bottom-up evaluation is globally optimal on the fixed tree because every feasible plan consists of one local choice followed by feasible child plans.
347 
348 \begin{figure}[H]
349 \centering
350 \includegraphics[width=0.97\linewidth]{39_pmr_gemm_planner.pdf}
351 \caption{PMR--GEMM chooses the least-cost certified plan that satisfies the requested output contract.}
352 \end{figure}
353 
354 \section{Hybrid fallback}
355 The planner always includes a generic leaf. This protects the worst case. Random dense matrices with no useful local rank, transform, tensor, or packet structure return to the generic path. The architecture is strongest when the mixed plan eliminates arithmetic or movement. It does not claim that naming a packet makes an operator cheaper.
356 
357 \chapter{Reference package}
358 
359 \section{Chiplet organization}
360 The reference package contains four compute chiplets, one I/O and control die, and four HBM4 stacks. Each compute chiplet contains 16 Packet Streaming Multiprocessors. Every multiprocessor contains four packet execution groups, giving 64 execution groups per chiplet and 256 across the package. Each chiplet also contains eight transform engines, four small-solver engines, one exact arithmetic cluster, and 16 MiB of shared SRAM.
361 
362 \begin{figure}[H]
363 \centering
364 \includegraphics[width=0.98\linewidth]{01_package_architecture.pdf}
365 \caption{The reference PRISM-1 package. The center die carries host I/O, global scheduling, RISC-V control, security, and telemetry.}
366 \end{figure}
367 
368 \section{Reference targets}
369 \begin{table}[H]
370 \centering
371 \caption{Reference architecture targets. These values belong to the model, not measured silicon.}
372 \begin{tabularx}{0.94\linewidth}{L{0.42\linewidth}Y}
373 \toprule
374 Property & Reference target \\
375 \midrule
376 Compute chiplets & 4 \\
377 Packet Streaming Multiprocessors & 64 \\
378 Packet execution groups & 256 \\
379 Execution group array & $16\times16$ matrix array plus vector lanes \\
380 Clock & 1.5 GHz \\
381 PSM scratchpad & 2 MiB across four independently banked regions \\
382 Shared SRAM & 16 MiB per compute chiplet \\
383 Total local and shared SRAM & 192 MiB \\
384 Transform engines & 32 \\
385 Small-solver engines & 16 \\
386 Exact arithmetic clusters & 4 \\
387 HBM4 & 4 stacks, 144 GiB total \\
388 Aggregate HBM bandwidth & greater than 11.2 TB/s \\
389 Package fabric & UCIe 3.0 class, up to 64 GT/s \\
390 Host interface & PCIe 7.0 x16 class, optional CXL \\
391 Reference power envelope & 500 W \\
392 \bottomrule
393 \end{tabularx}
394 \end{table}
395 
396 \section{Compute-chiplet layout}
397 The reference chiplet places a $4\times4$ mesh of Packet Streaming Multiprocessors at its center. Every multiprocessor contains four execution groups, giving 64 matrix and vector groups per chiplet. Transform engines sit along one edge, solver engines along another, shared SRAM banks line the data path, and the UCIe router occupies a package-facing edge. This is a planning floorplan rather than a placed design. Its purpose is to make communication and locality assumptions visible early.
398 
399 \begin{figure}[H]
400 \centering
401 \includegraphics[width=0.82\linewidth]{26_chiplet_floorplan.pdf}
402 \caption{Reference compute-chiplet floorplan. The drawing is functional. Bank count, channel width, and physical dimensions remain open.}
403 \end{figure}
404 
405 \section{Bandwidth balance}
406 The host link is intended for graph submission, coarse data movement, and result return. It is not the steady-state path for every packet. Reusable graphs, factors, and active atlases should remain in HBM or on-package SRAM. The modeled package fabric is wider than aggregate HBM bandwidth so inter-chiplet traffic does not become an immediate architectural bottleneck in the reference configuration.
407 
408 \begin{figure}[H]
409 \centering
410 \includegraphics[width=0.78\linewidth]{27_bandwidth_budget.pdf}
411 \caption{Reference bandwidth levels. Local SRAM bandwidth is a circuit-level target and is not assigned a final number in this draft.}
412 \end{figure}
413 
414 \section{Scale-down configurations}
415 The same Packet IR, commands, and descriptors support smaller devices.
416 \begin{table}[H]
417 \centering
418 \caption{Suggested development configurations.}
419 \begin{tabularx}{0.96\linewidth}{L{0.23\linewidth}rrrrY}
420 \toprule
421 Configuration & PSMs & Execution groups & Transform & Solver & Intended use \\
422 \midrule
423 FPGA overlay & 1 & 4 & 1 & 1 & Command, DMA, representation routing, replay, and certificate validation \\
424 Shuttle chiplet & 4 to 8 & 16 to 32 & 2 to 4 & 1 to 2 & Measured locality, solver occupancy, and Packet IR conformance \\
425 Reference chiplet & 16 & 64 & 8 & 4 & Full chiplet mesh and resident solver experiments \\
426 Full package & 64 & 256 & 32 & 16 & Data-center scale structured workloads \\
427 \bottomrule
428 \end{tabularx}
429 \end{table}
430 
431 \section{Modeled arithmetic peaks}
432 With 256 execution groups and one $16\times16$ matrix array per group, the model yields
433 \[
434 \boxed{
435 \begin{aligned}
436 \text{FP16 or BF16} &\approx 196.6\text{ TFLOP/s},\\
437 \text{FP32} &\approx 98.3\text{ TFLOP/s},\\
438 \text{FP64} &\approx 24.6\text{ TFLOP/s}.
439 \end{aligned}}
440 \]
441 These are model peaks. The design is not organized around a claim of superior generic dense throughput. Its purpose is to execute fewer operations and move fewer bytes when the selected representation proves that the explicit array is unnecessary.
442 
443 \chapter{Packet Streaming Multiprocessor}
444 
445 \section{Multiprocessor anatomy}
446 The Packet Streaming Multiprocessor is the independently scheduled unit of PRISM. It accepts packet warps, reads their representation and output contracts, and routes work across four execution groups, the packet scratchpad, asynchronous DMA, transform and solver interfaces, and the certificate path.
447 
448 \begin{figure}[H]
449 \centering
450 \includegraphics[width=0.98\linewidth]{37_packet_streaming_multiprocessor.pdf}
451 \caption{One Packet Streaming Multiprocessor. A packet warp may use several execution forms without converting the operator into one explicit array.}
452 \end{figure}
453 
454 \section{Issue and completion path}
455 A packet warp becomes ready when its dependency token is satisfied and the packet directory confirms that the source representation is resident or in flight. The front end selects the representation route, reserves destination storage, and records the required certificate. Kernel completion produces a provisional result. The result becomes visible only after the check passes.
456 
457 \begin{figure}[H]
458 \centering
459 \includegraphics[width=0.90\linewidth]{28_command_state_machine.pdf}
460 \caption{Command states from queue entry to commit or local replay.}
461 \end{figure}
462 
463 Completion and commitment remain separate. A kernel may finish while its residual exceeds the declared budget. The distinction matters for mixed precision, iterative solves, approximate transforms, recovered edge packets, and low-rank recompression.
464 
465 \section{Packet scratchpad}
466 Each multiprocessor has 2 MiB of scratchpad divided into four independently banked regions. An execution group may use one bank privately or several groups may share a packet region. Separate banks hold active data, factors, descriptors, tokens, solver panels, and certificate state. Double buffering supports transforms and repeated grouped matrix batches.
467 
468 \section{Execution groups}
469 Each of the four execution groups contains a $16\times16$ matrix array and programmable vector lanes. Equal-shape blocks can be grouped across execution groups. The same lanes handle low-rank contractions, Kronecker mode products, sparse-chain factors, selectors, reductions, index generation, and generic leaves.
470 
471 Complex arithmetic uses paired real lanes. FP64 is available for certificates, small solvers, rank decisions, phase recovery, and sensitive reductions. Integer and fixed-point modes support selectors, image packets, modular arithmetic, and exact accumulators.
472 
473 \begin{figure}[H]
474 \centering
475 \includegraphics[width=0.93\linewidth]{02_packet_compute_tile.pdf}
476 \caption{Execution-group resources inside the multiprocessor. The figure shows matrix, vector, memory, nonlinear, and certificate paths.}
477 \end{figure}
478 
479 \section{Representation router}
480 The router reads the operator form from Packet IR. It dispatches block work to grouped matrix lanes, factor work to contraction lanes, transform plans to the transform fabric, small algebraic systems to resident solvers, and weakly structured leaves to the generic path. One packet warp may contain several representations.
481 
482 \section{Projector DMA}
483 The asynchronous packet DMA accepts selectors represented as intervals, strided slices, residue classes, polyphase channels, masks, index lists, transform bands, packet-tree nodes, and compact basis factors. A selector is applied through addressing and compact arithmetic. No dense projector matrix is required.
484 
485 \section{Certificate and commit path}
486 The certificate unit accumulates residuals, packet norms, trace quantities, energy partitions, branch margins, and mixed-precision bounds. Deterministic mode uses a fixed reduction tree and wide accumulation. The commit controller releases a provisional result only after the declared acceptance rule passes.
487 
488 \chapter{Descriptors as the hardware language}
489 
490 \section{Packet descriptor entry}
491 A packet descriptor identifies the packet, its parent, its atlas, its selector, its shape, its location, its precision, and its error budget.
492 
493 \begin{figure}[H]
494 \centering
495 \includegraphics[width=0.98\linewidth]{04_packet_descriptor.pdf}
496 \caption{One packet descriptor entry. The exact bit allocation may change during RTL design, but the semantic fields are fixed.}
497 \end{figure}
498 
499 \begin{definition}[Packet descriptor]
500 A packet descriptor is a typed record
501 \[
502 \mathsf P=(i,p,a,\sigma,\mathbf n,\ell,\pi,\tau),
503 \]
504 where $i$ is the packet ID, $p$ is the parent, $a$ is the atlas, $\sigma$ is the selector type, $\mathbf n$ is the shape, $\ell$ is the storage location, $\pi$ is the precision tag, and $\tau$ is the allowed local error contribution.
505 \end{definition}
506 
507 \section{Transfer edge descriptor}
508 The transfer descriptor is the hardware form of $P_\beta T P_\alpha$. It identifies the source and destination packets, operator class, shape, rank, precision, sensitivity, payload, and dependency token.
509 
510 \begin{figure}[H]
511 \centering
512 \includegraphics[width=0.98\linewidth]{05_transfer_descriptor.pdf}
513 \caption{A transfer edge descriptor keeps the operator class and certificate weight attached to the edge.}
514 \end{figure}
515 
516 \section{Atlas descriptor}
517 An atlas descriptor records an analysis graph, a synthesis graph, normalization data, and packet selectors. A unitary transform uses its adjoint for synthesis. A redundant exact frame records the canonical dual or another declared synthesis map satisfying
518 \[
519 \Scal\Acal=I.
520 \]
521 
522 \chapter{Memory hierarchy}
523 
524 \section{Exact archive and active representations}
525 The exact archive, cold factors, large graphs, and model history remain in HBM. Completeness does not imply a dense array. An exact archive may be a transform tuple, factor graph, sparse chain, packet tree, geometric edge list, or explicit sample field. Shared SRAM stores active packet graphs and reusable representations. PSM scratchpads hold local blocks, factor panels, transform stages, solver panels, and residuals.
526 
527 \begin{figure}[H]
528 \centering
529 \includegraphics[width=0.90\linewidth]{06_memory_hierarchy.pdf}
530 \caption{Representation-first memory hierarchy. The explicit full array is created only under a matching output contract.}
531 \end{figure}
532 
533 \section{Representation-first storage}
534 For an equal-block BDLR operator
535 \[
536 A=D+UV^*,
537 \]
538 with dimension $n$, block width $b$, and rank $r$, the stored scalar count is
539 \[
540 \boxed{n(b+2r)}
541 \]
542 in place of $n^2$.
543 
544 \begin{proposition}[BDLR representation reduction]
545 If $b+2r<n$, BDLR storage reduces the scalar count by
546 \[
547 \boxed{\frac{n}{b+2r}.}
548 \]
549 The same factor appears in the ideal apply count for a fixed number of right-hand sides.
550 \end{proposition}
551 
552 \begin{proof}
553 The block-diagonal part stores $(n/b)b^2=nb$ scalars. The two rank factors store $2nr$. The total is $n(b+2r)$. A full array stores $n^2$ scalars.
554 \end{proof}
555 
556 The same rule extends beyond BDLR. A Kronecker operator stores its mode factors. A butterfly stores its sparse stages. A transform-domain operator stores the plan and diagonal or block payload. A packet graph stores packet descriptors and active edge payloads. The active representation is the operator until a different output contract is requested.
557 
558 \begin{figure}[H]
559 \centering
560 \includegraphics[width=0.76\linewidth]{16_representation_memory.pdf}
561 \caption{Stored BDLR representation for the model case $n=8192$, $b=64$, and $r=8$.}
562 \end{figure}
563 
564 \chapter{Packet network and scheduling}
565 
566 \section{PSM mesh}
567 Each compute chiplet uses a $4\times4$ mesh of Packet Streaming Multiprocessors. Routers support unicast, multicast, and tree reduction. Multicast distributes low-rank factors, Kronecker factors, and transform data. Reduction combines destination contributions, small contractions, posterior scores, and residuals.
568 
569 \begin{figure}[H]
570 \centering
571 \includegraphics[width=0.62\linewidth]{20_packet_mesh.pdf}
572 \caption{One chiplet mesh. Each displayed router node represents one Packet Streaming Multiprocessor rather than one execution group.}
573 \end{figure}
574 
575 \section{Packet warps and dependency tokens}
576 Packet warps group operations that share a representation, shape class, packet relation, or certificate boundary. A warp becomes ready when its dependency tokens are satisfied. Completion tokens wake downstream work. Replayable regions keep descriptors and placement until a certificate mismatch or local refinement invalidates the region.
577 
578 \section{Local refinement}
579 Suppose a parent packet task $v$ is replaced by an acyclic child module $H=(W,F)$. Predecessors of $v$ connect to child entries. Child exits connect to successors of $v$.
580 
581 \begin{theorem}[Topological splice]
582 Let $\prec$ be a topological order of the original graph and let $\prec_H$ be a topological order of the child module. Replacing $v$ in $\prec$ by $\prec_H$ gives a topological order of the refined graph. Every unaffected pair of context tasks keeps its relative order.
583 \end{theorem}
584 
585 \begin{proof}
586 Every context edge is unchanged. Every child edge is respected by $\prec_H$. Every predecessor of $v$ appeared before $v$ and therefore before the inserted child order. Every successor appeared after $v$ and therefore after the inserted child order. Removing the inserted children restores the original context order.
587 \end{proof}
588 
589 \begin{figure}[H]
590 \centering
591 \includegraphics[width=0.74\linewidth]{11_refinement_local_schedule.pdf}
592 \caption{A parent packet is replaced by a local child graph while remote descriptors remain unchanged.}
593 \end{figure}
594 
595 \chapter{Transform fabric}
596 
597 \section{One configurable engine family}
598 The transform engines share butterfly, permutation, lifting, and selector hardware. They support FFT, DCT, FWHT, Haar, biorthogonal lifting, and polyphase transforms.
599 
600 \begin{figure}[H]
601 \centering
602 \includegraphics[width=0.92\linewidth]{08_transform_fabric.pdf}
603 \caption{The transform fabric supports several exact atlases without storing separate fixed data paths for each one.}
604 \end{figure}
605 
606 \section{Exact analysis and synthesis}
607 Let $U$ be unitary and let $E_\alpha$ be coordinate selectors. The pulled-back projectors are
608 \[
609 P_\alpha=U^*E_\alpha U.
610 \]
611 The hardware analysis applies $U$ and selects the coordinates. Synthesis scatters the selected coordinates and applies $U^*$.
612 
613 \begin{theorem}[Transform-atlas hardware contract]
614 If the selector family is complete, the analysis and synthesis command graphs satisfy
615 \[
616 \boxed{\Scal\Acal=I.}
617 \]
618 If the selector family is incomplete, the certificate must report the omitted-coordinate residual.
619 \end{theorem}
620 
621 \begin{proof}
622 For a complete selector family, $\sum_\alpha E_\alpha=I$. Hence
623 \[
624 \Scal\Acal x
625 =U^*\left(\sum_\alpha E_\alpha\right)Ux
626 =U^*Ux
627 =x.
628 \]
629 The incomplete case replaces the identity by the declared selector sum.
630 \end{proof}
631 
632 \chapter{Transfer engines}
633 
634 \section{Block diagonal and block sparse}
635 Block-diagonal operators run as independent shape batches. Block-sparse operators are grouped by edge shape and destination. Destination packet accumulation can be local, multicast, or reduced through the mesh.
636 
637 \section{BDLR dataflow}
638 For
639 \[
640 A=D+UV^*,
641 \]
642 the apply is
643 \[
644 AX=DX+U(V^*X).
645 \]
646 The diagonal blocks remain distributed. The $r\times q$ contraction is reduced and broadcast.
647 
648 \begin{figure}[H]
649 \centering
650 \includegraphics[width=0.92\linewidth]{07_bdlr_dataflow.pdf}
651 \caption{The BDLR path keeps the low-rank representation compressed.}
652 \end{figure}
653 
654 \begin{theorem}[BDLR apply count]
655 For $q$ right-hand sides and equal packet width $b$, the modeled arithmetic count is
656 \[
657 \boxed{2qn(b+2r).}
658 \]
659 A dense apply requires $2qn^2$ operations.
660 \end{theorem}
661 
662 \begin{proof}
663 The block-diagonal product costs $2qnb$. The contraction $V^*X$ costs $2nrq$. Multiplication by $U$ costs another $2nrq$. Adding the terms does not change the leading expression.
664 \end{proof}
665 
666 \section{Where BDLR remains useful}
667 The low-rank path is not uniformly favorable. Its benefit depends on block width, correction rank, right-hand-side count, and factor reuse. The reference model sweeps a range of block sizes and ranks while holding $n=8192$ and $q=32$ fixed.
668 
669 \begin{figure}[H]
670 \centering
671 \includegraphics[width=0.82\linewidth]{29_bdlr_speedup_sensitivity.pdf}
672 \caption{Modeled BDLR speedup across block width and correction rank. The comparison includes arithmetic, data movement, and graph overhead from the reference model.}
673 \end{figure}
674 
675 \begin{figure}[H]
676 \centering
677 \includegraphics[width=0.82\linewidth]{30_bdlr_storage_sensitivity.pdf}
678 \caption{Dense-to-factor storage reduction for the same parameter sweep.}
679 \end{figure}
680 
681 The compiler should not infer a gain from the name of the representation. It should evaluate the actual block width, rank, reuse, and output contract. A high-rank correction or a request for immediate dense materialization may remove most of the benefit.
682 
683 \section{Compressed composition}
684 When downstream stages accept BDLR factors, composition returns new block factors and low-rank factors. Materialization is a separate output contract. The compiler cannot compare a compressed product with a dense explicit matrix without accounting for that difference.
685 
686 \section{Woodbury solve}
687 The chip uses packet solves with $D_\alpha$ and one small dense correction:
688 \[
689 (D+UV^*)^{-1}
690 =D^{-1}-D^{-1}U(I+V^*D^{-1}U)^{-1}V^*D^{-1}.
691 \]
692 The solver engines handle the rank-sized middle system.
693 
694 \chapter{Mixed precision and certificates}
695 
696 \section{Per-edge precision}
697 A global dtype ignores the fact that packet transfers can have very different sensitivities. Each edge carries its precision and sensitivity.
698 
699 \begin{theorem}[Packet error bound]
700 Let
701 \[
702 A=\sum_{e\in E}A_e,
703 \qquad
704 \widehat A=\sum_{e\in E}(A_e+E_e).
705 \]
706 If edge $e$ starts in packet $\alpha(e)$, then
707 \[
708 \boxed{
709 \norm{(\widehat A-A)x}
710 \le
711 \sum_{e\in E}\norm{E_e}\norm{P_{\alpha(e)}x}.}
712 \]
713 \end{theorem}
714 
715 \begin{proof}
716 Exact packet reconstruction gives
717 \[
718 (\widehat A-A)x=\sum_eE_eP_{\alpha(e)}x.
719 \]
720 The triangle inequality gives the bound.
721 \end{proof}
722 
723 \section{Precision allocation}
724 Under a logarithmic cost model and total error budget $\tau$, the continuous allocation is
725 \[
726 \varepsilon_e
727 =\frac{\tau c_e}{s_e\sum_f c_f},
728 \]
729 where $s_e$ is sensitivity and $c_e$ is cost. The compiler maps the result to supported formats.
730 
731 \begin{figure}[H]
732 \centering
733 \includegraphics[width=0.78\linewidth]{19_precision_allocation.pdf}
734 \caption{More sensitive packet edges receive tighter precision targets.}
735 \end{figure}
736 
737 \chapter{Unknown-edge and Gibbs reconstruction}
738 
739 \section{Why the chip includes a small-solver path}
740 The self-calibrating reconstruction uses large transforms and very small algebraic systems in one graph. A general GPU often pays high launch and movement cost around the small systems. PRISM keeps the full chain resident.
741 
742 \begin{figure}[H]
743 \centering
744 \includegraphics[width=0.98\linewidth]{09_edge_recovery_pipeline.pdf}
745 \caption{The self-calibrating edge-recovery graph from high-frequency packet to native singular synthesis.}
746 \end{figure}
747 
748 \section{Resident Hankel and Prony operations}
749 The edge-recovery engines perform:
750 \begin{enumerate}
751 \item Fourier packet extraction
752 \item decimated polyphase grouping
753 \item streaming Hankel construction
754 \item rank estimation
755 \item annihilator solve
756 \item polynomial root recovery
757 \item physical phase selection
758 \item Vandermonde amplitude solve
759 \item edge packet synthesis
760 \item residual and branch-margin checks
761 \end{enumerate}
762 
763 \section{Small-solver organization}
764 The solver cluster is built for matrices that are too small to fill the PSM mesh but too frequent to send back to the host. A local panel store feeds QR, Cholesky, Jacobi-style SVD, companion-matrix roots, and Vandermonde solves. FP64 is the default format for rank decisions, phase recovery, and branch-margin checks.
765 
766 \begin{figure}[H]
767 \centering
768 \includegraphics[width=0.92\linewidth]{31_solver_pipeline.pdf}
769 \caption{Illustrative resident pipeline for unknown-edge recovery. Transform and solver stages overlap where data dependencies permit.}
770 \end{figure}
771 
772 The solver cluster is also used by Bayesian regression batches, Woodbury corrections, packet Krylov restarts, and small exactness checks. It is not intended to compete with a large dense eigensolver.
773 
774 \section{Why native edge synthesis matters}
775 After edge recovery, the discontinuity is synthesized as an edge packet. The smooth residual is reconstructed spectrally. The chip does not force the recovered singular packet back through a truncated global Fourier sum.
776 
777 \chapter{PR-LASM execution}
778 
779 \section{Exact archive and compact state}
780 The exact observation archive is kept in complete spatial, Fourier, Haar, polyphase, and categorical atlases. Macro, meso, and micro states are separate statistical packet types with dimensions 48, 96, and 192 in the reference model.
781 
782 \section{Resident state layout}
783 The exact archive and compact predictive states remain separate in memory and in the descriptor type system. This prevents a compact state vector from being mistaken for an invertible representation of the signal.
784 
785 \begin{figure}[H]
786 \centering
787 \includegraphics[width=0.96\linewidth]{32_pr_lasm_state_map.pdf}
788 \caption{Exact archive, compact states, mechanism portfolio, and transition graph in one resident PR-LASM step.}
789 \end{figure}
790 
791 \section{Typed Bayesian programs}
792 The mechanism portfolio shares state matrices while allowing different operators, atlases, resolutions, and memory laws. The solver engines batch models by feature shape.
793 
794 \begin{figure}[H]
795 \centering
796 \includegraphics[width=0.92\linewidth]{10_bayesian_pipeline.pdf}
797 \caption{Mechanism families share resident state matrices and small-solver batches.}
798 \end{figure}
799 
800 \section{Memory and planning}
801 Delay, power-law, exponential, and Volterra memory packets run in the nonlinear and memory units. The graph scheduler stores exact deterministic transitions separately from probabilistic predictions. Replay stops when a state or certificate mismatch is detected.
802 
803 \chapter{Exact arithmetic mode}
804 
805 \section{Residue and modular packets}
806 One exact arithmetic cluster per compute chiplet supports 64-bit modular addition, multiplication, valuation, residue selection, and CRT merge. Longer values use limb vectors in PSM scratchpad.
807 
808 \section{Why this belongs on the chip}
809 The arithmetic calculus and the signal calculus share the same structural operations:
810 \[
811 \text{residue packet}
812 \to
813 \text{transfer}
814 \to
815 \text{refinement}
816 \to
817 \text{weighted reconstruction}.
818 \]
819 The exact arithmetic path is smaller than the floating-point path, but it allows the same descriptor and graph system to execute p-adic, recurrence, and finite-field packet workloads.
820 
821 \chapter{Packet Seed Command interface}
822 
823 \section{Command groups}
824 The first implementation uses memory-resident 256-bit commands. RISC-V control cores fill a queue and ring a doorbell. The command groups are shown below.
825 
826 \begin{figure}[H]
827 \centering
828 \includegraphics[width=0.92\linewidth]{21_command_groups.pdf}
829 \caption{Packet Seed Command groups.}
830 \end{figure}
831 
832 \section{Representative commands}
833 \begin{longtable}{L{0.22\linewidth}L{0.68\linewidth}}
834 \toprule
835 Command & Meaning \\
836 \midrule
837 \endfirsthead
838 \toprule
839 Command & Meaning \\
840 \midrule
841 \endhead
842 \texttt{PSELECT} & Apply a declared packet selector without materializing a projector matrix \\
843 \texttt{PSPLIT} & Replace a parent packet by declared children \\
844 \texttt{PCOARSEN} & Reconstruct a parent from a complete child family \\
845 \texttt{POLYPHASE} & Extract, permute, or interleave phase channels \\
846 \texttt{WAVELET\_LIFT} & Execute predict, update, and scale steps \\
847 \texttt{BLK\_GEMM} & Execute a batch of equal-shape transfer blocks \\
848 \texttt{BDLR\_APPLY} & Apply block diagonal plus low rank without materialization \\
849 \texttt{HANKEL\_BUILD} & Stream moments into a small Hankel matrix \\
850 \texttt{ROOT\_PHASE} & Recover physical roots from decimated channels \\
851 \texttt{BAYES\_FIT} & Fit one shape-class batch of conjugate regressions \\
852 \texttt{GRAPH\_REFINE} & Replace one parent task by a local child graph \\
853 \texttt{RESIDUAL} & Form and store a reconstruction residual \\
854 \texttt{COMMIT} & Mark a result valid after required certificates pass \\
855 \bottomrule
856 \end{longtable}
857 
858 \section{Completion record}
859 Every completed command produces a compact record containing the completion token, status, cycle count, bytes moved, exception code, residual summary, and certificate pointer. Downstream dependencies consume the token only after the commit state is reached.
860 
861 \section{Protection and replay}
862 Descriptor tables, command queues, and certificate records require ECC or parity protection. A command that encounters an uncorrectable descriptor error is aborted before execution. A certificate failure invalidates only the declared replay region unless the error is marked package-wide.
863 
864 \chapter{Compiler}
865 
866 \section{Routing policy}
867 The compiler first asks whether the structure changes the cost of the computation. A named packet decomposition is not sufficient. The route decision uses representation size, expected reuse, graph size, materialization requirements, and measured or modeled engine cost.
868 
869 \begin{figure}[H]
870 \centering
871 \includegraphics[width=0.88\linewidth]{25_workload_router.pdf}
872 \caption{Reference routing logic. The final compiler will use calibrated costs, but the reject path remains part of the specification.}
873 \end{figure}
874 
875 \section{Shared Packet IR}
876 The CUDA and PRISM backends consume the same typed graph. Packet IR records representation form, packet and atlas identity, output contract, precision, reuse, dependencies, and certificate requirements. Backend selection does not change the mathematical result.
877 
878 \begin{figure}[H]
879 \centering
880 \includegraphics[width=0.94\linewidth]{40_shared_packet_ir.pdf}
881 \caption{Shared Packet IR makes CUDA the software foundation and matched baseline for PRISM.}
882 \end{figure}
883 
884 \section{Compiler flow}
885 The compiler begins with a typed graph rather than an unstructured kernel list.
886 
887 \begin{figure}[H]
888 \centering
889 \includegraphics[width=0.98\linewidth]{12_compiler_pipeline.pdf}
890 \caption{The packet compiler preserves the output contract while changing representation, placement, precision, and schedule.}
891 \end{figure}
892 
893 \section{Legality pass}
894 Before optimization, the compiler checks packet completeness, shape compatibility, parent-child identities, analysis-synthesis pairing, output contracts, and certificate requirements.
895 
896 \section{Representation pass}
897 The operator is classified as explicit dense, block diagonal, block sparse, low rank, BDLR, Kronecker, sparse factor chain, transform generated, packet graph, small solver, or nonlinear packet interaction. A form is chosen only when it reduces the declared cost or is required by the output contract.
898 
899 \section{PMR--GEMM planning}
900 The representation pass invokes the Bellman planner on the candidate packet tree. The planner considers generic, block, low-rank, Kronecker, sparse-chain, transform, and split choices. The explicit array contract filters out plans that do not return every entry. Apply, factor, and transform contracts leave compressed plans available.
901 
902 \begin{figure}[H]
903 \centering
904 \includegraphics[width=0.95\linewidth]{39_pmr_gemm_planner.pdf}
905 \caption{The mixed-representation planner selects a certified plan under the requested output contract.}
906 \end{figure}
907 
908 \section{Placement and fusion}
909 The compiler keeps together parent and child packets, diagonal blocks with corresponding factor rows, transform stages sharing one coefficient stream, and small solver chains. Analysis, packet selection, feature reduction, and synthesis may be fused when the exact atlas contract is unchanged.
910 
911 \section{CUDA compatibility backend}
912 The CUDA backend maps Packet IR to grouped GEMM, cuBLAS and cuBLASLt, cuFFT, cuSPARSE, CUB reductions, asynchronous copies, stream-ordered allocation, and CUDA Graph replay. It remains the first implementation target and the reference for same-representation comparisons.
913 
914 \section{PRISM backend}
915 The PRISM backend replaces launch-heavy graph regions with resident packet warps, PSM scratchpads, representation routing, transform-to-solver handoff, local refinement, and certificate-gated commit. The backend does not change the representation chosen by the compiler unless the cost model requests a new plan.
916 
917 \section{Worked BDLR compilation}
918 A BDLR operator enters the compiler as the typed identity $A=D+UV^*$. No explicit matrix is constructed. The legality pass checks dimensions and the requested output form. The representation pass keeps the factors. Placement co-locates each diagonal block with the corresponding rows of $U$ and $V$. Precision is assigned per transfer contribution. The schedule computes $DX$, reduces $V^*X$, broadcasts the small contraction, and forms $U(V^*X)$ locally.
919 
920 \begin{figure}[H]
921 \centering
922 \includegraphics[width=0.96\linewidth]{36_compiler_trace.pdf}
923 \caption{One BDLR operator through the compiler. The dense matrix is never formed.}
924 \end{figure}
925 
926 \section{Certificate plan}
927 The compiler decides where direct residuals are affordable and where proven upper bounds are used. A graph may contain several certificate boundaries rather than one final check.
928 
929 \chapter{End-to-end execution traces}
930 
931 \section{Block diagonal plus low rank}
932 The host submits packet descriptors for the diagonal blocks and factor rows. The graph contains one block batch, one reduction for $V^*X$, one factor broadcast, one local update, and one certificate. The dense matrix is absent from the graph and from memory.
933 
934 The external contract is still ordinary matrix application. A direct residual may compare the structured output with a dense reference during bring-up. Production runs can use a proven bound or a spot-check policy when a full dense reference would defeat the representation saving.
935 
936 \section{Unknown-edge reconstruction}
937 The transform engine extracts the chosen Fourier packet. The projector DMA groups decimated phase channels. The solver cluster builds the Hankel matrix, estimates rank, finds the annihilator, recovers roots, resolves physical phases, and solves amplitudes. The recovered edge packet is synthesized directly. The smooth residual follows the spectral path. A final residual and branch-margin record are written before commit.
938 
939 \section{One PR-LASM step}
940 The exact archive remains in HBM. Macro, meso, and micro states remain in SRAM. Mechanism families reuse the same state matrices. The small solvers update their posterior records. The planner reads exact transition edges separately from probabilistic predictions. A large residual can request local packet refinement without invalidating the rest of the graph.
941 
942 \section{Why these traces matter}
943 The three examples use different engines but share one architectural pattern. The representation remains typed, local work is scheduled by dependency tokens, intermediate factors remain resident, and the result is not committed until the declared check passes.
944 
945 \chapter{Compositional correctness}
946 
947 \begin{theorem}[Hardware reconstruction theorem]
948 Let a finite calculus graph have exact packet analysis and synthesis, exact transfer kernels, and an acyclic dependency graph. Suppose every hardware command implements its declared local map and every packet sum uses the declared complete family. Then the committed hardware output equals the mathematical graph output.
949 \end{theorem}
950 
951 \begin{proof}
952 Order the graph topologically. Each source command loads the declared seed or packet. Assume every predecessor of a node has the correct value. The command implements the node's declared local map, so the node output is correct. Packet accumulation is exact because the declared child or source family is complete. Induction reaches every sink. The final synthesis therefore equals the mathematical graph output. The commit command changes status, not value.
953 \end{proof}
954 
955 \begin{theorem}[Certified commit]
956 Suppose a command result is provisional until a certificate $c(y)$ is evaluated. If the commit controller releases $y$ only when $c(y)$ satisfies the declared acceptance rule, then every visible result has passed that rule. A failed result cannot satisfy a downstream completion token.
957 \end{theorem}
958 
959 \begin{proof}
960 The provisional buffer is not addressable through the committed packet directory. Passing the rule changes the directory state and releases the completion token. Failure leaves the committed state unchanged and redirects the declared graph region to replay or abort. Downstream commands therefore cannot observe an unchecked value through the normal dependency path.
961 \end{proof}
962 
963 \begin{corollary}[Local refinement correctness]
964 If a parent packet is replaced by a child graph whose synthesis equals the parent interface, the refined hardware graph has the same external mathematical output.
965 \end{corollary}
966 
967 \begin{proof}
968 The topological-splice theorem gives a legal schedule. Exact child synthesis gives the same value at the parent interface. Every downstream command therefore receives the same input.
969 \end{proof}
970 
971 \chapter{Performance accounting}
972 
973 \section{Four different sources of gain}
974 A fair result must say what changed. The total route may improve because the mathematics removed work, because the same representation ran better on another device, because a kernel was fused or graph-replayed, or because one-time setup was amortized. These are different quantities:
975 \[
976 S_{\mathrm{total}}
977 =
978 S_{\mathrm{representation}}
979 S_{\mathrm{architecture}}
980 S_{\mathrm{kernel}}
981 S_{\mathrm{amortization}}.
982 \]
983 This is a bookkeeping identity only when every factor comes from matched rows with the same output contract and timing scope. Otherwise the factors are reported separately.
984 
985 \begin{figure}[H]
986 \centering
987 \includegraphics[width=0.92\linewidth]{41_gain_decomposition.pdf}
988 \caption{Representation, packet-CUDA, graph-replay, and output-contract gains answer different questions.}
989 \end{figure}
990 
991 \section{Measured CUDA foundation}
992 The prior packet-GPU study contains 154 matched CPU and GPU rows. The recorded GPU is an RTX 3070 Ti Laptop GPU. For $n=8192$, block width $64$, and 32 right-hand sides, the equal-block packet path took $0.046032$ ms and was $14.8919\times$ faster than the matched device-resident dense GPU row. For BDLR with rank eight, the standard packet path took $0.097280$ ms and CUDA Graph replay took $0.079872$ ms. The graph row was $10.9355\times$ faster than the matched dense GPU row. The graph improvement over the standard packet path was about $1.218\times$.
993 
994 A compressed BDLR product at $n=1024$ took $0.1582$ ms. Materializing the explicit output took $0.5073$ ms. Those rows have different output contracts. The comparison shows the cost of requesting every entry. It is not a claim that one result is a faster implementation of the other.
995 
996 \begin{figure}[H]
997 \centering
998 \includegraphics[width=0.91\linewidth]{43_cuda_measured_baselines.pdf}
999 \caption{Measured CUDA packet timings from the earlier structured-operator study.}
1000 \end{figure}
1001 
1002 \section{Representation reduction}
1003 For
1004 \[
1005 A=D+UV^*,
1006 \]
1007 with dimension $n$, block width $b$, rank $r$, and $q$ right-hand sides, a factor-first application uses
1008 \[
1009 2qn(b+2r)
1010 \]
1011 modeled operations and stores
1012 \[
1013 n(b+2r)
1014 \]
1015 scalars. The corresponding dense counts are $2qn^2$ and $n^2$. For
1016 \[
1017 n=8192,
1018 \qquad b=64,
1019 \qquad r=8,
1020 \qquad q=32,
1021 \]
1022 the arithmetic and storage reduction is
1023 \[
1024 \boxed{\frac{n}{b+2r}=102.4.}
1025 \]
1026 This reduction belongs to the representation. A CUDA backend and a PRISM backend can both use it.
1027 
1028 \section{PRISM architecture model}
1029 The architecture model uses
1030 \[
1031 T=
1032 \max\left(
1033 \frac{F}{\eta_cP},
1034 \frac{B}{\eta_bW}
1035 \right)
1036 +T_{\mathrm{graph}},
1037 \]
1038 where $F$ is arithmetic, $B$ is data movement, $P$ is peak arithmetic, $W$ is bandwidth, and $\eta_c$, $\eta_b$ are efficiency factors. The model is used to decide which hardware paths are worth building. It is not a silicon measurement.
1039 
1040 \begin{figure}[H]
1041 \centering
1042 \includegraphics[width=0.84\linewidth]{14_roofline.pdf}
1043 \caption{Reference PRISM roofline with representative packet workloads.}
1044 \end{figure}
1045 
1046 \section{Total route model and architecture-only models}
1047 The earlier dense-route comparison predicts $70.79$ microseconds for a dense application and $1.87$ microseconds for the PRISM BDLR route. The ratio is about $37.8$. This is a total route model. It includes representation reduction and therefore is not labeled PRISM-over-CUDA architecture gain.
1048 
1049 The more relevant architecture models begin with the same structured pipeline on both sides. They estimate:
1050 \begin{center}
1051 \begin{tabular}{lrr}
1052 \toprule
1053 Workload & Generic structured path & PRISM path \\
1054 \midrule
1055 Fused multi-atlas analysis & $14.73$ $\mu$s & $8.96$ $\mu$s \\
1056 Polyphase edge recovery & $4.00$ $\mu$s & $1.35$ $\mu$s \\
1057 Bayesian model portfolio & $427.93$ $\mu$s & $300.52$ $\mu$s \\
1058 \bottomrule
1059 \end{tabular}
1060 \end{center}
1061 The corresponding modeled gains are $1.64\times$, $2.96\times$, and $1.42\times$. These are the present estimates of what residency, fusion, local solvers, and packet scheduling may add after a structured representation is already in use.
1062 
1063 \section{Sensitivity and crossover}
1064 No single row should define the architecture. BDLR gains depend on block width and correction rank. Transform gains depend on size, reuse, and fusion. Sparse graphs depend on regularity. Small solvers depend on batch size and handoff cost.
1065 
1066 \begin{figure}[H]
1067 \centering
1068 \includegraphics[width=0.84\linewidth]{29_bdlr_speedup_sensitivity.pdf}
1069 \caption{Total route sensitivity across block width and correction rank.}
1070 \end{figure}
1071 
1072 \begin{figure}[H]
1073 \centering
1074 \includegraphics[width=0.84\linewidth]{30_bdlr_storage_sensitivity.pdf}
1075 \caption{Representation-storage reduction across block width and correction rank.}
1076 \end{figure}
1077 
1078 \section{Negative controls}
1079 The earlier CUDA study retained cases where structure lost. Recursive HODLR was slower than dense GPU execution in the tested case. A GPU Walsh-Hadamard transform lost to the CPU at the smaller tested length. A two-stream dense pipeline lost to the serial path. Iterative refinement lost to a direct FP64 solve. The PRISM compiler must preserve these negative controls and route similar work away from specialized paths.
1080 
1081 \begin{figure}[H]
1082 \centering
1083 \includegraphics[width=0.86\linewidth]{23_workload_fit.pdf}
1084 \caption{PRISM should accelerate strong reusable structure and reject weak or one-off structure.}
1085 \end{figure}
1086 
1087 \chapter{Power, area, and thermal design}
1088 
1089 \section{Power budget}
1090 The reference package targets a 500 W envelope. The model allocates power to execution groups, SRAM, the packet network, HBM PHYs, transform and solver blocks, control, and margin.
1091 
1092 \begin{figure}[H]
1093 \centering
1094 \includegraphics[width=0.72\linewidth]{17_power_budget.pdf}
1095 \caption{Reference power allocation.}
1096 \end{figure}
1097 
1098 \section{Area allocation}
1099 Distributed SRAM is the largest target area because the architecture depends on resident packets and factors. Matrix and vector lanes occupy the next largest share.
1100 
1101 \begin{figure}[H]
1102 \centering
1103 \includegraphics[width=0.72\linewidth]{18_area_allocation.pdf}
1104 \caption{Target compute-chiplet area allocation.}
1105 \end{figure}
1106 
1107 \section{Thermal behavior}
1108 The scheduler can spread long transform and matrix batches across chiplets. UCIe priority sideband and fast-throttle features are natural matches for package-wide thermal events. Local descriptor replay can be paused without discarding the packet graph.
1109 
1110 \chapter{Reliability, protection, and recovery}
1111 
1112 \section{Protected state}
1113 Packet descriptors, transfer descriptors, dependency tokens, and certificate records control meaning as well as data movement. They require stronger protection than ordinary cache metadata. The reference plan uses ECC for SRAM-resident tables, parity on command queues, sequence numbers on replay regions, and end-to-end tags on HBM packet records.
1114 
1115 \section{Failure containment}
1116 An execution-group or PSM error should not force a package-wide reset unless the packet directory or global scheduler has lost coherence. Local kernel faults invalidate the destination packet and its descendants. A link or memory fault invalidates every packet whose provenance crosses the failed resource. The compiler emits provenance information so the runtime can identify the affected region.
1117 
1118 \section{Determinism}
1119 Deterministic mode fixes the reduction tree, solver ordering, and replay schedule. It is slower than the highest-throughput mode. Its purpose is bring-up, regression testing, exact replay, and certificate comparison.
1120 
1121 \section{Security boundary}
1122 The architecture does not introduce a new trust model. Host isolation, command validation, memory protection, firmware signing, and secure update remain required. Packet descriptors make the dataflow easier to audit, but they do not replace platform security.
1123 
1124 \chapter{Programming model}
1125 
1126 \section{Four software layers}
1127 The software stack has four levels:
1128 \begin{enumerate}
1129 \item a high-level calculus graph
1130 \item shared Packet IR
1131 \item CUDA or PRISM backend lowering
1132 \item Packet Seed Commands, descriptor tables, and the runtime queue
1133 \end{enumerate}
1134 The release includes JSON examples for BDLR application, PMR--GEMM planning, self-calibrating edge recovery, and a PR-LASM step.
1135 
1136 \section{Host control}
1137 RISC-V management cores run the command runtime, graph loader, memory manager, telemetry, and error handling. The CUDA backend uses the same Packet IR before final lowering. Ordinary vector code handles control-side data preparation. The accelerator command queue is the stable interface to the packet engines.
1138 
1139 \section{Device libraries}
1140 A practical library should expose:
1141 \begin{itemize}
1142 \item packet and atlas construction
1143 \item transform analysis and synthesis
1144 \item transfer graph creation
1145 \item BDLR and block-sparse operators
1146 \item edge-recovery graphs
1147 \item Bayesian program batches
1148 \item certificate policies
1149 \item graph replay and local refinement
1150 \end{itemize}
1151 
1152 \chapter{Verification}
1153 
1154 \section{Verification ladder}
1155 The architecture is specified so each development stage has a clear target. Mathematical contracts come first. The behavioral model checks those contracts. Bit-accurate kernels then define rounding and exception behavior. RTL simulation and formal properties check control. An FPGA overlay measures real data movement before a chiplet is attempted.
1156 
1157 \begin{figure}[H]
1158 \centering
1159 \includegraphics[width=0.74\linewidth]{33_verification_pyramid.pdf}
1160 \caption{Verification ladder from mathematical contracts to measured silicon.}
1161 \end{figure}
1162 
1163 \section{Behavioral tests}
1164 The executable model currently verifies:
1165 \begin{itemize}
1166 \item complete residue-packet reconstruction
1167 \item exact polyphase round trip
1168 \item exact Haar round trip
1169 \item BDLR factor execution against dense materialization
1170 \item local DAG substitution
1171 \item derived package totals
1172 \item descriptor contracts
1173 \item precision-budget allocation
1174 \item certificate-gated commit
1175 \item local refinement descriptor bounds
1176 \item compiler routing decisions
1177 \item BDLR sensitivity tables
1178 \item package bandwidth hierarchy
1179 \item Packet Streaming Multiprocessor hierarchy
1180 \item PMR--GEMM Bellman planning
1181 \item output-contract legality without mandatory dense state
1182 \item measured CUDA baseline registry
1183 \item typed gain decomposition
1184 \end{itemize}
1185 
1186 \begin{certificate}[Current executable result]
1187 The behavioral and architecture model passes
1188 \[
1189 \boxed{18/18\text{ self-tests}}
1190 \]
1191 and the independent pytest suite passes
1192 \[
1193 \boxed{18/18\text{ tests}.}
1194 \]
1195 The largest semantic residual is the BDLR comparison residual
1196 \[
1197 1.42\times10^{-14},
1198 \]
1199 which is consistent with floating-point roundoff.
1200 \end{certificate}
1201 
1202 \section{RTL boundary}
1203 The release contains a SystemVerilog architecture skeleton for descriptors, command buffering, dependency tokens, the packet directory, representation routing, PSM scheduling, execution-group control, the residual path, certificate-gated commit, and the top-level queue interface. No HDL compiler or synthesis tool was available in the build environment. The RTL skeleton is therefore not described as verified or synthesizable silicon.
1204 
1205 \section{What must be verified before tapeout}
1206 A serious implementation requires:
1207 \begin{itemize}
1208 \item bit-accurate kernel models
1209 \item formal checks of command ordering and descriptor protection
1210 \item CDC and reset verification
1211 \item UCIe, HBM, PCIe, and optional CXL compliance IP integration
1212 \item SRAM and NoC timing closure
1213 \item thermal and power-integrity analysis
1214 \item fault injection for replay and certificate failure
1215 \item compiler and runtime conformance suites
1216 \end{itemize}
1217 
1218 \chapter{Implementation path}
1219 
1220 \begin{figure}[H]
1221 \centering
1222 \includegraphics[width=0.95\linewidth]{22_implementation_path.pdf}
1223 \caption{The software and CUDA stages precede FPGA and silicon work.}
1224 \end{figure}
1225 
1226 \section{Stage 1: software and CUDA foundation}
1227 The calculus already has CPU references, CUDA packet kernels, grouped block execution, compressed BDLR products, Woodbury solves, CUDA Graph replay, mixed-precision certificates, transform paths, and measured structured-operator baselines. This stage supplies the semantics, Packet IR, workload traces, and matched comparison.
1228 
1229 \section{Stage 2: trace-driven backend comparison}
1230 The next software stage lowers the same Packet IR to CUDA and to the PRISM simulator. It records representation, bytes, arithmetic, launch count, solver size, reuse, residual, and output contract. This stage identifies the graph regions that remain bottlenecked after CUDA has already used the better algorithms.
1231 
1232 \section{Stage 3: FPGA Packet Streaming Multiprocessor}
1233 The FPGA overlay should implement one Packet Streaming Multiprocessor, packet DMA, one transform path, one matrix and factor path, one small solver, the packet directory, dependency tokens, residual accumulation, and certificate-gated commit. The descriptor and Packet IR formats should match the later ASIC.
1234 
1235 \begin{figure}[H]
1236 \centering
1237 \includegraphics[width=0.95\linewidth]{34_fpga_overlay.pdf}
1238 \caption{Recommended FPGA overlay for measuring the architectural features that do not reduce to an ordinary CUDA kernel.}
1239 \end{figure}
1240 
1241 \section{Stage 4: one compute chiplet}
1242 A shuttle-scale device can use four to eight Packet Streaming Multiprocessors, one transform cluster, one small-solver cluster, external memory, and a simple host link. This stage should measure factor residency, scratchpad bandwidth, packet-warp occupancy, transform-to-solver handoff, and local refinement.
1243 
1244 \section{Stage 5: full package}
1245 The full package adds four compute chiplets, HBM4, UCIe, host I/O, and package-wide management. It is justified only after the CUDA and FPGA stages show a stable same-representation advantage on real workloads.
1246 
1247 \section{Development risks}
1248 The highest risks are package power, HBM integration, small-solver occupancy, network congestion, compiler misclassification, descriptor overhead, and false certificate acceptance. Early CUDA and FPGA measurement is the main mitigation.
1249 
1250 \begin{figure}[H]
1251 \centering
1252 \includegraphics[width=0.86\linewidth]{35_risk_matrix.pdf}
1253 \caption{Development risk map. Values are planning judgments rather than measured frequencies.}
1254 \end{figure}
1255 
1256 \section{Architecture freeze checklist}
1257 The following items should be frozen before production RTL begins.
1258 \begin{enumerate}
1259 \item Packet, transfer, atlas, representation, and certificate descriptor semantics
1260 \item Packet IR representation forms and output contracts
1261 \item Packet-warp and Packet Streaming Multiprocessor scheduling rules
1262 \item command and completion-record formats
1263 \item commit and replay rules
1264 \item supported numerical formats and rounding behavior
1265 \item minimum transform, factor, and solver operation set
1266 \item CUDA and PRISM backend conformance tests
1267 \item error and exception reporting
1268 \end{enumerate}
1269 SRAM bank count, issue width, NoC virtual channels, exact root-solver implementation, and final DVFS domains may remain implementation choices until synthesis and floorplanning begin.
1270 
1271 \chapter{What would count as success}
1272 
1273 The chip should be judged against claims that can be measured:
1274 \begin{enumerate}
1275 \item structured operations move fewer bytes than an explicit-array route
1276 \item BDLR, PMR--GEMM, and regular block-sparse graphs sustain useful Packet Streaming Multiprocessor occupancy
1277 \item transform analysis and synthesis remain exact within the declared numerical format
1278 \item mixed-precision results satisfy their packet bounds
1279 \item local refinement changes only the local descriptor region
1280 \item edge recovery keeps the small algebraic chain resident
1281 \item Bayesian portfolios reuse state matrices rather than reloading them per model
1282 \item negative controls are routed to CUDA, a general device, or a generic leaf when PRISM is not the better path
1283 \end{enumerate}
1284 
1285 A successful PRISM chip would not prove the calculus. The mathematics already supplies the contracts. The hardware question is whether keeping those contracts visible saves enough scheduling, movement, and handoff cost beyond the already optimized CUDA implementation to justify a dedicated machine.
1286 
1287 \chapter{Final architecture statement}
1288 The final design follows one principle:
1289 \[
1290 \boxed{
1291 \text{Do not materialize, move, or schedule structure that the calculus has already declared inactive.}
1292 }
1293 \]
1294 The machine executes
1295 \[
1296 \begin{aligned}
1297 \text{seed object}
1298 &\longrightarrow \text{Packet IR}\\
1299 &\longrightarrow \text{mixed-representation plan}\\
1300 &\longrightarrow \text{packet warps on CUDA or PRISM}\\
1301 &\longrightarrow \text{local refinement and synthesis}\\
1302 &\longrightarrow \text{certificate and commit}.
1303 \end{aligned}
1304 \]
1305 PRISM-1 is a CUDA-like packet-programmable processor, not a dense-matrix preservation machine. Its hardware state may be a factor graph, transform chain, packet tree, sparse operator, explicit array, or mixture of those forms. The requested output contract determines what must be returned.
1306 
1307 The CUDA backend proves that the calculus can run before silicon. The FPGA and ASIC question is narrower and testable: whether resident packet scheduling, factor reuse, transform-to-solver handoff, local refinement, and certificate-gated execution add enough value beyond the packet CUDA path.
1308 
1309 \appendix
1310 \chapter{Reference data sheet}
1311 \input{docs/datasheet_table.tex}
1312 
1313 \chapter{Operation-to-engine map}
1314 \begin{figure}[H]
1315 \centering
1316 \includegraphics[width=0.96\linewidth]{13_workload_engine_map.pdf}
1317 \caption{The main calculus operations and their primary hardware engines.}
1318 \end{figure}
1319 
1320 \chapter{Executable model and source layout}
1321 The source package contains the executable architecture model, independent tests, compiler examples, documentation, generated figures, machine-readable results, and an RTL module skeleton. Raw source listings are kept in the release rather than printed across the final paper.
1322 
1323 \begin{longtable}{L{0.32\linewidth}L{0.58\linewidth}}
1324 \toprule
1325 Path & Role \\
1326 \midrule
1327 \endfirsthead
1328 \toprule
1329 Path & Role \\
1330 \midrule
1331 \endhead
1332 \texttt{prism\_chip\_model.py} & Behavioral operations, roofline model, sensitivity sweeps, figures, and self-tests \\
1333 \texttt{tests/} & Independent contract tests \\
1334 \texttt{compiler\_ir/} & BDLR, PMR--GEMM, unknown-edge, and PR-LASM graph examples \\
1335 \texttt{rtl\_skeleton/} & Descriptor, queue, scoreboard, packet directory, representation router, PSM scheduler, execution group, residual, commit, and top-level module boundaries \\
1336 \texttt{docs/} & Data sheet, command specification, compiler notes, and microarchitecture notes \\
1337 \texttt{results/} & Machine-readable architecture results \\
1338 \bottomrule
1339 \end{longtable}
1340 
1341 \chapter{RTL module boundaries}
1342 \begin{longtable}{L{0.34\linewidth}L{0.56\linewidth}}
1343 \toprule
1344 Module & Responsibility \\
1345 \midrule
1346 \endfirsthead
1347 \toprule
1348 Module & Responsibility \\
1349 \midrule
1350 \endhead
1351 \texttt{prism\_descriptor\_pkg} & Command opcodes and packed descriptor types \\
1352 \texttt{prism\_command\_fifo} & Command-ring buffering and flow control \\
1353 \texttt{prism\_token\_scoreboard} & Dependency-token readiness and completion tracking \\
1354 \texttt{prism\_packet\_directory} & Packet validity, provisional state, commit state, and storage location \\
1355 \texttt{prism\_residual\_accumulator} & Wide residual accumulation \\
1356 \texttt{prism\_commit\_controller} & Certificate comparison, commit, replay, and abort decisions \\
1357 \texttt{prism\_representation\_router} & Dispatch among block, factor, transform, solver, packet-graph, and generic leaves \\
1358 \texttt{prism\_psm\_scheduler} & Packet-warp issue, dependency tracking, replay-region control, and execution-group assignment \\
1359 \texttt{prism\_execution\_group} & Matrix, vector, selector, reduction, and provisional-result boundary for one execution group \\
1360 \texttt{prism\_tile\_shell} & Compatibility shell for one execution group during staged RTL development \\
1361 \texttt{prism\_top} & Queue, scoreboard, packet directory, and completion interface shell \\
1362 \bottomrule
1363 \end{longtable}
1364 
1365 The module set remains a boundary specification rather than production RTL. A production implementation still requires bit-accurate datapaths, interface IP, reset and clock-domain design, verification properties, synthesis, timing closure, and physical design.
1366 
1367 \chapter{Implementation baseline}
1368 \section*{Internal algorithmic basis}
1369 The architecture integrates three existing project components.
1370 \begin{itemize}
1371 \item Dense Transfer Algebra supplies PMR--GEMM, compatible middle bases, Kronecker rules, sparse factor chains, and the generic fallback.
1372 \item Projector-Resolved Seed Calculus VIII supplies exact block, BDLR, compressed-product, Woodbury, packet-Krylov, mixed-precision, amortization, and CUDA Graph results.
1373 \item The CUDA backend supplies the working software route through grouped matrix kernels, FFT and sparse libraries, asynchronous transfers, graph replay, and packetwise certification.
1374 \end{itemize}
1375 These algorithms are architecture inputs. PRISM does not claim them as consequences of the chip.
1376 
1377 The package assumptions use current public baselines from the UCIe Consortium, PCI-SIG, Micron, and RISC-V International. The relevant values are the 48 and 64 GT/s classes in UCIe 3.0, the 128 GT/s PCIe 7.0 host-link class, Micron's 2048-bit HBM4 interface with bandwidth above 2.8 TB/s per stack, and the ratified RISC-V Vector 1.0 programming model. These sources establish a plausible interconnect, memory, and control baseline. They do not validate the PRISM microarchitecture.
1378 
1379 \end{document}

Back to source controls

Back to PRISM-1