A DSP virtualization system and method based on dynamic loading and redirection technology

Abstract

The application discloses a DSP virtualization system and method based on dynamic loading and redirection technology, and the system is realized by cooperation of a HOST side running on a host and a DSP side running on a DSP. The DSP side comprises a DSP firmware module, and the HOST side comprises a DSP Lib module, a vDSP Manager module and a vDSP Lib module. The application realizes concurrent use of single DSP resources by multiple users through the DSP virtualization system, solves the problem that DSP can only be developed and used by a single user, and achieves the purpose of improving the utilization rate of DSP resources. For CPU-DSP collaborative application, a user can flexibly support new DSP API calling requests in a CPU-DSP application program through DSP function blueprint extension and vDSP Lib module extension.

Description

Technical Field

[0001] This invention belongs to the field of virtualization technology, specifically, it relates to a DSP virtualization system and method based on dynamic loading and redirection technology, which can be used in HPC, edge computing, cloud computing and other fields. Background Technology

[0002] With the support for heterogeneous computing resources in emerging businesses such as edge computing and artificial intelligence, cloud computing infrastructure is clearly unprepared. Both IaaS and PaaS platforms are still mainly geared towards general-purpose computing resources, primarily CPUs. Meanwhile, heterogeneous computing resources, represented by FPGAs and GPUs, are being integrated into cloud computing through virtualization methods such as vCUDA and Overlay. However, DSP heterogeneous resource virtualization is still not supported.

[0003] In the traditional DSP development model, users typically use a DSP integrated development environment (IDE) for program design and development, and then use a specific firmware flashing tool to flash the DSP program onto the DSP, ultimately generating a runnable DSP image. The main drawback of this development model is that the DSP can only be developed and used by a single user, regardless of the application scenario or the type of DSP product. For an application with low resource requirements and that does not need continuous operation, most of the DSP's hardware resources will be idle for most of the time, making it difficult to fully utilize the DSP within a given time and space. Summary of the Invention

[0004] One of the objectives of this invention is to provide a DSP virtualization system based on dynamic loading and redirection technology, which enables multiple users to concurrently use a single DSP resource through DSP virtualization, solving the problem that in the prior art, a DSP can only be developed and used by a single user, thereby improving the utilization rate of DSP resources.

[0005] To achieve the above objectives, the technical solution adopted by the present invention is as follows:

[0006] A DSP virtualization system based on dynamic loading and redirection technology is implemented through collaborative work between the HOST side running on the host and the DSP side running on the DSP. The DSP side includes a DSP firmware module, and the HOST side includes a DSP Lib module, a vDSP Manager module, and a vDSP Lib module, wherein:

[0007] Multiple vDSP Lib modules are configured. Each vDSP Lib module is used to intercept DSP API call requests in the CPU-DSP application and redirect them to the vDSP Manager module; it is also used to receive the processing results returned by the vDSP Manager module and pass them to the CPU-DSP application.

[0008] The vDSP Manager module is used to receive multiple DSP API call requests that have been redirected by the vDSP Lib module, serialize all DSP API call requests, and pass the DSP API call requests in the sequence to the DSPLib module one by one; it is also used to receive the processing results returned by the DSP Lib module and pass them to the corresponding vDSP Lib module.

[0009] The DSP Lib module is used to receive DSP API call requests sent by the vDSP Manager module and pass the DSP API call requests to the DSP firmware module; it is also used to receive the processing results returned by the DSP firmware module and pass them to the vDSP Manager module.

[0010] The DSP firmware module is used to control the DSP to dynamically load processing functions to process the DSP API call request and complete the DSP service according to the DSP API call request sent by the DSP Lib module, and return the processing result corresponding to the DSP API call request to the DSP Lib module.

[0011] Several alternative methods are provided below, but they are not intended as additional limitations on the overall solution above. They are merely further additions or optimizations. Provided there are no technical or logical contradictions, each alternative method can be combined individually with respect to the overall solution above, or multiple alternative methods can be combined with each other.

[0012] Preferably, the DSP firmware module includes a DSP static logic unit, a DSP function blueprint, an input data area, and an output data area. The DSP function blueprint includes multiple DSP processing functions. The DSP firmware module, based on the DSP API call requests sent by the DSPLib module, controls the DSP to dynamically load processing functions to process the DSP API call requests and complete DSP services, including:

[0013] The DSP static logic unit is used to move the corresponding processing function from the DSP function blueprint to the DSP's internal RAM according to the DSP API call request sent by the DSP Lib module;

[0014] The internal RAM of the DSP is used to execute the processing function. When the processing function is executed, it reads the data to be processed from the input data area, processes the data, and outputs the processing result, which is then stored in the output data area.

[0015] The DSP static logic unit is also used to read the corresponding processing result from the output data area and return it to the DSP Lib module after the processing function is executed.

[0016] Preferably, the deployment process of the DSP function blueprint is as follows:

[0017] For each processing function, copy parameters are generated by specifying CMD segments and mapping pragma to specified segments, and finally a DSP firmware image is generated. When the DSP firmware image starts running, the processing functions are written into the DSP's SDRAM to form a DSP function blueprint.

[0018] Preferably, the DSP static logic unit moves the corresponding processing function from the DSP function blueprint to the DSP's internal RAM, including:

[0019] The DSP static logic unit moves the code of the corresponding processing function from the DSP's SDRAM to the execution location on the DSP's internal RAM according to the DSP function blueprint and copy parameters.

[0020] Preferably, the DSP Lib module interacts with the DSP firmware module based on the DSP driver.

[0021] Preferably, the vDSP Manager module communicates with the vDSP Lib module using SOCKET in a server-client mode, with the vDSP Manager module acting as the server and the vDSP Lib module acting as the client.

[0022] Preferably, the vDSP Manager module runs execution threads and service threads;

[0023] A service thread interacts with a vDSP Lib module to receive DSP API call requests, convert the DSP API call requests into server-side data types, and send them to the execution thread; it also receives the processing results returned by the execution thread and passes them to the corresponding vDSP Lib module.

[0024] An execution thread interacts with a DSP Lib module to serialize DSP API call requests sent by various service threads and pass the DSP API call requests in the sequence to the DSP Lib module one by one; it is also used to receive the processing results returned by the DSP Lib module and pass them to the corresponding service thread.

[0025] The DSP virtualization system based on dynamic loading and redirection technology provided by this invention has the following advantages compared with the prior art:

[0026] (1) Improve DSP resource utilization: This invention enables multiple users to use a single DSP resource concurrently through a DSP virtualization system, solving the problem that DSP can only be developed and used by a single user, thereby improving the utilization of DSP resources.

[0027] (2) CPU-DSP application development is easy to extend: For CPU-DSP collaborative applications, users can easily extend the DSP function blueprint and vDSP Lib module to flexibly support new DSP API call requests in CPU-DSP applications.

[0028] The second objective of this invention is to provide a DSP virtualization method based on dynamic loading and redirection technology. This method enables multiple users to concurrently use a single DSP resource through DSP virtualization, solving the problem that in the prior art, a DSP can only be developed and used by a single user, thereby improving the utilization rate of DSP resources.

[0029] To achieve the above objectives, the technical solution adopted by the present invention is as follows:

[0030] A DSP virtualization method based on dynamic loading and redirection technology, implemented based on the aforementioned DSP virtualization system based on dynamic loading and redirection technology, the DSP virtualization method based on dynamic loading and redirection technology includes:

[0031] Each of the multiple vDSP Lib modules intercepts DSP API call requests in the CPU-DSP application and redirects them to the vDSP Manager module;

[0032] The vDSP Manager module receives multiple DSP API call requests that have been redirected by the vDSP Lib module, serializes all DSP API call requests, and passes each DSP API call request in the sequence to the DSP Lib module.

[0033] The DSP Lib module receives DSP API call requests sent by the vDSP Manager module and passes the DSP API call requests to the DSP firmware module;

[0034] The DSP firmware module controls the DSP to dynamically load processing functions to process the DSP API call request and complete the DSP service based on the DSP API call request sent by the DSP Lib module, and returns the processing result corresponding to the DSP API call request to the DSP Lib module.

[0035] The DSP Lib module receives the processing result returned by the DSP firmware module and passes it to the vDSPManager module;

[0036] The vDSP Manager module receives the processing result returned by the DSP Lib module and passes it to the corresponding vDSP Lib module;

[0037] The vDSP Lib module receives the processing results returned by the vDSP Manager module and passes them to the CPU-DSP application.

[0038] Preferably, the DSP firmware module includes a DSP static logic unit, a DSP function blueprint, an input data area, and an output data area. The DSP function blueprint includes multiple DSP processing functions. Based on the DSP API call request sent by the DSPLib module, the DSP firmware module controls the DSP to dynamically load processing functions to process the DSP API call request, complete the DSP service, and return the processing result corresponding to the DSP API call request to the DSPLib module, including:

[0039] The DSP static logic unit moves the corresponding processing function from the DSP function blueprint to the DSP's internal RAM according to the DSP API call request sent by the DSP Lib module;

[0040] The DSP's internal RAM executes the processing function. When the processing function is executed, it reads the data to be processed from the input data area, processes the data, and outputs the processing result, which is then stored in the output data area.

[0041] After the processing function is executed, the DSP static logic unit reads the corresponding processing result from the output data area and returns it to the DSP Lib module.

[0042] Preferably, the vDSP Manager module runs execution threads and service threads, with one service thread interacting with one vDSP Lib module and one execution thread interacting with one DSP Lib module;

[0043] The vDSP Manager module receives multiple DSP API call requests that have been redirected by the vDSP Lib module, serializes all DSP API call requests, and passes each DSP API call request in the sequence to the DSP Lib module, including:

[0044] The service thread receives DSP API call requests, converts the DSP API call requests into server-side data types, and sends them to the execution thread.

[0045] The execution thread serializes the DSP API call requests sent by each service thread and passes the DSP API call requests in the sequence to the DSP Lib module one by one;

[0046] The vDSP Manager module receives the processing result returned by the DSP Lib module and passes it to the corresponding vDSP Lib module, including:

[0047] The execution thread receives the processing result returned by the DSP Lib module and passes it to the corresponding service thread;

[0048] The service thread receives the processing result returned by the execution thread and passes it to the corresponding vDSP Lib module for interaction.

[0049] The DSP virtualization method based on dynamic loading and redirection technology provided by this invention has the following advantages compared with the prior art:

[0050] (1) Improve DSP resource utilization: This invention enables multiple users to use a single DSP resource concurrently through DSP virtualization, solving the problem that DSP can only be developed and used by a single user, and thus improving the utilization of DSP resources.

[0051] (2) CPU-DSP application development is easy to extend: For CPU-DSP collaborative applications, users can easily extend the DSP function blueprint and vDSP Lib module to flexibly support new DSP API call requests in CPU-DSP applications. Attached Figure Description

[0052] Figure 1 This is a schematic diagram of the DSP virtualization system based on dynamic loading and redirection technology of the present invention;

[0053] Figure 2 This is a schematic diagram of the multiplexing model of the present invention;

[0054] Figure 3This is a schematic diagram illustrating the dynamic loading of the processing function in this invention. Detailed Implementation

[0055] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0056] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains. The terminology used herein in the description of the invention is for the purpose of describing particular embodiments only and is not intended to limit the invention.

[0057] To address the problem in existing technologies that allow DSPs to be developed and used only by a single user, this embodiment proposes a DSP virtualization system based on dynamic loading and redirection technology. This system employs a layered architecture, achieving this through collaborative work between the host-side (HOST) and DSP-side (DSP). For example... Figure 1 As shown, the system specifically includes a DSP firmware module on the DSP side and a DSP Driver, DSP Lib module, vDSP Manager module, and vDSP Lib module on the HOST side.

[0058] A. vDSP Lib module on the HOST side

[0059] The vDSP Lib module is used to enable DSP application logic in CPU-DSP applications to access and use DSP resources. It registers itself with the vDSP Manager module as a replacement for the DSP Lib library.

[0060] In this embodiment, the system has multiple vDSP Lib modules. Each vDSP Lib module is used to intercept DSP API call requests in the CPU-DSP application and redirect them to the vDSP Manager module; it is also used to receive the processing results returned by the vDSPManager module and pass them to the CPU-DSP application.

[0061] B. vDSP Manager module on the HOST side

[0062] The vDSP Manager module communicates with the vDSP Lib module using a SOCKET in a server-client model, with the vDSP Manager module acting as the server and the vDSP Lib module as the client. The vDSP Manager module spawns threads to manage DSP devices and respond to DSP API call requests from the vDSP Lib module.

[0063] The vDSP Manager module in this embodiment is used to receive multiple DSP API call requests that have been redirected by the vDSP Lib module, serialize all DSP API call requests, and pass the DSP API call requests in the sequence to the DSP Lib module one by one; it is also used to receive the processing results returned by the DSP Lib module and pass them to the corresponding vDSP Lib module.

[0064] In this embodiment, a one-to-many multiplexing model is designed in the virtualization system to multiplex DSP devices in multiple user applications. For example... Figure 2 The diagram shows a one-to-many multiplexing model.

[0065] In this multiplexing model, the vDSP Manager module runs two different threads: the execution thread and the service thread.

[0066] One service thread interacts with one vDSP Lib module, and one service thread corresponds to one CPU-DSP application waiting for DSP services. This thread is used to receive DSP API call requests, convert the DSP API call requests into server-side data types and send them to the execution thread; it is also used to receive the processing results returned by the execution thread and pass them to the corresponding vDSP Lib module.

[0067] Each execution thread interacts with one DSP Lib module, meaning each execution thread corresponds to a physical DSP device. This thread serializes the DSP API call requests sent by each service thread and passes each request in the sequence to the DSP Lib module to manipulate the DSP device and complete the DSP task. It also receives the processing results returned by the DSP Lib module and passes them to the corresponding service thread. Specifically, when an execution thread completes its task, the service thread collects the results and transmits them to the corresponding vDSP Lib module as the return value.

[0068] Under the coordination of the vDSP Manager module, two or more different service threads can work together to operate a DSP hardware resource by connecting to an execution thread. The execution thread is responsible for serializing all requests in the service thread and executing them one by one through calls to the DSP Lib module in the real physical machine.

[0069] C. DSP Lib module on the HOST side

[0070] The DSP Lib module is designed and developed based on the DSP driver; that is, the DSP Lib module interacts with the DSP firmware module based on the DSP driver. The DSP device acts as a PCIe slave device of the host, and the PCIe driver for the DSP is implemented on the host side. Through the PCIe driver, DSP resources can be accessed and managed.

[0071] The DSP Lib module establishes the interaction and control channel between the upper-layer host and the physical DSP. It primarily includes functions such as DSP initialization, message / data interaction, and status monitoring, and provides a series of DSP API programming interfaces. These programming interfaces are invoked in the worker thread of the vDSPManager module, serving as the sole channel for interaction between the upper-layer application and the physical DSP.

[0072] Therefore, the DSP Lib module in this embodiment is mainly used to receive DSP API call requests sent by the vDSP Manager module and pass the DSP API call requests to the DSP firmware module; it is also used to receive the processing results returned by the DSP firmware module and pass them to the vDSP Manager module.

[0073] It is easy to understand that the DSP Lib module also has functions such as DSP initialization and status monitoring, which are used to initialize the DSP or monitor the connection status with the DSP. These functions are called and implemented by the host through the interface provided by the DSP Lib module. They are routine functions in the use of DSP resources and are not the focus of this application, so they will not be described in detail.

[0074] D. DSP firmware module on the DSP side

[0075] The DSP firmware module is mainly used to control the DSP to dynamically load processing functions to process DSP API call requests and complete DSP services based on DSP API call requests sent by the DSP Lib module, and return the processing results corresponding to the DSP API call requests to the DSP Lib module.

[0076] In the DSP development environment, a DSP firmware project is established for the design and development of the DSP firmware. Based on the principle of separating user DSP tasks from statically formatted components, the entire logic of the DSP firmware module is divided into DSP static logic units, DSP function blueprints, and IN / OUT data areas (input data area and output data area).

[0077] 1) DSP Static Logic Unit

[0078] The DSP static logic unit mainly implements basic functions such as DSP device initialization, status monitoring and heartbeat monitoring between the DSP and the host, message transmission, and data transmission and reception. It also dynamically loads the corresponding processing functions in the DSP function blueprint according to the DSP API call request from the host.

[0079] 2) DSP Function Blueprint

[0080] In DSP firmware development, the use of CMD file segment specification and pragma to map DSP processing functions to specified segments supports moving code from FLASH or external SDRAM to internal RAM for execution, achieving dynamic code loading while improving running speed.

[0081] In the DSP development environment, all the processing functions required by the DSP can be integrated into the DSP firmware project. For each processing function, copy parameters are generated by specifying CMD segments and mapping pragma to specified segments, including their respective load addresses, runtime addresses, function code lengths, etc., and finally, a DSP firmware image is generated. When the DSP firmware image starts running, copies of different processing functions are written into the DSP's SDRAM, forming the DSP function blueprint.

[0082] like Figure 3 As shown, when a DSP API call request is received from the HOST side, and the corresponding DSP processing function (e.g., Func_1, Func_2, ..., Func_N) is invoked, the DSP static logic unit moves the function code from SDRAM to the execution location in the DSP's internal RAM according to the DSP function blueprint and copy parameters, and then executes it at high speed in the internal RAM. After execution is complete, the result is stored in the output data area, waiting for the arrival of a new DSP call request.

[0083] 3) IN / OUT data area

[0084] IN / OUT data is used to store the input and output data of DSP processing functions. When a processing function in the DSP function blueprint is called and executed, it first reads the data to be processed from the input data area, and after completing the data processing, stores the processing result in the output data area.

[0085] Therefore, the DSP firmware module of this application, when executing the DSP API call request sent by the DSP Lib module, controls the DSP to dynamically load the processing function to process the DSP API call request and complete the DSP service, performs the following operations:

[0086] The DSP static logic unit is used to move the corresponding processing function from the DSP function blueprint to the DSP's internal RAM according to the DSP API call request sent by the DSP Lib module. The DSP's internal RAM is used to execute the processing function. When the processing function is executed, it reads the data to be processed from the input data area, processes the data, and outputs the processing result, which is stored in the output data area. The DSP static logic unit is also used to read the corresponding processing result from the output data area and return it to the DSP Lib module after the processing function has been executed.

[0087] In the virtualization system of this embodiment, for the DSP design and implementation portion of each CPU-DSP application, the user can complete it on the HOST side through the interface call of the vDSP Lib module. The vDSPLib module in each CPU-DSP application issues DSP API call requests externally. The vDSP Manager module receives call requests from multiple users and intercepts and redirects the vDSP Lib API, sending requests to the real DSP by calling the local DSP Lib module. After receiving the request, the DSP side dynamically loads the corresponding DSP API call request through functions, obtains user data from the HOST side from the input data area, processes the data, and stores the processing results in the output data area for use by the HOST side user. This enables concurrent use of a single DSP resource by multiple users, solving the problem in existing technologies where DSPs can only be developed and used by a single user, thereby improving DSP resource utilization.

[0088] In another embodiment, based on the aforementioned DSP virtualization system based on dynamic loading and redirection technology, a DSP virtualization method based on dynamic loading and redirection technology is implemented, specifically including the following steps:

[0089] Each of the multiple vDSP Lib modules intercepts DSP API call requests in the CPU-DSP application and redirects them to the vDSP Manager module;

[0090] The vDSP Manager module receives multiple DSP API call requests that have been redirected by the vDSP Lib module, serializes all DSP API call requests, and passes each DSP API call request in the sequence to the DSP Lib module.

[0091] The DSP Lib module receives DSP API call requests sent by the vDSP Manager module and passes the DSP API call requests to the DSP firmware module;

[0092] The DSP firmware module controls the DSP to dynamically load processing functions to process the DSP API call request and complete the DSP service based on the DSP API call request sent by the DSP Lib module, and returns the processing result corresponding to the DSP API call request to the DSP Lib module.

[0093] The DSP Lib module receives the processing result returned by the DSP firmware module and passes it to the vDSPManager module;

[0094] The vDSP Manager module receives the processing result returned by the DSP Lib module and passes it to the corresponding vDSP Lib module;

[0095] The vDSP Lib module receives the processing results returned by the vDSP Manager module and passes them to the CPU-DSP application.

[0096] In another embodiment, the DSP firmware module includes a DSP static logic unit, a DSP function blueprint, an input data area, and an output data area. The DSP function blueprint includes multiple DSP processing functions. Based on the DSP API call request sent by the DSP Lib module, the DSP firmware module controls the DSP to dynamically load processing functions to process the DSP API call request, complete the DSP service, and return the processing result corresponding to the DSP API call request to the DSP Lib module, including:

[0097] The DSP static logic unit moves the corresponding processing function from the DSP function blueprint to the DSP's internal RAM according to the DSP API call request sent by the DSP Lib module;

[0098] The DSP's internal RAM executes the processing function. When the processing function is executed, it reads the data to be processed from the input data area, processes the data, and outputs the processing result, which is then stored in the output data area.

[0099] After the processing function is executed, the DSP static logic unit reads the corresponding processing result from the output data area and returns it to the DSP Lib module.

[0100] In another embodiment, the vDSP Manager module runs execution threads and service threads, with one service thread interacting with a vDSP Lib module and one execution thread interacting with a DSP Lib module;

[0101] The vDSP Manager module receives multiple DSP API call requests that have been redirected by the vDSP Lib module, serializes all DSP API call requests, and passes each DSP API call request in the sequence to the DSP Lib module, including:

[0102] The service thread receives DSP API call requests, converts the DSP API call requests into server-side data types, and sends them to the execution thread.

[0103] The execution thread serializes the DSP API call requests sent by each service thread and passes the DSP API call requests in the sequence to the DSP Lib module one by one;

[0104] The vDSP Manager module receives the processing result returned by the DSP Lib module and passes it to the corresponding vDSP Lib module, including:

[0105] The execution thread receives the processing result returned by the DSP Lib module and passes it to the corresponding service thread;

[0106] The service thread receives the processing result returned by the execution thread and passes it to the corresponding vDSP Lib module for interaction.

[0107] In another embodiment, the deployment process of the DSP function blueprint is as follows:

[0108] For each processing function, copy parameters are generated by specifying CMD segments and mapping pragma to specified segments, and finally a DSP firmware image is generated. When the DSP firmware image starts running, the processing functions are written into the DSP's SDRAM to form a DSP function blueprint.

[0109] In another embodiment, the DSP static logic unit moves the corresponding processing function from the DSP function blueprint to the DSP's internal RAM, including:

[0110] The DSP static logic unit moves the code of the corresponding processing function from the DSP's SDRAM to the execution location on the DSP's internal RAM according to the DSP function blueprint and copy parameters.

[0111] In another embodiment, the DSP Lib module interacts with the DSP firmware module based on the DSP driver.

[0112] In another embodiment, the vDSP Manager module communicates with the vDSP Lib module in a server-client mode using a SOCKET, with the vDSP Manager module acting as the server and the vDSP Lib module acting as the client.

[0113] For ease of understanding, in one embodiment, the overall workflow of implementing a multi-user CPU-DSP application using a DSP virtualization method is specifically described, mainly consisting of the following steps:

[0114] S1. When the CPU-DSP application needs to use DSP services, it issues a DSP API call request through the vDSP Lib module.

[0115] In the S2 vDSP Manager module, a service thread will be started to receive DSP API call requests, convert the DSP API call requests into a server-side representation, and then forward the DSP API call requests to the execution thread.

[0116] S3. Each execution thread corresponds to a physical DSP device. It obtains DSP functions and their parameters from the DSP API call requests sent by the service thread, serializes the DSP API call requests in the service thread, and converts them into calls to the programming interfaces in the DSP Lib module.

[0117] The S4 and DSP Lib modules communicate and interact with the DSP-side firmware through the DSP driver interface, passing DSP API call requests from the HOST side to the DSP firmware module.

[0118] S5. When the DSP firmware module receives a DSP API call request from the HOST side, the corresponding DSP processing function is called. The DSP static logic unit moves the code of the processing function according to the DSP function blueprint and copy parameters, copies it from SDRAM to the running location on the DSP's internal RAM, and then runs it at high speed in the internal RAM.

[0119] S6. In the DSP firmware, when the processing function in the DSP function blueprint is called and executed in the internal RAM, it first reads the data to be processed from the input data area, and after the data processing is completed, it stores the processing result in the output data area.

[0120] S7. When the DSP static logic unit detects that the DSP's processing function task has been completed, it retrieves the processing result from the output data area and passes it to the execution thread.

[0121] The execution thread in the S8 vDSP Manager module passes the processing results to the service thread.

[0122] The service thread in the S9 vDSP Manager module collects the results and transmits them to the corresponding vDSP Lib module as return results, which are then returned by the vDSP Lib module to the CPU-DSP application it serves.

[0123] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0124] The embodiments described above are merely illustrative of several implementations of the present invention, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of the invention. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of the present invention, and these modifications and improvements all fall within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the appended claims.

Claims

1. A DSP virtualization system based on dynamic loading and redirection technology, implemented through collaborative work between the HOST side running on the host and the DSP side running on the DSP, characterized in that, The DSP side includes a DSP firmware module, and the HOST side includes a DSP Lib module, a vDSP Manager module, and a vDSP Lib module, wherein: Multiple vDSP Lib modules are configured. Each vDSP Lib module is used to intercept DSP API call requests in the CPU-DSP application and redirect them to the vDSP Manager module; it is also used to receive the processing results returned by the vDSP Manager module and pass them to the CPU-DSP application. The vDSP Manager module is used to receive multiple DSP API call requests that have been redirected by the vDSP Lib module, serialize all DSP API call requests, and pass the DSP API call requests in the sequence to the DSP Lib module one by one; it is also used to receive the processing results returned by the DSP Lib module and pass them to the corresponding vDSP Lib module. The DSP Lib module is used to receive DSP API call requests sent by the vDSP Manager module and pass the DSP API call requests to the DSP firmware module; it is also used to receive the processing results returned by the DSP firmware module and pass them to the vDSP Manager module. The DSP firmware module is used to control the DSP to dynamically load processing functions to process the DSP API call request and complete the DSP service according to the DSP API call request sent by the DSP Lib module, and return the processing result corresponding to the DSP API call request to the DSP Lib module.

2. The DSP virtualization system based on dynamic loading and redirection technology as described in claim 1, characterized in that, The DSP firmware module includes a DSP static logic unit, a DSP function blueprint, an input data area, and an output data area. The DSP function blueprint includes multiple DSP processing functions. The DSP firmware module, based on the DSP API call requests sent by the DSP Lib module, controls the DSP to dynamically load processing functions to process the DSP API call requests and complete DSP services, including: The DSP static logic unit is used to move the corresponding processing function from the DSP function blueprint to the DSP's internal RAM according to the DSP API call request sent by the DSP Lib module; The internal RAM of the DSP is used to execute the processing function. When the processing function is executed, it reads the data to be processed from the input data area, processes the data, and outputs the processing result, which is then stored in the output data area. The DSP static logic unit is also used to read the corresponding processing result from the output data area and return it to the DSP Lib module after the processing function is executed.

3. The DSP virtualization system based on dynamic loading and redirection technology as described in claim 2, characterized in that, The deployment process of the DSP function blueprint is as follows: For each processing function, copy parameters are generated by specifying CMD segments and mapping pragma to specified segments, and finally a DSP firmware image is generated. When the DSP firmware image starts running, the processing functions are written into the DSP's SDRAM to form a DSP function blueprint.

4. The DSP virtualization system based on dynamic loading and redirection technology as described in claim 3, characterized in that, The DSP static logic unit moves the corresponding processing functions from the DSP function blueprint to the DSP's internal RAM, including: The DSP static logic unit moves the code of the corresponding processing function from the DSP's SDRAM to the execution location on the DSP's internal RAM according to the DSP function blueprint and copy parameters.

5. The DSP virtualization system based on dynamic loading and redirection technology as described in claim 1, characterized in that, The DSP Lib module interacts with the DSP firmware module based on the DSP driver.

6. The DSP virtualization system based on dynamic loading and redirection technology as described in claim 1, characterized in that, The vDSP Manager module communicates with the vDSP Lib module using SOCKET in a server-client mode, with the vDSP Manager module acting as the server and the vDSP Lib module acting as the client.

7. The DSP virtualization system based on dynamic loading and redirection technology as described in claim 1, characterized in that, The vDSP Manager module contains execution threads and service threads. A service thread interacts with a vDSP Lib module to receive DSP API call requests, convert the DSP API call requests into server-side data types, and send them to the execution thread; it also receives the processing results returned by the execution thread and passes them to the corresponding vDSP Lib module. An execution thread interacts with a DSP Lib module to serialize DSP API call requests sent by various service threads and pass the DSP API call requests in the sequence to the DSP Lib module one by one; It is also used to receive the processing results returned by the DSP Lib module and pass them to the corresponding service thread.

8. A DSP virtualization method based on dynamic loading and redirection technology, implemented based on the DSP virtualization system based on dynamic loading and redirection technology as described in claim 1, characterized in that, The DSP virtualization method based on dynamic loading and redirection technology includes: Each of the multiple vDSP Lib modules intercepts DSP API call requests in the CPU-DSP application and redirects them to the vDSP Manager module; The vDSP Manager module receives multiple DSP API call requests that have been redirected by the vDSP Lib module, serializes all DSP API call requests, and passes each DSP API call request in the sequence to the DSP Lib module. The DSP Lib module receives DSP API call requests sent by the vDSP Manager module and passes the DSP API call requests to the DSP firmware module; The DSP firmware module controls the DSP to dynamically load processing functions to process the DSP API call request and complete the DSP service based on the DSP API call request sent by the DSP Lib module, and returns the processing result corresponding to the DSP API call request to the DSP Lib module. The DSP Lib module receives the processing result returned by the DSP firmware module and passes it to the vDSP Manager module; The vDSP Manager module receives the processing result returned by the DSP Lib module and passes it to the corresponding vDSPLib module; The vDSP Lib module receives the processing results returned by the vDSP Manager module and passes them to the CPU-DSP application.

9. The DSP virtualization method based on dynamic loading and redirection technology as described in claim 8, characterized in that, The DSP firmware module includes a DSP static logic unit, a DSP function blueprint, an input data area, and an output data area. The DSP function blueprint includes multiple DSP processing functions. Based on the DSP API call requests sent by the DSP Lib module, the DSP firmware module controls the DSP to dynamically load processing functions to process the DSP API call requests, complete the DSP services, and return the processing results corresponding to the DSP API call requests to the DSP Lib module, including: The DSP static logic unit moves the corresponding processing function from the DSP function blueprint to the DSP's internal RAM according to the DSP API call request sent by the DSP Lib module; The DSP's internal RAM executes the processing function. When the processing function is executed, it reads the data to be processed from the input data area, processes the data, and outputs the processing result, which is then stored in the output data area. After the processing function is executed, the DSP static logic unit reads the corresponding processing result from the output data area and returns it to the DSP Lib module.

10. The DSP virtualization method based on dynamic loading and redirection technology as described in claim 8, characterized in that, The vDSP Manager module contains execution threads and service threads. One service thread interacts with one vDSP Lib module, and one execution thread interacts with one DSP Lib module. The vDSP Manager module receives multiple DSP API call requests that have been redirected by the vDSP Lib module, serializes all DSP API call requests, and passes each DSP API call request in the sequence to the DSP Lib module, including: The service thread receives DSP API call requests, converts the DSP API call requests into server-side data types, and sends them to the execution thread. The execution thread serializes the DSP API call requests sent by each service thread and passes the DSP API call requests in the sequence to the DSP Lib module one by one; The vDSP Manager module receives the processing result returned by the DSP Lib module and passes it to the corresponding vDSPLib module, including: The execution thread receives the processing result returned by the DSP Lib module and passes it to the corresponding service thread; The service thread receives the processing result returned by the execution thread and passes it to the corresponding vDSP Lib module for interaction.

Images