3.3 Parameters and configuration¶

PRISM separates three kinds of values: wire constants fixed by the protocol, parameters chosen when the RTL is elaborated, and operation state that CONTROL installs at run time.

Protocol constants¶

These constants define the wire ABI, so they are protocol semantics, not free deployment knobs.

// repo/prism-hdl/src/prism_pkg.sv (conceptual view)
localparam int unsigned PRISM_VERSION_MAJOR          = 2;      // Protocol major version
localparam int unsigned PRISM_VERSION_MINOR          = 0;      // Protocol minor version
localparam logic [15:0] PRISM_ETHERTYPE            = 16'h88B5; // L2 frame discriminator
localparam int unsigned PRISM_ETH_MTU_BYTES         = 1500;     // Ethernet payload bytes

localparam int unsigned PRISM_CONTROL_WORD_BYTES   = 2;        // CONTROL command word length
localparam int unsigned PRISM_CONTROL_HEADER_BYTES  = 32;       // CONTROL header bytes
localparam int unsigned PRISM_DATA_HEADER_BYTES     = 40;       // DATA/RESULT header bytes
localparam int unsigned PRISM_PROGRESS_HEADER_BYTES = 44;       // PROGRESS header bytes
localparam int unsigned PRISM_NUMBERGROUP_DESCRIPTOR_BYTES = 4; // Per-group descriptor bytes

The body of a DATA or RESULT packet contains one or more NumberGroups; its maximum value bytes depend on group descriptors and padding. Changing a wire constant requires matching updates to the CCL, RTL, tests, PCAP parser, and Wireshark dissector.

Build parameters¶

prism_collective_core is elaborated with the following parameters. They are not negotiated by CONTROL; changing one produces a different bitstream.

Parameter	Default	U280 build	Meaning
`NUM_PORTS`	2	1	full-duplex 512-bit AXI4-Stream ports
`LINK_MTU`	1500	1500	largest frame payload the node sends
`KULISCH_W`	320	280	width of the exact accumulator state
`MAX_KULISCH_BITS`	4096	280	largest Kulisch width an operation may request
`MAX_ORIGINAL_TERMS`	16	2	rank terms one exact element may sum
`MAX_CHILDREN`	8	2	children of the node in the collective tree
`EXACT_BANKS`	8	4	exact accumulator banks
`ENABLE_FP32_ACCUMULATION`	1	0	include the `FP32_ARRIVAL` policy

The U280 values cover a reduction of two ranks and are the configuration that meets timing at 250 MHz on that device.

Compiled protocol and arithmetic support¶

The RTL does not answer in-band capability queries; the local capability catalog lists the implemented SINGLE tuples. KULISCH_FIXED supports the native RESULT formats (INT8, FP16, BF16 and FP32), exact Kulisch RESULT of KULISCH_W bits, and AUTO, each up to 4096 elements. FP32_ARRIVAL produces FP32 RESULT. Supported MTUs are 576 and 1500 bytes. INT8, FP16, BF16 and FP32 are the rank formats. A registry value does not imply that every bitstream implements it.

Each arithmetic slice has sixteen lanes, so sixteen FP32 elements fill one 512-bit beat; narrower formats use parallel slices. The DATA reader issues up to four slices from one INT8 beat, two from FP16 or BF16 and one from FP32.

Concurrent operations and storage resources¶

The current SINGLE integration admits one operation at a time. Its in-band record bounds children and endpoints to eight each, receive intervals to 16, and receive credit to 65536 bytes. Release returns the context and result ownership.

These bounds are independent: increasing an endpoint limit does not enlarge arithmetic state, result retention, or receive credits.

Throughput sizing¶

For datatype $d$, let $b_d$ be its wire bits per element, $A_d$ the elements accepted per cycle, $D$ the AXI width, $f$ the clock and $II$ the initiation interval:

\[ A_d \le \frac{D}{b_d}, \qquad T_{port,d}=\frac{A_db_df}{II}, \qquad A_{min}(d)=\left\lceil\frac{T_{goal}II}{b_df}\right\rceil. \]

For $D=512$, $f=250\,\mathrm{MHz}$ and $II=1$ a full beat carries 128 Gbit/s of payload, above the 100 Gbit/s of the link.

For $C$ simultaneous contributors, an aligned binary reduction requires:

\[ E_{input}=CL_d, \qquad A_{binary}=(C-1)L_d. \]

Kulisch instead accepts $CL_d$ deposits. Both paths output $L_d$ reduced elements. A wider output type can then become the bottleneck:

\[ P_{e2e} \le \min\left(P_{in},\left\lfloor\frac{D}{b_o}\right\rfloor\right). \]

For example, 64 INT8 inputs converted to FP32 need 2048 output bits per cycle. One 512-bit egress must serialize or backpressure them. The rates above describe numeric payload, not Ethernet overhead or timing closure.

Logical tiles and physical issue width¶

The RTL separates a variable-length NumberGroup from a 512-bit native issue group and sixteen-lane arithmetic slices. The reader retains global positions while forming issue groups. Each physical port feeds port-local exact slices or banked online FP32 state; neither port nor group boundary changes an element's arithmetic owner.

Kulisch width and cost¶

The protocol permits a configured Kulisch width from 8 to 4096 bits; a build implements up to MAX_KULISCH_BITS. The required width is

\[ W=E_{max}-E_{min}+p+1+\lceil\log_2(\text{maximum terms})\rceil. \]

For FP32 the base width is 278 bits, so the U280 build (two terms) needs 279 of its 280 bits and the default build (16 terms) 282 of its 320. The bound counts original rank terms, not local children. An exact operation whose configured width cannot represent its original-term bound is rejected during setup rather than reported as an exact result.

The state grows as

\[ S_{Kulisch} \approx B R_b L_K W_K, \]

with $B$ independent arithmetic banks, $R_b$ their range contexts, $L_K$ their stored lanes and $W_K$ the wide-state width. This estimates storage, not measured utilization.

Runtime configuration¶

CONTROL commands install or select operation state within compiled limits.

// Runtime-programmed (CONTROL) state, not elaboration-time parameters:
// - trusted AM binding and operation generation
// - node role, parent/child endpoints and physical peer bindings
// - result destinations
// - collective semantic (REDUCE/ALLREDUCE) and operator (SUM in current RTL)
// - input/accumulator/partial/output format tuple
// - element count, maximum original terms, MTU and receive credits
// - staged/active/complete lifecycle

The RTL integration uses one SINGLE node. DATA has bounded duplicate recognition and RESULT has retained finite retry; neither establishes a general multi-switch datapath.

Elaboration checks and verification¶

Modules use $fatal guards for illegal capacities, parser widths, port indices, and accumulator widths. Every configuration in the parameter matrix elaborates with Verilator, and the default and U280 configurations run cycle-accurate SINGLE tests.