“Electronic analog controllers can be made from a solid-state or tube amplifier, a capacitor and a resistor. Electronic analog PID control loops were often found within more complex electronic systems, for example, the head positioning of a disk drive, the power conditioning of a power supply, or even the movement-detection circuit of a modern seismometer. Nowadays, electronic controllers have largely been replaced by digital controllers implemented with microcontrollers or FPGAs.” (Wikipedia)
This blog post explains the typical design workflow for FPGA-based digital control systems and covers some of the FPGA programming tools. The simulation capabilities provided by such tools can be highly beneficial when fine-tuning a control algorithm. We also examine ways in which software simulations and hardware implementations can co-exist and how FPGAs can be used to accelerate simulation.
To demonstrate our design workflow, we’ll use the following example: a mono-variable system that provides an output, y(t), when excited by a given input signal, u(t). Internal system dynamics cause the y(t) output to differ from the input signal. An error signal, e(t), is obtained by subtracting the actual output from the desired output, r(t) (also called a reference signal or set point).
Feeding the system with the proper input signal in the hope of collecting a desired output can be challenging. If the system is an electrical analog system, the following figure shows how the system can be excited u(t) with a given input signal and how the error e(t) induced by the system can be measured.
The addition of a feedback controller at the input of the system can be used to compensate for system effects in order to obtain the desired output. The feedback controller is responsible for providing the system with a proper input signal, u(t). The controller will typically implement an algorithm that computes the input signal u(t) in a way that minimizes the difference between the desired output and the measured output (in other words, minimize the e(t) error signal).
Like with any other design workflow, designing an FPGA-based digital controller is typically an iterative process and requires simulation and tuning prior to hardware implementation. Software simulation engines like Matlab Simulink let us model the system along with our control algorithm on a digital computer to see how both will behave.
In the following figure, the system is simulated with the Simulink block set, whereas the proposed Controller is simulated with the Xilinx System Generator block set. The System Generator block set allows a seamless hardware synthesis of the algorithm being developed, which means an FPGA netlist can be generated by simply compiling the model. When simulated in the Simulink environment, the result is a “bit true” and “cycle true” simulation of the controller. Even in the simulation phase of the design workflow, we will typically choose to implement the controller using the System Generator block set instead of the Simulink block set because we know it will lead to direct and seamless hardware implementation when targeting the FPGA. Using a pure simulation in the early stages of controller design lets us start working right away, as the real system doesn’t need to be available.
To validate the control algorithm’s performance on the real system, ADCs and DACs are required to convert the signals between the analog and discrete domains. In this example, a mono-variable single-input single-output (SISO) system is considered to keep things simple, whereas in real applications, a multi-variable multiple-input multiple-output (MIMO) system is much more common. In these cases, the number of DACs must match the system’s inputs, and the number of ADCs must match the system’s outputs.
Systems like the Nutaq PicoDigitizer are offered in a wide variety of configurations where the number of DACs and ADCs can be chosen based on the system requirements. The Nutaq Model-Based Design Kit (MBDK) comes with block set that can be complied to target the PicoDigitizer‘s Virtex-6 FPGA. These cores, once placed on the FPGA, will link the ADC/DAC signals to the FPGA user logic. The following figure shows four cores, each of them corresponding to an ADC and a DAC of a two-in/two-out system.
To connect the cores, Nutaq provides a streaming interface called RTDEx. RTDEx can be used in Simulink to exchange data in real-time between the Simulink environment and the remote PicoDigitizer platform. The following figure shows the downstream and upstream block sets from Nutaq.
The green blocks are compiled and used to target the PicoDigitizer’s FPGA (they receive data from the ADCs and send data to the DACs). The yellow blocks are kept in the Simulink environment. They hold the System Generator block set implementation of the control algorithm and enable the sending and receiving of data to the system in real-time over Gigabit Ethernet (referred to as the “Simulink interface”).
The following figure shows the resulting system where the control algorithm’s performance can be validated in real time. It is important to note that with this approach, the latency of the Simulink interface and the Gigabit Ethernet link must be taken into account with respect to the dynamics of the controller. Alternative low-latency solutions are also provided with the Nutaq MBDK, such as PCIe streaming between the FPGA and C API.
Once validated with the real system, the developed algorithm is ready to be tested on actual hardware (rather than in Simulink). The algorithm’s Simulink model (implemented via System Generator blocks) is compiled to generate an FPGA netlist, which will then be used to target the PicoDigitizer‘s Virtex-6 FPGA. This transition from a simulated controller to a hardware controller is guaranteed to be seamless, thanks to the “bit true” and “cycle true” simulation capabilities of System Generator.
Now, the PicoDigitizer Virtex-6 FPGA not only implements the RTDEx cores to enable data exchange with Simulink, it also holds the implementation of the controller that will feed the system with its input signal u
In its normal mode of operation, the controller algorithm implemented on the Virtex-6 FPGA can be operated on its own without the Simulink when the set point is provided by an analog input.
Finally, it’s possible to increase the speed of a simulation by fully utilizing the computation power offered by the Viretex-6 FPGA. This time, instead of using regular Simulink blocks to implement a model of the real system, we use the System Generator block set as shown.
Strictly from a Simulink simulation perspective, there is no benefit to do this. But now both the controller and the system can be compiled in order to generate a netlist for the Virtex-6 FPGA. The following figure shows both the system and the controller running on the FPGA at a speed that is much faster than what can be achieved in a simulated environment. In fact, depending on the complexity of each block, it may be possible to run the blocks together at a speed greater than real-time. This approach is well-suited for collecting controller behaviour data over a long period of time.
With this approach, a means for feeding the system with a test signal r[n] must be provided. Capabilities to record e[n] are also useful, assuming the performance of the controller is to be monitored. The Nutaq MBDK record and playback IP cores offer such capabilities, allowing you to load a source data file from an external host computer to the system’s DDR3 RAM memory over Gigabit Ethernet as well as store the output in DDR3 RAM memory for future recovery.
The suggested workflow for the design of an FPGA-based digital control system is straight-forward. Simulation capabilities allow a team of developers to work in parallel and use models of the system rather than an actual system. Designing the control algorithm in a model-based environment like Xilinx System Generator ensures seamless transition to FPGA-based hardware like Nutaq’s PicoDigitizer, from which it can be deployed with the real system. By modeling the real system with the System Generator block set, the simulation can be accelerated by running it on an FPGA instead of in a PC-based simulation engine.