Discrete FIR Filter — Control Systems/Discrete
Control_Systems/Discrete/Discrete_FIR_Filter · 1 input / 1 output port(s) at insert · exports to Python, MATLAB, Java, Rust, C, C++, VHDL, Verilog, SystemVerilog, PLC Structured Text
Description#
The block's own DESCRIPTION_HTML, rendered verbatim — the same text the config dialog's info panel and the library navigator show. Fix a wrong sentence in the block's .cpp (R-D9), never here.
Discrete FIR Filter
Control Systems / Discrete
A finite impulse response filter – a weighted sum of the most recent inputs, with no feedback at all:
y[k] = c0·u[k] + c1·u[k−1] + … + cn·u[k−n]
The coefficients ARE the impulse response, so a run of n+1 equal values ci = 1/(n+1) is a moving average over n+1 samples. Before the line has filled, the configured initial states stand in for the inputs that have not happened yet.
Having no poles, an FIR filter is unconditionally stable whatever its coefficients, and has exactly linear phase whenever they are symmetric – the two properties it is usually chosen for. The price is order: matching the sharpness of a low-order IIR filter takes many more taps.
Ports
- Input – the signal to filter, of any size [p,m].
- Output – the filtered signal, of the same size.
The filter is SISO, but it is applied independently to every entry of the input signal, each entry carrying its own delay line.
Parameters
- Coefficients – c0…cn, a vector whose first entry multiplies the current sample and whose last multiplies the oldest. Its length sets the filter order: n+1 values means n states.
- Initial States – the contents of the delay line at the start of the run. A scalar seeds every tap; a vector of length n seeds them individually, newest first.
- Sampling Time (s) – zero or less inherits the solver's rate; a positive value runs the block at that period.
Code export
All ten targets: Python, MATLAB, Java, Rust, C, C++, VHDL, Verilog, SystemVerilog and PLC Structured Text. The coefficients are baked into the generated sum rather than exposed as tunable parameters, because their count also fixes how many state words the core carries. Change them here and export again.
The three HDL targets emit the delay line unrolled, so a long filter on a large signal is a large entity – the state word count is n×p×m.
Simulink bridge
Import and export, mapped to
simulink/Discrete/Discrete FIR Filter.
"Coefficients" to Coefficients, "Initial States" to
InitialStates, and "Sampling Time (s)" to SampleTime, as
on every block.
Two Simulink parameters are always implied rather than offered as a choice:
FilterStructure = Direct form, which is the structure this
block realizes and therefore what makes the initial states mean the same thing on
both sides, and CoefSource = Dialog parameters, since the taps
come from the config here and never from a port.
What does not cross: coefficients arriving on a port, the enable port and external reset all add input ports in Simulink, and no config value here can add or remove a port. Simulink's symmetric, antisymmetric, transposed and lattice structures do not cross either – they are the same filter computed differently, but they define their states differently, so the initial states would no longer mean the same thing.
Notes
- Discrete only, and stateful: n past inputs per entry.
- Being linear, the block is directly usable by the model reduction and linear-analysis commands.
Code facts#
| Fact | Value |
|---|---|
| registered type | Control_Systems/Discrete/Discrete_FIR_Filter |
| family | Control_Systems/Discrete |
| solver environment class | ICoreBlock_0_Control_Systems_1_Discrete_2_Discrete_FIR_Filter |
| source | src/ICoreSDK/ICoreBlockLibrary/Blocks/Control_Systems/Discrete/Discrete_FIR_Filter/ICoreBlock_0_Control_Systems_1_Discrete_2_Discrete_FIR_Filter.cpp |
| header | src/ICoreSDK/ICoreBlockLibrary/Blocks/Control_Systems/Discrete/Discrete_FIR_Filter/ICoreBlock_0_Control_Systems_1_Discrete_2_Discrete_FIR_Filter.h |
| default size on canvas | 130 × 85 px |
| ports at insert | 1 in, 1 out |
| code generators implemented | Python, MATLAB, Java, Rust, C, C++, VHDL, Verilog, SystemVerilog, PLC Structured Text |
Ports#
| # | Direction | Signal type | Description label |
|---|---|---|---|
| 1 | in | ICoreDouble | — |
| 2 | out | ICoreDouble | — |
Ports the constructor creates. A block whose port list changes with its configuration adds or removes ports at load time; the count above is the one a freshly inserted block has.
Configuration variables#
| Config variable | Default | Simulink parameter |
|---|---|---|
Coefficients | [0.5 0.5] | Coefficients |
Initial States | 0 | InitialStates |
Every block also carries Sampling Time (s) from ICoreBlockSolverEnvironment: zero or less inherits the solver's rate, a positive value runs the block at that period.
Simulink bridge#
| support | Support::Both |
| Simulink path | simulink/Discrete/Discrete FIR Filter |
| port-count rule | PortsParam::None |
SampleTime parameter | yes |
| always set | FilterStructure = Direct form, CoefSource = Dialog parameters |
| ICore config | Simulink parameter | Value translation |
|---|---|---|
Coefficients | Coefficients | passes through |
Initial States | InitialStates | passes through |
Caveat (shown to the user): coefficients arriving on a port, the enable port and external reset are not supported (each adds an input port in Simulink); the filter structure is always Direct form, since the symmetric, transposed and lattice alternatives define their states differently and the initial states would stop meaning the same thing
Catalog contract: src/ICoreSDK/ICoreCoder/ICoreCommandSystem/SimulinkBridge/ICoreSimulinkBlockCatalog.h
Description vs code#
The lists agree. check_block_descriptions.py finds no disagreement between the description's Ports, Parameters, Code export and Simulink bridge lists and the code's.
The verdict above is
tools/docs/check_block_descriptions.py(P7.1), which compares LISTS. It cannot read a sentence: "stateless" on a block with a state, an initial-value semantic the recursion does not implement, a "not synthesizable" caveat the HDL banner contradicts. That is the agent audit (P7.3) on BLOCK_DESCRIPTION_AUDIT.md, and this tool's green is not a substitute for one.
File banner (developer view)#
The top comment of the block's .cpp — the maths, the realization and the export strategy, addressed to whoever changes it. It must not contradict the description above (P7.5).
Discrete FIR Filter block — a tapped delay line, element-wise Direct form, so the states ARE the past inputs Simulink's "Initial states" names and they seed 1:1. See the header for the A/B/C/D. Everything below the matrices comes from ICoreDiscreteLinearBlockBase.
Sample results#
The same rig also ran:
| Stimulus | What it is | Output range |
|---|---|---|
impulse | Impulse: one sample of 1 at k = 5, 0 elsewhere (Repeating Sequence Stair) | 0 … 0.5 |
ramp | Ramp: slope 1 from t = 0 | 0 … 5.75 |
sine | Sine Wave: amplitude 1, 2 rad/s, no phase, no bias | -0.9949 … 0.994 |
table | Repeating Sequence Stair: [-2 -1 -0.5 0 0.5 1 2 3], one entry per sample | -1.5 … 2.5 |
Plotted: step — Step: 0 -> 1 at t = 1 s
Category dynamic · sample time 0.1 · 60 steps · commit ccf005c8 · produced by docsSample --out <folder> --steps 60 · data docs/generated/samples/Control_Systems__Discrete__Discrete_FIR_Filter.json · the SVG is generated from those numbers by tools/docs/plot_svg.py, so it is a run and not a drawing (R-D10).