The bug you mention is what I was worried about. I will check out the share Coef BRAMs setting. Your email on the compiler problem got me thinking. It seems to me that if the bug were in the compiler, then Xilinx would be out of business, because these bugs would be all over the world. The bug seems to effect only the FFT, and not all the other stuff on the FPGA. Probably the bug has to do with the matlab front end, either in xilinx system generator, or in some script somewhere. Is it possible that the files that define the Roach2 board have some quirk that effect the FFT scripts? Probably if we compile the FFT for Roach1 the bug goes away. The difference is the choice of FPGA and the board files etc. for the Roach2. Probably worth checking the board files.
________________________________ From: Andrew Martens [[email protected]] Sent: Friday, December 11, 2015 11:42 PM To: Madden, Timothy J. Cc: [email protected] Subject: Re: [casper] casper Digest, Vol 95, Issue 2- ROACH2 FFT 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. <[email protected]<mailto:[email protected]>> 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: [email protected]<mailto:[email protected]> 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 [[email protected]<mailto:[email protected]>] Sent: Wednesday, December 09, 2015 1:51 AM To: Madden, Timothy J. Cc: [email protected]<mailto:[email protected]> 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. <[email protected]<mailto:[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]<mailto:[email protected]> [[email protected]<mailto:[email protected]>] on behalf of [email protected]<mailto:[email protected]> [[email protected]<mailto:[email protected]>] Sent: Tuesday, October 06, 2015 2:11 PM To: [email protected]<mailto:[email protected]> Subject: casper Digest, Vol 95, Issue 2 Send casper mailing list submissions to [email protected]<mailto:[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]<mailto:[email protected]> You can reach the person managing the list at [email protected]<mailto:[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]<mailto:[email protected]>> Subject: Re: [casper] Weird FFT block problem To: "Michael D'Cruze" <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Message-ID: <CAG1GKSkz26KdDpf=PSHseLmBW1J7ec2O=drgzf-x_gd8ye9...@mail.gmail.com<mailto:[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]<mailto:[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]<mailto:[email protected]>] > *Sent:* 06 October 2015 15:50 > *To:* Michael D'Cruze; > [email protected]<mailto:[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]<mailto:[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]<mailto:[email protected]>> Subject: [casper] FFT problems To: [email protected]<mailto:[email protected]> Message-ID: <capu71p8qvenhksppgqa0amjer2z6von60znud64myqo7xom...@mail.gmail.com<mailto: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 *************************************
