Title: OP5600 with RT-LAB 2022.1 and eHS Solver License – FPGA Compatibility and Model Partitioning

Q&A
, , ,
1

Hello everyone,

I am working with an OPAL-RT OP5600 HIL simulator, RT-LAB 2022.1, and an eHS Solver license. I would like to use the eHS SE S-Function Driver to simulate a bidirectional electric vehicle battery charger connected to an electrical grid.

My system consists of the following components:

  • Battery model
  • DC/DC converter
  • DC-link capacitor
  • DC/AC converter
  • filter
  • IEEE 9-bus electrical network

I would appreciate your help with two questions:

1. FPGA compatibility

How can I verify whether my OP5600 configuration supports FPGA-based eHS simulation with RT-LAB 2022.1 and the eHS SE S-Function Driver? Which FPGA hardware, firmware, and software compatibility requirements should I check?

2. Model partitioning between eHS SE and Simulink

What is the recommended way to partition my system?

  • Option A: Put only the power converters in eHS SE, while keeping the battery model, and IEEE 9-bus network in Simulink/RT-LAB.
  • Option B: Put the battery, DC/DC converter, DC link, DC/AC converter, filter, and electrical network entirely in eHS SE, while implementing the controllers in Simulink.

Which approach would you recommend for a real-time HIL simulation, considering computational resources, simulation time step, and solver compatibility?

Thank you in advance for your help and suggestions.

2

Hi @CosmicNewt51,

  1. FPGA Compatibility & Verification Checklist
    To confirm that your OP5600 and RT-LAB 2022.1 setup supports FPGA-based eHS simulation with the eHS SE S-Function Driver, you can check the following items:

(A) Software Compatibility:

Ensure your MATLAB/Simulink version matches the supported versions for RT-LAB 2022.1 (typically MATLAB R2020b, R2021a, or R2021b).

Verify your eHS solver version is compatible with RT-LAB 2022.1. The eHS SE S-Function driver workflow is supported in eHS v3.1 and later. Refer to the RT-LAB: Software Compatibility
matrix for details.

If using custom bitstreams or RT-XSG, check that RT-XSG and the Xilinx toolchain (Vivado/ISE) align with RT-LAB 2022.1.

(B) FPGA Hardware & Firmware (Bitstream):

Check the FPGA board installed inside your OP5600 (commonly a Xilinx Virtex-6, Virtex-7, Kintex-7, or OP5142).

Ensure the active FPGA firmware (.bin or .tar.gz) is a standard OPAL-RT bitstream configured with the eHS IP core and compatible with eHS SE.

(C) License Verification:

Open the RT-LAB License Manager (or check your target properties) to confirm an active eHS license feature.

Check your licensed eHS matrix tier (eHSx32, eHSx64, or eHSx128), as this sets the maximum number of switches, passive components (L, C), and electrical nodes supported on the FPGA.

  1. Model Partitioning Strategy

Your ideas for the strategies are very interesting. I’d love to hear what approach you actually end up with. Here are some of my recommendation.

Option A: Hybrid Partitioning (Recommended)
FPGA (eHS SE): Fast power converters (DC/DC converter, DC-link capacitor, DC/AC converter, and output filter).

CPU (Simulink / RT-LAB): Battery model, IEEE 9-bus electrical network, and controller algorithms.

Key Advantages:

Optimized Time Steps: High-frequency switching elements run at sub-microsecond time steps (~200–500 ns) on the FPGA, preventing PWM distortion and numerical instability.

Resource Efficiency: Keeps the FPGA footprint low, easily fitting within standard eHSx32 or eHSx64 cores.

Non-Linear Support: Slow-dynamics models like the battery (SOC lookup tables, thermal/aging equations) and large networks run comfortably on CPU cores at standard time steps (20–50 µs) using Simscape / ARTEMiS.

Consideration: Requires a CPU–FPGA decoupling interface (controlled voltage/current sources) which introduces a 1-step communication delay between the grid and converter interfaces.

Option B: All-in-eHS Electrical System
FPGA (eHS SE): Entire electrical circuit (Battery + DC/DC + DC link + DC/AC + Filter + IEEE 9-bus grid).

CPU (Simulink / RT-LAB): Control loops and high-level management only.

Key Advantages:

Zero Interface Delay: Eliminates decoupling delays between the converters, battery, and grid.

Considerations:

Matrix Limits: The IEEE 9-bus grid and passive components significantly increase branch/node counts, likely requiring an eHSx64 or eHSx128 license.

Model Constraints: The battery and grid components must be modeled using linear or piecewise-linear representations compatible with eHS.

Summary & Recommendation

For an EV charger connected to a 9-bus network, I would recommend Option A (Hybrid Partitioning) as it is the industry-standard approach for real-time HIL:

  1. Put the switching converters and filter in eHS SE on the FPGA for sub-microsecond precision.
  2. Put the battery model, 9-bus grid, and controls in Simulink on the CPU to handle complex dynamics and preserve FPGA resources.
3

@CosmicNewt51

Hi, this sounds really interesting!

I only have a little experience with eHS, but I’d love to hear more about the model you are trying to build and what you want to test with it. Are you connecting a physical controller, or mainly validating the charger/grid behaviour first?

I was also wondering about the size of the model. When I was using eHS, I remember that the FPGA solver had practical limits depending on the number/configuration of switching devices and the required time step. Would putting the full charger, battery and 9-bus network into eHS risk making the model too large for the FPGA?

Have you already tried either option, even with a simplified version of the model? If so, which one did you test, and were the simulation results and real-time performance okay? I’d be really interested to hear what worked best for you!