An SDK system and chip

Abstract

An SDK system and a chip, the SDK system adopts a dynamically reconfigurable architecture, comprising an API layer, a business API implementation layer, a function layer and a driver layer; the API layer comprises API interfaces of one or more subsystems to the outside, a general external interface and a public registration management module; the business API implementation layer comprises business APIs inside the subsystems and public processing APIs for public calling between the subsystems; the function layer comprises a general business management module, a public resource management module and a business function module of the subsystems; the driver layer is arranged to realize calling of the function layer to registers. Through the scheme of the embodiment, dynamic reconfiguration can be realized according to a business application scene, flexible deployment of products is supported, and resource utilization of the products is maximized.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and more specifically, to an SDK system and chip. Background Technology

[0002] With the development of national digitalization and new infrastructure, the ASIC chip industry has experienced explosive growth. To support the digital transformation of various industries, the use of ASIC chips is inseparable from the support of SDK software. By fully leveraging the business functions of ASIC, equipment manufacturers can save product development time, shorten product launch time, and quickly meet market demands.

[0003] Currently, most mainstream SDK software architectures employ static configuration methods for business logic. They abstract and encapsulate the operating system and hardware, configuring business logic from top to bottom, switching between different business processes, neglecting resource management, and lacking dynamic management of business and its corresponding resource attributes. This prevents flexible handling strategies such as dynamic allocation, loading, and unloading of business logic and its corresponding resources. The rapid development of businesses in the communications field, increasingly powerful product functions, and shorter iteration cycles have led to increasingly comprehensive business capabilities of ASIC chips. Since SDK software architecture essentially serves product development, it also needs to become increasingly flexible to adapt to changes in communication products and the communications market.

[0004] ASIC chips belong to different business areas, have varying functional complexities, and are used in different network scenarios. Therefore, their SDK architecture designs also differ. In particular, communication ASIC chips, which have high business integration and strong adaptability to various business scenarios, exhibit the following development trends in SDK software architecture design requirements: The SDK architecture needs to be flexible, easy to integrate and port, reducing the investment costs for product development personnel; business scenario-driven, with the SDK flexibly adapting to different business scenarios to facilitate the development, deployment, and maintenance of different system-level business functions, reducing maintenance costs throughout the product lifecycle; and compatibility and iteration, ensuring that the SDK architecture does not require a complete replacement due to ASIC chip upgrades, effectively supporting rapid product iteration. Summary of the Invention

[0005] The following is an overview of the subject matter described in detail herein. This overview is not intended to limit the scope of the claims.

[0006] To address the aforementioned technical problems, this disclosure provides an SDK system in one embodiment. The SDK system adopts a dynamically reconfigurable architecture, including an API layer, a business API implementation layer, a functional layer, and a driver layer, wherein:

[0007] The API layer includes API interfaces of one or more subsystems, general external interfaces, and a public registration management module. The public registration management module is configured to provide a public registration interface and dynamically open the API interfaces of the subsystems.

[0008] The business API implementation layer includes business APIs within the subsystem and common processing APIs for common calls between the subsystems;

[0009] The functional layer includes a general business management module, a public resource management module, and the business function modules of the subsystem. The general business management module is configured to manage the subsystem's use of the general business module, and the public resource module is configured to uniformly schedule the system resources used by the subsystem.

[0010] The driver layer is configured to enable the functional layer to call the registers.

[0011] One embodiment of this disclosure also provides a chip including an SDK system as described in any embodiment of this disclosure.

[0012] Compared with related technologies, the SDK system and chip provided in this disclosure provide a dynamic and reconfigurable SDK software architecture, changing the traditional "direct-drive static architecture" to a "reconfigurable dynamic architecture". This enhances the business dynamic loading and resource dynamic management attributes of the SDK system, maximizes the rational utilization of product resources, saves system resources, and the dynamic reconfiguration of business application scenarios can support the flexible deployment of products, improve flexibility, and reduce development and maintenance costs.

[0013] Other features and advantages of this disclosure will be set forth in the following description, and will be apparent in part from the description, or may be learned by practicing the disclosure. Other advantages of this disclosure may be realized and obtained by means of the methods described in the description and the accompanying drawings. Attached Figure Description

[0014] The accompanying drawings are used to provide an understanding of the technical solutions of this disclosure and form part of the specification. They are used together with the embodiments of this disclosure to explain the technical solutions of this disclosure and do not constitute a limitation on the technical solutions of this disclosure.

[0015] Figure 1 This is a schematic diagram of a business-driven SDK software architecture;

[0016] Figure 2 This is a schematic diagram of a dynamically reconfigurable SDK software architecture according to an embodiment of this disclosure;

[0017] Figure 3 This is a schematic diagram of a two-level reconstruction structure according to an embodiment of this disclosure;

[0018] Figure 4 This is a flowchart illustrating the operation of a dynamically reconfigurable SDK software architecture according to an embodiment of this disclosure. Detailed Implementation

[0019] This disclosure describes several embodiments, but these descriptions are exemplary and not limiting, and it will be apparent to those skilled in the art that many more embodiments and implementations are possible within the scope of the embodiments described herein. Although many possible combinations of features are shown in the drawings and discussed in the detailed description, many other combinations of the disclosed features are also possible. Unless specifically limited, any feature or element of any embodiment may be used in combination with, or may replace, any feature or element of any other embodiment.

[0020] This disclosure includes and contemplates combinations of features and elements known to those skilled in the art. The embodiments, features, and elements disclosed in this disclosure may also be combined with any conventional features or elements to form a unique inventive scheme as defined by the claims. Any feature or element of any embodiment may also be combined with features or elements from other inventive schemes to form another unique inventive scheme as defined by the claims. Therefore, it should be understood that any feature shown and / or discussed in this disclosure may be implemented individually or in any suitable combination. Therefore, the embodiments are not limited except by the limitations imposed by the appended claims and their equivalents. Furthermore, various modifications and changes may be made within the scope of the appended claims.

[0021] The software architecture of ASIC chips for communication services typically adopts a static design scheme with direct service drivers. Figure 1 See the diagram for a business-driven SDK software architecture. Figure 1 UAL (User Adaptation Layer) and CHIPSET HARDWARE (chipset hardware) fall outside the scope of the user system architecture. The general SDK architecture includes:

[0022] The API layer, which is the part of the SDK that exposes its business logic, is used for direct calls when configuring UAL functions;

[0023] The business API implementation layer is the internal interface of the ASIC chip to implement a specific business. The business API and the UAL at the lower levels cannot be called directly and belong to the kernel of the SDK.

[0024] The functional layer, which is the logical implementation of all business functions supported by the ASIC chip, corresponds to all business functions integrated by the ASIC. As the functions of the ASIC become more and more complex, the implementation logic becomes more and more complex.

[0025] The driver layer, namely the register driver layer of the ASIC chip, facilitates the functional layer's access to the underlying registers and serves the functional layer.

[0026] The System Adaptation Layer (SAL) facilitates the use of different operating systems by the functional layers, thus providing services to the functional layers.

[0027] The Driver Adaptation Layer (DAL) facilitates the use of different hardware devices by the functional layer, such as unifying various bus access drivers to serve the functional layer.

[0028] The APP implementation provides examples of specific functions, enabling developers to quickly familiarize themselves with the business functions of the SDK and ASIC chip.

[0029] Figure 1 The SDK architecture shown involves an upper-layer user interface outside the SDK system calling corresponding SDK API interfaces to perform business control configuration based on business needs. This configuration is then distributed to the ASIC chip registers through underlying hardware-independent abstraction and encapsulation to complete the business function configuration. The key is the functional layer; the API layer and business API implementations are for use within the functional layer, while the driver layer, SAL, and DAL provide common support for the functional layer. For SDK software users, business configuration proceeds from top to bottom, initiating calls through the UAL, layer by layer, until reaching the ASIC chip hardware.

[0030] As the functionality of communication ASIC chips becomes increasingly complex, the corresponding product application scenarios are also becoming more and more intricate. Figure 1 The architecture shown has the following drawbacks:

[0031] The system resources behind the business functions are not dynamically managed, resulting in serious waste of system resources (such as memory, CPU thread processing, etc.). The system resources have high requirements for the specifications of the core components corresponding to the product, which increases the product cost.

[0032] Business functions cannot be dynamically loaded, unloaded, or reloaded according to application scenarios. Users need to compile different software versions according to different scenarios, which increases the product's operation and maintenance costs.

[0033] There are a large number of resource calls and logic processing that are not used in business scenarios, which introduces the risk of usage errors to developers from the perspective of code maintenance and fault debugging, and reduces the stability of product operation.

[0034] Therefore, one embodiment of this disclosure provides an SDK system that adopts a dynamically reconfigurable architecture. Figure 1 A schematic diagram of the dynamically reconfigurable SDK software architecture according to an embodiment of this application is shown below. Figure 2 As shown, it includes an API layer, a business API implementation layer, a function layer, and a driver layer, wherein:

[0035] The API layer includes API interfaces of one or more subsystems, general external interfaces, and a public registration management module. The public registration management module is configured to provide a public registration interface and dynamically open the API interfaces of the subsystems.

[0036] The business API implementation layer includes business APIs within the subsystem and common processing APIs for common calls between the subsystems;

[0037] The functional layer includes a general business management module, a public resource management module, and the business function modules of the subsystem. The general business management module is configured to manage the subsystem's use of the general business module, and the public resource module is configured to uniformly schedule the system resources used by the subsystem.

[0038] The driver layer is configured to enable the functional layer to call the registers and serve the functional layer.

[0039] Compared with this embodiment Figure 1 The business-driven SDK software architecture shown further subdivides the layers related to business processing. At the same time, it creatively adds dynamic management attributes for business scenarios horizontally, allowing the SDK system to be flexibly restructured according to business scenarios, achieving elastic processing of "one system for multiple business scenarios".

[0040] In an exemplary embodiment of this disclosure, the public registration management module provides a public registration interface to dynamically open the API interface of the subsystem, including: registering the general external interface to the outside after initialization; and, upon receiving an instruction input through the general external interface, if it is determined that the first subsystem needs to be deployed, loading the API interface of the first subsystem and connecting it with the business API inside the subsystem to open the loaded API interface to external calls, and notifying the first subsystem of the functional layer to perform initialization;

[0041] The functional layer also includes an initialization module for each of the subsystems. The initialization module of the first subsystem is configured to initialize the business function module of the first subsystem after receiving an initialization notification, and apply for system resources from the public resource management module through the inter-subsystem interface.

[0042] The public resource management module uniformly schedules the use of system resources by the subsystem, including: after receiving the application for system resources from the first subsystem, applying for system resources for the business function modules of the first subsystem, and managing the system information of the business function modules of the first subsystem.

[0043] In one example of this embodiment, the initialization module is further configured to, upon receiving an initialization notification, apply to the general business management module for registration of general business functions through the inter-subsystem interface;

[0044] The general business management module manages the use of the general business module by the subsystem, including: managing general business functions, and registering the general business functions for the first subsystem after receiving a registration application for the general business functions from the first subsystem.

[0045] In one example of this embodiment, the general business management module registers general business functions for the first subsystem, including one or more of the following processes:

[0046] Register and apply for general business functions for the first subsystem;

[0047] Set the priority for the first subsystem to use the general business functions;

[0048] The logic for the first subsystem to preempt the general business function is handled.

[0049] In one example of this embodiment, the public registration management module dynamically opens the API interface of the subsystem, and further includes: after receiving the instruction input through the general external interface, if it is determined that the second subsystem needs to be uninstalled, the API interface of the second subsystem is uninstalled and no longer opened to external calls, and the second subsystem of the functional layer is notified to perform the emptying process.

[0050] The functional layer also includes an empty interface module for each of the subsystems. After receiving the empty processing notification, the empty interface module of the second subsystem cancels the business function module of the second subsystem and applies to the public resource management module to cancel system resources through the inter-subsystem interface.

[0051] The public resource management module, which uniformly schedules the system resources used by the subsystem, also includes: upon receiving a request from the second subsystem to cancel system resources, releasing the system resources occupied by the business function modules of the second subsystem.

[0052] After the second subsystem in this example performs the empty handling, all the processing APIs of the second subsystem will be canceled, that is, the APIs will be assigned NULL values.

[0053] In one example of this embodiment, the empty interface module is further configured to apply to the general business management module to cancel the general business function after receiving the notification of empty processing;

[0054] The general business management module manages the use of the general business module by the subsystem, and also includes: after receiving the cancellation application of the second subsystem for the general business function, canceling the use of the general business function by the second subsystem.

[0055] In one example of this embodiment, after receiving the instruction input through the general external interface, the public registration management module determines that a first subsystem needs to be deployed, including: after receiving the instruction to deploy a specified business function, searching for the correspondence between the business function and the subsystem, and determining the subsystem corresponding to the specified business function as the first subsystem to be deployed.

[0056] In one example of this embodiment, the API interface of the subsystem dynamically opened by the public registration management module includes parameters, which include parameters of each subsystem. The dynamically reconfigurable SDK software architecture can control whether the subsystems migrate or overlap according to the API interface parameters.

[0057] When the relationship between subsystems is migration (i.e. when different business scenarios are switched), the loading and unloading order of subsystems can be controlled according to API interface parameters. Specifically, for example, in the dynamic reconstruction process, the API interface parameters can be used to control whether the subsystem of the business scenario to be uninstalled is uninstalled first and then the subsystem of the business scenario to be deployed is loaded, or the subsystem of the business scenario to be deployed is loaded first and then the subsystem of the business scenario to be uninstalled is uninstalled.

[0058] When the relationship between subsystems is superimposed, users can choose not to dynamically uninstall subsystems and directly deploy new systems.

[0059] In one example of this embodiment, when the dynamically reconfigurable SDK software architecture is migrated in different scenarios, the order of deployment of the subsystem to be deployed and uninstallation of the subsystem to be uninstalled can be controlled according to the order of deployment and uninstallation instructions input by the user; and the input instructions and uninstallation instructions can be one instruction controlling two operations, or they can be two separate instructions.

[0060] In one example of this embodiment, the dynamically reconfigurable SDK software architecture also allows users to manually uninstall subsystems, that is, users can directly call the uninstallation interface API of the API layer to uninstall subsystems, and manual uninstallation has a higher priority than dynamic uninstallation.

[0061] The dynamically reconfigurable SDK software architecture described in this embodiment allows for the existence of only one business scenario or multiple business scenarios simultaneously. Furthermore, users can flexibly control whether scenarios are migrated or superimposed, as well as the order and method of scenario deployment and uninstallation.

[0062] In one example of this embodiment, the public resource management module can uniformly manage the system-level resources used by each subsystem, including memory management, task management, semaphore management, log management, etc., and can also provide the SDK users with information on the usage of system-level resources.

[0063] In an exemplary embodiment of this disclosure, the business API implementation layer further includes a resource reloading module, which is configured to: after determining that the public resource management module releases the system resources occupied by the business function module of the second subsystem, save the system information of the second subsystem according to the system configuration;

[0064] It should be noted that saving the system information of the second subsystem is optional and depends on user needs: When saving the system information of the second subsystem is selected, after the public resource management module determines that the system resources occupied by the business function modules of the second subsystem are released, the public resource management module can notify the resource reload module through the mutual interface. After the resource reload module determines the system resources occupied by the second subsystem, it saves the system information of the second subsystem according to the system configuration; when not saving the system information of the second subsystem is selected, after the public resource management module determines that the system resources occupied by the business function modules of the second subsystem are released, the system information of the second subsystem can be released directly.

[0065] The system information includes any one or more of the following: memory information, task information, semaphore information, and log information.

[0066] In an exemplary embodiment of this disclosure, the driver layer includes a subsystem submodule support verification module and a business-independent general processing interface;

[0067] The subsystem submodule support verification module is set to verify the deployment status of the subsystem, allowing deployed subsystems to access the underlying registers and prohibiting undeployed subsystems from accessing the underlying registers.

[0068] The business-independent general processing interface is configured to provide an interface that is independent of business logic.

[0069] In this embodiment, the driver layer dynamically opens the services of the deployed subsystems to the external user agent layer (UAL). For drivers corresponding to services that are not opened, calls will be prohibited to prevent misuse of the function layer and reduce the risk of ASIC chip operation.

[0070] In an exemplary embodiment of this disclosure, the API layer further includes an internal debugging external interface, which is configured to receive internal debugging instructions;

[0071] The business API implementation layer also includes an internal debugging channel, which is configured to directly transmit the internal debugging command to the driver layer after receiving the internal debugging command input from the internal debugging external interface.

[0072] The driver layer also includes an internal debugging channel, which is configured to read registers according to the internal debugging instructions to perform debugging and directly locate chip-level problems.

[0073] This embodiment designs an internal debugging channel as a VIP green channel, allowing direct access from the API layer to the driver layer to manipulate registers, bypassing the functional layer. This solves the problem of top-down, layer-by-layer calls in the SDK architecture, which prevents cross-layer calls and the inability to access business functions not exposed to external UAL. It can be applied to scenarios requiring cross-layer access and is a high-level processing method, but its use is not recommended in normal applications. For example, during internal debugging, internal developers can use this internal debugging channel to locate problems.

[0074] In an exemplary embodiment of this disclosure, the SDK system further includes:

[0075] SAL (System Adaptation Layer) facilitates the use of different operating systems by the functional layer, thus serving the functional layer.

[0076] The DAL (Drive Adaptation Layer) facilitates the use of different hardware devices by the functional layer, ensuring a unified driver that serves the functional layer.

[0077] The APP implementation provides examples of specific functions, enabling developers to quickly familiarize themselves with the business functions of the SDK and ASIC chip.

[0078] In one exemplary embodiment of this disclosure, the SDK system is applied to an integrated circuit, which may be an ASIC chip, but is not limited to an ASIC chip;

[0079] The API interfaces, business APIs, and business function modules of the subsystems are built based on business application scenarios, and different subsystems correspond to different business application scenarios.

[0080] It should be noted that the SDK system disclosed herein can be applied to, but is not limited to, ASIC chips. The embodiments disclosed herein are only used to illustrate the SDK system based on ASIC chips.

[0081] In summary, the functional layer described in this embodiment, that is, the logical implementation of all business functions supported by the ASIC chip, corresponds to all business functions of the ASIC. When the subsystem is initialized, it will apply to the public resource management module for the required system-level resources and register to request unified management of these system resources.

[0082] If the implementation of a subsystem's business functions involves the use of a general business module, it will register with the general business management module to ensure that the general business management module manages its use. When other subsystems also use the general business management module, the usage priority strategy of each subsystem will be flexibly arranged.

[0083] The general business management module and public resource management module of the functional layer can be regarded as two "internal stewards" of the SDK system, one responsible for general business functions and the other responsible for public system-level resources.

[0084] Furthermore, the API layer, i.e., the part of the SDK that exposes its business logic, is directly called during UAL configuration. The design concept of the public registration management module of the API layer in this embodiment is to classify the external API interfaces according to subsystems based on the requirements of a dynamically reconfigurable SDK software architecture. Common parts between subsystems are extracted and provided separately, offering a public registration interface that dynamically exposes the APIs of different subsystems to the external UAL layer. This public registration management module can be considered an "external steward" for the SDK system's external business functions.

[0085] The following example illustrates the process of "secondary refactoring" of the dynamically reconfigurable SDK software architecture:

[0086] In an exemplary embodiment of this disclosure, the public registration management module acts as an "external steward," while the general business management module and public resource management module of the functional layer act as two "internal stewards." Depending on the business deployment scenario, they cooperate to achieve dynamic reconfigurability of the SDK software. See also... Figure 3 When business deployment scenarios change, and users input these changes into the SDK system through configuration, the system will automatically complete the following "secondary refactoring" process:

[0087] When the "External Manager" receives this input from outside the SDK system, it dynamically opens the API interface corresponding to the new business scenario to the external UAL, dynamically loads the interface, closes the API interface of the original business scenario, and dynamically unloads the interface. This achieves the reconstruction of the first level of external APIs, ensuring that SDK software users can use the API interface of the new business scenario without realizing it, and do not need to pay attention to the status of the API interface of the original business scenario.

[0088] The "Internal Steward" has two main functions: First, it dynamically manages the usage of corresponding business scenarios within general business functions, releasing the resources occupied by the original business scenarios and eliminating the need for complex logic checks during business calls. Second, it dynamically allocates the required system resources based on corresponding new business scenarios, releasing the system-level resources of the original business scenarios, thereby saving system-level resources and improving the performance of the SDK system. Therefore, the "Internal Steward" implements a second-level refactoring of the second-level business function implementation on both general business functions and common system-level resources.

[0089] In one example of this embodiment, the API layer is essentially an API data structure management based on business attributes. For example, if an ASIC chip can support functional subsystem 1, functional subsystem 2, ..., functional subsystem N, then the business type enumeration is defined as follows:

[0090]

[0091] The management structure based on each business subsystem is defined as follows:

[0092]

[0093] This example uses the above core data structures to perform a first-level dynamic refactoring, making it easy for UAL to directly call the business function APIs corresponding to the refactored functional subsystems, while the APIs of functional subsystems that are not deployed are left unattended.

[0094] In one example of this embodiment, the general service management module needs to abstract the general service functions of the ASIC (e.g., general service templates, general channel interfaces, general time slot resource allocation, etc., used by functional subsystems 1, 2, ..., N). After abstraction, the data structure is defined according to the attributes of each general service function, and scheduling management is implemented. Taking the channel interface service function as an example, the ASIC chip has 8 general channels, which are shared by functional subsystems 1, 2, ..., N. Technically, the following data structure and management interface need to be defined:

[0095] Management channel attribute data structure;

[0096] The functional subsystem registration and application channel resource interface includes set, get, getNext, and delete;

[0097] Priority definition for channel usage between functional subsystems

[0098] The interface for managing the logic of channel preemption between functional subsystems.

[0099] This example uses the core data structures and processing interfaces described above to complete the second-level reconstruction of the general business management module. If a functional subsystem is not dynamically reconstructed at the first level, its corresponding channel resources, priorities, and preemption logic will no longer be processed. Instead, these general business functions will only be available to the functional subsystems dynamically built at the first level, minimizing the workload on the SDK.

[0100] In one example of this embodiment, the public resource management module needs to make an overall assessment of the ASIC's system resources, such as the memory, task processes, log recording resources, and semaphore quantity required by subsystem 1, subsystem 2... subsystem N. If a subsystem is not dynamically reconstructed at the first level, its corresponding memory resources, process resources, and log resources will be released, and the use of these system resources will only be developed for subsystems dynamically constructed at the first level.

[0101] The dynamically reconfigurable SDK software architecture in this embodiment is compared to... Figure 1 Compared to the general business-driven SDK software architecture shown, a two-level dynamically reconfigurable architecture for ASIC chips with high business complexity is designed by adding a public registration management module at the API layer and a general business management module and a public resource management module at the functional layer. The specific design concept is as follows:

[0102] 1. When used in multiple business scenarios, the public registration management module of the API layer dynamically refactors the first-level API according to the actual business scenario used, and exposes it to the user agent layer (UAL layer) for direct call when switching business scenarios;

[0103] 2. When used in multiple business scenarios, the functional layer calls the general business management module when switching business scenarios. The second-level general business management module is dynamically refactored according to the actual business scenario used, so as to unify the management of the use of the general business management module and reduce unnecessary business processing impact.

[0104] 3. When used in multiple business scenarios, the functional layer calls the public resource management module when switching business scenarios. The second-level public resource management module is dynamically refactored according to the actual business scenario used, reducing unnecessary business system consumption of system resources.

[0105] 4. Because of the existence of the general business management module and the public resource management module, users can query the usage of general business and system resources as needed, and perform unified management and query the status of business resource usage.

[0106] The public registration management module is the first-level component for dynamically refactoring external API interfaces, while the general business management module and public resource management module are the second-level components for dynamically refactoring business processes. These three components work together to coordinate and complete the dynamic refactoring. Dynamic refactoring is divided into first-level and second-level refactoring, and can be flexibly refactored multiple times based on business needs. First-level dynamic refactoring is directly perceived by SDK users, while second-level dynamic refactoring is imperceptible to SDK users and is completed internally within the SDK system.

[0107] The dynamically reconfigurable SDK software architecture described in this embodiment has the following advantages:

[0108] 1. When used in multiple business scenarios, business calls can be dynamically refactored as needed;

[0109] 2. When used in multiple business scenarios, there is no waste of system resources;

[0110] 3. Unified management of system resource usage;

[0111] 4. Unified management of the use of general modules.

[0112] The following example illustrates the workflow of the dynamically reconfigurable SDK software architecture in a specific scenario:

[0113] For example, during the evolution and iteration of network technology, a certain communication ASIC chip needs to replace functional subsystem A (corresponding to business application scenario A) with functional subsystem B (corresponding to business application scenario B), which has a greater technological advantage. Moreover, each application scenario is quite complex and corresponds to hundreds of business functions such as "business function 001", "business function 002"... "business function 100".

[0114] In an exemplary embodiment of this disclosure, for the above scenario, see [link to relevant documentation]. Figure 4 The dynamically reconfigurable architecture of the SDK system performs the following steps when performing secondary dynamic reconfiguration in two scenarios, "Business Application Scenario A" and "Business Application Scenario B":

[0115] First, load "Business Application Scenario A":

[0116] Step S401: After power-on, the API layer public registration management module starts working. Its initialization primarily involves the initialization of internal management data structures. For the business logic, there is no default business scenario, and no business function APIs will be registered. That is, the APIs corresponding to "Business Application Scenario A" and "Business Application Scenario B," namely "Functional Subsystem A" and "Functional Subsystem B," will not be registered. General external interfaces and internal debugging external interfaces are registered externally by default and are therefore not shown in the flowchart.

[0117] Step S402: The public resource management module initializes itself, mainly the data structure of internal management, but does not request any system-level resources for the "functional subsystem A" and "functional subsystem B" corresponding to "business application scenario A" and "business application scenario B".

[0118] Step S403: Other common SAL and DAL are initialized normally, mainly involving internal data structures. At this point, initialization is complete, and the SDK minimum system is finished. If users want to debug internal registers through the VIP green channel, they can configure any function; however, for business functions, it is in an "unloaded state."

[0119] At this point, the user initiates the deployment of "Business Function 001" under "Business Application Scenario A" and proceeds to step S404.

[0120] In step S404, the user bar uses a general external interface to request the deployment of "Business Function 001" under "Business Application Scenario A". Then, the API layer public registration management module loads all business APIs (including "Business Function 001") of the corresponding "Functional Subsystem A" under "Business Application Scenario A". Originally, this external API was handled as empty during initialization, but now it is open to the UAL layer for direct call.

[0121] Step S405: Initialize the business function module (including "Business Function 001") corresponding to "Functional Subsystem A" under "Business Application Scenario A" in Function Layer. Taking "Business Function 001" as an example, during initialization, it initializes the data structure required for its own operation, and initiates the registration for the use of general business functions (i.e., step S407) and applies for the use of public system-level resources (i.e., step S406).

[0122] In step S406, after the public resource management module receives the public resource application from the corresponding "functional subsystem A" (including "business function 001") under "business application scenario A", it applies for system resources for the module, creates a data structure, and manages the system information such as memory, tasks, semaphores, and logs required by each business function (including "business function 001") under the scenario.

[0123] Step S407: The general business management module registers the use of the shared functional module of the entire ASIC chip by the corresponding "functional subsystem A" (including "business function 001") under "business application scenario A", so as to facilitate the general business management module to manage the use of the shared functional module, such as priority, preemption, etc.

[0124] Step S408, "Business Application Scenario A" business function initialization is complete, SDK software for "Business Application Scenario A"

[0125] After the dynamic reconstruction of "Application Scenario A" is completed, and the UAL calls the external API 5 corresponding to "Business Function 001", "Business Function 001" is sent to the ASIC register through the driver layer and DAL layer, and the function is generated normally.

[0126] In particular, if a problem occurs during distribution, the VIP green debugging channel can be used to directly operate and read registers for debugging.

[0127] At this point, "Business Application Scenario A" has been loaded. Now, the user network migrates, and Service 0 is moved from "Business Function 001" under "Business Application Scenario A" to "Business Function 002" under "Business Application Scenario B". The product needs to be configured based on the new application scenario, requiring dynamic reconstruction of the corresponding SDK architecture. The dynamic reconstruction process continues according to the following steps:

[0128] Step S409, similar to step S404, requires the user to use a general external interface to deploy the "business application".

[0129] If "Business Function 002" corresponds to "Functional Subsystem B" under "Scenario B", then the API layer public registration management module loads all APIs (packages) corresponding to "Functional Subsystem B" under "Business Application Scenario B".

[0130] (Including "Business Function 002"), this external API was originally handled as an empty string during initialization, but now it is open to direct calls from the UAL layer.

[0131] The reverse operation of steps S410 and S404: Dynamically uninstalling the API layer public registration management module.

[0132] All business APIs (including "Business Function 001") corresponding to "Functional Subsystem A" under "Business Application Scenario A" were originally exposed to the UAL layer for direct call in STEP4. Now...

[0133] Even when the system is suspended and no longer in actual use, the uninstallation of "Functional Subsystem A" under "Business Application Scenario A" is also executed based on user-issued instructions. These instructions can be used in conjunction with the deployment in step S409.

[0134] The instructions for "Functional Subsystem B" under "Business Application Scenario B" can be issued as a single instruction or as a single instruction.

[0135] Steps S411 and S405 are reversed; Function Layer "Business Application Scenario A"

[0136] The business function module corresponding to "Functional Subsystem A" (including "Business Function 001") is deregistered.

[0137] Taking "Business Function 001" as an example, the data structure required for the operation of the function itself is deregistered, and the use of general business functions is initiated to register (i.e., step S413) and the use of public system resources is deregistered (i.e., step S412) to complete the release of the corresponding resources.

[0138] The reverse operation of steps S412 and S406: After receiving the public resource cancellation application of the business function module (including "business function 001") of the corresponding "functional subsystem A" under "business application scenario A", the public resource management module cancels the system resources occupied by the module according to the system configuration, releases the data structure, and no longer manages the system information such as memory, tasks, semaphores, and logs required by each business function (including "business function 001") under this scenario.

[0139] At this point, the resource reloading module in the API layer will determine whether to save this system information based on the system configuration, such as uploading log information to the file system.

[0140] The reverse operation of steps S413 and S407 is to register the use of each business function (including "Business Function 001") of "Functional Subsystem A" under "Business Application Scenario A" on the common function module of the entire ASIC chip, and no longer manage the use of the business on the general business function in the general business management module, such as deleting the business from priority, preemption and other management.

[0141] Step S414, similar to step S405, initializes the business function module of "Functional Subsystem B" under "Business Application Scenario B" in Function Layer (including "Business Function 002"). Taking "Business Function 002" as an example, it initializes the data structure required for its own operation, and initiates the registration for the use of general functions (step S416) and applies for the use of public system-level resources (step S415).

[0142] In step S415, similar to step S406, after the public resource management module receives the public resource application from the corresponding "functional subsystem B" (including "business function 002") under "business application scenario B", it applies for system resources for the module, creates data structures, and manages the system information such as memory, tasks, semaphores, and logs required by each business function (including "business function 002") under the scenario.

[0143] Step S416, similar to step S407, registers the use of the shared functional module of the entire ASIC chip by the corresponding "functional subsystem B" (including "business function 002") under "business application scenario B", so as to facilitate the use and management of the shared functional module by the general business management module, such as priority, preemption, etc.

[0144] Step S417 is similar to step S408. After the business function of "Business Application Scenario B" is initialized, the SDK software is dynamically reconstructed for "Business Application Scenario B". After the UAL calls the external API corresponding to "Business Function 002", "Business Function 002" is sent to the ASIC register through the driver layer and DAL layer. The function takes effect normally. In particular, if a problem occurs in the sending, the register can be directly operated and read through the VIP green debugging channel for debugging.

[0145] When faced with the above scenarios, Figure 1 The business-driven SDK software architecture shown will inevitably present SDK software users with two usage options, and each option will face the following technical limitations:

[0146] Option 1: Use a single SDK software, which is convenient for users to develop and maintain. However, the SDK software needs to implement all business functions of "Functional Subsystem A" and "Functional Subsystem B" at the same time, that is, "Business Function 001" to "Business Function 100" of each subsystem. When implementing it, it is necessary to apply for the corresponding business system resources. For the use of "Business Application Scenario A" or "Business Application Scenario B", there will be a waste of system resources from a technical point of view, and there will be a lot of redundant SDK code logic, which introduces the risk of using SDK software.

[0147] Option 2: Use two sets of SDK software, namely, compile software for "Functional Subsystem A" and "Functional Subsystem B" for use in "Business Application Scenario A" or "Business Application Scenario B". This avoids the problem of Option 1 in terms of technology, but introduces technical problems of SDK software development and maintenance. When the application of the product is switched from "Business Application Scenario A" to "Business Application Scenario B", the SDK software needs to be replaced. It cannot be done directly on the same set of SDK software through dynamic configuration, which lacks flexibility.

[0148] Both of these options will indirectly affect the physical cost and maintenance cost of the product to some extent. In other words, this SDK architecture design cannot meet the product requirements of ASIC chip users with high business function complexity.

[0149] In this embodiment, the SDK system adopts a dynamically reconfigurable architecture. For SDK software users, a single SDK system is used. Through dynamic adjustments in steps S401-S417, the SDK system flexibly and dynamically unloads and loads external functional interfaces as business usage scenarios change. Internally, it dynamically registers and deregisters general business function resources and system-level resources, effectively achieving dynamic reconfiguration of the SDK system based on business application scenarios. Simultaneously, it ensures minimal system resource usage and minimal processing of business function logic, while also improving system stability.

[0150] One embodiment of this disclosure also provides a chip including an SDK system as described in any embodiment of this disclosure.

[0151] In one or more exemplary embodiments described above, the described functionality may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functionality may be stored as one or more instructions or code on or transmitted via a computer-readable medium and executed by a hardware-based processing unit. The computer-readable medium may comprise a computer-readable storage medium corresponding to a tangible medium, such as a data storage medium, or a communication medium comprising any medium facilitating the transfer of a computer program from one place to another, such as according to a communication protocol. In this manner, the computer-readable medium may generally correspond to a non-transitory tangible computer-readable storage medium or a communication medium, such as a signal or carrier wave. The data storage medium may be any available medium accessible by one or more computers or one or more processors to retrieve instructions, code, and / or data structures for implementing the techniques described in this disclosure. Computer program products may comprise computer-readable media.

[0152] For example, and not as a limitation, such computer-readable storage media may include RAM, ROM, EEPROM, CD-ROM or other optical disc storage devices, magnetic disk storage devices or other magnetic storage devices, flash memory, or any other medium that can be used to store desired program code in the form of instructions or data structures and is accessible by a computer. Furthermore, any connection may also be referred to as a computer-readable medium. For example, if instructions are transmitted from a website, server, or other remote source using coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave, then coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of medium. However, it should be understood that computer-readable storage media and data storage media do not include connections, carrier waves, signals, or other transient media, but rather refer to non-transient tangible storage media. As used herein, disks and optical discs include compact optical discs (CDs), laser discs, optical discs, digital versatile discs (DVDs), floppy disks, or Blu-ray discs, where disks typically reproduce data magnetically, while optical discs use lasers to reproduce data optically. The above combinations should also be included within the scope of computer-readable media.

Claims

1. An SDK system, characterized in that, The SDK system adopts a dynamically reconfigurable architecture, including an API layer, a business API implementation layer, a functional layer, and a driver layer, wherein: The API layer includes API interfaces for one or more subsystems, a general external interface, and a public registration management module. The public registration management module is configured to provide a public registration interface and dynamically open the API interfaces of the subsystems, including: registering the general external interface after initialization; and, upon receiving an instruction input through the general external interface, if it is determined that a first subsystem needs to be deployed, loading the API interface of the first subsystem and connecting it with the business API inside the subsystem to open the loaded API interface to external calls, and notifying the first subsystem of the functional layer to initialize. The business API implementation layer includes business APIs within the subsystem and common processing APIs for common calls between the subsystems; The functional layer includes a general business management module, a public resource management module, and the business function modules of the subsystem. The general business management module is configured to manage the subsystem's use of the general business module, and the public resource module is configured to unify the scheduling of the subsystem's use of system resources. The driver layer is configured to enable the functional layer to call the registers.

2. The SDK system according to claim 1, characterized in that: The functional layer also includes an initialization module for each of the subsystems. The initialization module of the first subsystem is configured to initialize the business function module of the first subsystem after receiving an initialization notification, and apply for system resources from the public resource management module through the inter-subsystem interface. The public resource management module uniformly schedules the use of system resources by the subsystem, including: after receiving the application for system resources from the first subsystem, applying for system resources for the business function modules of the first subsystem, and managing the system information of the business function modules of the first subsystem.

3. The SDK system according to claim 2, characterized in that: The initialization module is also configured to, upon receiving an initialization notification, apply to the general business management module for registration of general business functions through the inter-subsystem interface; The general business management module manages the use of the general business module by the subsystem, including: managing general business functions, and registering the general business functions for the first subsystem after receiving a registration application for the general business functions from the first subsystem.

4. The SDK system according to claim 3, characterized in that: The general business management module registers general business functions for the first subsystem, including one or more of the following processes: Register and apply for general business functions for the first subsystem; Set the priority for the first subsystem to use the general business functions; The logic for the first subsystem to preempt the general business function is handled.

5. The SDK system according to claim 2, characterized in that: The public registration management module dynamically opens the API interface of the subsystem, and also includes: after receiving the instruction input through the general external interface, if it is determined that the second subsystem needs to be uninstalled, uninstalling the API interface of the second subsystem and no longer opening it to external calls, and notifying the second subsystem of the functional layer to perform empty processing; The functional layer also includes an empty interface module for each of the subsystems. After receiving the empty processing notification, the empty interface module of the second subsystem cancels the business function module of the second subsystem and applies to the public resource management module to cancel system resources through the inter-subsystem interface. The public resource management module, which uniformly schedules the system resources used by the subsystem, also includes: upon receiving a request from the second subsystem to cancel system resources, releasing the system resources occupied by the business function modules of the second subsystem.

6. The SDK system according to claim 5, characterized in that: The empty interface module is also configured to apply to the general business management module to cancel the general business function after receiving the notification of empty processing. The general business management module manages the use of the general business module by the subsystem, and also includes: after receiving the cancellation application of the second subsystem for the general business function, canceling the use of the general business function by the second subsystem.

7. The SDK system according to claim 2, characterized in that: After receiving the instruction input through the general external interface, the public registration management module determines that a first subsystem needs to be deployed, including: after receiving the instruction to deploy a specified business function, searching for the correspondence between the business function and the subsystem, and determining the subsystem corresponding to the specified business function as the first subsystem to be deployed.

8. The SDK system according to claim 1, characterized in that: The SDK system is applied to integrated circuits; The API interfaces, business APIs, and business function modules of the subsystems are built based on business application scenarios, and different subsystems correspond to different business application scenarios.

9. The SDK system according to claim 5, characterized in that: The business API implementation layer also includes a resource reloading module, which is configured to: after determining that the public resource management module releases the system resources occupied by the business function module of the second subsystem, save the system information of the second subsystem according to the system configuration; The system information includes any one or more of the following: memory information, task information, semaphore information, and log information.

10. The SDK system according to claim 1, characterized in that: The driver layer includes a subsystem submodule support verification module and a business-independent general processing interface; The subsystem submodule support verification module is set to verify the deployment status of the subsystem, allowing deployed subsystems to access the underlying registers and prohibiting undeployed subsystems from accessing the underlying registers. The business-independent general processing interface is configured to provide an interface that is independent of business logic.

11. The SDK system according to claim 1, characterized in that: The API layer also includes an internal debugging external interface, which is configured to receive internal debugging commands. The business API implementation layer also includes an internal debugging channel, which is configured to directly transmit the internal debugging command to the driver layer after receiving the internal debugging command input from the internal debugging external interface. The driver layer also includes an internal debugging channel, which is configured to read registers according to the internal debugging instructions to perform debugging and directly locate chip-level problems.

12. A chip, characterized in that, Includes the SDK system as described in any one of claims 1-11 above.

Images