RF Sequential FIR (programmable)

Introduction link

The Sequential FIR (programmable) block is the run-time reloadable sibling of Component_SeqFIR. It shares the exact same time-shared MAC datapath — one multiplier walks all NumTaps taps within the SysClk / DataClk window, so a long filter costs a single multiplier per channel — but instead of a compile-time coefficient ROM it stores the taps in a small dual-port BRAM that can be rewritten while the design runs.

      SAMPLE_IN ┐  (1 pulse per new sample, gapped every ClockRatio)
    IN_I / IN ┤ [ 1x time-shared MAC over NumTaps ] ── OUT_I / OUT
    IN_Q      ┘        ▲   coef_ram (BRAM)          └─ OUT_Q
                       │                          VALID_OUT ──
    COEF_ADDR ─────────┤
    COEF_DATA ─────────┤  (write h[addr] = data on COEF_WR pulse)
    COEF_WR   ─────────┘
  

Unlike the fixed seq_fir, this block is configured through the standard property grid (widths, tap count, clock ratio and the MAC output shift). The FIR Designer shown above is still the recommended companion tool: use it to prototype the response and export a quantised integer coefficient set, then stream those coefficients into the block at run time over the COEF_* interface. See the Visual designer note below.

For the fixed-coefficient (ROM, no reload) version see Component_SeqFIR (seq_fir).

Pin Description link

Properties link

Usage link

Time-sharing / clock-ratio concept link

Identical to seq_fir: CLK is the system clock, a new input sample is presented once every ClockRatio system clocks and marked with a one-cycle SAMPLE_IN pulse. On that pulse the delay line shifts, the accumulator clears and a counter starts; each subsequent system clock performs exactly one MAC (acc += delay[cnt] * coef_ram[cnt]); after NumTaps cycles the shifted result is driven on the output and VALID_OUT pulses. Because one tap is processed per clock:

      NumTaps <= ClockRatio          (checked at compile time)
  

so the core needs only one multiplier (Real) or two (Complex), independent of filter length.

Coefficient reload link

The coefficients are held in a NUM_TAPS x CoefSize dual-port BRAM (ram_2p) with a synchronous write port:

      on rising CLK:
      if COEF_WR = 1:  coef_ram[COEF_ADDR] <= COEF_DATA   (signed)
  

• COEF_ADDR is ceil(log2(NumTaps)) bits — the tap index to write.
• COEF_DATA is CoefSize signed bits — the new coefficient value.
• COEF_WR is a one-cycle write strobe.

Writes and MAC reads are independent (true dual-port), so you may reload taps at any time. The clean recipe is to update the whole tap set in the gap between samples (the COEF_* interface is normally quiet during a MAC burst); as long as you do not overwrite the tap the MAC is currently reading, the filter transitions smoothly. To load a full NumTaps-length response, issue NumTaps writes walking COEF_ADDR from 0 to NumTaps - 1. There is no double-buffer: the change takes effect on the next convolution that reads the rewritten location.

Coefficients survive reset (the BRAM is not cleared by ap_rst; it powers up to 0 and holds whatever was last written).

Bit widths and scaling link

Data is signed two’s complement. Internally:

      ACC_SIZE = InputSize + CoefSize + 8            (8 guard bits)
    OUT_SIZE = ACC_SIZE - CoefShift
             = InputSize + CoefSize + 8 - CoefShift
    ADDR_SIZE = ceil(log2(NumTaps))
  

CoefShift is the right-shift applied to the accumulator before the output. It is a property here (not stored by a designer), and it must match the fixed-point scale that the host/driver used when quantising the coefficients it writes. If you quantise with a scale of 2^(CoefSize-1)-1 (unity DC gain), use CoefShift = CoefSize - 1.

Complex vs real link

• Real: pins IN / OUT, one multiplier.
• Complex: IN_I/IN_Q and OUT_I/OUT_Q, two multipliers, sharing the same coefficient BRAM (one write port updates both channels).

Visual designer link

This block itself uses the standard property grid — double-clicking it edits the hardware parameters directly, it does not open the WebView2 designer. The FIR Designer pictured in the introduction (the same tool the fixed seq_fir opens on double-click) is nonetheless the easiest way to produce a valid coefficient set: design the response there, let it quantise the taps to signed CoefSize integers and note the accumulator shift it reports, then set CoefShift to that value and stream the integer taps into the BRAM over COEF_ADDR / COEF_DATA / COEF_WR (typically from a register bank the SDK fills). Because the taps are not baked in, you can swap the entire response without resynthesising the bitstream.

Latency and throughput link

• #pragma HLS PIPELINE II=1: one MAC per system clock.
• End-to-end latency from SAMPLE_IN to VALID_OUT is about NumTaps system clocks.
• Sustained throughput is one filtered sample every ClockRatio system clocks (the input DataClk rate).
• All ports use the ap_none interface.

Reset link

RESET (ap_rst) clears the delay line, accumulator and tap counter. It does not clear the coefficient BRAM.

Typical applications link

• Adaptive / LMS equaliser where an external engine updates taps.
• Software-defined channel-select filter: change bandwidth from the SDK without a rebuild.
• Matched filter whose shape tracks a run-time-selected symbol rate.

Resources & Timing link

• Latency: ~NumTaps system-clock cycles from SAMPLE_IN to VALID_OUT

• Throughput: One sample every ClockRatio system clocks (the DataClk rate)

Implemented with Vitis HLS. One DSP multiplier for Real, two for Complex, regardless of filter length (time-shared MAC, one MAC per system clock, II=1). Coefficients live in a NUM_TAPS x CoefSize dual-port BRAM (ram_2p) with a synchronous write port, so they are reloadable at run time and are NOT optimised away by Vivado (DSP usage is deterministic). A NumTaps-deep delay line (per channel) is kept in registers / SRL. Hard constraint enforced at compile: NumTaps <= ClockRatio.