Hi Michael, Are you certain that 1. The snapshot bram address counters have been changed to accommodate the new deeper rams. If not they will wrap and never write to the lower part of the ram. 2. Whatever controls the valid signal to the shared brams has been modified so that valid goes high for 8k clocks?
I think you'll track down the problem pretty quickly if you simulate the vacc and vacc control logic. As for the blackboxed and non-blackboxed designs behaving differently, I can only suppose that they're not really the same for some reason, or there's something fishy going on with the port connection of fft to gateways in the black boxes model file. Cheers, Jack On Sat, 12 Sep 2015 6:35 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…. > > > > >
