Demux — Control Systems/Base Blocks

Control_Systems/Base_Blocks/Demux · 1 input / 2 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.

Demux

Control Systems / Base Blocks

Splits one input signal into several narrower ones, by rows, in port order. A [6,1] input across three outputs becomes three [2,1] signals. It is the inverse of Mux, and the two are usually used as a pair: mux a set of signals to carry them through a subsystem, demux them at the far end.

Ports

Input – the wide signal u, of any size [m,n]. There must be at least as many rows as there are outputs.
Outputs – two by default, and the count is user-editable (this is the block whose OUTPUT list grows, unlike every other variable-port block in the library). Output k carries a consecutive run of the input's rows and all of its columns, so each is [m_k,n] and the m_k sum to m.

How the rows are shared out: evenly when the count divides, and otherwise the remainder goes to the earlier outputs – a [5,1] over three outputs gives [2,1], [2,1], [1,1]. That is Simulink's own rule, measured against the R2026a block rather than assumed.

Parameters

None. The width of each output follows from the input and the port count, so there is nothing to configure; add or remove output ports to change the split.
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 split is unrolled at export time, so the generated code is plain assignment with no loop over ports and no arithmetic at all.

The three HDL targets are fully synthesizable: splitting is data movement, so the values stay in the Q16.16 datapath and nothing is converted at the port boundary or approximated.

Simulink bridge

Import and export, mapped to simulink/Signal Routing/Demux. There is no parameter behind the split on the ICore side: the output port count becomes Simulink's Outputs number, and an imported count becomes this port list.

Simulink also accepts a width vector there ([2 3]), sizing each output individually instead of splitting evenly. That does not cross: ICore derives every output's width from the input, so an imported vector contributes its length as the port count and the bridge reports that the widths were dropped.

The rate does NOT cross. Simulink's Demux is a virtual block with no SampleTime parameter – verified against the R2026a dialog, which carries only Outputs and DisplayOption – so "Sampling Time (s)" stays on the ICore side. Writing it anyway would be a hard set_param error that aborts the generated script. DisplayOption is cosmetic in Simulink (whether the block draws as a bar) and has no ICore counterpart, so it is left at whatever the far side holds.

Notes

Algebraic, with no state – pure signal routing; nothing is scaled or reordered.
The output sizes are derived from the input, so they are only settled once the upstream block has resolved its own.
Deliberately carries no state space, even though splitting is linear: it RE-INDEXES rather than rescales, and a state space has one output where this block has several. The same reasoning as Matrix Concatenate's, running the other way.
An input with fewer rows than the block has outputs is reported and stops the run, rather than leaving an output port with no rows to carry.

Code facts#

Fact	Value
registered type	`Control_Systems/Base_Blocks/Demux`
family	`Control_Systems/Base_Blocks`
solver environment class	`ICoreBlock_0_Control_Systems_1_Base_Blocks_2_Demux`
source	`src/ICoreSDK/ICoreBlockLibrary/Blocks/Control_Systems/Base_Blocks/Demux/ICoreBlock_0_Control_Systems_1_Base_Blocks_2_Demux.cpp`
header	`src/ICoreSDK/ICoreBlockLibrary/Blocks/Control_Systems/Base_Blocks/Demux/ICoreBlock_0_Control_Systems_1_Base_Blocks_2_Demux.h`
default size on canvas	20 × 60 px
ports at insert	1 in, 2 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`	—
3	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#

No config variable beyond the Sampling Time (s) every block carries.

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/Signal Routing/Demux`
port-count rule	`PortsParam::DemuxOutputs`
`SampleTime` parameter	no — the counterpart defines none; the rate stays on the ICore side

Caveat (shown to the user): the rate does not cross: Simulink's Demux is a virtual block with no SampleTime parameter, so "Sampling Time (s)" stays on the ICore side. A Simulink width VECTOR ("[2 3]") contributes only its length -- ICore sizes every output from the input signal

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 3 ports (1 in, 2 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).

Demux block -- split one signal into several, by rows The inverse of Mux. The input's rows are shared out over the output ports in port order, as evenly as possible, and any remainder goes to the EARLIER outputs: a [5,1] into three outputs gives [2,1], [2,1], [1,1]. Every output keeps the input's column count.

MEASURED, NOT INFERRED. Simulink's Demux with Outputs = 3 on a width-5 signal answers [10;20], [30;40], [50] -- the extra rows go to the earlier ports, not the later ones. An even split ([10;20], [30;40] from a width-4 into 2) is of course the common case, and is the shape every rig in the pre-release suites uses.

THE PORT LIST THAT MOVES IS THE OUTPUT ONE, which is new in this library: every other variable-port block (Mux, Sum, Divide, Matrix Concatenate, ...) grows inputs. That is why the Simulink bridge needed a port-parameter kind of its own -- PortsParam::DemuxOutputs -- rather than reusing MuxCount with a different parameter name: the codec's port replay has to emit addPort(out, ...) and compare against the type's default OUTPUT count.

Code export: the split is unrolled at export time, so the generated code is plain assignment with no loop over ports.

Sample results#

No stimulus produced a sampled output in this rig — Invalid input size at: ICore Blocks/Home/Demux. 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__Base_Blocks__Demux.json