Re: [casper] casper Digest, Vol 95, Issue 2- ROACH2 FFT

[Madden, Timothy J.]

I am still having problems wiht ROACH2 FFT:

1) If I put FFt and PFB directly into design it will simulate but not work at 
all.
2) If I black box the FFT, it simulates perfectly (before the black box state), 
and almost works in the final design.
It has problems with extra noise, and not much signal in the bins where there 
is supposed to have signal. This is when running on ROACH2, 128MHz, and 4 tap 
input. Also, when sines are not exactly at bin center, the amplitude changes 
from FFt to FFT. I do not see the amplitude change from FFT to FFT. By 
amplitude I mean magnitude. I am doing a complex FFT.
3) I have done this on ROACH1 and it seems to work OK.

The problem is strange and I have not seen it before.

I was thinking one could make  a "test fft" block by using 4 Xilinx FFT blocks, 
and preceding them with 2 levels of butterflys. Then one could have  4 tap 
input using xilinx FFT blocks. A reorder block would be necessary, and I am not 
sure of all the details. it would be interesting if someone were to try this.

Tim



From: Madden, Timothy J.
Sent: Wednesday, December 09, 2015 8:02 AM
To: Andrew Martens
Cc: casper@lists.berkeley.edu
Subject: RE: [casper] casper Digest, Vol 95, Issue 2- ROACH2 FFT

Thanks for the response Andrew...

I am black boxing the FFT so it does not simulate.. I used a black box because 
I had strange problems without black boxing. If I got the FFt working OK, then 
added more logic, the FFT would then break. Unreleated logic broke the compile. 
Black boxing seemed to make it work. I had not noticed these power problems 
until now.


When I had the FFT not black boxed, I seem to recall it sim'ed OK. I will try 
again to be sure. It almost seems like the sync signal is not aligned so we get 
wierd things based on phase. The noise (all the other bins) seems larger than 
it should be, like there could be an impulse somewhere. But the noise is 
constant in time.

I am using a black box with a green FFT block and green PFB. I am pretty sure 
the numbers are correct in the settings, as this worked on roach1.

Here is the origin of my git working copy
Fetch URL: https://github.com/ska-sa/mlib_devel.git

I git'ed this about a year ago, so it is not the newest stuff probably.


Tim


From: Andrew Martens [and...@ska.ac.za]
Sent: Wednesday, December 09, 2015 1:51 AM
To: Madden, Timothy J.
Cc: casper@lists.berkeley.edu
Subject: Re: [casper] casper Digest, Vol 95, Issue 2- ROACH2 FFT

Hi

Are you seeing these power anomalies in hardware or in simulation as well?

Which blocks from which repo are you using?

Regards
Andrew

On Tue, Dec 8, 2015 at 10:36 PM, Madden, Timothy J. 
mailto:tmad...@aps.anl.gov>> wrote:

I am using a ROACH2, and doing 512 length FFTs.

I am seeing some wierd FFT problems as well. I found that if I had the FFT/PFB 
in the design as green blocks, other logic would break it. Black boxing the FFT 
helps, as it makes it work more or less.

Even after black boxing the FFT/PFB I still see a problem. The problem is that 
if the source sinusoid is not exactly at a bin center I get seemingly random 
variations in energy in the relevant FFT coefficient. If I take the magnitude 
of the FFT bins, the power randomly varies. This should not happen. I initially 
thought I had a windowing problem and I was seeing large cutoffs in the sine 
signal, causing impulses etc. This should not happen with a polyphase block, as 
a hamming window is used, as well as four  FFT-lengths of time domain data. (I 
am using 4 taps in polyphase). The phase should change for each successive FFT, 
but magnitude should be consant in time. It is a subtle problem and it took me 
a while to notice it. I am trying different settings in the FFT (black boxed) 
to see if anything changes.

A simple python simulation proves that the magnitude should be constant. See 
below.
The roach2 board
#


import numpy

#run several times over and over again

L = 512
pi = arccos(-1)
ph=10.4*2*pi*numpy.arange(L)/L
ph = ph+rand()*2*pi

I=numpy.cos(ph)
Q=-1* complex(0,1) * numpy.sin(ph)

S = (I+Q) * numpy.hamming(L)

F=fft.fft(S)

plot(abs(F))





From: 
casper-boun...@lists.berkeley.edu 
[casper-boun...@lists.berkeley.edu] 
on behalf of 
casper-requ...@lists.berkeley.edu 
[casper-requ...@lists.berkeley.edu]
Sent: Tuesday, October 06, 2015 2:11 PM
To: casper@lists.berkeley.edu
Subject: casper Digest, Vol 95, Issue 2

Send casper mailing list submissions to
casper@lists.berkeley.edu

To subscribe or unsubscribe via the World Wide Web, visit

https://calmail.berkeley.edu/manage/list/listinfo/casper@lists.b

Re: [casper] casper Digest, Vol 95, Issue 2- ROACH2 FFT

[Andrew Martens]

Hi Timothy

You may have run into the ROACH2 compiler problem we found. Make sure that
the "Share coeff BRAMs where useful" option is not chosen in the
"Implementation" tab in the FFT mask of your design.

Regards
Andrew

On Fri, Dec 11, 2015 at 10:23 PM, Madden, Timothy J. 
wrote:

>
> I am still having problems wiht ROACH2 FFT:
>
> 1) If I put FFt and PFB directly into design it will simulate but not work
> at all.
> 2) If I black box the FFT, it simulates perfectly (before the black box
> state), and almost works in the final design.
> It has problems with extra noise, and not much signal in the bins where
> there is supposed to have signal. This is when running on ROACH2, 128MHz,
> and 4 tap input. Also, when sines are not exactly at bin center, the
> amplitude changes from FFt to FFT. I do not see the amplitude change from
> FFT to FFT. By amplitude I mean magnitude. I am doing a complex FFT.
> 3) I have done this on ROACH1 and it seems to work OK.
>
> The problem is strange and I have not seen it before.
>
> I was thinking one could make  a "test fft" block by using 4 Xilinx FFT
> blocks, and preceding them with 2 levels of butterflys. Then one could
> have  4 tap input using xilinx FFT blocks. A reorder block would be
> necessary, and I am not sure of all the details. it would be interesting if
> someone were to try this.
>
> Tim
>
>
> --
> *From:* Madden, Timothy J.
> *Sent:* Wednesday, December 09, 2015 8:02 AM
> *To:* Andrew Martens
> *Cc:* casper@lists.berkeley.edu
> *Subject:* RE: [casper] casper Digest, Vol 95, Issue 2- ROACH2 FFT
>
> Thanks for the response Andrew...
>
> I am black boxing the FFT so it does not simulate.. I used a black box
> because I had strange problems without black boxing. If I got the FFt
> working OK, then added more logic, the FFT would then break. Unreleated
> logic broke the compile. Black boxing seemed to make it work. I had not
> noticed these power problems until now.
>
>
> When I had the FFT not black boxed, I seem to recall it sim'ed OK. I will
> try again to be sure. It almost seems like the sync signal is not aligned
> so we get wierd things based on phase. The noise (all the other bins) seems
> larger than it should be, like there could be an impulse somewhere. But the
> noise is constant in time.
>
> I am using a black box with a green FFT block and green PFB. I am pretty
> sure the numbers are correct in the settings, as this worked on roach1.
>
> Here is the origin of my git working copy
> Fetch URL: https://github.com/ska-sa/mlib_devel.git
>
> I git'ed this about a year ago, so it is not the newest stuff probably.
>
>
> Tim
>
> --
> *From:* Andrew Martens [and...@ska.ac.za]
> *Sent:* Wednesday, December 09, 2015 1:51 AM
> *To:* Madden, Timothy J.
> *Cc:* casper@lists.berkeley.edu
> *Subject:* Re: [casper] casper Digest, Vol 95, Issue 2- ROACH2 FFT
>
> Hi
>
> Are you seeing these power anomalies in hardware or in simulation as well?
>
> Which blocks from which repo are you using?
>
> Regards
> Andrew
>
> On Tue, Dec 8, 2015 at 10:36 PM, Madden, Timothy J. 
> wrote:
>
>>
>> I am using a ROACH2, and doing 512 length FFTs.
>>
>> I am seeing some wierd FFT problems as well. I found that if I had the
>> FFT/PFB in the design as green blocks, other logic would break it. Black
>> boxing the FFT helps, as it makes it work more or less.
>>
>> Even after black boxing the FFT/PFB I still see a problem. The problem is
>> that if the source sinusoid is not exactly at a bin center I get seemingly
>> random variations in energy in the relevant FFT coefficient. If I take the
>> magnitude of the FFT bins, the power randomly varies. This should not
>> happen. I initially thought I had a windowing problem and I was seeing
>> large cutoffs in the sine signal, causing impulses etc. This should not
>> happen with a polyphase block, as a hamming window is used, as well as
>> four  FFT-lengths of time domain data. (I am using 4 taps in polyphase).
>> The phase should change for each successive FFT, but magnitude should be
>> consant in time. It is a subtle problem and it took me a while to notice
>> it. I am trying different settings in the FFT (black boxed) to see if
>> anything changes.
>>
>> A simple python simulation proves that the magnitude should be constant.
>> See below.
>> The roach2 board
>> #
>>
>>
>> import numpy
>>
>> #run several times over and over again
>>
>> L = 512
>> pi = arccos(-1)
>> ph=10.4*2*pi*numpy.arange(L)/L
>> ph = ph+rand()*2*pi
>>
>> I=numpy.cos(ph)
>> Q=-1* complex(0,1) * numpy.sin(ph)
>>
>> S = (I+Q) * numpy.hamming(L)
>>
>> F=fft.fft(S)
>>
>> plot(abs(F))
>>
>>
>>
>>
>> 
>> From: casper-boun...@lists.berkeley.edu [
>> casper-boun...@lists.berkeley.edu] on behalf of
>> casper-requ...@lists.berkeley.edu [casper-requ...@lists.berkeley.edu]
>> Sent: Tuesday, October 06, 2015 2:11 PM
>> To