Reference › User glossary — the vocabulary of using ICoreBlocks
kind: reference#glossary#vocabulary#user#terms#block#port#link#signal#recipe#template#console#export

User glossary — the vocabulary of using ICoreBlocks#

The words you meet in the ICoreBlocks window, its console and its files, each defined by what it means when you use the product. Every term is checked against the label, command or file that uses it (the list at the end names one place per term). Where a term has its own page, the entry says so and stops — this page defines, it does not explain. Terms are alphabetical inside five groups: the diagram, running a model, the console, files and projects, export and Simulink.

The diagram#

  • algebraic loop — a feedback loop in which every block has direct feedthrough (below), so no block's output can be computed before the others'. The run refuses to start and names the loop; break it with a Unit Delay, an Integrator, a strictly proper transfer function or an Algebraic Constraint block. See Sample time and loops — how the simulator paces a diagram.
  • block — one unit of computation you drag from the Library onto the canvas: it has input ports, output ports and a set of parameters, and its full name is a slash path such as Control_Systems/Base_Blocks/Gain. Every block in the library has its own page under Block catalog — every library block.
  • Block Configurator — the dialog that opens on a block and edits its parameters (Ok / Apply / Cancel); the same values the console reads with handle.listConfig and writes with handle.setConfig(name, value).
  • Block Description — the block's own reference card (the same text as its page under Block catalog — every library block): what it computes, its ports, its parameters, which export targets it supports and how it maps to Simulink. Opened from the block; printed by handle.info.
  • canvas — the drawing surface of a tab where one diagram level is laid out. Coordinates in console verbs (move, setCorners) are relative to the origin anchor, with +y up.
  • canvas area — a titled, coloured rectangle grouping part of a diagram (area(), setTitle, setColor). Decoration only: it does not change what runs.
  • comment out — exclude a block from the run without deleting it (Edit ▸ Comment Out, Ctrl+Shift+X, which uncomments a selection that is all commented out already; console handle.commentOut / handle.uncomment).
  • continuous block / discrete block — a block whose dynamics are written in continuous time (integrator, Continuous/ family: State Space, Transfer Function, PID …) versus one that advances only at its sample time (Discrete/ family: Unit Delay, Discrete Transfer Function, Zero-Order Hold …). How the solver treats each is on Solver mathematics — the forms, the discretizations and the stepping scheme and Sample time and loops — how the simulator paces a diagram.
  • diagram — everything on one canvas: the blocks, their links and the canvas decorations of one subsystem level. Home is the top level of every project.
  • direct feedthrough — a block has it when its output at an instant depends on its input at that same instant (a Gain, a Sum, a proper Transfer Function); it does not when the output is known from the block's state alone (an Integrator, a strictly proper Transfer Function, a Unit Delay, a Memory). Every feedback loop is opened at a block without it; a loop made only of blocks with it is an algebraic loop — u = f(u) at one instant, which the simulator refuses with Algebraic loop detected: … naming the blocks around it. See Sample time and loops — how the simulator paces a diagram.
  • gate (Subsystem_Input_Gate, Subsystem_Output_Gate) — the block inside a subsystem that carries a signal across the subsystem boundary; each gate you place becomes a port on the subsystem's own block outside. handle.info reports isGate: true for one.
  • initial state — the value a stateful block starts from at Start Time; the parameter is spelled per block (Initial Condition, Initial Output, Initial State Vector, Initial States …). Its effect on the first samples is on Sample time and loops — how the simulator paces a diagram.
  • Library (Library Navigator) — the left-rail panel that lists every block family, My Blocks and the Templates; search it, then drag onto the canvas. Families are those of Block catalog — every library block.
  • link — the wire from one output port to one or more input ports. A link fans out through branches; deleting its root branch deletes the whole link (console connect, handle.disconnect).
  • port — a block's connection point, input or output, numbered from 0 (Gain<0> in a recipe means port 0 of the block bound to Gain). A port carries one signal of a fixed size and may have a description label.
  • properties (handle.info / handle.get(property)) — the read-only sheet of a block: name, path, size, rotation, port list, isSubsystem, isGate, isScope, isSink, commentedOut.
  • scope — a block that charts what it receives during the run (Scope, Floating_Scope, XY_Graph); its chart is reachable from the console as handle.chart().
  • signal — the value travelling on a link at each sample: a scalar or a matrix of a fixed size, typed ICoreDouble in the port list. A block's description states which sizes it accepts.
  • sink — a block that consumes a signal and produces none (Sinks/ family: Display, Signal_Recorder, To_File, Terminator …). Sinks and output gates are what export verification records — see Exporting code — the ten targets, what each produces, and what verification proves.
  • source — a block with no input that generates a signal (Sources/ family: Constant, Step, Sine_Wave, Clock, From_Workspace …).
  • subsystem — a block that contains a diagram of its own; double-click enters it, Edit ▸ Move To New Subsystem (Ctrl+G) folds a selection into one, and the Subsystem Navigator lists the levels. Its ports are made by the gates inside it.
  • Subsystem Navigator — the left-rail tree of subsystem levels (Home and everything under it) used to jump between diagram levels.
  • tree node — a subsystem level as the console addresses it: a slash path such as Home/Plant (generateRecipe Home/Plant, clearDiagram(parent)). Every subsystem block owns one.
  • user block — a block of your own, saved by the Block Wizard as a .iblock file and listed under My Blocks. It is a stamp: placing it creates ordinary blocks (a subsystem, or a Python_Code block), so a project stays self-contained.

Running a model#

  • Build Project (Ctrl+D) — resolve every block's parameters, check sizes and ordering, and prepare the model to run; errors land in Run Diagnosis. Run Simulation (Ctrl+T) builds and runs; Step, Pause, Stop and Run In Debug Mode sit beside it in the Run menu.
  • global sample time (Global Sampling Time (sec), console globalSamplingTime, default 0.1) — the rate every block with a non-positive Sampling Time (s) inherits. See Sample time and loops — how the simulator paces a diagram.
  • Run Diagnosis — the panel collecting warnings and errors from a build or run (Expand All, Copy All); the first place to look when a run stops — see Troubleshooting — the messages you will meet and what to do.
  • sample time (Sampling Time (s) on every block) — how often the block advances: <= 0 inherits the global sample time (or the surrounding rate), > 0 runs the block at that period. Multi-rate diagrams and the one-sample delay of a loop are on Sample time and loops — how the simulator paces a diagram.
  • Solver Configuration (Ctrl+E) — the panel holding the run's settings: Simulation Time (start/stop, Infinite Simulations), Solver Type (Continuous / Discrete), Stepping (Fixed-step | Runge-Kutta | RK4, Variable-step | Dormand-Prince | RK45, Variable-step | TR-BDF2 (implicit) | TRBDF2, …), Coupling (Joint, the default — every continuous state integrated together — or Per-block), Global Discretization Method (Zero-order Hold, Tustin), tolerances and step bounds. The console prints the same table with modelConfig.
  • solver — the numerical method that integrates the continuous blocks between samples: a fixed-step or variable-step Runge–Kutta family chosen under Stepping. What each method does and costs is on Solver mathematics — the forms, the discretizations and the stepping scheme; its numerical limits on Numerics — what the solver will and will not do.
  • time series — a recorded signal: N time stamps against an N×M value block, produced by a Signal_Recorder during a run or built with timeSeries(t, v); open it with .time() / .values(), chart it with plot(s).

The console#

  • command (registered command) — a named action typed at the prompt, e.g. templates, modelConfig, saveTemplate <name>; help lists them and glossary prints everything the console understands. Roster: Command glossary — console commands, verbs, functions. The console itself: The command window — the command engine for a user.
  • Command History — the log of lines you typed, recalled with the Up arrow across sessions (View ▸ Loggers ▸ Command History; clearCommandHistory forgets it).
  • expression (matrix expression) — a line the console evaluates and prints: matrices in MATLAB-like brackets ([1 2; 3 4]), operators + - * / .* ./ ', and functions such as inv, eig, expm, tf, ss — the matrix functions listed on Command glossary — console commands, verbs, functions. Also accepted in any block parameter field.
  • handle — a console name bound to a diagram object by a recipe verb: g = block(Gain) binds g to the new block, l = connect(...) to a link branch, c = plot(...) to a chart. Handles are cleared by clearRecipeHandles.
  • Quick Code — the console panel (left rail and Code Engine ▸ Quick Code): a >>> prompt with the output history above it. See The command window — the command engine for a user.
  • recipe verb — one of the diagram-building calls a recipe or the console can use: block, subsystem, connect, handle.setConfig, handle.move, area, textbox … Roster: Command glossary — console commands, verbs, functions; how they compose: Recipes and templates — recording, replaying and reusing diagrams.
  • ICore Script IDE — the window where the .icore scripts in <project>/scripts are written in tabs, run, debugged (breakpoints, stepping, watches) and fixed. Called the Script Runner before 2026-09-23.
  • statement separator — ; separates statements on one line and, at the end of a statement, silences its output (errors still print). a = 1; b = 2 runs both quietly.
  • Terminal — a real shell of your operating system inside the window (left rail Terminal), distinct from the console: it does not understand recipe verbs.
  • variables space — the workspace of named values the console declares (K = [1 2; 3 4]) and blocks read: a parameter set to a bare name (Gain Value = K) is looked up here at build. Variables Space on the left rail shows it; clearVariablesSpace empties it; a project's recipe saves it.

Files and projects#

  • .iblock — a user block definition written by the Block Wizard: identity and ports, an icon, a description, and a body that is either recipe text (a composite) or Python source. Import User Block / Export User Block in the Library move them between machines.
  • .iproj — a project file: the recipe that rebuilds the whole diagram tree together with the variables space. Also the form of a bundle template.
  • .icore (named .iscript until 2026-09-22) — a recipe file for one subsystem level: the output of Export as ICore Recipe..., of saveTemplate, and of generateRecipe; also a console script under <project>/scripts. See Recipes and templates — recording, replaying and reusing diagrams.
  • .itest — a console regression suite: one line of console input per case with the output it must produce, run by the regress command. Only relevant if you extend the console.
  • project — a folder holding a .iproj file of the same name (the caption in Open Project...; File > New Project... makes one), beside it solver.ini (the Solver Configuration), exportTargets.ini (the export targets), scripts/, CodeExportTests/ and whatever the exports write. Save Project, Reload From Disk and the Git panel act on the folder.
  • recipe — the text of commands that rebuilds a diagram from nothing (Gain = block(...); Gain.setConfig(...); l = connect(...)). Projects, templates, undo/redo and Simulink import/export are all recipes. See Recipes and templates — recording, replaying and reusing diagrams.
  • template — a ready-made diagram shipped with the app or saved by you: a subsystem template (.icore, inserted with useTemplate <id>) or a bundle (.iproj, opened with openTemplate <id>); templates lists the 49 shipped ones (2026-08-17). Roster: Template catalog — every .icore.

Your licence and this machine#

These are new in the window as of 2026-08-19. With no licence resolved — the sign-in dialog dismissed, or signed out — the application still opens and your models open, edit and save, but simulation, code export and the other licensed features refuse with a sentence until you sign in, and the licence banner says so.

  • Account (the Account button on the toolbar, or Help ▸ Account…) — who is signed in, what the licence covers, and this machine's seat. Everything else about the account — other machines, seats, invoices, organisation administration — is on the web portal, which the panel links to.
  • grace — the state a licence enters when its validity lapses and the licensing service could not be reached: the application stays fully functional for thirty days while the banner counts them down. A network failure never blocks a paid user, so grace is not an error and is not something to act on urgently.
  • expired — grace used up, or a licence the service was reached and said no to. Models still open and save; simulation and code export refuse with a sentence. A licence problem never destroys or refuses to open your work. See Troubleshooting — the messages you will meet and what to do.
  • licence banner — the non-modal strip just under the editor's top panel that appears only in grace (with the days remaining), when expired, or with no licence resolved, and offers a way to the Account panel. It is not a notification: in grace it can be dismissed for the session, but an expired or missing licence keeps it up, because it is the explanation for why Run does nothing; it goes away when the licence does.
  • seat — this machine's claim on the licence. Signing out releases it, which frees it for another machine — a machine nobody is signed in on does not hold a seat. Sign out from the Account panel; the app then asks you to sign in, and you can sign in as a different account.
  • update banner — a strip just under the editor's top panel (below the licence banner when both show), shown when a newer build is available to install (Details…, or Not now for this session).
  • Check for Updates… — in the Help menu: asks for a newer build right away instead of waiting for the daily check, and always answers. What a Mac copy in /Applications does with the answer is in ICoreBlocks — the user manual, under Update banner.
  • maintenance / version ceiling — a perpetual licence owns every build up to a stated version, forever. Past it the updater says an update is available with a maintenance plan rather than reporting an error, because owning what you bought is a healthy state, not a fault.
  • watermark — some licences add a comment line or two to the header of every generated file, stating the licence's commercial-use terms. It is comment text: the generated program is unchanged and still compiles everywhere.
  • Code Export Verifier — the panel and headless flow that runs a target's exported code on a recorded pulse-train input, runs the same diagram in the app, and reports the residual. Verification levels: None, Output Gates Only, Output Gates and Sink Blocks, Strict - All Signals. See Exporting code — the ten targets, what each produces, and what verification proves.
  • Deploy (Deploy To Hardware, Deploy Targets) — the panel where export targets are created (Create Target) and exported (Deploy / Deploy All); they are verified from the Code Export Verification window (Verify All).
  • export target — one configured code export: Target Name, Target Path, Source Subsystem, a language, and a Verification level. Deploying it writes the generated code for that subsystem to that path.
  • export verification / residual — the measured difference between the exported code's output and the app's own run, expressed as a percentage of the simulated peak (residualPercent); a target passes when it meets its threshold. See Exporting code — the ten targets, what each produces, and what verification proves.
  • HDL — the three hardware targets VHDL, Verilog, System Verilog. Their code is synthesizable: fixed-point arithmetic, one clocked pass per sample, and a deployableCore / testbench split, so it can be placed on an FPGA rather than only simulated. See Exporting code — the ten targets, what each produces, and what verification proves and Numerics — what the solver will and will not do.
  • language / code type — one of the ten export languages: Python, MATLAB, Java, Rust, C, C++, VHDL, Verilog, System Verilog, PLC - ST. A block's description lists which of them it supports.
  • parity — the property that a block or diagram computes what its Simulink counterpart computes on the same input, sample by sample. A block's description says whether it has a Simulink mapping; per-block parity is certified by the project's own MATLAB testbenches, not something you run from the app.
  • Simulink bridge — the import/export pair on the top bar: Export as Simulink Script... writes a MATLAB script (new_system, add_block, set_param, add_line) that rebuilds your diagram in Simulink; Import Simulink Model Script reads such a recipe.m back. Blocks with no Simulink equivalent are reported and skipped, never guessed at; the mapping is stated on each block's page. The solver configuration crosses too (since 2026-09-03): the script sets the model's StartTime, StopTime, SolverType, Solver and FixedStep or MaxStep/MinStep/InitialStep/RelTol/AbsTol from your Solver Configuration (RK1–RK4 as ode1–ode4, BE1 as ode1be, RK45/RK23 as ode45/ode23, TRBDF2 as ode23tb, the Discrete solver as FixedStepDiscrete; TR2 as ode14x, the nearest) and carries every setting as a % ICORE-CONFIG: comment, and an import reads them back — a script Simulink Copilot wrote from a real model configures the solver from its set_param(model, …) alone, with any solver ICoreBlocks has no method for read as the nearest one and reported. The import dialog's prompt asks Copilot to include that call.
  • testbench — the runnable driver generated next to exported code (<name>_tb.vhd for VHDL, <name>_testbench.cpp for C++, and likewise per language) that steps the core; in a verification run it feeds the recorded input and writes <name>_output.csv for the verifier to compare.

The vocabulary in action#

One headless session (binary built 2026-09-25 23:58, approximately commit 1dac24c57; run 2026-09-26). A value is declared into the variables space, a subsystem is created and renamed to Plant, two blocks are placed inside it and linked, then the recipe of that tree node is printed. Note that Gain Value was set to the name K, and the recipe keeps the name — the block resolves it from the variables space at build.

$ ICoreBlocks --console "K = 2.5; s = subsystem(); s.rename(Plant); g = block(Gain, s); g.setConfig(Gain Value, K); c = block(Constant, s); connect(c<0>, g<0>); generateRecipe Home/Plant"
Software Initialized
Gain = block(Control_Systems/Base_Blocks/Gain, ICore Blocks/Home/Plant);
Gain.rename(Gain);
Gain.move(0, 0);
Gain.resize(70, 70);
Gain.setConfig(Sampling Time (s), -1);
Gain.setConfig(Gain Value, K);
Gain.setConfig(Multiplication Type, Element-wise (K.*u)%~%Matrix (K*u)%~%Matrix (u*K)%~%Matrix (K*u) (u vector)~~Element-wise (K.*u));
Constant = block(Control_Systems/Sources/Constant, ICore Blocks/Home/Plant);
Constant.rename(Constant);
Constant.move(0, 0);
Constant.resize(70, 70);
Constant.setConfig(Sampling Time (s), -1);
Constant.setConfig(Constant Value, 1);
Constant.setConfig(Output data type, ICoreDouble%~%ICoreSingle%~%ICoreBool%~%ICoreInt8%~%ICoreUInt8%~%ICoreInt16%~%ICoreUInt16%~%ICoreInt32%~%ICoreUInt32%~%ICoreInt64%~%ICoreUInt64~~ICoreDouble);
l = connect(Constant<0>, Gain<0>);
l.rename("ICoreDouble");
l.setCorners((65, -35), (95, -35), (95, 25), (-25, 25), (-25, -35), (5, -35));

The same session, ending on a variable read and on a block's parameter list — every statement before the last ends in ; and is therefore silent:

$ ICoreBlocks --console "K = [1 2; 3 4]; g = block(Control_Systems/Base_Blocks/Gain); g.setConfig(Gain Value, K); K"
Software Initialized
K = [[1, 2], [3, 4]]  # Matrix of Double

$ ICoreBlocks --console "K = [1 2; 3 4]; g = block(Control_Systems/Base_Blocks/Gain); g.setConfig(Gain Value, K); g.listConfig"
Software Initialized
g config:
  Sampling Time (s) = -1
  Gain Value = K
  Multiplication Type = Element-wise (K.*u)%~%Matrix (K*u)%~%Matrix (u*K)%~%Matrix (K*u) (u vector)~~Element-wise (K.*u)

(Startup lines were stripped; everything else is verbatim.)

Where each term appears#

One file per term, the place its label or command is spelled — evidence, not reading material.

<small>

  • block, port, link, properties, isGate / isSink / isScope — src/ICoreBlocks/ICoreCoder/ICoreCommandSystem/ICoreRecipeInterpreter.cpp (handle.info property table)
  • Block Configurator, Block Description — src/ICoreBlocks/ICoreStudio/StudioObjects/ICoreModelViews/Block/BlockConfigUI/ConfigDialog/ICoreBlockConfigView_ConfigDialog.cpp
  • canvas, canvas area, comment out, subsystem (Move To New Subsystem), Build Project, Run Simulation, Run Diagnosis, Loggers — src/ICoreBlocks/ICoreStudio/StudioObjects/PrimaryWindow/ICorePrimaryWindow.cpp (menu bar)
  • Library, My Blocks, Subsystem Navigator, Variables Space, Quick Code, Terminal, Script IDE, Solver Configuration, Deploy To Hardware, Code Export Verification — src/ICoreBlocks/ICoreStudio/StudioObjects/StudioSurface/FixedPanels/LeftFixedPanel/MainMenuButtons/ICoreLeftFixedPanelMainMenuButtons.cpp (rail button texts)
  • gate — src/ICoreBlocks/ICoreBlockLibrary/Blocks/Private/Subsystem_Components/ (Subsystem_Input_Gate, Subsystem_Output_Gate) and src/ICoreBlocks/ICoreModel/Block/GateBlock/ICoreBlockSubsystemGate.h
  • continuous / discrete block, sink, source, scope, initial state — src/ICoreBlocks/ICoreBlockLibrary/Blocks/Control_Systems/{Continuous,Discrete,Sinks,Sources}/ (family folders; Initial Condition etc. are the blocks' own parameter keys)
  • sample time (Sampling Time (s)) — src/ICoreBlocks/ICoreModel/SolverEnvironments/ICoreBlockSolverEnvironment.cpp
  • global sample time, solver, Solver Configuration labels — src/ICoreBlocks/ICoreStudio/StudioObjects/Panels/ModelConfig/ICoreModelConfigPanel.cpp; option strings in src/ICoreBlocks/ICoreSimulation/ICoreModelConfigurator.cpp; modelConfig in src/ICoreBlocks/ICoreCoder/ICoreCommandSystem/ICoreModelConfigCommands.cpp
  • time series, expression, statement separator, glossary — src/ICoreBlocks/ICoreCoder/ICoreCommandSystem/ICoreCommandGlossary.cpp (the syntax: and time series: sections)
  • command, handle, help — src/ICoreBlocks/ICoreCoder/ICoreCommandSystem/ICoreCommandEngine.cpp; clearRecipeHandles, clearVariablesSpace, generateRecipe, timeSeriesDemo in ICoreCommandSamples.cpp beside it
  • Command History — src/ICoreBlocks/ICoreStudio/StudioObjects/Panels/CommandWindow/ICoreCommandHistoryStore.cpp
  • variables space (parameter lookup by name) — src/ICoreBlocks/ICoreModel/Block/BlockConfig/ICoreBlockConfigVariable.h
  • recipe verb — src/ICoreBlocks/ICoreCoder/ICoreCommandSystem/ICoreRecipeInterpreter.cpp; recipe (serialization) — ICoreRecipeSerializer.cpp beside it
  • .icore, .iproj, template, templates / useTemplate / openTemplate / saveTemplate — src/ICoreBlocks/ICoreCoder/ICoreCommandSystem/TemplateLibrary/ICoreTemplateLibrary.h and ICoreTemplateCommands.cpp
  • ICore Script IDE (<project>/scripts) — src/ICoreBlocks/ICoreCoder/ICoreCommandSystem/ICoreScriptRunner.h
  • .iblock, user block, Block Wizard — src/ICoreBlocks/ICoreBlockLibrary/UserBlocks/ICoreUserBlockDefinition.h; Import User Block / Export User Block in src/ICoreBlocks/ICoreStudio/StudioObjects/Panels/LibraryNavigator/ICoreLibraryUserBlockEntry.cpp
  • .itest, regress — testingLabs/RegressionLab/ICoreConsoleRegressionSuite.h and the notes under testingLabs/tests/regression/
  • project (.iproj caption) — src/ICoreBlocks/ICoreStudio/ExternalCommunications/ProjectNavigator/ICoreProjectNavigator.cpp; solver.ini / exportTargets.ini — src/ICoreBlocks/ICoreStudio/StudioManager/Serialization/ICoreStudioSerialization.cpp
  • language / code type (the ten names) — src/ICoreBlocks/ICoreCodegen/ICoreCodegen.cpp; export target fields — src/ICoreBlocks/ICoreCodegen/ICoreCodeExportTarget.h
  • Deploy, Create Target, Deploy All, Verify All, verification levels — src/ICoreBlocks/ICoreStudio/StudioObjects/Panels/CodeExportPanels/ICoreDeployToHardwarePanel.cpp, ICoreCodeExportVerifierView.cpp; level names in src/ICoreBlocks/ICoreVerification/CodeExportVerification/ICoreCodeExportVerifier.cpp
  • export verification, residual (residualPercent), testbench, <name>_output.csv — src/ICoreBlocks/ICoreVerification/CodeExportVerification/ICoreCodeExportVerifier.h
  • HDL, synthesizable, deployableCore / testbench split, <name>_tb.vhd — src/ICoreBlocks/ICoreCodegen/CodeParsers/HDL/ICoreVHDLParser.h; <name>_testbench.cpp — src/ICoreBlocks/ICoreCodegen/CodeParsers/Others/ICoreCppParser.h
  • Simulink bridge (Export as Simulink Script..., Import Simulink Model Script) — src/ICoreBlocks/ICoreStudio/StudioObjects/StudioSurface/FixedPanels/TopFixedPanel/ICoreTopFixedPanel.cpp; the per-block mapping — src/ICoreBlocks/ICoreCoder/ICoreCommandSystem/SimulinkBridge/ICoreSimulinkBlockCatalog.h
  • parity — the notes under testingLabs/tests/simulink_parity/

</small>

For contributors#

The contributor glossary defines the same objects by the header they live in, together with the tree's own vocabulary; the module pages on the model, the simulator, the coder and the code generators state the invariants behind these definitions.