Multi-port concurrent testing method, apparatus, device, and storage medium

Abstract

The application discloses a multi-port concurrent test method and device, equipment and storage medium, and belongs to the technical field of integrated circuits. The application realizes independent controllability of each port test process, greatly improves the accuracy and reliability of the test result. First, the parameter confusion problem is avoided from the source by replacing the command line parameter passing mode with a configuration file. Second, in the test preparation stage, for any port to be tested, the scheme randomly or on demand obtains the port configuration information of a certain test case from the configuration file, and stores the mapping relationship between the port and the corresponding port configuration information. In this way, in the test running stage, each test case can obtain correct port configuration information based on the mapping relationship when executing, and generate an excitation sequence accordingly. Therefore, the test platform can accurately match the independent test requirements of each port, ensuring the accuracy and reliability of the test result.

Description

Technical Field

[0001] This application relates to the field of integrated circuit technology, and in particular to a multi-port concurrent testing method, apparatus, device, and storage medium. Background Technology

[0002] Chip design refers to the design of integrated circuits such as ASICs (Application Specific Integrated Circuits) and SOCs (System-On-Chip). After the chip design is completed and before tape-out manufacturing, simulation verification (also known as testing) is performed on the chip to verify whether it meets the expected specifications.

[0003] For chips under test (DUTs) with multiple ports, the mode or state of one port may affect the functionality of other ports. Therefore, multi-port concurrency testing is required during the testing phase. Multi-port concurrency testing involves simultaneously initiating parallel access to multiple ports of the DUT to simulate multi-service concurrency in a real-world scenario, thereby verifying the functional correctness, timing stability, and reliability of the DUT when multiple ports are operating in parallel.

[0004] Because multi-port concurrent testing involves the parallel execution of multiple test cases, command-line arguments (+plusargs) often conflict between different test cases. For example, after reading configuration information (including configuration parameters and their values) from the command line using the `$value$plusargs` function, the testing platform cannot distinguish which test case each configuration belongs to, causing interference between configuration information from different ports. This prevents the testing platform from accurately matching the independent testing requirements of each port, severely impacting the accuracy and reliability of test results. Therefore, for multi-port concurrent testing, how to achieve independent and controllable testing processes for each port to improve the accuracy and reliability of test results has become a problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0005] This application provides a multi-port concurrent testing method, apparatus, device, and storage medium. The technical solution is shown below.

[0006] On the one hand, a multi-port concurrent testing method is provided, the method comprising: Obtain the configuration file, which includes port configuration information for multiple test cases. These multiple test cases are executed concurrently during the test run phase. The port configuration information includes port running parameters and their values. During the test preparation phase, for any port on the chip under test to be tested, a test case is assigned to the port, the port configuration information corresponding to the assigned test case is obtained from the configuration file, and the mapping relationship between the port and the obtained port configuration information is stored. During the test run phase, the multiple test cases are executed concurrently. For any test case, when the test case is executed, the port configuration information of the corresponding port is obtained based on the mapping relationship, a stimulus sequence is generated according to the port configuration information, and the stimulus sequence is sent to the port to test the port.

[0007] In some embodiments, storing the mapping relationship between the port and the acquired port configuration information includes: The obtained port configuration information is converted into a first type array; the first type array uses the port identifier and the port operating parameters as keys, and the parameter values ​​of the port operating parameters as values; Extract the running parameters and their values ​​from the first type array, and store the extracted running parameters and their values ​​into the second type array of the port; When the test case is executed, it obtains the port configuration information of the corresponding port based on the mapping relationship, including: When the test case is executed, it retrieves the port configuration information of the corresponding port from the second type array of the corresponding port.

[0008] In other embodiments, the second type array of the ports is stored within a UVM (Universal Verification Methodology) component; the UVM component is a static component that runs as a singleton throughout the testing process.

[0009] In other embodiments, the test cases, when executed, obtain port configuration information of the corresponding port based on the mapping relationship, including: When the test case is executed, it retrieves the port configuration information of the corresponding port by calling the component and based on the mapping relationship; wherein the calling component is implemented using macro definition, and the macro is integrated into the test case.

[0010] In other embodiments, obtaining the port configuration information corresponding to the assigned test cases from the configuration file includes: Obtain the port configuration information of the multiple test cases from the configuration file, and store the port configuration information of the multiple test cases into a queue; Retrieve the port configuration information corresponding to the assigned test cases from the queue.

[0011] In other embodiments, obtaining the port configuration information of the plurality of test cases from the configuration file and storing the port configuration information of the plurality of test cases in a queue includes: The port configuration information of the multiple test cases is obtained from the configuration file using the SV (systemverilog) component, and the port configuration information of the multiple test cases is stored in a queue. The SV component is created during the test preparation phase and is a static component that runs as a singleton throughout the entire test process.

[0012] On the other hand, a multi-port concurrent testing device is provided, the device comprising: The first acquisition unit is configured to acquire a configuration file, which includes port configuration information for multiple test cases. The multiple test cases are executed concurrently during the test run phase. The port configuration information includes port running parameters and their values. The second acquisition unit is configured to, during the test preparation phase, assign test cases to any port to be tested on the chip under test, and obtain port configuration information corresponding to the assigned test cases from the configuration file. The storage unit is configured to represent the mapping relationship between the port and the acquired port configuration information; The test unit is configured to concurrently execute the plurality of test cases during the test run phase. For any test case, when the test case is executed, it obtains the port configuration information of the corresponding port based on the mapping relationship, generates a stimulus sequence according to the port configuration information of the port, and sends the stimulus sequence to the port to test the port.

[0013] In some embodiments, the storage unit is configured as follows: The obtained port configuration information is converted into a first type array; the first type array uses the port identifier and the port operating parameters as keys, and the parameter values ​​of the port operating parameters as values; Extract the running parameters and their values ​​from the first type array, and store the extracted running parameters and their values ​​into the second type array of the port; When the test case is executed, it obtains the port configuration information of the corresponding port based on the mapping relationship, including: When the test case is executed, it retrieves the port configuration information of the corresponding port from the second type array of the corresponding port.

[0014] In other embodiments, the second type array of the ports is stored within a UVM component; the UVM component is a static component that runs as a singleton throughout the testing process.

[0015] In other embodiments, the test cases, when executed, obtain port configuration information of the corresponding port based on the mapping relationship, including: When the test case is executed, it retrieves the port configuration information of the corresponding port by calling the component and based on the mapping relationship; wherein the calling component is implemented using macro definition, and the macro is integrated into the test case.

[0016] In other embodiments, the first acquisition unit is configured to: Obtain the port configuration information of the multiple test cases from the configuration file, and store the port configuration information of the multiple test cases into a queue; Retrieve the port configuration information corresponding to the assigned test cases from the queue.

[0017] In other embodiments, the first acquisition unit is configured to: The SV component is used to obtain the port configuration information of the multiple test cases from the configuration file and store the port configuration information of the multiple test cases in a queue. The SV component is created during the test preparation phase and is a static component that runs as a singleton throughout the entire test process.

[0018] On the other hand, a computer device is provided, the device including a processor and a memory, the memory storing computer program code, the computer program code being loaded and executed by the processor to implement the above-described multi-port concurrent testing method.

[0019] On the other hand, a computer-readable storage medium is provided, wherein computer program code is stored in the storage medium and is loaded and executed by the processor of a computer device to implement the above-described multi-port concurrent testing method.

[0020] On the other hand, a computer program product is provided, the computer program product including computer program code stored in a computer-readable storage medium, a processor of a computer device reading the computer program code from the computer-readable storage medium, the processor executing the computer program code, causing the computer device to perform the above-described multi-port concurrent testing method.

[0021] The multi-port concurrent testing solution provided in this application achieves independent and controllable testing processes for each port, significantly improving the accuracy and reliability of test results. First, this solution replaces command-line parameter passing with configuration files, thus avoiding parameter confusion at the source. Second, during the test preparation phase, for any port to be tested, this solution randomly or on-demand retrieves the port configuration information of a specific test case from the configuration file and stores the mapping relationship between that port and the retrieved port configuration information. Thus, during the test execution phase, each test case, when executed concurrently, can obtain the correct port configuration information based on this mapping relationship and generate a stimulus sequence accordingly. The generated stimulus sequence is then sent to the corresponding port, enabling testing of each port. Because this solution ensures that each test case only calls its own proprietary configuration information during execution, the testing platform can accurately match the independent testing needs of each port, ensuring the accuracy and reliability of the test results. Attached Figure Description

[0022] To more clearly illustrate the technical solutions in the embodiments of this application, 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 this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0023] Figure 1 This is a schematic diagram of an architecture for multi-port concurrent testing provided in an embodiment of this application; Figure 2 This is a schematic diagram illustrating the execution process of a VCS command during the parallel execution of multiple test cases, as provided in an embodiment of this application. Figure 3 This is a schematic diagram illustrating a command-line parameter conflict problem between different test cases provided in an embodiment of this application; Figure 4 This is a schematic diagram of an implementation environment provided in an embodiment of this application; Figure 5 This is a flowchart of a multi-port concurrent testing method provided in an embodiment of this application; Figure 6 This is a data flow diagram showing how each port independently obtains configuration information, as provided in the embodiments of this application. Figure 7 This is a schematic diagram of the structure of a multi-port concurrent testing device provided in an embodiment of this application; Figure 8 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0024] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0025] In this application, the terms "first," "second," etc., are used to distinguish identical or similar items that have essentially the same function. It should be understood that there is no logical or temporal dependency between "first," "second," and "nth," nor does it limit the quantity or execution order. It should also be understood that although the following description uses the terms "first," "second," etc., to describe various elements, these elements should not be limited by the terms.

[0026] These terms are simply used to distinguish one element from another. For example, without departing from the various examples, the first element can be referred to as the second element, and similarly, the second element can be referred to as the first element. Both the first and second elements can be elements, and in some cases, they can be separate and distinct elements.

[0027] "At least one" refers to one or more elements. For example, at least one element can be one element, two elements, three elements, or any integer number of elements greater than or equal to one. "Multiple" refers to two or more elements. For example, multiple elements can be two elements, three elements, or any integer number of elements greater than or equal to two.

[0028] In this article, "and / or" indicates that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. The character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0029] The abbreviations and key terms used in the embodiments of this application will be introduced below.

[0030] UVM (Universal Verification Methodology) is a methodology and framework for building standardized, automated, and highly reusable verification environments. Verification environments built on UVM allow for flexible decomposition and combination of verification components, enabling efficient reuse across different projects and levels.

[0031] VCS (Verilog Compiler Simulator) is a high-performance digital circuit simulation tool that uses a compiled simulation architecture. It can pre-compile hardware description language code such as Verilog / SystemVerilog into highly optimized binary executables, making it suitable for large-scale design and complex verification environments.

[0032] PCIe (Peripheral Component Interconnect Express) is a high-speed parallel component interconnect interface protocol that provides high-bandwidth, low-latency, and scalable point-to-point interconnection between the motherboard and peripherals.

[0033] CXL (Compute Express Link): An open, high-speed, cache-coherent interconnect standard based on the PCIe physical layer. It adds cache coherency and memory semantics protocols to PCIe, enabling memory space sharing and hardware-level data synchronization between the CPU and peripherals.

[0034] A test case is the basic execution unit in the testing process. It verifies the correctness of the chip design's functionality, performance, or port behavior by setting preset stimuli, configuring parameters, and setting expected results in a reproducible manner.

[0035] testlist: refers to a list containing all test cases to be executed.

[0036] +uvm_testname: VCS simulation command-line parameter, which supports dynamically specifying the test cases for this simulation run.

[0037] The `$value$plusargs` function is a commonly used system function in Verilog and SystemVerilog, used to read command-line arguments during the simulation run phase to achieve dynamic configuration of the simulation stimulus verification environment.

[0038] As mentioned earlier, chip simulation and verification is a crucial step in the integrated circuit design process. This step requires building a verification platform based on the SystemVerilog language and UVM, and using simulation tools such as VCS to compile and simulate the DUT (Design Under Test). After one compilation, the same test case can be executed repeatedly. The verification environment is the core component of the verification platform, and the platform also includes other verification resources.

[0039] Additionally, the IEEE standard provides the `$value$plusargs` function, which allows the verification environment to retrieve different `+plusargs` values ​​from the command line each time a simulation starts, thereby simulating different test scenarios. It should be noted that `+plusargs` is referred to as configuration information in this document, which includes configuration parameters and their values; the configuration parameters are also referred to as configuration items, and correspondingly, the parameter values ​​are referred to as the parameter values ​​corresponding to the configuration items.

[0040] Taking interface-type IPs as an example, a PCIe IP (PCIe controller IP core) can support 8 ports, and a CXL Switch (a high-speed switching device supporting the CXL protocol) also has multiple external ports with identical functions. In actual verification, it is usually necessary to verify concurrent scenarios where multiple ports simultaneously send and receive data. To this end, in the pre-silicon verification stage, the same test case can be copied multiple times and driven to different ports respectively to achieve concurrent testing of multi-port parallel sending and receiving.

[0041] For example, Figure 1 This is a schematic diagram of a multi-port concurrent testing architecture provided in an embodiment of this application. Figure 1 In the CXL interface, the first layer includes three test cases: case0, case1, and case2. These three test cases all inherit from the second layer's `base_test` class. `base_test` is the base test class and the parent class of these three test cases. The third layer is the Device Underlying Unit (DUT), which integrates three independent CXL host / device ports: `CXL_PortA`, `CXL_PortB`, and `CXL_PortC`. Each port can be configured with an independent operating mode; for example, `CXL_PortA` can be configured in PCIe mode, `CXL_PortB` in CXL non-Flit mode, and `CXL_PortC` in CXL Flit mode. Additionally, `PCS` is the Physical Coding Sublayer, and `PHY` is the Physical Layer; together, they constitute the underlying physical transmission path of the CXL interface.

[0042] The bottom layer includes three CXL / PCIe authentication IPs: VIP 0, VIP 1, and VIP 2. These are used to simulate the behavior of CXL hosts / devices and PCIe devices: VIP 0 sends a protocol-compliant stimulus to CXL_PortA and receives a DUT response for protocol checking; VIP 1 sends a protocol-compliant stimulus to CXL_PortB and receives a DUT response for protocol checking; VIP 2 is used to send a protocol-compliant stimulus to CXL_PortB and receive a DUT response for protocol checking.

[0043] To enable multiple test cases to drive multiple ports in parallel during a single simulation, dynamic configuration is currently achieved through a command-line argument parsing mechanism: the `$value$plusargs` function reads configuration information from the VCS command line and stores it in variables, thus completing the concurrent scheduling of multiple test cases. Taking the VCS command "vcs +uvm_testname=case0 +testcase1=case1+testcase2=case2" as an example, its execution flow is as follows: Figure 2 As shown: After the simulation starts, VCS first parses the command-line parameter +uvm_testname=case0 and executes test case case0. In the build_phase() phase of test case case0, the configuration information for ports +testcase1=case1 and +testcase2=case2 is read twice via the $value$plusargs function call, respectively, to obtain the test cases corresponding to port 1 and port 2. Then, based on the read configuration, case0 instantiates and starts two independent test processes, case1 and case2, to achieve concurrent execution of the two test cases, driving the corresponding ports to complete the verification. Case0 and case2 can be randomly selected from the testlist; they can be the same test case or different test cases.

[0044] However, the above method suffers from command-line argument (+plusargs) conflict issues. In single-port verification scenarios, verification engineers typically add statements like: $value$plusargs("mode =%s", mode) to dynamically pass parameters such as the port operating mode into the verification environment in the simulation command in the form of vcs +uvm_testname=testcase +mode=pcie_mode or vcs +uvm_testname=testcase+mode=cxl_flit_mode, thereby generating differentiated stimuli for the same test case in different simulations.

[0045] However, in multi-port concurrent verification scenarios, this method can lead to parameter obfuscation issues. Figure 3 For example, if we need to achieve the following: port 0 runs test case 0, operating in PCIe mode at GEN5 speed, and port 1 runs test case 1, operating in CXL io mode at GEN6 speed, if we directly pass +uvm_testname=case0 +testcase1=case1 +testcase2=case2 +mode=pcie_mode +mode=cxl_io_mode +speed=GEN5 +speed=GEN6 into the VCS command, it will cause a parameter parsing conflict because the test cases on different ports all read parameters with the same name through the $value$plusargs function. This will result in case 0 and case 1 being unable to distinguish their respective operating modes and speed parameters, ultimately leading to parameter parsing conflicts and failing to meet the verification requirements for independent configuration of multiple ports.

[0046] In summary, to address the command-line parameter conflict issue in multi-port concurrent verification scenarios and to meet the independent configuration requirements of different ports, this application adds several components to the verification environment to replace the `$value$plusargs` function, and uses independent configuration files to replace the VCS command-line parameter passing method. This solution enables precise binding of parameters to test cases and ports, ensuring that each test case only loads its own corresponding configuration information during execution, completely unaffected by the parameters of other test cases, thus fundamentally solving the parameter confusion problem.

[0047] In some embodiments, such as Figure 4 As shown, this embodiment adds several components to the verification environment, including: test case selection component 1, parameter parsing component 2, parameter management component 4, and parameter invocation component 4. In addition, this embodiment also supports importing an independent configuration file 5 into the verification environment via a parsing tool to achieve multi-port concurrent testing. The above components and configuration files are described below.

[0048] configuration file In practical engineering, test engineers typically maintain a testlist for simulation. This list uses an independent configuration file as its storage medium to centrally manage the test cases to be executed and their corresponding configuration information.

[0049] Configuration file 5 is imported into the verification environment using a parsing tool. Different parsing tools can be used to import configuration files of different formats into the verification environment. Furthermore, configuration file 5 can be in text, XML, or JSON format, etc., and this application does not impose any limitations on this.

[0050] Taking configuration file 5 as a text file as an example, each line of configuration file 5 contains the name of a test case (casename) and the configuration information required for that test case to be executed. That is, the format of each line is as follows: case0, +mode=pcie_mode, +speed=GEN5 case1, +mode=cxl_flit_mode, +speed=GEN6 Where mode represents the working mode of the port corresponding to the test case, and speed represents the transmission rate of the port corresponding to the test case.

[0051] Test case selection component This application embodiment is based on the singleton design pattern, implementing a globally unique static SystemVerilog component and naming it case_container.sv. This component needs to be created and instantiated synchronously when test_top is instantiated.

[0052] It should be noted that this component includes test case selection component 1 and parameter parsing component 2.

[0053] Additionally, taking configuration file 5 as a text file as an example, this component will extract the text information stored in configuration file 5 line by line and store it in a string caselist[$]. Here, string caselist[$] belongs to SystemVerilog syntax and represents a dynamically sized string queue named caselist, used to store the names of test cases, i.e., casename.

[0054] In this embodiment of the application, the component includes a test case selection component 1, which is used to randomly or on demand obtain the name of a test case and the configuration information corresponding to the test case from the caselist[$], so as to realize random testing or targeted testing.

[0055] Parameter parsing component In this embodiment of the application, the component includes a parameter parsing component 2, which is used to parse the selection result of the test case selection component 1 and store the parsed data into two-dimensional structured data.

[0056] Taking the two-dimensional structured array string plusrags[port_num][string] as an example, the first dimension of the array is used to store the port identifier, realizing the indexing and differentiation of the port; the second dimension of the array is indexed by the exclusive configuration item of the test case corresponding to each port, and the content is stored by the parameter value corresponding to each configuration item.

[0057] For example, suppose test case 0 is selected for port 0, that is, the test case selection component selects this line in configuration file 5: case0 +mode=pcie_mode, +speed=GEN5.

[0058] After being parsed by parameter parsing component 2, we get plusrags[0][mode] = pcie_mode, plusrags[0][speed] = GEN5.

[0059] Parameter management component (uvm_valueplusargs) This component is also a globally unique static component, mainly used to store and manage the configuration information to be used by each port in each round of simulation.

[0060] Its internal definition includes: static function uvm_valueplusargs get_valueplusargs(input int port_id), which is a global static function that takes a port identifier (port_id) as input and returns the configuration information of the globally unique uvm_valueplusargs configuration object for the corresponding port, so that the test cases corresponding to each port can independently obtain their own exclusive configuration information.

[0061] In addition, this component maintains a string associative array: `string valueplusargs[string]`, used to store all configuration parameters and their values ​​for the test cases corresponding to each port, to achieve independent storage and fast retrieval of configuration parameters. For example, one port corresponds to one globally independent string associative array; this application does not limit this. In other words, this component allocates and maintains a globally unique string associative array for each port to store the exclusive configuration parameters for the test cases corresponding to that port, ensuring that the configurations of each port are independent and isolated from each other.

[0062] For example, assuming test case 0 is selected for port 0, that is, the test case selection component selects this line in configuration file 5: case0, +mode=pcie_mode, +speed=GEN5, then the string associative array corresponding to port 0 will store the following key-value pairs: valueplusargs [mode] = "pcie_mode", valueplusargs [speed] = "GEN5".

[0063] Parameter call component As an example, parameter invocation component 4 is embedded in each test case in the form of macro definitions, and this application does not limit this. In other words, the embodiments of this application use macro definitions to facilitate each test case to dynamically identify the port identifier of the corresponding port and obtain the configuration information of the corresponding port from parameter management component 4 based on the identified port identifier. It should be noted that the invocation method can also use API (Application Programming Interface), function calls, etc. to replace macro definitions, and this application does not limit this. In addition, configuration parameter matching can also be achieved by using the identifier of the test case, port address, etc. to replace the port identifier, and this application also does not limit this.

[0064] The following section will introduce how to implement multi-port concurrent testing based on the newly added components and the configuration files imported into the verification environment.

[0065] Figure 5 This is a flowchart illustrating a multi-port concurrent testing method provided in an embodiment of this application. The execution entity of this method is a testing platform (also called a verification platform), which runs on a computer device. See also... Figure 5 The method includes the following steps.

[0066] 501. Obtain the configuration file, which contains port configuration information for multiple test cases. These test cases are executed concurrently during the test run. The port configuration information includes port running parameters and their values.

[0067] In this embodiment, the configuration file is imported into the verification environment by a test engineer using a parsing tool. The testlist uses this configuration file as a storage medium to centrally manage the test cases to be executed and their corresponding configuration information. Since the configuration information for each test case consists of the working parameters and their values ​​required for the corresponding port, the configuration information described herein refers to the port configuration information.

[0068] It should be noted that port operating parameters, including port operating mode and transmission rate, are not part of the business logic of the test cases, and therefore will not be configured when creating test cases. Furthermore, after obtaining the corresponding port configuration information, each test case will generate a stimulus sequence adapted to the corresponding port based on the obtained port configuration information, and apply the generated stimulus sequence to the port to perform the test.

[0069] In some embodiments, testlist manages the test cases to be executed and their corresponding configuration information in a unified manner according to the format of "casename + plusargs", and this application does not limit this.

[0070] In summary, the embodiments of this application use configuration files to replace command-line parameter passing, thereby avoiding parameter confusion issues from the source.

[0071] 502. During the test preparation phase, for any port on the chip under test to be tested, assign a test case to the port, obtain the port configuration information corresponding to the assigned test case from the configuration file, and store the mapping relationship between the port and the obtained port configuration information.

[0072] This step is performed by the newly added test case selection component, parameter parsing component, and parameter management component in the verification environment. The test case selection component and parameter parsing component are both contained within the `case_container` component. It should be noted that this component is a globally unique static component, also referred to as the SV component in this document. In other words, this component is created during the test preparation phase and is a singleton static component that runs throughout the entire testing process.

[0073] It should be noted that the embodiments of this application support both randomly assigning test cases to each port and assigning test cases to each port on demand, and this application does not limit this.

[0074] In some embodiments, for any port to be tested, the port configuration information corresponding to the assigned test case is obtained from the configuration file, including but not limited to the following methods: First, retrieve the port configuration information of the multiple test cases to be executed from the configuration file, and store the port configuration information of the multiple test cases into a queue of string caselist[$].

[0075] For example, the testing platform uses the SV component to obtain the port configuration information of multiple test cases to be executed from the configuration file and stores the port configuration information of these multiple test cases in a queue. It should be noted that this step can be completed by other parts of the SV component besides the test case selection component and the parameter parsing component, and this application does not limit this.

[0076] Then, the test case selection component retrieves the port configuration information corresponding to the assigned test case from the queue.

[0077] It should be noted that if test cases are randomly assigned, the test case selection component will randomly select a casename for the port from the queue, that is, obtain the configuration information corresponding to the randomly selected test case; if test cases are assigned on demand, the test case selection component will select a casename from the queue, that is, obtain the configuration information corresponding to the on-demand selected test case.

[0078] In other embodiments, storing the mapping relationship between the port and the acquired port configuration information includes the following steps.

[0079] 5021. The obtained port configuration information is converted into a first type array through the parameter parsing component; wherein, the first type array uses the port identifier and port running parameters as keys and the parameter values ​​of the port running parameters as values.

[0080] In this embodiment, the first type array is two-dimensional structured data. For example, assuming test case 0 is selected for port 0, after parsing and transformation by parameter parsing component 2, the following first type array will be obtained: plusrags[0][mode]= pcie_mode, plusrags[0][speed]= GEN5.

[0081] 5022. Extract the running parameters and their values ​​from the first type array through the parameter management component, and store the extracted running parameters and their values ​​into the second type array of the port.

[0082] In this embodiment of the application, the second type array is stored in the parameter management component, which is a UVM component and is a static component that runs as a single instance throughout the entire testing process.

[0083] For example, suppose the first type array corresponding to port0 is as follows: Given that plusrags[0][mode] = pcie_mode and plusrags[0][speed] = GEN5, the string associative array corresponding to port0 will store the following key-value pairs: valueplusargs [mode] = "pcie_mode", valueplusargs [speed] = "GEN5".

[0084] In summary, the embodiments of this application construct a globally unique dual-component architecture. Based on this globally unique dual-component architecture, parameter parsing, categorized storage, and binding with ports are implemented. This ensures that the test cases corresponding to each port only call their own exclusive configuration information, avoiding parameter confusion issues.

[0085] 503. During the test run phase, multiple test cases are executed concurrently. For any test case, when the test case is executed, it obtains the port configuration information of the corresponding port based on the mapping relationship, generates a stimulus sequence based on the port configuration information of the port, and sends the generated stimulus sequence to the port to test the port.

[0086] It should be noted that, for any test case, obtaining the port configuration information of the corresponding port based on the mapping relationship during the execution of the test case means that the test case obtains the port configuration information of the corresponding port from the second type array of the corresponding port during the execution of the test case.

[0087] In some embodiments, for any test case, when the test case is executed, it obtains the port configuration information of the corresponding port by invoking a component (i.e., the aforementioned parameter-invoking component) and based on the mapping relationship. This invoking component is implemented using macro definitions and integrated into the test case.

[0088] For example, this calling component is implemented using the GetValuePlusargs series of macro definitions, which facilitates each test case to dynamically identify the port identifier of the corresponding port and obtain the configuration information of the corresponding port based on the identified port identifier. The implementation of the GetValuePlusargs series of macro definitions is as follows: `define GetValuePlusargsString (arg, arg_fmt) begin reg[1024 8-1:0】tmp; String plusargs; uvm_valueplusargs valueplusargs; valueplusargs = uvm_valueplusargs::get_valueplusargs(port_id); Plusargs = substr_retrive(arg_fmt); If(valueplusargs.exists(plusarg))begin arg=valueplusargs.get(plusarg); End else begin tmp = arg; end end Alternatively, the calling component can also be implemented using the `define GetValuePlusargsInt( arg_fmt, arg ) series of macro definitions or the `define GetValuePlusargsBit(arg_fmt, arg) series of macro definitions, and this application does not limit it in this regard.

[0089] In other embodiments, taking the implementation of the calling component using the GetValuePlusargs series of macro definitions as an example, the usage method is as follows: replace $value$plusargs(“mode=%s”,value) in each test case in batches with `GetValuePlusargsString( “mode=%s”,value)`.

[0090] It should be noted that since each test case in the multi-port concurrency test includes a port identifier (port_id) member variable, the macro definition does not need to pass port_id.

[0091] Figure 6 This is a data flow diagram showing how each port independently obtains configuration information, as provided in the embodiments of this application. The following is based on… Figure 6 The process of obtaining configuration information independently for each port is illustrated with an example.

[0092] like Figure 6 As shown in the top left table, the configuration file serves as the storage medium for the testlist. Each line contains the casename of a test case and the configuration information required for the execution of that test case.

[0093] For example, Figure 6 The example shows case0, +mode=pcie_mode, +speed=GEN5; case1, +mode=cxl_flit_mode, +speed=GEN6; ...; case100, +mode=cxl_non_flit_mode.

[0094] It should be noted that the configuration file may include more or fewer information entries than shown in the diagram, depending on the number of test cases to be executed included in the testlist.

[0095] like Figure 6 As shown in the upper right table, the parameter parsing component of case_container is used to convert each line of information in the configuration file into a two-dimensional structured array.

[0096] Assuming test case 0 is randomly or on demand assigned to port 0, after parsing by the parameter parsing component, the following two-dimensional structured array is obtained: plusrags[0][mode]= pcie_mode, plusrags[0][speed]= GEN5.

[0097] Assuming test case 1 is randomly or on demand assigned to port 1, the parameter parsing component will produce the following two-dimensional structured array: plusrags[1][mode]= cxl_flit_mode, plusrags[1][speed]= GEN6.

[0098] Assuming test case 100 is randomly or on demand assigned to port 100, the parameter parsing component will produce the following two-dimensional structured array: plusrags

[100] [mode]= cxl_non_flit_mode.

[0099] like Figure 6 As shown in the table at the bottom right, the parameter management component stores a global string association array corresponding to each port. Among them, the array m_global_valueplusargs[0] stores the configuration information required by port0, namely valueplusargs[mode]=pcie_mode, valueplusargs[speed]=gen5; The array m_global_valueplusargs[1] stores the configuration information required by port1, namely valueplusargs[mode]= cxl_flit_mode, valueplusargs[speed]=gen6; The array m_global_valueplusargs[2] stores the configuration information required by port2, i.e., valueplusargs[mode] = cxl_non_flit_mode.

[0100] Accordingly, when test cases 0, 1, and 2 are executed, they can obtain the port configuration information of the corresponding port based on the global string association array stored in the parameter management component.

[0101] In summary, the multi-port concurrent testing scheme provided in this application achieves independent control of the testing process for each port, significantly improving the accuracy and reliability of the test results. First, this scheme replaces command-line parameter passing with configuration files, thus avoiding parameter confusion at the source. Second, during the test preparation phase, for any port to be tested, this scheme randomly or on-demand retrieves the port configuration information of a specific test case from the configuration file and stores the mapping relationship between that port and the retrieved port configuration information. Thus, during the test execution phase, each test case, when executed concurrently, can obtain the correct port configuration information based on this mapping relationship and generate a stimulus sequence accordingly. The generated stimulus sequence is then sent to the corresponding port, enabling testing of each port. Because this scheme ensures that each test case only calls its own proprietary configuration information during execution, the testing platform can accurately match the independent testing requirements of each port, ensuring the accuracy and reliability of the test results.

[0102] Furthermore, this solution simplifies the test case development process, eliminating the need for developers to focus on the port deployment scenarios corresponding to test cases. Simultaneously, existing single-port test cases can be quickly migrated to multi-port scenarios through batch function replacement, reducing development and migration costs. Additionally, this solution boasts strong versatility, applicable to various multi-port driven chip simulation and verification scenarios, without requiring modifications to the core logic for specific hardware designs.

[0103] Figure 7 This is a schematic diagram of the structure of a multi-port concurrent testing device provided in an embodiment of this application. See also... Figure 7 The device includes: The first acquisition unit 701 is configured to acquire a configuration file, which includes port configuration information for multiple test cases. The multiple test cases are executed concurrently during the test run phase. The port configuration information includes port running parameters and their values. The second acquisition unit 702 is configured to, during the test preparation phase, assign test cases to any port to be tested on the chip under test, and obtain port configuration information corresponding to the assigned test cases from the configuration file. Storage unit 703 is configured to represent the mapping relationship between the port and the acquired port configuration information; Test unit 704 is configured to concurrently execute the plurality of test cases during the test run phase; for any test case, when the test case is executed, it obtains the port configuration information of the corresponding port based on the mapping relationship, generates a stimulus sequence according to the port configuration information of the port, and sends the stimulus sequence to the port to test the port.

[0104] The multi-port concurrent testing solution provided in this application achieves independent and controllable testing processes for each port, significantly improving the accuracy and reliability of test results. First, this solution replaces command-line parameter passing with configuration files, thus avoiding parameter confusion at the source. Second, during the test preparation phase, for any port to be tested, this solution randomly or on-demand retrieves the port configuration information of a specific test case from the configuration file and stores the mapping relationship between that port and the retrieved port configuration information. Thus, during the test execution phase, each test case, when executed concurrently, can obtain the correct port configuration information based on this mapping relationship and generate a stimulus sequence accordingly. The generated stimulus sequence is then sent to the corresponding port, enabling testing of each port. Because this solution ensures that each test case only calls its own proprietary configuration information during execution, the testing platform can accurately match the independent testing needs of each port, ensuring the accuracy and reliability of the test results.

[0105] In some embodiments, the storage unit is configured as follows: The obtained port configuration information is converted into a first type array; the first type array uses the port identifier and the port operating parameters as keys, and the parameter values ​​of the port operating parameters as values; Extract the running parameters and their values ​​from the first type array, and store the extracted running parameters and their values ​​into the second type array of the port; When the test case is executed, it obtains the port configuration information of the corresponding port based on the mapping relationship, including: When the test case is executed, it retrieves the port configuration information of the corresponding port from the second type array of the corresponding port.

[0106] In other embodiments, the second type array of the ports is stored within a UVM component; the UVM component is a static component that runs as a singleton throughout the testing process.

[0107] In other embodiments, the test cases, when executed, obtain port configuration information of the corresponding port based on the mapping relationship, including: When the test case is executed, it retrieves the port configuration information of the corresponding port by calling the component and based on the mapping relationship; wherein the calling component is implemented using macro definition, and the macro is integrated into the test case.

[0108] In other embodiments, the first acquisition unit is configured to: Obtain the port configuration information of the multiple test cases from the configuration file, and store the port configuration information of the multiple test cases into a queue; Retrieve the port configuration information corresponding to the assigned test cases from the queue.

[0109] In other embodiments, the first acquisition unit is configured to: The SV component is used to obtain the port configuration information of the multiple test cases from the configuration file and store the port configuration information of the multiple test cases in a queue. The SV component is created during the test preparation phase and is a static component that runs as a singleton throughout the entire test process.

[0110] All of the above-mentioned optional technical solutions can be combined in any way to form the optional embodiments of this application, and will not be described in detail here.

[0111] It should be noted that the multi-port concurrent testing device provided in the above embodiments is only illustrated by the division of the functional modules described above when performing multi-port concurrent testing. In practical applications, the functions described above can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the multi-port concurrent testing device and the multi-port concurrent testing method embodiments provided in the above embodiments belong to the same concept, and their specific implementation process can be found in the method embodiments, which will not be repeated here.

[0112] Figure 8 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application.

[0113] The computer device 800 can vary considerably due to differences in configuration or performance. It includes one or more Central Processing Units (CPUs) 801 and one or more memories 802. The memories 802 store computer program code, which is loaded and executed by the processors 801 to implement the aforementioned multi-port concurrent testing method. Of course, the computer device 800 also includes wired or wireless network interfaces, a keyboard, and input / output interfaces for input and output. The computer device 800 also includes other components for implementing its functions, which will not be elaborated upon here.

[0114] In some embodiments, this application also provides a computer-readable storage medium, such as a memory including computer program code, which can be executed by a processor in a computer device to complete the aforementioned multi-port concurrent testing method. For example, the computer-readable storage medium may be a read-only memory (ROM), a random access memory (RAM), a compact disc read-only memory (CD-ROM), magnetic tape, floppy disk, and optical data storage device, etc.

[0115] In some embodiments, this application also provides a computer program product, the computer program product including computer program code, the computer program code being stored in a computer-readable storage medium, a processor of a computer device reading the computer program code from the computer-readable storage medium, the processor executing the computer program code, causing the computer device to execute the above-described multi-port concurrent testing method.

[0116] Those skilled in the art will understand that all or part of the steps of the above embodiments can be implemented by hardware or by a program instructing related hardware. The program can be stored in a computer-readable storage medium, such as a read-only memory, a disk, or an optical disk.

[0117] The above description is merely an optional embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A multi-port concurrent testing method, characterized in that, The method includes: Obtain the configuration file, which includes port configuration information for multiple test cases. These multiple test cases are executed concurrently during the test run phase. The port configuration information includes port running parameters and their values. During the test preparation phase, for any port on the chip under test to be tested, a test case is assigned to the port, the port configuration information corresponding to the assigned test case is obtained from the configuration file, and the mapping relationship between the port and the obtained port configuration information is stored. During the test run phase, the multiple test cases are executed concurrently. For any test case, when the test case is executed, the port configuration information of the corresponding port is obtained based on the mapping relationship, a stimulus sequence is generated according to the port configuration information, and the stimulus sequence is sent to the port to test the port.

2. The method according to claim 1, characterized in that, The mapping relationship between the stored port and the acquired port configuration information includes: The obtained port configuration information is converted into a first type array; the first type array uses the port identifier and the port operating parameters as keys, and the parameter values ​​of the port operating parameters as values; Extract the running parameters and their values ​​from the first type array, and store the extracted running parameters and their values ​​into the second type array of the port; When the test case is executed, it obtains the port configuration information of the corresponding port based on the mapping relationship, including: When the test case is executed, it retrieves the port configuration information of the corresponding port from the second type array of the corresponding port.

3. The method according to claim 2, characterized in that, The second type array of the ports is stored within the Universal Verification Methodology (UVM) component; the UVM component is a static component that runs as a singleton throughout the entire testing process.

4. The method according to claim 1, characterized in that, When the test case is executed, it obtains the port configuration information of the corresponding port based on the mapping relationship, including: When the test case is executed, it retrieves the port configuration information of the corresponding port by calling the component and based on the mapping relationship; wherein the calling component is implemented using macro definition, and the macro is integrated into the test case.

5. The method according to claim 1, characterized in that, The step of retrieving the port configuration information corresponding to the assigned test cases from the configuration file includes: Obtain the port configuration information of the multiple test cases from the configuration file, and store the port configuration information of the multiple test cases into a queue; Retrieve the port configuration information corresponding to the assigned test cases from the queue.

6. The method according to claim 5, characterized in that, The step of obtaining the port configuration information of the multiple test cases from the configuration file and storing the port configuration information of the multiple test cases in a queue includes: The SV component is used to obtain the port configuration information of the multiple test cases from the configuration file and store the port configuration information of the multiple test cases in a queue. The SV component is created during the test preparation phase and is a static component that runs as a singleton throughout the entire test process.

7. A multi-port concurrent testing device, characterized in that, The device includes: The first acquisition unit is configured to acquire a configuration file, which includes port configuration information for multiple test cases. The multiple test cases are executed concurrently during the test run phase. The port configuration information includes port running parameters and their values. The second acquisition unit is configured to, during the test preparation phase, assign test cases to any port to be tested on the chip under test, and obtain port configuration information corresponding to the assigned test cases from the configuration file. The storage unit is configured to represent the mapping relationship between the port and the acquired port configuration information; The test unit is configured to concurrently execute the plurality of test cases during the test run phase. For any test case, when the test case is executed, it obtains the port configuration information of the corresponding port based on the mapping relationship, generates a stimulus sequence according to the port configuration information of the port, and sends the stimulus sequence to the port to test the port.

8. A computer device, characterized in that, The device includes a processor and a memory, the memory storing computer program code, which is loaded and executed by the processor to implement the multi-port concurrent testing method as described in any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, The storage medium stores computer program code, which is loaded and executed by a processor to implement the multi-port concurrent testing method as described in any one of claims 1 to 6.

10. A computer program product, characterized in that, The computer program product includes computer program code stored in a computer-readable storage medium. A processor of a computer device reads the computer program code from the computer-readable storage medium and executes the computer program code, causing the computer device to perform the multi-port concurrency testing method as described in any one of claims 1 to 6.

Images