Register configuration method and device of dnoc and electronic equipment
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- METAX INTEGRATED CIRCUITS (SHANGHAI) CO LTD
- Filing Date
- 2026-04-09
- Publication Date
- 2026-06-19
Smart Images
Figure CN121979573B_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of processor system technology, and in particular to a register configuration method, apparatus and electronic device for a DNOC. Background Technology
[0002] DNOC (Data Network On Chip) is a core data transmission architecture in multiprocessor systems, responsible for establishing data transfer channels between target processors. The accuracy and efficiency of its register configuration directly impact overall system performance. To improve the flexibility and performance of multiprocessor system deployment, the DNOC module has added a large number of configurable registers. However, this also presents significant challenges to subsequent software adaptation, specifically in the following three aspects:
[0003] First, register configuration is extremely complex and has a very high learning curve. DNOC adds a large number of registers with complex functions and cumbersome configuration rules. Software teams need to thoroughly study the programming guide to use them correctly, and they also need to manually write the configuration code for each register directly in the driver program. This makes it very easy to make configuration errors due to misunderstandings or oversights, and these errors are often difficult to detect during the coding phase.
[0004] Secondly, debugging efficiency is low and resources are wasted significantly. During the post-simulation and emulator testing phases, firmware / driver failures frequently occur due to misinterpretations of registers or manual coding errors. These problems require collaborative debugging between hardware and software teams to pinpoint, consuming substantial human resources and severely extending project cycles.
[0005] Third, R&D risks increase significantly. The software team needs to invest a lot of time to understand register functions and write and verify register configuration code, while the hardware team also needs to continuously intervene to debug test failures caused by misunderstandings. Furthermore, manually written configuration code lacks structured organization, with code from different configuration scenarios mixed together, making it difficult to reuse and maintain. This introduces huge uncertainties into driver and firmware development, increasing project delays and product stability risks.
[0006] Existing technologies lack a systematic DNOC register configuration management mechanism, resulting in scattered and difficult-to-reuse configuration information. Faced with large-scale, multi-scenario register configuration needs, there is an urgent need for a solution that can reduce configuration complexity, improve accuracy, and reduce debugging costs. Summary of the Invention
[0007] This application provides a register configuration method, apparatus, and electronic device for DNOC. By using standardized configuration templates, it achieves a unified configuration framework and automated process, significantly reducing configuration complexity and maintenance costs, and improving debugging efficiency.
[0008] In a first aspect, one embodiment of this application provides a register configuration method for a DNOC, wherein the DNOC is used to configure and manage data interconnect paths between multiple target processors in a multiprocessor system, and the method includes the following steps:
[0009] When it is necessary to configure the registers of the DNOC, a pre-stored register configuration file is read from a preset storage medium and the configuration information of the register to be configured is extracted. The register configuration file is obtained by converting the standardized configuration template generated according to the DNOC register configuration rules, filling in the configuration information of the register to be configured.
[0010] Based on the extracted configuration information of the registers to be configured, configuration instructions recognizable by the DNOC are generated;
[0011] The configuration command is sent to the DNOC to complete the register configuration of the DNOC.
[0012] Optionally, the standardized configuration template is taken from a predefined configuration template database;
[0013] The configuration template database provides a unique, standardized configuration template for each configuration scenario in the multiprocessor system.
[0014] Each of the standardized configuration templates includes at least: a configuration scenario identifier, and register address and configuration value fields of the registers in the DNOC related to the corresponding configuration scenario; the configuration value field provides a standardized placeholder for filling in the corresponding configuration value information when generating the register configuration file;
[0015] The configuration scenario refers to a specific hardware environment that requires independent configuration of the DNOC register, defined by the system topology of the multiprocessor system and the target processor. Different combinations of system topology and target processor correspond to different configuration scenarios. The target processor is selected from any of the following: a single-core processor or a core within a multi-core processor.
[0016] Optionally, the configuration scenario identifier includes a system topology identifier and a target processor identifier.
[0017] Optionally, when the target processor is a single-core processor, the target processor identifier is the processor identifier of the single-core processor; when the target processor is a core within a multi-core processor, the target processor identifier includes the processor identifier of the multi-core processor and the core identifier of the corresponding core.
[0018] Optionally, in the standardized configuration template, the configuration value field supports at least one of the following numerical provision formats:
[0019] A constant type that provides a fixed value that can be directly written to a register;
[0020] Expression type, providing an expression that includes at least one computed parameter;
[0021] An enumeration type that provides optional enumeration values to be selected from a predefined set of values.
[0022] Optionally, when the numerical value of the configuration value field is provided in the form of an expression type, the method further includes the following steps:
[0023] The expression is obtained from the configuration information of the register to be configured, and the current system value of each calculated parameter in the expression is obtained.
[0024] The value of the expression is calculated based on the current system values of each calculation parameter, and the calculation result is used as the final value of the configuration value field to generate configuration instructions.
[0025] Optionally, the preset storage medium includes multiple configuration storage partitions, each configuration storage partition uniquely corresponding to a configuration scenario;
[0026] Each configuration storage partition includes:
[0027] The header block stores the configuration scenario identifier for the corresponding configuration scenario, which is used for locating and matching the configuration scenario;
[0028] The data block is used to store the register addresses and configuration value information of the registers that need to be configured in the DNOC under the corresponding configuration scenario.
[0029] Optionally, the step of reading the pre-stored register configuration file from the preset storage medium and extracting the configuration information of the register to be configured specifically includes:
[0030] Determine the target configuration scenario identifier based on the current system configuration scenario;
[0031] Locate the target configuration storage partition whose header block contains the target configuration scenario identifier in the preset storage medium;
[0032] Extract the register address and configuration value information of the register to be configured from the data block of the target configuration storage partition.
[0033] Secondly, one embodiment of this application provides a register configuration apparatus for a DNOC, wherein the DNOC is used to configure and manage data interconnect paths between multiple target processors in a multiprocessor system, the apparatus comprising:
[0034] The information extraction module is used to read a pre-stored register configuration file from a preset storage medium and extract the configuration information of the register to be configured when it is necessary to configure the registers of the DNOC. The register configuration file is obtained by converting the standardized configuration template generated according to the DNOC register configuration rules, filling in the configuration information of the register to be configured.
[0035] The instruction generation module is used to generate configuration instructions that the DNOC can recognize based on the extracted configuration information of the registers to be configured.
[0036] The execution sending module is used to send the configuration instructions to the DNOC to complete the register configuration of the DNOC.
[0037] Thirdly, one embodiment of this application provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of any of the above methods.
[0038] Fourthly, one embodiment of this application provides a computer-readable storage medium having computer program instructions stored thereon, which, when executed by a processor, implement the steps of any of the above methods.
[0039] Fifthly, one embodiment of this application provides a computer program product or computer program that includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the methods provided in the various optional implementations of the first aspect described above.
[0040] The DNOC register configuration method, apparatus, and electronic device provided in this application provide a standardized configuration template with a pre-defined unified configuration framework. This clearly defines the specifications for filling in register configuration information, eliminating the need for software engineers to delve into complex DNOC programming guides. They can simply fill in the configuration information according to the template specifications to complete the configuration preparation, significantly reducing the understanding threshold and operational complexity of register configuration. The standardized and automated configuration process replaces the traditional high-risk model that relies on manual understanding and coding. This avoids repeated modifications due to a lack of understanding of configuration rules and reduces the additional burden on hardware teams for debugging. It effectively reduces the difficulty of driver and firmware development, significantly improves debugging efficiency, and reduces unnecessary consumption of human and time resources. Furthermore, this application provides a unified standardized configuration template through a configuration template database, ensuring that register configurations in different configuration scenarios and at different development stages follow consistent rules. This reduces maintenance risks caused by configuration differences, and the automated process reduces the operational costs of subsequent configuration iterations, further solving the long-term maintenance challenges in complex configuration scenarios. Attached Figure Description
[0041] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the embodiments of this application will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0042] Figure 1 This is a schematic diagram of the structure of a multiprocessor system provided in one embodiment of this application;
[0043] Figure 2 This is a flowchart illustrating a DNOC register configuration method provided in an embodiment of this application. Detailed Implementation
[0044] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, a detailed description is provided below in conjunction with the accompanying drawings and specific implementation methods. Although the embodiments of this application provide method operation steps as shown in the following embodiments or drawings, the method may include more or fewer operation steps based on conventional or non-inventive effort. For steps that do not logically have a necessary causal relationship, the execution order of these steps is not limited to the execution order provided in the embodiments of this application. Unless otherwise specified, the embodiments and features in the embodiments of this application can be arbitrarily combined with each other.
[0045] For ease of understanding, the terms used in the embodiments of this application are explained below:
[0046] A multiprocessor system is a computer system in which multiple processors are integrated through a high-speed interconnect network to collaboratively complete computational tasks. In this application, the multiprocessor system includes multiple target processors, which are core objects interconnected and configured via a DNOC. The multiprocessor system may also include other processing units such as a central processing unit (CPU) for global coordination.
[0047] GPU (Graphics Processing Unit), MGPU stands for Multi-GPU, which refers to a system composed of multiple interconnected GPUs, and its core purpose is to improve the system's data processing performance.
[0048] DNOC (Data Network On Chip) is a dedicated data transmission network architecture integrated within a target processor (such as a GPU). It is a core hardware module in a multiprocessor system used to configure and manage data interconnect paths between multiple target processors. By configuring the internal registers of DNOC, data transmission links, bandwidth, and communication protocols between target processors can be established, adjusted, and optimized. Its register configuration directly determines the interconnect efficiency, transmission stability, and topology adaptability between target processors.
[0049] Target processor: In the multiprocessor system of this application, this refers to the processor unit that is the target of DNOC register configuration and requires the establishment of a data interconnect path. Physically, the target processor can be a single-core processor or a single core within a multi-core processor. Each target processor typically corresponds to a DNOC interconnect endpoint that needs to be configured independently.
[0050] Single-chip processor: This refers to a processor chip that is physically manufactured as a single unit, integrating only one core functional silicon die (without multi-chip splitting design), and can participate as an independent unit in multi-processor system interconnection. Single-chip GPU chips, traditional single-core CPUs, and independently packaged dedicated processing chips (such as AI accelerator single-chip chips) all belong to the category of single-chip processors.
[0051] Multi-Chiplet Processor: A processor device formed by packaging multiple functional silicon wafers (called "chips") on the same substrate or interposer through heterogeneous or homogeneous integration. Its core features include: (1) Physical integration: Multiple independently manufactured chips are physically integrated into a package; (2) Logical unification: It is identified as a single logical processor at the operating system and software levels; (3) High-bandwidth interconnect: Chips communicate with each other through ultra-high bandwidth interconnects (such as NVLink, Infinity Fabric, EMIB, etc.) within the package; (4) Functional division: Different chips undertake different functions (computation, cache, I / O, memory, etc.).
[0052] Chip: refers to a silicon wafer with independent functions in a multi-chip processor.
[0053] Execution processor: refers to a hardware processing unit integrated within a target processor (such as a GPU) in a multiprocessor system, specifically responsible for executing the DNOC register configuration method of this application. Physically, the execution processor is an independent processing core or microcontroller (MCU), containing an initialization firmware program (such as SMP firmware). The core function of this program is: upon receiving a configuration task, to access a preset storage medium and independently execute program instructions to complete the entire process of reading the configuration file, parsing information, generating and sending configuration instructions to the DNOC.
[0054] The multiprocessor systems in this application include, but are not limited to, MGPU systems and multi-chip processor systems. Figure 1 Taking the MGPU system shown as an example, this system includes one CPU and multiple GPUs. The CPU, as the core of system startup and hardware management, is responsible for configuration triggering and global coordination. Each GPU integrates a dedicated execution processor and a DNOC. Multiple GPUs are interconnected through their respective DNOCs, forming a system-level data path. In this architecture, the execution processor is responsible for the configuration management of its respective GPU's internal DNOC module. When the system needs to configure the DNOC (e.g., during startup initialization or runtime topology changes), the CPU, as the system master controller, sends a configuration trigger signal to the execution processors within each GPU. Subsequently, each execution processor independently executes the configuration method described in this application: reading a pre-stored register configuration file matching the GPU scene from a preset storage medium, extracting configuration information from it, generating configuration instructions, and sending them to the DNOC within its own GPU to complete its register configuration, thereby achieving the initialization of the interconnection path between multiple GPUs or dynamic optimization and adjustment during runtime.
[0055] To address the software adaptation challenges posed by the addition of new registers in DNOC within multiprocessor systems (such as MGPUs), this application proposes a pre-configuration mechanism of "template-based configuration + pre-storage." The core objective is to replace the traditional method of manually writing configuration programs for drivers, thereby reducing the cost of understanding and the error rate. The core components of this pre-configuration mechanism include standardized configuration templates and a configuration template database. The database assigns a unique standardized configuration template to each configuration scenario defined by the system's topology and target processor. These standardized templates clearly define the format and specifications for filling in the configuration information of each relevant register in that configuration scenario, thus unifying the configuration framework and reducing the difficulty of understanding and adapting registers.
[0056] Before practical application, software technicians only need to call the standardized configuration template for the corresponding configuration scenario from the configuration template database, fill in the configuration value information of the register to be configured according to the filling format and specifications provided by the standardized configuration template, obtain the register configuration file, and then store the configured register configuration file in the preset storage medium for quick reading during subsequent configuration. After the register configuration file is completed and stored, when the system triggers DNOC register configuration (such as initialization, topology change), the execution processor in the system executes the following core process (S101-S103).
[0057] refer to Figure 2 This application provides a register configuration method for a DNOC, including the following steps:
[0058] S101. When it is necessary to configure the registers of DNOC, read the pre-stored register configuration file from the preset storage medium and extract the configuration information of the register to be configured.
[0059] The register configuration file in the default storage medium is obtained by converting a standardized configuration template, written according to the DNOC register configuration rules, into which the configuration information of the registers to be configured is filled in. The DNOC register configuration rules come from the DNOC Programming Guide.
[0060] DNOC is used to configure and manage data interconnect paths between multiple target processors in a multiprocessor system. DNOC register configuration is triggered during both system initialization and system operation. Specifically: After the multiprocessor system starts, the system initialization process is executed. During the execution of the initialization program, when the DNOC register configuration step is triggered, the pre-stored register configuration file is read from the preset storage medium, and the configuration data of the register to be configured is extracted. Furthermore, during system operation, if there are configuration requirements such as topology changes or functional upgrades, the processor's internal preset DNOC register configuration program may also be triggered. The processor then reads the corresponding configuration file from the preset storage medium and extracts the configuration data. The processor's internal preset DNOC register configuration program pre-specifies a unique identifier for the register to be configured; this identifier accurately locates the configuration information of the target register in the preset storage medium, and simultaneously achieves precise location of the target register within the DNOC.
[0061] S102. Based on the configuration information of the extracted registers to be configured, generate configuration instructions that can be recognized by DNOC.
[0062] In practical implementation, the processor extracts configuration information, such as the register addresses and corresponding configuration values of the registers to be configured from the register configuration file, and converts this information into standardized configuration instructions that DNOC can directly recognize and execute. This achieves precise mapping of configuration information to hardware operation instructions, avoiding configuration failures due to instruction format incompatibility, while ensuring the efficiency and accuracy of the configuration process. Generating DNOC-recognizable configuration instructions based on configuration information is a conventional technique in this field and will not be elaborated upon in this application.
[0063] S103. Send the configuration command to DNOC to complete the DNOC register configuration.
[0064] The DNOC register configuration method provided in this application addresses the issue of DNOC having a complex and numerous list of default configuration registers. The hardware team uses standardized configuration templates to pre-define a unified configuration framework, clearly defining the specifications for filling in register configuration information. Software engineers do not need to delve into the complex DNOC programming guide; they only need to fill in the configuration information according to the template specifications to complete the configuration preparation, significantly reducing the understanding threshold and operational complexity of register configuration. This standardized and automated configuration process replaces the traditional high-risk mode that relies on manual understanding and coding. It avoids repeated modifications due to a lack of understanding of configuration rules and reduces the additional burden on the hardware team for debugging. It effectively reduces the difficulty of driver and firmware development, significantly improves debugging efficiency, and reduces unnecessary consumption of human and time resources. Furthermore, this application provides a unified standardized configuration template through a configuration template database, ensuring that register configurations in different configuration scenarios and at different development stages follow consistent rules, reducing maintenance risks caused by configuration differences. Simultaneously, the automated process reduces the operational costs of subsequent configuration iterations, further solving the long-term maintenance challenges in complex configuration scenarios.
[0065] Based on the hardware topology of the multiprocessor system and the DNOC register configuration rules, the hardware team can develop unique, standardized configuration templates for each configuration scenario that the multiprocessor system may encounter in practical applications, thus creating a configuration template database. In this database, each configuration scenario has a unique identifier, facilitating accurate location of the target configuration scenario. This unique matching design between standardized configuration templates and configuration scenarios ensures configuration consistency across different scenarios.
[0066] In some optional implementations, each standardized configuration template includes at least: a configuration scenario identifier, and register address and configuration value fields of the registers in DNOC related to the corresponding configuration scenario; the configuration value field provides a standardized placeholder for filling in the corresponding configuration value information when generating the register configuration file.
[0067] It should be noted that the register addresses of each register are determined during the template design and are fixed information. Therefore, the register addresses will not be modified during register configuration. The content configured by software personnel mainly includes setting the configuration scenario (such as filling in the configuration scenario identifier in the standardized configuration template) and filling in the configuration value information of the registers. The configuration value field in the standardized configuration template is a placeholder to be filled in, and specific information (i.e., configuration value information) needs to be filled in according to different scenarios. The standardized register address and configuration value field format facilitates understanding and configuration by software personnel and can be directly parsed by the execution processor, improving the efficiency of automated execution.
[0068] A configuration scenario refers to a specific hardware environment defined by the system topology of a multiprocessor system and the target processor, requiring independent configuration of the DNOC registers. Different combinations of system topology and target processors correspond to different configuration scenarios. The target processor can be selected from any of the following: a single-core processor or a core within a multi-core processor.
[0069] When the target processor is uniformly selected as a single-core processor, assuming a multiprocessor system includes four single-core GPUs and provides three optional system topologies P1, P2, and P3, each system topology and each single-core processor combination corresponds to a configuration scenario, and each configuration scenario uniquely matches a standardized configuration template. Specifically, the combination of system topology P1 and GPU1 corresponds to configuration scenario S1, which corresponds to a dedicated standardized configuration template T1. Template T1 includes the register address and configuration value fields of the registers related to GPU1 in the DNOC when using the P1 topology; the combination of system topology P1 and GPU2 corresponds to configuration scenario S2, which corresponds to another dedicated standardized configuration template T2, including the register address and configuration value fields of the registers related to GPU2 in the DNOC when using the P1 topology, and so on. In summary, this example forms a total of 3 × 4 = 12 independent configuration scenarios, corresponding to the generation of 12 standardized configuration templates.
[0070] When the target processor is uniformly selected as a core within a multi-core processor, assuming a multi-processor system contains four multi-core GPUs, each GPU containing two cores (denoted as DIE1 and DIE2), and provides three optional system topologies: P1, P2, and P3. In this case, each combination of "system topology + processor + core" corresponds to an independent configuration scenario, and each configuration scenario uniquely matches a standardized configuration template. Specifically, in system topology P1, the core DIE1 of GPU1 corresponds to configuration scenario S3, and configuration scenario S3 corresponds to a dedicated standardized configuration template T3. This template contains the register address and configuration value fields of the registers to be configured related to DIE1 of GPU1 in the DNOC when using the P1 topology. Similarly, in system topology P1, the core DIE2 of GPU1 corresponds to configuration scenario S4, and configuration scenario S4 corresponds to another dedicated standardized configuration template T4, containing the register address and configuration value fields of the registers to be configured related to DIE2 of GPU1 in the DNOC when using the P1 topology, and so on. In summary, this example generates a total of 3×4×2=24 independent configuration scenarios, which correspond to the need to generate 24 standardized configuration templates.
[0071] It should be noted that the hardware team will take into account factors such as the DNOC programming guide and system topology to predetermine the DNOC registers to be configured for each target processor under a specific system topology, and write their register addresses and configuration value fields into the standardized configuration template for the corresponding scenario. For example, when using the P1 topology, the DNOC register addresses and configuration value fields related to GPU1 are pre-written into the dedicated standardized configuration template T1 for GPU1 in the P1 topology scenario.
[0072] The standardized configuration template pre-sets the DNOC register addresses and configuration value fields corresponding to the "system topology + target processor" (e.g., register addresses related to the P1 topology and GPU1). Software engineers do not need to deeply study the complex DNOC programming guide to clearly identify the configuration objects and core information, avoiding configuration deviations caused by incomplete understanding of the guide. Software engineers only need to supplement the basic configuration values according to the template instructions, without needing to pay attention to details such as register relationships and address validity, to quickly complete the configuration preparation. This completely eliminates the workload of manually selecting registers and deriving configuration logic, reducing operational complexity and avoiding problems such as address errors and missing configuration items caused by manually determining registers and configuration information, thus improving configuration efficiency and accuracy and shortening the development and debugging cycle.
[0073] In some alternative implementations, the configuration scenario identifier includes a system topology identifier and a target processor identifier. By decomposing the configuration scenario identifier into a system topology identifier and a target processor identifier, a precise description and matching of the configuration scenario is achieved.
[0074] Depending on the type of target processor, the target processor identifier has a different structure.
[0075] When the target processor is a single-chip processor, the target processor identifier includes the processor identifier of that single-chip processor. In this case, the configuration scenario identifier includes the system topology identifier and the processor identifier.
[0076] The following is an example of a standardized configuration template in JSON format:
[0077] {
[0078] "mgpu_config_id":{
[0079] "socket_idx":{
[0080] "reg1_addr":"value1",
[0081] "reg2_addr":"value2", ...
[0082] "regN_addr":"valueN"
[0083] }
[0084] }
[0085] }
[0086] In the example of the standardized configuration template above, the target processor is a single-core processor. mgpu_config_id represents the system topology identifier; socket_idx represents the processor identifier; reg1_addr represents the register address of the first register, value1 represents the configuration value field of the first register, and so on, regN_addr represents the register address of the Nth register, and valueN represents the configuration value field of the Nth register.
[0087] When the target processor is a chip within a multi-chip processor, the target processor identifier includes the processor identifier of the multi-chip processor and the chip identifier of the corresponding chip. In this case, the configuration scenario identifier includes the system topology identifier, the processor identifier, and the chip identifier.
[0088] The following is an example of a standardized configuration template in JSON format:
[0089] {
[0090] "mgpu_config_id":{
[0091] "socket_idx":{
[0092] "die_idx":{
[0093] "reg1_addr":"value1",
[0094] "reg2_addr":"value2", ...,
[0095] "regN_addr":"valueN"
[0096] }
[0097] }
[0098] }
[0099] }
[0100] In the example of the standardized configuration template above, the target processor is the chip, mgpu_config_id represents the system topology identifier; socket_idx represents the processor identifier, die_idx represents the chip identifier, and the two together constitute the target processor identifier in the chip scenario; reg1_addr represents the register address of the first register, value1 represents the configuration value field of the first register, and so on, regN_addr represents the register address of the Nth register, and valueN represents the configuration value field of the Nth register.
[0101] Software engineers only need to fill in the system topology identifier, processor identifier, chip identifier, and configuration values of each register in the corresponding fields.
[0102] Furthermore, to simplify the management of configuration templates and improve the versatility of the system architecture, this application also provides a unified template structure embodiment. In this embodiment, regardless of whether the target processor is a single-core processor or a core within a multi-core processor, a unified configuration scenario identifier structure containing core identifiers is adopted.
[0103] Specifically, all target processors in the system are logically considered as entities with at least one core. For single-core processors, a preset fixed core identifier (such as "DIE0") is assigned; for multi-core processors, their actual core identifier is used. In this way, the standardized configuration templates for all configuration scenarios have a completely consistent structural hierarchy (system topology-processor-core), achieving a thorough unification of the configuration management framework.
[0104] Taking a system containing hybrid processors as an example: Assume the system uses a P1 topology, containing a single-core processor GPU0 (containing one DIE0 core) and a multi-core processor GPU1 (containing two cores, DIE0 and DIE1). After adopting a unified template structure:
[0105] The configuration scenario identifier for GPU0 is: P1-GPU0-DIE0;
[0106] The configuration scenario identifier for GPU1's chip DIE0 is: P1-GPU1-DIE0;
[0107] The configuration scenario identifier for GPU1's chip DIE1 is: P1-GPU1-DIE1.
[0108] At this point, there are three configuration scenarios in the system, each corresponding to a standardized configuration template with the same JSON structure:
[0109] {
[0110] "mgpu_config_id": "P1",
[0111] "socket_idx": "GPU0", / / or "GPU1"
[0112] "die_idx": "DIE0", / / For GPU0, it's always "DIE0", while for GPU1, it can be either "DIE0" or "DIE1".
[0113] "reg1_addr": "value1",
[0114] "reg2_addr": "value2", ...
[0115] "regN_addr": "valueN
[0116] }
[0117] The above example uses JSON format to illustrate the structure of a standardized configuration template, but this application is not limited to this. Those skilled in the art will understand that the standardized configuration template can be implemented using any suitable data serialization format, such as, but not limited to, text formats (YAML, XML, TOML, INI, etc.).
[0118] Programming language data structures (such as Python dictionaries, C structs, Java classes, etc.) and database records (such as relational database tables, NoSQL documents, etc.) are all protected by this application, regardless of their specific format, as long as they implement the core structural features of the standardized configuration template described in this application (including configuration scenario identifiers, register addresses, configuration value field definitions, etc.).
[0119] In practical applications, the configuration template database can be indexed based on combinations of "system topology + target processor," facilitating rapid template retrieval and updates, and avoiding management chaos caused by scattered template storage. Furthermore, common configuration fields for the same target processor or system topology can be reused in the configuration template database, eliminating the need to repeatedly write templates for similar scenarios and significantly reducing development costs for multi-scenario adaptation. For example, when adding a target processor to a multi-processor system, only the specific fields for that new target processor and different topology combinations need to be added to the database to quickly expand configuration scenarios and improve system iteration efficiency.
[0120] Standardized configuration templates can also include auxiliary fields for explanation and prompts. These fields directly inform users of information such as "the meaning of topology identifiers, register functions, the range of optional configuration values and their corresponding functions," making it easier for users to understand the template without needing to consult complex programming guides. Users can clearly understand "what to fill in, how to fill it in, and what the purpose of filling it in" simply by referring to the template's built-in prompts, completely avoiding configuration errors caused by a lack of understanding of the guides. These auxiliary fields are only for explanation and do not affect the parsing logic of core configuration fields (configuration scenario identifiers, register addresses, configuration value fields, etc.).
[0121] In some alternative implementations, the configuration value field in the standardized configuration template supports at least one of the following numeric provision formats:
[0122] (1) Constant type: provides a fixed value that can be directly written to the register.
[0123] The constant type is suitable for static configuration values that are fixed and unchanging, such as basic enable bits and fixed link width configurations.
[0124] For example, in system topology P1, GPU1 corresponds to a dedicated standardized configuration template T1. This template contains the address and configuration value fields of the registers to be configured related to GPU1 in DNOC when using the P1 topology, as follows: DNOC register address to be configured 0x1000 (GPU1-DNOC link enable register), the configuration value field is a constant type with a fixed value of 0x01. This value can be directly written to the register to enable the communication link between GPU1 and DNOC, and is a fixed static configuration value; DNOC register address to be configured 0x1008 (GPU1 link width configuration register), the configuration value field is a constant type with a fixed value of 0x00001234. This value can be directly written to the register to fix the link width between GPU1 and DNOC to 8 bits, and is a fixed static configuration value.
[0125] (2) Enumeration type: Provides optional enumeration values selected from a predefined set of values.
[0126] Enumeration types are suitable for configuring a limited number of fixed options. During configuration, one of the optional enumeration values must be selected as the register configuration value and written to the corresponding configuration value field of the register.
[0127] For example, GPU1 in system topology P1 corresponds to a dedicated standardized configuration template T1. This template contains the address and configuration value fields of the registers to be configured related to GPU1 in DNOC when using the P1 topology, as follows:
[0128] The DNOC register address to be configured is 0x1010 (GPU1 transmission rate configuration register). The configuration value field is an enumeration type with three preset fixed options and corresponding encoded values: 0x00 represents "rate mode A (10Gbps)", 0x01 represents "rate mode B (20Gbps)", and 0x02 represents "rate mode C (40Gbps)". When configuring, select "rate mode B (20Gbps)" and write the corresponding encoded value 0x01 into this configuration value field. This is suitable for scenarios where the transmission rate is a limited fixed option, improving the standardization and readability of the configuration.
[0129] The DNOC register address to be configured is 0x1018 (GPU1 communication protocol selection register). The configuration value field is an enumeration type with two preset fixed options and corresponding encoding values: 0x00 represents "Protocol X (low latency priority)" and 0x01 represents "Protocol Y (bandwidth priority)". When configuring, if "Protocol X (low latency priority)" is selected, the corresponding encoding value 0x00 is written to this configuration value field to avoid configuration value confusion. At the same time, by binding the encoding with the meaning, it is easy for developers to quickly understand the configuration intent.
[0130] (3) Expression type: Provide an expression that contains at least one calculation parameter.
[0131] The expression type is suitable for configuration values that need to be dynamically calculated based on real-time parameters. The configuration value is calculated from a preset expression. The calculation parameters in the expression are system parameters that need to be dynamically obtained during the DNOC register configuration process, including but not limited to: static parameters characterizing inherent hardware characteristics (such as GPU model, memory specifications, etc.); dynamic parameters characterizing the system's runtime state (such as device temperature, computing load, power consumption threshold, etc.); topology parameters characterizing hardware interconnection characteristics (such as the number of active links, neighbor node communication status, etc.); policy parameters characterizing service configuration rules (such as performance priority mode, energy saving priority mode, etc.); basic identifier / capacity parameters, such as socket_idx, high bandwidth memory size, expandable memory size, etc.
[0132] When the value provided in the configuration value field is an expression type, during the DNOC register configuration process, the processor obtains the expression from the configuration information of the register to be configured and retrieves the current system value of each calculation parameter in the expression; it calculates the value of the expression based on the current system value of each calculation parameter, and uses the calculation result as the final value of the configuration value field to generate the configuration instruction.
[0133] For example, GPU1 in system topology P1 corresponds to a dedicated standardized configuration template T1. This template contains the address and configuration value fields of the registers to be configured related to GPU1 in DNOC when using P1 topology. Taking the address of the register to be configured in DNOC 0x1020 (GPU1 dynamic bandwidth threshold configuration register) in the template as an example, its configuration value field is an expression type, specifically defined as: (HBM capacity / 1024) + number of active links × 2 + (computing load / 100) × 5, where HBM capacity, number of active links, and computing load are the calculation parameters in the expression. Accordingly, the specific process for the processor to perform configuration value calculation and instruction generation for this register is as follows: Read the configuration information of register 0x1020 from the standardized configuration template T1, and extract the above expression (HBM capacity / 1024) + active link number × 2 + (computing load / 100) × 5; collect the current system values of each calculation parameter in the expression in real time, assuming that the HBM capacity of GPU1 under the current P1 topology is 2048GB (corresponding to the value 2048), the number of active links is 3, and the real-time computing load is 80% (corresponding to the value 80); perform the calculation based on the obtained current system values: (2048 / 1024) + (3×2) + (80 / 100)×5 = 2 + 6 + 4 = 12 (the decimal value 12 is converted to hexadecimal as 0x0C); take the calculation result 0x0C as the final value of the configuration value field of register 0x1020, and generate the DNOC register configuration instruction in combination with the register address 0x1020 to complete the configuration of the register.
[0134] The standardized configuration template provides software engineers with three numerical formats suitable for different scenarios: constant type for static configurations with fixed values; enumeration type for configurations with limited fixed options, improving standardization through preset encoding values; and expression type for configurations requiring real-time dynamic parameter calculation. By providing multiple configuration value fields, it adapts to both static and dynamic configuration needs. The combination of these three types allows the standardized configuration template to cover the configuration requirements of various DNOC registers in multiple systems. Whether it's simple static configuration or complex dynamic configuration, it can be achieved through corresponding numerical formats, significantly expanding the applicable scenarios of the solution. Software engineers do not need a deep understanding of the underlying register logic or system parameter relationships; they only need to fill in or select configuration information according to the preset types in the template to complete the configuration, further reducing the configuration threshold, improving configuration flexibility and reliability, and making the DNOC register configuration method more suitable for various application scenarios from simple multiprocessor systems to complex multi-chip architectures.
[0135] Meanwhile, the template clearly indicates the numerical type, which facilitates unified management and updates by the hardware team. For example, when adding new configuration scenarios in the future, only the corresponding numerical form needs to be selected to supplement the field content, without the need to reconstruct the template structure, thus improving the maintainability and scalability of the template.
[0136] The preset storage medium in this application can be a non-volatile storage medium commonly used in multiprocessor systems, such as VBIOS (Video BIOS) and onboard Flash memory. The specific storage medium type can be flexibly selected according to the system hardware architecture, storage capacity requirements and read / write speed requirements, and is not limited here.
[0137] To ensure the register configuration file can be stably stored on the default storage medium and is compatible with the subsequent fast reading and parsing by the processor, it must be converted to a file format supported by the storage medium before storing the completed configuration file. For example, when the default storage medium is VBIOS, the register configuration file must be converted to a binary (bin) format file. This format features a compact data structure, strong storage compatibility, and high parsing efficiency, satisfying both VBIOS storage format requirements and the processor's parsing logic for the configuration file, ensuring smooth execution of the configuration process.
[0138] In some optional implementations, the preset storage medium includes multiple configuration storage partitions, each uniquely corresponding to a configuration scenario. Each configuration storage partition includes a header block and a data block; wherein, the header block is used to store the configuration scenario identifier corresponding to the configuration scenario for locating and matching the configuration scenario; the data block is used to store the register addresses and configuration value information of the registers that need to be configured in the DNOC under the corresponding configuration scenario.
[0139] Accordingly, step S101, "reading the pre-stored register configuration file from the preset storage medium and extracting the configuration information of the register to be configured", specifically includes the following steps: determining the target configuration scenario identifier based on the current system configuration scenario; searching for the target configuration storage partition in the preset storage medium whose header block contains the target configuration scenario identifier; and extracting the register address and configuration value information of the register to be configured from the data block of the target configuration storage partition.
[0140] Taking a multiprocessor system with four configuration scenarios as an example, the default storage medium adopts a partitioned design. Each configuration scenario uniquely corresponds to an independent configuration storage partition, and each partition contains a fixed structure of "header block + data block". Configuration scenario 1 is P1 topology-GPU1, and the standardized configuration template for configuration scenario 1 is T1, corresponding to partition 1. The default storage medium stores the configuration scenario identifier from the standardized configuration template T1 into the header block of partition 1, and stores the address of the register to be configured and the configuration value field from the standardized configuration template T1 into the data block of partition 1. The standardized configuration templates for the other three scenarios are also stored in their respective partitions in the same way.
[0141] Taking the execution processor needing to complete the DNOC configuration of GPU1 under the P1 topology as an example, the process is as follows: Obtain the current configuration requirements (target configuration scenario: P1 topology - GPU1); traverse each configuration storage partition of the preset storage medium and read the configuration scenario identifier of the header block of each partition; when the configuration scenario identifier of the header block of partition 1 is read, complete the scenario matching and lock partition 1; read the address of the register to be configured and the corresponding configuration value information in sequence from the data block of partition 1; perform subsequent operations based on the read configuration information.
[0142] Correspondingly, the aforementioned storage partitioning structure based on configuration scenarios is also applicable in multi-core processor application scenarios. Specifically, the configuration scenario identifier is a combination of "system topology identifier + processor identifier + core identifier". An independent partition is allocated for each of these combinations in the pre-defined storage medium. The header block stores the configuration scenario identifier corresponding to the combination (i.e., "system topology identifier + processor identifier + core identifier"), and the data block stores the register configuration information of the corresponding core. When configuration information needs to be read, the target configuration scenario is located based on the configuration scenario identifier in the header block, and the register configuration information of that core is read from the corresponding data block.
[0143] Based on the standardized configuration template, a standardized storage foundation is built by pre-setting the partitioning of storage media and the fixed block structure. Efficient and accurate information extraction is achieved through standardized processes, making DNOC's register configuration scheme more adaptable to complex multi-processor systems and multi-chip architectures in various scenarios.
[0144] To ensure that the execution processor can accurately parse the register configuration file, this application predefines a standardized format protocol. This protocol clearly specifies the core content of the standardized configuration template and the register configuration file it generates, including field arrangement rules, data encoding methods, and configuration value type identification formats. Regardless of whether the register configuration file is a binary bin file or another format, it must strictly adhere to this predefined format protocol. The format protocol is formulated around the core fields of the standardized configuration template (such as the address and configuration value fields of the registers to be configured related to GPU1 in DNOC when using the P1 topology), ensuring that the execution processor can accurately extract various configuration information according to unified rules.
[0145] This application embodiment also provides a DNOC register configuration device, which is disposed in the execution processor, and the device includes the following modules:
[0146] The information extraction module is used to read a pre-stored register configuration file from a preset storage medium and extract the configuration information of the register to be configured when it is necessary to configure the registers of the DNOC. The register configuration file is obtained by converting the standardized configuration template generated according to the DNOC register configuration rules, filling in the configuration information of the register to be configured.
[0147] The instruction generation module is used to generate configuration instructions that the DNOC can recognize based on the extracted configuration information of the registers to be configured.
[0148] The execution sending module is used to send the configuration instructions to the DNOC to complete the register configuration of the DNOC.
[0149] In some optional implementations, the standardized configuration template is taken from a predefined configuration template database; the configuration template database provides a unique standardized configuration template for each configuration scenario in the multiprocessor system; each standardized configuration template includes at least: a configuration scenario identifier, and register address and configuration value fields of the registers in the DNOC related to the corresponding configuration scenario; the configuration value field provides a standardized placeholder for filling in the corresponding configuration value information when generating the register configuration file; wherein, the configuration scenario refers to a specific hardware environment that requires independent configuration of DNOC registers, jointly defined by the system topology of the multiprocessor system and the target processor; different combinations of system topology and target processor correspond to different configuration scenarios; the target processor is selected from any of the following: a single-chip processor, or a chip within a multi-chip processor.
[0150] In some alternative implementations, the configuration scenario identifier includes a system topology identifier and a target processor identifier.
[0151] In some optional implementations, when the target processor is a single-core processor, the target processor identifier is the processor identifier of the single-core processor; when the target processor is a core within a multi-core processor, the target processor identifier includes the processor identifier of the multi-core processor and the core identifier of the corresponding core.
[0152] In some optional implementations, the configuration value field in the standardized configuration template supports at least one of the following numerical provision formats:
[0153] A constant type that provides a fixed value that can be directly written to a register;
[0154] Expression type, providing an expression that includes at least one computed parameter;
[0155] An enumeration type that provides optional enumeration values to be selected from a predefined set of values.
[0156] In some optional implementations, when the configuration value field is provided in the form of an expression, the method further includes the following steps: obtaining an expression from the extracted configuration information of the register to be configured, and obtaining the current system value of each calculation parameter in the expression; calculating the value of the expression based on the current system value of each calculation parameter, and using the calculation result as the final value of the configuration value field to generate configuration instructions.
[0157] In some optional implementations, the preset storage medium includes multiple configuration storage partitions, each configuration storage partition uniquely corresponding to a configuration scenario. Each configuration storage partition includes: a header block, used to store the configuration scenario identifier corresponding to the configuration scenario for locating and matching the configuration scenario; and a data block, used to store the register addresses and configuration value information of the registers to be configured in the DNOC under the corresponding configuration scenario.
[0158] In some optional implementations, the step of reading a pre-stored register configuration file from a preset storage medium and extracting the configuration information of the register to be configured specifically includes:
[0159] Determine the target configuration scenario identifier based on the current system configuration scenario;
[0160] Locate the target configuration storage partition whose header block contains the target configuration scenario identifier in the preset storage medium;
[0161] Extract the register address and configuration value information of the register to be configured from the data block of the target configuration storage partition.
[0162] The DNOC register configuration device provided in this application adopts the same inventive concept as the aforementioned DNOC register configuration method. Since the principle of this device in solving the problem is similar to that of the method, its implementation can refer to the implementation of the method and achieve the same beneficial effects. Repeated details will not be elaborated further.
[0163] Based on the same inventive concept as the register configuration method of the DNOC described above, embodiments of this application also provide an electronic device, which may include a processor and a memory.
[0164] The processor in the aforementioned electronic device can be a general-purpose processor, such as a central processing unit (CPU), digital signal processor (DSP), application-specific integrated circuit (ASIC), field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components, capable of implementing or executing the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly manifested as being executed by a hardware processor, or executed by a combination of hardware and software modules within the processor.
[0165] Memory, as a non-volatile computer-readable storage medium, can be used to store non-volatile software programs, non-volatile computer-executable programs, and modules. Memory can include at least one type of storage medium, such as flash memory, hard disk, multimedia card, card-type memory, random access memory (RAM), static random access memory (SRAM), programmable read-only memory (PROM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), magnetic memory, magnetic disk, optical disk, etc. Memory is any other medium capable of carrying or storing desired program code in the form of instructions or data structures that can be accessed by a computer, but is not limited to this. The memory in the embodiments of this application can also be a circuit or any other device capable of implementing storage functions for storing program instructions and / or data.
[0166] Those skilled in the art will understand that all or part of the steps of the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it performs the steps of the above method embodiments. The aforementioned computer storage medium can be any available medium or data storage device that a computer can access, including but not limited to: mobile storage devices, random access memory (RAM), magnetic storage (e.g., floppy disks, hard disks, magnetic tapes, magneto-optical disks (MO), etc.), optical storage (e.g., CDs, DVDs, BDs, HVDs, etc.), and semiconductor storage (e.g., ROMs, EPROMs, EEPROMs, non-volatile memory (NAND flash), solid-state drives (SSDs)) and other media capable of storing program code.
[0167] Alternatively, if the integrated units described above in this application are implemented as software functional modules and sold or used as independent products, they can also be stored in a computer-readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, or the parts that contribute to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the methods described in the various embodiments of this application. The aforementioned storage medium includes: mobile storage devices, random access memory (RAM), magnetic memory (e.g., floppy disks, hard disks, magnetic tapes, magneto-optical disks (MO), etc.), optical memory (e.g., CDs, DVDs, BDs, HVDs, etc.), and semiconductor memory (e.g., ROMs, EPROMs, EEPROMs, non-volatile memory (NAND flash), solid-state drives (SSDs), etc.) and other media capable of storing program code.
[0168] The above embodiments are only used to provide a detailed description of the technical solutions of this application. However, the description of the above embodiments is only for the purpose of helping to understand the methods of the embodiments of this application and should not be construed as a limitation on the embodiments of this application. Any changes or substitutions that can be easily conceived by those skilled in the art should be covered within the protection scope of the embodiments of this application.
Claims
1. A register configuration method of a data network on chip (DNOC), characterized in that, The DNOC is used to configure and manage data interconnect paths between multiple target processors in a multiprocessor system, and the method includes the following steps: When it is necessary to configure the registers of the DNOC, a pre-stored register configuration file is read from a preset storage medium and the configuration information of the register to be configured is extracted. The register configuration file is obtained by converting the standardized configuration template generated according to the DNOC register configuration rules, filling in the configuration information of the register to be configured. Based on the extracted configuration information of the registers to be configured, configuration instructions recognizable by the DNOC are generated; The configuration command is sent to the DNOC to complete the register configuration of the DNOC; The standardized configuration template is taken from a predefined configuration template database; The configuration template database provides a unique, standardized configuration template for each configuration scenario in the multiprocessor system. Each of the standardized configuration templates includes at least: a configuration scenario identifier, and register address and configuration value fields of the registers in the DNOC related to the corresponding configuration scenario; the configuration value field provides a standardized placeholder for filling in the corresponding configuration value information when generating the register configuration file; The configuration scenario refers to a specific hardware environment that requires independent configuration of the DNOC register, defined by the system topology of the multiprocessor system and the target processor. Different combinations of system topology and target processor correspond to different configuration scenarios. The target processor is selected from any of the following: a single-core processor or a core within a multi-core processor.
2. The method of claim 1, wherein, The configuration scenario identifier includes the system topology identifier and the target processor identifier.
3. The method of claim 2, wherein, When the target processor is a single-core processor, the target processor identifier is the processor identifier of the single-core processor; when the target processor is a core within a multi-core processor, the target processor identifier includes the processor identifier of the multi-core processor and the core identifier of the corresponding core.
4. The method according to any one of claims 1 to 3, characterized in that, In the standardized configuration template, the configuration value field supports at least one of the following numerical provision formats: A constant type that provides a fixed value that can be directly written to a register; Expression type, providing an expression that includes at least one computed parameter; An enumeration type that provides optional enumeration values to be selected from a predefined set of values.
5. The method of claim 4, wherein, When the numerical value of the configuration value field is provided in the form of an expression type, the method further includes the following steps: The expression is obtained from the configuration information of the register to be configured, and the current system value of each calculated parameter in the expression is obtained. The value of the expression is calculated based on the current system values of each calculation parameter, and the calculation result is used as the final value of the configuration value field to generate configuration instructions.
6. The method according to any one of claims 1 to 3, characterized in that, The preset storage medium includes multiple configuration storage partitions, and each configuration storage partition uniquely corresponds to a configuration scenario. Each configuration storage partition includes: The header block stores the configuration scenario identifier for the corresponding configuration scenario, which is used for locating and matching the configuration scenario; The data block is used to store the register addresses and configuration value information of the registers that need to be configured in the DNOC under the corresponding configuration scenario.
7. The method of claim 6, wherein, The step of reading the pre-stored register configuration file from the preset storage medium and extracting the configuration information of the register to be configured specifically includes: Determine the target configuration scenario identifier based on the current system configuration scenario; Locate the target configuration storage partition whose header block contains the target configuration scenario identifier in the preset storage medium; Extract the register address and configuration value information of the register to be configured from the data block of the target configuration storage partition.
8. A register configuration device for an on-chip data network (DNOC), characterized in that, The DNOC is used to configure and manage data interconnect paths between multiple target processors in a multiprocessor system, and the apparatus includes: The information extraction module is used to read a pre-stored register configuration file from a preset storage medium and extract the configuration information of the register to be configured when the registers of the DNOC need to be configured. The register configuration file is obtained by converting the standardized configuration template generated according to the DNOC register configuration rules, filling in the configuration information of the register to be configured. The instruction generation module is used to generate configuration instructions that the DNOC can recognize based on the extracted configuration information of the registers to be configured. The execution sending module is used to send the configuration instructions to the DNOC to complete the register configuration of the DNOC; The standardized configuration template is taken from a predefined configuration template database; The configuration template database provides a unique, standardized configuration template for each configuration scenario in the multiprocessor system. Each of the standardized configuration templates includes at least: a configuration scenario identifier, and register address and configuration value fields of the registers in the DNOC related to the corresponding configuration scenario; the configuration value field provides a standardized placeholder for filling in the corresponding configuration value information when generating the register configuration file; The configuration scenario refers to a specific hardware environment that requires independent configuration of the DNOC register, defined by the system topology of the multiprocessor system and the target processor. Different combinations of system topology and target processor correspond to different configuration scenarios. The target processor is selected from any of the following: a single-core processor or a core within a multi-core processor.
9. An electronic device comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method as described in any one of claims 1 to 7.