[comp.arch] 320C30 FFT timing

low@melair.UUCP (Rick Low) (08/01/89)

In article <3469@epimass.EPI.COM>, jbuck@epimass.EPI.COM (Joe Buck) writes:
  > In article <277@melair.UUCP> low@melair.UUCP (Rick Low) writes:
  > >..., then I wrote a 1024-point, radix-4,
  > >complex, floating-point (obviously), looped (i.e. not inline coded)
  > >FFT for this beast. [ the TI TMS320C30 ].
  > >
  > >I simulated this FFT using TI's C30 simulator and assuming zero wait
  > >states for external memory.  This FFT ran in 2.71 ms for an average
  > >of about 17 MFLOPs.  The control structure of this FFT -- i.e. non-butterfly
  > >code -- took 18 percent of the total execution time.
  > 
  > I'm currently working on the real thing, not just the simulator.
  > 
  > Unless you took account of a bug in the C30 simulator, your number is
  > a bit too optimistic: it always takes two cycles to write to external
  > memory, even with zero wait states; the C30 simulator counts it as one.
  > To get the true time, add a cycle for each external memory write cycle.

I didn't take this bug into account.  However, everything but a few
control variables (e.g. number of passes, butterfly arm separation, etc.)
was in internal memory (code and twiddle factors in ROM, data in RAM), so my
simulated times were only a little bit optimistic.  If memory serves me
correctly (the source code's at home) these control variables were accessed in
general about once per pass, to update them and load address registers.
That causes of the order of 100 external memory accesses for the whole FFT.

  > Yes, zero wait state external RAM is buildable, especially since all the
  > external RAM doesn't have to have the same number of wait states.  I'm
  > currently writing code for a board with six C30's on it, with 8K of
  > 0-wait-state external memory for each.  It brings one back to the old
  > days of computing, where you count cycles and count memory words.

OK, where do I sign up for this project?  :-)  I'm starting to
go into DSP withdrawl here -- I haven't processed a digital signal
for months. 

  > 
  > -- 
  > -- Joe Buck	jbuck@epimass.epi.com, uunet!epimass.epi.com!jbuck

Rick Low
MEL Defence Systems Limited, Ottawa, Canada
+1 613 836 6860
mitel!melair!low@uunet.UU.NET
-- 
Rick Low
MEL Defence Systems Limited, Ottawa, Canada
+1 613 836 6860
mitel!melair!low@uunet.UU.NET