Support

HIL

If you develop electromechanical systems controlled by software, especially by microcontrollers, there is added value in having a real-time simulation with the same microcontroller used for production. You will be able to verify any system behavior without the risk of damaging real components, recreate any test scenario you can envision, and perform continuous testing with low power consumption and no need for direct human supervision.
Ultimately, this translates into significant cost savings and happier engineers.

The smallest achievable step is 90ns, but this can only be attained with very small circuits. Typically, it will be around 120ns for most designs.
Please refer to the examples provided.

To utilize this HIL platform, you will typically create a schematic using the KirLab Studio desktop application.
After your design is finalized, it needs to be built. This process usually takes between 10 to 15 minutes depending on circuit complexity, and is carried out on our cloud servers.
All circuit parameters can be modified without requiring a rebuild.
Once the model is built, it can be loaded onto your devices; it takes merely 5 seconds to prepare the device to run the simulation.

Yes. We have a curated motor library that will closely match behaviors observed in environments such as Matlab.

Yes. GaN transistors can be switched at frequencies as high as 2MHz, but our simulation step is likely to be more than adequate for these applications, as the PWM signals controlling the gates are sampled with a 4ns resolution.

If these time steps are not suitable for your application, you can explore the clock prescaling feature. For instance, with a prescaling factor of 8, having KirLab HIL run for 8 seconds actually signifies that it will have simulated 1 second of the designed system. You can then prescale the clock of your microcontroller with the same factor and observe the entire system interact at a fraction of real time, while maintaining the 100ns/4ns step and sampling, thus increasing the resolution in relative terms.

Yes, it requires only one digital pin on each of them, and they will operate in parallel, starting and stopping simultaneously.

Nexus

If you develop electromechanical systems controlled by software, especially by microcontrollers, creating a detailed simulation of the entire system can be extremely useful. You will be able to debug your code while it interacts with realistic physical models, as well as create complex simulations where all the system interactions are fully observable.

Nexus is specifically designed to be lightweight, making it suitable for small dt power electronics simulations. You can expect minimal variation in the execution times of your models after integrating them with Nexus.

Yes, Nexus operates on the principle of independent process synchronization, allowing you to fully leverage multi-core processors.

Typically, the speed of your simulation will be dictated by a single bottleneck process. To identify it, you can operate Nexus in profiling mode using the command line option -p; this will display statistics on the duration each process takes to complete its steps.

A global time is defined by the user for the master process. Additionally, each process maintains its own local time, over which they have full control. Upon invoking the nexus_sync API, a process will pause until the global time matches the requested time. If the specified time has already passed, the call will have no effect.
Data sharing occurs only when all processes have progressed beyond the global time.

Certainly not. While the Nexus master operates at a fixed time step, processes can run on a different one, invoking the synchronization API without any regard for the master’s step. If a process has a smaller time step, extra synchronization calls will simply be disregarded with no incurred overhead. Conversely, if a process has a larger time step, it will miss some synchronization steps.

While Python is significantly slower than a program compiled in C, the more crucial factor for a bottleneck is the synchronization step. Typically, your Python script will not need to synchronize as often as your microcontroller simulation or physical models, so it will seldom be a problem.

Still have questions? It will be a pleasure to answer them.