{"id":514765,"date":"2017-12-14T03:30:04","date_gmt":"2017-12-14T02:30:04","guid":{"rendered":"http:\/\/antonpotocnik.com\/?p=514765"},"modified":"2017-12-14T03:45:11","modified_gmt":"2017-12-14T02:45:11","slug":"red-pitaya-fpga-project-4-averager","status":"publish","type":"post","link":"https:\/\/antonpotocnik.com\/?p=514765","title":{"rendered":"Red Pitaya FPGA Project 5 \u2013 High-Bandwidth Averager"},"content":{"rendered":"

Introduction<\/h1>\n

Up to now we discussed simple projects that demonstrated basic ideas behind FPGA programming. In this post we will go a step further and create a data acquisition system. In particular, we will implement a High-Bandwidth Averager, which will acquire a sequence of measurements at the highest sampling rate (125 Msamples\/s) and on each trigger accumulate these measurements on the on-chip Block Random Access Memory (BRAM). Our approach can be extended and ultimately used for ultra-sensitive homodyne or heterodyne detection in radio systems<\/a>, radars, nuclear magnetic resonance<\/a> (NMR) or even superconducting quantum circuits<\/a>.<\/p>\n

\"\"<\/a><\/p>\n

FPGA acquisition system will require more comprehensive post-processing options such as data analysis, visualization and storage. For this reason we will take Pavel Demin<\/a>‘s approach and create a client program, running on any computer in the network, and a server program, running on the Red Pitaya’s Linux. Client will set configuration, start measurements, and download data from the server via a TCP\/IP protocol.<\/p>\n

This guide is split into to two parts, in the first part we will describe FPGA logic behind the Averager and in the second part we will demonstrate how to setup server on Red Pitaya\u2019s Linux and a python client on a local computer. The purpose of this project is to learn how to store and read-out acquired data from the FPGA programmable logic. <\/p>\n

Building the Project<\/h1>\n

To start off download the project from github as described in previous posts. Then build custom IP cores by navigating to \/redpitaya_guide base folder in Vivado\u2019s tcl console and execute<\/p>\n

\r\nsource make_cores.tcl\r\n<\/pre>\n
This will create the following IP cores in the folder tmp\/cores<\/em> needed for Averager project: axis_red_pitaya_adc_v1_0<\/em>, axis_red_pitaya_dac_v1_0<\/em>, bram_switch<\/em>, axi_bram_reader <\/em>and axis_averager_v1_0<\/em>. The first two are taken from Pavel Demin, as discussed in the previous post,\u00a0<\/a> the last three are custom made for accumulation and read-out of measured data.<\/p>\n
When custom cores are successfully generated, build the project by appropriately modifying the make_project.tcl <\/em>script and execute it in the Vivado\u2019s tcl console as described in Project 1<\/a><\/p>\n
\r\nsource make_project.tcl\r\n<\/pre>\n
FPGA part<\/h1>\n
The general block design of the Averager is composed of five main parts: processing system, configuration, data acquisition, triggering and averaging as shown in the figure below. We have also added a signal generator part for testing the data acquisition system. The signal generator creates a sine tone on both Red Pitayas’ DAC output ports with frequency 125 MHz\/32 = 3.90625 MHz. This design is based on block design from Project 4<\/a>, where processing system, data acquisition and signal generator hierarchies are described in greater detail.<\/p>\n
<\/a>
Block Design Overview<\/p><\/div>\n
Averager Hierarchy<\/h3>\n
High-Bandwidth Averager collects a number of consecutive measurements from the ADC block, reads the same number of values stored in the BRAM memory and writes the sum of collected and read values back to the memory. This is repeated on every trigger signal. Each memory location, therefore, contains a sum of ADC values always measured at the specific time after the trigger.<\/p>\n
Acquisition begins with a release of a reset<\/em> signal. At this points the Averager sets BRAM memory locations to zero and awaits for a trigger. On each trigger the Averager accumulates NSAMPLES<\/em> number of ADC values, adds them to the previous measurements and writes the sums back to the memory. After NAVERAGES<\/em> number of triggers the Averager stops and asserts the finished<\/em> signal. <\/p>\n
The finished<\/em> signal has two functions: first it lets the program running on Red Pitaya’s Linux know that acquisition is completed and results can be read. The second function is to re-route the BRAM PORTA line of the Block Memory Generator from Averager to AXI BRAM Reader block. This gives a program running on the processing system\/Linux access for reading BRAM memory.<\/p>\n
\"\"<\/a>
Averager Hierarchy<\/p><\/div>\n
The key feature of our averaging algorithm is its capability to read and write data to the BRAM in a single clock cycle. Averager is ready for the next trigger on the second clock cycle after the previous measurement sequence is finished. This reduces the dead time during averaging and with that the overall duration of data acquisition. The High-Bandwidth Averager can measure up to approx. 65k, 32-bit wide ADC values set by the 2.1 Mb<\/a> size of the on-chip BRAM memory. However, the FPGA implementation might suffer from timing issues when using all of the resources. If we need more measurement storage we can use Red Pitaya’s on-board 512 MB DDR memory. We will show how to do that in future projects. Reading and writing in a single clock cycle requires Averager to use both read (PORTB) and write (PORTA) ports of the True Dual-Port Block Memory Generator and a special BRAM Switch block to share the BRAM Generator’s reading port between the Averager and the AXI BRAM Reader. The later is connected to the Processing System via the AXI interface.<\/p>\n
[expand title=”Implementation details”]
\nThe BRAM generator has to be set to Standalone, True Dual Port core. We set the maximum number of entries to 1024 and width to 32 bit. Make sure that no reset input is used and Always Enable option is used for both ports. The Averager IP core has nsamples<\/em>, naverages<\/em>, trig<\/em>, user_reset<\/em> and data_in<\/em> input ports. In addition it has two BRAM ports for reading and writing to the BRAM memory and the finished<\/em> and averages_out<\/em> output ports. The later contains a number of averages currently done and it is mainly used for debugging. finished<\/em> signal is connected to the 1 LSB and averages_out<\/em> is connected to the 7 MSBs of the led_o<\/em> external port.<\/p>\n
To view the Averager’s Verilog code right-click on the block and select Edit in IP Packager<\/em>. The averaging is coded as a state machine with 5 states. The 0th<\/sup> state clears the registers, the 1st state prepares registers for writing zeros to the BRAM memory, the 2nd state performs the zero writing, the 3rd state prepares addresses for reading and writing and the 4th state performs reading and writing to the BRAM generator. Once the number of averages is met the system goes and stops in the 5th state.
\n[\/expand]<\/p>\n
 <\/p>\n
<\/h3>\n
Configuration GPIO Hierarchy<\/h3>\n
In the previous project we learned how to read and set registers on the FPGA logic. We will use the same approach here for setting configuration values such as number of samples, number of averages and trigger rate. We will use the second GPIO port as an input to indicate the completion of the averaging. 32 bits of the output port contain four 8-bit configuration values: log2NAVERAGES, log2NSAMPLES, trigger_select<\/em> and control<\/em>:<\/p>\n
gpio_out1[31:0] = 31<\/sub>[{log2NAVERAGES<\/em>} {log2NSAMPLES<\/em>} {trigger_select<\/em>} {control<\/em>}]0<\/sub><\/p>\n
gpio_in2[31:0] = 31<\/sub>[{31-bit empty} {1-bit finished}]0<\/sub><\/p>\n
For now only the LSB of control<\/em> value is used as a user_reset<\/em> bit. When this bit becomes asserted averaging resets and when it is disserted averaging starts with the next trigger signal.<\/p>\n
If you ever need more configuration output bits you can use Pavel Demin\u2019s axi_configuration_v1_0<\/em> IP core with a custom number of bits in a single output port. axi_configuration_v1_0<\/em> can be found in redpitaya_guide\/core<\/em> folder and is automatically created when running make_cores.tcl<\/em> script.<\/p>\n
\"GPIO<\/a>
GPIO Hierarchy<\/p><\/div>\n
<\/h3>\n
Trigger Hierarchy<\/h3>\n
Trigger hierarchy creates a low frequency clock, which is used as a trigger for the Averager. The principle is very similar to the one in the LED blink project where we used an input clock to trigger a binary counter and select a specific bit of the counter\u2019s 32-bit output. Here we implement this principle in a custom RTL module. The selected bit is specified by the  trigger_select<\/em> configuration value, which we extract from gpio1_io_o<\/em>[15:8] port using Slice core.<\/p>\n
<\/a>
Trigger Hierarchy<\/p><\/div>\n
Trigger rate after the selector module<\/a> is calculated as<\/p>\n
trigger_rate = f0 \/ 2<\/em>^(26 - trigger_select + 1)<\/em>,<\/code><\/p>\n
where f0<\/em> = 125 MHz is the ADC clock frequency, +26 is an offset set in the selector module<\/em> and +1 comes from the fact that binary counter<\/em> is increased by one on every clock cycle, which makes the frequency of its first LSB equal to f0<\/em>\/2. This is a very simple trigger that might not yield the best performance, but is sufficient to demonstrate the basic idea behind the Averager. Since our trigger rate is commensurate with DAC signal frequency the Averager will always start a measurement at the same phase of the signal. This will result in full averaged signal even for millions of averages. If trigger rate would be incommensurate relative to f0<\/em>, the average would converge to zero.<\/p>\n
A more realistic design would include an external trigger. This could be brought into the programmable logic using exp_#<\/em> port.<\/p>\n
 <\/p>\n
Software part<\/h1>\n
Server<\/h3>\n
To setup a server on Red Pitaya’ Linux, copy server.c<\/em> file from the project folder 5_averager\/server<\/em> to the folder on the Linux, using for example WinSCP. With Putty compile and run the server by typing<\/p>\n
\r\ngcc -o server server.c\r\n.\/server\r\n<\/pre>\n
Server is listening on port 1001 for incoming connections. After a connection is established client can send parameters, nsamples<\/em>, naverages<\/em> and trigger_select<\/em>, and at the end request a measurement start. Parameters are sent as 32-bit values, where 4 MSB represent parameter identification number and 28 LSB the parameter value.
\nAfter start_measurement<\/em> is received server releases the user_restart<\/em> bit and waits for the finished<\/em> signal from FPGA. When the measurement is finished server reads the data from BRAM memory and sends it to the client.    <\/p>\n
Client<\/h3>\n
Client program is written in Python 2.7 and uses Qt Graphical User Interface (GUI). If you don’t already have python on your computer, I recommend installing Python(X,Y)<\/a> for windows users. This collection includes all the required packages including Qt Designer and Spyder (IDE). <\/p>\n
averager.py<\/em> and averager.ui<\/em> files can be found in the project directory 5_averager\/client<\/em>. I would suggest looking into the GUI file averager.ui<\/em> by opening it with the Qt Editor<\/em> and checking the element’s properties. Also reading python code averager.py<\/em> using Spyder<\/em> or any other text editor might be interesting. <\/p>\n
My preferred way of running the client is by executing the following line in IPython (Qt) enhanced console<\/p>\n
\r\nrun averager.py\r\n<\/pre>\n
Averager’s GUI should be intuitive. Enter Red Pitaya’s IP address and press Start<\/em> button. If you didn’t connect Red Pitaya’s OUT1 port to the IN1 port you will see a noisy signal. After connecting the two ports and pressing the start button a sinusoidal signal will appear in the graph section of the GUI as shown in the left screenshot below.
\n
\"\"<\/a>
Python Client Program
<\/p><\/div><\/p>\n
You can play with different parameters. I recommend setting trigger rate<\/em> to f0\/<\/em>1024, nsamples<\/em> to 1024 and naverages<\/em> to 262114. The measurement should take approximately 4 s. It will be hard to detect differences between highly averaged measurements in a time domain. To see how noise reduces when increasing naverages<\/em> plot FFT in log scale by checking FFT<\/em> and Log Scale<\/em> boxes and choose Abs<\/em> value.<\/p>\n
Scale<\/em> check box re-scales the 14-bit ADC values into an appropriate voltage range. The scaling values depend on your jumper setting on the Red Pitaya board and slowly change with time. Since my scaling parameters might differ from yours, you can calibrate your Red Pitaya with known voltage sources and modify the scaling coefficients hard-coded in the averager.py<\/em> file.<\/p>\n
Conclusions<\/h1>\n
In this guide we have demonstrated how to efficiently write to the BRAM memory and read-out values at the end of the measurement. One could use Averager as an oscilloscope with a single average. However, to exploit all its capabilities one might need to extend it with an external trigger option or add a module that would detect signal transitions and issue automatic triggers to the Averager. In any case, I hope this project gives you enough material to further pursue your own FPGA ideas. <\/p>\n
 <\/p>\n\n\n\n
<< Red Pitaya Project 4 – Frequency Counter<\/a><\/td>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
 <\/p>\n
References<\/h1>\n