A method for constructing a verification platform for GPU flexible interconnection

Abstract

This application relates to the field of chip verification technology, and in particular to a method for constructing a verification platform for flexible GPU interconnection. It includes: obtaining a topology information description file; the topology information description file includes interconnection information of several topologies and topology information of each design under test (DUT) included in each topology; the DUT is a functional module in the GPU that is interconnected with external systems; instantiating the DUT according to the topology information description file; constructing a verification environment in the test platform that matches the topology in the topology information description file according to a dynamic configuration file; the dynamic configuration file is obtained by parsing the topology information description file; and implementing connections between DUTs and between the DUTs and the verification environment according to the dynamic configuration file. This invention can solve the problems of existing methods, such as fixed verification environment structure, insufficient reusability and scalability, and difficulty in supporting verification of multiple types of DUTs and various interconnection topologies and interconnection modes.

Description

Technical Field

[0001] This invention relates to the field of chip verification technology, and in particular to a method for constructing a verification platform for flexible GPU interconnection. Background Technology

[0002] With the rapid development of high-performance computing, artificial intelligence, data centers, and cloud computing, GPUs, as core accelerators, are widely used in servers and computing nodes. To achieve high-speed interconnection between multiple GPUs, PCIe is extensively used as the interconnection solution in system architecture. The multiple PCIe interfaces used in GPUs can not only connect and communicate with the host, but also directly interconnect with other GPU chips, or connect to switch chips to achieve multi-point interconnection.

[0003] The aforementioned diverse interconnect structures and application scenarios place higher demands on chip design verification, particularly the construction of verification platforms. Users must not only verify the functional integrity of individual PCIe modules or subsystems but also their configuration, data interaction, protocol interaction, and hardware behavior under different topologies. Complex interconnect topologies and usage scenarios necessitate the construction of matching system verification platforms. This ensures that potential design flaws are identified and fixed before chip tape-out, board mass production, and large-scale cluster deployment. Furthermore, such verification platforms, which more closely approximate the actual system topology, help front-end design engineers and architects verify whether system-level solutions meet expectations.

[0004] Existing methods for building verification platforms have the following problems: Traditional verification environments suffer from fixed structures and insufficient reusability. Industry-standard test platforms often only support rigid connections between a single GPU and a single Bus Functional Model (BFM). When verifying real-world interconnection scenarios such as GPU-to-GPU interconnection, multi-GPU interconnection via a switch, or multi-GPU interconnection via bifurcation, each new test scenario requires manual modification of the GPU and BFM instantiation and connection methods in the testbench. This results in multiple environments coexisting, making reuse impossible and exponentially increasing maintenance costs.

[0005] Manual modifications can lead to mismatches or omissions. Complex interconnect scenarios often require system-level configurations, such as the internal drive signal settings and initialization configurations for the PCIe subsystems within a chip system under a specific topology, and the configurations of external chips for each PCIe subsystem (such as address space allocation). Traditional verification platforms often scatter various settings across different locations on the platform, which can easily cause configuration mismatches or omissions when some parameters need to be adjusted.

[0006] Unable to quickly respond to changes in architecture or system applications. GPU interconnect solutions are often flexible and changeable. When the system architecture proposes new interconnect application scenario requirements, traditional methods often require a long period of time to build a complete environment to meet the design requirements. Once the solution is adjusted, efforts need to be re-invested to complete it, ultimately resulting in the new solution not receiving front-end verification support and failing to be implemented. Summary of the Invention

[0007] The purpose of this invention is to provide a method for constructing a verification platform for flexible GPU interconnection, so as to solve the above-mentioned problems existing in the existing verification platform construction methods.

[0008] According to the present invention, a method for constructing a verification platform for flexible GPU interconnection is provided, the method comprising the following steps: S100, Obtain the topology information description file; the topology information description file includes interconnection information of several topologies and topology information of each topology and each design under test; the design under test is a functional module in the GPU that is interconnected with the outside. S200, instantiate the design under test based on the topology information description file; S300, construct a verification environment in the test platform that matches the topology in the topology information description file according to the dynamic configuration file; the dynamic configuration file is obtained by parsing the topology information description file; S400, based on the dynamic configuration file, enables connections between designs under test and between designs under test and the verification environment.

[0009] Compared with the prior art, the present invention has at least the following beneficial effects: In this invention, the topology information description file includes interconnection information for several topologies and topology information for each design under test (DUT) within each topology. Based on the topology information description file, the DUT can be instantiated, and a verification environment matching the topologies in the topology information description file can be generated based on a dynamic configuration file obtained from parsing the topology information description file. This also enables connections between DUTs and between the DUTs and the verification environment. Compared to existing technologies where verification engineers need to manually rewrite or modify the test platform for each GPU interconnect topology tested, this invention is applicable to different GPU interconnect topologies. Only one topology information description file needs to be written to automatically generate the verification platform. This solves the problems of fixed verification environment structure, insufficient reusability and scalability in existing technologies, difficulty in supporting multiple types of DUTs and multiple interconnect topologies and interconnection modes, manual modifications leading to mismatches or omissions, and inability to quickly respond to changes in architecture or system applications. Attached Figure Description

[0010] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0011] Figure 1 A flowchart illustrating the construction method of a verification platform for flexible GPU interconnection provided in an embodiment of the present invention; Figure 2 This is a schematic diagram illustrating the connection between designs under test when at least two designs under test are interconnected via a switch, as provided in an embodiment of the present invention. Detailed Implementation

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

[0013] According to this embodiment, a method for constructing a verification platform for flexible GPU interconnection is provided. The method includes the following steps: Figure 1 As shown: S100, Obtain the topology information description file; the topology information description file includes interconnection information of several topologies and topology information of each topology and each design under test; the design under test is a functional module in the GPU that is interconnected with the outside.

[0014] In one specific implementation, the topology information description file is obtained by the user after filling it in according to the format requirements. In this embodiment, the design under test (DUT) is the functional module (IP) in the GPU that is interconnected with the outside world.

[0015] As one specific implementation, the interconnection information includes at least one of the following: topology type, number of DUTs, hardware module name of the DUT module, instance name of the DUT instance, type of the DUT, operating mode of the DUT, connection method of the DUT, and address range allocated to the DUT. As one specific implementation, the interconnection information of a topology is: Topology type: topo_0 DUT Number: 2 DUT Module: Module_0, Module_1 DUT Intance name: DUT_0, DUT_1 DUT Type: Endpoint, dualmode DUT Mode: mgpu_mode, rc_mode Connection:direct Address Range:{ DUT_0, BAR0, 0x00000000_00000000-0xFFFFFFFF_FFFFFFFF}, {DUT_1, host, 0x00000000_00000000-0xFFFFFFFF_FFFFFFFF}.

[0016] As another specific implementation, the interconnection method information of a topology is as follows: Topology type: topo_1 DUT Number: 3 DUT Module: Module_0, Module_1, Module_1 DUT Intance name: DUT_0, DUT_1, DUT_2 DUT Type: Endpoint, dualmode, dualmode DUT Mode: mgpu_mode, ep_mode, ep_mode Connection: switch Address Range:{ DUT_0, BAR0, 0x0000_0000_0000_0000-0x0000_0000_FFFF_FFFF}, {DUT_1, BAR0, 0x0000_0001_0000_0000-0x0000_0001_FFFF_FFFF}, {DUT_2, BAR1, 0x0000_0002_0000_0000-0x0000_0002_FFFF_FFFF}.

[0017] In one specific implementation, the topology information of the design under test (DUT) includes at least one of the following: DUT Name, DUT Version, DUT Type, parameters of the links supported by the DUT, bus information of the DUT, and hardware characteristic information of the DUT. In another specific implementation, the parameters of the links supported by the DUT include Linkwidth, Speed, and Max Payload Size. The bus information of the DUT includes the total number of interfaces, interface name, interface protocol, interface type, data width, and maximum outstanding transactions. The hardware characteristic information of the DUT includes Bar Number, Bar Size, Bar Type, number of physical functions (PF Number), and number of virtual functions (VF Number).

[0018] As a specific implementation, the topology information of one of the designs under test in a topology is as follows: DUT Name: DUT_0 DUT Version: 1.0 DUT Type: Endpoint Linkwidth: ×16 Speed: GEN5 Max Payload Size: 512 Interface number: 5 Interface Name: AXI_MST_0, AXI_MST_1, AXI_SLV_0, SENDFREE_SLV_0,SENDFREE_SLV_1 Interface Protocol: AXI4, AXI4, AXI4, SENDFREE, SENDFREE Interface Type: Master, Master, Slave, Slave, Slave Data Width: 512, 512, 256, 32, 32 Outstanding: 256, 256, 512, 8, 16 Bar Number: 0, 1, 2, 3, 4, 5 Bar Size: 64G, 0, 32G, 0, 0, 0 Bar Type: Prefetchable, None, Prefetchable, None, None, None PF Number: 1 VF Number: 4 As a specific implementation, the design under test (DUT) is connected in any of the following ways: the DUT is connected to the interface functional model (e.g., single GPU mode, SGPU_MODE) as the end point of the interface; the DUT is connected to an external device as the root complex (RC) of the interface; at least two DUTs are directly connected via the interface (e.g., two DUTs are directly connected via the interface, MGPU_P2P_MODE); at least two DUTs are interconnected via a switch (MGPU_SWITCH_MODE); or the DUT is connected to at least two other DUTs via bifurcation.

[0019] As a specific implementation, the interface protocol type is an interface protocol that supports point-to-point interconnection, including PCIe protocol and CXL protocol, etc.

[0020] S200 instantiates the design under test based on the topology information description file.

[0021] As a specific implementation, the interconnection information of the topology includes the number of designs under test, the hardware module name of the designs under test, and the instantiation name of the designs under test; S200 includes: for any topology included in the topology information description file: S201, obtain the number of designs under test included in the topology, the hardware module name of the design under test, and the instantiation name of the design under test.

[0022] S202, Generate the same number of instantiation statements as the number of designs under test included in the topology; each instantiation statement includes a hardware module name to be written and an instantiation name to be written.

[0023] S203, write the hardware module name and instantiation name of the design under test included in the topology into the instantiation statement respectively.

[0024] As a specific implementation, when the topology is topo_1 as described above, the three instantiation statements obtained by executing S201-S203 are as follows: module_0 dut_0(); module_1 dut_1(); module_1 dut_2(); It should be understood that the first instantiation statement above corresponds to the hardware module name module_0, and the instantiation name is dut_0; the second instantiation statement above corresponds to the hardware module name module_1, and the instantiation name is dut_1; the third instantiation statement above corresponds to the hardware module name module_1, and the instantiation name is dut_2.

[0025] In this embodiment, the above-mentioned S201-S203 process can be implemented directly by writing a script, or: (1) the topology information description file can be parsed by writing a script to obtain a static configuration file including the static configuration information of each topology. The static configuration information of each topology exists in the form of macro definitions. The static configuration information includes: the number of designs under test, the hardware module name of the design under test, and the instantiation name of the design under test; (2) the instantiation process of the design under test can be implemented by the static configuration file and the top-level instantiation file hdl_top.v of the hardware description. Among them, hdl_top.v includes the instantiation statements corresponding to all connection methods. The user side can control the macro definition of one topology in the static configuration file to take effect through additional macro definitions during the compilation stage. The effective macro definition will control hdl_top.v to generate the instantiation statement of the topology corresponding to the effective macro definition selected by the user side. For example, the user side controls the topology corresponding to the effective macro definition in the static configuration file to be 3 designs under test connected by a switch through additional macro definitions during the compilation stage. Figure 2 As shown.

[0026] S300: Based on the dynamic configuration file, a verification environment matching the topology in the topology information description file is constructed in the test platform; the dynamic configuration file is obtained by parsing the topology information description file.

[0027] As a specific implementation method, a script is used to parse the topology information description file and generate a dynamic configuration file. The topology information description file is in JSON or table format, which cannot be directly parsed by the verification platform. The dynamic configuration file uses a data structure that the verification platform can recognize, and includes information on the interconnection method of the topology and the topology information of each tested design.

[0028] In this embodiment, the dynamic configuration file is as follows: class sys_topo_info extends topo_info_c; ... int dut_number[$]; string dut_module_name[$]; string dut_inst_name[$]; string dut_type[$]; string dut_mode[$]; addr_range_t addr_range[$]; ... function new(); ... dut_module_name.push_back(“module_0”); dut_module_name.push_back(“module_1”); dut_module_name.push_back(“module_1”); ... addr_range.push_back('{}) ... endfunction endclass The code above defines a class named `sys_topo_info`, which inherits from the basic topology information class `topo_info_c`. `sys_topo_info` is a container for dynamic topology configuration information, used to store and transmit the topology configuration of the entire system in the UVM verification environment. The contents of `sys_topo_info` include: it declares multiple dynamic arrays / queues (such as `dut_type[$]`, `addr_range[$]`) to store a variable number of DUT information; in the `new()` constructor, the code uses the `push_back` method to populate the queues with the specific configuration values ​​extracted from the topology information description file by the parsing script; for example, `dut_module_name.push_back("module_0")` indicates that the hardware module used by the first DUT is `module_0`; `addr_range.push_back('{})` populates the detailed address mapping relationship (not fully expanded in the code snippet). The object of the sys_topo_info class will eventually be put into UVM's config_db, which can be queried and used by various components in the entire verification environment (such as environment classes and agents), so that the verification environment can know the specific topology of the current simulation.

[0029] As a preferred embodiment, constructing a verification environment matching the topology in the topology information description file within the test platform based on the dynamic configuration file includes: simulating the dynamic configuration file corresponding to a topology in the topology information description file and a pre-built unified verification environment class together to generate a verification environment matching the topology in the topology information description file; wherein, the component types, quantities, and parameter configurations to be generated within the verification environment matching the topology in the topology information description file are determined based on the information of the topology in the dynamic configuration file. As a specific embodiment, a portion of the code for the unified verification environment class is as follows: class pciex_env extends uvm_env; topo_info m_topo; ... axi_agent axi_intf[$]; sendfree_agent sendfree_intf[$]; ... function void build_phase(uvm_phase phase); ... if(!uvm_config_db#(topo_info)::get(this,””,”topo_info”,m_topo)) `uvm_fatal(“”,”topo_info not found”) ... if_cfg_t ifs; m_topo.get_interface_by_type(“AXI4”, ifs); foreach(ifs[i])begin string inst_name = ifs[i].instance_name; axi_agent ag; ag = axi_agent::type_id::crate(inst_name, this); ag.cfg.data_width = ifs.data_width; ... axi_intf.push_back(ag); end endfunction ... endclass In the code above, `pciex_env` serves as a unified verification environment class. The specific composition of its internal components is not fixed during coding but dynamically determined at runtime based on externally injected configuration data. The code for the `pciex_env` class is a fixed template; it only defines containers (queues) for a series of potentially used component types (such as `axi_agent`, `sendfree_agent`). However, its runtime behavior (how many agents are created, what type of agents are created, and how each agent is configured) is entirely driven by the passed-in `topo_info` object (which is the dynamic configuration file mentioned above), thus achieving the flexibility of adapting a single environment class to multiple DUT configurations. The implementation principle of the above code is as follows: Obtaining configuration: In the `build_phase`, the environment obtains the globally shared `topo_info` object (i.e., an instance of `sys_topo_info`) through the `uvm_config_db::get` method. This ensures that all environment instances act based on the same set of topology information. Query and Decision: The environment calls methods such as `m_topo.get_interface_by_type(“AXI4”, ifs)` to retrieve a detailed configuration list of all required interfaces of a specific type (e.g., AXI4) from the topology information object. Dynamic Creation and Configuration: The configuration list is iterated through using a foreach loop. For each item in the list (representing a specific physical interface), a corresponding agent instance is dynamically created using the UVM factory (`axi_agent::type_id::create`). Simultaneously, the newly created agent is customized based on specific parameters in the configuration (e.g., `data_width`). Storage Management: The created agent instances are stored in a dynamic array (e.g., `axi_intf[$]`) for use in the subsequent connection phase.

[0030] Therefore, the verification platform (Testbench) can generate a verification environment for each DUT based on the configuration information related to each DUT in the dynamic configuration file, thus generating components of the test platform. The advantages of using a unified verification environment class to generate verification environments for all DUTs included in the target topology are: extremely high code reusability: There is no need to write and maintain different environment classes for each DUT type or topology scenario; a single codebase can cover all situations, significantly reducing development and maintenance costs. Guaranteed architectural consistency: All generated verification environments have identical component structures and interfaces, allowing test cases, scoreboards, and other upper-level components to be seamlessly reused across different environments, improving the overall consistency of the platform. Easy maintenance and upgrades: Any improvements to verification methods or components only need to be modified in one place (in the unified pciex_env class) to be automatically applied to all verification environments generated based on different topologies.

[0031] S400, based on the dynamic configuration file, enables connections between designs under test and between designs under test and the verification environment.

[0032] In this embodiment, the top-level step in S300 only instantiates the design under test (DUT), without connecting the DUTs to each other or to the verification environment; the connection work is completed on the test platform. As a specific implementation, S400 includes: for the connection between the DUT and the verification environment, using either bind or force methods.

[0033] As a specific implementation, S400 includes: for the connection between the designs under test, when the connection method of the designs under test is that at least two designs under test are directly connected through an interface, setting the interface function model (BFM) inside the environment to passive mode, and directly connecting the differential interfaces of the two designs under test.

[0034] As a preferred embodiment, S400 includes: for the connection between designs under test (DUTs), when the connection method involves at least two DUTs interconnected via an interface switch, setting the Interface Function Model (BFM) within the environment of one of the DUTs to active mode to act as an interface switch, and simultaneously connecting the DUT to the corresponding port of the interface function model according to its location in the topology configuration data file, and passing the interface function model handle to the environments of other DUTs via a configuration database (config_db). Figure 2As shown, ENV_0, ENV_1, and ENV_2 are the verification environments for DUT_0, DUT_1, and DUT_2, respectively. This preferred implementation has the following advantages: Resource optimization and behavior uniqueness: Only one active switch model needs to be instantiated and managed in the entire system, avoiding the resource waste and potential behavior inconsistencies caused by instantiating a BFM for each DUT. All communication via the switch is handled by this single entity, ensuring the correctness and consistency of system-level interaction logic. Achieving efficient centralized routing: The simulated switch's BFM can act as a global routing center, possessing complete port mapping and routing table information. All other passive BFMs in all environments only need to send transactions to this central handle, which is responsible for accurately forwarding them to the target port, clearly simulating the centralized switching architecture of a real switch. Simplified connection and configuration management: Other environments do not need to concern themselves with complex physical connection topologies; they only need to obtain this shared BFM handle and communicate with it. This simplifies the connection logic and configuration complexity within the verification platform, making the platform easier to build and debug.

[0035] Based on S400, this embodiment implements the connection process of the test platform and completes the construction process of the test platform. Subsequently, users can conduct tests based on the constructed test platform and the written test cases.

[0036] As a specific implementation method, users can write test cases based on the constructed verification platform and control the constraints of test incentives.

[0037] This embodiment can generate static configuration information required for instantiating the design under test and dynamic configuration information required for the verification environment and connections by parsing the topology information description file, thereby realizing the automatic construction of the verification platform. Compared with the existing technology, which requires verification engineers to manually rewrite or modify the test platform for each GPU interconnect topology to be tested, this embodiment is applicable to different GPU interconnect topologies. Only one topology information description file needs to be written. By automatically parsing the file, the verification platform can be automatically generated. This solves the problems of fixed verification environment structure, insufficient reusability and scalability in the existing technology, which makes it difficult to support the verification of multiple types of designs under test and multiple interconnect topologies and interconnect modes. Manual modification leads to mismatch or omissions and cannot quickly respond to changes in architecture or system applications.

[0038] While specific embodiments of the invention have been described in detail by way of example, those skilled in the art should understand that the examples are for illustrative purposes only and not intended to limit the scope of the invention. It should also be understood that various modifications can be made to the embodiments without departing from the scope and spirit of the invention. The scope of the invention is defined by the appended claims.

Claims

1. A method for constructing a verification platform for flexible GPU interconnection, characterized in that, The method includes the following steps: S100, Obtain the topology information description file; the topology information description file includes interconnection information of several topologies and topology information of each topology and each design under test; the design under test is a functional module in the GPU that is interconnected with the outside. S200, instantiate the design under test based on the topology information description file; S300, construct a verification environment in the test platform that matches the topology in the topology information description file according to the dynamic configuration file; the dynamic configuration file is obtained by parsing the topology information description file; S400, based on the dynamic configuration file, enables connections between designs under test and between designs under test and the verification environment.

2. The method for constructing a verification platform for flexible GPU interconnection according to claim 1, characterized in that, The interconnection information of the topology includes the number of designs under test, the hardware module names of the designs under test, and the instantiation names of the designs under test; S200 includes: for any topology included in the topology information description file: S201, obtain the number of designs under test included in the topology, the hardware module name of the designs under test, and the instantiation name of the designs under test; S202, Generate the same number of instantiation statements as the number of designs under test included in the topology; each instantiation statement includes a hardware module name to be written and an instantiation name to be written. S203, write the hardware module name and instantiation name of the design under test included in the topology into the instantiation statement respectively.

3. The method for constructing a verification platform for flexible GPU interconnection according to claim 1, characterized in that, Building a verification environment in the test platform that matches the topology in the topology information description file according to the dynamic configuration file includes: Simulate the dynamic configuration file corresponding to a topology in the topology information description file together with a pre-built unified verification environment class to generate a verification environment that matches the topology in the topology information description file; wherein, the component types, quantities and parameter configurations to be generated within the verification environment that matches the topology in the topology information description file are determined according to the information of the topology in the dynamic configuration file.

4. The method for constructing a verification platform for flexible GPU interconnection according to claim 1, characterized in that, The S400 includes: For the connection between designs under test, when the connection method of the designs under test is that at least two designs under test are interconnected through a switch, the interface function model inside the verification environment of one of the designs under test is set to active mode to act as a switch. At the same time, according to the location of the design under test in the dynamic configuration file, the design under test is connected to the corresponding port of the interface function model, and the handle of the interface function model is passed to the verification environment of other designs under test through the configuration database.

5. The method for constructing a verification platform for flexible GPU interconnection according to claim 1, characterized in that, The interconnection information includes at least one of the following: topology type, number of designs under test, hardware module name of the design under test, instantiation name of the design under test, type of the design under test, working mode of the design under test, connection method of the design under test, and address space allocated to the design under test; the topology information of the design under test itself includes at least one of the following: name of the design under test, version of the design under test, type of the design under test, parameters of the links supported by the design under test, bus information of the design under test, and hardware characteristic information of the design under test.

6. The method for constructing a verification platform for flexible GPU interconnection according to claim 5, characterized in that, The connection method of the design under test is any of the following: the design under test is connected to the interface functional model as the end device of the interface; the design under test is connected to an external device as the root complex of the interface; at least two designs under test are directly connected through the interface. At least two designs under test are interconnected via a switch; the designs under test are connected to at least two other designs under test via a branching mechanism.

7. The method for constructing a verification platform for flexible GPU interconnection according to claim 1, characterized in that, The dynamic configuration file adopts a data structure that the verification platform can recognize. The dynamic configuration file includes the interconnection information of the topology and the topology information of each design under test.

8. The method for constructing a verification platform for flexible GPU interconnection according to claim 1, characterized in that, The S400 includes: For connections between designs under test, when the connection method of the designs under test is that at least two designs under test are directly connected through an interface, the interface function model inside the environment is set to passive mode, and the differential interfaces of the two designs under test are directly connected.

9. The method for constructing a verification platform for flexible GPU interconnection according to claim 1, characterized in that, The S400 includes: For the connection between the design under test and the verification environment, the bind or force method is used.

10. The method for constructing a verification platform for flexible GPU interconnection according to claim 4, characterized in that, The interface protocol type is a peer-to-peer interconnection interface protocol, which includes PCIe protocol and CXL protocol.

Images