Generic High Speed DAQ
Our ready-to-prototype generic high speed DAQ solution is based on experience with different diagnostic and low-level control devices that we have integrated throughout the years.
The digitizer part of these applications such as acquisition setup, clock routing, data transfer from the board to the computer, displaying signals on HMIs, etc. is not in the domain or of interest to beam diagnostics or RF physicists. From a physicist’s point of view, the most important part of the application is the analogue front-end and signal processing of acquired ADC data which is specific to each application. These two can often be specific to the machine and can vary from institute to institute, which is why off-the-shelf solutions might not be adequate. The system avoids ‘reinventing the wheel’ for every device that is based on a digitizer board, to avoid separate development of common parts and to provide a generic interface for devices throughout the accelerator.
Introduction
Diagnostic devices such as BPMs, BCMs and low-level controls, for example LLRF, can all be generally considered to be digitizer boards with some custom FPGA processing and specific analogue front-ends. Their underlying functionality is the same — gather some signals, process them and sometimes provide an output. All these applications thus require generic DAQ functionality, while each of them adds signal processing specific to the application.
The key properties of the solution are:
◊ Out of the box support of generic digitizer functionality (firmware, driver, library, screens)
◊ Ability to extend the FPGA core with application-specific code
◊ Control system framework independent library allowing easy integration into any framework
◊ Option for an application-specific analogue front-end due to the concept of rear transition modules (RTMs) in MTCA.4 standard
The system allows for immediate prototyping. Even if the user is not a software engineer, the setup provides basic building blocks that can be used to facilitate an iterative development procedure of physics-related algorithms without requiring daily services from control specialists.
If the user does not have FPGA programming experience, initial prototyping can simply be done by using the provided library and HMI screens. Data from ADCs can be stored (either in text files or on a central archiving service) and fee to application-specific algorithms for processing off-line (for example in Matlab). Once the algorithms have been finalized, they can be moved to the FPGA for real-time processing of data.
The (custom algorithm) development process thus becomes more ‘infrastructure’ (hardware, software) independent, allowing physicists to develop independently of the control system group, with tools they know well (Matlab for example). The software/firmware architecture keeps the main processing core the same for all the applications. This reduces development and maintenance costs and the number of different hardware that need to be kept in stock.
The common core for digitizer-related functionality is not the only aspect of these devices that can be generalized. Extra common interfaces, such as MPS, can be identified and added later.
Architecture
Starting bottom up (from hardware), we first have the firmware that provides support for generic digitizer functionality and leaves enough room for custom signal processing applications. The custom part can be added in addition to the digitizer functionality, keeping the basic core common for all applications. The interface exposed by the firmware is a register map that can be extended with custom, application-specific, registers.
One level above the firmware is the lowest software component — the kernel module. Kernel module implements DMA functionality, access to device registers, interrupt handling, etc. All the functionality of the module is more or less generic PCI Express communication and does not include DAQ-specific functionality. This keeps the complexity of the module to a minimum — the module itself is not foreseen to change even when custom code is added to the FPGA. By using the same kernel module in all the applications, we make sure that the code running in the kernel is well tested and stable.
The most complex part of the software stack is the user-space library which is written in C. The library exposes all the functionality supported by the board. Its main purpose is to provide a userfriendly API that hides the actual register map and exposes the board from a more functional point of view; for example, exposing a ‘select clock source’ function, instead of calling a 32-bit register written directly to the board. By pushing all the complexity to the C library, we achieve two things:
1.The kernel module can stay the same for all the applications. This allows for a well-tested code running in the kernel, where bugs are typically hard to find and cause more inconveniences than in user-space.
2.The board can be easily integrated into any control system framework. Since the main functionality is included in the library, the CS specific applications only need to provide a link between the library and CS.
When application specific processing is added to the FPGA, the library can be extended to provide access to the existing functionality.
Conclusion
The idea of a generic FPGA core for several devices is not new, but the MTCA.4 standard offers more flexibility due to the concept of rear transition modules (RTMs). By using RTMs, the same digitizer board can serve several applications by having a customized analogue front-end. This also simplifies having items on stock, since the board can be turned into a BPM, BCM, etc. by simply flashing the correct firmware.
The solution aims to minimize the time spent on integration of the board and provide a ‘ready to prototype’ base system with supported generic DAQ functionality and a possibility to add custom signal processing cores to the FPGA.
This article was originally published in Control Sheet №33.
ABOUT THE AUTHOR
Urša Rojec started working at Cosylab as a student in 2011. Her background is in Physics. Major projects she worked were the European Spallation Source in Lund, Sweden, where she worked in the ICS Division as part of the hardware and integration group on control system integration (into EPICS) of Low Level RF and Diagnostics. Recently she worked on the beamline control system for a Proton Therapy project. In her free time she enjoys skiing.
Want more articles like this?
Do you want to learn more information on building the right control system infrastructure? Please let us know in the comments below!
