Hi Tim, Ah, that's the problem! The sync out pulse will only come once per input sync, and can be used for resetting downstream logic. However, after a sync, every N_FFT/N_INPUTS clock cycles represents a new spectra. You should be able to verify this in simulation by varying the FFT signal inputs for different windows of data. If you need a pulse before every spectra, you'll have to use the sync pulse to reset a counter with a 1 spectra period and generate pulses from that.
Cheers, Jack On 2 May 2014 14:39, Madden, Timothy J. <[email protected]> wrote: > > Jack > > I think this may be getting clearer in my murky mind. If I send one and only > one sync pulse into the PFB, conneced to FFT, I get one and only one sync > out. I am assuming that this means that the FFT runs once. > > Should I assume that the FFT is still running forever? If this is the case I > need to assume that the coefficients are streaming out forever even if there > is no fft sync out, and redesign my logic that saves the data to RAM. > Currently my logic waits for the fft sync out before storing coefficients. > > Thanks for your time. > > Tim > > > ________________________________________ > From: Jack Hickish [[email protected]] > Sent: Friday, May 02, 2014 4:35 PM > To: Madden, Timothy J. > Cc: [email protected]; [email protected] > Subject: Re: [casper] casper Digest, Vol 78, Issue 2 > > Hi Tim, > > On 2 May 2014 14:16, Madden, Timothy J. <[email protected]> wrote: >> Aaron >> >> I thought they were streaming until I tried using simulink. >> >> If I give the FFTs ONE and only ONE pulse, they compute ONE FFT and stop. So >> I have to give a series of pulses. >> So then I must figure out what sync frequency is necessary. It seems to be >> true that the FFTs need repeating sync pulses. > > This definitely *shouldn't* be the case. What simulation are you > running that suggests only one FFT is being performed? >> >> Because the docs are unclear on this point, I decided to simulate the FFT by >> giving one sync pulse and seeing how long it takes for the sync to come out >> of the FFT. It comes out at a much longer time than would allow for >> streaming. For for a 512 point FFT with 2 inputs, and reorder block, the >> time between fft sync in and fft sync out is 900 clocks, which is too slow >> for a true streaming FFT. >> > > The latency doesn't affect the ability of the FFT to stream -- it > might take ~900 clocks for a 512 point FFT to emerge from the block, > but that doesn't mean that it's 900 clocks before the next transform > starts being calculated. Everything is pipelined so that the input > data stream can be valid on every clock. > >> I removed the reorder block, and the time between sync in and sync out of >> the FFT block became 640 clocks. This is again too slow for streaming. For >> streaming speed, the FFT would have to complete in 256 clocks. >> >> Either I do not understand what is going on, or the FFT blocks are too slow >> to "stream." >> >> Regarding the memo on using sync pulses, it suggests that the FFT speed will >> be: >> >> (512/2 ) * LCM(reorder block). >> >> I am not sure how to calc. the reorder block stages, as it is not obvious >> from the >> simulink blocks. There was another factor for the PFB as well. >> > > I think you have to look inside the FFT descrambler and the reorder > blocks will tell you their order (it's printed under the block name). > > Cheers, > Jack > >> >> >> Tim >> >> ________________________________________ >> From: [email protected] [[email protected]] >> on behalf of [email protected] >> [[email protected]] >> Sent: Friday, May 02, 2014 2:15 PM >> To: [email protected] >> Subject: casper Digest, Vol 78, Issue 2 >> >> Send casper mailing list submissions to >> [email protected] >> >> To subscribe or unsubscribe via the World Wide Web, visit >> >> https://calmail.berkeley.edu/manage/list/listinfo/[email protected] >> >> or, via email, send a message with subject or body 'help' to >> [email protected] >> >> You can reach the person managing the list at >> [email protected] >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of casper digest..." >> >> >> Today's Topics: >> >> 1. Re: FFT compute time (Aaron Parsons) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Fri, 2 May 2014 12:06:08 -0700 >> From: Aaron Parsons <[email protected]> >> Subject: Re: [casper] FFT compute time >> To: Dan Werthimer <[email protected]> >> Cc: "Madden, Timothy J." <[email protected]>, >> "[email protected]" <[email protected]> >> Message-ID: >> <cacu45xb6mdugm2zzan-9vk_d9qtfrwimygpyo4er+sgwj+7...@mail.gmail.com> >> Content-Type: text/plain; charset="utf-8" >> >> Dear Tim, >> >> You are aware that the CASPER FFTs are streaming, right? By this, I mean >> that they can accept data input at the full clock rate with no pausing >> between FFT windows. Everything Dan says is correct about latency, but >> historically there have been very few applications that have strict limits >> on absolute latency. I'm confused by the statement in your first email >> regarding not missing data. As long as the data lines all feed in to >> CASPER FFT inputs, no data are missed. >> >> Aaron >> >> >> On Fri, May 2, 2014 at 10:12 AM, Dan Werthimer <[email protected]>wrote: >> >>> >>> tim, >>> >>> one more thought: >>> >>> the PFB FIR in front of the FFT dominates the latency of the PFB/FFT. >>> >>> the PFB has latency of (Ntaps-1) x FFTlength / Nparallelinputs. >>> >>> a four tap PFB has about three times the latency of the FFT, >>> so if you remove the PFB you will cut latency down by about a factor of >>> three >>> (assuming you remove the corner turn in the FFT). >>> >>> you can also put more inputs in parallel, as i mentioned in my previous >>> email, to cut latency down by factors of 2, 4, 8,... >>> >>> best wishes, >>> >>> dan >>> >>> >> >> >> -- >> Aaron Parsons >> 510-306-4322 >> Hearst Field Annex B54, UCB >> -------------- next part -------------- >> An HTML attachment scrubbed and removed. >> HTML attachments are only available in MIME digests. >> >> End of casper Digest, Vol 78, Issue 2 >> ************************************* >>
