CN114356315A - Multi-core DSP automatic storage allocation technology based on model drive - Google Patents

Abstract

The invention relates to the field of embedded information processing, in particular to a multi-core DSP automatic storage allocation technology based on model driving. Which comprises the following steps: s1, establishing a model/component design specification meeting the DSP operation; s2, adopting the automatic code generation technology based on the hierarchical class library to create the data type, scalar and vector needed by the model, adopting the free combination complex function to automatically generate the complex variable which can be used by each model in the single processor, simultaneously automatically generating the cross-processor complex variable, merging the process into the model design specification and realizing the process with the assistance of IDE; and S3, automatically generating a project and a corresponding storage configuration file by adopting a template-based configuration file generation technology. The invention solves the problems of storage definition and allocation of the conventional multi-DSP software system, greatly improves the coding efficiency during storage allocation, obviously reduces the error probability, and also ensures the saving and the use of storage resources from the mechanism.

Description

Multi-core DSP automatic storage allocation technology based on model drive

Technical Field

The invention relates to the field of embedded information processing, in particular to a multi-core DSP automatic storage allocation technology based on model driving.

Background

At present, multi-core DSPs such as imported TI (C5X, C6X series) and domestic FT (M6678) are widely applied to the fields of military and civil embedded processing. Different from the X86 platform, the above-mentioned DSP (import TI and domestic FT multi-core DSP) adopts a multi-level Data cache form, which is close to the kernel, an L1 program cache and an L1 Data cache, and outward sequentially an L2 cache, a multi-core Shared Memory (MSM) and a DDR3 Memory (Double-Data-Rate Synchronous Random Access Memory). The closer the memory is to the kernel, the smaller the storage capacity of the memory is, but the faster the access speed of the memory is; the further away the memory is from the kernel, the greater the storage capacity of the memory, but the slower the access speed of the memory. Under the condition that the core main frequency is 1GHz, the communication bandwidth of an L1 data cache and an L1 program cache is 32GB/s, the communication bandwidth of an L2 cache is 16GB/s, and the communication bandwidth of a multi-core shared memory is 64 GB/s. Under the condition that the primary frequency of the DDR3 memory is 1333MHz, the bandwidth is 10.664GB/s, as shown in a schematic diagram of a C66XX/FT6678 storage architecture in FIG. 1, an L1 data cache and an L1 program cache are 32KB, an L2 cache is 512KB, a multi-core shared memory is 4MB, and a DDR3 is 2 GB. From the architecture of the multicore C6678DSP, it can be seen that the higher the computational performance when placing data in memory closer to the core, but the smaller the amount of tasks that can be completed, limited by memory capacity.

From the analysis, the strategy of variable development directly determines the final running efficiency of the code and the real-time performance of the system based on the software development of the multi-core DSP, and sometimes the strategy can reach 5 to 10 times. Conventional variable tunneling strategies are shown in table 1:

table 1 conventional variable tunneling strategy

Based on the variable tunneling strategy of table 1, an embedded system, consisting of multiple DSPs, whose memory definition and allocation generally follows the following steps:

step 1, writing a storage configuration file (CMD file), and setting a stack and a DDR space. The operations are in a relatively close relationship with the bottom layer of the hardware, the requirement on developers is high, once the CMD file is set incorrectly, software operation is crashed or the result is rare, and troubleshooting is difficult and time-consuming.

And 2, determining the software functions realized on each processor, and defining various scalars, vectors and matrixes in source files (generally C/C + +) deployed to the processor. Often different designers have their own definition styles and the code is not easily maintained.

And 3, reasonably distributing the variables defined in the step 2 to different storage areas (L2/MSM/DDR) according to the performance requirement.

And 4, along with the increase of functions, the variables are more and more, and the distribution range is wider. Meanwhile, the L2/MSM storage area may overflow, and it takes a lot of time to pool various vectors/matrices in many files, otherwise, a new processor is needed, resulting in waste of hardware resources.

And 5, in order to reduce the software debugging and maintenance difficulty of a complex system (multiple DSPs), a plurality of processor codes are required to be put into the same project, so that variables developed in the same storage area on different processors are mutually overlapped, and the storage space is wasted. To avoid this problem, it is necessary to define "complex variables," which further increases the design difficulty of the variables/stores, as shown in fig. 2.

At present, the following problems exist in the storage allocation link of the software development in the embedded field based on the multi-core DSP:

first, storage allocation often lacks a uniform framework and specification, habits of developers dominate, variables are randomly allocated to different files, errors are easy to occur, and maintenance and upgrading are difficult.

Second, type declarations and variable definitions are mostly done in a completely manual manner. Not only is the efficiency low, but also errors are easy to occur.

Thirdly, vectors required among different functions are often exclusively used for DSP storage, which causes waste of storage resources. When no storage resource is available, the problem can be solved only by expanding hardware, which results in an increase in cost of expanding the hardware scale of the system.

Fourthly, most of the projects adopt a manual mode to create engineering and storage configuration files, higher requirements are put forward on the capability of developers, repeated labor is carried out among projects, the efficiency is lower, and meanwhile errors are easy to occur.

Disclosure of Invention

The invention aims to provide a multi-core DSP automatic storage allocation technology based on model driving aiming at the problems in the background technology, effectively solves the problems, greatly improves the coding efficiency during storage allocation, obviously reduces the error probability, also ensures the saving and the use of storage resources from the mechanism and supports the signal level modeling and simulation in the model-based system engineering (MBSE).

The technical scheme of the invention is based on a model-driven multi-core DSP automatic storage allocation technology, and comprises the following steps:

s1, establishing a model/component design specification meeting the DSP operation;

s2, adopting the automatic code generation technology based on the hierarchical class library to create the data type, scalar and vector needed by the model, adopting the free combination complex function to automatically generate the complex variable which can be used by each model in the single processor, simultaneously automatically generating the cross-processor complex variable, merging the process into the model design specification and realizing the process with the assistance of IDE;

and S3, automatically generating a project and a corresponding storage configuration file by adopting a template-based configuration file generation technology.

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

input/output ports: the system is responsible for I/O of the model and receiving and transmitting data;

the function is realized: the function of the responsible model is realized by a set of files, each file is provided with a plurality of function functions, and after the user finishes configuration, the files and the main entry functions of function scheduling are automatically generated by a tool;

controlling: the scheduling function is responsible for scheduling the model function, and determining which conditions and which time/moment scheduling function;

interface: and the system is responsible for realizing storage and recovery, debugging, monitoring and file operation of the model.

Preferably, in step S2, the IDE-assisted implementation steps are as follows:

s21, setting basic model information: name, author, date, version, and description;

s22, setting model input, output, configurable parameters needed in function realization and vectors needed in operation.

Preferably, step S22 includes the following substeps:

the method comprises the following steps that 1, a hierarchical class library is created, automatic generation of data type definition and variable opening are supported, and for codes and variables frequently edited by a user, automatic code generation is realized in a mode that variable character strings are generated along with editing of the user and are written into files, and the method essentially comprises two main processes of character string generation and file generation;

substep 2, using a hierarchical class library to respectively generate a header file for describing a variable type, a variable definition source file and a related file for describing a model;

and substep 3, reasonably planning the distribution mode of the variables.

Preferably, the specific strategy of substep 3 is as follows:

firstly, analyzing the operation sequence of the models aiming at a single-processor multi-model scene with a plurality of models operating in the same processor, and combining vectors in the same storage space in the serially executed models to form a cross-model complex variable;

secondly, aiming at a multi-processor multi-model scene belonging to the same project, the IDE automatically combines an array, a structure body and a combined body of each processor into a large structure body at the top layer, and then automatically combines all the large structure bodies at the top layer under the project;

finally, the model file generation class is called to create h and cpp files corresponding to each model.

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

s31, making a storage configuration file template and project file templates corresponding to different platforms, wherein the storage configuration file is a CMD file for short;

s32, designing a storage configuration file generation class, and managing and changing the CMD file;

s33, designing a project file generation class, and managing and changing various project files, wherein the corresponding project file is project/ccproject;

and S34, during daily development of the project, the user can modify the CMD file through UI operation, and at the moment, the storage configuration file generation class collects the modification information of the user and automatically completes the modification of the CMD file.

Compared with the prior art, the invention has the following beneficial technical effects:

firstly, a model-driven multi-core DSP storage allocation framework and a mode are based on: the model driven development mode widely applied to 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, the global variable serves the links of the input, the output, the function realization and the like of the model. Therefore, the logic and the framework of the global variable storage allocation are solidified, the allocation mode is normalized, the definition is unified and concentrated, and the global variable storage allocation method is not scattered in different files randomly according to the habit of a user.

Secondly, the invention provides a multi-core DSP storage allocation code automatic generation technology based on a hierarchical class library, and declarations and definitions (including corresponding header files and automatic creation of source files) of various variables (including complex structure body types) can be automatically completed by constructing the hierarchical class library and setting variable types and names in an IDE.

Thirdly, the invention provides a multi-core DSP storage saving use technology based on a free combination complex. Different vectors in multiple models in a single processor can be freely combined according to an execution mode through UI assistance, and corresponding codes are automatically generated. Meanwhile, for a multi-processor and multi-engineering scene, the whole storage overhead of a single processor can be automatically defined into a top-layer large structure body and combined with other processors.

Fourthly, the invention provides a technology for automatically generating engineering and storage configuration files based on a template, and system-level files such as the storage configuration files, the engineering files and the like are automatically generated, managed and maintained based on the template.

Drawings

FIG. 1 is a schematic diagram of a C66XX/FT6678 storage architecture;

FIG. 2 is a block diagram of a conventional multi-DSP software system storage and engineering relationship;

FIG. 3 is a model/component abstraction diagram;

FIG. 4 is a hierarchical class library serving automatic code generation;

FIG. 5 is a flow diagram of automatic generation of variable code using a hierarchical class library;

FIG. 6 is a diagram of a single processor multi-model store lib complex;

FIG. 7 is a block diagram of a technique for automatic template-based profile generation;

FIG. 8 is an interface for model configuration via an IDE;

FIG. 9 is an interface for multi-model complex liberty via IDE.

Detailed Description

The invention provides a model-driven multi-core DSP automatic storage allocation technology, which comprises the following steps:

firstly, establishing a model/component design specification meeting the operation of a DSP, bringing storage requirement management into the specification (especially vector/matrix variable), putting an end to personalized development and random development, and establishing the model design specification from input/output ports, function realization, control and interface dimensions according to the design idea of object-oriented and the requirement of MBSE model abstraction, as shown in FIG. 3, the functions of each part are as follows:

input/output ports: the system is responsible for I/O of the model and receiving and transmitting data;

the function is realized: the function of the responsible model is realized by a set of files, each file contains a plurality of function functions, and after the user finishes configuration, the files and the main entry functions of function scheduling are automatically generated by a tool;

controlling: the system is responsible for scheduling the model function and determining which conditions and which time/moment to schedule the function;

interface: and the system is responsible for realizing storage and recovery, debugging, monitoring, file operation and the like of the model.

Secondly, data types, scalars and vectors required by the model are created by adopting an automatic code generation technology based on a hierarchical class library, complex variables which can be commonly used by all models in a single processor are automatically generated by adopting a free combination complex function, simultaneously, cross-processor complex variables are automatically generated, the process is fused into a model design specification and is assisted and realized by an IDE (Integrated Development Environment), and the steps of the IDE assisted realization are as follows S21 and S22:

s21, as shown in fig. 7, model basic information is set: name, author, date, version, and description.

S22, as shown in fig. 7, setting configurable parameters and vectors required for model input, output and function implementation, this step includes the following substeps:

the method comprises the following steps of substep 1, creating a hierarchical class library, supporting automatic generation of data type definition and variable opening, wherein the class library is composed as shown in FIG. 4, and for codes and variables frequently edited by a user, automatic code generation is realized by adopting a mode of generating variable character strings along with the editing of the user and writing the variable character strings into a file, and the method essentially comprises two main processes of character string generation and file generation. A hierarchical class library is designed for this purpose, and the main functions of each class are shown in Table 2.

TABLE 2 hierarchical class library introduction serving automatic code generation

Substep 2, as shown in fig. 5, using the hierarchical class library to generate a header file describing the variable type, a variable definition source file, and a related file (h/. cpp) describing the model, respectively;

substep 3, DSP memory space (especially on-chip memory space) is very limited, while the complexity of signal processing algorithms leads to increased memory requirements, and the stringent real-time requirements lead to efficient use of on-chip memory requirements. Aiming at the contradiction, the distribution mode of the variables needs to be reasonably planned, otherwise, the demand of the system hardware is expanded in multiples, and the specific strategy is as follows:

firstly, analyzing the running sequence of the models aiming at a single-processor multi-model scene that a plurality of models run on the same processor, and combining vectors in the same storage space (such as all vectors are L2) in the serially (non-parallel) executed models to form a cross-model complex variable;

secondly, aiming at a multi-processor multi-model scene belonging to the same project, the IDE automatically combines an array, a structure body and a combined body of each processor into a topmost 'big structure body', as shown in FIG. 9, and then automatically combines all the top 'big structure bodies' under the project, and a user does not need to write codes by hand, as shown in FIG. 6;

finally, the model file generation class is called to create h and cpp files corresponding to each model.

Thirdly, as shown in fig. 7, the project and the corresponding storage profile are automatically generated by adopting the template-based profile generation technology, and the specific steps are as follows S31, S32, S33 and S34:

s31, making a storage configuration file template and project file templates corresponding to different platforms, wherein the storage configuration file is a CMD file for short;

s32, designing a storage configuration file generation class, and managing and changing the CMD file;

s33, designing a project file generation class, which is responsible for managing and changing various project files, such as TI66xx series DSP, and the corresponding project file is project/. ccsproject;

and S34, during daily development of the project, the user can modify the CMD file through UI operation, and at the moment, the storage configuration file generation class collects the modification information of the user and automatically completes the modification of the CMD file. This way, it can be ensured that the CMD file is not changed or modified at will.

The invention has the following advantages:

firstly, a model-driven multi-core DSP storage allocation framework and a mode are based on: the model driven development mode widely applied to 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, the global variable serves the links of the input, the output, the function realization and the like of the model. Therefore, the logic and the framework of the global variable storage allocation are solidified, the allocation mode is normalized, the definition is unified and concentrated, and the global variable storage allocation method is not scattered in different files randomly according to the habit of a user.

Secondly, a multi-core DSP storage allocation code automatic generation strategy/flow based on the hierarchical class library is as follows: after the frame and the mode followed by storage allocation are determined, the coding efficiency is improved and the error probability is reduced in order to reduce the proportion of manually written codes. The invention provides a multi-core DSP (digital signal processor) storage allocation code automatic generation technology based on a hierarchical class library, and declarations and definitions of various variables (including complex structure body types) can be automatically completed (including automatic creation of corresponding header files and source files) by constructing the hierarchical class library and setting variable types and names in an IDE (integrated development environment).

Thirdly, the multi-core DSP storage saving use strategy/flow based on the free combination complex is as follows: the invention provides a multi-core DSP storage saving use technology based on a free combination complex, which aims to further save storage resource overhead and improve the use efficiency of the multi-core DSP storage allocation while completing the standard and efficient allocation of the multi-core DSP storage allocation. Different vectors in multiple models in a single processor can be freely combined according to an execution mode through UI assistance, and corresponding codes are automatically generated. Meanwhile, for a multi-processor and multi-engineering scene, the whole storage overhead of a single processor can be automatically defined into a top-layer large structure body and combined with other processors.

Fourthly, automatically generating a strategy/flow based on the multi-core DSP engineering and storage configuration file of the template: after the DSP function design is completed, in order to further reduce the development difficulty, the invention provides a technology for automatically generating engineering and storage configuration files based on a template, and system level files such as the storage configuration files, engineering files and the like are automatically generated, managed and maintained based on the template.

In a model-driven multi-core DSP memory allocation framework and approach, the following alternatives or practices may exist, but are essentially the same:

1) the "model" is replaced by the "component" and the like.

2) In the process of model abstraction, "input parameter", "output parameter", "intermediate array" (see fig. 8) are places where the storage is largely used in the program, and the description names may also be changed, but the nature is to define the data type (such as structure body), define various variables (such as structure body variable, large array or vector, etc.).

In a "hierarchical class library" based multi-core DSP storage allocation code auto-generation strategy/flow, the following alternatives or practices may exist, but are essentially the same:

1) the "hierarchical class library" is replaced with another name, or the names of the various classes in the class library are changed, but the functions are similar.

2) This is not done using a form of object-oriented programming (i.e., by creating class libraries), but the flow is similar to that of FIG. 5.

In a "free-form complex" based multi-core DSP memory sparing usage policy/procedure, the following alternatives or practices may exist, but are essentially the same:

1) the storage saving usage is not based on a model but is still achieved by defining a complex, the flow is similar to fig. 6.

2) The single processor is eventually used to generate a "large structure" (for automatic association with other processors) replacement name, but is still structural in nature.

3) Automatic federation does not occur via UI means (see FIG. 9), but the essence is still to design a federation for arrays in non-parallel code.

4) The UI interface differs from fig. 9, but is inherently designed for federation selection for arrays/vectors that can be federated.

5) The "big structure" federation process between processors is renamed, but is still complex-by-definition.

In a "template" based multi-core DSP engineering and storage profile auto-generation strategy/process, the following alternatives or practices may exist, but are essentially the same:

1) the "storage configuration file class" and "project file class" are different in name but similar in function.

2) This is not done using object-oriented programming (i.e., by creating class libraries), but the process flow is similar to that in the right-half of fig. 7.

The embodiments of the present invention have been described in detail with reference to the drawings, but the present invention is not limited thereto, and various changes can be made within the knowledge of those skilled in the art without departing from the gist of the present invention.

Claims (6)

1. The model-driven multi-core DSP automatic storage allocation technology is characterized by comprising the following steps of:

s1, establishing a model/component design specification meeting the DSP operation;

s2, adopting the automatic code generation technology based on the hierarchical class library to create the data type, scalar and vector needed by the model, adopting the free combination complex function to automatically generate the complex variable which can be used by each model in the single processor, simultaneously automatically generating the cross-processor complex variable, merging the process into the model design specification and realizing the process with the assistance of IDE;

and S3, automatically generating a project and a corresponding storage configuration file by adopting a template-based configuration file generation technology.

2. The model-driven-based multi-core DSP automatic storage allocation technology according to claim 1, wherein in step S1, a model design specification is established from input/output ports, function implementation, control and interface dimensions according to the object-oriented design concept and the requirement of MBSE model abstraction, and each part has the following functions:

input/output ports: the system is responsible for I/O of the model and receiving and transmitting data;

the function is realized: the function of the responsible model is realized by a set of files, each file is provided with a plurality of function functions, and after the user finishes configuration, the files and the main entry functions of function scheduling are automatically generated by a tool;

controlling: the scheduling function is responsible for scheduling the model function, and determining which conditions and which time/moment scheduling function;

interface: and the system is responsible for realizing storage and recovery, debugging, monitoring, file operation and the like of the model.

3. The model-driven multi-core DSP automatic storage allocation technology according to claim 1, wherein in step S2, the IDE assisted implementation steps are as follows:

s21, setting basic model information: name, author, date, version, and description;

s22, setting model input, output, configurable parameters needed in function realization and vectors needed in operation.

4. The model-driven multi-core DSP automatic memory allocation technique according to claim 3, wherein the step S22 comprises the following sub-steps:

the method comprises the following steps that 1, a hierarchical class library is created, automatic generation of data type definition and variable opening are supported, and for codes and variables frequently edited by a user, automatic code generation is realized in a mode that variable character strings are generated along with editing of the user and are written into files, and the method essentially comprises two main processes of character string generation and file generation;

substep 2, using a hierarchical class library to respectively generate a header file for describing a variable type, a variable definition source file and a related file for describing a model;

and substep 3, reasonably planning the distribution mode of the variables.

5. The model-driven-based multi-core DSP automatic storage allocation technology according to claim 4, wherein the specific strategy of substep 3 is as follows:

firstly, analyzing the operation sequence of the models aiming at a single-processor multi-model scene with a plurality of models operating in the same processor, and combining vectors in the same storage space in the serially executed models to form a cross-model complex variable;

secondly, aiming at a multi-processor multi-model scene belonging to the same project, the IDE automatically combines an array, a structure body and a combined body of each processor into a large structure body at the top layer, and then automatically combines all the large structure bodies at the top layer under the project;

finally, the model file generation class is called to create h and cpp files corresponding to each model.

6. The model-driven-based multi-core DSP automatic storage allocation technology according to claim 1, wherein the specific steps of step S3 are as follows:

s31, making a storage configuration file template and project file templates corresponding to different platforms, wherein the storage configuration file is a CMD file for short;

s32, designing a storage configuration file generation class, and managing and changing the CMD file;

s33, designing a project file generation class, and managing and changing various project files, wherein the corresponding project file is project/ccproject;

and S34, during daily development of the project, the user can modify the CMD file through UI operation, and at the moment, the storage configuration file generation class collects the modification information of the user and automatically completes the modification of the CMD file.

Images