Compile caching

Overview

When you compile a model, Schematic Editor translates the schematic into the target files required to run the simulation. For large models, or when the same model is compiled repeatedly during development, recompiling the entire model on every change can be time consuming.

With compile caching enabled, the compiler stores the results of a successful compilation in a cache. On the next compile, it compares the current state of the model with what is stored in the cache and reuses the cached results for the parts of the model that have not changed. Only the parts of the model that were modified since the last compile are recompiled. As a result, compilation of models with small, localized changes is significantly faster.

How it works

The compiler divides the model into parts that can be cached and tracked independently. For each part it computes a signature that captures everything that affects the compiled result, such as component properties, connections, and relevant model and hardware settings. During compilation:

• If the signature of a model part matches the one stored in the cache, the previously compiled result is reused and that part is not recompiled.
• If the signature differs (the part was added, removed, or modified), that part is recompiled and its new result is written back to the cache.

The cache is populated automatically after each successful compilation, so no manual maintenance is required. If any change affects the whole model (for example, a change to a global setting that influences every part), the model is recompiled in full and the cache is refreshed.

What is cached

Compiling a model produces its target files on disk, in the model's target files directory. Compile caching is organized around the same structure.

If the model uses device markers (a multi-HIL setup), the parts of the model tied to each HIL device are compiled into a separate target files subfolder inside the main target files directory. Each of these device partitions is compiled as a separate unit and is cached and invalidated on its own, so a change affecting one device does not force the others to be recompiled.

For every device partition, a set of important target files is recorded in the cache as an integrity record. On the next compile, these files are checked against the record. In addition, the files in the main target files directory are recorded, so that changes affecting the model as a whole can be detected.

Looking at a single device partition, its components fall into two groups, and the partition can be thought of as being composed of two parts:

• the power electronics (PE) part, made up of the electrical circuit components, their properties, and their connections; and
• the signal processing (SP) part, made up of the signal processing components and their configuration.

The PE and SP parts cache is checked independently, so a change confined to one of them does not require the other to be recompiled.

What triggers a recompile

On each compile, the current state of the model is compared against the cache and only what has changed is recompiled. The scope of the recompilation depends on what was modified.

• When only the PE part of a device partition changes - for example a circuit component is added or removed, its properties are edited, or the way components are connected is changed - only the PE part of that partition is recompiled.
• When only the SP part changes, only the SP part of that partition is recompiled. The same applies to a change in the definition of a C-function block, or in a namespace variable that such a block refers to, since these are part of the tracked state.
• When a change affects both parts, the whole device partition is recompiled.

The recorded integrity files are also checked, independently of any change to the schematic:

• If any of the recorded target files of a device partition are changed or missing, that device partition is recompiled.
• If files in the main target files directory are changed or missing, a full model compile is performed.

Finally, some changes affect a device as a whole and force a full recompile of that device, rebuilding both its PE and SP parts:

• Changing the target hardware - the selected HIL device or its configuration.
• Changing model settings or global compile settings, such as the simulation method, simulation time step, solver and offline-simulation settings, numeric precision, CPU optimization, signal processing execution rates, or the C-code export options.
• Changing device marker overrides or other device-level settings.
• Upgrading or otherwise changing the Typhoon HIL software version. Cached results are tied to the version that produced them and are never reused across versions.

The cache is also treated as invalid - and the affected part recompiled from scratch - when there is no cached data to reuse, for example the first time a model is compiled or after an interrupted compilation. Disabling compile caching has the same effect: every compilation is performed in full.

Forcing a full compile

Because compile caching reuses previously compiled results, in rare cases you may suspect that the cache has become invalid and no longer reflects the current model (for example, after an unexpected error or an interrupted compilation). In that case you can discard the cache and force the next compilation to be performed in full.

Enabling compile caching

Compile caching is controlled by a global Typhoon HIL Control Center setting and is turned off by default. To enable it:

1. In the Typhoon HIL Control Center, open the Typhoon HIL Settings dialog by clicking the settings button in the upper right corner (see Figure 8).
2. Locate the Schematic Editor option Speed up model compilation, via caching and enable it.
3. Compile your model as usual. Subsequent compilations of the same model will reuse cached results for the unchanged parts.

The setting applies to all models compiled from Schematic Editor. Because the feature is in BETA, it is recommended to keep it enabled only while you evaluate it, and to perform a full compile if you observe unexpected results.