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