- Energy-efficient power delivery for servers and data centres
- Batteries—quick coatings
- World’s biggest solar and battery project to be built in South Australia
- Report shows 3 million people affected by outages in 2016
In this article you will learn how modelling helped a small team of algorithm and embedded software engineers design a motor control algorithm and implement it on a programmable system-on-chip (SoC).
We were the embedded engineers on this team. We will show how modelling helped us partition our design, balance functional behaviour with implementation resources, and test in the lab.
Programmable SoCs such as Xilinx, Zynq, SoCs and Altera SoC FPGAs, which combine programmable logic and microprocessor cores on the same chip, have been design teams new platforms for algorithms deployment in a wide range of applications, including embedded vision, communications, and control of motors and power electronics. These design teams typically include two categories of engineers: algorithm engineers, responsible for conceptual development and elaboration of math-based or rule-based algorithms, and embedded engineers, responsible for refining the algorithms and implementing them in software or hardware on the embedded device.
Algorithm engineers commonly use modelling early in the development process to gain confidence that their algorithms are functionally correct for their application.
Embedded engineers, on the other hand, don’t always see the benefits of modelling. However, when these teams do not work closely together, the result can be late error detection, causing project delay; excessive resource use; or compromised functionality due to inadequate design and test iterations.
We set out to see whether modelling could help both algorithm and embedded engineers create a more efficient and collaborative design process. We wanted to focus on modelling algorithm components that we could explore using simulation. We would use simulation to help us make partitioning decisions, use simulation and code generation to balance functional behaviour with implementation resources, and automate integration and deployment of the generated code and hand code to make more efficient use of lab time.
Proposed Workflow
We proposed a workflow that would be a mix of code generated from models and hand code. We would begin with models provided by the algorithm developer and iteratively elaborate the models by adding implementation details. At each iteration we would simulate system behaviour to ensure the functional correctness of the algorithm models, implement the algorithms with code generation to obtain code that behaved like the model, and then automate integration with our reference design to ensure a repeatable process to get to hardware implementation.
Selecting a Hardware Platform
For this case study we decided to design a velocity controller for a permanent magnet synchronous motor using a field-oriented control (FOC) algorithm, and then to deploy it to a Zynq-7000 All Programmable SoC Intelligent Drives Kit II (Figure 2). We chose motor control because it is an application where algorithm engineering and embedded engineers often need to work together. We chose the Zynq Intelligent Drives Kit II because it was readily available and offered the I/O support we required.
The Zynq Intelligent Drives Kit II is a development platform used by engineers who want to test motor control algorithms running on a Zynq Z-7020 SoC device. Based on the ZedBoard development board, the kit includes an Analog Devices FMC motor control module and a 24V brushless DC motor equipped with a 1,250 cycles/revolution encoder. Because we wanted to test motor control algorithms under a range of operating conditions, we used the Zynq Intelligent Drives Kit II with an optional dynamometer system.
Partitioning Algorithm Components
We chose to implement algorithm components on the ARM if they required rates of a few kHz or less. The constraint of a few kHz rates was set because we planned to run a Linux operating system on the ARM. Algorithm components requiring faster rates would be implemented on the FPGA.
We wanted to implement algorithm components on the ARM whenever possible because we found that design iterations were faster on the ARM than on the FPGA. It was easier to target the algorithm to the ARM core because it supported native floating-point math operations. Most FPGAs perform floating-point math inefficiently, so targeting programmable logic requires the additional step of converting algorithms to fixed point. In addition, we found the process of compiling C code for the ARM was generally faster than compiling HDL code for the FPGA.
We used simulation to determine whether algorithm components could be executed at rates slow enough for the ARM or if the FPGA was required. For example, the algorithm engineer initially proposed an encoder calibration routine that ran at 25 kHz, which would have to be implemented on the FPGA. We used simulation to test whether we could run the encoder calibration component at 1 kHz, found that we could, and decided to implement it on the ARM.
Balancing functional behaviour and implementation resources
Once we had functionally correct models with the desired component rates, we grouped all components intended for C code generation into an algorithm C model and all components intended for HDL code generation into an algorithm HDL model. We then iteratively added implementation details to the models and generated code until we felt it would fit within an acceptable amount of memory and execute at the component rate.
We used Embedded Coder to generate C code from the algorithm C model and generate a report summarising the calling interface and estimated data memory usage. While reviewing the report we realized that all the data types were double-precision floating point. We wanted the data that would interface to the FPGA to be integer or fixed point and the rest of the mathematics to be single-precision floating point. We applied these data types to the model, used simulation to verify the behaviour was still acceptable, then generated the improved code. At this point we felt confident that the code was suitable for implementation on the ARM.
We implemented the algorithm HDL model as fixed point since fixed-point operations consume fewer resources on FPGAs. To achieve this, we worked with the algorithm engineer to identify and bound key signal ranges in the design (current, voltage, and velocity), then used Fixed-Point Designer to define fixed-point data types that would ensure calculations did not overflow. We used HDL Coder to generate code and a summary report.
We reviewed the resource estimation section of the report to identify math operations that seemed unexpectedly large. For example, our initial selection of word lengths resulted in several multiplications of two 34-bit numbers, which we felt would needlessly consume FPGA resources. We were able to identify this issue in the resource utilisation report, reduce the precision in the model, use simulation to verify functionality was still correct, and then generate the improved code. We used Xilinx Vivado Design Suite to synthesise the code and verify that it met timing requirements.
Benefits of this approach
The workflow described here enabled us to work more efficiently with the algorithm engineer. Through simulation we assessed the effect of algorithm partitioning on system performance and verified that the encoder calibration component could be moved from higher-rate programmable logic partition to the lower-rate ARM partition.
Simulation also allowed us to make decisions that conserved implementation resources while maintaining functional behaviour, such as reducing word length of math operations in the programmable logic, or converting data to be passed through the AXI interconnect from floating-point to fixed-point data types. Finally, our prototype testing in the lab helped us identify errors in mapping ADC count to current, and enabled our algorithm engineer to run further testing to characterise the motor’s torque constant.
Overall, the workflow supported a close collaboration between us and the algorithm engineer, producing a more efficient implementation while economising on lab time.