hi glen,
this problem of non-repeat of power spectra
might be a problem with how often you put in a sync pulse.
it might also be a problem that your test pattern is
not a multiple of pfb taps * fft length.
the sync pulse must be a multiple of
reorder_block's_Number_of_cycles_to_repeat
* fft_length / (Number of FFT parallel samples per clock)
* pfb_number_of_taps
to find the reorder block number of cycles to repeat,
you need to drill down into the fft and find the reorder block,
and see how many cycles it takes to repeat. this number
will change depending on fft parameters.
peter - did you casper write a memo about this? - we need one.
mark -
as we discussed before, can you make the number_of_cycles_to_repeat
appear on the simulink FFT block, so the designer doesn't have to
drill down to find this number.
dan
G Jones wrote:
Hi Andrew,
I'm using green blocks, but I verified the functionality vs. the pink
blocks because I thought there might be something wrong there, but in
simulation they both agree. The FFT is a wideband real with 2^11 taps
(1024 ch) and the PFB is a 2-tap hamming window. I have a mux that
allows me to bypass the PFB, and I find the same behavior whether the
PFB is bypassed or not. I am trying lower clock frequencies, but I
notice the issue even when going from 1024 to 1023 MHz. The design
meets timing at 1024/256 MHz. I have tried many frequencies and it
seems like every now and then I find one that works as well as 1024,
but most are slightly off. Again, the error seems to be about 1 LSB
per FFT, but still I can't see why there should be any error unless
the clock is not working right.
I have not yet tried compiling for different frequencies, I will do that now.
I will be presenting about GAVRT at URSI.
Thanks,
Glenn
On 5/14/08, Andrew Siemion <[email protected]> wrote:
Hi Glenn,
I'm guessing that your lowering the clock frequency, not raising it? What
is the FFT length you are using, and how many taps are in your pfb? Are you
using green fft blocks or purple fft blocks?
Henry and I were looking into the DCM for a while when we were trying to
clock realllllly slowly, and as I recall it only had a couple of modes..
Like 2 or 4 or something, so I would think that whatever mode it selected
for 1024 mhz would be the same as what it would select for 1020MHz or even
800 or 900 MHz.
Have you confirmed that compiling for a different target frequency fixes the
problem?
Btw, are you going to URSI?
- Andrew
On 5/14/08 11:38 PM, "G Jones" <[email protected]> wrote:
> Hello,
> I am investigating the accuracy and reliability of my spectrometer
> design, so I set up a test vector generator that feeds a known
> sequence (a counter in fact) into the PFB/FFT. The test vector is set
> up so that it has exactly the same period as the FFT length so that
> the spectrum should be static. I find that when I run my design at the
> speed I compiled it for, 1024 MHz ADC clock, 256 MHz FPGA clock, I get
> the expected spectrum. However, if I change the frequency, even by
> just a few MHz, the spectrum changes very slightly (seems to be the
> least significant bit or so). The spectrum is still static, just
> slightly off from what it should be. Is this behavior expected? My
> best guess is that the DCM on the ADC clock is configured optimally
> for the compiled speed, and thus the clock is not locking as well when
> run at a different speed. Is there anything that can be done about
> this? It seems like a major hassle to have to make different builds
> just to accommodate different sampling clocks. By the way, I am
> sending a sync pulse through at regular intervals that precisely match
> the integration time (I verified in simulation that the sync pulse is
> occurring exactly when it should to keep every TVG spectrum
> identical), so it is not a matter of the design free running for long
> periods of time.
> Glenn
>
