Check Box — Control Systems/Dashboard

Control_Systems/Dashboard/Check_Box · 0 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 Box

Control Systems / Dashboard

An operator control that puts its current setting on a wire:

y = v_cleared or y = v_checked, whichever the check box is set to

Ports

Output – the control's value y, always a scalar [1,1] signal. The block has no inputs: it is a source, and nothing it reads comes from the diagram.

Parameters

State – which way the check box is set: Cleared or Checked. Defaults to Cleared.
Cleared Value – the number on the output in the Cleared state. Scalar; defaults to 0.
Checked Value – the number on the output in the Checked state. Scalar; defaults to 1. The two defaults are Simulink's own: its Checkbox ships with the pair [0 1].
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 setting is resolved to one number when the configuration is loaded and exposed as a tunable parameter on the generated core, so a deployed core can be re-pointed at a different setting without regenerating it – which is the whole point of a control. Like Constant and unlike the time-driven sources, this block reads no clock on any target, so the three HDL targets are genuinely synthesizable: the value is a Q16.16 literal driven onto the signal.

Simulink bridge

No equivalent, and this is not an omission. Simulink's Checkbox is a DASHBOARD block and has ZERO ports of any kind - measured on R2026a, where a model holding one and nothing else refuses to run with "contains no blocks or all blocks are virtual". It does not put its value on a wire: it reaches its target through Binding, a reference to another block's PARAMETER, and ICore has no cross-block parameter reference for that to become (the same absence that blocks Signal Routing/Parameter Writer and the State Reader/Writer pair). This block is the ICore reading of that control - the value goes on a wire instead - so it is a DIFFERENT block from the Simulink one rather than a mapping of it, and it is reported on exchange rather than asserted. There is also nothing to compare against: the Simulink block is virtual, so no simulation of it produces a sample. Wire this block into whatever the Simulink dashboard control would have been bound to.

Notes

Algebraic and stateless, and time-independent: the output is the same at every instant of a run, because the setting is read once when the configuration loads.
The two values may be any numbers and need not be 0 and 1 – a check box between two set-points is the ordinary use, and nothing here treats the output as a flag.

Code facts#

Fact	Value
registered type	`Control_Systems/Dashboard/Check_Box`
family	`Control_Systems/Dashboard`
solver environment class	`ICoreBlock_0_Control_Systems_1_Dashboard_2_Check_Box`
source	`src/ICoreBlocks/ICoreBlockLibrary/Blocks/Control_Systems/Dashboard/Check_Box/ICoreBlock_0_Control_Systems_1_Dashboard_2_Check_Box.cpp`
header	`src/ICoreBlocks/ICoreBlockLibrary/Blocks/Control_Systems/Dashboard/Check_Box/ICoreBlock_0_Control_Systems_1_Dashboard_2_Check_Box.h`
default size on canvas	70 × 70 px
ports at insert	0 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	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
`State`	`Cleared%~%Checked~~Cleared`	—
`Cleared Value`	`0`	—
`Checked Value`	`1`	—

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::None`
Simulink path	—
port-count rule	`PortsParam::None`
`SampleTime` parameter	yes

Caveat (shown to the user): Simulink's Checkbox is a DASHBOARD block and has ZERO ports of any kind - measured on R2026a, where a model holding one and nothing else refuses to run with "contains no blocks or all blocks are virtual". It does not put its value on a wire: it reaches its target through Binding, a reference to another block's PARAMETER, and ICore has no cross-block parameter reference for that to become (the same absence that blocks Signal Routing/Parameter Writer and the State Reader/Writer pair). This block is the ICore reading of that control - the value goes on a wire instead - so it is a DIFFERENT block from the Simulink one rather than a mapping of it, and it is reported on exchange rather than asserted. There is also nothing to compare against: the Simulink block is virtual, so no simulation of it produces a sample. Wire this block into whatever the Simulink dashboard control would have been bound to

Catalog contract: src/ICoreBlocks/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.

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 Box block -- an operator control that puts its setting on a wire y is one of two numbers, chosen by which way the control is set.

It is a SOURCE: no inputs, one 1x1 output. The setting is resolved to a single number when the configuration loads, so the block reads no clock, holds no state and answers the same number at every instant of a run -- which is what lets all ten targets share one body that copies a tunable parameter onto the output signal, exactly as Constant's does.

⚠ THERE IS NO SIMULINK COUNTERPART, AND THAT IS A MEASUREMENT RATHER THAN A GAP. Simulink's Checkbox has ZERO ports of any kind and is VIRTUAL -- a model holding one and nothing else refuses to run with "contains no blocks or all blocks are virtual" (R2026a, measured). It reaches its target through Binding, a reference to another block's PARAMETER, which this tree has no counterpart for. So this block is the reading of that control which this tree's signal model can express -- the value goes on a wire -- and the bridge reports it rather than asserting a mapping that would be wrong. There is also nothing to compare against: a virtual block produces no sample, so no parity testbench is owed or possible.

Sample results#

Plotted: free — No input: the block run alone

Category source · sample time 0.1 · 60 steps · commit 38bce32b1d1471614469d78cd797992dfd022eac · produced by docsSample --out <folder> --blocks Knob Slider Check_Box Toggle_Switch Rocker_Switch Slider_Switch Push_Button Rotary_Switch Combo_Box Radio_Button Edit --steps 60 · data docs/generated/samples/Control_Systems__Dashboard__Check_Box.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).