Dynamic local reconfigurable method based on DSP chip

Abstract

The invention discloses a dynamic local reconfigurable method based on a DSP chip, and the method comprises the steps: receiving an external command and data through a peripheral interface, and updating the related data of a to-be-reconstructed function in an application program in a DSP operation process, so as to complete a local reconstruction function, do not need to be powered off for restarting, and do not affect other modules in the program. According to the method, functions called in an application program serve as elements of local reconstruction, a TI TMS320C6678 multi-core DSP chip serves as a hardware carrier, the effectiveness of the method is verified, and the method is also suitable for domestic Feiteng FT-M6678.

Description

Technical Field

[0001] The invention belongs to the technical field of DSP application, and in particular relates to a dynamic local reconfigurable method based on a DSP chip. Background Art

[0002] Dynamic reconfiguration is a branch of reconfigurable computing, which realizes the time-division multiplexing of hardware resources, can effectively improve the flexibility and reliability of embedded systems, and enable the system to achieve the most efficient multi-tasking capability at the lowest hardware cost.

[0003] There is currently little research on the reconfigurable function of DSP. For example, the patent "Multi-channel reconfigurable signal processing device" (authorization announcement number: CN 112199320 B) and the patent "A reconfigurable signal processing board based on VPX architecture and its reconstruction method" (authorization announcement number: CN 115905813 B) realize the reconstruction of DSP applications by receiving external burning file data and overwriting the original program and then restarting. The patent "A dynamic global reconfigurable method based on DSP chip" (patent number: ZL 2023 1 0870603.6) pre-burns multiple versions of applications with different functions to different locations of FLASH, then triggers and modifies the location of FLASH pointed to by external instructions during DSP BOOT, and finally controls the DSP soft reset to realize the reconstruction of DSP applications.

[0004] When debugging an application, it is often the individual algorithm processing modules that need to be adjusted and updated, and the overall architecture program is fixed. The methods described in the above patents all belong to the category of global reconfiguration, which is not applicable in this application scenario. The method of replacing all applications in the DSP is also relatively extensive. Therefore, it is necessary to study a local reconfiguration method that does not affect other modules in the application and reconstructs the target module in a targeted manner. Summary of the invention

[0005] In order to overcome the shortcomings of the prior art, the present invention provides a dynamic local reconfiguration method based on a DSP chip. During the operation of the DSP, external commands and data are received through a peripheral interface, and the relevant data of the function to be reconstructed in the application is updated to complete the local reconstruction function without power off and restart, and does not affect the other modules in the program. The method uses the function called in the application as the element of local reconstruction and the TI TMS320C6678 multi-core DSP chip as the hardware carrier, which verifies the effectiveness of the method, and the domestic Feiteng FT-M6678 is also applicable.

[0006] The technical solution adopted by the present invention to solve the technical problem is as follows:

[0007] Step 1: Divide the FLASH used in DSP BOOT into three partitions, which are independent of each other and have no overlap. The first partition stores the data of the application program burning file generated by the conversion tool chain, called app_data; the second partition stores the relevant data of the function to be partially reconstructed in the application, called func_data; the third partition stores the configuration list data, called cfg_list;

[0008] Step 2: further subdivide the second partition into several non-overlapping sub-partitions as needed, called sub_area, and one sub-partition stores one func_data of the function to be partially reconstructed;

[0009] Step 3: When writing a DSP application, specify the DSP memory occupied by the func_data of several functions to be partially reconstructed at runtime as non-overlapping memory areas within the DSP in a way limited by assembly instructions, and correspond one-to-one with the sub-partitions in the FLASH:

[0010] Step 4: Generate a configuration list cfg_list based on the correspondence between the function name of each proposed local reconstruction function and its storage address, running address, data length and other configuration parameters, and store it in the third partition of FLASH;

[0011] Step 5: Add a module for moving func_data in the main() function of the application; it is responsible for reading the cfg_list in the third partition of FLASH after the DSP is successfully powered on and all drivers are initialized but before entering the formal application, and then moving the func_data stored in each sub-partition of the second partition of FLASH to the corresponding DSP memory according to the attached information of each node in the configuration linked list, and finally sending the cfg_list data to the host computer through the peripheral interface to ensure that the host computer has the latest cfg_list of DSP;

[0012] At this point, the preparations for local reconstruction have been completed;

[0013] Step 6: Based on the original application, first change the function content of the function to be reconstructed, then compile and generate update.out, convert and generate the burning file update.dat, and finally find the relevant data func_data_update of the function according to the information of the function to be reconstructed in the update.map file;

[0014] Step 7: The host computer reads func_data_update, assembles the protocol packet and sends it to the DSP through the DSP's peripheral interface;

[0015] Step 8: The DSP application runs normally; during the operation, it receives external protocol data through the peripheral interface and parses the command word according to the established protocol content;

[0016] Step 9: When the local reconstruction command, the func_data_update of the function to be reconstructed and its length are parsed, the storage location of the func_data of the function in FLASH and the running memory location in DSP are obtained by reading and traversing cfg_list, and then the func_data in the running memory location is replaced with func_data_update;

[0017] Step 10: Test whether the execution result of the proposed reconstructed function meets the expectation; if so, replace the func_data in the storage location in FLASH with func_data_update; if not, jump to step 6 and repeat until it meets the requirements;

[0018] Step 11: Update the cfg_list information and write it to the third partition of FLASH.

[0019] Furthermore, in step 1, there is no specific limit on the size of the three partitions. The first partition needs to store the burning file of the entire application, occupies the largest space, and needs to start from address 0x0; the second partition stores the func_data of each quasi-local reconstruction function, and occupies a medium size of space; the third partition only needs to store the configuration linked list data, and occupies the smallest space.

[0020] Furthermore, in step 2, the size of the sub-partition is unlimited and is mainly determined by the size of the func_data of the function to be partially reconstructed that needs to be stored; the application has a total of 2 functions func_0() and func_1() to be partially reconstructed, among which the f0_data of func_0() is relatively large, and its corresponding sub-partition 0 is allocated 128kB, occupying FLASH 0x800000~0x81FFFF; and the f1_data of func_1() is relatively small, so its corresponding sub-partition 1 is allocated 32kB, occupying FLASH 0x820000~0x827FFF address.

[0021] Furthermore, in step 3, f0_data of the function to be reconstructed func_0() is stored in sub0_area in FLASH and run0_area in DSP memory, f1_data of the function to be reconstructed func_1() is stored in sub1_area in FLASH and run1_area in DSP memory, and so on. There is no limit on the position of DSP memory occupied by func_data of the function to be partially reconstructed.

[0022] Furthermore, in step 6, the latest func_data_update of the function to be reconstructed can be found from the burning file update.dat, or the update.out file can be loaded online to directly save the generated data file func_data_update from the DSP memory occupied by the function.

[0023] Furthermore, in step 7, the peripheral interface is any interface supported by the DSP, including an Ethernet port, a serial port, and 1553B.

[0024] The beneficial effects of the present invention are as follows:

[0025] (1) The present invention proposes a local reconfiguration method based on a DSP chip, which can be used to reconfigure a specific module in a DSP application program without affecting other modules, thereby effectively increasing the accuracy of DSP reconstruction.

[0026] (2) The present invention has strong applicability, and its universal local reconstruction process can be applied to a variety of DSP chips on the market without limiting the external communication interface. BRIEF DESCRIPTION OF THE DRAWINGS

[0027] Figure 1 Memory partition and corresponding relationship diagram of the method of the present invention.

[0028] Figure 2 The present invention is a flowchart of the method for burning.

[0029] Figure 3 DSP startup flow chart of the method of the present invention.

[0030] Figure 4 A partial reconstruction flow chart of the method of the present invention. DETAILED DESCRIPTION

[0031] The present invention is further described below in conjunction with the accompanying drawings and embodiments.

[0032] The main purpose of the present invention is to propose a dynamic partial reconfiguration method based on DSP chips, which can be applied to DSP chips such as TI's TMS320C6678, TMS320C6657, and domestic FT-M6678. The present invention mainly solves the problem that the application software of the DSP chip cannot reconfigure some key modules on demand.

[0033] The present invention provides a dynamic local reconfiguration method based on a DSP chip, characterized by comprising the following steps:

[0034] A. Divide the FLASH used in DSP BOOT into three partitions, which are independent of each other and have no overlap. The first partition stores the data of the application program burning file generated by the conversion tool chain (called app_data), the second partition stores the relevant data of the function to be partially reconstructed in the application (called func_data), and the third partition stores the configuration list data (called cfg_list);

[0035] B. The second partition is further subdivided into a number of non-overlapping sub-partitions (called sub_area) as needed, and one sub-partition corresponds to storing one func_data of the function to be partially reconstructed;

[0036] C. When writing DSP applications, the DSP memory occupied by the func_data of several functions to be partially reconstructed at runtime is specified as a non-overlapping memory area within the DSP in a manner limited by assembly instructions, and corresponds one-to-one with the sub-partitions in the FLASH.

[0037] D. Generate a configuration list cfg_list based on the correspondence between the function name of each proposed local reconstruction function and its storage address, running address, data length and other configuration parameters, and store it in the third partition of FLASH;

[0038] E. Add a module for moving func_data in the main() function of the application. It is responsible for reading the cfg_list in the third partition of FLASH after the DSP is successfully powered on and all drivers are initialized but before entering the formal application, and then moving the func_data stored in each sub-partition of the second partition of FLASH to the corresponding DSP memory according to the attached information of each node in the configuration linked list, and finally sending the cfg_list data to the host computer through the peripheral interface to ensure that the host computer has the latest cfg_list of DSP;

[0039] At this point, the preparations for local reconstruction have been completed.

[0040] F. Based on the original application, first change the function content of the function to be reconstructed, then compile to generate update.out, convert to generate the burning file update.dat, and finally find the relevant data func_data_update of the function according to the information of the function to be reconstructed in the update.map file;

[0041] G. The host computer reads func_data_update, assembles the protocol packet and sends it to the DSP through the DSP's peripheral interface;

[0042] The H.DSP application runs normally. During operation, it receives external protocol data through the peripheral interface and parses the command word according to the established protocol content;

[0043] I. When the local reconstruction command, the func_data_update of the function to be reconstructed and its length are parsed, the storage location of the func_data of the function in FLASH and the running memory location in DSP are obtained by reading and traversing cfg_list, and then the func_data in the running memory location is replaced with func_data_update;

[0044] J. Test whether the execution result of the proposed reconstructed function meets the expectation. If yes, replace the func_data in the storage location in FLASH with func_data_update; if no, jump to step (6) and repeat until it meets the requirements;

[0045] K. Update the cfg_list information and write it to the third partition of FLASH.

[0046] In step A, there is no specific limit on the size of each partition, which can be flexibly changed according to the actual application. The first partition needs to store the burning file of the entire application, occupies the largest space, and needs to start from the 0x0 address. The second partition stores the func_data of each proposed local reconstruction function, and occupies a medium space. The third partition only needs to store the configuration list data, and occupies the smallest space. For example, the first partition allocates 8MB of space, occupying FLASH 0x0~0x7FFFFF addresses; the second partition allocates 4MB of space, occupying FLASH 0x800000~0xBFFFFF addresses; the third partition allocates 16kB of space, occupying FLASH 0xC00000~0xC04000 addresses.

[0047] In step B, the application has two functions func_0() and func_1() to be partially reconstructed. Among them, the f0_data of func_0() is relatively large, and its corresponding sub-partition 0 can be allocated 128kB, occupying FLASH 0x800000~0x81FFFF; while the f1_data of func_1() is relatively small, so its corresponding sub-partition 1 is allocated 32kB, occupying FLASH 0x820000~0x827FFF address.

[0048] In step C, if the f0_data of the function to be reconstructed func_0() is stored in the sub0_area in the FLASH and the run0_area in the DSP memory, the f1_data of the function to be reconstructed func_1() is stored in the sub1_area in the FLASH and the run1_area in the DSP memory, and so on. The location of the DSP memory occupied by the func_data of the function to be partially reconstructed is not restricted, as long as the address is legal, it can be used. For example, the run0_area of ​​func_0() can be specified as the 128kB space starting from 0x0C300000 in the DSP, corresponding to the sub-partition 0 of the FLASH; the run1_area of ​​func_1() can be specified as the 32kB space starting from 0x0C320000 in the DSP, corresponding to the sub-partition 1 of the FLASH.

[0049] In step D, the configuration list cfg_list is only a specific way of storing the information of the quasi-local reconstruction function. Other ways may also be used, such as a structure array, a combination of multiple integer arrays, etc.

[0050] In step E, there is no restriction on the method of moving data. You can directly use memory copy or use on-chip EDMA peripheral, as long as the moving function can be completed.

[0051] In step F, the latest func_data_update of the function to be reconstructed can be found from the burning file update.dat or the update.out file can be loaded online to directly save the generated data file func_data_update from the DSP memory occupied by the function.

[0052] In step G, the peripheral interface can be any interface supported by DSP, such as network port, serial port, 1553B, etc. In order to pursue efficiency, the network port is mostly used. The data protocol content needs to be defined in advance.

[0053] In step I, the method of replacing func_data is not limited.

[0054] Example:

[0055] The present invention is applicable to DSP chips. The example uses the TMS320C6678 chip produced by TI, and the domestic FT-M6678 can also be used.

[0056] Figure 1 The figure shows the memory division and corresponding relationship diagram of SRAM and FLASH inside DSP when the present invention is applied. Figure 1 In the FLASH, there are three partitions, as follows:

[0057] 1) Partition 1 is used to store the application program's burning file data app_data, so the allocated space is the largest, 8MB, occupying the FLASH space from 0x0 to 0x800000;

[0058] 2) Partition 2 is further divided into multiple sub-partitions s_area to store the f_data of each function to be reconstructed in the application. The f0_data of function func_0() is stored in s0_area (sub-partition 0), the f1_data of function func_1() is stored in s1_area (sub-partition 1), and so on. The location and size of partition 2 in FLASH are not fixed and can be set as needed. In this example, partition 2 is set to 4MB.

[0059] 3) The third partition is used to store cfg_list indicating f_data parameter information. Similar to the second partition, the location and size in FLASH are not fixed and can be set as needed. In this example, the third partition is set to 16kB.

[0060] The internal SRAM of DSP corresponds to the second partition of FLASH, and a series of r_area are allocated to store the f_data of each function to be reconstructed used by the application program at runtime, and the sizes are consistent. Among them, r0_area corresponds to s0_area, r1_area corresponds to s1_area, and so on.

[0061] The correspondence between r_area and s_area, as well as the function names of the functions to be reconstructed, the length of f_data and other parameters generates cfg_list.

[0062] Figure 2 The flowchart of the present invention for burning the DSP program is shown in Figure 1. After the normal burning of the application program to the 0x0 address of the FLASH, the steps of writing the f_data of each function to be reconstructed into the corresponding s_area of ​​the FLASH and writing the cfg_list into the third partition of the FLASH are added to prepare for use when the DSP is powered on.

[0063] Figure 3 The figure shows the DSP power-on startup flow chart when the present invention is applied. An additional moving module is added to the application program, which is responsible for moving the functions f_data to be reconstructed stored in the second partition of FLASH from s_area to r_area after the program enters the main() function and the initialization of each peripheral driver is completed, and finally enters the application module to start execution. In this process, the cfg_list information stored in the FLASH is read and cached locally for standby, and the cfg_list is sent to the host computer for its use.

[0064] Figure 4 The flowchart of local reconstruction when the present invention is applied is shown. When the application is executed normally, the protocol data sent by the host computer is received through the peripheral, and then the command word carried by the protocol is parsed; when the local reconstruction command is parsed, the latest f_data_update and length len of the function are first obtained, and then the s_area in FLASH and r_area in DSP SRAM corresponding to the function are obtained by traversing cfg_list, and finally the f_data in s_area is replaced with the latest f_data_update and tested to see if the result meets the expectation; if the result is incorrect, it is necessary to change the function code to generate a new f_data_update and repeat the local reconstruction process until the requirements are met; if the result is OK, f_data_update is written into s_area, and cfg_list is updated and written into the third partition of FLASH, and the local reconstruction process ends.

Claims

1. A dynamic local reconfiguration method based on DSP chip, characterized in that: The steps include: Step 1: Divide the FLASH used in DSP BOOT into three partitions, which are independent of each other and have no overlap. The first partition stores the data of the application program burning file generated by the conversion tool chain, called app_data; the second partition stores the relevant data of the function to be partially reconstructed in the application, called func_data; the third partition stores the configuration list data, called cfg_list; Step 2: further subdivide the second partition into several non-overlapping sub-partitions as needed, called sub_area, and one sub-partition stores one func_data of the function to be partially reconstructed; Step 3: When writing a DSP application, specify the DSP memory occupied by the func_data of several functions to be partially reconstructed at runtime as non-overlapping memory areas within the DSP in a way limited by assembly instructions, and correspond one-to-one with the sub-partitions in the FLASH: Step 4: Generate a configuration list cfg_list based on the correspondence between the function name of each proposed local reconstruction function and its storage address, running address, data length and other configuration parameters, and store it in the third partition of FLASH; Step 5: Add a module for moving func_data in the main() function of the application; it is responsible for reading the cfg_list in the third partition of FLASH after the DSP is successfully powered on and all drivers are initialized but before entering the formal application, and then moving the func_data stored in each sub-partition of the second partition of FLASH to the corresponding DSP memory according to the attached information of each node in the configuration linked list, and finally sending the cfg_list data to the host computer through the peripheral interface to ensure that the host computer has the latest cfg_list of DSP; At this point, the preparations for local reconstruction have been completed; Step 6: Based on the original application, first change the function content of the function to be reconstructed, then compile and generate update.out, convert and generate the burning file update.dat, and finally find the relevant data func_data_update of the function according to the information of the function to be reconstructed in the update.map file; Step 7: The host computer reads func_data_update, assembles the protocol packet and sends it to the DSP through the DSP's peripheral interface; Step 8: The DSP application runs normally; during the operation, it receives external protocol data through the peripheral interface and parses the command word according to the established protocol content; Step 9: When the local reconstruction command, the func_data_update of the function to be reconstructed and its length are parsed, the storage location of the func_data of the function in FLASH and the running memory location in DSP are obtained by reading and traversing cfg_list, and then the func_data in the running memory location is replaced with func_data_update; Step 10: Test whether the execution result of the proposed reconstructed function meets the expectation; if so, replace the func_data in the storage location in FLASH with func_data_update; if not, jump to step 6 and repeat until it meets the requirements; Step 11: Update the cfg_list information and write it to the third partition of FLASH.

2. A dynamic local reconfigurable method based on a DSP chip according to claim 1, characterized in that: In step 1, there is no specific limit on the size of the three partitions. The first partition needs to store the burning file of the entire application, occupies the largest space, and needs to start from address 0x0; the second partition stores the func_data of each proposed local reconstruction function, and occupies a medium size of space; the third partition only needs to store the configuration linked list data, and occupies the smallest space.

3. A dynamic local reconfiguration method based on DSP chip according to claim 2, characterized in that: In step 2, the size of the sub-partition is unlimited and is mainly determined by the size of the func_data of the function to be partially reconstructed that needs to be stored; the application has two functions func_0() and func_1() to be partially reconstructed, among which the f0_data of func_0() is relatively large, and its corresponding sub-partition 0 is allocated 128kB, occupying FLASH 0x800000~0x81FFFF; while the f1_data of func_1() is relatively small, so its corresponding sub-partition 1 is allocated 32kB, occupying FLASH 0x820000~0x827FFF address.

4. The dynamic local reconfiguration method based on DSP chip according to claim 3, characterized in that: In step 3, f0_data of the function to be reconstructed func_0() is stored in sub0_area in FLASH and run0_area in DSP memory, f1_data of the function to be reconstructed func_1() is stored in sub1_area in FLASH and run1_area in DSP memory, and so on. There is no limit on the position of DSP memory occupied by func_data of the function to be partially reconstructed.

5. A dynamic local reconfiguration method based on DSP chip according to claim 4, characterized in that: In step 6, the latest func_data_update of the function to be reconstructed can be found from the burning file update.dat, or the update.out file can be loaded online to directly save the generated data file func_data_update from the DSP memory occupied by the function.

6. A dynamic local reconfiguration method based on DSP chip according to claim 5, characterized in that: In step 7, the peripheral interface is any interface supported by the DSP, including an Ethernet port, a serial port, and 1553B.

Images