DSP - BLOCK SUM

Introduction link

The Block Sum block chops the input stream into consecutive blocks of N samples and, at the end of each block, publishes the sum of that block:

$$ S_1 = \sum_{i=0}^{N-1} x_i $$

That is the raw first accumulator, presented as it stands. It is Block Mean without the final shift, and therefore the cheapest block of the whole family: one adder and one requantiser, no multiplier, no divider and no serial arithmetic.

N is a runtime input, not a property. You drive the exponent on the EXP pin and the block size is $N = 2^{\mathrm{EXP}}$:

The sum itself never divides by N - but N is what decides where a block ends, so it is still a runtime input, and changing the block length while the design is running costs nothing. In the rest of the family the same property has a second consequence: because N is a power of two every division by N is an exact arithmetic shift, which is why none of these blocks contains a divider.

What it is FOR link

The sum is the integral of the block. In pulse processing, the sum of the samples over a gate IS the integrated charge; in a slow control loop it is the quantity you accumulate and let the CPU scale itself; in a measurement chain it is the numerator you want when the denominator is going to be something other than N (a live-time, a number of triggers, a second block’s sum).

Take it, rather than the mean, when:

• you want the raw accumulator and intend to do your own arithmetic downstream - combining several blocks, normalising by something other than N, or accumulating further;
• you want the full precision of the accumulation with no shift at all;
• you want the absolute cheapest block-rate measurement there is.

Take Block Mean instead when the number you actually want is a baseline or a level: it is this block plus one barrel shifter, and its output stays in the range of a sample, which makes it far easier to size.

Cost link

One accumulator (input working width + Max Block Exponent bits) and one requantiser. No multiplier, no divider, not even a shifter in the datapath. Nothing in this family is cheaper.

When to use this instead of Block Statistics link

The all-in-one Block Statistics block is not deprecated and can emit this same SUM among twenty other statistics. The rule is simple:

• you want several statistics of the SAME block - the sum and the mean and the RMS of the same N samples - use Block Statistics. They share one accumulator and one serial tail, so the second and third statistic are nearly free.
• you want exactly one number - use this block. Then you synthesise only that number: the pin list, the logic and the tail are all that the sum needs, and nothing else reaches the synthesiser.

Pin Description link

Properties link

Accuracy link

The accumulator $S_1$ is an exact integer, so the only error in this block is the single final requantisation into the Q format you chose for the SUM pin. There is no accumulated rounding and no approximation anywhere in the datapath.

That is not an aspiration. The host regression (tb/block-ops/run_tb.ps1) demands tolerance ZERO against a Python golden (tb/block-ops/ gen_golden.py) that evaluates the definition above in exact rational arithmetic - not “within 1 LSB”, not “within a few counts”. Any deviation at all fails the build.

Sizing the SUM output: saturation matters here link

This is the one block of the family where the output format needs real thought. The internal accumulator is sized for the worst case - the input working width plus Max Block Exponent bits, so it cannot overflow no matter what you feed it. But the SUM pin carries the Q format you choose, and the requantisation into it is the last step. A long block of same-signed samples reaches numbers that a narrow format simply cannot hold:

• a 16 bit signed input summed over a $2^{10}$ block reaches $\pm 2^{15}\cdot 2^{10} = \pm 2^{25}$ - a 26 bit signed quantity;
• the same input over a $2^{20}$ block reaches $\pm 2^{35}$.

Size SUM as (input width + block exponent) bits if you want it never to clip. If you know your signal never sits at full scale for a whole block you can be tighter, but there is no cheap safety net: with Saturation = YES the pin clamps to the format maximum (symmetric bounds for a signed format) and with NO it wraps, and neither raises a flag. Note that the exponent in that rule is the exponent you actually run at, not Max Block Exponent - but EXP is a runtime input, so if you intend to sweep it, size for the largest value you will drive.

The default is 24 bits signed, which is exactly enough for a 16 bit signed input over blocks up to $2^{8}$.

Accumulation and IN_DV link

IN_DV is the only qualifier. It says “this clock carries a sample”: a sample is accumulated, and counts towards N, exactly on the clocks where IN_DV is high. Clocks with IN_DV low are ignored completely - whatever sits on IN during them cannot corrupt the block - while the tail keeps running, which is what you want: the tail has nothing to do with the input stream.

Unconnected, IN_DV ties to '1' and EXP ties to 10 (N = 1024), so the block free-runs with nothing wired except IN.

There is deliberately no CE pin. On the all-in-one Block Statistics block an earlier revision had one, and it did not survive synthesis: with nothing but internal state gated by it, Vitis could reason the frozen path away and delete the port from the generated entity while SciCompiler’s wrapper still wired it, which failed a real Vivado build with [VRFC 10-718] formal port <ce> does not exist in entity. The whole per-operator family was built without one. To stall this block, gate its IN_DV - a block that only accumulates on IN_DV has no need to be frozen.

When EXP changes link

EXP is clamped to Max Block Exponent and then latched on the first accepted sample of a block, and held for that whole block. A change therefore takes effect on the NEXT block: a block in progress always finishes against the N it was started with, and a block is never emitted against a different N than the one it was accumulated with. For a sum that is the difference between a meaningful number and a partial one, so it is worth stating plainly: no result you ever see is the sum of a number of samples other than the N its SAMPLE_COUNT reports.

Timing: the latency contract link

OUT_DV pulses for one clock, L clocks after the clock on which the N-th sample of the block was accepted - not when that sample arrives. SUM is updated on that same clock and on no other. For this block

$$ L = 2 $$

and it is a constant: there is no serial arithmetic here at all, so L does not depend on the input width, on the output width or on EXP. The two clocks are one to enter the final state and one to present the registered result.

The rule that governs the whole family is that the tail of one block must finish before the next block completes, i.e.

$$ 2^{\mathrm{EXP}} \ge L $$

If a block completes while the previous tail is still running, that block’s result is DROPPED: no OUT_DV for it, the accumulator is unaffected and later blocks come out correctly, but a result is silently skipped. There is no error pin for it.

With $L = 2$ that condition is $2^{\mathrm{EXP}} \ge 2$, i.e. EXP $\ge$ 1, so it cannot bite here: the only value that violates it is EXP = 0, a block of a single sample. The blocks where this rule really matters are the ones with a serial tail - Block RMS, Block Variance, Block Std Dev and Block Crest Factor, whose L runs to tens of clocks and whose minimum usable exponent the compiler prints in the compilation log.

Knowing where the block is: BUSY, INTEGRATING and SAMPLE_COUNT link

Three optional status outputs, all defaulting to NO. They answer different questions:

Every output of this block is a register, so each status bit is observed on the clock after the event that sets it:

• INTEGRATING rises on the clock after the FIRST sample of a block is accepted and falls on the clock after the N-th - it is high exactly while the block is ACCUMULATING.
• BUSY covers the accumulation and the tail. It rises with INTEGRATING, stays high across the tail, and its LAST HIGH CLOCK IS THE OUT_DV PULSE; it falls on the clock after.
• On a continuous stream the next block starts before the previous tail ends, so BUSY never drops and INTEGRATING dips for exactly one clock per block boundary - which makes it a free block marker.
• SAMPLE_COUNT is a fixed 32 bits and reads 1 after the first accepted sample, N after the N-th. It is NOT cleared at the block end: it HOLDS N through the tail and past OUT_DV, until the first sample of the next block takes it back to 1. So on the OUT_DV clock it reads the length of the block being presented - which is exactly the divisor a consumer needs if it wants to turn this sum back into a mean. Only RESET clears it to 0.

Q formats link

Both ports carry their own fixed point format (integer bits, fractional bits, sign), the same convention as the Fixed P. family. The result is requantised into the SUM format with the selected rounding (nearest / truncate) and overflow policy (saturate / wrap); saturation is symmetric for signed formats, as everywhere else in the toolchain.

A sum of signed samples is signed, and it reaches N times the amplitude of a sample - see “Sizing the SUM output” above, which is the part of this guide worth re-reading before you place the block.

Verification link

The core is regression tested by a host-side csim harness (tb/block-ops/run_tb.ps1) that runs one simulated clock at a time and follows OUT_DV. The expected values come from tb/block-ops/gen_golden.py, which evaluates $\sum x$ in exact rational arithmetic and shares no algorithm with the core; the tolerance is 0. Sum coverage includes pseudo-random and ramp inputs, a deliberately narrow saturating output format, the same configuration with saturation off so it wraps, and an EXP that changes half way through a block. The status outputs are checked clock by clock against the contract above. A cross-check compiles this core and the all-in-one block_stats.cpp into the same binary, drives them with identical stimulus, and compares the two clock by clock.