Automatic storage allocation method for multi-core DSP based on model-driven

Abstract

The present invention relates to the field of embedded information processing, and specifically to a multi-core DSP automatic storage allocation method based on model drive. It includes the following steps: S1, establishing a model / component design specification that meets the DSP operation; S2, using the automatic code generation technology based on "hierarchical class library" to create the data types, scalars, and vectors required by the model, using the "free combination union" function to automatically generate union variables that can be used by various models in a single processor, and automatically generating cross-processor union variables at the same time, integrating the above process into the model design specification and assisted by IDE; S3, using template-based configuration file generation technology to automatically generate engineering and corresponding storage configuration files. The present invention solves the problems of storage definition and allocation in conventional multi-DSP software systems, greatly improves the coding efficiency during storage allocation, significantly reduces the error probability, and also ensures the economical use of storage resources from a mechanism perspective.

Description

Technical Field

[0001] The invention relates to the field of embedded information processing, and in particular to a multi-core DSP automatic storage allocation method based on model driving. Background Art

[0002] At present, multi-core DSPs such as imported TI (C5X, C6X series) and domestic FT (M6678) are widely used in military and civilian embedded processing fields. Unlike the X86 platform, the above DSPs (imported TI and domestic FT multi-core DSPs) use multi-level data caches. The L1 program cache and L1 data cache are close to the core, and the L2 cache and multi-core shared memory (MSM, MultiCore Shared Memory) and DDR3 memory (Double-Data-Rate Three SynchronousDynamic Random Access Memory) are outward. The closer the memory is to the core, the smaller the storage capacity of the memory, but the faster the memory access speed; the farther the memory is from the core, the larger the storage capacity of the memory, but the lower the memory access speed. When the core frequency is 1GHz, the communication bandwidth of L1 data cache and L1 program cache is 32GB / s, the communication bandwidth of L2 cache is 16GB / s, and the communication bandwidth of multi-core shared memory is 64GB / s. When the main frequency of DDR3 memory is 1333MHz, the bandwidth is 10.664GB / s. Figure 1 As shown in the C66XX / FT6678 storage architecture diagram, the L1 data cache and L1 program cache are 32KB, the L2 cache is 512KB, the multi-core shared memory is 4MB, and the DDR3 is 2GB. From the architecture of the multi-core C6678DSP, it can be seen that when the data is placed in the memory closer to the core, the computing performance is higher, but due to the limitation of storage capacity, the amount of tasks that can be completed is smaller.

[0003] From the above analysis, we can see that in software development based on multi-core DSP, the strategy of variable creation directly determines the final running efficiency of the code and the real-time performance of the system, which can sometimes be up to 5-10 times. The conventional variable creation strategy is shown in Table 1:

[0004] Table 1 Conventional variable development strategy

[0005]

[0006] Based on the variable allocation strategy in Table 1, the storage definition and allocation of an embedded system composed of multiple DSPs usually follows the following steps:

[0007] Step 1: Write a storage configuration file (CMD file) to set the stack and DDR space. These operations are closely related to the underlying hardware and require high standards from developers. Once the CMD file is set incorrectly, the software will crash or the results will be inexplicable, making troubleshooting difficult and time-consuming.

[0008] Step 2: Determine the software functions implemented on each processor and define various scalars, vectors, and matrices in each source file (usually C / C++) deployed to the processor. Often different designers have their own definition styles, and the code is not easy to maintain.

[0009] Step 3: According to the performance requirements, the variables defined in step 2 are reasonably allocated to different storage areas (L2 / MSM / DDR).

[0010] Step 4: As functions increase, variables increase and are distributed over a wide range. At the same time, the L2 / MSM storage area may overflow, and a lot of time is needed to coordinate various vectors / matrices in many files. Otherwise, additional processors are needed, resulting in a waste of hardware resources.

[0011] Step 5: In order to reduce the difficulty of software debugging and maintenance of complex systems (multiple DSPs), it is necessary to put several processor codes into the same project, which will cause the variables opened in the same storage area on different processors to overlap with each other, wasting storage space. To avoid this problem, it is necessary to define "union variables", which further increases the difficulty of variable / storage design, such as Figure 2 shown.

[0012] At present, in the storage allocation link of embedded software development based on multi-core DSP, there are the following problems:

[0013] First, storage allocation often lacks a unified framework and specifications. Developers’ habits play a dominant role, and variables are randomly allocated to different files, which is not only prone to errors but also difficult to maintain and upgrade.

[0014] Second, most of them use completely manual methods to declare types and define variables, which is not only inefficient but also prone to errors.

[0015] Third, the vectors required by different functions often occupy DSP storage exclusively, resulting in a waste of storage resources. When no storage resources are available, the only solution is to expand the hardware, which increases the cost of expanding the system hardware scale.

[0016] Fourth, most projects and storage configuration files are created manually, which places higher demands on the capabilities of developers, leads to duplication of work between projects, low efficiency, and is prone to errors. Summary of the invention

[0017] The purpose of the present invention is to propose a multi-core DSP automatic storage allocation method based on model-driven to address the problems existing in the background technology, which effectively solves the above problems, greatly improves the coding efficiency during storage allocation, significantly reduces the error probability, and also ensures the economical use of storage resources from a mechanism perspective and supports the "signal level" modeling and simulation in model-based system engineering (MBSE).

[0018] The technical solution of the present invention is a multi-core DSP automatic storage allocation method based on model-driven, comprising the following steps:

[0019] S1. Establish model / component design specifications that meet DSP operation;

[0020] S2. Use the automatic code generation technology based on "hierarchical class library" to create the data types, scalars, and vectors required by the model. Use the "free combination union" function to automatically generate union variables that can be used by various models in a single processor, and automatically generate cross-processor union variables. Integrate the above process into the model design specification and implement it with the assistance of IDE;

[0021] S3, using template-based configuration file generation technology to automatically generate projects and corresponding storage configuration files.

[0022] Preferably, in step S1, according to the object-oriented design concept and the requirements of MBSE model abstraction, the model design specification is established from the dimensions of input / output ports, function implementation, control and interface, and the functions of each part are as follows:

[0023] Input / output port: responsible for the I / O of the model, sending and receiving data;

[0024] Functional implementation: responsible for the functional implementation of the model, which is a collection of files. Each file contains several functional functions. When the user completes the configuration, these files and the main entry function of functional scheduling are automatically generated by the tool;

[0025] Control: responsible for the scheduling of model functions, determining the conditions and timing / moment to schedule the function;

[0026] Interface: responsible for implementing model storage and recovery, debugging, monitoring, and file operations.

[0027] Preferably, in step S2, the steps assisted by the IDE are as follows:

[0028] S21. Set basic model information: name, author, date, version and description;

[0029] S22. Set the model input, output, configurable parameters required for function implementation, and vectors required for operation.

[0030] Preferably, step S22 comprises the following sub-steps:

[0031] Sub-step 1: Create a hierarchical class library to support automatic generation of data type definitions and variable development. For codes and variables that are frequently edited by users, automatic code generation is achieved by generating variable strings and writing them into files as the user edits. Its essence includes two main processes: string generation and file generation.

[0032] Sub-step 2: Use the hierarchical class library to generate header files describing variable types, variable definition source files, and related files describing the model;

[0033] Sub-step 3: Rationally plan the allocation of variables.

[0034] Preferably, the specific strategy of sub-step 3 is as follows:

[0035] First, for the single-processor multi-model scenario where multiple models run on the same processor, the model running order is analyzed, and the vectors with the same storage space in the serially executed models are combined to form a cross-model union variable;

[0036] Secondly, for multi-processor and multi-model scenarios belonging to the same project, the IDE automatically combines the arrays, structures, and unions of each processor into the top-level "big structure", and then automatically combines all top-level "big structures" under the project;

[0037] Finally, call the model file generation class to create the .h and .cpp files corresponding to each model.

[0038] Preferably, the specific steps of step S3 are as follows:

[0039] S31, making a storage configuration file template and project file templates corresponding to different platforms, the storage configuration file is referred to as a CMD file;

[0040] S32. Design storage configuration file generation class, responsible for managing and changing CMD files;

[0041] S33, design engineering file generation class, responsible for managing and changing various engineering files, the corresponding engineering files are .project / .ccsproject;

[0042] S34. During daily project development, users can modify CMD files through UI operations. At this time, the storage configuration file generation class collects user modification information and automatically completes the modification of the CMD file.

[0043] Compared with the prior art, the present invention has the following beneficial technical effects:

[0044] First, the model-driven multi-core DSP storage allocation framework and method: the model-driven development model widely used in X86 and ARM platforms is extended and expanded to the embedded strong real-time processing field using multi-core DSP. Based on the abstraction and definition of the embedded platform operation model, global variables serve the input, output and function realization of the model. Therefore, the logic and framework of global variable storage allocation are solidified, the allocation method is standardized, and the definition is unified and intensive, and no longer scattered in different files according to user habits.

[0045] Second, the present invention proposes a multi-core DSP storage allocation code automatic generation technology based on a "hierarchical class library". By building a hierarchical class library and setting variable types and names in the IDE, the declaration and definition of various (including complex structure types) variables can be automatically completed (including automatic creation of corresponding header files and source files).

[0046] Third, the present invention proposes a multi-core DSP storage saving technology based on "free combination union". With the help of UI, different vectors in multiple models in a single processor can be freely combined according to the execution mode and the corresponding code can be automatically generated. At the same time, for multi-processor and multi-project scenarios, all storage overheads of a single processor can be automatically defined as a top-level "large structure" and combined with other processors.

[0047] Fourthly, the present invention proposes a "template-based" engineering and storage configuration file automatic generation technology, which automatically generates, manages, and maintains system-level files such as storage configuration and engineering based on the template. BRIEF DESCRIPTION OF THE DRAWINGS

[0048] Figure 1 This is a schematic diagram of the C66XX / FT6678 storage architecture;

[0049] Figure 2 It is a block diagram of the storage and engineering relationship of a conventional multi-DSP software system;

[0050] Figure 3 Abstract schematic diagram for models / components;

[0051] Figure 4 A hierarchical class library to serve automatic code generation;

[0052] Figure 5 Flowchart for automatic variable code generation using hierarchical class libraries;

[0053] Figure 6 A schematic diagram of a single processor multi-model storage free combination union;

[0054] Figure 7 Automatically generate technical block diagrams for template-based configuration files;

[0055] Figure 8 An interface for model configuration through IDE;

[0056] Fig. 9 It is an interface for freely combining multiple model combinations through IDE. DETAILED DESCRIPTION

[0057] The multi-core DSP automatic storage allocation method based on model driving proposed by the present invention comprises the following steps:

[0058] First, establish model / component design specifications that meet DSP operation, incorporate storage demand management into the specifications (especially vector / matrix variables), eliminate personalized development, scattered and irregular development, and establish model design specifications from the input / output port, function implementation, control and interface dimensions in accordance with object-oriented design ideas and MBSE model abstraction requirements, such as Figure 3 As shown, the functions of each part are as follows:

[0059] Input / output port: responsible for the I / O of the model, sending and receiving data;

[0060] Functional implementation: responsible for the functional implementation of the model, which is a collection of files. Each file contains several functional functions. When the user completes the configuration, these files and the main entry function of the functional scheduling are automatically generated by the tool;

[0061] Control: responsible for the scheduling of model functions, determining the conditions and timing / moment to schedule the function;

[0062] Interface: responsible for implementing model storage and recovery, debugging, monitoring, file operations, etc.

[0063] Second, the automatic code generation technology based on "hierarchical class library" is used to create the data types, scalars, and vectors required by the model. The "free combination union" function is used to automatically generate union variables that can be used by various models in a single processor, and automatically generate cross-processor union variables. The above process is integrated into the model design specification and implemented with the assistance of IDE (Integrated Development Environment). The steps of IDE-assisted implementation are as follows S21 and S22:

[0064] S21, such as Figure 7 As shown, set the basic information of the model: name, author, date, version, description, etc.

[0065] S22, such as Figure 7 As shown, set the model input, output, configurable parameters required for function implementation, and vectors required for operation. This step includes the following sub-steps:

[0066] Sub-step 1: Create a hierarchical class library to support automatic generation of data type definitions and variable development. The composition of the class library is as follows: Figure 4 As shown in Figure 2, for the codes and variables that users frequently edit, automatic code generation is achieved by following the user's editing to generate variable strings and write them into files. Its essence includes two main processes: string generation and file generation. For this purpose, a hierarchical class library is designed, and the main functions of each class are shown in Table 2.

[0067] Table 2 Introduction to hierarchical class libraries for automatic code generation

[0068]

[0069] Sub-step 2: Figure 5 As shown, using the hierarchical class library, header files describing variable types, variable definition source files, and related files describing models (.h / .cpp) are generated respectively;

[0070] Sub-step 3: DSP storage space (especially on-chip storage space) is very limited, while the complexity of signal processing algorithms leads to an increase in storage requirements, and the stringent real-time requirements lead to the efficient use of on-chip storage requirements. In view of the above contradictions, the allocation of variables must be reasonably planned, otherwise the system hardware requirements will expand exponentially. The specific strategies are as follows:

[0071] First, for the single-processor multi-model scenario where multiple models run on the same processor, the model running order is analyzed, and vectors in the same storage space (for example, all in L2) in the serial (non-parallel) executed models are combined to form a cross-model union variable;

[0072] Secondly, for multi-processor and multi-model scenarios belonging to the same project, the IDE automatically combines the arrays, structures, and unions of each processor into the top-level "big structure", such as Fig. 9 As shown, all top-level "large structures" under the project are automatically combined, and users do not need to write code manually, such as Figure 6 As shown;

[0073] Finally, call the model file generation class to create the .h and .cpp files corresponding to each model.

[0074] Third, if Figure 7 As shown, a template-based configuration file generation technology is used to automatically generate a project and a corresponding storage configuration file. The specific steps are as follows S31, S32, S33 and S34:

[0075] S31, making a storage configuration file template and project file templates corresponding to different platforms, the storage configuration file is referred to as a CMD file;

[0076] S32. Design storage configuration file generation class, responsible for managing and changing CMD files;

[0077] S33, design engineering file generation class, responsible for managing and changing various engineering files, such as TI66xx series DSP, the corresponding engineering file is .project / .ccsproject;

[0078] S34. During daily project development, users can modify CMD files through UI operations. At this time, the storage configuration file generation class collects user modification information and automatically completes the modification of CMD files. This method can ensure that CMD files will not be changed arbitrarily or modified by mistake.

[0079] The advantages of the present invention are as follows:

[0080] First, the model-driven multi-core DSP storage allocation framework and method: the model-driven development model widely used in X86 and ARM platforms is extended and expanded to the embedded strong real-time processing field using multi-core DSP. Based on the abstraction and definition of the embedded platform operation model, global variables serve the input, output and function realization of the model. Therefore, the logic and framework of global variable storage allocation are solidified, the allocation method is standardized, and the definition is unified and intensive, and no longer scattered in different files according to user habits.

[0081] Second, a multi-core DSP storage allocation code automatic generation strategy / process based on a "hierarchical class library": After determining the framework and method followed by the storage allocation, in order to reduce the proportion of manual code writing, improve coding efficiency, and reduce the probability of error. The present invention proposes a multi-core DSP storage allocation code automatic generation technology based on a "hierarchical class library". By building a hierarchical class library and setting variable types and names in the IDE, the declaration and definition of various (including complex structure types) variables can be automatically completed (including the automatic creation of corresponding header files and source files).

[0082] Third, a multi-core DSP storage saving strategy / process based on a "free combination union": While completing the standardized and efficient allocation of multi-core DSP storage allocation, in order to further save storage resource overhead and improve its utilization efficiency, the present invention proposes a multi-core DSP storage saving technology based on a "free combination union". With the assistance of the UI, different vectors in multiple models in a single processor can be freely combined according to the execution method and the corresponding code can be automatically generated. At the same time, for multi-processor and multi-project scenarios, the entire storage overhead of a single processor can be automatically defined as a top-level "large structure" and combined with other processors.

[0083] Fourth, the strategy / process for automatic generation of multi-core DSP engineering and storage configuration files based on "templates": After completing the design of each DSP function, in order to further reduce the difficulty of development, the present invention proposes an automatic generation technology of engineering and storage configuration files based on "templates", which automatically generates, manages, and maintains system-level files such as storage configuration and engineering based on templates.

[0084] In the model-driven multi-core DSP storage allocation framework and method, there may be the following alternatives or practices, but the essence is the same:

[0085] 1) Replace "model" with "component" or similar terms.

[0086] 2) In the process of model abstraction, "input parameters", "output parameters", "intermediate arrays" (see Figure 8 ) are places where storage is used extensively in the program. Their descriptive names may also be changed, but their essence is still to define data types (such as structures) and various variables (such as structure variables, large arrays or vectors, etc.).

[0087] In the multi-core DSP storage allocation code automatic generation strategy / process based on the "hierarchical class library", there may be the following alternatives or practices, but they are essentially the same:

[0088] 1) Replace the "hierarchical class library" with another name, or change the names of various classes in the class library, but their functions are similar.

[0089] 2) It is not implemented using object-oriented programming (that is, by creating a class library), but the process is similar to Figure 5 similar.

[0090] In the multi-core DSP storage conservation strategy / process based on the "free combination union", there may be the following alternatives or practices, but they are essentially the same:

[0091] 1) Not based on the model, but still achieves storage conservation by defining the federation, the process and Figure 6 similar.

[0092] 2) The "large structure" (used to automatically combine with other processors) generated by the single processor is renamed, but it is still a structure in essence.

[0093] 3) Not through the UI (see Fig. 9 ) for automatic union, but the essence is still to design a union for arrays in non-parallel code.

[0094] 4) UI interface and Fig. 9 Different, but the essence is still to select arrays / vectors that can be combined for union design.

[0095] 5) The name of the "big structure" union process between processors is changed, but the essence is still to define the union.

[0096] In the "template-based" multi-core DSP engineering and storage configuration file automatic generation strategy / process, there may be the following alternatives or practices, but the essence is the same:

[0097] 1) The names of "Storage Configuration File Class" and "Project File Class" are different, but their functions are similar.

[0098] 2) It is not implemented using object-oriented programming (that is, by creating a class library), but the processing flow is similar to Figure 7 The right half of the process is similar.

[0099] The embodiments of the present invention are described in detail above with reference to the accompanying drawings, but the present invention is not limited thereto, and various changes can be made within the knowledge scope of technicians in the relevant technical field without departing from the purpose of the present invention.

Claims

1. A multi-core DSP automatic storage allocation method based on model-driven, characterized in that: The steps include: S1. Establish model / component design specifications that meet DSP operation; S2. Use the automatic code generation technology based on "hierarchical class library" to create the data types, scalars, and vectors required by the model. Use the "free combination union" function to automatically generate union variables that can be used by various models in a single processor, and automatically generate cross-processor union variables. The above process is integrated into the model design specification and implemented with the assistance of IDE; S3, using template-based configuration file generation technology to automatically generate projects and corresponding storage configuration files; In step S2, the steps assisted by the IDE are as follows: S21. Set basic model information: name, author, date, version and description; S22, setting the model input, output, configurable parameters required for function implementation and vectors required for operation; Step S22 includes the following sub-steps: Sub-step 1: Create a hierarchical class library to support automatic generation of data type definitions and variable development. For codes and variables that are frequently edited by users, automatic code generation is achieved by generating variable strings and writing them into files as the user edits. Its essence includes two main processes: string generation and file generation. Sub-step 2: Use the hierarchical class library to generate header files describing variable types, variable definition source files, and related files describing the model; Sub-step 3: Rationally plan the allocation of variables. The specific strategy of sub-step 3 is as follows: First, for the single-processor multi-model scenario where multiple models run on the same processor, the model running order is analyzed, and the vectors with the same storage space in the serially executed models are combined to form a cross-model union variable; Secondly, for multi-processor and multi-model scenarios belonging to the same project, the IDE automatically combines the arrays, structures, and unions of each processor into the top-level "big structure", and then automatically combines all top-level "big structures" under the project; Finally, call the model file generation class to create the .h and .cpp files corresponding to each model.

2. The model-driven multi-core DSP automatic storage allocation method according to claim 1 is characterized in that: In step S1, according to the object-oriented design concept and the requirements of MBSE model abstraction, the model design specification is established from the dimensions of input / output ports, function implementation, control and interface. The functions of each part are as follows: Input / output port: responsible for the I / O of the model, sending and receiving data; Functional implementation: responsible for the functional implementation of the model, which is a collection of files. Each file contains several functional functions. When the user completes the configuration, these files and the main entry function of functional scheduling are automatically generated by the tool; Control: responsible for the scheduling of model functions, determining the conditions and timing / moment to schedule the function; Interface: responsible for implementing model storage and recovery, debugging, monitoring, and file operations.

3. The model-driven multi-core DSP automatic storage allocation method according to claim 1, characterized in that: The specific steps of step S3 are as follows: S31, making a storage configuration file template and project file templates corresponding to different platforms, the storage configuration file is referred to as a CMD file; S32. Design storage configuration file generation class, responsible for managing and changing CMD files; S33, design engineering file generation class, responsible for managing and changing various engineering files, the corresponding engineering files are .project / .ccsproject; S34. During daily project development, users can modify CMD files through UI operations. At this time, the storage configuration file generation class collects user modification information and automatically completes the modification of the CMD file.

Images