CN113867943B - Radar software memory allocation method based on embedded system - Google Patents
Radar software memory allocation method based on embedded system Download PDFInfo
- Publication number
- CN113867943B CN113867943B CN202111083331.2A CN202111083331A CN113867943B CN 113867943 B CN113867943 B CN 113867943B CN 202111083331 A CN202111083331 A CN 202111083331A CN 113867943 B CN113867943 B CN 113867943B
- Authority
- CN
- China
- Prior art keywords
- software module
- current
- software
- grouping
- memory
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
- G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
- G06F9/5011—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals
- G06F9/5016—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals the resource being the memory
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Devices For Executing Special Programs (AREA)
Abstract
The invention discloses a radar software memory allocation method based on an embedded system, which comprises the following steps: step 1: setting a queue, wherein all software modules of radar software in the embedded system traversed according to the depth priority order are arranged in the queue; step 2: judging whether the passing rate of the current grouping after the current accessed software module is added into the current grouping is larger than the consumed time required by the operation of the initial unit data volume of the embedded system or not and whether the sum of the used memories of the current grouping and the current accessed software module before the current accessed software module is added into the current grouping is smaller than the memory of a single board card or not, if so, performing step 3, otherwise, performing step 8; and step 3: and judging whether the currently accessed software module is the last software module of the current queue. The invention realizes the automation of the distribution of each software module in the radar embedded system in the memory space of the embedded equipment.
Description
Technical Field
The invention relates to the field of software-based radars, in particular to a radar software memory allocation method based on an embedded system.
Background
The traditional radar software development process is based on an embedded integrated development environment to complete real-time processing software design, coding and compiling, and an executable file after compiling is downloaded to embedded equipment for debugging and verification. The process relates to the resource scheduling of software and hardware, puts high requirements on software designers, besides the need for radar expertise, it also needs to have a certain hardware basis and software programming techniques.
To improve software development efficiency, model-based design methods are beginning to be widely appreciated. It begins in the automobile manufacturing and aerospace industries in the early 90 s of the 20 th century, and these industries need to use a large number of microprocessor units, so engineers find that developing embedded systems by modeling and simulation methods is of great advantage; in the middle of the 90 s, the development of a control algorithm simulation technology prompts an automatic code generation technology; in 1984, with the establishment of MathWorks, products such as Simulink/Stateflow, embedded Matlab and the like under the flag integrate modeling, simulation and analysis tools, so that the products become a leader of software suppliers based on model design. Therefore, the software development process is changed into the process of designing and developing software on a visual interactive development platform, and the system model is visualized through an intuitive software module diagram.
However, the software module granularity provided by Simulink is at the component level, and the difficulty is conceivable if embedded devices with hundreds of thousands and millions of component integrations today are built through the tool. Therefore, although the radar software development is based on a model-based design method, a hardware modeling simulation mode is not adopted, and codes generated and compiled automatically are downloaded to a real embedded device to be operated.
Radar software runs on embedded devices and carries hard real-time operating systems (such as VxWorks), thus placing higher demands on the allocation of memory resources:
(1) The memory space of the embedded device is limited, and software modules as many as possible need to be operated in limited hardware resources;
(2) The hard real-time system does not have the function of automatic resource allocation and needs to appoint communication, address space calculation and the like used by a software module;
(3) The hard real-time system does not have a resource isolation function, so that the occupation condition of other software modules needs to be considered when the memory address space is multiplexed.
Based on the above points, the resource division of the current embedded device still adopts a manual mode, but the manual allocation mode inevitably lowers the development efficiency and the automation level of the whole system.
Disclosure of Invention
In order to solve the above problems, the present invention provides a radar software memory allocation method based on an embedded system, which includes the following steps:
step 1: setting a queue, wherein all software modules of radar software in the embedded system traversed according to the depth priority order in the queue access a first software module in the queue, enter a first grouping operation and set empty groups;
and 2, step: judging whether the passing rate of the current grouping after the current accessed software module is added into the current grouping is larger than the consumed time required by the operation of the initial unit data volume of the embedded system or not and whether the sum of the used memories of the current grouping and the current accessed software module before the current accessed software module is added into the current grouping is smaller than the memory of a single board card or not, if so, performing step 3, otherwise, performing step 8; the memory sizes of the single board cards in the embedded system are the same; the passing rate of the current grouping after the currently accessed software module is added into the current grouping = the unit time advance number/the sum of the processing time of all the software modules of the current grouping after the currently accessed software module is added into the current grouping;
and step 3: judging whether the currently accessed software module is the last software module of the current queue, if so, performing the step 4, and if not, performing the step 6;
and 4, step 4: deleting the currently accessed software module from the current queue and adding the deleted software module into the current packet, ending the packet operation, entering the next packet operation, setting a new empty packet, and performing the step 5;
and 5: judging whether the current queue is empty, if so, finishing all grouping operations, and performing step 9, otherwise, skipping to the first software module of the current queue and performing step 2;
step 6: adding the currently accessed software module into the current group, deleting the currently accessed software module from the current queue, and performing step 7;
and 7: skipping to the next software module according to the traversal sequence, and performing the step 2;
and 8: judging whether the currently accessed software module is the last software module of the current queue, if so, ending the grouping operation, entering the next grouping operation, setting a new empty group, jumping to the first software module of the current queue, and performing the step 2; if not, skipping to the currently accessed software module and the next software module of all the sub-software modules thereof according to the traversal sequence, and performing the step 2;
and step 9: all the software modules in the same group are deployed on the same board card, and different groups are deployed on different board cards.
Further, the sum of the used memories of the current group and the currently accessed software module refers to:
judging whether all the software modules of the current group and the current software modules can carry out memory multiplexing, if the memory multiplexing can be carried out, taking the sum of the occupied memories of all the software modules of the current group and the currently accessed software modules after the multiplexing as the sum of the used memories, and if the memory multiplexing cannot be carried out, directly taking the sum of the occupied memories of all the software modules of the current group and the currently accessed software modules as the sum of the used memories;
the conditions of whether all the software modules of the current group and the current software module can carry out memory multiplexing are as follows:
condition 1: assuming that a currently accessed software module is a software module A, a software module C and a software module B exist in a current group, a data channel is formed between the software module C and the software module A through the software module B, the software module C is a front two-stage software module of the software module A, the software module B is a front one-stage software module of the software module A, and the software module A needs to output data;
condition 2: the running time of the other software modules using the input memory area of the software module B in the current grouping or the running time of the other software modules using the input memory area of the software module B does not conflict with the running time of the output memory area of the software module A using the input memory area of the software module B;
when the condition 1 and the condition 2 are simultaneously satisfied, the output memory area of the software module a can reuse the input memory area of the software module B, that is, all the software modules currently grouped and the software modules currently accessed can perform memory reuse.
Compared with the prior art, the radar software memory allocation method based on the embedded system provided by the invention has the advantages that the communication memory of the software module is multiplexed according to the time independence and the topological relation of the software module, and the utilization rate and the multiplexing rate of the board card memory are improved.
Drawings
FIG. 1 is a flow chart of an embodiment of the present invention.
FIG. 2 is a diagram of software module groupings according to an embodiment of the present invention.
Fig. 3 is a communication memory reuse graph after the second grouping operation according to the embodiment of the present invention.
Fig. 4 is a diagram of the comm memory access after the third packet operation according to the embodiment of the present invention.
Detailed Description
The following describes in detail a specific embodiment of a method and a device for allocating a radar software memory based on an embedded system according to the present invention with reference to the accompanying drawings.
Example one
As shown in fig. 1, the present embodiment provides a radar software memory allocation method based on an embedded system, including the following steps:
step 1: setting a queue, wherein all software modules traversed according to the depth priority order are in the queue, a first software module in the queue is accessed, a first grouping operation is carried out, and empty groups are set;
and 2, step: judging whether the passing rate of the current grouping after the current accessed software module is added into the current grouping is larger than the consumed time required by the operation of the initial unit data volume of the embedded system or not and whether the sum of the used memories of the current grouping and the current accessed software module before the current accessed software module is added into the current grouping is smaller than the memory of a single board card or not, if so, performing step 3, otherwise, performing step 8; the memory sizes of the single board cards in the embedded system are the same; the passing rate of the current grouping after the software module which is accessed currently is added into the current grouping = the unit time advance number/the sum of the processing time of all the software modules which are grouped currently after the software module which is accessed currently is added into the current grouping;
and step 3: judging whether the currently accessed software module is the last software module of the current queue, if so, performing the step 4, otherwise, performing the step 6;
and 4, step 4: deleting the currently accessed software module from the current queue and adding the deleted software module into the current packet, ending the packet operation, entering the next packet operation, setting a new empty packet, and performing the step 5;
and 5: judging whether the current queue is empty, if so, finishing all grouping operations, performing step 9, otherwise, skipping to the first software module of the current queue, and then performing step 2;
step 6: adding the currently accessed software module into the current group, deleting the currently accessed software module from the current queue, and performing step 7;
and 7: skipping to the next software module according to the traversal sequence, and performing the step 2;
and step 8: judging whether the currently accessed software module is the last software module of the current queue, if so, ending the grouping operation, entering the next grouping operation, setting a new empty group, jumping to the first software module of the current queue, and performing the step 2; if not, skipping to the currently accessed software module and the next software module of all the sub software modules thereof according to the traversal sequence, and performing the step 2;
and step 9: all software modules in the same group are deployed on the same board card, and different groups are deployed on different board cards.
The sum of the used memory of the current group and the currently accessed software module is:
judging whether all the software modules of the current group and the current software modules can carry out memory multiplexing, if the memory multiplexing can be carried out, taking the sum of the occupied memories of all the software modules of the current group and the currently accessed software modules after the multiplexing as the sum of the used memories, and if the memory multiplexing cannot be carried out, directly taking the sum of the occupied memories of all the software modules of the current group and the currently accessed software modules as the sum of the used memories;
the conditions of whether the currently grouped software modules and the currently accessed software modules can perform memory multiplexing are as follows:
condition 1: supposing that the currently accessed software module is a software module A, a software module C and a software module B exist in the current group, a data channel is formed between the software module C and the software module A through the software module B, the software module C is a first two-stage software module of the software module A, the software module B is a first-stage software module of the software module A, and the software module A needs to output data;
condition 2: the running time of the other software modules using the input memory area of the software module B in the current grouping or the running time of the other software modules using the input memory area of the software module B does not conflict with the running time of the output memory area of the software module A using the input memory area of the software module B;
when the condition 1 and the condition 2 are satisfied at the same time, the output memory area of the software module a may multiplex the input memory area of the software module B, that is, all the software modules currently grouped and the software module currently accessed may perform memory multiplexing.
Taking the directed acyclic graph with 11 software modules in fig. 2 as an example, the specific implementation process of this embodiment is shown in fig. 2-4.
All software modules traversing according to the depth priority order are in the queue, and the sequence of traversing according to the depth priority order of each software module in the queue in the embodiment is specifically (software module 1, software module 2, software module 3, software module 7, software module 8, software module 9, software module 6, software module 5, software module 10, software module 4, and software module 11). The first grouping operation divides the software modules 1,2,3,7,8,9,6,5 and 4 into a small group, and specifically, when accessing the software module 1,2,3,7,8,9,6,5, the software modules can meet the conditions of the throughput rate or the size of the used memory, so that the first grouping is added. When the currently accessed software module is the software module 10, the software module 10 does not meet the condition of using the memory size in the step 2 if the currently accessed software module is added into the current packet, the step 8 is started, the software module 4 jumps to the software module 4, the software module 4 meets the condition of the passing rate and the memory size in the step 2 and is added into the current packet, the step 7 is started, the currently accessed software module jumps to the software module 11, and the step 8 is started if the software module 11 is added into the current packet, the current packet operation is ended, the next packet operation is started, and the current queue is (the software module 10 and the software module 11)); in the second grouping operation, although the requirement of using the memory size can be met if the software modules 10 and 11 are put into the same group, the two modules cannot meet the passing rate condition in the same group, so that the software module 10 is independently used as one group; the third grouping operation takes the software module 11 as a group, as shown in fig. 4, and all grouping operations end.
Fig. 3 and 4 show memory reuse diagrams during a grouping operation, and fig. 3 is an exemplary diagram of memory reuse after a second grouping operation. In the figure, each software module needs to occupy a certain memory partition if there is an input and an output, especially a software module with multiple outputs, if it needs to output different data to each subsequent module, it also needs multiple different output partitions (for example, there are 3 different output partitions for software module 3 in the figure), if it outputs the same data to each subsequent module, the output partitions can be the same (for example, the data output from software module 4 to software module 5 and the data output from software module 11 are the same, one output partition can be used). However, certain input and output partitions may reuse memory if the rules for multiplexing are satisfied. The rules of this multiplexing are: the method comprises the following steps that a condition 1 is that a currently accessed software module is assumed to be a software module A, a software module C and a software module B exist in a current group, a data channel is formed between the software module C and the software module A through the software module B, the software module C is a first two-stage software module of the software module A, the software module B is a previous stage software module of the software module A, and the software module A needs to output data; condition 2 is that there is no conflict between the running time of the other software modules using the input memory area of the software module B or the running time of the other software modules using the input memory area of the software module B and the running time of the output memory area of the software module a using the input memory area of the software module B in the current grouping; when the condition 1 and the condition 2 are satisfied simultaneously, the output memory area of the software module a may reuse the input memory area of the software module B, that is, all the software modules currently grouped and the software module currently accessed may perform memory reuse.
In fig. 3, the software modules that have the first two levels of software modules and need to output data include software modules 3,7,8, 4, and 5, where the software modules 3,7, and 8 all satisfy the above rules, so that memory multiplexing is possible. The software module 4 does not satisfy the above rules and cannot be reused. The related data flow of the software module 5 includes two paths, one is that the software module 1 outputs data to the software module 2 and then the software module 2 directly outputs the data to the software module 5, and the other is that the software module 2 outputs data to the software module 3 and then the software module 3 outputs the data to the software module 5. If the software module 5 uses the input memory area (partition 1) of the previous software module 2, the usage time thereof will conflict with the time when the software module 3 reuses the input memory area (partition 1) of the software module 2, so that the software module 5 cannot reuse the partition 1. Software module 5 can reuse partition 2 because the time at which software module 5 uses the input memory region (partition 2) of its previous software module 3 does not conflict with the time at which software module 7 reuses the input memory region (partition 2) of its previous software module 3.
Fig. 4 is a diagram illustrating an example of memory multiplexing after the third grouping operation.
And according to the final grouping result, deploying all software modules in the same group to the same board card, and deploying different groups to different board cards.
The invention provides a radar software memory allocation method based on an embedded system, which realizes the automation of the allocation of each software module in radar software in the memory space of embedded equipment and ensures the high utilization rate and the high reuse rate of the board card memory.
The above description is only for the purpose of illustrating the preferred embodiments of the present invention and should not be taken as limiting the scope of the present invention, which is intended to cover any modifications, equivalents, improvements, etc. within the spirit and scope of the present invention.
Claims (2)
1. A radar software memory allocation method based on an embedded system is characterized by comprising the following steps:
step 1: setting a queue, wherein all software modules of radar software in the embedded system traversed according to the depth priority order in the queue access a first software module in the queue, enter a first grouping operation and set empty groups;
step 2: judging whether the passing rate of the current grouping after the current accessed software module is added into the current grouping is larger than the consumed time required by the initial unit data volume operation of the embedded system or not and whether the sum of the used memories of the current grouping and the current accessed software module before the current accessed software module is added into the current grouping is smaller than the memory of a single board card or not, if yes, performing step 3, and otherwise, performing step 8; the memory sizes of the single board cards in the embedded system are the same; the passing rate of the current grouping after the currently accessed software module is added into the current grouping = the unit time advance number/the sum of the processing time of all the software modules of the current grouping after the currently accessed software module is added into the current grouping;
and step 3: judging whether the currently accessed software module is the last software module of the current queue, if so, performing the step 4, otherwise, performing the step 6;
and 4, step 4: deleting the currently accessed software module from the current queue and adding the deleted software module into the current packet, ending the packet operation, entering the next packet operation, setting a new empty packet, and performing the step 5;
and 5: judging whether the current queue is empty, if so, finishing all grouping operations, and performing step 9, otherwise, skipping to the first software module of the current queue and performing step 2;
step 6: adding the currently accessed software module into the current group, deleting the currently accessed software module from the current queue, and performing step 7;
and 7: skipping to the next software module according to the traversal sequence, and performing the step 2;
and 8: judging whether the currently accessed software module is the last software module of the current queue, if so, ending the grouping operation, entering the next grouping operation, setting a new empty group, jumping to the first software module of the current queue, and performing the step 2; if not, skipping to the currently accessed software module and the next software module of all the sub-software modules thereof according to the traversal sequence, and performing the step 2;
and step 9: all software modules in the same group are deployed on the same board card, and different groups are deployed on different board cards.
2. The embedded system-based radar software memory allocation method according to claim 1, wherein the sum of the used memories of the currently grouped software modules and the currently accessed software modules is:
judging whether all the software modules of the current group and the current software modules can be subjected to memory multiplexing, if the memory multiplexing can be carried out, taking the sum of the occupied memories of all the software modules of the current group and the currently accessed software modules after the multiplexing as the sum of the used memories, and if the memory multiplexing cannot be carried out, directly taking the sum of the occupied memories of all the software modules of the current group and the currently accessed software modules as the sum of the used memories;
the conditions of whether all the software modules of the current group and the current software module can carry out memory multiplexing are as follows:
condition 1: assuming that a currently accessed software module is a software module A, a software module C and a software module B exist in a current group, a data channel is formed between the software module C and the software module A through the software module B, the software module C is a front two-stage software module of the software module A, the software module B is a front one-stage software module of the software module A, and the software module A needs to output data;
condition 2: the running time of the other software modules using the input memory area of the software module B in the current grouping or the running time of the other software modules using the input memory area of the software module B does not conflict with the running time of the output memory area of the software module A using the input memory area of the software module B;
when the condition 1 and the condition 2 are simultaneously satisfied, the output memory area of the software module a can reuse the input memory area of the software module B, that is, all the software modules currently grouped and the software modules currently accessed can perform memory reuse.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111083331.2A CN113867943B (en) | 2021-09-15 | 2021-09-15 | Radar software memory allocation method based on embedded system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111083331.2A CN113867943B (en) | 2021-09-15 | 2021-09-15 | Radar software memory allocation method based on embedded system |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN113867943A CN113867943A (en) | 2021-12-31 |
| CN113867943B true CN113867943B (en) | 2022-12-30 |
Family
ID=78996104
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202111083331.2A Active CN113867943B (en) | 2021-09-15 | 2021-09-15 | Radar software memory allocation method based on embedded system |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN113867943B (en) |
Family Cites Families (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103888827A (en) * | 2012-12-20 | 2014-06-25 | 中山大学深圳研究院 | Digital television application management layer system and method based on embedded kernel |
| CN111428240B (en) * | 2020-03-20 | 2021-10-15 | 安芯网盾(北京)科技有限公司 | Method and device for detecting illegal access of memory of software |
| CN111966481A (en) * | 2020-09-04 | 2020-11-20 | 苏州浪潮智能科技有限公司 | Parallel computing management method and system suitable for multi-tenant scene |
-
2021
- 2021-09-15 CN CN202111083331.2A patent/CN113867943B/en active Active
Also Published As
| Publication number | Publication date |
|---|---|
| CN113867943A (en) | 2021-12-31 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN103080900B (en) | The method of parallelization automatic control program and compiler | |
| US20110107162A1 (en) | Parallelization method, system and program | |
| CN114139475A (en) | Chip verification method, system, device and storage medium | |
| US20230153158A1 (en) | Method, apparatus, system, and storage medium for performing eda task | |
| CN113032963A (en) | Simulink model simulation acceleration method and device | |
| US20040078180A1 (en) | Method for automatically decomposing dynamic system models into submodels | |
| US20230118325A1 (en) | Method and apparatus having a memory manager for neural networks | |
| CN117034821B (en) | Regression verification method and medium for chip design front-end simulation verification | |
| US20220309218A1 (en) | Method for dividing simulation models up between a processor and an fpga | |
| CN115469894A (en) | Application program installation control method, device, equipment and storage medium | |
| CN115617009A (en) | Virtual development environment apparatus, method and recording medium | |
| CN113867943B (en) | Radar software memory allocation method based on embedded system | |
| CN102004660A (en) | Realizing method and device of business flows | |
| WO2005114499A1 (en) | Method and apparatus for allocating data paths | |
| Beck et al. | Simulated annealing applied to multicomputer task allocation and processor specification | |
| Shang et al. | Asynchronous system synthesis based on direct mapping using VHDL and Petri nets | |
| CN113255265B (en) | Segmentation and verification method, device, electronic equipment and storage medium | |
| Peñil et al. | Automatic synthesis from UML/MARTE models using channel semantics | |
| Bringmann et al. | Cross-level hierarchical high-level synthesis | |
| CN115186793A (en) | Control method and device of multi-level calculation model and readable storage medium | |
| US20040143813A1 (en) | System development supporting apparatus, system development supporting method, and computer-readable recorded medium | |
| Conrad et al. | Graph transformations for model-based testing | |
| CN117422047B (en) | Circuit simulation method and automatic simulation method for CPU and GPU heterogeneous platform | |
| CN111007836B (en) | New energy BMS hardware-in-the-loop test case library establishing method | |
| CN114330217B (en) | Simultaneous signal grouping and pin assignment for pin position driving of a design under test |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |