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