Re: [casper] Spectrum issues

[James Smith]

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"  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 0b1110 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 

Re: [casper] Spectrum issues

[Danny Price]

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 0b1110 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 
>  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 

Re: [casper] Spectrum issues

[Jack Hickish]

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