{"id":519284,"date":"2017-01-13T10:13:17","date_gmt":"2017-01-13T09:13:17","guid":{"rendered":"http:\/\/antonpotocnik.com\/?p=519284"},"modified":"2017-12-14T03:35:58","modified_gmt":"2017-12-14T02:35:58","slug":"red-pitaya-fpga-project-4-frequency-counter","status":"publish","type":"post","link":"https:\/\/antonpotocnik.com\/?p=519284","title":{"rendered":"Red Pitaya FPGA Project 4 – Frequency Counter"},"content":{"rendered":"

Introduction<\/h1>\n

On the way to a powerful acquisition systems let us make a quick detour and create a useful and simple project – the Frequency Counter<\/em><\/a>. Yes, to measure frequencies one can use Red Pitaya’s native apps such as Oscilloscope<\/a> or Spectrum Analyzer<\/a>, however, our program will be able to determine frequencies with much higher resolution and at the same time we will learn how to use Red Pitaya’s 125 Msamples\/s 14-bit ADC and DAC peripherals in the FPGA program.<\/p>\n

<\/a>This project contains two separate parts: the data acquisition<\/em> part with frequency counter and LED data display and the signal generator<\/em> part. To communicate with these two parts we use the General Purpose IO block for setting configuration values and reading the counter output.<\/p>\n

The frequency counter will be implemented in the reciprocal counting scheme <\/a>where a period of time of a predefined number of signal oscillations is measured and then inverted and divided by the number of oscillations. Such scheme can yield a much better frequency resolution, especially for low frequency signals, compared to the conventional method where number of signal cycles are counted in a predefined gate time.<\/p>\n

Building the Project<\/h1>\n

To start off download the project from the github<\/a>. First, build the necessary custom IP cores by navigating to \/redpitaya_guide<\/em> base folder\u00a0in Vivado\u2019s tcl console and execute<\/p>\n

\r\nsource make_cores.tcl\r\n<\/pre>\n
This will create all custom IP cores in the \/redpitaya_guide\/t<\/em>mp\/cores<\/em> folder. In this project we will use axis_red_pitaya_adc <\/em>and axis_red_pitaya_dac <\/em>IP cores from Pavel Demin which are handling fast ADCs and DACs peripherals on the Red Pitaya board. I only added\u00a0a global clock buffer\u00a0to the axis_red_pitaya_adc<\/em> core for an optimal performance under Vivado 2016.3 and higher version.<\/p>\n
Once the custom cores are created build the project by appropriately modifying the make_project.tcl <\/em>script and execute it in Vivado\u2019s tcl console with<\/p>\n
\r\nsource make_project.tcl\r\n<\/pre>\n
Project overview<\/h1>\n
The full block design of the frequency counter project is composed of six parts: Processing System, GPIO, Signal Generator, Data Acquisition, Frequency Counter and Signal Decoder block as shown in the figure below.<\/p>\n
<\/a>
Block Design Overview<\/p><\/div>\n
These parts will be described in detail below. You can skip the lengthy description and go directly to the fun part at the end of the post.<\/p>\n
Processing system<\/h3>\n
Let\u2019s start with the most common part – the processing system IP core. Together with the AXI Interconnect and Processor System Reset block these are the most common blocks in most of the Zynq 7000 FPGA applications. Since they take quite some space and have a lot of connections we will join them in a single hierarchy block, so they will take less space and make block design more transparent. To create a hierarchy select desired blocks, right click and select Create Hierarchy<\/em>. From now on we will put in hierarchies most of the blocks with related functionality.<\/p>\n
\"Processing<\/a>
Processing System 7 Hierarchy<\/p><\/div>\n
General Purpose Input-Output Core<\/h3>\n
In the previous project we have learned how to write and read from the FPGA logic. We will use the same approach here for setting configurations such as number of cycles and signal generator’s phase increment. We will use the first GPIO port as an input to make results of the frequency counter available to a program running on the Linux side. Second GPIO port will be used as an 32-bit output port containing 27-bit phase_inc <\/em>value for the signal generator and 5-bit log2Ncycles<\/em> value for the frequency counter:<\/p>\n
gpio2_io_o[31:0] = 31<\/sub>[ {27-bit phase_inc<\/em>} {5-bit log2Ncycles<\/em>} ]0<\/sub>.<\/p>\n
If you ever need more configuration output bits you can use Pavel Demin\u2019s axi_configuration<\/em> IP core with a custom number of bits in a single output port. axi_configuration<\/em> can be found in the redpitaya_guide\/core<\/em> folder, which is automatically created with the make_cores.tcl<\/em> script as described above.<\/p>\n
Signal Generator<\/h3>\n
Signal Generator hierarchy creates a sin(\u03c9t<\/em>) and cos(\u03c9t<\/em>) signals at the two DAC output ports with a user defined frequency. The analog signal is generated with three blocks: DDS compiler<\/em> for calculating 14-bit sinusoidal values, Clock Wizard<\/em> to create a double clock frequency which allows setting the two DAC channels on each input clock cycle and AXI-4 Stream Red Pitaya DAC<\/em> core for setting signal values to the external DAC unit. We will use\u00a0125 MHz adc_clock<\/em> as input clock to achieve 125 Msamples\/s data rate.<\/p>\n
<\/a>
Signal Generator Hierarchy<\/p><\/div>\n
Frequency, amplitude and other parameters can be set in the Direct Digital Synthesizer (DDS) re-customization dialog. Current DDS core settings will create sin(\u03c9t<\/em>) on one and cos(\u03c9t<\/em>) on the other DAC channel with maximal amplitude of +\/- 1V (maximal range) on both channels.<\/p>\n
The synthesized signal frequency is in the DDS compiler determined by a phase increment value at each clock cycle. A nice description of the signal synthesizer operation can be found in the DDS compiler product guide<\/a>. The signal frequency can be set fixed at the design stage by choosing Fixed<\/em> Phase Increment in the DDS re-customization dialog. In this case the dialog automatically calculates the required constant phase increment for a desired frequency and frequency resolution. Note that the output frequency will be a divisor of the clock frequency and might therefore deviate from the requested frequency.<\/p>\n
Since we want to change the frequency during an operation we choose Streaming<\/em> Phase Increment in the re-customization dialog, which requires a phase increment value to be continuously supplied to the S_AXIS_PHASE input interface. AXIS interface implements the AXI4-Stream protocol<\/a> developed for fast directed data flow. It implements the basic handshake using at least tvalid<\/em> and tready<\/em> signals, however, we will neglect even those for our nearly constant phase increment value. To create a continuous stream of the user defined values we use Pavel Demin’s AXI4-Stream Constant<\/a> IP core, which converts 32-bit input bus to the AXIS master interface. For the input we take 27-bit phase_inc <\/em>value from the gpio2_io_o<\/em> port using Slice IP core. Calculation of the phase_inc<\/em> for a desired output frequency will be discussed in the last part of the post.<\/p>\n
Data Acquisition<\/h3>\n
AXI4-Stream Red Pitaya ADC Core<\/h4>\n
The first block in the Data Acquisition hierarchy is the axis_red_pitaya_adc_v1_0 IP core with two main features. First, it converts the external 125 MHz clock from adc_clk_a<\/em> and adc_clk_b<\/em> differential external ports into our programmable logic as a adc_clk<\/em> clock. Second, it reads the ADC data from two input channels which becomes available on each adc_clk<\/em> clock cycle and makes it available over the AXI Stream (AXIS) interface M_AXIS<\/em>. axis_red_pitaya_adc_v1_0<\/em> IP core uses two ports of the AXIS interface, the axis_tvalid<\/em> port which is always asserted and the axis_tdata<\/em> a 32-bit data port with new measurements available on every clock cycle. 32-bit axis_tdata<\/em> contains 16-bit\u00a0channel 2 value and 16-bit channel 1 value:<\/p>\n
M_AXIS_tdata[31:0] = 31<\/sub>[ {16-bit ADC2 value} {16-bit ADC1 value} ]0<\/sub>.<\/p>\n
Since Red Pitaya has 14-bit ADC the 16-bit value has two most significant bits set to either 00 or 11 depending on the sign of the measured value. It is instructive to have a look at the Verilog code of\u00a0 AXI4-Stream Red Pitaya ADC core<\/a>. Note that Red Pitaya’s ADC core has an additional output port (adc_csn)<\/em> connected to the external port adc_csn_o<\/em> for a clock duty cycle stabilization.<\/em><\/p>\n
\"\"<\/a>
Data Acquisition Hierarchy<\/p><\/div>\n
Signal Split\u00a0 Module<\/h4>\n
The second block in the hierarchy is the signal_split<\/em> RTL module. It transforms ADC output interface M_AXIS with two channel values into two M_AXIS output interfaces each containing a single channel value. The module has a very simple Verilog code, which can be found on github<\/a>.<\/p>\n
It is interesting to note that if you want to create an input or an output interface on a RTL module, simply name the input or output ports with a standard interface notation (see Vivado IP user guide<\/a>). For example, in the signal_split RTL block port names: S<\/em>_AXIS_PORT1_tdata <\/em>and S<\/em>_AXIS_PORT1_tvalid<\/em> are automatically combined into an S<\/em>_AXIS_PORT1<\/em>\u00a0interface.<\/p>\n
Frequency Counter Module<\/h3>\n
The frequency counter hierarchy is build around its main RTL module frequency_counter<\/em> with two main inputs: S_AXIS_IN<\/em> interface containing measured single channel ADC signal and Ncycles, <\/em>a value that specifies a number of signal oscillation for time measurement. Since exact number for Ncycles<\/em> is not important user specifies a 5-bit logarithmic value\u00a0log2Ncycles<\/em> via the gpio core. Ncycles<\/em> is then calculated as<\/p>\n
Ncycles<\/em> = 2^log2Ncycles<\/em><\/p>\n
using a pow2<\/em> RTL module. See the figure below.<\/p>\n
\"\"<\/a>
Frequency Counter Hierarchy<\/p><\/div>\n
The verilog code<\/a> of the\u00a0frequency_counter\u00a0<\/em>RTL module has three main parts. The first part directly wires the S_AXIS_IN<\/em> to the M_AXIS_OUT<\/em> interface so that data is\u00a0 transferred to the next block for processing. Instead, we could split the AXIS interface before the module, however, this would require an additional IP core – the AXI3-Stream Broadcaster.<\/p>\n
The second part of the code sets the state<\/em> buffer depending on the measured signal value relative to the high or low threshold values. If the signal is above the high threshold value state<\/em> buffer is set to one and if the signal is below the low threshold value state<\/em> buffer is set to 0. Using two threshold values helps to prevent false state<\/em> transitions in case of noisy data.<\/p>\n
The third part increments counts<\/em> register on each clock cycle, increments cycles<\/em> register on each positive state<\/em> transition and clears cycles<\/em> and counter<\/em> registers when cycles<\/em> exceeds Ncycles<\/em>. Before clearing the counter<\/em> its value is copied to the counter_output<\/em> register which is wired to the output port. The result of the frequency counter module is therefore a number of clock cycles in a time of Ncycles<\/em> signal oscillations, updated on each Ncycles<\/em> signal oscillations. The frequency is then calculated as<\/p>\n
frequency<\/em> = Ncycles<\/em>\/counts<\/em>*125 MHz.<\/em><\/p>\n
Signal Decode Module<\/h3>\n
The final block in the ADC signal chain and in the block design is the signal_decode<\/em> RTL module. Its purpose is to display the ADC value on the Red Pitaya LED bar mostly for visual effects. The implementation is a simple 8-bit decoder <\/a>from Vivado’s Language Templates. In signal_decoder.v<\/a> the three MSBs of the ADC value are decoded and displayed on LEDs. However, if your ADC range jumpers are set to +\/- 20 V instead of +\/-1 V you will see no activity when connecting the output of the Red Pitaya’s DAC to the input of its ADC port. In this case BIT_OFFSET<\/em> parameter can be set to 4 to decode 4th, 5th and 6th signal’s MSBs. Shifting the bit position is related to signal amplification by a factor of 2. You can play with this value if the range is not optimal.<\/p>\n
Fun Part<\/h1>\n
We are ready to test the frequency counter. Connect the Red Pitaya’s OUT1 port to the IN1 port. Save the project, create bitstream and write it to the FPGA as described in previous projects.<\/p>\n
Next, copy the counter.c<\/em> <\/a>program found in redpitaya_guide\/4_frequency_counter\/server<\/em> folder to Red Pitaya’s\u00a0 Linux, compile it and execute it as shown in the figure below.<\/p>\n
<\/a>
Demonstration of counter.c program<\/p><\/div>\n
The program can be used with the following parameters:<\/p>\n
\r\n.\/counter {log2Ncycles} {frequency_Hz}\r\n<\/pre>\n
Keep in mind that the frequency resolution depends on the number of clock counts within Ncycles<\/em> signal oscillations. Low frequency signals require small Ncycles<\/em> and high frequencies signals require large Ncycles<\/em>.\u00a0 The maximal number of counts<\/em> can be 2^32, the highest DAC frequency can be 125 MHz\/4 = 31.25 MHz and the lowest frequency can be approx. 1 Hz. The conversion from the desired frequency into the phase_inc<\/em> is done in the counter.c<\/em><\/a>.<\/p>\n
When setting the frequency to 2 Hz the LED bar on the Red Pitaya board looks very much like Knight Rider’s lights \ud83d\ude42<\/p>\n\n\n\n
<< Red Pitaya Project 3 – Stopwatch<\/a><\/td>\nRed Pitaya Project 5 – Averager >><\/a><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
References<\/h1>\n