General software interface implementation method based on bus architecture

By adopting a general software interface method based on the bus architecture in the design of FPGA software, the transplantation difficulties caused by software interface specificity are solved, and the generalization and flexibility of software modules are improved.

CN119883211APending Publication Date: 2025-04-25BEIJING INST OF REMOTE SENSING EQUIP
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202411969204.6
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2024-12-30
Publication Date
2025-04-25

AI Technical Summary

Technical Problem

In conventional FPGA software design, the degree of software interface is relatively high, which leads to adjustments or modifications when transplanting to other projects, which is not conducive to the promotion and application of software modules.

Method used

The general software interface implementation method based on the bus architecture is adopted, and the common data interaction requirements of each software module are designed, the software workflow is divided, the functional modules are divided, and the common software interface bus summary is formed to realize the bus architecture control of each software module.

Benefits of technology

The software module is universalized, avoids the impact of interface changes on other modules, improves the independence and flexibility of the software module, and facilitates the dynamic configuration of data flow and software parameters.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN119883211A_ABST
    Figure CN119883211A_ABST
Patent Text Reader

Abstract

The invention provides a universal software interface implementation method based on a bus architecture, and relates to the field of FPGA software module design reusability and generalization design. According to the method, interconnection and interoperability among software modules are redefined by adopting a universal bus type interface mode, bus type packaging design is carried out on the common software modules, a configurable parameter configuration area and a function implementation area are formed, cooperative work among the function modules is achieved through a task scheduling unit, and the function modules are integrated into a whole. The completed universal module can be applied to the development of the integrated programmable SOC platform software based on the FPGA or integrated with the FPGA and the CPU, and the generalization of the software module is realized. The problems that in a conventional design, the special degree of a software interface is high, adjustment or modification is needed when the software interface is transplanted into other projects, and application and popularization of a software module are not facilitated are solved. And the convenience of module interconnection is improved under the condition that the software universality is further improved.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This document relates to the field of reusable and universal design of FPGA software modules, and in particular to a method for realizing a universal software interface based on a bus architecture. Background Art

[0002] In FPGA software design, a modular approach is usually adopted to implement the construction of each functional module, and a top-down or bottom-up approach is used to complete the integration of each functional module, so as to realize the hardware function of the final product. In conventional design, the data interface between modules is usually defined by the designer, and a common module is formed after verification of multiple projects. It usually has a strong project correlation. This type of module usually defines the interface between modules based on the requirements of each functional module, and has a relatively strong hardware correlation. When the interface chip changes, the software interface also changes, which is not conducive to the integration of different modules. The software interface has a high degree of specialization and needs to be adjusted or modified when transplanted to other projects, which is not conducive to the promotion and application of software modules.

[0003] Therefore, an interface design method is urgently needed to solve the problem that in conventional design, the software interface is highly specialized and needs to be adjusted or modified when transplanted to other projects, which is not conducive to the promotion and application of software modules. Summary of the invention

[0004] This specification provides a general software interface implementation method based on a bus architecture, which is used to solve the problem that in conventional designs, the software interface has a high degree of specialization and needs to be adjusted or modified when transplanted to other projects, which is not conducive to the promotion and application of software modules.

[0005] In a first aspect, this specification provides a method for implementing a general software interface based on a bus architecture, comprising:

[0006] Design software workflow and complete input and output interface division according to task requirements;

[0007] Divide the functional modules based on the task functional requirements and confirm the software module requirements;

[0008] Divide the software modules into data processing modules, control modules and interface modules according to their functions;

[0009] According to the interface connectivity of different modules, the common data interaction requirements of different modules in the interface modules are sorted out, and the interaction data types of each model are determined; wherein the interaction data types are divided into data flow type, register type and parameter configuration type;

[0010] For parameter configuration modules, the configuration parameters of the modules are extracted to form a general software register configuration area and stored in the respective modules;

[0011] For data flow modules, the data flow paths of the modules are sorted out to form software module function configuration areas, which are stored in the respective modules;

[0012] A software interface bus summary is formed according to registers and functional requirements, and the buses of various types of modules are mounted on the general interconnection bus;

[0013] The task scheduling unit allocates and configures the address space of the bus to form a bus address space allocation table and an interrupt response table;

[0014] According to the task requirements of each module, the task scheduling unit controls the bus access of each software module to realize the bus architecture control of the general software module.

[0015] In a second aspect, the present specification provides a general software interface bus architecture based on a bus architecture, wherein the bus architecture operation platform is an FPGA or a fusion programmable SOC platform integrating an FPGA and a CPU, and the unit modules included in the bus architecture in the method are: a task scheduling unit, a cross-connection module, and a plurality of functional interconnection modules;

[0016] Wherein, the task scheduling unit is connected to the cross interconnection module via a central interconnection bus, and each functional interconnection module is connected in parallel and respectively connected to the cross interconnection module;

[0017] The task scheduling unit is used to manage the cross-connection module, the bus status of each functional interconnection module, and interrupt requests, and perform module configuration and task scheduling;

[0018] The cross-connection module is used to realize bus interconnection and data interaction between the task scheduling unit and each functional interconnection module;

[0019] Each functional interconnection module is divided into a parameter configuration area and a function implementation area. The parameter configuration area is used to obtain data from various peripherals and perform communication control, and configure module parameters through the task scheduling unit; the function implementation area is used to process the input data stream and output the processed data to the bus.

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

[0021] This specification provides a method for implementing a general software interface based on a bus architecture. The method redefines the interconnectivity between software modules by adopting a general bus interface, designs bus-type encapsulation of commonly used software modules, forms a configurable parameter configuration area and a function implementation area, and realizes the collaborative work between functional modules through a task scheduling unit. The completed general module can be applied to the software development of a fusion programmable SOC platform based on FPGA or integrated FPGA and CPU to realize the generalization of software modules. The method uniformly encapsulates mature functional modules, and the interconnection interface between modules adopts a bus form instead of the previously customized signal format. It has the characteristics of strong configurability and strong independence of each module, which can avoid the impact of interface changes on other modules and easily realize the isolation of software modules. At the same time, the system selects whether to adopt a bus control method according to the characteristics of different software modules, and can realize the dynamic configuration of software parameters. By adopting a general bus architecture design, data streams and software parameters can be easily changed through modules such as CPU, which greatly improves the versatility and flexibility of software modules. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] The drawings described herein are used to provide a further understanding of this specification and constitute a part of this specification. The illustrative embodiments and descriptions of this specification are used to explain this specification and do not constitute an improper limitation on this specification. In the drawings:

[0023] Figure 1 It is a schematic diagram of a general software interface implementation method based on a bus architecture provided in an embodiment of this specification;

[0024] Figure 2 It is a schematic diagram of a functional interconnection module structure based on a universal interconnection bus provided in an embodiment of this specification;

[0025] Figure 3 It is a schematic diagram of a general software interface bus architecture based on a bus architecture provided in an embodiment of this specification. DETAILED DESCRIPTION

[0026] In order to make the purpose, technical solutions and advantages of this specification clearer, the technical solutions of this application will be clearly and completely described below in conjunction with the specific embodiments of this application and their corresponding drawings. Obviously, the described embodiments are only part of the embodiments of this specification, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this document.

[0027] The technical solutions provided by the embodiments of this specification are described in detail below in conjunction with the accompanying drawings. Specific embodiment one:

[0029] This embodiment provides a general software interface implementation method based on a bus architecture, see Figure 1 , specifically including the following steps:

[0030] Step 101: Design the software workflow and complete the input and output interface division according to the task requirements;

[0031] Step 102: Divide the functional modules based on the task functional requirements and confirm the software module requirements;

[0032] Step 103: Divide the software modules into data processing modules, control modules and interface modules according to their functions;

[0033] Step 104: based on the interface connectivity of different modules, sort out the common data interaction requirements of different modules in the interface class modules, and determine the interaction data type of each model; wherein the interaction data type is divided into data stream type, register type and parameter configuration type.

[0034] Step 105: For parameter configuration modules, extract the configuration parameters of the modules, form a general software register configuration area, and store it in each module;

[0035] Step 106: for the data flow type module, sort out the data flow path of the module to form a software module function configuration area, and store it in each module;

[0036] Step 107: A software interface bus summary is formed according to registers and functional requirements, and buses of various types of modules are mounted on a universal interconnect bus;

[0037] Step 108, the task scheduling unit allocates and configures the address space of the bus to form a bus address space allocation table and an interrupt response table;

[0038] Specifically, one implementation of step 108 may be:

[0039] S81. Determine whether to update the specified module parameters according to the external input, coordinate the working sequence of each module or manage the priority of the external input response.

[0040] Specifically:

[0041] S812, according to the relevant parameters passed by the functional interconnection module when calling, the task scheduling unit allocates an address space and an interrupt number to the functional interconnection module, and the task scheduling unit dynamically adjusts the parameters and processes the relevant interrupt request during operation;

[0042] S813. If the functional interconnection module does not need to be controlled by the task scheduling unit, it will not be connected to the task scheduling unit. The function of the module is fixed when in use, and parameters cannot be dynamically adjusted during operation.

[0043] Step 109: According to the task requirements of each module, the task scheduling unit controls the bus access of each software module to implement bus architecture control of the general software module.

[0044] Optional, bus-based data flow processing, flexible selection of bus clock frequency according to data speed;

[0045] When processing data across clock domains, use the cache function to adjust the data bit width and clock.

[0046] Optionally, register classes are configured using a low-speed bus, and data stream processing is processed using a high-speed bus.

[0047] In summary, this embodiment redefines the interconnectivity between software modules by adopting a universal bus interface, performs bus-type encapsulation design on commonly used software modules, forms a configurable parameter configuration area and a function implementation area, and realizes the collaborative work between functional modules through a task scheduling unit. The completed universal module can be applied to the software development of a fusion programmable SOC platform based on FPGA or integrated FPGA and CPU, so as to realize the universalization of software modules. The system uniformly encapsulates mature functional modules, and the interconnection interface between modules adopts a bus form instead of the previously customized signal format. It has the characteristics of strong configurability and strong independence of each module, which can avoid the impact of interface changes on other modules and easily realize the isolation of software modules. At the same time, the system selects whether to adopt a bus control method according to the characteristics of different software modules, and can realize the dynamic configuration of software parameters. By adopting a universal bus architecture design, data streams and software parameters can be easily changed through modules such as CPU, which greatly improves the universality and flexibility of software modules. Specific embodiment 2:

[0049] This embodiment provides a general software interface implementation method based on a bus architecture, see Figure 2 , Figure 3 The method is run on a platform that is an FPGA or a fusion programmable SOC platform that integrates an FPGA and a CPU. The unit modules included in the bus architecture in the method include: a task scheduling unit, a cross-connection module, and a plurality of functional interconnection modules;

[0050] Specifically, the connection relationship between each module is:

[0051] The task scheduling unit is connected to the cross interconnection module via a central interconnection bus, and each functional interconnection module is connected in parallel and respectively connected to the cross interconnection module; the functional interconnection module is connected to the peripheral device;

[0052] Based on the above connection relationship, the functions of each module are:

[0053] The task scheduling unit is used to manage the cross-connection module, the bus status of each functional interconnection module, and interrupt requests, and perform module configuration and task scheduling;

[0054] The cross-connection module is used to realize bus interconnection and data interaction between the task scheduling unit and each functional interconnection module;

[0055] Each functional interconnection module is divided into a parameter configuration area and a function implementation area. The parameter configuration area is used to obtain data from various peripherals and perform communication control, and configure module parameters through the task scheduling unit; the function implementation area is used to process the input data stream and output the processed data to the bus.

[0056] Furthermore, the working principle of each module is described in detail below:

[0057] First of all, it should be noted that the task scheduling unit is implemented by a soft-core MCU or a hard-core CPU. When a soft-core MCU or a hard-core CPU is used, task scheduling and peripheral management, register parameter table configuration, etc. can be conveniently performed. At the same time, some complex calculations can be completed, reducing the complexity of FPGA programming.

[0058] Furthermore, the software types of the functional interconnection modules include: data processing type, control type and interface type.

[0059] According to the general data processing flow, sort out the functional modules and divide the software modules into data processing, control and interface modules;

[0060] Each functional interconnection module is any one of all software types;

[0061] Furthermore, if Figure 2 As shown, the functional interconnection module forms a parameter control area with the parameterizable part according to the processing requirements, connects it to the low-speed bus of the CPU, and performs update control on a small amount of data;

[0062] As the carrier of the specific functions of the module, the function realization area completes the high-speed processing of input data, including data calculation, control parameter conversion and interface switching, etc. It uses a high-speed bus to perform real-time processing of large amounts of data on data streams that need to be processed at high speed.

[0063] The functional interconnection module processes the data stream in the form of data packets. The processing delay of each functional interconnection module is accurate to the clock number level according to different algorithms, and the delay is fixed after the parameter configuration is completed.

[0064] The functional interconnection module determines whether to connect the functional modules to the CPU control bus according to the processing requirements of each module, updates the working parameters of each module through the low-speed bus or makes it work in an independent mode to achieve the commonality of each module.

[0065] Based on this, when setting up multiple parallel functional interconnection modules, each module can be connected to the functional interconnection module through a low-speed bus, and the parameter configuration of each functional module can be realized by allocating different address spaces to each module. When adding new modules, it is only necessary to expand the new address range.

[0066] Optionally, the task scheduling unit determines whether to update a module parameter based on external input, coordinates the working sequence of each module, or manages the priority of external input response, as follows:

[0067] Each functional interconnection module passes relevant parameters to the task scheduling unit when it is called, and the task scheduling unit allocates address space and interrupt number to the functional interconnection module. The task scheduling unit can dynamically adjust parameters and process relevant interrupt requests during operation. If the functional interconnection module does not need to be controlled by the task scheduling unit, it will not be connected to the task scheduling unit. The function of the module is fixed when in use, and the parameters cannot be adjusted dynamically during operation.

[0068] Optionally, when multiple modules work together, the interrupt request of each functional interconnection module is adjusted according to the priority;

[0069] The startup sequence of each functional interconnection module can also be flexibly configured through the CPU.

[0070] Furthermore, the cross-interconnection module is used to realize the connection of multiple bus data, and finally aggregate them to the control and communication bus of the task scheduling unit to realize the functional interconnection between the task scheduling unit and each functional interconnection module.

[0071] In summary, this embodiment redefines the interconnectivity between software modules by adopting a universal bus interface, performs bus-type encapsulation design on commonly used software modules, forms a configurable parameter configuration area and a function implementation area, and realizes the collaborative work between functional modules through a task scheduling unit. The completed universal module can be applied to the software development of a fusion programmable SOC platform based on FPGA or integrated FPGA and CPU, so as to realize the universalization of software modules. The system uniformly encapsulates mature functional modules, and the interconnection interface between modules adopts a bus form instead of the previously customized signal format. It has the characteristics of strong configurability and strong independence of each module, which can avoid the impact of interface changes on other modules and easily realize the isolation of software modules. At the same time, the system selects whether to adopt a bus control method according to the characteristics of different software modules, and can realize the dynamic configuration of software parameters. By adopting a universal bus architecture design, data streams and software parameters can be easily changed through modules such as CPU, which greatly improves the universality and flexibility of software modules. Specific embodiment three:

[0073] This embodiment provides a general software interface implementation method based on a bus architecture, which consists of a task scheduling unit (CPU / MCU), a cross-interconnection module and sub-functional modules. The operating platform is an FPGA or a fusion programmable SOC platform integrating FPGA and CPU, wherein the task scheduling unit completes the bus status and interrupt request management of each module, the cross-interconnection module completes the bus interconnection and data interaction between the CPU and each interconnected module, and each sub-module completes data processing and communication control with each peripheral, data acquisition, etc.

[0074] Optionally, the general software interface implementation based on the bus architecture requires a CPU or a soft-core unit to implement bus interconnection and configuration management of each module, forming a software operation control process with the CPU as the core.

[0075] Optionally, the cross-connection module realizes the connection of multiple bus data, and finally aggregates them to the control and communication bus of the CPU to realize the functional interconnection between the CPU and other modules.

[0076] Optionally, each functional module forms a parameter control area for the parameterizable part according to processing requirements, and connects it to the low-speed bus of the CPU to realize update control of a small amount of data; for data streams that require high-speed processing, a high-speed bus is used to realize real-time processing of large amounts of data.

[0077] Optionally, each functional module may determine whether to access the CPU control bus as required, and may work in an independent mode to achieve the versatility of each module.

[0078] Furthermore, the method described in this embodiment implements universal processing of each module in the FPGA software to extract configurable parameters and data streams that can be used for processing, and implements bus management and task scheduling of each module through control modules such as the CPU in the software module integration design, ultimately achieving collaborative work between the modules.

[0079] The software architecture based on the universal interconnection bus described in this embodiment usually runs on a pure FPGA platform or an integrated SOC chip with a hard-core CPU, and is mainly composed of a CPU / MCU module that can realize task scheduling, a bus cross-interconnection module and other functional modules. The design functions of each module are as follows:

[0080] 1. The task scheduling unit is implemented by a soft-core MCU (pure FPGA platform) or a hard-core CPU to manage the bus status and interrupt requests of each module, and use the flexible programming method of the CPU to realize the configuration and task scheduling of each module;

[0081] 2. The cross-connection module completes the bus interconnection and data interaction between the CPU and each interconnection module;

[0082] 3. Each sub-module completes its own data processing function and communication control and data acquisition with various peripherals.

[0083] Figure 3 It is a common parallel architecture. Each module interacts with each other through a central interconnection module. In commonly used software algorithm processing, it is usually necessary to perform multi-step processing on the data flow. In this way, each module can be cascaded using a common data bus to form a process-based data processing function.

[0084] Each module is divided into a parameter configuration area and a function implementation area. The parameter configuration area can complete the configuration of module parameters through the CPU, such as module enable, data structure adjustment and processing algorithm selection; the function implementation area completes the processing of the input data stream and outputs the processed data to the bus.

[0085] In data stream processing, each module is usually processed in the form of data packets. The processing delay of each module can be accurate to the clock level according to different algorithms, and the delay is fixed after the parameter configuration is completed;

[0086] When multiple modules work together, the interrupt request of each module is adjusted according to the priority, and the startup sequence of each module can also be flexibly configured through the CPU.

[0087] The bus-based data flow processing method can realize flexible configuration of data bit width, and flexibly select the bus clock frequency according to the data speed. When cross-clock domain processing of data is required, the cache function in the module can be flexibly used to adjust the data bit width and clock.

[0088] After adopting the universal interconnect bus software framework, various software modules can be easily formed into a standard software library, which is convenient for version control and status management of the software. Each module is maintained by a dedicated person, reducing the workload of familiarizing with the interface when calling.

[0089] Compared with the previous functional modular design concept, this solution uniformly encapsulates mature functional modules. The interconnection interface between modules adopts a bus form instead of the previous customized signal format. It has the characteristics of strong configurability and strong independence of each module. It can avoid the impact of interface changes on other modules and easily achieve isolation of software modules.

[0090] The universal software interface based on the bus architecture designed in this embodiment can realize the universal improvement of existing software modules, and realize the improvement of the convenience of module interconnection while further improving the versatility of the software.

[0091] The interconnect bus architecture described in the present embodiment can be expanded or improved according to actual use, such as realizing multifunctional cascading of data processing functions. Figure 3 The parallel architecture is improved to a parallel + series architecture to achieve multi-level processing of data.

[0092] According to the implementation method provided in this embodiment, the existing module usage method can be flexibly selected and compatible with the original functions, which can improve the software development efficiency.

[0093] Furthermore, the present embodiment aims to provide a universal software interface, enhance the universality of software module interconnection, and implement a universal design method for software modules.

[0094] In this regard, this embodiment proposes a general software interface implementation method based on a bus architecture, and the specific steps are as follows:

[0095] Step 1: According to the general data processing process, sort out the functional modules and divide the software modules into data processing, control and interface modules;

[0096] Step 2: Sort out the common data interaction requirements of various modules according to the interface connectivity requirements of different modules, and divide them into data stream type, register type and parameter configuration type according to the interaction data type;

[0097] Step 3: Extract the configuration parameters of different modules to form a general software register configuration area;

[0098] Step 4: Sort out the data flow path of the module to form a software module function configuration area;

[0099] Step 5: A software interface bus summary is formed according to register and function requirements, where the register class is configured using a low-speed bus and the data stream processing is processed using a high-speed bus;

[0100] Step 6: Mount the bus of each software module on the universal interconnection bus, use the universal control module (CPU / MCU) to implement the address space allocation and configuration of the bus, and form a bus address space allocation table and an interrupt response table;

[0101] Step 7: Run the general control module (CPU / MCU) to implement bus access and control of each software module, and implement bus architecture control of the general software module.

[0102] At this point, the implementation of the general software interface based on the bus architecture has been completed.

[0103] After adopting the method of the embodiment, whether to adopt the bus control method can be selected according to the characteristics of different software modules, and dynamic configuration of software parameters can be realized. By adopting a universal bus architecture design, data flow and software parameters can be conveniently changed through modules such as the CPU, which greatly improves the versatility and flexibility of the software module.

[0104] In summary, this embodiment redefines the interconnectivity between software modules by adopting a universal bus interface, performs bus-type encapsulation design on commonly used software modules, forms a configurable parameter configuration area and a function implementation area, and realizes the collaborative work between functional modules through a task scheduling unit. The completed universal module can be applied to the software development of a fusion programmable SOC platform based on FPGA or integrated FPGA and CPU, so as to realize the universalization of software modules. The system uniformly encapsulates mature functional modules, and the interconnection interface between modules adopts a bus form instead of the previously customized signal format. It has the characteristics of strong configurability and strong independence of each module, which can avoid the impact of interface changes on other modules and easily realize the isolation of software modules. At the same time, the system selects whether to adopt a bus control method according to the characteristics of different software modules, and can realize the dynamic configuration of software parameters. By adopting a universal bus architecture design, data streams and software parameters can be easily changed through modules such as CPU, which greatly improves the universality and flexibility of software modules.

[0105] The above description is only a preferred embodiment of this specification and is not intended to limit this specification. For those skilled in the art, this specification may have various changes and modifications. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of this specification shall be included in the protection scope of this specification.

Claims

1. A method for realizing a general software interface based on a bus architecture, characterized in that: include: Design software workflow and complete input and output interface division according to task requirements; Divide the functional modules based on the task functional requirements and confirm the software module requirements; Divide the software modules into data processing modules, control modules and interface modules according to their functions; According to the interface connectivity of different modules, the common data interaction requirements of different modules in the interface modules are sorted out, and the interaction data types of each model are determined; wherein the interaction data types are divided into data flow type, register type and parameter configuration type; For parameter configuration modules, the configuration parameters of the modules are extracted to form a general software register configuration area and stored in the respective modules; For data flow modules, the data flow paths of the modules are sorted out to form software module function configuration areas, which are stored in the respective modules; A software interface bus summary is formed according to registers and functional requirements, and the buses of various types of modules are mounted on the general interconnection bus; The task scheduling unit allocates and configures the address space of the bus to form a bus address space allocation table and an interrupt response table; According to the task requirements of each module, the task scheduling unit controls the bus access of each software module to realize the bus architecture control of the general software module.

2. The method according to claim 1, characterized in that The task scheduling unit allocates and configures the address space of the bus to form a bus address space allocation table and an interrupt response table, including: Determine whether to update the specified module parameters based on external input, coordinate the working sequence of each module, or manage the priority of external input response.

3. The method according to claim 2, characterized in that The determining whether to update the specified module parameters according to the external input, coordinating the working sequence of each module or managing the priority of the external input response includes: According to the relevant parameters passed by the functional interconnection module when calling, the task scheduling unit allocates address space and interrupt number to the functional interconnection module, and the task scheduling unit dynamically adjusts the parameters and processes the relevant interrupt request during work; If the functional interconnection module does not need to be controlled by the task scheduling unit, it will not be connected to the task scheduling unit. The function of the module is fixed when in use, and the parameters cannot be dynamically adjusted during operation.

4. A general software interface bus architecture based on a bus architecture, applied to the method according to any one of claims 1 to 3, characterized in that: The bus architecture operation platform is an FPGA or a fusion programmable SOC platform integrating FPGA and CPU. The unit modules included in the bus architecture in the method are: a task scheduling unit, a cross-connection module and a plurality of functional interconnection modules; Wherein, the task scheduling unit is connected to the cross interconnection module via a central interconnection bus, and each functional interconnection module is connected in parallel and respectively connected to the cross interconnection module; The task scheduling unit is used to manage the cross-connection module, the bus status of each functional interconnection module, and interrupt requests, and perform module configuration and task scheduling; The cross-connection module is used to realize bus interconnection and data interaction between the task scheduling unit and each functional interconnection module; Each functional interconnection module is divided into a parameter configuration area and a function implementation area. The parameter configuration area is used to obtain data from various peripherals and perform communication control, and configure module parameters through the task scheduling unit; the function implementation area is used to process the input data stream and output the processed data to the bus.

5. The bus architecture according to claim 4, characterized in that: The task scheduling unit is implemented by a soft-core MCU or a hard-core CPU; The software types of functional interconnection modules include: data processing, control and interface.

6. The bus architecture according to claim 4, characterized in that: The functional interconnection module forms a parameter control area for the parameterizable part according to the processing requirements, connects it to the low-speed bus of the CPU, and performs update control on a small amount of data; A high-speed bus is used to perform real-time processing of large amounts of data on data streams that require high-speed processing.

7. The bus architecture according to claim 8, characterized in that: The functional interconnection module determines whether to connect the functional modules to the CPU control bus according to the processing requirements of each module, updates the working parameters of each module through the low-speed bus or makes it work in an independent mode to achieve the commonality of each module.

8. The bus architecture according to claim 7, characterized in that: The functional interconnection module processes the data stream in the form of data packets. The processing delay of each functional interconnection module is accurate to the clock number level according to different algorithms, and the delay is fixed after the parameter configuration is completed.

9. The bus architecture according to claim 8, characterized in that: The task scheduling unit is specifically used to: when multiple modules work together, adjust the interrupt request of each functional interconnection module according to the priority; The startup sequence of each functional interconnection module can also be flexibly configured through the CPU.

10. The bus architecture according to claim 9, characterized in that: The cross-connection module is used to realize the connection of multi-channel bus data, and finally summarize them on the control and communication bus of the task scheduling unit to realize the functional interconnection between the task scheduling unit and various functional interconnection modules.