Fft In Sopc

Thanks Majd,

I have an update for anyone else that may have experienced the same issue:

1. Following Majd's example code, I built my SOPC just as he recommended.

2. Everything seemed to be ok, except my SGDMA_st_mm component never sent any data out. (see C code below)

// Exert from file8.c

//start transfer data

alt_avalon_sgdma_do_async_transfer(transmit_DMA, desc);

//wait to finish

while (IORD(SGDMA_MM_TO_ST_FFT_BASE,0)!=12) {};

//start receive data

alt_avalon_sgdma_do_async_transfer(receive_DMA, desc1);

while (IORD(SGDMA_ST_TO_MM_FFT_BASE,0)!=14) {};

//wait to finish....

//(THIS NEVER HAPPENED!! THE CODE WAS STUCK AND AFTER DEBUGGING I

// REALIZED THAT IT MUST HAVE BEEN THE FFT COMPONENT THAT WAS

// NOT WORKING PROPERLY...WHAT ELSE COULD IT HAVE BEEN RIGHT??

3. I then went back to the avalon wrapper that Majd provided in the same zip file. This file is written in verilog. Herein lies the issue:

- My entire design (with the exception of some megacore-generated files), was written in VHDL. Using the verilig wrapper should not have posed an issue, since the SOPC builder analyzes the input file an generates yet another file that encapsulates the wrapper. The mere fact that the file was described in verilog was not the issue.

- However, I looked over the verilog file and discovered a few things that concerned me (BTW, im not a verilog coder, but I learned enough to parse through the file):

1. There was no fft_pts input for the wrapped FFT component (Possibly not an issue, if your design assigns that signal properly, perhaps outside of the SOPC). Since my FFT component needed the input, and there was no other external port to feed the FFT component, I added a register for this input, WITHOUT PROPERLY REGISTERING THE SIGNAL, i.e. always@ (posedge clk). I just wrote "reg fft_pts and connected the register to the intantiated FFT's fftpts_in port. (MISTAKE# 1)

2. My fft component needed both real and imaginary component. The wrapper however, assigns 0 to the imaginary component. This is not an issue if your input contains only real data; my input had real and imaginary data. I then split the avalon_mm_to_st into 2 16-bit parts- The first 16-bits were assigned directly to the real input of the FFT, the lower 16-bits were assigned to the imaginary input to the FFT (Your fft may have a different precision, but the punchline is since the avalon interface only has 1 data port, you have to encapsalate inside of that 1 port).

3. Applying the same logic above, I added a register for the inverse signal to the FFT. Once again, if you have external signals that connect to the inverse, you may be able to approach it differently.

Next I regenerated my SOPC, along with the new avalon_wrapper component. However, my code was still getting stuck at the same spot (see code above).

I then figured that the FFT component was not working at all, but why?

SOLUTION:

I registered the inverse and fftpts_in registers PROPERLY. Simply declaring "reg [10 :0] fftpts_in" and "reg inverse" was not enough to truly register the signal, a prerequisite for the FFT component to work properly. What Majd provided in the zip file above really works! If you have any questions or need help getting your FFT component working with the SGDMA, Majd or myself can provide you with some additional help. Just post to the thread and fire away.

EDIT: My code no longer stalls at the spot. Once the fft works properly, the avalon_st_mm interface will infact continue properly.

Thanks Majd!