DSP - BLOCK VARIANCE

Introduction link

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

$$ S_1 = \sum_{i=0}^{N-1} x_i , \qquad S_2 = \sum_{i=0}^{N-1} x_i^2 $$

$$ \mathrm{var} = \overline{x^2} - \mathrm{mean}^2 = \frac{S_2}{N} - \left(\frac{S_1}{N}\right)^{!2} $$

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}}$:

Because N is a power of two, every division by N is an exact arithmetic shift. There is no divider and no reciprocal ROM, which is also why the block size can be changed while the design is running, for free.

What it is FOR link

The variance is the spread of the block about its own mean, with the DC level removed - the standard stability, noise and pile-up indicator. A baseline that is quiet has a small variance; one sitting on a pulse, a glitch or an oscillation does not, however clean its mean looks.

It is also the cheapest of the three spread measures in this family, and the only exact one:

• Block Variance (this block) - no square root, bit exact, one serial multiply in the tail.
• Block Std Dev - this block plus a serial square root: same value in input units, one more serial engine, up to 1 LSB of error.
• Block RMS - includes the DC level, so it is a different quantity, not a cheaper standard deviation.

If you only need to COMPARE or THRESHOLD spreads, stop here. The square root is monotone, so thresholding the variance against the SQUARE of your threshold gives exactly the same decisions as thresholding the standard deviation - with no root, no root guard bits and a much shorter tail.

When to use this instead of Block Statistics link

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

• you want several statistics of the SAME block - variance and mean and min/max of the same N samples - use Block Statistics. They share one accumulator pair and one serial tail, so the second and third statistic are nearly free: the shift-add squarer this block runs alone is the same one the all-in-one block reuses for the standard deviation.
• you want exactly one number - use this block. Then you synthesise only that number: the pin list, the two accumulators, the serial squarer and the tail are all that the variance needs, and nothing else reaches the synthesiser.

Two Block Statistics blocks side by side would duplicate the accumulators; two per-operator blocks side by side duplicate them too. One Block Statistics block never does.

Pin Description link

Properties link

The design decision that makes it exact link

The variance is not computed as $(S_2/N) - (S_1/N)^2$ from two truncated quotients. It is computed from the exact integer numerator:

$$ \mathrm{var_num} = N,S_2 - S_1^2 , \qquad \mathrm{variance} = \frac{\mathrm{var_num}}{N^2} $$

Both $S_1$ and $S_2$ are exact integer accumulators; $N S_2$ is a shift (N is a power of two); $S_1 \cdot S_1$ is an exact integer square computed serially; and the division by $N^2$ is a shift again. Two consequences follow, and they are the whole reason the block is built this way:

1. The result is BIT EXACT. The only rounding anywhere is the single final requantisation into the Q format you chose for the VARIANCE pin. That is not an aspiration: the host regression (tb/block-ops/run_tb.ps1) demands tolerance ZERO against a Python golden that evaluates the definition in exact rational arithmetic - not “within 1 LSB”, not “within a few counts”. Any deviation at all fails the build.

2. The variance can never come out negative. By Cauchy-Schwarz,

$$ N,S_2 - S_1^2 = \sum_{i<j} (x_i - x_j)^2 \ \ge\ 0 $$

always, so the classic “variance went slightly negative because two quotients were rounded independently” failure cannot happen here. That is what makes an UNSIGNED VARIANCE output format safe - which is the default - and what keeps a negative radicand out of Block Std Dev’s square root. The non-negative clamp is still present in the shared core and still load bearing, but no stimulus through the ports can reach it; it is unit tested directly with negative inputs instead.

If you ever see VARIANCE = 0 on a signal that is not constant, the value was simply smaller than one LSB of the format you chose.

Accumulation and IN_DV link

IN_DV is the only qualifier. It says “this clock carries a sample”: a sample is added to $S_1$, squared into $S_2$, 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 serial 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, and there is no reason to stall the tail.

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. Both the $N S_2$ shift and the final $N^2$ shift use that latched exponent, so the arithmetic of a block is always self-consistent.

Timing: the serial tail link

Why it is serial link

A block has a whole block period of slack after its N-th sample: the next result is not due for another $2^{\mathrm{EXP}}$ clocks. So there is no reason to build a parallel datapath for the post-accumulation arithmetic. II=1 is only needed while ACCUMULATING - one sample per clock, one multiply, two adds - and the tail has all the time in the world.

$S_1 \cdot S_1$ is therefore ONE reused shift-add stage stepped once per clock, consuming one bit of $|S_1|$ per clock. The cost is CLOCKS, not multipliers: the only multiplier in the whole block is the $x \cdot x$ during accumulation, and there is no DSP in the tail.

The latency contract link

OUT_DV pulses for one clock when the tail COMPLETES, L clocks after the clock on which the N-th sample of the block was accepted - not when that sample arrives. VARIANCE is updated on that same clock and on no other. The state walk is IDLE -(go)-> MUL x (IN_SW + EXP) -> VAR -> FIN -> IDLE with OUT_DV registered, so

$$ L = 2 + (\mathrm{IN_SW} + \mathrm{EXP} + 1) $$

where $\mathrm{IN_SW}$ is the signed working width of a sample: the input width, +1 if the input is UNSIGNED (a sample has to be promoted to signed before it can be accumulated). $|S_1|$ is at most $\mathrm{IN_SW} - 1 + \mathrm{EXP}$ bits wide for a block of $2^{\mathrm{EXP}}$ samples, so $\mathrm{IN_SW} + \mathrm{EXP}$ shift-add steps always clear it.

Block Variance and Block Std Dev are the only blocks in the family whose latency depends on the RUNTIME exponent. A longer block makes $|S_1|$ wider and therefore costs more multiply steps. But a longer block also gives more slack: the block grows exponentially in EXP and the tail only linearly, so the $2^{\mathrm{EXP}} \ge L$ constraint gets easier as EXP grows, not harder. The output format does not enter the formula at all - widening VARIANCE costs nothing in clocks, because there is no square root here.

The 2^EXP >= L rule link

The tail of one block must finish before the next block completes:

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

If a block completes while the previous tail is still running, that block’s result is DROPPED. A completed block is only handed to the tail when the tail is IDLE, so: no OUT_DV for it, the accumulators are unaffected, later blocks come out correctly - and there is no error pin. A result is simply skipped.

Three things guard against it, and one hole remains:

• the property validator refuses a configuration whose minimum exponent exceeds Max Block Exponent - here that is driven by the INPUT width, since $\mathrm{IN_SW} + \mathrm{EXP} + 3$ clocks have to hide inside $2^{\mathrm{EXP}}$ samples;
• CompileHDL prints the tail length and the minimum usable EXP into the compilation log for every placement;
• but EXP is a PIN. Nothing can stop a user driving it below the minimum at RUN TIME. If you make EXP runtime programmable from a register interface, clamp it in your own logic - the block will not complain, it will just stop emitting some results.

Worked numbers link

Take the first row in full. An 8 bit signed input gives $\mathrm{IN_SW} = 8$ and $L = 2 + 8 + \mathrm{EXP} + 1 = 11 + \mathrm{EXP}$ clocks. At $\mathrm{EXP} = 3$ that is $L = 14$ and $2^3 = 8 < 14$, so it does not fit; at $\mathrm{EXP} = 4$ it is $L = 15$ and $2^4 = 16 \ge 15$, so it does. The minimum usable EXP is 4, a block of 16 samples - and every larger exponent fits too, because $2^{\mathrm{EXP}}$ outruns $11 + \mathrm{EXP}$ from there on. With the default $\mathrm{EXP} = 10$ the tail is 21 clocks inside a 1024-sample block: over 98% idle.

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, and never during the tail.
• BUSY covers the accumulation and the serial 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. BUSY high with INTEGRATING low therefore means “the samples are all in, I am computing”.
• 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. The two separate visibly only when the input pauses for longer than the tail.
• 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 the final count N through the whole 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 the useful thing to latch alongside the result. Only RESET clears it to 0.

Q formats link

Both data 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 VARIANCE format with the selected rounding (nearest / truncate) and overflow policy (saturate / wrap); saturation is symmetric for signed formats, as everywhere else in the toolchain.

Sizing: the variance is a SQUARE, so it needs about twice the integer bits of the input if you do not want it to saturate - which is why the default is 32 bits for a 16 bit input. It is never negative, so UNSIGNED is safe and buys one bit; that is the default too. Unlike Block RMS and Block Std Dev, the output width here costs nothing in clocks: there is no square root, so a wide VARIANCE format is paid for in registers only.

Cost link

One multiplier for $x^2$ (unavoidable at one sample per clock), two accumulators ($S_1$ at $\mathrm{IN_SW} + $ Max Block Exponent bits, $S_2$ at $2,\mathrm{IN_SW} - 1 + $ Max Block Exponent), one shift-add stage with a product, an addend and a multiplier register, a barrel shifter for the two power-of-two shifts, and one requantiser. No divider, no second multiplier and no DSP in the tail.

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 $\overline{x^2} - \mathrm{mean}^2$ in exact rational arithmetic and shares no algorithm with the core; the tolerance is 0. Variance coverage includes pseudo-random input, a constant block (variance exactly zero), an extremes pattern alternating maximum positive and maximum negative samples, a fractional output format, an EXP that alternates between blocks, and an unsigned input (which is the case that costs the extra IN_SW bit and therefore an extra tail clock). 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; tb/block-ops/port_check.py preprocesses the real core to prove the symbol’s pin list matches the entity’s port list for every enable combination, and the harness #errors at COMPILE TIME if the tail formula in the .cpp, in the plugin and in the generator ever disagree.