Really good point Bruce I'd expect there to be some tweaking on the various cache and flash accelerator settings absolutely required. There are many handles in the the F4, but a flash miss only costs a 6 cycles at full smoke.
hmm interleaved instruction and data access to flash could get messy. I think when steve mentioned in-place FFT- he meant the user data, not the twiddle factors. IE if input data is over written with the output data, or not. but, still your point about table access and cached access to the twiddle factors stands. ************** "Literal pools are fetched from Flash memory through the D-Code bus during the execution stage of the CPU pipeline. The CPU pipeline is consequently stalled until the requested literal pool is provided. To limit the time lost due to literal pools, accesses through the AHB databus D-Code have priority over accesses through the AHB instruction bus I-Code. If some literal pools are frequently used, the data cache memory can be enabled by setting the data cache enable (DCEN) bit in the FLASH_ACR register. This feature works like the instruction cache memory, but the retained data size is limited to 8 rows of 128 bits." ***************** might be worthwhile during those ops to disable D cache, OR rearrange the twiddle factors and tables to suit the cache and flash prefetch architecture some experimentation required. ************ On 29/07/2015 10:31 AM, Bruce Perens wrote: > Do you really get good performance from tables used in-place in FLASH? > FLASH is page addressed, the cache is small, and table reads are > random. I'd imagine there'd be a lot of thrashing getting pieces of a > table in and out of cache. > > I've seen lots of people implement execute-in-place at great expense > only to end up rejecting it due to poor performance. > > Thanks > > Bruce > > On Tue, Jul 28, 2015 at 4:31 PM, glen english <[email protected]> wrote: >> thanks for the info. >> >> I would have thought RAM would have been no issue- coefficients stored in >> the FLASH (that's big) , and good packing, use of the RAM ( as the M4 is >> pretty good with its alignment options/access options ) , together with the >> fact that the codec doesn't have a very long state memory. >> I'll probably stay with the STM in order to stay with the crowd. STm32F7. >> It's just not very s3xy. >> >> Just have to wait for the silicon to settle down the the errata sheet to >> shorten a bit. >> Actually STM don't call them bugs, they are called "silicon limitations" >> >> Those using STM chips are well advised to read the errata sheet carefully. >> >> 73 >> >> >> >> On 28/07/2015 1:14 PM, Steve wrote: >> >> I think that David said he kept the kissfft only because it was faster. The >> kissfft however, uses twice as much memory, not being an in-place algorithm. >> >> This can be easily changed in the code though, if a slower in-place is used >> that still performs the task "fast enough" and you are running out of >> memory. >> >> He did do a lot of memory optimizations last year, as I recall. >> >> On Mon, Jul 27, 2015 at 7:33 PM, Shane Burrell <[email protected]> >> wrote: >>> My last project working with codec2, the code is coupled to kissfft. >> >> >> ------------------------------------------------------------------------------ >> >> >> >> _______________________________________________ >> Freetel-codec2 mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/freetel-codec2 >> >> >> -- >> - >> Glen English >> RF Communications and Electronics Engineer >> >> CORTEX RF >> & >> Pacific Media Technologies Pty Ltd >> >> ABN 40 075 532 008 >> >> PO Box 5231 Lyneham ACT 2602, Australia. >> au mobile : +61 (0)418 975077 >> >> >> ------------------------------------------------------------------------------ >> >> _______________________________________________ >> Freetel-codec2 mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/freetel-codec2 >> > ------------------------------------------------------------------------------ > _______________________________________________ > Freetel-codec2 mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/freetel-codec2 > -- - Glen English RF Communications and Electronics Engineer CORTEX RF & Pacific Media Technologies Pty Ltd ABN 40 075 532 008 PO Box 5231 Lyneham ACT 2602, Australia. au mobile : +61 (0)418 975077 ------------------------------------------------------------------------------ _______________________________________________ Freetel-codec2 mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freetel-codec2
