Assertion — Control Systems/Model Verification

Control_Systems/Model_Verification/Assertion · 1 input / 0 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.

Assertion

Control Systems / Model Verification

Asserts that its input never goes zero. The test is a purely logical one: ≠ 0 passes, = 0 fails, and the magnitude of a nonzero value carries no further meaning. Any zero entry fails it, so a vector or matrix signal is asserted as soon as one of its elements reaches zero. Drive it from a comparison and the run reports the instant the condition it guards stops holding.

Ports

Input – the condition being asserted, of any size [m,n], read as a logical test only.
No outputs – the block is a pure sink. Simulink's Assertion is the one block in the Model Verification library with no "output assertion signal" option, so unlike its ten Check siblings this one has no verdict port to offer.

Parameters

Enabled – whether a failing sample is reported at all.
- on – a failure is logged once per run, with the block's path and the time it first happened (the default).
- off – the block is inert.
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.
Ignored entirely when Enabled is off.
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 accept the block, and in every one of them it emits a body that does nothing. That is deliberate rather than a gap: an assertion is a simulation-time diagnostic, it has no output signal to compute, and a deployed core has no run to stop – which is also why Simulink Coder drops Model Verification blocks from generated code. The block is therefore free to leave in a model that will be exported: it costs nothing in the generated core and changes no signal. If you want the verdict to REACH the generated code, use one of the Check blocks instead – they all carry a verdict output that every target computes.

Simulink bridge

Import and export, mapped to simulink/Model Verification/Assertion. "Enabled" to Enabled and "Stop When Assertion Fails" to StopWhenAssertionFail as plain pass-through values, so the round trip is lossless. Note the capitalised Simulink names: Assertion spells them with capitals where its ten Check siblings use enabled and stopWhenAssertionFail. Simulink's AssertionFailFcn, a MATLAB callback run on failure, has no ICore equivalent and does not cross. "Sampling Time (s)" goes to SampleTime, as on most blocks – Assertion is the ONLY block in this family that has such a parameter at all.

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.
Being a sink, it is covered by code export verification but not by Simulink parity: a parity testbench compares an exported core's OUTPUT, and this block has none. The verifier records the signal FEEDING it instead, so a green row proves the exported core builds, runs and leaves that signal untouched.

Code facts#

Fact	Value
registered type	`Control_Systems/Model_Verification/Assertion`
family	`Control_Systems/Model_Verification`
solver environment class	`ICoreBlock_0_Control_Systems_1_Model_Verification_2_Assertion`
source	`src/ICoreSDK/ICoreBlockLibrary/Blocks/Control_Systems/Model_Verification/Assertion/ICoreBlock_0_Control_Systems_1_Model_Verification_2_Assertion.cpp`
header	`src/ICoreSDK/ICoreBlockLibrary/Blocks/Control_Systems/Model_Verification/Assertion/ICoreBlock_0_Control_Systems_1_Model_Verification_2_Assertion.h`
default size on canvas	70 × 70 px
ports at insert	1 in, 0 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`	—

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
`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/Assertion`
port-count rule	`PortsParam::None`
`SampleTime` parameter	yes

ICore config	Simulink parameter	Value translation
`Enabled`	`Enabled`	passes through
`Stop When Assertion Fails`	`StopWhenAssertionFail`	passes through

Caveat (shown to the user): Simulink's AssertionFailFcn (a MATLAB callback run on failure) has no ICore equivalent and does not cross

Catalog contract: src/ICoreSDK/ICoreCoder/ICoreCommandSystem/SimulinkBridge/ICoreSimulinkBlockCatalog.h

Description vs code#

The checker has a blind spot here — it could not resolve something (a grouped port bullet, a computed config name), which is reported and never counted as a pass. A reader has to settle it:

B0 Ports lists 2 entries for 1 port (1 in, 0 out) — grouped, or one undocumented? a reader must say
B0 every stimulus in the sample errored — cross-checks skipped

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.

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).

Assertion block -- reports when its input goes zero Passes while every entry of the input is nonzero; fails the moment any entry is 0. Drive it from a comparison and the run tells you the instant the condition it guards stops holding.

A pure SINK. Simulink's Assertion is the ONE block in the Model Verification library with no "output assertion signal" option -- the other ten grow a verdict port when export is ticked, this one cannot -- so there is nothing to publish and nothing to compare. It declares itself with setSinkBlock() accordingly.

Code export: model verification is a SIMULATION-time activity, and the exported cores deliberately do nothing, exactly as Simulink Coder drops Model Verification blocks from generated code. See the description's "Code export" section, which says so to the user.

Sample results#

No stimulus produced a sampled output in this rig — Assertion failed at t = 0.000000 s: ICore Blocks/Home/Assertion. That is a fact about the single-block rig, not a verdict on the block: an offline batch fit, a block whose output only appears at onSolverFinish, or one that needs a driven environment cannot be exercised alone.

Category unsampled · sample time 0.1 · 60 steps · commit ccf005c8 · produced by docsSample --out <folder> --steps 60

Sample data: docs/generated/samples/Control_Systems__Model_Verification__Assertion.json