Something we've had with PFBs and FFTs is that they don't resize properly if you simply change their length in a design. It may be worth deleting them and putting new ones. On 12 Sep 2015 20:03, "Danny Price" <dpr...@cfa.harvard.edu> wrote:
> Hi Michael > > I always blame the sync gen first! I’d suggest just sending out a single > pulse to reset the logic, not a heartbeat, at least to begin with, to rule > this out. Jack’s suggestion that it might be the addressing of the shared > BRAM is definitely a possibility too. > > It’s very easy for the FFT to become broken if you’re using an unstable > github branch. I’d suggest testing the FFT by itself in its own simulink > model. You can use the blackbox tutorial setup as a starting point, and > then add in some test vectors. The easiest test vector is a delta function, > e.g. [0 0 1 0 0 … 0]. The FFT will take the FT of this, which will be a > sine wave if you look at the real/imag components separately (take the > power and you’ll get back a DC signal), where the frequency of the wave > will depend on where the delta is. > > The test procedure in this case is to connect up a scope to the output and > just look to see if you get a sine wave out, your eye will be able to tell > if it’s a major bug. Once you’ve got it simulating, blackbox it up and then > you don’t have to worry. > > Also look out for toolflow version mismatches. As Jack (et al) have just > updated the casper_astro repository, I’d suggest using that: > https://github.com/casper-astro/mlib_devel > Make sure to run update_casper_blocks(gcs) on your design. Deleting and > redrawing the FFT from scratch isn’t a bad idea either. > > Once you’ve got it simulating OK, here’s some other general tips for > spectrometer that I started writing before reading your email properly: > > * One of the first things I’d do is play around with the shift schedule. A > 2^15 point FFT will have 15 stages, and shifting every stage will probably > shift your signal into oblivion. It doesn’t look to me like you have > overflows (generally lots of spikes everywhere), but overshifting can also > be detrimental. Maybe try writing 0b111111100000 or so, so you shift the > first N stages only (someone may have a more rigorous approach/strategy?). > > * It’s also important to check that your RMS input from the digitizer > isn’t too high. Even with RFI, having an RMS of 32 or below on an 8-bit ADC > would be good. A good reference for this is: A. R. Thompson, D. T. Emerson, > and F. R. Schwab, “Convenient formulas for quantization efficiency,” Radio > Science, vol. 42, p. 3022, Jun. 2007 (Just read the last paragraph if > you’re pressed for time!). You can compute the RMS by looking at raw ADC > samples (use a snapshot block) > > * An approach I’ve found useful for debugging is looking at your data in > terms of bits — i.e. take the log2 of your data. This can help find > quantization and saturation issues. In the tut3_spectrum.png, all the RFI > spikes are suspiciously similar heights, which I would guess is due to > saturation or quantization somewhere along the line. > > Cheers > Danny > > On Sep 12, 2015, at 9:34 AM, Michael D'Cruze < > michael.dcr...@postgrad.manchester.ac.uk> wrote: > > Hi everyone, > > > I’m having quite a lot of trouble getting large-ish designs (16k channels) > to produce spectra. The spectra that are being produced are quite strange. > I’ve provided links below to a few examples. The first link is the spectrum > produced by the unmodified tut3 model (except for the ADC and FPGA clocks > increased to 1024 MHz and 256 MHz, respectively). It’s pretty much as you’d > expect – a bog-standard L-band spectrum full of RFI. The second link is > what happens when I try to increase the number of channels to 16k. As you > can see, I can pull 16k channels from the board, but there are no actual > data in there, beyond the original 2k channels. All the usual blocks were > modified to get the model to work at 16k channels: the #PFB and #FFT points > increased to 32768, the vector length in the VACC increased to 8192, the > sync_gen block (using for now before changing to a PPS-based system) > adjusted, and the shared_brams adjusted for longer address length. The > third link is a zoomed-in image of the same spectrum, just to show that > there is a partial spectrum in there. The fourth link is what comes out > when I replace the FFT and PFB blocks with black-boxes… where the > pre-compiled PFB and FFT blocks have the same settings as in the previous > spectra….! The inconsistency between compiling with “raw” blocks and > pre-compiled blocks is another source of concern. > > > https://dl.dropboxusercontent.com/u/38103354/tut3_spectrum.png > > https://dl.dropboxusercontent.com/u/38103354/tut3_mod3_correct.png > > https://dl.dropboxusercontent.com/u/38103354/tut3_mod3.png > > https://dl.dropboxusercontent.com/u/38103354/tut3_mod2.png > > > I can also make my models available if anyone would like. If I were to > list every setting I’d changed to try and get this to work, this email > would take about an hour to write…. but I’ve kept a log of everything I’ve > tested. So, I’d be very grateful for suggestions for what to do next… I > really have run out of ideas. I’ve compared the settings I’m using to the > VEGAS models available on the git repo, and have even looked back to the > deprecated “million channel spectrometer” model to look at the block > settings used there. Nothing seems very different to what I’m doing. > > > I’m going for 16k channels at the moment just because I was having trouble > getting timing closure on 32k channels in 2-pols, with all the backend > logic. Eventually I need to get a 64k channel model in 1-pol working, with > the 5 GS/s ASIAA ADC, so this pre-requisite is essential. > > > Many thanks in advance > > Michael > > > P.S. I should add that the 1024 MHz ADC clock has to stay fixed because > the downconverted 500 MHz L-band signal comes into the ADC at 0.5—1 GHz…. > > > > > >
