Handling FPGA-CPU hybrides with Model Based Design
FPGA and SOC
FPGAs are ideally suited for time-critical and demanding systems. Capacity and computing power continue to grow and fpga vendors increasingly offer additional function blocks such as high-speed communications
interfaces, DSP’s for analog/mixed signal and a huge amount of logic and internal memory. On the roadmaps of the FPGA giants are much more hard-coded function blocks, including optical communication channels,
digital radio, video, radar and data encryption.
Often, there is also a need in a system for the flexibility of a processor for programming applications. Traditionally this was done in an fpga-based system by using a softcore. Despite the performance of the programmable silicon, the performance of these soft cores lags far behind that of the processors of mobile phones and tablets.
FPGA vendors Altera and Xilinx give into this demand by the recent introduction of system-on-chip (SoC) devices that integrate an FPGA with a dual-core ARM Cortex-A9 processor, the industry standard in terms of CPUs. They have
both already announced multicore 64bit ARM systems in their generations SOCs.
The increasing complexity and introduction of processors impose different requirements on the development of a system. Traditionally, FPGA functionality was usually described in VHDL. For the FPGA-SOCs software development is coming along: a software designer is added to the development in order to write drivers, applications and possibly the configuration of a (real-time) operating system.
One way to deal with this complexity, is using model based design. A traditional design process consists of putting the requirements and specifications on paper, implementation in hardware and software and finally the verification in a test environment. Often several iterations are necessary because the specs are ambiguous or incomplete. Design errors are often only found at a late stage, and changes in the requirements cost a lot of extra work and puts the project planning under time pressure.
At 3T, we have been working for some time with model based design. We have done a number of projects (see also Bits&Chips 4, 2013) and developed a specific development environment designed based on Matlab/Simulink for it. With Matlab HDL/C Coder, we can generate VHDL or C/C ++ – code for the FPGA logic and ARM Cortex-processor.
With model based design, the development process looks radically different. The specs are immediately recorded in models and verified in a simulation environment. The impact of specific requirements is readily apparent, changes in requirements are easy to implement and design errors are found at an early stage. The models are an exact specification of the code to build and can be implemented in either hardware, software or FPGA logic. Our experience is that these properties make the method suitable for the development of multidisciplinary FPGA SOC-based systems.
Flashy development for GATSO
In collaboration with our customers, Gatso from Haarlem, we have developed a radar tracking system based on the Xilinx Zynq-soc. Gatso produces systems to determine speed violations on the roads. The radar module measures the position and speed of vehicles on the basis of the range-doppler principle: the reflections of transmitted frequency sweeps are synchronously measured by two receivers and translated into a two-dimensional spectrum in which speed and position of objects emerge. Object recognition algorithms are used in order to be able to track the different vehicles in the time.
Gatso has developed Matlab models to stimulate the signalprocessing- and radar algorithms and validated them with raw radar data. These models are therefore the specifications of the radar tracking system and can be used as a golden reference against which the implementation models continously are verified.
The input and output of the radar elektronics go via ethernet. This facilitates that the system can be tested against pc-gebased models.
The functionality is roughly divided into dsp functions and radar algorithms. The DSP-part consists of the generation of the frequency sweeps, data acquisition, filtering, and a two-dimensional FFT. The timing between the output of the frequency sweeps and sampling the reflected radar data is very precise. These conditions require the use of an FPGA.
The algorithms to detect objects, and to track them, are typical software tasks. Again, real-time requirements apply, but the allowable jitter is a few milliseconds, about a thousand times higher than for the DSP section. With a performance test, we have demonstrated early that the dual-core Cortex-A9 has enough computing power to perform these demanding algorithms.
We investigated different operating systems for the software side of the system. Gatso placed few demands on the OS-choice and the software architecture, with one major exception: all algorithms must be integrated using Matlab-C/C ++ code generation in the software framework. In this way Gatso can at a later stage refine the existing algorithms and add new ones.
Excellent real time properties were required for the operating system, and the preference was to go for open source. In a test with real-time Linux with a software-based TCP/IP stack, the Ethernet bandwidth turned out to be an issue. The data processing system uses a Gigabit Ethernet link to read the radar data and write the output an SSD. The required bandwidth for this is approximately 750 Mb/s full-duplex, and that proved unfeasible. We have therefore chosen to use UDP and implement the Ethernet interface in the FPGA logic.
After the removal of the requirement for tcp support in the software, Ecos turned our to be the best option for the operating system. A disadvantage of this RTOS is that there is only single core of implementations are available for the ARM Cortex-A9. We use the processor system therefore in an asymmetric multiprocessing configuration (AMP), which Ecos resides on the first core and the algorithms run “bare metal” on the second core. As part of the software framework, we have designed an effective communication mechanism to exchange information between the two CPU cores.
The radar tracking system is controlled and read out via a CAN-bus interface. The CanOpen stack vendor has ported it to the Xilinx Zynq architecture and integrated it together with our software architect into Ecos. The fpga design was created using the Vivado tooling of Xilinx. Vivado is a complete toolset for design, verification and debugging of Xilinx FPGAs and SOCS. The tooling also includes a SDK to develop software applications.
The FFT calculations are based on standard Xilinx IP block; for data acquisition, digital filtering and ethernet we have developed our own functional blocks that we could add as an IP-cores in the IP-catalog of Vivado, allowing them to be coupled to eachother by means of a block diagram. The blocks can be connected to standard 64 bit Axi-buses with the processor system and they have addressable registers that are mapped into the shared memory space of the CPU and the FPGA.
For the FPGA-design we did not use code generation. Matlab is used for the verification of the functional ip-blocks. From the golden reference models, test vectors are generated for each IP block. Those can be offered to simulation environment, but it’s just as easy to offer them via the Ethernet link to use the actual electronics.
Flexible test solutions: MINT
Another project with an FPGA-SOC is the Multi Interface Board, a flexible board that we developed in-house. Thanks to an Altera Arria V SOC we can adapt it to specific customer requirements.
The board supports standard PC interfaces such as USB3.0 and Gigabit Ethernet, as well as industry standards such as CANopen, EtherCAT, Modbus TCP and Serial Rapid IO (SRIO). It may be used to extend a standard laptop or PC with a SRIO interface and custom interfaces based on RS485 and LVDS. There is also a FPGA mezzanine connector (FMC) available for expansion cards.
The board can also be used as a qualification tool to connect a device-under-test via Ethernet or USB to a standard PC. The PC is really only used for the user interface; the test scripts (stimuli) are downloaded to the SOC from the PC and executed by the ARM cores, while the fpga models the sensors and actuators.
The PC thus does not have any influence on the timing, resulting in that we can test completly closed-loop in real time. Simultaneously, the test scripts can still be easily modified or extended. The qualification is fully automated and is also ideal for repeatable regression testing.
We use model based design for a different applications of the board as a platform for rapid prototyping and hardware-in-the-loop simulations when we are testing algorithms. Matlab and Simulink models are mapped to the FPGA and ARM cores and simulated real-time on the hardware.
From our projects we see no major differences between the FPGA-SOC architectures from Xilinx and Altera. If a company already has previous experience with FPGAs of one of the two suppliers, it seems natural to stay with the supplier for a FPGA-SOC. Designing a SOC based system is very different compared to traditional FPGA development. With SOCs, development becomes multidisciplinary bringing software and hardware design together.
The suppliers of the SOC realize this and invest heavily in the development of good development tools. OpenCL, high-level synthesis and model-based design should bring the design process to a higher level of abstraction. Our projects show that model-based design helps to significantly make the development process faster when using an FPGA-SOC and makes the ultimate solution more reliable.
Ronald Grootelaar (firstname.lastname@example.org) is systeemarchitect at 3T en specialized in embedded processing and model-based design for embedded applications.
Richard Mijnheer (email@example.com) is CEO of 3T.
Source: Bits&Chips, nr.8, oktober 2014