MCF5441x Data Cache Closed Beta

Discussion to talk about software related topics only.
Post Reply
User avatar
dciliske
Posts: 623
Joined: Mon Feb 06, 2012 9:37 am
Location: San Diego, CA
Contact:

MCF5441x Data Cache Closed Beta

Post by dciliske »

We have recently implemented the Data Cache on MCF5441x based products for the DDR memory region. Using a task-switch performance test (testing the various OS Task control structs: OS_SEM, OS_FIFO, etc.), the cache has increased the DDR memory performance to 95% of the SRAM performance, a >200% increase for tight loops.

Now, there are some caveats with the cache. First, network buffers are explicitly *not cached*. The cache hardware does not perform bus snooping, and therefore cannot make itself aware of other bus masters accessing the cached region. Importantly, these other bus masters include the Ethernet module and the eDMA controller. For the Ethernet module, we take care of this by modifying the linker script to place the PoolBuffers in an uncached memory region. Given that these buffers are explicitly designed to be used by this hardware and are large relative to size of the cache, it does not make sense to try and cache them. Additionally, the hardware control descriptors are in SRAM, which is uncached. However, because SRAM is disabled in Debug builds, the cache is also disabled for debug.

The only change, albeit a very important one, for *some* customer code is if you are using any other Bus Master to *write* to DDR memory other than the PoolBuffers. To this, I am talking primarily those few of you who have written code to utilize the eDMA controller for various things.

The data cache has been configured in "Write-Through, Data Store Buffer Enabled" mode. This means that any write access to memory that hits the cache, will also perform a write out to the physical memory location as well, keeping them synchronized. However, because the Data Store Buffer is used, the write is queued instead of written immediately and stalling the core. This does however mean that for any write, the pipeline needs to be synchronized before allowing other bus masters to read from the written memory. This means either waiting a sufficient number of cycles or issuing a 'NOP' command.

Finally, the real major issue for using other masters (like the eDMA) is that the cache needs to be invalidated for regions that are touched by them. To that end, we have implemented several functions to easily identify whether a buffer is in the cacheable region and to invalidate it's possible cache data. We make use of both of these in the updated DSPI driver to invalidate any cacheable read buffer before initiating the transaction.

Usually, we roll out new features in a full release. However, some features due to their complexity and timing we like to send out to a select handful of knowledgable users for initial use (i.e. IPv6). This is one of those complex issues. We have just released 2.8.2. This change provides a large amount of positive impact for users that we want to get it into people's projects as soon as possible, but also can *really break* applications in subtle and unexpected ways. It is also a change that is highly coupled to changes in the build system, and therefore difficult to remove (but not disable).

For these reasons, we wish to perform a limited off-cycle closed beta to interested parties. If you are so inclined, please submit a support request and we will provide you with the patch and final documentation.
Dan Ciliske
Project Engineer
Netburner, Inc
Post Reply