DSP - BLOCK SLOPE STATS

Introduction link

The Block Slope Stats block chops the input stream into consecutive blocks of N samples, forms the first difference

$$ d_i = x_i - x_{i-1} $$

and, at the end of each block, publishes the mean and the standard deviation of those N differences:

$$ \mathrm{SLOPE_MEAN} = \frac{1}{N}\sum_{i=0}^{N-1} d_i , \qquad \mathrm{SLOPE_SIGMA} = \sqrt{\ \overline{d^2} - \bar{d}^{,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 anywhere in the block - which is also why the block size can be changed while the design is running, for free.

What each output is FOR link

The first difference is a one-tap high-pass filter: it deletes any constant offset and keeps only how fast the signal is moving. The two outputs then answer two different questions.

SLOPE_MEAN is the average RAMP RATE of the block, in input LSBs per sample. It measures drift: a leaking baseline, a charging coupling capacitor, a detector warming up, a slow control loop that has not settled. The sum of the differences telescopes, so

$$ \sum_{i=0}^{N-1} d_i = x_{N-1} - x_{-1} \quad\Longrightarrow\quad \mathrm{SLOPE_MEAN} = \frac{\text{net change across the block}}{N} $$

where $x_{-1}$ is the last accepted sample of the previous block. Two useful consequences: it is EXACTLY zero for any block that starts and ends at the same value, whatever the signal did in between; and it depends only on the two endpoints, so it is a drift meter, not a shape meter.

SLOPE_SIGMA is the sample-to-sample ROUGHNESS. Because the difference has already removed everything constant, and heavily attenuated everything slow, it does not see drift at all. That is exactly what makes it the better noise estimator on a signal that is moving: Block Std Dev on a drifting baseline reports the drift, not the noise, while this reports the noise. For white noise of standard deviation $s$ the differences are the difference of two independent samples, so

$$ \mathrm{SLOPE_SIGMA} \longrightarrow s\sqrt{2} \approx 1.414,s $$

To recover $s$, multiply by $1/\sqrt{2} \approx 0.7071$. On a signal whose noise is correlated sample to sample - anything that has been through a filter

• the factor is smaller than $\sqrt{2}$, so calibrate it once against a known source rather than assuming it.

Together they are a cheap signal quality monitor: SLOPE_MEAN says how fast the channel is walking away, SLOPE_SIGMA says how noisy it is, and they are independent of each other.

Cost link

SLOPE_MEAN alone is one subtractor, one accumulator, one barrel shifter and one requantiser - no multiplier, no divider and no serial arithmetic at all, so its result is out 2 clocks after the block’s last sample.

SLOPE_SIGMA adds a squarer during accumulation (the only multiplier in the block), a second accumulator, and a serial tail: one reused shift-add stage for $S_d \cdot S_d$ and one reused digit-recurrence square root stage. The cost is CLOCKS, not DSPs - there is no multiplier in the tail at all.

When to use this instead of Block Statistics link

The all-in-one Block Statistics block is not deprecated, but note first: it has no slope statistics. It computes the moments of the SAMPLES, not of their differences, so there is no output there that corresponds to either of these. The usual family rule therefore applies with one extra clause:

• you want several statistics of the SAME block - the mean and the RMS and the min/max 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, or its per-operator sibling. Then you synthesise only that number: the pin list, the logic and the tail are all that it needs, and nothing else reaches the synthesiser.
• you want these numbers - use this block, because there is nowhere else to get them. Pair it with a Block Statistics block on the same stream if you also want the moments of the samples themselves.

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 FIRST DIFFERENCE CROSSES THE BLOCK BOUNDARY link

$d_0$ of a block is $x_0$ minus the LAST ACCEPTED SAMPLE OF THE PREVIOUS BLOCK, not $x_1 - x_0$. This is deliberate, and there are two reasons - the first one is the important one:

1. It gives EXACTLY N differences per block, so “divide by N” stays a SHIFT. The N-1 differences that live strictly inside a block would need a real division by a non-power-of-two: a divider, a longer tail and a rounding error, for a definition that is no better.
2. The stream is continuous. The step between two consecutive samples is a real step whether or not a block boundary happens to sit between them.

This is the same reasoning that makes Block Zero Crossings carry its sign memory across blocks, and Block Peak Count its Schmitt state.

CONSEQUENCE: DISCARD THE FIRST BLOCK link

After RESET the held “previous sample” is 0. So the first difference of the first block is $x_0 - 0 = x_0$ itself - the whole sample, not a step - and both statistics of that block are contaminated by it. On a signal sitting at a baseline of 1000 LSB, the first block’s SLOPE_MEAN is high by $1000/N$ and its SLOPE_SIGMA is dominated by that one enormous “difference”.

Discard the first block after every reset, or arrange to reset while the input is at zero. OUT_DV counts the blocks for you; ignore the first pulse.

“Previous sample” means previous ACCEPTED sample link

Clocks with IN_DV low do not exist as far as this core is concerned. The held sample is updated only on accepted samples, so a gapped stream differences the samples it was actually given, not the gaps: if samples arrive at clocks 4, 9 and 11, the differences are $x_9 - x_4$ and $x_{11} - x_9$.

That is the right behaviour for a decimated or gated stream, but be aware of what it means physically: the difference is per SAMPLE, not per CLOCK. If your IN_DV gaps are irregular, SLOPE_MEAN is a rate per sample and not a rate per unit time.

Exactness link

Both statistics are built the way Block Mean and Block Std Dev build theirs, on the difference stream instead of the sample stream. With $S_d = \sum d_i$ and $S_{dd} = \sum d_i^2$:

$$ \mathrm{SLOPE_MEAN} = \frac{S_d}{N}, \qquad \mathrm{var}{\mathrm{num}} = N,S{dd} - S_d^2, \qquad \mathrm{SLOPE_SIGMA} = \frac{\sqrt{\mathrm{var}_{\mathrm{num}}}}{N} $$

$N S_{dd}$ is a shift and $S_d \cdot S_d$ is an exact serial shift-add product, so $\mathrm{var}_{\mathrm{num}}$ is an exact integer. Therefore:

• SLOPE_MEAN is BIT EXACT - the only error is the single final requantisation into the Q format you chose;
• SLOPE_SIGMA is within 1 LSB - the square root is the only approximation anywhere in the block, and it is computed with 4 guard bits below the output LSB so that the final rounding still has something to round.

The variance numerator is clamped non-negative before the root, so no configuration can present a radicand the root engine cannot take.

That is not an aspiration. The host regression (tb/block-ops/run_tb.ps1) demands tolerance ZERO on the mean against a Python golden (tb/block-ops/gen_golden.py) that evaluates the definitions above in exact rational arithmetic and shares no algorithm with the core.

Note also what the difference does to the dynamic range: one difference is one bit wider than a promoted sample (call it DW = IN_SW + 1), because the difference of two full-scale samples of opposite sign needs it. The two accumulators are sized from that, and nothing in the datapath can overflow.

Accumulation and IN_DV link

IN_DV is the only qualifier. It says “this clock carries a sample”: a difference is formed, 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 or move the held sample - 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. You can sweep EXP from a register interface while the stream runs and every result stays self-consistent.

Note that with SLOPE_SIGMA enabled the tail length depends on EXP - see below.

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 subtract, one square, two adds per sample - and the tail has all the time in the world:

• $S_d \cdot S_d$ is ONE reused shift-add stage stepped once per clock, consuming one bit of $|S_d|$ per clock, $\mathrm{DW} + \mathrm{EXP}$ steps;
• the square root is ONE reused compare-subtract stage stepped once per clock, producing one result bit per clock, $\mathrm{RTW}$ steps.

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. Both outputs are updated on that same clock and on no other.

With SLOPE_SIGMA OFF the state walk is IDLE -(go)-> FIN -> IDLE and

$$ L = 2 $$

a constant, exactly like Block Mean.

With SLOPE_SIGMA ON the walk is IDLE -(go)-> MUL x (DW + EXP) -> VAR -> LD -> SQRT x RTW -> FIN -> IDLE, and with OUT_DV registered

$$ \mathrm{DW} = \mathrm{IN_SW} + 1, \qquad \mathrm{RTW} = \mathrm{SLOPE_SIGMA\ width} + \mathrm{SQG} + 1 = \mathrm{SLOPE_SIGMA\ width} + 5 $$

$$ L = 2 + (\mathrm{DW} + \mathrm{EXP} + 1) + (\mathrm{RTW} + 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 differenced). Both terms are user visible: a WIDE SLOPE_SIGMA format costs root steps and a LONG BLOCK costs multiply steps.

Like Block Std Dev and Block Variance, this block’s latency depends on the runtime exponent. A longer block makes $|S_d|$ 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 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 overrun 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, and tells you the tail length and the minimum;
• 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 fourth row - the default configuration - in full. A 16 bit signed input gives $\mathrm{IN_SW} = 16$ and $\mathrm{DW} = 17$; the default SLOPE_SIGMA format (16 integer bits, 0 fractional bits, unsigned) gives $\mathrm{RTW} = 16 + 5 = 21$. So

$$ L = 2 + (17 + \mathrm{EXP} + 1) + (21 + 1) = 42 + \mathrm{EXP} $$

At $\mathrm{EXP} = 5$ that is $L = 47$ and $2^5 = 32 < 47$, so it does not fit; at $\mathrm{EXP} = 6$ it is $L = 48$ and $2^6 = 64 \ge 48$, so it does. The minimum usable EXP is 6, a block of 64 samples - and every larger exponent fits too. With the default $\mathrm{EXP} = 10$ the tail is 52 clocks inside a 1024-sample block: still over 94% idle.

Turning SLOPE_SIGMA off collapses all of this: L drops to a constant 2 and the minimum usable exponent to 1. If all you want is the drift, that is a much cheaper block.

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. So BUSY high with INTEGRATING low means “the samples are all in, I am computing” - which on this block is a visible state, tens of clocks long.
• 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 whole tail and past OUT_DV, until the first sample of the next block takes it back to 1. so it reads N at OUT_DV only when the input STOPS for the whole tail; on a CONTINUOUS stream the next block has already started and OUT_DV shows how far into it you are. The clock that always reads N is the one INTEGRATING falls on - which is the useful thing to latch alongside the results. Only RESET clears it to 0.

Q formats link

All three data ports carry their own fixed point format (integer bits, fractional bits, sign), the same convention as the Fixed P. family. Each result is requantised into its own 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 rules:

• SLOPE_MEAN must be SIGNED for any signal that can fall as well as rise - a falling ramp has a negative slope. That is the default. Its magnitude can never exceed one sample’s worth of range (it is a net change divided by N), so the input’s integer bits are always enough; the fractional bits are where the value actually lives. A drift of 1 LSB over a 1024-sample block is a slope of $2^{-10}$, which reads as 0 in the default Q16.0 format. Give SLOPE_MEAN at least as many fractional bits as the largest EXP you drive, or slow drift is invisible.
• SLOPE_SIGMA is UNSIGNED by default - a standard deviation is never negative, and UNSIGNED buys one bit. It is at most the full difference range, so DW bits of integer always fit. Remember that every extra bit of SLOPE_SIGMA width costs one clock of tail.

Enabling and disabling outputs link

Each of the two data outputs has its own enable, both defaulting to YES. Turning one off removes the pin and all of its logic before synthesis (the enables are preprocessor switches on the HLS core, so nothing reaches the synthesiser at all). Disabling SLOPE_SIGMA removes the squarer, the second accumulator, the serial multiplier and the whole square root engine, and shortens L to 2. At least one output must be enabled - the property page refuses a configuration with both off, because the block would have nothing to say.

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 the definitions above in exact rational arithmetic and shares no algorithm with the core. Slope coverage includes pseudo-random input (SL_RAND_E6), a pure ramp whose slope mean is a known constant and whose slope sigma is zero (SL_RAMP_E6), a constant signal where both are zero (SL_CONST_E6), a sine with fractional output formats (SL_SINE_E7_Q), mean-only and sigma-only configurations (SL_ONLY_MEAN, SL_ONLY_SIG, which also exercise the two different tail lengths), IN_DV gaps inside the accumulation to pin the “previous ACCEPTED sample” rule (SL_DVGAP_E6), and an EXP that changes half way through a block (SL_EXPCHG). The status outputs are checked clock by clock against the contract above, and the tail length is cross-checked at compile time between the C macro, the VB TailClocks function and the golden generator - the testbench refuses to build if the three disagree.