Published
Use of FPGA on the example of parallel data sampling
Insight in Brief
Although microcontrollers are becoming increasingly powerful, they are not optimally suited for many applications. Especially for parallel acquisition of time-critical sensor data or deterministic processing of large amounts of data, FPGAs are the ideal solution.
Our experience with FPGAs has been continuously extended over the last years and has been successfully used in various medical medical and measurement devices - be it as a standalone controller, as a coprocessor of a microcontroller or with a softcore processor.
In this article, the practical use will be explained using the example of the acquisition of time-critical sensor data.
Introduction
Measuring devices and closed-loop or open-loop control systems often require a large number of sensors. In the past, these sensors often had an analog output. More and more, however, the sensors are connected via a digital interface such as SPI or I2C. Digital transmission makes the signal much less susceptible to external interference. However, classic processors only have a limited number of these interfaces. Additional interfaces can only be obtained, if at all, by switching to the next larger device family. If the sensors are to be sampled in parallel, the limits are definitely reached. In this case the FPGA is used.
FPGA (Field Programmable Gate Arrays) offer the possible flexibility with the interfaces and is designed to execute different operations in parallel. In the following example from one of our projects we would like to show how an FPGA can be ideally used for this purpose.
The classic approach
For a flow measurement device, various sensor values must be continuously recorded and evaluated. Figure 1 shows an overview of the measured values. In addition to these sensors, the system needs other sensors to determine other measurement parameters. Since each value represents a snapshot, it makes sense to sample all sensors that are used in the flow calculation at the same time. In addition, each sensor has a different interface and the sampling interval should be fixed.
If several sensors are connected to one SPI or I2C bus, then only one sensor can be read out at a time per bus interface. So that a simultaneous readout is possible, a separate interface must be assigned to each sensor. If you only consider the number of sensors, this would still be possible in this case with a microcontroller. In most cases, however, other interfaces are required in addition to the sensors. (USB, Ethernet to a PC. I2C for a battery manager, SPI for flash, etc.) Furthermore it is very difficult to read out all sensors in parallel. For this the microcontroller usually has too few DMA (Direct Memory Access) channels, which can be active at the same time. This is where the FPGA comes into play.
Solution with FPGA
To put it simply, the FPGA only has GPIOs. These can be specifically assigned depending on the application. - Of course, FPGAs also have pins with special functions. Mostly, however, these are special properties for fast bus systems or memory connections (PCIe, DDR memory). For this application, however, at most the partially integrated ADC inputs are of relevance. - This allows the definition of any number of data interfaces. In addition, these can also be replaced by others at any time. With simple and slow interfaces like SPI or I2C you are also only limited by the number of logic blocks and pins.
Structure of the interfaces
The single interfaces are best implemented in three layers:
- PHY: Implementation of the physical interface (SPI, I2C, ...)
- MAC: Translation of the single packets into a single data packet.Both in send and receive direction.
- DATA: Here the actual sensor data is unpacked or commands are packed.
This division makes it possible that different tasks are encapsulated in the individual entities and the respective code becomes smaller and thus also less error-prone.In addition, if multiple sensors from the same manufacturer are used, it is likely that they will use an identical protocol. In this case, in addition to the entity for the PHY, the MAC layer can also be instantiated identically multiple times. This drastically reduces the development effort.
Sampling control
How can it be ensured that all sensors are read out at the same time? For this purpose there is a block in the FPGA which generates a regular trigger signal. It can either be that this is always active, or can be controlled via a configuration interface. In this case it generates a pulse (\( T_p \)) every 1ms. Each of the communication interfaces has an interface inside as shown in the following example:
As soon as the interface sees an edge at the "enable" input, the component starts data acquisition independently. As soon as this is completed, the component signals with an edge on "dataValid" that valid data are available. Each sensor component has a sampling time Ts. This is the time between the edge on "enable" to the edge on "dataValid". Now any sensor can be integrated. It is only to be noted that the maximum sampling time of each component (\( T_{s,max} \)) is smaller than the time between the pulses (\( T_p \)).
\( T_{s,max} < T_p \)
Collecting the data and communication with firmware
In the end, the data must be transferred to a firmware. Be it for further processing, visualization or storage. There are again numerous possibilities for this:
- The data can be transferred directly to a PC.
- The data can be passed to a softcore. E.g. NIOS II or a RISC-V.
- The data can be passed to a microprocessor.
For the measuring device the third variant was chosen. For this, an SPI interface with a special protocol was defined.
Summary
Instead of several interfaces the processor needs only one interface to read different sensors. Encapsulating the sensor sampling also improves testability, since this component can be tested completely detached from the business logic. If a sensor needs to be replaced at a later date, only the FPGA needs to be retested. The firmware with the business logic does not need to be touched. In addition, the real-time behavior of the sampling is absolutely deterministic.
More Expert Blog articles
Discover IMT’s engineering expertise and innovative solutions in our Expert Blog. Gain valuable know-how from our experts and explore technology highlights.