Posted by

John on Jan 20, 2013 in

Uncategorized |

0 comments
There are precisely 1,048,576 complex data points that come in with each SETI@Home Work Unit where each the real and imaginary components are both represented by single-precision floating point numbers each. These one million odd data points are stored in a variable named "DataIn", with the number of data points is stored in a variable called "NumDataPoints." These variables are defined in the analyzeFuncs.cpp file as such: typedef float sah_complex[2]; sah_complex *DataIn; int NumDataPoints; In the CUDA version of SETI@Home, this dataset is passed into the memory of the graphics card and stored in its local memory. Afterwards, a set of 58,347 "Chirp/Fft Pairs" are generated and also passed and stored into the memory of the graphics card as well. The total number of Chirp/Fft Pairs is stored in a variable called num_cfft. These variables are defined as such: typedef struct { double ChirpRate; int ChirpRateInd; int FftLen; int GaussFit; int PulseFind; } ChirpFftPair_t; int num_cfft; ChirpFftPair_t *ChirpFftPairs; After these two data structures have been loaded by the seti_analyze function, which holds the core of the SETI@Home analysis, the seti_analyze function starts to iterate over each of these 58,347 Chirp/Fft Pairs and performs an analysis on the input data based on the parameters of each Chirp/Fft Pair. Here is some more detailed descriptions: Chirps the original DataIn data using the ChirpRateInd and ChirpRate values from the current Chirp/Fft pair, along with another value that comes from the work unit called "subband sample rate." After the original data set has been chirped, a discrete fast fourier transform is performed on the chirped data using the Fast Fourier Transform in the West library. The fft length is also specified as a parameter in the Chirp/Fft Pair. The results from the Fft are then processed by a function called "GetPowerSpectrum," which simply squares each of the components of the data passed in. After these 3 steps, the resulting data is processed, depending on certain values with the following functions which are not candidates for FPGA acceleration at this time: FindSpikes FindAutocorrelation analyze_pot It should be noted that the GPU/CUDA code also optimizes parts of the analyze_pot function, along with some of the functions which analyze_pot calls. Getting Started So what does this mean for us? Well, what if we replicated the same thing but in a separate project and then use that separate project to develop the FPGA code? We can re-implement those sections of code – namely the ChirpData, Fft, and GetPowerSpectrum functions in a high-level language like LabVIEW and see what some advanced tools automatically port LabVIEW code to an FPGA can do for us. For more information on LabVIEW and its graphical FPGA development environment, including its FPGA builder tool that automatically moves parts of an application into an FPGA see: www.ni.com. Step 1 – Export the Input Data I modified the original analyzeFuncs.cpp file to "dump" all of the input data and the results at certain points of execution. The goal here was to dump enough data so that the separate program would have enough information to reproduce a portion of the calculation in an isolated environment and to validate the results are accurate by loading the results from a previous run and comparing the values. For the input data, we need two files, one for the Work Unit Data points, and another for the Chirp/Fft pairs. Work Unit Data points will be stored in a file called "binWorkUnitDataPoints.bin"...

Hosting: So what do you think the next step is? What would make FPGAs...Knochi: Hi there, is anybody here? I came to this...Arivald Ha'gel: Hello, I'm amazed that there is anyone worki...Roy: So if I read this correctly you do have seti working on a...mark: Hi, Will this eventually work on a stand alone &q...jimbo: What happened to this interesting project? In the...