Why use cache on a DSP? (c6x specifically)

Unless I'm missing something, for hard real-time systems a cache is
absolutely useless...

I am new to the c6x family of DSPs (and DSPs with data caches) and
although I like the c6x archetecture, there is something that is
bothering me: the Program/Data cache. What good is a data-cache when I
have to set my parameters (ie buffersize, numtaps, ect) for the worst
case scenario (ie a 100% cache miss?). I'm working on a hard real-time
system where a missed dealine cannot be tolerated. I suppose there
might be some way to "prime the cache" like accessing all the data the
algorithm would access first but this seems wastefull.

Worse yet, there seems to be no way to turn off the cache off to level
out the performance which really irritates me.

I could understand this design decision if most DSP applications were
not hard-realtime (like a Windows media player or something), but
arent a majority of DSP applications hard real-time?

Although I hate to be cynical, the only logical reason to use cache
would seem to be to boost the paper specs on the part.

I can't speak for the C6x, but in my experience (primarily SHARC), you can
often guarantee that the instruction cache will be used, for example with
non-interruptible looped code.  On the second, etc. times through the loop,
with my code I know I will get 100% cache hits.

With the data cache, is it a read-ahead type (again I'm not familiar with
the C6X)?  If so, I would think you could also guarantee cache hits with
non-interruptible sequential access code.

There are definitely situations where the cache is useful and you can count
on hits.  Whether yours is one of those or not, I do not know.

-Jon

"awestport" <awestport@hotmail.com> wrote in message
news:427e5468.0401051230.2f49b9a@posting.google.com...
> Unless I'm missing something, for hard real-time systems a cache is
> absolutely useless...
>
> I am new to the c6x family of DSPs (and DSPs with data caches) and
> although I like the c6x archetecture, there is something that is
> bothering me: the Program/Data cache. What good is a data-cache when I
> have to set my parameters (ie buffersize, numtaps, ect) for the worst
> case scenario (ie a 100% cache miss?). I'm working on a hard real-time
> system where a missed dealine cannot be tolerated. I suppose there
> might be some way to "prime the cache" like accessing all the data the
> algorithm would access first but this seems wastefull.
>
> Worse yet, there seems to be no way to turn off the cache off to level
> out the performance which really irritates me.
>
> I could understand this design decision if most DSP applications were
> not hard-realtime (like a Windows media player or something), but
> arent a majority of DSP applications hard real-time?
>
> Although I hate to be cynical, the only logical reason to use cache
> would seem to be to boost the paper specs on the part.

>>>>> "awestport" == awestport  <awestport@hotmail.com> writes:

    awestport> Unless I'm missing something, for hard real-time systems a cache is
    awestport> absolutely useless...

I used to use a Masscomp computer with a 68K and cache.  It had a hard
real-time OS.

    awestport> Although I hate to be cynical, the only logical reason to use cache
    awestport> would seem to be to boost the paper specs on the part.

Maybe putting zero wait-state memory of the size and speed people want
is too costly in silicon or power?  Pick a different part if you don't
like the cache on the c6x?

Personally, I expect almost all high-end DSPs to come with cache, if
they don't already.

Ray

In article <427e5468.0401051230.2f49b9a@posting.google.com>,
awestport <awestport@hotmail.com> wrote:
>Unless I'm missing something, for hard real-time systems a cache is
>absolutely useless...

Depends.  The caches are guaranteed to help the second time thru any
loop or data set that fits completely inside the caches, unless
interrupted in a manner which requires cache line reloads.  Thus, all
small noninterruptable loops are accelerated, and even interruptable
loops, if the peak possible interrupt rate is significantly slower than
the loop repeat rate.  The amount of acceleration depends on whether
and by how much cache latency is less than memory latency in cycles.

There are also tricks that can be played, such as allocating
instructions and data in interrupt routines to locked cache lines or
to cache lines orthogonal from those used by all other routines (an
exercise for the student, etc.)

So it's not useless in many hard real-time cases, just harder to
analyze.

>Worse yet, there seems to be no way to turn off the cache off to level
>out the performance which really irritates me.

If there are cache invalidate instructions, you can use them to slow
down performance to simulate your expected peak worse case rate of cache
misses.


IMHO. YMMV.
-- 
Ron Nicholson   rhn AT nicholson DOT com   http://www.nicholson.com/rhn/ 
#include <canonical.disclaimer>        // only my own opinions, etc.

Though I have not used the C6x series, I have used many TI DSPs, and every
one of them has an easy way to disable the cache (i.e., one bit in a control
register). Unless TI really broke with their ways, there is probably a way
to disable it.

Jim Gort

"awestport" <awestport@hotmail.com> wrote in message
news:427e5468.0401051230.2f49b9a@posting.google.com...
> Unless I'm missing something, for hard real-time systems a cache is
> absolutely useless...
>
> I am new to the c6x family of DSPs (and DSPs with data caches) and
> although I like the c6x archetecture, there is something that is
> bothering me: the Program/Data cache. What good is a data-cache when I
> have to set my parameters (ie buffersize, numtaps, ect) for the worst
> case scenario (ie a 100% cache miss?). I'm working on a hard real-time
> system where a missed dealine cannot be tolerated. I suppose there
> might be some way to "prime the cache" like accessing all the data the
> algorithm would access first but this seems wastefull.
>
> Worse yet, there seems to be no way to turn off the cache off to level
> out the performance which really irritates me.
>
> I could understand this design decision if most DSP applications were
> not hard-realtime (like a Windows media player or something), but
> arent a majority of DSP applications hard real-time?
>
> Although I hate to be cynical, the only logical reason to use cache
> would seem to be to boost the paper specs on the part.

awestport@hotmail.com (awestport) wrote in message news:<427e5468.0401051230.2f49b9a@posting.google.com>...
> Unless I'm missing something, for hard real-time systems a cache is
> absolutely useless...
> 
> I am new to the c6x family of DSPs (and DSPs with data caches) and
> although I like the c6x archetecture, there is something that is
> bothering me: the Program/Data cache. What good is a data-cache when I
> have to set my parameters (ie buffersize, numtaps, ect) for the worst
> case scenario (ie a 100% cache miss?). I'm working on a hard real-time
> system where a missed dealine cannot be tolerated. I suppose there
> might be some way to "prime the cache" like accessing all the data the
> algorithm would access first but this seems wastefull.
> 
> Worse yet, there seems to be no way to turn off the cache off to level
> out the performance which really irritates me.
> 
> I could understand this design decision if most DSP applications were
> not hard-realtime (like a Windows media player or something), but
> arent a majority of DSP applications hard real-time?

The cache is there to cut down on the cost of the part. It is true
that you must be aware of it and how to work around it's limitations
to get maximum performance from the part...

Instruction cache: No problem, It will quickly fill within the first
loop or two of your critical code. If your really worried, execute
your critical code once before the timing requirement is in effect.

Data cache: The key is to make sure that all data is accessed once
before the critical code executes so it is fluent in the cache: Take a
fir filter for example... You are probably circular buffering your X
data, so it will be in the cache. For your coefficents, just read them
once before the timing requirement is needed.

One caveot though: If your data+coefficients are bigger than the
cache, you will take some misses. Look at the cache sizes and plan for
this.

> Although I hate to be cynical, the only logical reason to use cache
> would seem to be to boost the paper specs on the part.

LOL. It's really just to save on expensive, wide memory. The c67x can
access up to 128 bits of data memory and 256 bits of program memory (8
32 bit instructions) per cycle. The reason for this cache is to cut
down on the amount of this wide memory and thereby the cost.

> What good is a data-cache when I
> have to set my parameters (ie buffersize, numtaps, ect) for the worst
> case scenario (ie a 100% cache miss?). 

The cache guarantees less that 100% cache miss... that's why it's
there!
For my experience (And you'll have to trust me on this one), the cache
introduces a degradation of 5%-15% in performance, depending on the
application. However, with the introduction of caches, zero-wait-state
memories can be eliminated, and thus the frequency can be increased
(usually by more than 15%). So, in general The customers gets a
cheaper, faster DSP !!!

Also, don't forget that the cache includes mechanisms like prefetch
and locking to improve its' effectiveness.
 
> Worse yet, there seems to be no way to turn off the cache off to level
> out the performance which really irritates me.

I'm sure there is -- you just didn't find it.
Look in the user manual of the device.
In the MSC8102 (Motorola Quad-Core SC140), the ICache and Prefetch are
fully controllable.

> Although I hate to be cynical, the only logical reason to use cache
> would seem to be to boost the paper specs on the part.

No.. It's to reduce prices, increase frequency, and decrease power.

erez_st@hotmail.com (Erez Steinberg) writes:
<snip>
MJT> awesport wrote:
> > Worse yet, there seems to be no way to turn off the cache off to level
> > out the performance which really irritates me.
> 
> I'm sure there is -- you just didn't find it.
> Look in the user manual of the device.
> In the MSC8102 (Motorola Quad-Core SC140), the ICache and Prefetch are
> fully controllable.
> 

The C6x11 (low-cost) parts cannot disable the L1 cache, although the
L2 cache can be disabled and used as normal SRAM.

This appears to be to reduce the required bandwidth beyond the L1
boundary, as someone else pointed out, the C6x core can read 256-bits
of code and 128-bits of data each cycle. Providing this from an SRAM
the size of the L2 cache would be expensive.

<snip>

-- 
martin.j.thompson@trw.com
TRW Conekt, Solihull, UK
http://www.trw.com/conekt

> bothering me: the Program/Data cache. What good is a data-cache when I
> have to set my parameters (ie buffersize, numtaps, ect) for the worst

I am writing code on a C6713 for a hard disk audio recorder which uses
the DSP for everything from audio processing to the GUI. The binary
program takes up about 3Mbytes of SDRAM. The C6713 has 256Mbytes of
internal ram that can be used as cache and/or internal program/data
RAM.

With the cache turned off I get a 50X hit in performance (not 50
percent, 50 times)! The real-time audio processing interrupt is too
large to fit in internal memory. Without the cache I would have to
plop down a few Mbytes of fast SRAM to make this work almost as well.

In this situation the real-time task only takes up 80% or so or the
DSP processing power. The remaining 20% is used for FireWire and GUI
operations. Therefore if one of my audio interrupts takes an extra 19%
of time to execute, it will not cause a problem. As long as there is
an /average/ of 20% left over for the non-real-time tasks to do their
thing then every one is happy.

BTY, here is a link the Deva audio recorder that I am referring to:

http://www.zaxcom.com/audio/devas.shtml

that's a 320x240x18 color touch screen on the front...

-howy
zaxcom engineer

howard@zaxcom.com (howy) writes:

> > bothering me: the Program/Data cache. What good is a data-cache when I
> > have to set my parameters (ie buffersize, numtaps, ect) for the worst
> 
> I am writing code on a C6713 for a hard disk audio recorder which uses
> the DSP for everything from audio processing to the GUI. The binary
> program takes up about 3Mbytes of SDRAM. The C6713 has 256Mbytes of

k Bytes, surely :-)                                         ^^^^^^

> internal ram that can be used as cache and/or internal program/data
> RAM.
> 
> With the cache turned off I get a 50X hit in performance (not 50
> percent, 50 times)! The real-time audio processing interrupt is too
> large to fit in internal memory. 

Sounds like a big interrupt service!  Can it not be split, so that the
*really really* time critical bits can live in internal RAM all the time?
<snip>

Cheers,
Martin

-- 
martin.j.thompson@trw.com
TRW Conekt, Solihull, UK
http://www.trw.com/conekt