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. <[email protected]> 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: [email protected] [[email protected]] > on behalf of [email protected] [ > [email protected]] > Sent: Tuesday, October 06, 2015 2:11 PM > To: [email protected] > Subject: casper Digest, Vol 95, Issue 2 > > Send casper mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > > https://calmail.berkeley.edu/manage/list/listinfo/[email protected] > > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of casper digest..." > > > Today's Topics: > > 1. Re: Weird FFT block problem (Jack Hickish) > 2. FFT problems (Jonathon Kocz) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 06 Oct 2015 15:53:15 +0000 > From: Jack Hickish <[email protected]> > Subject: Re: [casper] Weird FFT block problem > To: "Michael D'Cruze" <[email protected]>, > "[email protected]" <[email protected]> > Message-ID: > <CAG1GKSkz26KdDpf=PSHseLmBW1J7ec2O= > [email protected]> > Content-Type: text/plain; charset="utf-8" > > Ah, > > I would guess what happens is that you have delay stages being implemented > in bram where the stage delay is fewer clock cycles than the bram latency, > causing an initialization implosion. I suspect if you changed the "minimum > delay implemented in bram" (or whatever it's called) parameter to be a bit > higher you might not get this error. But as you say, >10 is very excessive, > and I'd be surprised if it makes any difference to your timing. I think if > you open your mapped design in planahead/fpga editor you'll find that > almost all that latency is being wrapped up in a single slice as a shift > register. But hey, if it works it works :) > > Jack > > On Tue, 6 Oct 2015 at 16:42 Michael D'Cruze < > [email protected]> wrote: > > > Hi Jack, > > > > > > > > After cycling through the settings I think I?ve isolated the issue. I was > > a bit quick to declare a solution?.i was able to repeat the problem. The > > problem occurs when the BRAM latency is set to >10. I appreciate this may > > seem excessive in any case however as you know I?m messing with settings > to > > get a 2^17 point FFT block to compile at 256 MHz? > > > > > > > > When the problem first arose I grabbed the latest casper-astro-soak-test > > commit, which didn?t solve the immediate issue. > > > > > > > > Perhaps someone could confirm that bram latencies >10 causes this issue? > > It?s a 2^17 point FFT with fanout 1. > > > > > > > > BW > > Michael > > > > > > > > *From:* Jack Hickish [mailto:[email protected]] > > *Sent:* 06 October 2015 15:50 > > *To:* Michael D'Cruze; [email protected] > > *Subject:* Re: [casper] Weird FFT block problem > > > > > > > > Hi Michael, > > > > > > > > If the initialisation script fails half way through drawing then often > > you'll be left with a bunch of blocks half connected, so I think that's > > (probably) a symptom rather than a cause of the issue. Are you using the > > latest casper-astro branch? Do you remember what FFT parameters you were > > using? Was it a block fresh from the library of one you had previously > > configured? If the latter, do you remember how it was configured? > > > > Gonna be tricky to track this down if it can't be recreated... > > > > > > > > Cheers, > > > > Jack > > > > > > > > On Tue, 6 Oct 2015 at 15:25 Michael D'Cruze < > > [email protected]> wrote: > > > > Hi all, > > > > > > > > I had an odd problem while messing about with the FFT block today ? on > > setting a new combination of parameters and attempting a new compile, an > > error came up which I?ve never seen before. Something along the lines of > an > > initialisation error in the FFT. On inspection, the component blocks > within > > the FFT were in pieces and not linked up correctly. In the biplex core > > itself there was nothing except the in/out ports. This is very strange > and > > I can?t find anything similar on the mailing list. I?ve solved it by > > erasing and re-cloning the CASPER libraries, however wondered if anyone > had > > a clue why this would happen? FYI update_blocks didn?t help. > > > > > > > > Thanks > > > > Michael > > > > > -------------- next part -------------- > An HTML attachment scrubbed and removed. > HTML attachments are only available in MIME digests. > > ------------------------------ > > Message: 2 > Date: Tue, 6 Oct 2015 09:05:00 -0700 > From: Jonathon Kocz <[email protected]> > Subject: [casper] FFT problems > To: [email protected] > Message-ID: > < > capu71p8qvenhksppgqa0amjer2z6von60znud64myqo7xom...@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hi Casper, > > While we're talking weird FFT problems... > > I have experienced an interesting problem with the FFT libraries when > compiling for ROACH2, that I'm hoping someone might be able to explain. > > I have tried multiple versions of the libraries, and various branches > (latest CASPER, SKA-SA, SMA), on Ubuntu, CentOS, RedHat and Windows, all > using Xilinx 14.7 and Matlab 2012b, but the error stays the same: the FFT > (various sizes/number of inputs/wb/biplex_2x/biplex_4x) simulates fine, but > when I compile I get zeros for some of the outputs. > > After various experiments, I found that if I black box the FFT, and then > include it in the design, everything works, so I'm presuming the problem is > something in the system generator options when run by the tool flow. > > Can anyone help me out with an explanation for why this might occur? > > Thanks, > Jonathon > -------------- next part -------------- > An HTML attachment scrubbed and removed. > HTML attachments are only available in MIME digests. > > End of casper Digest, Vol 95, Issue 2 > ************************************* > >
