MCA

Introduction link

Principle of Operation link

The MCA block is the classic Sci-Compiler pulse-height analysis chain. A single 16-bit ADC stream goes in, an energy word plus a data-valid strobe come out. Internally it is four stages on one clock, one sample per clock:

1. Fast trapezoidal trigger — a short trapezoid (TRIG_K, TRIG_M) whose derivative is compared against THRS; the peak of that derivative fires TRIGGER_OUT.
2. Slow trapezoidal shaper — a long trapezoid (TRAP_K, TRAP_M) with integrated pole-zero deconvolution (DECONV_M) and an output gain (TRAP_GAIN).
3. Baseline restorer — a moving average of the shaper output over $2^{\mathrm{BL_LEN}}$ samples, frozen for BL_INIB samples after every trigger.
4. Energy sampler — samples (shaper − baseline) SAMPLE_POS samples after the trigger and raises ENERGY_DV.

What makes this block different from its two siblings link

The MCA family in this plugin has three members that do the same job with very different engineering trade-offs. All three are built from the same Vivado/Vitis HLS C sources, but only one of them runs HLS on your machine:

Pick this block when you want the standard chain and you do not want a Vitis HLS installation in the build path (it also makes remote/cloud builds and rebuilds on a plain Vivado install deterministic — the netlist is already in the plugin, so two builds of the same project give bit-identical logic).

Pick MCA HLS instead when you need shaping longer than 2048 samples, a trigger trapezoid longer than 128 samples, an independently sized baseline buffer, hardware time stamps, or the trigger-inhibit input.

Pick MCA Short Signal instead when the pulses are short, FPGA area is the constraint, or you need pile-up rejection.

Pin Description link

Properties link

⚙️ Detailed Operation link

Where the RTL comes from link

CompileHDL does not invoke any synthesis tool. It copies one of three embedded VHDL files into the project’s pcores/ directory and instantiates the matching top entity:

Each file is RTL emitted by Vivado HLS 2017.4. The generator report is still embedded in the netlist as a CORE_GENERATION_INFO attribute; for the 2048 variant it reads:

  MCAHP_2048,hls_ip_2017_4,{HLS_INPUT_TYPE=cxx, HLS_INPUT_FIXED=1,
  HLS_INPUT_PART=xc7k160tfbg676-3, HLS_INPUT_CLOCK=12.500000,
  HLS_INPUT_ARCH=pipeline, HLS_SYN_CLOCK=10.402286,
  HLS_SYN_LAT=12, HLS_SYN_TPT=1,
  HLS_SYN_MEM=9, HLS_SYN_DSP=6, HLS_SYN_FF=2343, HLS_SYN_LUT=2822}
  

So the core was closed at 12.5 ns (80 MHz) target, 10.4 ns achieved on a Kintex-7 −3, it is fully pipelined at one sample per clock, and it costs roughly 9 BRAM / 6 DSP / 2343 FF / 2822 LUT. Those figures are for the 2048 variant; the 512 and 1024 variants differ only in the depth of two RAMs (see below), so the DSP/FF/LUT cost is essentially the same and only the BRAM count shrinks.

What Shaping Size really changes link

The delay memories inside the netlist were read directly from the three files. Only two of them scale:

This has three practical consequences that the property text does not mention:

• TRAP_K and TRAP_M must stay below Shaping Size — they are used as read-pointer offsets into the two scaling RAMs, and an offset larger than the RAM depth aliases onto the wrong sample instead of raising an error.
• TRIG_K and TRIG_M must stay below 128 in every variant. Choosing Shaping Size = 2048 does not buy you a longer trigger trapezoid. If you need one, use MCA HLS.
• The baseline ring buffer is always 2048 words, so BL_LEN is usable up to 11 ($2^{11} = 2048$) regardless of Shaping Size — even though the property description claims Shaping Size “will affect the trapezoidal shaper and the baseline restorer”. It does not affect the baseline restorer.

Trapezoidal filter and pole-zero link

The slow shaper is the Jordanov–Knoll recursive trapezoid with the deconvolution term folded in:

$$ d^{k}[n] = x[n] - x[n-k] $$ $$ d^{k,m}[n] = d^{k}[n] - d^{k}[n-m] $$ $$ p[n] = p[n-1] + d^{k,m}[n] $$ $$ s[n] = s[n-1] + \bigl(256,p[n] + M,d^{k,m}[n]\bigr) $$

with $k$ = TRAP_K, $m$ = TRAP_M, $M$ = DECONV_M. The rise time of the trapezoid is $\min(k,m)$ samples and the flat top is $|k-m|$ samples, so the usual setting is TRAP_M = TRAP_K + flat-top (the default pair 0x0100 / 0x010A is a 256-sample rise with a 10-sample flat top).

DECONV_M is a fixed-point coefficient scaled by 256, which is why the classic pole-zero formula carries that factor:

$$ M = \frac{256}{e^{T_s/\tau} - 1} $$

where $T_s$ is the sample period and $\tau$ the preamplifier decay constant. Set DECONV_M to 0 to disable pole-zero cancellation.

TRAP_GAIN is a Q8.16 multiplier applied to the shaper output (0x010000 = ×1.0).

Baseline restorer and energy sampling link

The baseline is the moving average of the shaper output over $2^{\rm BL_LEN}$ samples. On every trigger the average is frozen and BASELINE_HOLD goes high for BL_INIB samples, so BL_INIB must cover the whole pulse (rise + flat top + fall) or the tail of the pulse will be averaged into the baseline and the spectrum will drift with rate.

SAMPLE_POS is the distance, in samples, from the trigger to the point where (shaper − baseline) is captured. It should land in the middle of the flat top:

$$ \mathrm{SAMPLE_POS} \approx \mathrm{TRAP_K} + \frac{\mathrm{TRAP_M} - \mathrm{TRAP_K}}{2} $$

Configure / run link

RUN_CFG is the master enable. With RUN_CFG = 0 the chain is held in its configuration state: accumulators, delay lines and pointers are cleared and no energy is produced. Bring all the parameter pins to their final values first, then raise RUN_CFG. The HLS cores contain a pre-roll counter that discards the first passes through the delay lines after RUN_CFG rises, so the first valid energies appear only after the delay lines have filled — allow a few thousand samples of dead time after every RUN_CFG 0→1 edge before trusting the spectrum.

Software interface link

This block declares no memory-mapped registers: CompileMMC and CompileSDK are empty. Everything is controlled through pins. The usual pattern is to drive the parameter pins from Register blocks (so the SciSDK can write them) and to feed ENERGY / ENERGY_DV into a Spectrum, List or Oscilloscope endpoint, which is where the SciSDK-visible registers actually live.

Realistic wiring link

  ADC ─► DATA_IN            ENERGY ───► Spectrum / List endpoint
      POLARITY            ENERGY DV ─┘
      OFFSET              TRIGGER ───► counter / coincidence logic
 Reg ─► THRS TRIG_K TRIG_M      BL HOLD ─► (diagnostics)
 Reg ─► TRAP_K TRAP_M DECONV_M TRAP_GAIN
 Reg ─► BL_LEN BL_INIB SAMPLE_POS
 Reg ─► RUN(1) CFG(0)    TRAP MON / TRAP-BL MON / BL MON ─► Oscilloscope
  

The five 32-bit monitor outputs (TRIGGER_DELTA_MON, TRIGGER_TRAP_MON, TRAP_MON, TRAP_BL_MON, BL_MON) exist to be wired into an oscilloscope endpoint while you tune the filter; they can all be left unconnected in production.

Timing link

The symbol latency (13) is what the Sci-Compiler scheduler uses to align this block with parallel paths; the HLS report figure (12) is the core’s own measured latency. Use 13 when you have to compensate a parallel branch by hand.

Resources & Timing link

• Latency: 13 clocks declared on the symbol (the HLS report embedded in the netlist says 12); trigger to ENERGY DV is SAMPLE_POS samples on top of that

• Throughput: 1 sample per clock (HLS_SYN_TPT = 1)

• Figures reported by Vivado HLS 2017.4 for the 2048 variant on xc7k160tfbg676-3: 9 BRAM, 6 DSP, 2343 FF, 2822 LUT.
• Timing was closed at a 12.5 ns target with a 10.4 ns estimate, i.e. the core is comfortable at 80 MHz and was not characterised above ~96 MHz.
• The 512 and 1024 variants differ only in the depth of two RAMs; expect the same DSP/FF/LUT cost and fewer BRAMs.
• No memory-mapped registers are generated (CompileMMC / CompileSDK are empty) — the software interface is whatever endpoint you connect ENERGY to.