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