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…. > > > > > > > > >
