Check Input Resolution — Control Systems/Model Verification
Control_Systems/Model_Verification/Check_Input_Resolution · 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.
Check Input Resolution
Control Systems / Model Verification
Verifies that a signal only ever lands on multiples of a given step, and publishes the verdict: y = 1 where the entry is an exact multiple of Resolution, y = 0 where it is not. The usual job is confirming that a signal really has come from a quantizer, an ADC or a fixed-point path of the resolution it claims.
The test is exact, with no tolerance band – which is Simulink's behaviour, measured. A continuously varying signal will therefore fail almost every sample, and that is the correct answer rather than a defect: feed this block something already quantized.
Ports
- Input – the signal u under test, of any size [m,n].
- Output – the verdict y, of the SAME size [m,n]: one 1.0/0.0 flag per entry.
Parameters
- Resolution – scalar, the step the signal is expected to land on. Defaults to 1, as in Simulink. Must be non-zero; a zero or negative resolution is reported rather than dividing by it.
- Enabled – whether a failing sample is REPORTED. It does not
change the output signal: an entry that fails still reads 0 with this off, which
is what Simulink's counterpart does.
- on – a failure is logged once per run, with the block's path and the time it first happened (the default).
- off – the block computes its verdict silently.
- Stop When Assertion Fails – whether a reported failure also ends
the run.
- on – the run stops at the first failing sample and is marked failed (the default).
- off – the run continues and the failure is a warning.
- 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 resolution is baked in as an export-time constant rather than exposed as a tunable parameter.
The eight software targets take a remainder and compare it to zero. The three
HDL targets do something different and worth knowing about: a Q16.16 value is an
integer scaled by 216, so "is a multiple of" is an exact integer
divisibility test on the raw words – rem in VHDL,
% in Verilog and SystemVerilog. That is bit-exact and far cheaper
than a fixed-point divider, but it is exact only while Resolution is itself
representable in Q16.16, i.e. a dyadic rational such as 0.5, 0.25 or 0.125.
Give it 0.1 and the hardware answers about the nearest representable constant
instead, which is a different question from the one the software targets
answer.
Simulink bridge
Import and export, mapped to simulink/Model Verification/Check Input
Resolution. "Resolution" to resolution, "Enabled" to
enabled and "Stop When Assertion Fails" to
stopWhenAssertionFail, all as plain pass-through values, so the
round trip is lossless. The block always sets Simulink's export to
on: ICore's block always has its verdict output, whereas Simulink's
grows one only when that box is ticked. The Simulink counterpart has no
SampleTime parameter, so "Sampling Time (s)" does not cross –
the block runs at the surrounding Simulink rate.
Notes
- Algebraic, with no signal state. The only state is a one-shot latch so that a failing run logs its complaint once rather than once per sample.
- Not linear, and so deliberately carries no state space – model reduction reports it as unmergeable rather than absorbing a comparison.
- Simulink's own
resolutionaccepts a vector; ICore takes a scalar and reports anything else, rather than broadcasting from a first entry.
Code facts#
| Fact | Value |
|---|---|
| registered type | Control_Systems/Model_Verification/Check_Input_Resolution |
| family | Control_Systems/Model_Verification |
| solver environment class | ICoreBlock_0_Control_Systems_1_Model_Verification_2_Check_Input_Resolution |
| source | src/ICoreSDK/ICoreBlockLibrary/Blocks/Control_Systems/Model_Verification/Check_Input_Resolution/ICoreBlock_0_Control_Systems_1_Model_Verification_2_Check_Input_Resolution.cpp |
| header | src/ICoreSDK/ICoreBlockLibrary/Blocks/Control_Systems/Model_Verification/Check_Input_Resolution/ICoreBlock_0_Control_Systems_1_Model_Verification_2_Check_Input_Resolution.h |
| default size on canvas | 80 × 80 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 |
|---|---|---|
Resolution | 1 | resolution |
Enabled | on%~%off~~on | enabled |
Stop When Assertion Fails | on%~%off~~on | stopWhenAssertionFail |
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/Model Verification/Check Input Resolution |
| port-count rule | PortsParam::None |
SampleTime parameter | no — the counterpart defines none; the rate stays on the ICore side |
| always set | export = on |
| ICore config | Simulink parameter | Value translation |
|---|---|---|
Resolution | resolution | passes through |
Enabled | enabled | passes through |
Stop When Assertion Fails | stopWhenAssertionFail | passes through |
Caveat (shown to the user): the block runs at the surrounding Simulink rate; "Sampling Time (s)" does not cross. Simulink's "resolution" accepts a vector where ICore takes a scalar. ICore's block always carries its verdict output, so the bridge pins Simulink's "export" to on
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).
Check Input Resolution -- verifies the input lands only on multiples of a given step y = 1 where u is an exact multiple of
resolution, 0 elsewhere. Entry by entry, so the output keeps the input's size. Measured against Simulink R2026a: an exact test, with no tolerance band.TWO FAMILIES OF IMPLEMENTATION, and they agree exactly:
- The eight SOFTWARE targets take a remainder and compare it to zero. C's fmod and
Java/Rust's % truncate; MATLAB's mod and NumPy's np.mod floor. Those differ in SIGN on negative inputs -- but they are zero on exactly the same values, and zero is the only thing asked, so the split is harmless here. It would NOT be if this block ever published the remainder itself.
- The three HDL targets cannot divide cheaply in Q16.16, so they exploit the format:
a Q16.16 value IS an integer scaled by 2^16, so "u is a multiple of r" is exact integer divisibility of the raw words --
remin VHDL,%in Verilog and SystemVerilog. Bit-exact, and cheaper than a divider.The HDL route is exact only while
resolutionis itself representable in Q16.16 (a dyadic rational). The description says so; a resolution of, say, 0.1 is not, and the hardware answer would then be about the rounded constant rather than the one typed.
Sample results#
| t | in ICoreDouble-Out-0 | out ICoreDouble-Out-0 |
|---|---|---|
| 0 | 0 | 1 |
| 0.4 | 0 | 1 |
| 0.8 | 0 | 1 |
| 1.2 | 1 | 1 |
| 1.6 | 1 | 1 |
| 2 | 1 | 1 |
| 2.4 | 1 | 1 |
| 2.8 | 1 | 1 |
| 3.2 | 1 | 1 |
| 3.6 | 1 | 1 |
| 4 | 1 | 1 |
| 4.4 | 1 | 1 |
| 4.8 | 1 | 1 |
| 5.2 | 1 | 1 |
Every 4th of 60 samples, from the step stimulus.
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) | 1 … 1 |
Plotted: step — Step: 0 -> 1 at t = 1 s
Category static · sample time 0.1 · 60 steps · commit ccf005c8 · produced by docsSample --out <folder> --steps 60 · data docs/generated/samples/Control_Systems__Model_Verification__Check_Input_Resolution.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).