System memory requirement evaluation of SOC embedded software architecture design

Reproduced in the original: http://blog.csdn.net/yueqian_scut/article/details/24602941 thank you very much.

Memory is an important module of SOC (System on chip, systems on chip) integrated design, and it is a part of the SOC which has a large proportion of cost. Memory management software and hardware design is an important part of SOC software architecture design, architects must balance cost and efficiency, so as to save memory while guaranteeing the performance of the whole system. System memory requirements Assessment is the most basic requirement for embedded software architects and one of its most important skills. In general, when the SOC project is approved, the architect will complete the system memory needs assessment.

The following is a prototype of the SOC design in a multimedia electronic solution that illustrates the approximate evaluation process:

 

1. Perform functional and performance decomposition of each application according to product specifications

Product specifications typically describe application feature scenarios and performance. The architect will perform functional and performance decomposition of each scenario and analyze the relationship of each scenario to memory usage. Including:

1) List all the application scenarios, identify the life cycle of each application, when and when it will end.

2) Whether the system to support multiple applications (multi-process), such as listening to the song to browse the picture, which means that the two applications are simultaneously using memory, can not be applied memory time-sharing;

3) Whether the system to support a variety of media, such as simultaneous access to card devices and flash devices, generally in a single process only access to a single storage device, unless the implementation of data replication, but in multi-process, different processes to access different storage devices is also normal, Simultaneous access to different storage devices means that two drivers are using memory simultaneously.

4) Whether the system should support multiple file systems at the same time. Different storage devices may have problems deploying different file systems, which also exist in 2).

5) Explicit system-supported codec format, which shows the algorithm memory requirements. Different codec formats require different memory requirements, and the same algorithm, at different rates, also leads to different memory requirements.

6) System performance requirements, such as LCD brush screen, a large framebuffer will naturally have better performance.

2. Layering the system software to clarify the composition of each layer of the module

1) System sub-start, drive, operating system, file system, middleware (algorithm, UI), application framework, application and other levels, general consumer electronics products, such as multimedia equipment, game consoles and other product systems will be divided into multiple levels. Each layer will be composed of several modules, such as driving the sub-character device driver and block device driver, the general key is a character device, storage device is generally a block device, storage device may support NAND flash, SD-MMC card, uhost, etc., file system has FAT32, EXFAT, etc. The application layer will of course include a number of applications.

2) Define the level of software required for each application implementation. Some applications may require many layers, such as music, from applications to application frameworks (ui+ keys), APIs, middleware (decoding), operating systems, drivers, and so on, where the application does not need to decode the middleware.

3. Identify the modules for memory-sharing multiplexing in each software hierarchy to find the maximum memory requirements

such as "memory-saving software design skills" This article mentions that applications, drivers, middleware, data segments have the need for reuse. To distinguish the different constituent modules in each software hierarchy in 2, it is clear that each module can be used for time-sharing. In the case of multiplexing, to find the maximum memory requirements of the module, such as NAND flash driver is more complex than the card driver, the NAND flash drive memory demand is naturally high, and music applications are naturally more complex than settings or FM applications, and its memory needs naturally more.

    

4. The code for the maximum memory requirement module is analyzed, and the code of its resident memory code and block (bank) management is roughly defined.

Resident code snippets are generally called frequent, high-performance code snippets, such as interrupt management, message management, and so on. A large number of code in general applications can be loaded on demand, such as music sound management and volume settings These function codes do not require a high performance, it is possible to load time-sharing into memory execution, to achieve the purpose of memory time-sharing.

5. Determine the space of resident code space and time-sharing memory for each software hierarchy

Minimizing the amount of resident code space under the cost requirements can lead to a decrease in code execution performance because the bank code is loaded before execution, typically from NAND flash or card, and we want to minimize the memory space used by the bank code as far as the cost is required. It can also cause the bank code to switch frequently and degrade performance, so it can not blindly reduce memory, but carefully analyze the function and performance of each sub-module to the memory of the approximate requirements. For example, the function implementation of two sub-modules is 8k and 4k, then we can consider the 2K reuse space, that is, the former divided into 4 banks, the latter 2 banks, whether it can achieve performance, if the reuse space is set to 4K, the efficiency will be higher, but the cost will increase, if set to 1k, the former will have 8 bank , too many switches.

6. Clear code space that can be cured

Application of resident code is not curable, because different applications need resident code, that is, it is changing, and like operating system interrupt management, time management, task scheduling management and other code is generally unchanged, it can be cured to ROM, so as to achieve the purpose of saving memory.

7. Consideration of other special needs

By 6, we can roughly get the memory requirements of the whole system. Consider the memory requirements of some special scenarios to see if the previously developed memory will satisfy this scenario. For example, the memory requirements distribution in the startup phase, memory requirements during OS boot initialization, and so on. These are not the specifications of the product, it is also the architectural designer to consider.

Typically, the memory obtained in 6 is evaluated again for minor adjustments.

Please focus on the SOC Embedded software Architecture Design (Controller SOC firmware architecture) Series Blog:

One of SOC Embedded software Architecture design: System memory requirement evaluation

Soc Embedded Software Architecture design two: CPU without MMU design method of virtual memory management

Soc Embedded Software Architecture design Three: Code chunking (Bank) Design principles

Soc Embedded Software Architecture design four: Memory space planning allocation

The design of SOC Embedded software architecture: The reconfiguration of executable program

Embedded: Memory-saving Software design tips