Subsystem — Private/Subsystem Components

Subsystem

Subsystem Components

A block that contains a diagram of its own. Double-click it to open the level inside, where the subsystem is built from ordinary blocks like any other canvas.

Ports

A subsystem has no port list of its own: its ports are the gates placed inside it. Add an Input Gate inside and a matching input port appears on the block here; add an Output Gate and an output port appears. Signal sizes travel through the gates, so nothing has to be declared twice.

Parameters

• Treat as Atomic Unit – Off (default) or On, Simulink's TreatAsAtomicUnit. An atomic subsystem runs its contents as one unit. Every subsystem already runs that way today, so On changes the order of nothing; what it adds is the rate rule below. A plain subsystem (Off) is marked for Simulink's virtual behaviour, where its contents join the level around it, and runs as one unit until that lands.
• Sampling Time (s) – -1 (default) inherits the rate of the level around it. On an atomic subsystem a positive value is Simulink's SystemSampleTime: every block inside that inherits (-1) runs at it, discrete blocks included, and a run is refused if any block inside runs at another period (Simulink's InvBlkInPeriodicAtomic, which refuses a multiple of the period too) or has continuous states (InvBlkWithNoSTPrmInPeriodicAtomic). On a plain subsystem Simulink ignores the value; ICore's fixed-step continuous solver still hands it to the continuous blocks inside, as it always has.
• Function Packaging – Auto (default), Inline, Nonreusable function or Reusable function, Simulink's RTWSystemCode. It shapes exported code only, never a number, and is read only on an atomic subsystem: Simulink accepts it on a plain one and ignores it. See Code export.
• Variant – Off (default) or On, Simulink’s Variant. On makes this a Variant Subsystem: the subsystems directly inside it are its choices, and only the active one runs; every other choice leaves the run and the export whole, whatever is inside it. Wire the input gate to every choice, and each output of every choice through a Variant Merge (one per output) to the output gate. No choice active stops the run, as Simulink stops it.
• Variant Control Mode – expression (default), label or sim codegen switching, read on a Variant Subsystem. In expression mode each choice’s Variant Control is a condition over the variables (V==1, V>=1 && W~=2, mod(V,2)==1, true), and the FIRST true choice runs, as Simulink’s Variant Subsystem takes it; in label mode the choice whose control equals Label Mode Active Choice runs; sim codegen switching runs the (sim) choice.
• Label Mode Active Choice – the active label, in label mode.
• Variant Control – true by default: what makes this subsystem the active choice when it sits directly inside a Variant Subsystem. Read nowhere else.
• Variant Choices Specifier – empty (default), or the files a Variant Assembly Subsystem’s choices are, Simulink’s VariantChoicesSpecifier: a cell of paths inside the project folder, {'References/Fast.icore','References/Slow.icore'} (.icore may be left off). Read on a Variant Subsystem in label mode, where the choices become exactly those files as soon as the edit is made: each one a referenced subsystem named after its file, its Variant Control the file’s name, filled from the file and wired like any choice. A file the list drops loses its choice, and so does any choice that names no listed file; {} removes them all and clears the active label. A file that is not in the project folder, or a value that is not a cell, is refused and the list goes back to the files the choices name, as Simulink refuses it. The active label is kept, so if its choice went the run stops until another is chosen. The choices and the edit undo together. Ignored elsewhere, as Simulink ignores it.
• Referenced File – empty (default), or the path of an .icore recipe file inside the project folder, relative to it (References/Filter.icore), Simulink’s ReferencedSubsystem. A subsystem that names a file is an instance of it: the project saves the path and the subsystem’s gates, and the file holds its contents, which every instance shows when the project is opened. Editing any instance edits the file. The first instance edited holds the file until the project is saved; the save writes the file from that instance, before the project itself. An edit in another instance of the same file meanwhile is refused and taken back, and so is an undo or redo there, as Simulink refuses it. A save also makes the file from the instance when it is not there yet. A file that is missing when the project opens is not an error: the instance keeps its gates, so its ports and links, and nothing else inside. The ready-made Subsystem Reference (Ports & Subsystems templates) is one, on a file of its own.
• Reference Type – Subsystem (default) or Model. Model makes this a Model block, Simulink’s ModelReference, where Subsystem is a Subsystem Reference: it is atomic whatever Treat as Atomic Unit says, so its contents run as one unit and its Sampling Time (s) is its own rate, which under a fixed-step solver must be a whole multiple of the step (Simulink’s FixedStepNEFundStep); and its Model Arguments apply.
• Model Arguments – empty (default), or this instance’s values for names the blocks inside it read, K=2, c=[1 2], Simulink’s InstanceParameters. Read only on a Model block. A block inside whose parameter is the name K takes this instance’s value, ahead of a global variable K; a Model block inside another takes its own first. So two instances of one file can run with two gains. The ready-made Model (Ports & Subsystems templates) is a Model block on a file of its own.

Code export

All ten targets, structurally. A subsystem generates no solve code of its own – it has no arithmetic to emit. What reaches Python, MATLAB, Java, Rust, C, C++, VHDL, Verilog, SystemVerilog and PLC Structured Text is the code of the blocks inside it, each emitted for the target as usual. A plain subsystem's blocks join the level around it. In the six software targets an atomic subsystem is packaged by its Function Packaging:

• Auto and Nonreusable function – a function of its own, called where the subsystem sits.
• Inline – no function: its blocks run where it sits.
• Reusable function – subsystems whose generated code is identical share one function, and each keeps its own parameters, signals and state in a frame of its own, so two copies with different gains still share it. A copy that cannot be framed – it reaches a data store, is referenced across its boundary, or is fed from outside the export – gets a function of its own, with a warning that says why. An atomic subsystem inside a reusable one is inlined into it.

VHDL, Verilog, SystemVerilog and PLC Structured Text keep every subsystem inlined in their one clocked process or function block.

Simulink bridge

Handled structurally, not through the block catalog. The bridge rebuilds the hierarchy on the far side rather than mapping this block to a library primitive. Two parameters cross, both ways: Treat as Atomic Unit as TreatAsAtomicUnit, and an atomic subsystem's positive Sampling Time (s) as SystemSampleTime. Simulink's Atomic Subsystem library block imports as a Subsystem with the flag on, which is all that block is. A SystemSampleTime on a plain Simulink subsystem is ignored on import, as Simulink ignores it.

A Variant Subsystem crosses as Simulink's library Variant Subsystem block, the only way a script makes one (Variant is read-only on a plain subsystem, measured). Its choices carry VariantControl, and its Variant Control Mode and Label Mode Active Choice cross by name. Simulink leaves the choices unwired and matches them to the subsystem's ports by position, so the export draws no line and no Variant Merge inside it, and the import wires the choices by position and adds the merges back.

A referenced subsystem crosses as Simulink’s Subsystem Reference, and a Model block as its Model block, each naming a file the script builds and saves first. Their library blocks import too: they arrive naming no file and with no ports, and a later set_param of ReferencedSubsystem or ModelName fills them from the file the script builds. One never named imports empty, with a note, where Simulink refuses to run it.

A Variant Model is a Variant Subsystem whose choices are Model blocks (Reference Type Model): it exports as the same library block, each choice a ModelReference with its VariantControl. Simulink’s library Variant Model imports as one, its two choices, Model (true) and Model1 (false), filled from the referenced file each one’s ModelName names when the script builds it.

A Variant Assembly Subsystem (label mode, a Variant Choices Specifier) crosses as Simulink’s library Variant Assembly Subsystem: the export builds each choice’s file and sets VariantChoicesSpecifier to them, which makes the choices on that side, then the label. The library block imports with no choice, and a set_param of its specifier makes one choice per file the script builds, named and labelled after the file.

Notes

• Grouping is structural, not numerical: the blocks inside are solved as part of the same model, and nesting one level changes no result.