Leveraging Python and FPGA for Real-Time 'Hardware in the Loop' Use Case

Leveraging Python and FPGA for Real-Time ’Hardware in the Loop’ Use Case

Development and simulation of power electronics timing’s control functions

When developing FPGA designs, the behavioural simulation of target functions aims to validate their operation and detect possible errors in their code. It often happens that the analysis time is very long because of code complexity or because of significant system timing constants. This is the case for signal synchronisation functions required in railway system power supplies. Therefore, using a “Hardware In the Loop” test bench is a good way to save time during the development phase.

Date: 24 juillet 2024

Expertises:

Evolutivité des systèmes embarqués et réseaux IoT 

Domaine: Transport & logistique 

Thème d'innovation: Edge Computing 

A propos du projet: M&SSCoT 

In railway power supplies, electrical load is distributed across several power inverters. Power delivery by each inverter must be continuously synchronised otherwise this would lead to instability and power loss of the traction system.

The M&SSCoT research project addressed this issue by developing an IT network architecture of power supplies. As part of this project, CETIC has developed a solution on FPGA for synchronising inverters.

Simulation time issue

Indeed, every inverter having its local clock must be synchronised by a common reference signal to correct phase deviation of output signals delivering power.
The correction consists of a measurement of the counting deviation of the local clock compared to the reference period supplemented by a correction of the counting error. This last aspect is more complicated to develop because the phenomenon is only detectable over long periods, several hundred milliseconds, which requires very long simulation times. In addition, the VHDL simulation must be carried out on several generator instances, which lengthens the simulation time and complicates the functional validation.

The “Hardware In the loop” simulation

Functional testing of several configurations and inverters with different local clocks is then not possible. At this stage of functional validation, behavioural simulation with traditional tools is far too restrictive. It is then necessary to implement the function to be tested in a physical component, for a real time execution which then considerably reduces the simulation time.
“Hardware In the loop” simulation addresses this issue. It consists in adding a hardware component to the simulation loop. This is a co-simulation of the function implemented on the hardware component, in our case an FPGA, and its control (configuration parameters, status monitoring, alarm, etc.) provided by software.
However, implementation may require significant additional effort. The overhead of developing the software control, additional configuration interface, must remain acceptable to justify the use of HIL simulation.

At this stage of functional verification, it is not necessary to implement the function on the final target FPGA. Indeed, it is preferable to consider the hardware solution best suited to implement the software control of the function. So SoC [1] FPGA circuits, such as AMD’s Zynq, integrating an ARM processor and FPGA logic resources are entirely suitable. As for the hardware platform, many development board references are available. However, it is necessary to be able to implement the FPGA control software without major effort. Then two additional aspects must therefore be taken into account :

Pynq, the friendly open source environment for HIL simulation

  • First, an environment that integrates a low-level layer responsible for communications between the processor and the programmable logic, is required. This is what Pynq offers. It is the AMD’s open source environment based on an Ubuntu Linux distribution enriched with FPGA control drivers and Python libraries (Hardware Overlay API and PS-PL interfaces). Pynq is recommended for rapid prototyping and thus helps to develop the test application in the form of a python script easily using Jupyter [2] Notebook.
  • Secondly, the synchronisation of inverter control implemented in Zynq programmable logic must be connected to the processor. This means that a communication interface must be added. In our case this interface will give access to the function configuration parameters, the test signals being directly routed to FPGA pins connected to test points. Vivado, the FPGA development tool, offers the Advanced eXtensible Interface (AXI) protocol as a standard interface for connecting programmable logic to the processor. The implementation is simple, in graphical form :
    Integration of the inverter control function in the SoC FPGA

The “Hardware In the loop” verification bench implementation

As for the test platform, Pynq supports several ZynQ card references, with different resources. In our case, the entry-level PynqZ2 card (around €200) is perfect. The SoC FPGA is sufficiently equipped with logic resources and the card has sufficient test pins for visualisation of the carrier signals on the oscilloscope.

The Pynq Z2 board

The verification bench is then very simple to implement. A master delivers the reference signal to 2 (or more) generators as slaves. The output signal, is displayed on oscilloscope . It is thus possible to display in real time the synchronisation of signals with different values of the configuration parameters.

The verification bench

This verification bench made it possible to validate, in a real-time environment, the principle of the synchronisation function, that is, the correction of the difference between the local clock and the reference signal. As the effect is only visible over long periods, a malfunction could have led to phase jumps or loss of synchronisation after several minutes.Thanks to simple hardware and software implementation offered by Pynq, validation time has been significantly shortened.

However, the validation only concerns the functional aspect, the SoC FPGA circuit of the PynqZ2 card not being the final circuit. There still remain the post-implementation simulation stage. But this first stage helps to clearly separate the implementation problems from the functional problems.

[1Sytem on Chip

— -

Interested in evaluating or exploring FPGA technology capabilities, especially for Edge Computing, through high level programming programming languages like Python ?
Do not hesitate to contact us (see authors contact information).
.