A dynamic local reconfiguration method based on DSP chip

Abstract

This invention discloses a dynamic partial reconfiguration method based on a DSP chip. During DSP operation, this method receives external commands and data through a peripheral interface and updates the relevant data of the function to be reconfigured in the application program to complete the partial reconfiguration. This method does not require powering down or restarting the application program, and does not affect other modules in the program. This method uses functions called in the application program as the elements for partial reconfiguration, and uses the TI TMS320C6678 multi-core DSP chip as the hardware carrier. The effectiveness of this method has been verified, and the domestic Feiteng FT-M6678 is also applicable.

Description

Technical Field

[0001] The invention belongs to the technical field of DSP application, and in particular relates to a dynamic local reconfiguration 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 functionality of DSPs. For example, the patents "Multi-channel Reconfigurable Signal Processing Device" (Authorization Announcement No.: CN 112199320 B) and "A Reconfigurable Signal Processing Board Based on VPX Architecture and Reconfiguration Method Thereof" (Authorization Announcement No.: CN 115905813 B) implement DSP application reconfiguration by receiving externally burned file data, overwriting the original program, and then restarting. The patent "A Dynamic Global Reconfiguration Method Based on DSP Chip" (Patent No.: ZL 2023 1 0870603.6) pre-burns multiple versions of applications with different functions to different locations in the FLASH, then triggers and modifies the location pointed to in the FLASH during DSP boot with external instructions, and finally controls the DSP soft reset to achieve DSP application reconfiguration.

[0004] When debugging an application, it's often the individual algorithm processing modules that need to be adjusted and updated, while the overall architecture is fixed. The methods described in the aforementioned patents all fall under the category of global reconfiguration, which is not applicable in this application scenario. Replacing the entire application within the DSP is also crude, so it's necessary to develop a local reconfiguration method that can reconfigure the target module without affecting other modules within the application. Summary of the Invention

[0005] To overcome the shortcomings of existing technologies, the present invention provides a dynamic partial reconfiguration method based on a DSP chip. During DSP operation, this method receives external commands and data through a peripheral interface and updates the relevant data of the function to be reconfigured in the application program to complete the partial reconfiguration function. This method does not require power off and restart, and does not affect other modules in the program. This method uses the functions called in the application program as the elements for partial reconfiguration, and uses the TI TMS320C6678 multi-core DSP chip as the hardware carrier. The effectiveness of this method has been verified, and the domestic Feiteng FT-M6678 is also applicable.

[0006] The technical solutions adopted by the present invention to solve the technical problems are as follows:

[0007] Step 1: Divide the FLASH used for DSP BOOT into three independent and non-overlapping partitions. Partition 1 stores the data of the application program file generated by the conversion tool chain, called app_data. Partition 2 stores the data related to the function to be partially reconstructed in the application, called func_data. Partition 3 stores the configuration list data, called cfg_list.

[0008] Step 2: Subdivide the second partition into several non-overlapping sub-partitions as needed, called sub_area. Each sub-partition stores the func_data of a 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, and correspond one-to-one with the sub-partitions in the FLASH, in a manner limited by assembly instructions:

[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 to move func_data in the main() function of the application. This module 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. Then, according to the information attached to each node in the configuration list, the func_data stored in each sub-partition of the second partition of FLASH is moved to the corresponding DSP memory. Finally, the cfg_list data is sent to the host computer through the peripheral interface to ensure that the host computer has the latest cfg_list of the 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 to generate update.out, convert to generate the burning file update.dat, and finally find the relevant data func_data_update of the function based on 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 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 function's func_data 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 function to be reconstructed 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 not limited 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 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; 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 location of the DSP memory occupied by the func_data of the function to be partially reconstructed.

[0022] Furthermore, in step 6, in addition to finding the latest func_data_update of the function to be reconstructed from the burning file update.dat, the update.out file can also 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 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 many DSP chips on the market without limiting the external communication interface. BRIEF DESCRIPTION OF THE DRAWINGS

[0027] Figure 1 Memory partitioning 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 Flowchart of partial reconstruction of the method of the present invention. DETAILED DESCRIPTION

[0031] The present invention will be further described below with reference to the accompanying drawings and examples.

[0032] The main purpose of this 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 the domestic FT-M6678. This invention mainly solves the problem that the application software of DSP chips 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 for DSP boot into three independent, non-overlapping partitions. Partition 1 stores the data of the application program file generated by the conversion toolchain (called app_data), partition 2 stores the data related to the function to be partially reconstructed in the application (called func_data), and partition 3 stores the configuration list data (called cfg_list).

[0035] B. Further subdivide the second partition into several non-overlapping sub-partitions (called sub_area) as needed, with each sub-partition corresponding to the 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 non-overlapping memory areas within the DSP in a manner limited by assembly instructions, and corresponds one-to-one to 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 to move func_data in the main() function of the application. This module is responsible for reading the cfg_list in the third partition of the FLASH after the DSP is successfully powered on and all drivers are initialized, but before entering the formal application. Then, based on the information attached to each node in the configuration list, it moves the func_data stored in each sub-partition of the second partition of the FLASH to the corresponding DSP memory. Finally, it sends the cfg_list data to the host computer through the peripheral interface to ensure that the host computer has the latest cfg_list of the 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 based on 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 function's func_data 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 not, 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 are no specific restrictions on the size of each partition and they can be flexibly changed based on the actual application. Partition 1 needs to store the entire application's flash file, occupies the largest space, and must start at address 0x0. Partition 2 stores the func_data of each function to be partially reconstructed, occupying a medium size. Partition 3 only needs to store configuration linked list data and occupies the smallest space. For example, partition 1 allocates 8MB of space, occupying FLASH addresses 0x0 to 0x7FFFFF; partition 2 allocates 4MB of space, occupying FLASH addresses 0x800000 to 0xBFFFFF; and partition 3 allocates 16kB of space, occupying FLASH addresses 0xC00000 to 0xC04000.

[0047] In step B, the application has two functions to be partially reconstructed, func_0() and func_1(). 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. There is no restriction on the location of the DSP memory occupied by the func_data of the function to be partially reconstructed; 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 at 0x0C300000 in the DSP, corresponding to the subpartition 0 of the FLASH; the run1_area of ​​func_1() can be specified as the 32kB space starting at 0x0C320000 in the DSP, corresponding to the subpartition 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 the on-chip EDMA peripheral, as long as the moving function can be completed.

[0051] In step F, in addition to finding the latest func_data_update of the function to be reconstructed from the burn-in file update.dat, the update.out file can also 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 the DSP, such as Ethernet, serial, or 1553B. For efficiency, Ethernet is often used. The data protocol must be defined in advance.

[0053] In step I, there is no restriction on the method of replacing func_data.

[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 chip can also be used.

[0056] Figure 1 The figure shows the memory division and corresponding relationship between 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 0x0 ~ 0x800000 space;

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

[0059] 3) Partition 3 is used to store the cfg_list file, which contains the f_data parameter information. Similar to Partition 2, its location and size in the FLASH are not fixed and can be set as needed. In this example, Partition 3 is set to 16kB.

[0060] The DSP's internal SRAM corresponds to the second partition of the FLASH. A series of r_area areas are allocated to store the f_data of each function to be reconstructed during application runtime. The r0_area corresponds to the s0_area, the r1_area corresponds to the 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. 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 to the corresponding s_area of ​​the FLASH and writing the cfg_list to the third partition of the FLASH are added for use when the DSP is powered on.

[0063] Figure 3 The figure shows the DSP power-up startup flow chart for this invention. A migration module has been added to the application. After the program enters the main() function and the peripheral drivers are initialized, it moves the f_data of the functions to be reconstructed stored in the second partition of the FLASH from the s_area to the r_area. Finally, the application module enters and begins execution. During this process, the cfg_list information stored in the FLASH is read and cached locally for backup, and the cfg_list is sent to the host computer for use.

[0064] Figure 4 The flowchart of the local reconstruction process when the present invention is applied is shown. When the application is executing normally, the protocol data sent by the host computer is received through the peripheral device, 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. Then, by traversing the cfg_list, the corresponding s_area in the FLASH and r_area in the DSP SRAM are obtained. 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, the function code needs to be modified to generate a new f_data_update and the local reconstruction process is repeated until the requirements are met. If the result is correct, the f_data_update is written to s_area, and the cfg_list is updated and written to the third partition of the 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 for DSP BOOT into three independent and non-overlapping partitions. Partition 1 stores the data of the application program file generated by the conversion tool chain, called app_data. Partition 2 stores the data related to the function to be partially reconstructed in the application, called func_data. Partition 3 stores the configuration list data, called cfg_list. Step 2: Subdivide the second partition into several non-overlapping sub-partitions as needed, called sub_area. Each sub-partition stores the func_data of a 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, and correspond one-to-one with the sub-partitions in the FLASH, in a manner limited by assembly instructions: 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, and data length, and store it in the third partition of FLASH; Step 5: Add a module to move func_data in the main() function of the application. This module 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. Then, according to the information attached to each node in the configuration list, the func_data stored in each sub-partition of the second partition of FLASH is moved to the corresponding DSP memory. Finally, the cfg_list data is sent to the host computer through the peripheral interface to ensure that the host computer has the latest cfg_list of the 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 to generate update.out, convert to generate the burning file update.dat, and finally find the relevant data func_data_update of the function based on 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 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 function's func_data 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 function to be reconstructed 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 reconfiguration 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 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 a DSP chip according to claim 2, characterized in that: In step 2, the size of the sub-partition is not limited 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 to be partially reconstructed, func_0() and func_1(), 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 addresses.

4. The dynamic local reconfiguration method based on DSP chip according to claim 3, characterized in that: In step 3, the f0_data of the function to be reconstructed func_0() is stored in the sub0_area in 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 FLASH and the run1_area in the DSP memory, and so on. There is no limit on the position of the DSP memory occupied by the func_data of the function to be partially reconstructed.

5. The dynamic local reconfiguration method based on DSP chip according to claim 4, characterized in that: In step 6, in addition to finding the latest func_data_update of the function to be reconstructed from the burning file update.dat, the update.out file can also 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 a 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