www.ti.com
Data Memory
The only resources consumed by eXpressDSP-compliant algorithms are MIPS and memory. All I/O, peripheral control, device management, and scheduling is managed by the application — not the algorithm. Thus, we need to characterize code and data memory requirements and worst-case execution time.
There is one important addition, however. It is possible for an algorithm to inadvertently disrupt the scheduling of threads in a system by disabling interrupts for extended periods. Since it is not possible for a scheduler to get control of the CPU while interrupts are disabled, it is important that algorithms minimize the duration of these periods and document the worst-case duration. It is important to realize that, due to the pipeline of modern DSPs, there are many situations where interrupts are implicitly disabled; e.g., in some zero-overhead loops. Thus, even if an algorithm does not explicitly disable interrupts, it may cause interrupts to be disabled for extended periods.
4.1Data Memory
All data memory for an algorithm falls into one of three categories:
∙Heap memory - data memory that is potentially (re)allocated at run-time;
∙Stack memory - the C run-time stack; and
∙Static data - data that is fixed at program build time.
Heap memory is bulk memory that is used by a function to perform its computations. From the function's point of view, the location and contents of this memory may persist across functions calls, may be (re)allocated at run-time, and different buffers may be in physically distinct memories. Stack memory, on the other hand, is scratch memory whose location may vary between consecutive function calls, is allocated and freed at run-time, and is managed using a LIFO (Last In First Out) allocation policy. Finally, static data is any data that is allocated at design-time (i.e., program-build time) and whose location is fixed during run-time.
In the remainder of this section, we define performance metrics that describe an algorithm'sdata memory requirements.
4.1.1 Heap Memory
Heap memory is run-time (re)allocable bulk memory that is used by a function to perform its computations. From a function'spoint of view, the location and contents of this memory may persist across functions calls, may be (re)allocated at run-time, and different buffers may be in physically distinct memories.
It is important to note that heap memory can be allocated at design-time and avoid the code space overhead of run-time memory management. The only requirement is that all functions that access this memory must assume that it may be allocated at run-time. Thus, these functions must reference this memory via a pointer rather than a direct reference to a named buffer.
Rule 19
All algorithms must characterize their worst-case heap data memory requirements (including alignment).
All algorithms must characterize their worst-case data memory requirements by filling out the table below. Each entry should contain a pair of numbers corresponding to the size (in 8-bit bytes) required and an alignment (in 8-bit bytes). If no special alignment is required, the alignment number should be set to zero. Note that the numbers supplied may represent aggregate totals. For example, if an algorithm requires two unaligned External data buffers, it may report the sum of the sizes of these buffers.
| | DARAM | | SARAM | | External |
| Size | Align | Size | Align | Size | Align |
Scratch | 0 | 0 | 1920 | 0 | 0 | 0 |
Persistent | 0 | 0 | 0 | 0 | 1440 | 0 |
