Configuring Memory Settings for Optimal Performance with the LabVIEW Embedded Module for Blackfin Processors

Defining a strategy for memory utilization is critical for optimizing an embedded application. Ideally, an embedded programmer could place an entire application in the "good memory", which is that closest to the chip. However, the physical constraints of today's embedded processors make it impossible to have enough of the "good memory" for large applications, as chip vendors fulfill the need for low-power designs and chip footprints become smaller and smaller. Not to mention design complexity continues to drive code size to more of lines of code. This article describes how to configure a LabVIEW Embedded Module for Blackfin Processors application for optimal memory usage.

Overview of Blackfin Memory

The physical location of memory in respect to the processor is the first consideration when defining a memory strategy for an embedded application. The following diagram shows the memory hierarchy of a Blackfin processor.




Internal memory on the Blackfin consists of L1 and L2 memory, with L1 being the fastest. L1 memory will be discussed in more detail later in the "VI Mapping" section of this document. L2 memory is not available on all Blackfin processors, but more information on L2 memory can be found in the ADSP-BF53x/BF56x Blackfin Processor Programming Reference.

L3 memory, or external memory, is commonly found in one of three forms: synchronous, asynchronous, or nonvolatile. The Blackfin processor has an external memory controller that supports both synchronous and asynchronous types. It's also important to note that these two types of memory are directly memory-mapped to the Blackfin's memory space. In contrast, nonvolatile memory, such as Nand or Nor flash, have to be indirectly accessed.

The memory map of the Blackfin defines address locations for internal and external memory (L1, L2, and L3). By default, the Embedded Module for Blackfin Processors is configured to map either the ADSP-BF533 or ADSP-BF537 EZ-KIT memory to the memory map below. To learn about how to target a custom Blackfin design from LabVIEW Embedded, which takes into account different memory map settings, refer to the application note Deploying a Design from the LabVIEW Embedded Module for Blackfin Processors to a Custom Target. The following table contains the memory addresses of the ADSP-BF537 Memory Map. These address locations will never change regardless of the Blackfin design.

Cache is a high-level memory that is not directly accessed by the developer, but implemented on the Blackfin via a cache controller. The cache controller allows larger instruction and data sections to exist in low-level memory, and code and data that are used most frequently are brought into cache (by the cache controller) and thus, are available for single-cycle access, just as though it was in L1 memory. (See the Analog Devices application note EE-271: Cache Memory on Blackfin Processors for more information on cache)

Caching can be thought of as putting a "copy" of a block of external memory closer to the chip in internal memory, for faster memory access times. Different caching methods are used depending on whether an instruction cache or a data cache is used, and these caching methods attempt to predict which blocks of memory need to be copied. If the correct block is chosen, this is the optimal case and is called a cache "hit". As the diagram below illustrates, the time to access memory with cache enabled when a cache "hit" occurs is much shorter then the alternative with no caching.



To enable cache in the Embedded Module for Blackfin Processors, from the Embedded Project Window, select Target >> Build Options...



In the Advanced tab, choose to Enable cache. Cache can be enabled for instructions only, for data only, or for both.




Note: Not all applications will benefit from caching, but if you are unsure it's strongly recommended to enable cache and compare the performance vs. no cache.

VI Mapping

Ideally, an embedded programmer could place an entire application in the "good memory", which is that closest to the chip (L1 memory). While that's not going to be physically possible, when tweaking performance it's still necessary to use L1 memory for optimizing certain pieces of your code, even if it all won't fit there.

The following table outlines the available L1 memory on the ADSP-BF537, broken up by instruction vs. data memory. The reason there is a distinction between memory used for instructions or memory used for data, is because there are multiple busses that interface from the Blackfin processor core to L1 memory, which means breaking up the memory in this manner is more efficient and allows the developer greater flexibility in defining a memory strategy.

Scratchpad SRAM is a dedicated 4K byte bank of scratchpad data SRAM. The scratchpad is independent of the configuration of the other L1 memory banks and cannot be configured as cache or targeted by DMA. Typical applications use the scratchpad data memory where speed is critical. It can be accessed by the core processor at full performance. In LabVIEW, scratchpad SRAM is very useful for large data sets such as look-up tables. To map a particular VI to a section of memory, from the Embedded Project Window, select Target >> Memory Map...


A dialog box will appear with all the VI's in your LabVIEW application. In the example below, only one VI is available, and it configured for "Linker Default" memory mapping in both Code (or Instruction) and Data.



The linker default is to always put the entire LabVIEW application in external memory (SDRAM).

The linker default is to always put the entire LabVIEW application in external memory (SDRAM). This default can be easily changed, however, and each VI can be mapped into specific L1 memory for both code and data.

Conclusion

Configuring an embedded application for optimal memory usage should not be overlooked. In most cases, enabling cache is strongly recommended. Additionally, techniques such as putting arrays of data in scratchpad memory SRAM can further speed up an application.

Reader Comments | Submit a comment »