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#

  • 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; console handle.commentOut / handle.uncomment).
  • continuous block / discrete block — a block whose dynamics are written in continuous time (integrator, Continues/ 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.
  • 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, …), 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>, gitCommit <message>; 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 132 matrix functions of 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 Tools ▸ 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 74 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.
  • Script Runner — the window that runs a saved .iscript from <project>/scripts line by line, as if typed at the prompt.
  • 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.
  • .iscript — 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...), 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* commands 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 (.iscript, 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 .iscript.
  • 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), exported (Deploy / Deploy All) and verified (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.
  • 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-08-16 23:39, approximately commit 2e126fbf; run 2026-08-17). 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);
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 noise from the windowing layer was 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/ICoreSDK/ICoreCoder/ICoreCommandSystem/ICoreRecipeInterpreter.cpp (handle.info property table)
  • Block Configurator, Block Description — src/ICoreSDK/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/ICoreSDK/ICoreStudio/StudioObjects/PrimaryWindow/ICorePrimaryWindow.cpp (menu bar)
  • Library, My Blocks, Subsystem Navigator, Variables Space, Quick Code, Terminal, Script Runner, Solver Configuration, Deploy To Hardware, Code Export Verification — src/ICoreSDK/ICoreStudio/StudioObjects/StudioSurface/FixedPanels/LeftFixedPanel/MainMenuButtons/ICoreLeftFixedPanelMainMenuButtons.cpp (rail button texts)
  • gate — src/ICoreSDK/ICoreBlockLibrary/Blocks/Private/Subsystem_Components/ (Subsystem_Input_Gate, Subsystem_Output_Gate) and src/ICoreSDK/ICoreModel/Block/GateBlock/ICoreBlockSubsystemGate.h
  • continuous / discrete block, sink, source, scope, initial state — src/ICoreSDK/ICoreBlockLibrary/Blocks/Control_Systems/{Continues,Discrete,Sinks,Sources}/ (family folders; Initial Condition etc. are the blocks' own parameter keys)
  • sample time (Sampling Time (s)) — src/ICoreSDK/ICoreModel/SolverEnvironments/ICoreBlockSolverEnvironment.cpp
  • global sample time, solver, Solver Configuration labels — src/ICoreSDK/ICoreStudio/StudioObjects/Panels/ModelConfig/ICoreModelConfigPanel.cpp; option strings in src/ICoreSDK/ICoreSimulation/ICoreModelConfigurator.cpp; modelConfig in src/ICoreSDK/ICoreCoder/ICoreCommandSystem/ICoreModelConfigCommands.cpp
  • time series, expression, statement separator, glossary — src/ICoreSDK/ICoreCoder/ICoreCommandSystem/ICoreCommandGlossary.cpp (the syntax: and time series: sections)
  • command, handle, help — src/ICoreSDK/ICoreCoder/ICoreCommandSystem/ICoreCommandEngine.cpp; clearRecipeHandles, clearVariablesSpace, generateRecipe, timeSeriesDemo in ICoreCommandSamples.cpp beside it
  • Command History — src/ICoreSDK/ICoreStudio/StudioObjects/Panels/CommandWindow/ICoreCommandHistoryStore.cpp
  • variables space (parameter lookup by name) — src/ICoreSDK/ICoreModel/Block/BlockConfig/ICoreBlockConfigVariable.h
  • recipe verb — src/ICoreSDK/ICoreCoder/ICoreCommandSystem/ICoreRecipeInterpreter.cpp; recipe (serialization) — ICoreRecipeSerializer.cpp beside it
  • .iscript, .iproj, template, templates / useTemplate / openTemplate / saveTemplate — src/ICoreSDK/ICoreCoder/ICoreCommandSystem/TemplateLibrary/ICoreTemplateLibrary.h and ICoreTemplateCommands.cpp
  • Script Runner (<project>/scripts) — src/ICoreSDK/ICoreCoder/ICoreCommandSystem/ICoreScriptRunner.h
  • .iblock, user block, Block Wizard — src/ICoreSDK/ICoreBlockLibrary/UserBlocks/ICoreUserBlockDefinition.h; Import User Block / Export User Block in src/ICoreSDK/ICoreStudio/StudioObjects/Panels/LibraryNavigator/ICoreLibraryUserBlockEntry.cpp
  • .itest, regress — testingLabs/RegressionLab/ICoreConsoleRegressionSuite.h and the notes under testingLabs/tests/regression/
  • project (.iproj caption) — src/ICoreSDK/ICoreStudio/ExternalCommunications/ProjectNavigator/ICoreProjectNavigator.cpp; solver.ini / exportTargets.ini — src/ICoreSDK/ICoreStudio/StudioManager/Serialization/ICoreStudioSerialization.cpp
  • language / code type (the ten names) — src/ICoreSDK/ICoreCodegen/ICoreCodegen.cpp; export target fields — src/ICoreSDK/ICoreCodegen/ICoreCodeExportTarget.h
  • Deploy, Create Target, Deploy All, Verify All, verification levels — src/ICoreSDK/ICoreStudio/StudioObjects/Panels/CodeExportPanels/ICoreDeployToHardwarePanel.cpp, ICoreCodeExportVerifierView.cpp; level names in src/ICoreSDK/ICoreVerification/CodeExportVerification/ICoreCodeExportVerifier.cpp
  • export verification, residual (residualPercent), testbench, <name>_output.csv — src/ICoreSDK/ICoreVerification/CodeExportVerification/ICoreCodeExportVerifier.h
  • HDL, synthesizable, deployableCore / testbench split, <name>_tb.vhd — src/ICoreSDK/ICoreCodegen/CodeParsers/HDL/ICoreVHDLParser.h; <name>_testbench.cpp — src/ICoreSDK/ICoreCodegen/CodeParsers/Others/ICoreCppParser.h
  • Simulink bridge (Export as Simulink Script..., Import Simulink Model Script) — src/ICoreSDK/ICoreStudio/StudioObjects/StudioSurface/FixedPanels/TopFixedPanel/ICoreTopFixedPanel.cpp; the per-block mapping — src/ICoreSDK/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.