311 blocks · ten export targets ICoreSDK 1.1.31 is now available

Draw the system.
Export the code.
Verify it matches.

ICore Blocks is a block-diagram modelling environment for control, robotics and machine-learning systems. It exports any level of a model to ten languages — then compiles that code, runs it, and compares it against its own simulation, sample by sample.

Download the app Read the documentation

software targets · tolerance 0.1 % · observed agreement ≈1e-11 %

examples/Closed_Loop_Speed_Control running

Solver

Fixed-step

Exported

10 targets

Residual

1e-11 %

The loop

One model, from a blank canvas
to a program on the target.

Four steps, in order. Everything in the window also has a console equivalent, so the same model can be driven from a build.

Draw

Place blocks from the library navigator and join them with signal links. Subsystems nest beneath the top level, so a model stays readable as it grows.

Run

Set the start and stop time, the solver and the sampling. Continuous and discrete parts live in the same model — most real ones are mixed.

Read

Scopes fill in as the run advances. Results are also variables: read them in the command window, chart them, or keep them for the next run.

Export

Turn any subsystem — or the whole model — into a stand-alone program with a testbench and a build file, in the language the target needs.

Capabilities

Everything the model needs,
in one environment.

Eleven things it does that you would otherwise assemble from separate tools.

Edit → Reduce

Block reduction

Collapse a chain of linear blocks into a single state-space realization — in series, in parallel, or around a feedback loop, including unity feedback. The reduction resolves the algebraic loop the direct-feedthrough terms create, and refuses the merge when that loop is singular rather than inventing a result.

iScript · agents

AI agents that edit the diagram

The diagram language is text, and the documentation describing it is public — so an agent at your terminal can read the docs, write an .iscript, and hand it to the Studio. Script Runner runs it and stops at the first failing line; Import as ICore Recipe replays it into the level on screen; a file dropped in the templates folder appears without a restart. generateRecipe writes the current diagram back out, so the agent can read what it just built.

Simulink bridge

Import and export Simulink

Move a level across in either direction — write a model out as a Simulink script, or read one back in. Blocks carry their own Simulink catalog mapping, and the parity suite checks them against Simulink, block by block, before every release.

Ten targets

Code export

Any subsystem becomes a stand-alone program: a deployable core advancing one sample per call, a testbench, and a build file. C, C++, Rust, Python, MATLAB, Java, VHDL, Verilog, SystemVerilog and IEC 61131-3 Structured Text.

Solver

Global solvers, per-rate subsystems

Continuous or discrete. Fixed-step: Euler (RK1), Improved Euler / Heun (RK2), Bogacki–Shampine (RK3), Runge–Kutta (RK4). Variable-step: Dormand–Prince (RK45), Bogacki–Shampine (RK23). Subsystems may run at their own sampling rate, reconciled by a multi-rate tolerance you control.

Deploy

Multi-target, multi-rate deploy

A model that runs at several rates ships as several targets: each one names its own source subsystem, its own language and its own verification level, and each is generated at that subtree's rate. Targets are saved beside the project and go out together with Deploy All.

User code

Your code in the loop

Drop a C or Python block into the diagram and your own source runs inside the simulation loop, with the ports you declare on it — for the part of a model that was never going to be a block.

Console

Python and MATLAB, both

The command window has a Python REPL's feel — a bare variable prints as a Python repr, matrices print as lists — while keeping MATLAB's rules where they matter: a statement ending in ; is silent, and matrices are stored in MATLAB syntax. Type either; it understands both.

My Blocks

Block Wizard — build your own library

Make your own blocks and keep them. The wizard writes a .iblock file — identity, ports, icon, description, and a body that is either recipe text or Python — and it appears under My Blocks in the navigator, ready to import, export or hand to someone else. A definition stamps into ordinary blocks when placed, so a project that uses your library stays self-contained.

C++ SDK

Eigen, wrapped

The linear algebra is Eigen underneath — Dense, plus Polynomials, Matrix Functions, Splines, FFT, Numerical Differentiation and Levenberg–Marquardt — reached through ICoreMatrix and its neighbours. You get the performance without binding your own code to the dependency.

ICoreMath

The maths in one place

Matrices, polynomials, splines, time series and complex variables. Calculus, geometry, optimisation, signal processing and control-systems tooling — discretization, root locus, state-space and transfer-function conversion, time response — and the expression evaluator the console itself runs on.

Code export · ten targets

The same diagram, in the language the hardware speaks.

Every export has the same shape: a deployable core that advances the model by exactly one sample per call, a testbench that drives it across the simulation window, and — where the language has one — a build file so the folder compiles as it is. Storage is fixed-size and nothing is allocated at run time.

306 / 308library blocks export to all ten targets. The two exceptions are the user-code blocks, which are C-only and Python-only by definition.
Paramsstay tunable after export — change a gain without regenerating.
Solverfixed-step or discrete. A variable-step model is refused rather than silently approximated.
Each rowopens that language's page — what it writes, what it needs, and how it is checked.

Target	Deploy writes	One call advances one sample
C	`<name>_deployableCore.h/.c`, testbench, `CMakeLists.txt`	`DeployableCore_init(&core)`, then `execute_blocks(&core)`
C++	`<name>_deployableCore.hpp`, testbench, `CMakeLists.txt`	`struct DeployableCore` · `execute_blocks()`
Rust	`<name>_deployableCore.rs`, testbench, `Cargo.toml`	`execute_blocks(&mut self)`
Python	`<name>_deployableCore.py`, testbench	`execute_blocks()` · needs `numpy`
MATLAB	`<name>_deployableCore.m`, testbench	`classdef … < handle` · `core.execute_blocks()`
Java	`<name>_deployableCore.java`, testbench	`executeBlocks()`
VHDL	`icore_pkg.vhd`, entity, testbench, `Makefile` (GHDL)	one rising `clk` edge
Verilog	`icore_defs.vh`, module, testbench, `Makefile` (Icarus)	one `clk` edge
SystemVerilog	`icore_defs.svh`, module, testbench, `Makefile` (Icarus)	one `clk` edge
PLC · ST	`<name>_deployableCore.st`, testbench	`FUNCTION_BLOCK FB_<name>` — one scan

Verification

Generated code you can check, not code you have to trust.

Most code generators ask for faith. This one exports the model, builds it with a real toolchain, runs it over the simulation window, and compares every sample against the solver — then reports the residual as a percentage. Choose how strict to be: output gates only, gates and sinks, or strict across all signals.

0.1 %the tolerance for software targets, where the exported code runs the same arithmetic as the solver. Anything above noise is a real defect.
≈1e-11 %what passing runs actually measure.
≈5e-13how closely the ten languages agree with one another on the same model.
≈1e-14a discrete state-space against an exact zero-order-hold reference.

$ ICoreBlocks --console "G = tf([1],[1 1]); y = step(G, 5, 6); y.values()"

[[0], [0.632121], [0.864665], [0.950213], [0.981684], [0.993262]]

The step response of 1/(s+1) at t = 0…5 — the samples of 1 − e^−t, and the curve plotted at the top of this page. The command window is a calculator, a scripting surface and the headless interface, with 62 commands.

$ Code Engine → Code Export Verifier → Verify All

Target class	Tolerance	Observed
Software · 7 languages	0.1 %	≈1e-11 %
HDL · Q16.16	quantum 1.5e-5	quantisation-bound

The three HDL targets carry every signal in Q16.16 — about ±32768 with a step of 1.5e-5 — so their residual is set by the number format, not by the generator.

Checked against Simulink, block by block

Every block bridged to Simulink is driven with a seeded random stimulus. The identical samples go through the Simulink counterpart and through the block's own generated MATLAB, and the outputs are compared sample-by-sample against a per-block tolerance. It is a pre-release suite: a block that drifts fails the release.

Every block ships with a measurement

308 of the 311 library blocks carry a sample from a real headless run — a step, impulse, sine or ramp response, or an input-to-output table where that is the point — regenerated with the software, never drawn by hand. The same rule governs this page: every number on it is a measurement.

The library · 311 blocks, 35 families

Four domains, one signal model.

Blocks carry typed matrix signals over port-based links, so a controller, an estimator and a classifier sit in the same diagram and export through the same path. Each block's description — its ports, parameters and what it computes — is one text, shown in the library navigator, in its configuration dialog and on its documentation page.

Control systems

205

Continuous and discrete dynamics, discontinuities, lookup tables, matrix operations, trigonometry, sources and sinks, model verification.

Machine learning

Neural networks, classical models, preprocessing, feature engineering and anomaly detection — exportable to the same ten targets.

Robotics

Coordinate transforms, planar kinematics, 3-D orientation, perception filters, actuators and drivetrain.

System identification

Estimation and validation, including monitors for model fit, excitation richness and residual whiteness.

42 templates

Start from a worked example

Closed-loop control, subsystem building blocks and more ship with the application. Opening one creates a project of its own, so the template is never modified.

62 commands

Scriptable, and headless

Anything done in the window has a console equivalent, and the console runs without one: --console executes a command and exits, which is how models are driven in a build.