FPGA Data Acquisition

=Problem Definition= Our main objective is to create a cheap, modular FPGA data acquisition and control system using commercial, off-the-shelf parts. Our design uses a Red Pitaya FPGA in order to take in two analog inputs. Once we have these, our web application allows users to control the output signal through a PID loop. This output is then downloaded as a CSV file onto the connected computer. Our design has a wide variety of lab applications and can be useful for anything from laser modulation to circuit analysis. Traditional data acquisition systems are very expensive due to their degree of specialization. An affordable and flexible solution would be desirable for many companies looking to process multi-phase inputs.

=Background= Our project is sponsored by Thorlabs, which is historically an optomechanics company, that is pushing to provide better electronics for instruments and instrument systems. This typically involves the handling of analog control signals that interact with some digital controller. The goal of our project is to expand Thorlabs portfolio by creating an FPGA-based Data Acquisition/Controller device.

A similar Capstone project was sponsored by Thorlabs last year, and this project will seek to expand upon their work, which was done with an FPGA development board made by Red Pitaya. The previous team was able to create some custom hardware for the purposes of Thorlabs, however, they encountered difficulty when attempting to load this hardware onto the FPGA. This served as the entry point for our team, whose first major decision involved whether to use our budget to purchase new FPGAs or to attempt to resolve the issues with the Red Pitaya.

FPGA
A field-programmable gate array (FPGA) is a type of re-configurable integrated circuit. This allows users to program the FPGA and create new circuits in physical hardware, making them more adaptable than a chip with only programmable software. This adaptability often can allow for faster computations done at the hardware layer, rather than in software, and make the FPGA a good fit for flexible data acquisition systems like the one being designed in this project.

STEMLab 125-14 Red Pitaya
The Red Pitaya is an FPGA with built-in ADC, and DAC converters, each operating at 125 MSPS with 12-bits of resolution. This makes it a good fit for our project because it doesn't require peripheral hardware to capture or produce signals.

The Red Pitaya utilizes a Zynq 7000 SoC which is composed of an FPGA and ARM-based processor which run together. The FPGA is programmed using a bitstream, and will typically be programmed with a .bit file provided by Red Pitaya which gives us access to many useful hardware modules. The processor runs a version of Ubuntu Linux and has access to FPGA through memory-mapped registers.



=Specifications= In the world of microcontrollers, the cost of data acquisition systems represents a major hurdle for many companies. Acquiring the hardware and software combination in order to process multi-phase inputs can put a big dent in a project’s budget. Furthermore, many data acquisition and control systems that are available are highly specialized which prevents use across different platforms. Our goal is to create a cheap, modular FPGA data acquisition and control system using easily available off the shelf hardware. This solution will be affordable and portable, which allows use across many different system types and a multitude of applications.

Thorlabs will provide a testing setup, which uses our controller as a component in a Pound Drever Hall loop.

To make a clearer path for our project, the requirements of our project were split into 3 tiers.

Tier 1
Tier 1 represents our primary objective of creating a dual channel data	acquisition device. In this case, dual channel data acquisition must include support not only logging, but also filtering, and decimation up to 16 bits of resolution. These features should also ideally be implemented through hardware in the FPGA to fully utilize our board.

Tier 2
Tier 2 represents our projects secondary objective of implementing a controller which acts alongside the logger. This controller should start as a simple proportional controller and be scaled to PID control if proportional control proves insufficient for laser control.

Tier 3
Tier 3 represents system modularity, which would allow a dual channel control system to expand to quad channel by running another controller alongside it in parallel. This tier is considered our project’s stretch objective because of our limited time.

=Design= The development choice we implemented was done in Python using Jupyter Notebook. Red Pitaya allows us to open and run python programs using Jupyter development environment. The mercury library allows us to map the inputs and outputs which minimizes the amount of code we need on our end. The Red Pitaya Python library interacts with FPGA modules to read in analog input and generate analog output. By using this library, we can easily generate and read signals which allows us to implement our control loop.

When we began the project, the files and documentation passed on to us from the previous senior design group did not effectively address the design concerns that our sponsor dictated at the outset of our tenure on the project. As discussed in the specifications section above, the main goals were to implement dual-channel data acquisition and dual-channel analog output such that a PID loop could be implemented in custom hardware instantiated in FPGA. The previous design fell short of this in several ways. Their system was composed of a Xilinx Vivado project that contained components for analog signal acquisition, decimation, Figure of Merit calculation, PID control, and analog signal output. While components such as these are useful in addressing the problem, the critical flaw in this system was that it did not target the STEMlab 125-14. The Vivado project did not make use of the board’s constraint files, so the bitstream generated by the project was incompatible. Additionally, if the FPGA portion of the design required a software counterpart such that the end-user would be able to control the functionality in the FPGA and save the data collected from the ADCs. Due to these shortcomings in the initial design, continued development was justified, and we began our work on the project.

At the outset of our work on the project, it seemed like our work would consist of two parts: editing the previous team’s Vivado project to conform to the STEMlab 125-14’s constraint file and developing a software system for interacting with the FPGA system. While studying the documentation for the STEMlab 125-14, we discovered that Red Pitaya offered a complete FPGA system that contained all the modules necessary to achieve our design goals. These included an Analog Signal module for reading in data from the ADCs and writing data out to the DACs, an Oscilloscope module for the decimation and filtering of the data incoming from the Analog Signal Module, a PID module for implementing a Proportional-Integral-Derivative control loop, an Arbitrary Signal Generation module for generating outputs (independently from the PID module or interacting with it) and a Daisy Chaining module for synchronizing functionality across multiple STEMlab development boards. A block diagram of Red Pitaya’s FPGA system may be seen below.



All the modules in the FPGA system were linked to memory-mapped registers such that software running on the Processing System of the Zynq 7000 SoC could read and write to the FPGA modules to configure them and collect data from them. Red Pitaya did not provide a Vivado project to enable visual editing of the FPGA system. Instead, they provided a collection of TCL scripts that built the bitstream for the FPGA system directly from source files. Part of our work involved building the Vivado project using Xilinx Vivado command-line tools such that the FPGA system can be opened and examined in Vivado, allowing the end-user to edit the existing system components or add entirely new FGPA modules. In this way, the pieces of a system using our work may be selectively placed in software or hardware. We felt that this was a crucial step towards achieving the flexibility desired for our project.

Alongside the FPGA portion of our design solution, we developed a software solution to serve as the intermediary between the user and the FPGA system. This system was implemented using the Jupyter notebook development environment that was included with Red Pitaya OS and accessible through the web interface. It uses the Red Pitaya Python library to interact with the Oscilloscope module and Arbitrary Signal Generation modules. Our Python program also uses the Pandas Python library to record incoming analog signal information to a CSV file. With these systems, we achieve dual-channel data acquisition with decimation and filtering, data logging, and dual-channel analog output. We also implemented a form of control loop, but it was not the full PID loop in hardware that we initially set out to create. We implemented a proof-of-concept Proportional control loop in software instead since the Red Pitaya Python library was not equipped with the ability to interact with the PID control module that is included in the Red Pitaya FPGA system. The next section will explore how effectively these various requirements were addressed.

=Validation=

=Design Evaluation= Our initial plan for testing our system was to use the laser system provided by Thorlabs near the beginning of our project. To do this we would have captured and recorded the emissions from the laser diode and used our control loop to respond to it, adjusting the current supplied to the laser diode to achieve the desired emissions. However, after developing our Python program and meeting in the lab to perform the testing the system was no longer functioning. We had verified the functionality of the laser system when it arrived last semester, but the laser diode would not produce a beam for our system test. We spent quite some time troubleshooting the system, checking the charge of the batteries, and verifying continuity between solder points. It appeared that the laser diode was no longer functioning. After consulting with our sponsor about the issue, we decided to avoid attempting replacement of the laser diode and produce a new verification plan.

To proceed with verification of our system we created a sort of “hardware-in-the-loop” simulation. One STEMlab development board was used to generate a dummy analog output signal in lieu of the photo diodes in the laser system by using the DACs and the Analog Signal Generation module included in the FPGA system. A second STEMlab development board was used to capture this analog signal using the DACs and the Oscilloscope module of the FPGA system. Since these modules run independently and in parallel with each other, this process could be performed on a single board with the two SMA outputs connecting to the two SMA inputs, but we decided using two separate boards was a more effective way of demonstrating our system.

The Python code for generating, capturing, and plotting the data for system verification may be seen in EXPO Presentation Code section of the Appendix and a plot of some example data gathered using it may be seen in Figure 2. To demonstrate that the data displayed in the plot is what we expected, the configuration of the system will be detailed below.

The ADCs onboard the STEMlab 125-14 development boards capture 14-bit values at a sample rate of 125 MS/s and the minimum decimation factor that the Oscilloscope module is designed to accept is 8. Since every factor of two in decimation results in an additional bit of resolution in the information collected and proportional decrease in sample speed, this effectively gives 17-bit values at 15.625 MS/s. The size of the buffer in the Oscilloscope module is 16384. This dictates how many 17-bit values may be accumulated before they must be retrieved by the software portion of the system. The following equation demonstrates the usage of this information to determine the expected time that it takes to fill the buffer once. The calculation matches what is seen on the plot, effectively verifying that the dual channel analog output, dual channel analog input, decimation, and logging functionalities of our design are working as intended.

The two initial design goals we were unable to implement and therefore were unable to test were the daisy chaining functionality for analog I/O expandability and hardware PID control. =Budget= Due to utilizing the Red Pitaya, our project utilized very little of its budget. Only purchasing a single extra Red Pitaya over the course of our project so all three team members could work in parallel.



=Schedule=

=Future Work= The main design goals our team were unable to address were system modularity and PID control. We recommend that future teams avoid utilizing Python as their primary means of control over the system. Python provides no access to the daisy-chain synchronization, or PID FPGA modules included in the standard .bit file provided by Red Pitaya. Furthermore, we recommend that a team approaching this project in the future should avoid using the Red Pitaya web development framework due to the broken source code the company provides, and the general lack of documentation and support.

This leads us to suggest future teams use a C implementation which would have access to a wider range of FPGA modules. By utilizing the FPGA for PID control, the system would have a much higher potential for speed and latency by doing control computations at the hardware level. Additionally, access to the daisy chain module would open the door for system modularization, allowing the next group to meet our project’s stretch objective. A python implementation that accesses C programs could reach similar levels of functionality, however; developing in multiple langauges tends to create a more needlessly complex solution.

Some of the biggest shortcomings in our project could have been more easily resolved by finding a means or real-time diagnostics. Future teams should invest time in researching any available diagnostic systems for their chosen mode of Development.

Lastly, we recommend future teams spend more time investigating the Pound Drever Hall laser setup earlier in the semester. The laser diode included in the setup is extremely sensitive and can break a long period of time after being damaged, so it is important to safely store the test setup and validate its functionality on a frequent basis. This will give a longer lead time for any necessary repairs or give the team longer to create a more robust testing solution than the simple Hardware in loop simulation used for our final testing.

=Team Members= Jacob Jackson Major: Computer Engineering Email: jack0501@vandals.uidaho.edu

Taylor Stewart Major: Computer Engineering Email: stew5398@vandals.uidaho.edu

Cameron Williams Major: Computer Engineering Email: will6599@vandals.uidaho.edu

=Additional Documentation= Project Schedule Meeting Minutes Client Interview