Model Based Design brings 3T to faster FPGA development
In the development of FPGA firmware for a brake system for a robot, 3T used model based design to do the job. Ronald Grootelaar from 3T explains the used design approach.
Model Based Design (MBD) has become very popular in recent years. From the automotive and aerospace industry, this design methodology has found its way into many others. The approach is mainly an added value in multidisciplinary project teams, because everyone can work using the same model-based simulation tool with unambiguously defined specifications and model verification in the same test environment.
At 3T we also adopted MBD for the development of FPGA firmware. The recent system chip architectures of Altera and Xilinx with dual ARM Cortex-A9 cores and complete FPGA fabric, well fit with this approach. Algorithms can be implemented as required in hardware or software. For data exchange the SoCs fast Axi internal buses are used. For external data interfaces, we can choose to include Gigabit Ethernet, PCI Express, Serial RapidIO and/or USB .
The used FPGA development development flow is fully aligned with the tooling of MathWorks. We apply the model-based simulation environment of Simulink and the corresponding HDL Coder-toolbox for automatic (HDL) code generation. With this we take full advantage of the benefits that MBD offers : higher quality, faster time-to-market and a higher degree of flexibility.
In collaboration with one of our customers, we have recently developed a brake system for a handling robot. This robot transports and positions semi-finished products into a semiconductor machine. It is powered by two three-phase drives and can do both stretch and turning movements.
The robot uses the brake system to make a controlled emergency stop in case of an error situation. During a brake action, it is important to follow the movement with an accuracy of one millimeter to prevent damage to the machine. Because the brake system must do its work completely autonomously, we have to derive the path of movement from the energy in the drives before the brake action starts.
The brake system is based on the short-circuiting of the drive phases. We received a large Simulink model of the robot from our customer and it showed that a closed-loop control is needed to follow the path of movement during braking in order to get the required accuracy. Current limiters prevents damage to the mechanical construction.
The braking system is controlled in real time via a high-speed digital communication interface. For the measurement of the motor voltages up to 250 V, and the operation of the brake, specific analog -to-digital converters (ADCs) and digital-to-analog converters (DACs ) are required. All these preconditions require that a FPGA is used. In the FPGA firmware development, we have applied MBD .
3T used model based design in the development of a brake system for a handling-robot. Photos: Hirata
For brake functionality, we first designed a golden reference model that works based on floating point numbers. We reconstruct the path of movement by determining the relationships between the drive voltages, and then calculate the drive phase angle using an inverse tangent. From the drive phase angle of both drives, we finally derive the path of movement.
As an alternative for HDL-cosimulation, Mathworks supports FPGA-hardware-in-the-loop-verification.
The controller uses an infinite impulse response filter (IIR) of the third order combined with a current limiting algorithm. The IIR filter coefficients are adjustable and adaptable from software. After a few design iterations and tuning of the parameters, the golden reference sample worked in Simulink within the required specifications.
Generating HDL code for the FPGA is this unfortunately not just a “press of the button”. The floating point-based golden reference sample had first to be converted to a discrete fixed point model that contained only components supported by HDL Coder. To achieve this, we have examined the impact of this fixed point conversions and conversion of formulas to discrete components. Not all of the functionality appears to easily integrate in Simulink. This is particularly true for the required communication interface and ADC/DAC control.
We have therefore chosen to deliver the FPGA model as a separate IP block. This block is a separate subsystem in the Simulink model and is one on one translated into a VHDL entity. The transition from the system (line) frequency to the higher FPGA clock frequency we have modelled in Simulink through Rate Transition blocks, where the different sample rates are clearly shown in different colors.
With HDL Coder, we have generated the FPGA code in the next step. We have synthesized the resulting generic HDL using the HDL Coder Workflow Advisor and mapped it onto the selected FPGA architecture, a Xilinx Spartan-6. In this way, we got a picture of the required resources and timing closure.
In order to deal with timing closure problems, there is in HDL Coder the ability to distribute additional pipeline registers in the design. The desired number can set up per sub-block. The toolbox will ensure that the delay balancing is done, allowing for parallel data paths (without pipelining ) to have the same delay. HDL Coder does not place pipeline registers (by default) in the feedback paths because it changes the properties of the model. We can, however, manually add pipelining in the feedback paths to get the timing closure right, for example, if a filter is calculate at a lower frequency then the FPGA clock frequency.
To reduce the amount of FPGA resources, we can make use of resource sharing in HDL Coder. This mechanism does not work yet for all function blocks. In our FPGA model we use reciprocal square root calculations that HDL coder can not share, which is a heavy burden on the DSP cells available in the Spartan-6. We solved this resource problem by characterizing several subsystems in HDL Coder as a black box. Our FPGA designers have filled them with a number of generated Xilinx IP blocks and surrounded them with a handful of multiplexers and demultiplexers to control the resource sharing. In this way, we have been able to get the brake function implemented using the available FPGA resources (DSP cells, LUTs and registers).
The transition of the system (line), to the higher frequency FPGA clock frequency, we model in Simulink by means of Rate Transition-blocks, wherein the differing sample rates are displayed in different colors.
HDL Coder also has the ability to generate a Cosimulation model for RTL simulation. The RTL code generated, can run in an RTL cosimulator like Modelsim, which is controlled from Simulink. In cases like ours, this is always recommended because the cosimulation model simulates the generated HDL code, including pipelining, delay balancing, and any black boxes.
When generating the cosimulatie model, a Modelsim script is being created. The implementations of the black boxes we have to add manually, as well as any vendor-specific simulation libraries. We then first start Modelsim in server mode and then the Simulink simulation. Differences between the co-simulation and the original model are shown in scope plots. These make even marginal discrepancies between the blackbox implementations and Simulink equivalents visible.
Co-simulation will take considerably longer than a simulation in Simulink . Therefore MathWorks supports FPGA hardware-in-the-loop verification as an alternative. The HDL code is then first fitted, and then downloaded into a standard FPGA-board from Altera or Xilinx. Simulink communicates with this board via a standard Ethernet connection.
Ronald Grootelaar is Consulting Engineer at 3T in Enschede. During the Bits & Chips Hardware Conference on June 12 2013, he will give a presentation on model based design of FPGAs .
Source: Bits&Chips, 26 April 2013