|BeagleBoneBlack Software Organization for Digital Down Converter|
Starting at the bottom, there is the Beagle Bone Black GPIO hardware. The only digital pins required are those necessary for a bi-directional SPI interface. These signals are always taken from an I board. This board uses sets of 6 pins and includes power enable controls for the device along with a digital switch to isolate the io pins. Depending on the I board port used the pins can be accessed directly from user space or have a device tree applied to make the pins accessible to the PRUs. Port 2 of the I board has the pins accessible to the PRUs via register 30/31, while all other port have all pins directly accessible to the CPU.
The Xtst utility is the simplest and accesses the GPIO pins directly from user space. This utility accepts simple command line primitives to read and write words to the SPI interface. These can be strung together using Bash scripts to accomplish higher level programming operations that can be repeated. The advantage is simplicity – no PRU code is required. The down side is the SPI performance is quite low. These scripts are good for simple tests of new VHDL focusing on the SPI and digital operations.
The PRU0/1 software manipulates the SPI pins directly and is capable of high speed serial operations. When using the PRUs all SPI accesses pass through them. The only non PRU access to the port/board are the power enables which are separate lines on the I board and are controlled by its software. The PRU interface to CPU software is simple and limited to two basic commands: SPI word read/write, and SPI streaming read. The CPU writes a command and parameters to a PRU SRAM memory location. If the command is a read/write the results are returned to the SRAM and the PRU signals its conclusion by clearing the SRAM command. If the command is streaming, the PRU continuously reads the SPI interface saving the results to a DRAM circular buffer accessible by the CPU. The PRUs update the DRAM head pointer in their SRAM. While streaming, the PRU checks for a new or different command every 2048 SPI words read. PRU0 actually controls the GPIO pins for the SPI while PRU1 writes the streamed samples to DRAM. This is a similar approach used successfully in other projects (e.g. PRU benchmarks, 10MSPS ADC rev1, and rev2) PRU0 controls the speed of the SPI interface by how many 5nS instruction cycles it uses between SPI clock transitions. A nominal value of 40 clock (200nS) or 4.8MBits/second was tested using a 6” IDC cable producing error free transfers.
The X board software interfaces with the PRU code via PRU SRAM for SPI accesses and DRAM for streaming samples. This software provides a standardized ADC interface (get 2k samples, flush samples, get samples per second, …) and a standardized mixer interface (set LO frequency in Hertz). The X board software deals with the FPGA programming model to configure the mixer frequency, stream samples 2k at a time, select the FPGA fifo source stream (i.e. pick an internal channel of data), and configure an internal test pattern for use or actual ADC inputs. Depending on the fifo source stream selected the format and rate of the data changes. For example the raw ADC data is unsigned 12 bit real samples at the sample rate (e.g. 10MSP or 66MSPS). The final output source is the decimated IQ data stream which may be 100k samples per second of 16 bit signed I values and 16 signed bit Q values.
The Xboard interface is used by the standalone Xutil software to provide high level and higher performance tests of ADC/Mixer operations. Like Xtst, this is a command line utility with which operations can be strung together via Bash scripts. Specific tests of interest include the ability to snapshot 2k of samples and save to a CSV for analysis and the ability to continuously monitor a fixed pattern test to evaluate SPI error rates and speed.
Finally the X board interface can be used with other existing utilities (via the common ADC and Mixer interfaces) . Examples include a general workbench server that ties together multiple hardware modules (examples of ADC power spectra estimation and here and multi-board control here and source code); a SDR Server (examples here and here and source code), an ADC Http viewer (source code with examples to be covered in a future post).Related:
Prj141 Digital Down Converter
Prj141 Digital Interface
Prj141 Filter Design
Prj141 Filter Evaluation
Prj141 LX9 Utilization
Prj141 Higher Sampling Rates