Bus To Vector — Control Systems/Signal Attributes
Control_Systems/Signal_Attributes/Bus_To_Vector · 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.
Bus to Vector
Control Systems / Signal Attributes
Passes a bundle of signals through as the vector it already is: y = u, entry for entry, after checking that u is a single column [m,1]. The values are not what the block is for – the check is. Simulink's counterpart converts a virtual bus into a vector so that arithmetic downstream can treat a bundle of signals as one signal; in ICore a bundle of signals already is a stacked column, which is what Mux builds and what In Bus Element takes apart, so there is no conversion left to perform and what the block contributes is the guarantee that its output is a vector.
Ports
- Input – the bundle u, which must be a single column [m,1] of any height. A signal with more than one column is refused by name, with its size in the message, rather than passed on.
- Output – y, the same values at the same size, always.
Parameters
- None. Simulink's block has no dialog parameters at all, and there is nothing on this side to choose either: the block either accepts what arrives or stops the run.
- 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. Every one of them emits the same list of per-entry copies with constant subscripts, resolved at export time, and there is no parameter behind any of it. The three HDL targets are therefore pure wiring: no arithmetic, so nothing to quantize and nothing that can differ from the other seven by a fixed-point quantum. The size check is a build-time gate, so it does not appear in the generated code – a core is only ever exported from a model that already passed it.
Simulink bridge
Import and export, mapped to simulink/Signal Attributes/Bus to Vector. There is nothing to map: that block has no dialog parameters, measured against R2026a, and this one has no config of its own.
The rate does NOT cross. That block defines no SampleTime parameter
– verified by set_param against R2026a, which answers "BusToVector block
does not have a parameter named 'SampleTime'" – so "Sampling Time (s)" stays on the
ICore side. Writing it anyway would be a hard error that aborts the whole generated script
rather than a warning that degrades.
What crosses, and what a bus loses on the way. Simulink's block accepts a virtual bus and answers the concatenation of its elements in port order, a non-scalar element spread out in place and a nested bus flattened all the way down – measured: a Bus Creator of (1, [2 3], 4) answers [1 2 3 4], and ((1, 2), 3) answers [1 2 3]. That concatenation is exactly the stacked column an ICore Mux produces, which is why a Simulink Bus Creator imports as a Mux and this block then has the vector it wants. What does not cross is the bus's element names: this tree has no bus type to carry them, so an imported model keeps the values and the order and loses the labels.
Notes
- Algebraic, with no state: the output is the input, sample for sample.
- Deliberately carries no state space, even though the identity is perfectly linear. The arithmetic is nothing and the block's job is the ASSERTION, so a model reduction that absorbed it into a neighbour would discard exactly what a user placed it for. It is reported as unmergeable rather than folded away – the same choice Signal Specification makes, and for the same reason.
- Simulink refuses a matrix on this block's input rather than flattening it, and so does this one. To flatten a matrix into a column deliberately, use Reshape; to assert a size rather than assert vector-ness, use Signal Specification.
- The block accepts an input that never was a bundle – a plain scalar or a vector straight off another block – which matches Simulink, where neither is an error.
Code facts#
| Fact | Value |
|---|---|
| registered type | Control_Systems/Signal_Attributes/Bus_To_Vector |
| family | Control_Systems/Signal_Attributes |
| solver environment class | ICoreBlock_0_Control_Systems_1_Signal_Attributes_2_Bus_To_Vector |
| source | src/ICoreBlocks/ICoreBlockLibrary/Blocks/Control_Systems/Signal_Attributes/Bus_To_Vector/ICoreBlock_0_Control_Systems_1_Signal_Attributes_2_Bus_To_Vector.cpp |
| header | src/ICoreBlocks/ICoreBlockLibrary/Blocks/Control_Systems/Signal_Attributes/Bus_To_Vector/ICoreBlock_0_Control_Systems_1_Signal_Attributes_2_Bus_To_Vector.h |
| default size on canvas | 80 × 60 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#
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 Attributes/Bus to Vector |
| port-count rule | PortsParam::None |
SampleTime parameter | no — the counterpart defines none; the rate stays on the ICore side |
Caveat (shown to the user): Simulink's Bus to Vector has NO dialog parameters at all (measured against R2026a), and this block has no config of its own, so nothing crosses but the block itself. What a bus loses on the way is its element NAMES: ICore has no bus type -- a bundle of signals is a stacked column, which is what Mux builds -- so an imported model keeps the values and their order and drops the labels. The rate does not cross either: the Simulink block defines no SampleTime parameter, so "Sampling Time (s)" stays on the ICore side
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.
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).
Bus to Vector -- y = u, and the CHECK is the point Simulink's counterpart turns a virtual bus into a vector so that arithmetic downstream can treat a bundle of signals as one signal. Here that conversion has no work to do: a bundle of signals in this tree IS a stacked column -- what Mux builds and what In Bus Element takes apart -- so the values pass through unchanged and what remains is the assertion that the thing arriving really is a single column.
MEASURED in R2026a rather than reasoned, because the assertion is the whole block. A Bus Creator of (1, [2 3], 4) read through it answers [1 2 3 4]; a Mux of (5, 6) answers [5 6] and a bare Constant of 7 answers 7, so it does not insist on a bus; a nested bus ((1,2),3) flattens all the way to [1 2 3]. And a 2x3 matrix is REFUSED -- "Invalid dimension has been specified for 'Input Port 1'" -- rather than flattened column-major. So a matrix is refused here too, by name and with the size in the message.
TEN BACKENDS EMIT THE SAME LIST OF COPIES, one per entry with constant subscripts, so the three HDL targets are wiring and there is no arithmetic anywhere to quantize.
Algebraic and stateless. No state space -- see the header.
Sample results#
| t | in ICoreDouble-Out-0 | out ICoreDouble-Out-0 |
|---|---|---|
| 0 | -2 | -2 |
| 0.4 | 0.5 | 0.5 |
| 0.8 | -2 | -2 |
| 1.2 | 0.5 | 0.5 |
| 1.6 | -2 | -2 |
| 2 | 0.5 | 0.5 |
| 2.4 | -2 | -2 |
| 2.8 | 0.5 | 0.5 |
| 3.2 | -2 | -2 |
| 3.6 | 0.5 | 0.5 |
| 4 | -2 | -2 |
| 4.4 | 0.5 | 0.5 |
| 4.8 | -2 | -2 |
| 5.2 | 0.5 | 0.5 |
Every 4th of 60 samples, from the table 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) | 0 … 1 |
ramp | Ramp: slope 1 from t = 0 | 0 … 5.8 |
sine | Sine Wave: amplitude 1, 2 rad/s, no phase, no bias | -1 … 0.9996 |
step | Step: 0 -> 1 at t = 1 s | 0 … 1 |
Plotted: table — Repeating Sequence Stair: [-2 -1 -0.5 0 0.5 1 2 3], one entry per sample
Category static · sample time 0.1 · 60 steps · commit ed6153c5d837ea568ac73d3fe986e59a5ba48ee6 · produced by docsSample --out <folder> --blocks Bus_To_Vector --steps 60 · data docs/generated/samples/Control_Systems__Signal_Attributes__Bus_To_Vector.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).