Data-Dominant RTL Design & FIR Filters

Abstract

Digital systems are broadly categorized as either Control-Dominant or Data-Dominant. Control-dominant systems prioritize complex decision logic with simple datapaths (e.g., traffic light controllers), whereas data-dominant systems feature extensive, highly parallel datapaths managed by minimal control logic (e.g., Digital Signal Processors, FIR Filters). Implementing a Finite Impulse Response (FIR) Filter in custom hardware demonstrates how data-dominant RTL designs achieve orders-of-magnitude performance speedups over software by processing wide array operations in parallel along logarithmic adder trees.

---

Architectural Classification: Control-Dominant vs. Data-Dominant

RTL designs balance control complexity against datapath computation density depending on the target application:

Attribute	Control-Dominant Design	Data-Dominant Design
Controller Complexity	High: Complex state transition diagrams, many branching conditions.	Low: Minimal state count, often simple iterative loops or single-state control.
Datapath Complexity	Low: Simple registers, basic gates, or minimal arithmetic operations.	High: Extensive register chains, parallel multipliers, adders, and accumulators.
Primary Bottleneck	Decision logic latency & state decoding overhead.	Data propagation delay through deep arithmetic operators (Critical Path).
Typical Examples	CPU Control Units, Protocol Handshakers, Traffic Controllers.	Digital Signal Processors (DSP), FIR Filters, Video/Audio Codecs, Neural Net Accelerators.

---

Case Study: Finite Impulse Response (FIR) Filter

A Finite Impulse Response (FIR) Filter transforms an input digital stream $x(t)$ into a filtered output stream $y(t)$ by computing a configurable weighted sum of present and past input samples.

flowchart LR
    X["x(t)"] --> C0["c₀"]
    X --> D1["z⁻¹"]

    D1 --> C1["c₁"]
    D1 --> D2["z⁻¹"]

    D2 --> C2["c₂"]

    C0 --> A1["+"]
    C1 --> A1

    A1 --> A2["+"]
    C2 --> A2

    A2 --> Y["y(t)"]

Mathematical Definition

For an $N$-tap FIR filter, the transfer function is expressed as:

$$y(t)=\sum _{i=0}^{N-1}{c}_i\cdot x(t-i)$$

3-Tap FIR Filter Equation

$$y(t)=c_0\cdot x(t)+c_1\cdot x(t-1)+c_2\cdot x(t-2)$$

• Filter Taps ($N$): The number of past input samples preserved in the delay chain.
• Filter Coefficients ($c_i$): User-configurable constants that define the frequency response (e.g., low-pass, high-pass, or band-pass filtering).
  • Small $N$: Minimal delay/filtering.
  • Large $N$: Strong noise attenuation, sharper cutoff frequencies, but higher hardware resource usage.

Simple Moving Average Filtering Effect

---

RTL Design Pipeline for a 3-Tap FIR Filter

Step 1: Capture Behavior (HLSM)

Because the datapath processes samples continuously on every clock tick, the controller HLSM requires minimal control states.

High-Level State Machine (HLSM) for FIR Filter Control

Step 2: Datapath Construction

To execute $y(t)=c_{0}x(t)+c_{1}x(t-1)+c_{2}x(t-2)$, the datapath integrates:

1. Sample Delay Chain: A cascaded shift register chain ($x_{t0},x_{t1},x_{t2}$) storing incoming samples $x(t-i)$.
2. Coefficient Registers: Storage registers for constants $c_0,c_1,c_2$ (with write-enable logic for configuration).
3. Parallel Multipliers: Three array multipliers computing $c_i\cdot x(t-i)$ concurrently.
4. Adder Tree: Combinational adder stages summing the partial products into output $y(t)$.

3-Tap FIR Filter Datapath Architecture

Step 3 & 4: Controller Connection & FSM Synthesis

The simple controller asserts load/clear lines to configure coefficients and manage sample propagation.

Interfacing Datapath with Minimal Controller Block

---

Hardware (RTL Circuit) vs. Software Performance Analysis

Evaluating a 100-tap FIR filter demonstrates the profound performance advantage of hardware spatial parallelism over software temporal execution.

Critical Path through a 100-Tap FIR Filter Hardware Adder Tree

Gate-Delay Model Assumptions

• Adder Delay: $2$ gate delays per addition.
• Multiplier Delay: $20$ gate delays per multiplication.
• Software Instruction Delay: $10$ gate delays per instruction execution cycle.

Critical Path & Performance Breakdown

1. Hardware RTL Implementation (Parallel Spatial Processing)

In hardware, all $100$ multiplications execute concurrently in parallel ($20$ gate delays). The resulting $100$ products are summed via a balanced binary adder tree of depth $\lceil {\log }_2(100)\rceil =7$ adder stages.

$$\begin{array}{rl}\text{Longest Critical Path}& =\text{Multiplier Delay}+\left(\lceil {\log }_2(N)\rceil \times \text{Adder Delay}\right)\\ & =20+(7\times 2)\\ & =34\text{ Gate Delays per Sample Output}\end{array}$$

2. Software Implementation (Sequential Loop Processing)

A general-purpose processor must process the 100-tap filter sequentially inside a loop ($100$ multiplications + $100$ additions). Assuming $2$ instructions per operation:

$$\begin{array}{rl}\text{Total Operations}& =(100\text{ mults}\times 2\text{ inst})+(100\text{ adds}\times 2\text{ inst})=400\text{ instructions}\\ \text{Total Latency}& =400\text{ instructions}\times 10\text{ gate delays/instruction}\\ & =4000\text{ Gate Delays per Sample Output}\end{array}$$

Performance Summary Matrix

Metric	Software Execution (CPU)	Dedicated RTL Circuit (Data-Dominant)
Execution Paradigm	Sequential Iterative Loop	Parallel Spatial Hardware Datapath
3-Tap Latency	$\approx 240$ Gate Delays	$24$ Gate Delays ($1\text{ mult}+2\text{ adders}$)
100-Tap Latency	$4000$ Gate Delays	$34$ Gate Delays ($1\text{ mult}+7\text{ tree adders}$)
Speedup (100-Tap)	$1.0\times$ (Baseline)	$\approx 117.6\times$ Faster

Algorithmic Scaling Advantage

As the number of filter taps $N$ grows, software latency increases linearly $\mathcal{O}(N)$, whereas hardware critical path latency grows logarithmically $\mathcal{O}({\log }_{2}N)$ thanks to parallel adder tree structures.

---

Related Notes

• RTL Design Process
• High-Level State Machines
• Timing Constraints in Sequential Designs
• Multiplier & Divider
• Sequential Circuits