SOC embedded software architecture design: system memory requirement Evaluation

Memory is an important module in the Integrated Design of SOC (system on chip, on-chip system) and a significant proportion of cost in SOC. The software and hardware design of memory management is an important part of SOC Software Architecture Design. architects must balance costs and efficiency to ensure the performance of the entire system while saving memory. System memory requirement evaluation is the most basic requirement for Embedded Software architects and one of their most important skills. Generally, when the SOC project is established, the architect must evaluate the system memory requirements.

The following uses the SOC design in a multimedia electronic solution as a prototype to describe the general evaluation process:

 

1. function and performance decomposition for each application Scenario Based on Product Specifications

Product specifications generally describe application function scenarios and performance. Architects need to break down functions and performance of various scenarios and analyze the relationship between various scenarios in memory usage. Including:

1) list all application scenarios, define the life cycle of each application, and when.

2) whether the system must support multiple applications (multi-process) at the same time. For example, when listening to a song, you must browse the image. This means that the two applications use the memory at the same time and cannot use the memory at the same time;

3) whether the system must support multiple types of media at the same time, for example, accessing card devices and flash devices at the same time. Generally, only a single storage device is accessed during a single process, unless data replication is performed, however, in multi-process scenarios, it is normal for different processes to access different storage devices. Accessing different storage devices at the same time means that the two drivers use the memory at the same time.

4) whether the system must support multiple file systems at the same time. Different Storage devices may deploy different file systems, which also has 2) problems.

5) Specify the encoding/decoding formats supported by the system, as shown in the algorithm memory requirements. Different codec formats have different requirements on memory. In the same algorithm, different rates also lead to different memory requirements.

6) system performance requirements, such as LCD screen flushing. A large framebuffer will naturally provide better performance.

 

2. Hierarchy System software to clarify the composition of each layer of modules

1) The system is divided into startup, driver, operating system, file system, middleware (algorithm, UI), application framework, application, and other levels, general consumer electronic products, product systems such as multimedia devices and game consoles are divided into multiple layers. Each layer is composed of multiple modules. For example, if the driver is a character-driven device or a block device, the buttons generally belong to the character device, and the storage device generally belongs to the block device; storage devices may support NAND Flash, SD-MMC card, uhost and so on; file systems and FAT32, exfat and so on; Application Layer of course will include many applications.

2) define the software layers required for each application implementation. Some applications may need many layers, such as music, from application to Application Framework (ui + buttons), API, middleware (Decoding), operating system, and driver, however, you do not need to decode the middleware when setting the application.

3. Define the memory time-sharing module in each software layer, and find out the module with the maximum memory requirement.

As mentioned in the article "memory-saving embedded software design skills", application, driver, middleware, and data segments are all reusable. It is necessary to distinguish different component modules at each software layer in 2) to determine whether each module can be used for time-sharing. In the case of multiplexing, find out the module with the largest memory requirement. For example, if the NAND Flash Driver is more complex than the card driver, the memory requirement of the NAND Flash Driver is naturally higher; however, music applications are naturally more complex than those set up or FM applications, and naturally require more memory.

4. Analyze the code of the maximum memory requirement module to roughly identify the code of its resident memory code and the code of block (bank) management.

Resident code segments are generally frequently called code segments with high performance requirements, such as interrupt management and Message Management. Generally, a large amount of code in an application can be loaded and executed on demand. For example, music sound effect management and volume setting do not require high execution performance, it can be loaded to the memory for execution in a time-based manner to achieve the purpose of memory time-based multiplexing.

5. Determine the resident code space at each software level and the space for time-sharing memory.

Reducing the resident code space as much as possible at the cost will reduce the code execution performance, because the bank code should be loaded before execution, generally read from NAND Flash or card; at the cost, we also want to minimize the memory space used by bank code reuse. This will also lead to frequent bank code switching and lower performance, so we cannot blindly reduce the memory, instead, we carefully analyze the general requirements on memory for the functions and performance of each sub-module. For example, if the function implementation of the two sub-modules is 8 K and 4 K, we can consider the 2 k multiplexing space, that is, whether the former is divided into 4 banks and the latter two banks can achieve performance; if the reuse space is set to 4 K, the efficiency will be higher, but the cost will increase; if it is set to 1 K, the former will have 8 banks, with too many switching times.

6. Define the code space that can be solidified

The resident code of an application cannot be solidified, because different applications need resident code, that is, it is changed, code such as the interrupt management, time management, and task scheduling management of the operating system remains unchanged, which can be solidified into the Rom to save memory.

7. Consider other special requirements

Through 6, we can obtain the memory requirements of the entire system. In this case, we need to consider the memory requirements in some special scenarios to see whether the previously developed memory can meet the requirements of this scenario. For example, the memory demand distribution in the startup phase and the memory requirements during OS boot initialization. These are not the specifications of the product. They must also be considered by architects.

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

 

SOC embedded software architecture design: system memory requirement Evaluation