The year 2011 saw a signature development in the FPGA industry – the introduction of two new programmable SoC devices. Xilinx introduced the Zynq-7000 All Programmable SoCs, and Altera introduced the Cyclone V SoC and Arria V SoC FPGAs. These new programmable SoCs, each packing a high-performance dual-core ARM Cortex-A9 MPcore along with ample amounts of programmable logic, offered advantages for a plethora of applications. Now designers could enjoy the benefits of software application development on one of the industry’s most popular processors while gaining the flexibility and throughput potential from hardware acceleration on a high-speed, programmable logic fabric.

Designers saw they could migrate their old multichip solutions built from discrete processors and FPGAs to a new, single-chip platform. On this new platform, they could use FPGA-based accelerators to unclog software execution bottlenecks and tap into an arsenal of off-the-shelf, production-ready IP from Altera, Xilinx, and their IP partners for DSP, networking, communications, and more.

However, customers were now asking themselves – and their nascent programmable SoC vendors – how they were going to program these new devices. Designers imagining the potential of hardware/software codesign sought out integrated workflows that would intelligently partition designs between ARM processors and programmable logic. But, what they found were distinct hardware and software workflows: conventional embedded software development flows targeting ARM cores alongside a combination of IP assembly, traditional RTL, and emerging high-level synthesis tools for programmable logic.

Enter an Integrated Hardware/Software Workflow for Programmable SoCs

Skip ahead to September 2013 when MathWorks introduced its hardware/software workflow for Zynq-7000 SoCs using Model-Based Design. In this new workflow (Figure 1), designers create models in Simulink that represent a complete dynamic system, including a Simulink model for algorithms targeted for the Zynq SoC, and rapidly create hardware-software implementations for Zynq directly from the algorithm. Key elements to the new approach were: 

• System designers and algorithm developers used simulation in Simulink to create models for a complete system – communications, electromechanical components, and so forth – in order to evaluate design concepts, make high-level tradeoffs, and partition algorithms into software and hardware elements.
• HDL code generation from Simulink enabled the creation of IP cores and high-speed I/O processing on the fabric of the Zynq.
• C/C++ code generation from Simulink enabled the programming of the Zynq Cortex-A9 cores, supporting rapid embedded software iteration.
• Automatic generation of the AXI4 interfaces linking the ARM processing system and programmable logic with support for Xilinx Zynq and Altera SoCs.
• Integration with downstream tasks, such as C/C++ compilation and building the executable for the ARM, bitstream generation using Xilinx implementation tools and downloading to Zynq development boards allows for a rapid prototyping workflow.

Figure 1 – Model-Based Design for programmable SoCs

In October 2014, MathWorks extended this workflow to Altera Cyclone V SoCs, including generation of custom IP cores in VHDL or Verilog, building Linux executables, and generation of AXI4 interfaces linking algorithms partitioned between the Altera SoC hard processing system and programmable logic fabric. 

Central to this workflow are two technologies: Embedded Coder and HDL Coder. Embedded Coder generates production-quality C and C++ code from MATLAB, Simulink, and Stateflow, with target-specific optimizations for embedded systems. Embedded Coder has become so widely adopted that when you drive a modern passenger car, take a high-speed train, or fly on a commercial airline, there’s a high probability that the vehicle is being guided by real-time code generated by Embedded Coder. HDL Coder is the counterpart to Embedded Coder, generating VHDL or Verilog for FPGAs and ASICs, and it is integrated tightly into Xilinx and Altera workflows. This mature C and HDL code generation technology forms the foundation of the Model-Based Design programmable SoC workflow.  

Design teams using Model-Based Design in applications such as communications, image processing, smart power, and motor control have jumped on this workflow as the means for algorithm developers to work closely with hardware designers and embedded software developers to accelerate the implementation of algorithms on programmable SoCs. Once the generated HDL and C code is prototyped in hardware, it can be integrated with other design components needed for production using Xilinx Vivado IP Integrator and Altera Qsys.

Case Study: Field-oriented Control of a Three-Phase Motor

For several compelling reasons, one of the most popular applications that has emerged for programmable SoCs is custom motor controllers with efficient power conversion:

• Higher performance/efficiency initiatives – With electric motor-driven systems accounting for as much as 46% of global electricity consumption, attaining higher efficiency with novel control algorithms is increasingly a design goal for new motor drive designs. The high performance and precise timing offered by the programmable logic of Xilinx Zynq and Altera SoCs provide an ideal platform for implementation of low-latency, high-efficiency drives.
• Multi-axis control – Ample programmable logic and DSP resources on programmable SoCs open up possibilities for implementing multiple motor controllers on a single programmable SoC, whether each motor is operating independently or in combination, as in an integrated motion control system.
• Integration of industrial networking IP – Xilinx, Altera, and their IP partners offer IP for integration with EtherCAT, PROFINET, and other industrial networking protocols that can be readily incorporated into programmable SoCs.

To illustrate the use of this workflow on a common motor control example, consider the case of a field-oriented control algorithm for a three-phase electric motor being implemented on a Zynq-7020 SoC (details of this hardware prototyping platform are available at http://www.mathworks.com/zidk). As shown in Figure 2, the motor control system model includes two primary subsystems:

• Motor controller targeting the Zynq SoC that has been partitioned between the Zynq processing system and programmable logic.
• Motor controller FMC card connected to a brushless DC motor equipped with an encoder to measure shaft angle.

 Figure 2 – Case Study: Field-Oriented Control

We can look at hardware/software partitioning in terms of data flow:

• We assign the Velocity Control and Mode Select blocks to the ARM because they can run at a slower rate than other parts of the model, and because they are the portions of the design most likely to be modified and recompiled during development.
• The operating mode of the motor controller – e.g., open-loop operation, closed-loop regulation, etc. – is determined by a Mode Select state machine running on the ARM. This state machine manages the transitions between the start-up, open-loop control and an encoder calibration modes before switching to a closed-loop control mode.
• The encoder sensor signal is passed via an external port to an Encoder Peripheral in the programmable logic, then to a Position/Velocity Estimate block that computes the motor’s state (shaft position and velocity).
• The motor current is sensed by a Sigma-Delta analog-to-digital converter (ADC), and processed by a hand-coded ADC Peripheral block. 
• The Current Controller takes the motor state and current, as well as the operating mode and velocity control commands passed from the ARM core over the AXI4 interface, and then computes the current controller command. When in its closed-loop mode, it uses a Proportional-Integral (PI) control law, whose gains can be tuned using simulation and prototyping.
• The current controller command goes through the Voltage Conversion block and is output to the motor control FMC card via the PWM Peripheral, ultimately driving the motor.

This complete system can be modeled in Simulink, as shown in Figure 3.

Figure 3 – Control-loop model for motor control system with simulation results showing response to a velocity pulse command.

In Model-Based Design, the system increases to four components in the top-level Simulink model:

1. An input model provides a commanded shaft velocity and on/off commands to the controller as stimulus.
2. A model of the motor control algorithm that will be targeted for the Zynq SoC.
3. A plant model that includes the drive electronics of the FMC, a permanent-magnet synchronous machine (PMSM) model of the BLDC motor, a model of an inertial load on the motor shaft and an encoder sensor model.
4. An outputs model that includes postprocessing and graphics to help the algorithm developer refine and validate the model.

In Simulink, we can test out the algorithm with simulation long before we start hardware testing. We can tune the PI controller gains, try different stimulus profiles and examine the effect of different processing rates. As we use simulation, though, we face a fundamental issue: because of the disparate processing rates typical of motor control – that is, overall mechanical response rates of 1-10 Hz, core controller algorithm rates of 1-25 KHz, and programmable logic operating at 10-50 MHz or more – simulation times can run to many minutes or even hours. We can head off this issue with a control-loop model that uses behavioral models for the peripherals – the PWM, current sensing and encoder processing – producing the time response that is shown in Figure 3.

After we use the control-loop model to tune the controller, our next step is to prove out the controller in simulation using high-fidelity models that include the peripherals. We do this by incorporating timing-accurate specification models for the C and HDL components of the controller. These specification models (Figure 4) have the necessary semantics for C and HDL code generation. With simulation, we then verify that the system with specification models tracks extremely close to the control-loop model.

Figure 4 – Specification models for C and HDL code generation with simulation results.

With simulation showing good results, we move on to prototyping the controller in hardware. Following the workflow that was shown in Figure 1, we start by generating the IP core. The IP core generation workflow lets us choose the target development board and walks us through the process of mapping the core’s input and output ports to target interfaces, including the AXI4 interface and external ports (Figure 5).

Figure 5 – Top-level model for DUT and display of mapping of DUT’s I/O ports.

Through integration with Xilinx Vivado, the workflow builds the bitstream and programs the fabric of the Zynq-7020. With the IP core now loaded onto the target device, the next step is to generate embedded C code from the Simulink model targeting the ARM core. The process of generating C code, compiling it, and building the executable with embedded Linux is fully automated, and the prototype is then ready to run.

To run the prototype hardware and verify that it gives us results consistent with our simulation models, we build a modified Simulink model (Figure 6a) that will serve as a high-level control panel. In this model, we removed the simulation model for the plant – that is, the drive electronics, motor, load, and sensor – and replaced it with I/Os to the ZedBoard.

Figure 6(a) – Simulink model for testing prototype hardware.

Figure 6(b) – Comparison of results from hardware prototype and simulation. 

Using this model in a Simulink session, we can turn the motor on, choose different stimulus profiles, monitor relevant signals, and acquire data for later postprocessing in MATLAB, but for now we can repeat the pulse test (as shown in Figures 3 and 4). Figure 6b shows the results of the shaft rotational velocity and the phase current for the hardware prototype compared to the simulation results.

• The startup sequence for the hardware prototype is noticeably different than for the two simulation models. However, this is to be expected because the initial angle between the motor’s rotor and stator in the hardware test differs from the initial angle used in simulation, resulting in a different response as the current control algorithm drives the motor through its encoder calibration mode.
• When pulse is applied at 2 seconds, the results from simulation and prototype hardware match almost exactly. 

Based on these results, we could continue with further testing under different loading and operating conditions or we could move on to performing further C and HDL optimizations.

Summary

Model-Based Design for programmable SoCs is a workflow that engineers are using for hardware/software implementation of algorithms on Xilinx Zynq and Altera SoC devices. Use of simulation in Simulink provides early evaluation of algorithms, allowing designers to evaluate their effectiveness and make design tradeoffs at their desktop rather than in the lab – with higher productivity as a result.

Proven C and HDL code generation technology, along with hardware support for Xilinx and Altera SoCs, provide a rapid and repeatable process for getting algorithms running on real hardware. Continuous verification between the simulation and hardware environments enables designers to identify and resolve issues early in the development process.

MATLAB and Simulink are registered trademarks of The MathWorks, Inc. See www.mathworks.com/trademarks for a list of additional trademarks. Other product or brand names may be trademarks or registered trademarks of their respective holders.