Engineers in regulated industries often do their daily work in vendor tools: Keil, IAR, Vivado, TwinCAT, DeltaV, ISPF, CANoe and others. Domain modules bring that work into the Editor. The vendor's own engine (its compiler, simulator, controller connection or host system) stays the customer's, and the module drives it; the formats are read and checked by the module's own code.
Read this first: verification states
The domain modules are pre-release. Each capability is in one of four states, and moves only on evidence:
| State | Meaning |
|---|---|
| Modelled | Built and tested against a model of the vendor engine or material we generated, such as recorded tool output, test libraries written from the vendor's headers, or a simulated server |
| Kit shipped | As modelled, and a verification kit exists that runs the exact inputs against the real vendor tool; waiting for its report |
| Verified | Run against the real vendor tool or library, with the edition, version and operating system recorded; or, for the module's own readers, checked on files a vendor tool wrote or a vendor published, against an independent implementation |
| Verified by a customer | Run by a customer's engineer on their own project |
No capability of any module is verified by a customer yet. Most vendor paths are modelled or kit shipped, and most testing so far has been on Linux. Each section below says what has and has not been run. Do not rely on a capability for production work until it is verified for your tools, versions and operating system.
How modules run
- Modules run only in a trusted workspace, because they run the tools and commands the workspace configures. In Restricted Mode they do nothing.
- Some start by themselves when the workspace holds their kind of project. Others are behind a setting, off by default, while they are completed; the Editor never turns such a setting on by itself, and for most of them offers once per workspace to do so.
- Actions on hardware ask for confirmation first. Your organisation's policy can also govern domain-module actions such as flashing, erasing, writing fuses and loading a bitstream.
Embedded (microcontroller firmware)
Turns on: by itself, in a trusted workspace that contains a firmware project (Arm CMake presets, an STM32CubeMX export, or a Keil .uvprojx, IAR .ewp or STM32CubeIDE .cproject project).
Tools it drives: Arm GCC, Arm Compiler 6 (armclang), IAR, CMake and Ninja, OpenOCD, SEGGER J-Link, ST-LINK through STM32CubeProgrammer, GDB, QEMU, clangd (installed by you), Cppcheck.
What it does: imports Keil, IAR and STM32CubeIDE projects into CMake; builds a CMake preset with a Flash and RAM size report; runs host unit tests (CTest, Unity); flashes after a confirmation; debugs with F5 without a launch.json; shows peripheral registers from the SVD, RTOS awareness, fault decoding and a serial monitor; runs static analysis with Cppcheck.
State: built and unit-tested on recorded tool output. Running a firmware image in QEMU is verified against QEMU 9.1.1. Not yet run against IAR, Keil, TRACE32, J-Link, ST-LINK or STM32CubeProgrammer, not run on Windows, and nothing has been run on a board.
Does not do: there is no clock tree editor, and agents cannot yet call these services from the Editor.
The CLI has the same firmware tools in its embedded environment. See the CLI.
HDL (FPGA and ASIC)
Turns on: the setting neuralInverse.hdl.enabled (off by default), or the command Neural Inverse: Enable HDL Environment. A workspace with an HDL project file or HDL sources gets a one-time offer. With the setting off, only syntax colouring for .v, .vh, .sv, .svh, .vhd and .vhdl runs.
Open tools it drives: Verilator, Icarus Verilog and GHDL for lint and simulation; Yosys and nextpnr for synthesis and place and route; openFPGALoader for programming.
Vendor tools it drives: AMD Vivado, Intel (Altera) Quartus, Microchip Libero SoC and Lattice Radiant, in batch mode, with their messages and reports read into the same views.
What it does: a project file (hdl.json) with sources, testbenches and targets; lint on save; testbenches in the Testing view; a waveform viewer for VCD and FST; synthesis, implementation, utilisation and timing reports; design hierarchy, schematics and constraint checks.
State: the open flow is verified on Linux. Programming with openFPGALoader is not yet run on a board. Every Vivado, Quartus, Libero and Radiant path is kit shipped or modelled, not yet run against the vendor tools. Nothing is verified on Windows.
The CLI has hdl_project, hdl_lint and hdl_sim in its hdl environment.
PLC
Turns on: the setting neuralInverse.plc.enabled (off by default), or Neural Inverse: Enable PLC Environment, which asks for workspace trust first.
Vendor tools in scope: Beckhoff TwinCAT 3 first, then CODESYS V3.5, then Siemens TIA Portal.
What is built (TwinCAT): vendor tool discovery; the TwinCAT build through an engineering host helper, with messages in Problems; the TwinCAT project reader and writer with confirmed edits; Structured Text language support; an ADS client over TCP with a read-only target connection, symbol upload, a Watch view with live values, confirmed and logged value writes, and a trace with a plot.
State: built and tested on Linux. No vendor tool has been run, no controller has been connected, and nothing has run on Windows. Verification kits for the lab are ready.
Does not do: CODESYS and TIA Portal support is not started.
DCS (distributed control systems)
Turns on: the setting neuralInverse.dcs.enabled (off by default).
Vendor tool in scope first: Emerson DeltaV, through its FHX configuration exports. For the export itself, the module runs DeltaV's database export program (DBImpExpClient.exe), found from the setting neuralInverse.dcs.paths.deltav, only in a trusted workspace.
What is built: an FHX reader and index; language features (go to definition, references, hover, outline) for .fhx files; checks in Problems, such as a tag used by more than one module; value edits that keep the rest of the file byte for byte; a semantic compare of two configurations; views of sequential function charts and the instances of a module class.
State: modelled. No DeltaV system, other vendor tool or real plant export has been used, and nothing has run on Windows. The DeltaV export has a verification kit.
Does not do: other control systems (Honeywell Experion, Yokogawa CENTUM VP, Siemens PCS 7 and PCS neo, ABB 800xA) are in scope but not built.
Energy (IEC 61850 substations)
Turns on: the setting neuralInverse.energy.enabled (off by default), with Neural Inverse: Enable Energy Environment, or from the one-time offer in a trusted workspace with SCL files or COMTRADE records.
What it does: reads, indexes, validates, checks and edits a station's SCL files; prepares CID files; analyses COMTRADE disturbance records; decodes GOOSE and Sampled Values captures; browses IEDs online over MMS, including secure connections, with a read-only commissioning view.
State: the SCL reader and checks are verified on 292 public sample files, including PCM600 and Siemens System Configurator exports. Online MMS is verified against open-source IEC 61850 servers on Linux. The COMTRADE reader and writer are checked against an independent reader, and the GOOSE and Sampled Values decoder against tshark. Everything else is modelled. No relay vendor tool or relay has been run, no customer project opened, and nothing has run on Windows.
Does not do: loading a CID file to a relay goes through the relay vendor's tool. Some planned capabilities are not built.
Mainframe (COBOL, copybooks and JCL on z/OS)
Turns on: in a trusted window, while neuralInverse.mainframe.enabled is not false. The z/OS side runs while a z/OS connection exists (a z/OSMF profile of your Zowe team configuration, or a connection added with Connect to z/OS). The project side runs while a workspace folder holds a mainframe project. COBOL and JCL colouring is always available.
Vendor path: the shop's own Enterprise COBOL and binder procedures, JES, the Db2 precompiler with BIND and the CICS translator, all driven through z/OSMF.
What it does: data sets and members as in ISPF; submitting jobs and reading the spool as in SDSF; compiling on z/OS with the shop's procedure; checking a program on z/OS without building it; mapping an abend to source; reading data through its copybook. Data sets that match neuralInverse.mainframe.readOnlyDatasets (for example PROD.**) open read-only.
Workstation path: GnuCOBOL, GDB and COBOL Check, for compiling, running, debugging and testing on your machine.
State: nothing in this module has run against a z/OS system yet. Every z/OS capability is tested against a local server shaped like z/OSMF or fixtures written to IBM's documented formats. A verification kit lets a customer run the module's requests on their own z/OS. The workstation path is verified on Linux with GnuCOBOL 3.1.2, GDB 15.1 and COBOL Check 0.2.19. Nothing is verified on Windows or macOS.
Automotive (networks, diagnostics and calibration)
Turns on: by itself, in a trusted workspace that holds automotive work: DBC, LDF, ARXML, A2L, CDD, ODX or PDX files, CAN traces, Ethernet captures, or a CANoe project.
Vendor interfaces and tools: Vector, PEAK and Kvaser CAN interfaces through each vendor's own library; python-can; Vector CANoe4SW Server Edition for CANoe test units.
What it does: DBC, LDF and ARXML as languages with checks and navigation; a CAN database view; decoding and encoding; C code generation from a database; a live bus monitor; trace files; UDS diagnostics over CAN and DoIP; measurement and calibration over XCP from the A2L.
State: DBC and ARXML reading, the codec and ODX are verified on vendor and standards-body sample files, which are demo size. XCP is verified against XCPlite. The bus monitor is verified on python-can's virtual interfaces. Vector, PEAK and Kvaser interfaces are kit shipped: their backends ran only against test libraries. Many capabilities are modelled. Tested on Linux only, with no CAN hardware and no real ECU; Windows and macOS are untested, and no customer project has been tried.
Does not do: nothing the module writes has yet been opened in the vendor tools, and there is no import of vendor keymaps, layouts or settings.
Embedded Linux
An Embedded Linux module, for Yocto Project and Wind River Linux builds, is in early development behind the setting neuralInverse.embeddedLinux.enabled (off by default). It has not been run against a real build server, and is not ready for use.