Core particle verification method and related equipment

Abstract

The embodiment of the invention provides a core grain verification method and related equipment. The core grain verification method comprises the following steps: acquiring data path modules of a plurality of core grains in a to-be-tested design and module verification environments corresponding to the data path modules; the data path modules of the plurality of core particles are in heterogeneous design; the module verification environment is used for indicating a verification environment corresponding to the data path module; compiling the obtained data path module of each core particle into different file libraries and connecting the file libraries to a top layer module of the to-be-tested design; combining the obtained module verification environments corresponding to the data path modules of the core particles into a top layer verification environment; and based on the top layer verification excitation of the top layer verification environment, executing verification of data path modules of a plurality of core particles in a to-be-tested design. According to the scheme, the test accuracy of the test scene of the cross-heterogeneous data path module can be ensured.

Description

Technical Field

[0001] The embodiments of the present application relate to the field of computer technology, and in particular to a chip verification method and related equipment. Background Art

[0002] With the rapid development of the integrated circuit industry, chip complexity has greatly increased. Chiplet technology greatly simplifies the production process of complex chips by breaking them down into multiple small chips. Existing chip verification methods can verify multiple small chips one by one.

[0003] However, the existing chip verification methods have poor accuracy. Therefore, how to more accurately verify multiple small chiplets has become a problem that needs to be solved urgently by those skilled in the art. Summary of the Invention

[0004] In view of this, embodiments of the present application provide a chip verification method and related equipment to improve the accuracy of chip verification.

[0005] To achieve the above objectives, the embodiments of the present invention provide the following technical solutions:

[0006] In a first aspect, an embodiment of the present application provides a chiplet verification method, comprising:

[0007] Acquire data path modules of a plurality of corelets in a design to be tested and module verification environments corresponding to the data path modules; the data path modules of the plurality of corelets are heterogeneous designs; the module verification environments are used to indicate verification environments corresponding to the data path modules;

[0008] Compile the data path modules of each core particle obtained into different file libraries and connect them to the top-level module of the design to be tested;

[0009] Merging the module verification environments corresponding to the data path modules of each core particle obtained into a top-level verification environment;

[0010] Verification of datapath modules of a plurality of corelets in the design under test is performed based on the top-level verification stimulus of the top-level verification environment.

[0011] In a second aspect, an embodiment of the present application provides a chip verification device, comprising:

[0012] a data path module acquisition module, configured to acquire data path modules of a plurality of corelets in a design to be tested and module verification environments corresponding to the data path modules; the data path modules of the plurality of corelets are heterogeneous designs; and the module verification environments are configured to indicate verification environments corresponding to the data path modules;

[0013] A data path module conversion module is used to compile the acquired data path modules of each core particle into different file libraries and connect them to the top-level module of the design to be tested;

[0014] A verification environment merging module, configured to merge the module verification environments corresponding to the data path modules of each core particle obtained into a top-level verification environment;

[0015] A stimulus verification module is used to verify the data path modules of multiple core particles in the design under test based on the top-level verification stimulus of the top-level verification environment.

[0016] In a third aspect, an embodiment of the present application provides a computer device, comprising a processor and a memory, wherein the memory stores computer instructions, and the processor executes the computer instructions to implement the chip verification method as described above.

[0017] In a fourth aspect, an embodiment of the present application provides a storage medium, wherein the storage medium stores one or more computer-executable instructions, and the one or more computer-executable instructions are used to execute the chip verification method as described above.

[0018] In a fifth aspect, an embodiment of the present application provides a computer program, which is executed to implement the chip verification method as described above.

[0019] The embodiments of the present application provide a chip verification method and related equipment, wherein the chip verification method includes: obtaining data path modules of multiple chiplets in a design to be tested and a module verification environment corresponding to the data path modules; the data path modules of the multiple chiplets are heterogeneous designs; the module verification environment is used to indicate the verification environment corresponding to the data path module; compiling the obtained data path modules of each chiplet into different file libraries and connecting them to the top-level module of the design to be tested; merging the module verification environments corresponding to the obtained data path modules of each chiplet into a top-level verification environment; and performing verification of the data path modules of the multiple chiplets in the design to be tested based on the top-level verification stimulus of the top-level verification environment.

[0020] It can be seen that for a chip with multiple heterogeneous data path modules, the embodiment of the present application can merge the module verification environments into a top-level verification environment to ensure that, under the premise that the corresponding design to be tested only includes the top-level verification environment, each of the data path modules can still be controlled by the top-level verification environment, thereby making it possible to directly verify the design to be tested when verifying the chip with multiple heterogeneous data path modules, that is, to directly perform complete verification on the chip system including multiple heterogeneous data path modules without having to verify the multiple heterogeneous data path modules separately, so that the test scenario is more in line with the actual situation of the chip, thereby ensuring the test accuracy of the test scenario across heterogeneous data path modules. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are merely embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on the provided drawings without any creative work.

[0022] Figure 1 A schematic diagram of the process of the chip verification method provided in the embodiment of the present application;

[0023] Figure 2 Another schematic diagram of the process of verifying the core particle provided in the embodiment of the present application;

[0024] Figure 3 A schematic diagram of the process of compiling the data path module provided in an embodiment of the present application into the top-level module;

[0025] Figure 4 Another schematic flow chart of the chip verification method provided in an embodiment of the present application;

[0026] Figure 5 An optional flowchart of step S30 provided in an embodiment of the present application;

[0027] Figure 6 A schematic diagram of the top-level verification environment provided in this embodiment;

[0028] Figure 7 An optional flowchart of step S40 provided in an embodiment of the present application;

[0029] Figure 8 A schematic diagram of the structure of the chip verification device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0030] The following will be combined with the drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0031] With the rapid development of the integrated circuit industry, chip complexity has greatly increased. Chiplet technology (chiplets or microchips) allows complex chips to be broken down into multiple, simpler, smaller chips, significantly reducing reliance on chiplet manufacturing processes. Chiplet technology is widely used in a variety of chiplet applications with different functions.

[0032] Chiplet technology is often used to reduce CPU (processor) area. For example, chiplet technology divides the CPU into an IO die (input / output chip) and a core die (core chip). This effectively reduces the area of ​​the core die and improves core performance.

[0033] Furthermore, there is an IP (Intellectual Property) in the CPU for maintaining data consistency within the CPU, namely the data path module (Data Fabric, DF). There is only one data path module in a single CPU. After the CPU is split into io die and core die, it is necessary to independently design separate data path modules for the io die and core die based on the devices contained in the upstream and downstream of the io die and core die, that is, the data path module of the io die and the data path module of the core die are heterogeneous designs.

[0034] In a multi-chip verification method, verification environments are built separately for the io die and core die, and stimuli are written for independent verification. In each verification environment, only one data path module is instantiated (for example, only the data path module of the io die is instantiated), and a virtual environment is used to simulate the behavior of another data path module (for example, a virtual environment simulates the data path module of the core die) to interact, thereby generating two independent executable files, that is, the first executable file includes the instantiated data path module of the io die and the simulated data path module of the core die, and the second executable file includes the instantiated data path module of the core die and the simulated data path module of the io die. By using these two executable files, the data path module of the io die and the data path module of the core die are independently simulated.

[0035] However, this method does not consider the core die and IO die as a whole during verification, resulting in one-sided feedback data and the inability to guarantee the accuracy of the verification results.

[0036] This is because the datapath module needs to maintain data consistency. After the CPU is divided into the IO die and core die, both the IO die datapath module and the core die datapath module must be used simultaneously to maintain CPU data consistency. Therefore, the IO die datapath module and the core die datapath module can be considered as a whole. If verification is performed based on only the datapath module of one die, the obtained verification results will be one-sided and the accuracy of the verification results cannot be guaranteed.

[0037] At the same time, some complete data flows need to pass through two data path modules at the same time. In this case, a complete trace and record of each data flow that passes through the two data path modules at the same time is required. In the dynamics of the data flow in the entire system, there is a global check (verification mechanism) to compare the actual scenario with the expected scenario. If only two simulated io dies and core dies are verified separately, it is easy to cause the loss of the verification scenario of the interaction between the data path module of the io die and the data path module of the core die. These lost verification scenarios include some feedback that requires simulation of RTL (Register Transfer Level) behavior. However, if there is a problem with RTL in the interactive operation between different chiplets, and it can run correctly in the verification simulation of a single chiplet, these RTL problems will not be discovered in the verification, affecting the accuracy of the verification.

[0038] To solve the above problems, the embodiment of the present application provides a core particle verification method, which improves the accuracy and efficiency of core particle verification by connecting multiple heterogeneous data path modules to verify multiple heterogeneous data path modules at the same time. As an optional implementation, Figure 1 FIG. 1 shows a flow chart of the core particle verification method provided in an embodiment of the present application. Figure 1 As shown, the chip verification method provided in the embodiment of the present application includes the following steps.

[0039] Step S10: obtaining data path modules of a plurality of corelets in the design to be tested and module verification environments corresponding to the data path modules; the data path modules of the plurality of corelets are heterogeneous designs; the module verification environments are used to indicate the verification environments corresponding to the data path modules;

[0040] The design to be tested can be understood as the chip design to be tested, which may include multiple modules. The multiple core particles are secondary chips obtained by disassembling the design to be tested. The "data path modules of the multiple core particles are heterogeneous designs" refers to the "heterogeneity" between the data path modules of the multiple core particles, that is, the data path modules of the multiple core particles are diverse and of different types. Different and heterogeneous data path modules can support and manage a variety of different types of communication protocols, interfaces or functional modules, so that heterogeneous data path modules can connect and coordinate various types of components to meet the needs of complex system-on-chip (SoC) and multi-chip packaging (Multi-Die Packaging) architectures.

[0041] The module verification environment (Environment, env) is used to indicate the verification environment corresponding to the data path module, so as to understand and simulate the behavior of the data path module during the chip verification of the design to be tested, to ensure that the verification activities can accurately reflect the actual data flow and interaction between the design to be tested and the data path module. The module verification environment needs to interact with the data path module to simulate the transmission of data on the data path module in the actual chip. In addition, the parameters of the data path module (such as bandwidth, delay, protocol configuration) are also set by the module verification environment to match the parameters of the data path module. At the same time, the module verification environment also needs to monitor the data transmitted by the data path module to ensure the consistency and correctness of the data during the verification process.

[0042] In an alternative implementation, reference Figure 2 Another flow chart of the core particle verification method is shown, in which this step further obtains the module verification stimulus corresponding to the data path module; the module verification stimulus corresponding to the data path module is used to generate the verification stimulus corresponding to the data path module; the module verification stimulus includes a sequence (Sequence, seq), which is used to generate and manage a series of transactions (Transactions), thereby driving the design under test (DUT) to execute a specific operation mode. The sequence is used to generate incentives, control simulation processes and implement complex verification scenarios during the chip or core particle verification process. After starting the sequence of the core particle, the sequence generates a series of ordered transactions, which represent specific operations on the DUT and incentives to implement these operations. Only after obtaining the incentives can the verification device perform verification of the design under test. For a data path module, one sequence can be included to control all transactions and incentives, or multiple sequences can be included to control different transactions and incentives respectively.

[0043] Step S20: compile the acquired data path modules of each core particle into different file libraries and connect them to the top-level module of the design to be tested;

[0044] It should be noted that in order to facilitate the use of the data path module by the verification tool, the data path module needs to be compiled into the file library used by the simulation tool, so that the simulation tool can efficiently use the data path module and the underlying library files or functional modules used by the data path module when performing chip verification of the design under test. The top-level module of the design under test (TB_TOP, also known as the test platform top level) can be understood as the top-level module of the verification environment. The design under test that needs to be verified can be instantiated in the top-level module. The top-level module is used to connect the components of the design under test and the verification environment, configure the top-level verification stimulus for the design under test, manage the simulation environment, and ensure that the output of the design under test meets expectations.

[0045] It is understandable that, because the heterogeneous data path modules share many identical underlying library files and some commonly used functional modules, the underlying library files or functional modules of some heterogeneous data path modules have the same name, but these functional modules with the same name have different corresponding RTL logics due to the different data path modules to which they belong. Simultaneously, in a heterogeneous verification environment, the data path module of each core particle needs to be compiled once, so that the functional modules with the same name are compiled multiple times, thereby causing errors in the functional modules compiled multiple times. If the number of the functional modules with the same name is small, the functional modules with the same name can be manually modified to different names. However, for more complex core particles, the number of functional modules with the same name is large, and the workload of manually modifying the names is also large, thus making it difficult to manually complete the modification.

[0046] The inventors of this application considered that datapath modules could be compiled into a file library during core-grain verification using a simulation tool. Therefore, this solution allows heterogeneous datapath modules to be compiled into different file libraries during the process of compiling the datapath modules into the file library. In this way, when the simulation tool calls a functional module of the datapath module, the file name of the called functional module includes the name of the file library where the datapath module to which it belongs is located. This prevents duplicate file names from appearing when the functional modules of multiple heterogeneous datapath modules are compiled or called simultaneously by the simulation tool.

[0047] Further, in the specific implementation, refer to Figure 3 The flowchart of compiling a data path module into a top-level module is shown. In this step, the data path modules of the plurality of core particles may be first compiled into a plurality of different file libraries, and then the file library of the data path module of each core particle may be further connected to the top-level module of the design to be tested. The step of connecting the file library of the data path module of each core particle to the top-level module of the design to be tested may be specifically as follows: expanding the data path modules in the file library of the data path module of each core particle to the top-level module.

[0048] It should be noted that the expansion (Elaboration) is an intermediate step for the datapath module to generate a final executable or synthesizable model from the design source code. In a simulation or synthesis tool, the design description (for example, code written in a hardware description language such as Verilog, SystemVerilog, VHDL, etc.) is parsed and constructed into a complete, hierarchical design model. In this process, all module instances, parameters, connection relationships, and other elements in the design need to be parsed to generate a detailed internal representation so that subsequent simulation or synthesis steps can be accurately executed. Among them, the datapath modules in different file libraries need to be expanded separately.

[0049] Specifically, such as Figure 3 As shown, take the splitting of the CPU into core die and io die as an example. The data path modules of the core die and io die obtained are named cdd df.v and iod df.v respectively. In the core particle verification, it is necessary to first compile the cdd df.v into a database named CDD LIB DF, and compile the iod df.v into a database named IOD LIB DF. Afterwards, the data in the two databases are expanded to the top level of the design to be tested to obtain the two data path modules in the top level. At this time, the names of the two data path modules in the top level are automatically modified to TB_TOP.DF1CDD_LIB and TB_TOP.DF0 IOD_LIB respectively. In this way, since the names of the two data path modules in the top level are suffixed with the name of the database, errors caused by duplicate names are avoided.

[0050] Continue to refer Figure 1 , executing step S30: merging the module verification environments corresponding to the data path modules of each core particle obtained into a top-level verification environment;

[0051] There is only one verification environment in any chip or core particle, so when the multiple data path modules are verified separately, each of the data path modules has a corresponding module verification environment. When multiple sub-chip verifications are performed, it is necessary to use multiple data path modules for verification at the same time. At this time, it can be regarded as including multiple data path modules in a system chip, and the verification environment corresponding to the design to be tested is the top-level verification environment. It can be understood that the design to be tested includes multiple data path modules, and each of the data path modules requires its own corresponding module verification environment for verification. These data path modules cannot share their own module verification environments. Therefore, the stimulus verification components corresponding to each of the acquired data path modules can be merged into one stimulus verification component as the top-level verification environment, so that multiple data path modules can be verified simultaneously by a single stimulus verification component.

[0052] Continue to refer Figure 1 , step S40: based on the top-level verification stimulus of the top-level verification environment, performing verification on the data path modules of the plurality of corelets in the design to be tested.

[0053] For a chip with multiple heterogeneous data path modules, the components of the verification environment that control the data path modules, i.e., the module verification environment, can be merged into a top-level verification environment to ensure that the corresponding design to be tested corresponds to only one verification environment. That is, under the premise of only including the top-level verification environment, each of the data path modules is controlled by the top-level verification environment. As a result, when verifying the design to be tested with multiple heterogeneous data path modules, the design to be tested can be directly verified. That is, the design to be tested including multiple heterogeneous data path modules can be directly and completely verified without verifying the multiple heterogeneous data path modules separately. This ensures the test accuracy of test scenarios across heterogeneous data path modules, making chip verification more comprehensive and the test scenarios more in line with the actual conditions of the chip, thereby improving the efficiency of chip verification.

[0054] In a further optional example, in the scenario where the module verification stimulus corresponding to the data path module is obtained at the same time in step S10, the module verification stimulus of the top-level verification environment in this step can be generated based on the module verification stimulus of the data path module of each core particle. Accordingly, continue to refer to Figure 2 Before executing step S40, step S35 may be further executed: based on the obtained module verification stimulus of the data path module of each core particle, a top-level verification stimulus corresponding to the top-level verification environment is generated.

[0055] For further reference, Figure 4 Another flowchart of the core particle verification method is shown. In an optional implementation, after step S20 and before step S40, the method further includes:

[0056] Step S25: Generate matching parameters and interface configurations for the multiple data path modules.

[0057] It should be noted that during the verification process, it is necessary to ensure that the data transmission and communication mechanisms between these data path modules are normal. Since different types of data path modules are used for different functional modules, such as the computing data path module and the communication data path module, it is necessary to verify whether they can coordinate with each other properly.

[0058] Specifically, the step of generating matching parameters and interface configurations for the multiple data path modules includes: instantiating each data path module component. Instantiating each data path module component in the top-level module to ensure that their parameters and interface configurations are correct. For example, one data path module is responsible for communication between Core Dies, and another data path module is responsible for data transmission between IO Dies and Core Dies. Configuring the interfaces between the data path module components to ensure that data can be correctly transmitted between them, such as by transmitting defined shared signals, bus interfaces, or communicating through dedicated interconnection protocols.

[0059] The datapath module then needs to be integrated into the verification environment. This connected datapath module is then integrated as a component into a chip verification platform (e.g., UVM, the Universal Verification Methodology) to enable it to work collaboratively with other verification components (e.g., agents, monitors, drivers, and sequencers). For example, the monitor needs to be able to capture and analyze data transmitted through the datapath module to verify data consistency and transmission performance.

[0060] The generated parameters may include simulation parameters. Matching configuration simulation parameters are generated for the multiple datapath modules in the top-level module to ensure that the datapath modules behave as designed. For example, simulation parameters may include setting bandwidth, latency, and protocol parameters for the datapath modules to simulate the operating conditions of a real chip.

[0061] It can be understood that by connecting multiple datapath modules in the top-level module, the complex interconnect architecture in the design can be accurately simulated, ensuring that the verification environment can fully cover all data transmission paths and communication mechanisms. Connecting multiple datapath modules helps to verify the consistency and integrity of data when it is transmitted between different datapath modules, while evaluating the overall transmission performance of the system, such as bandwidth utilization and latency. In heterogeneous systems, different types of datapath modules are responsible for different functional modules. By connecting these datapath modules in the top-level module, their collaborative work can be verified to ensure that the overall functionality and performance of the design under test meet the design goals. Among them, connecting multiple datapath modules can increase the complexity and diversity of verification scenarios, improve verification coverage, and ensure that the design can work properly under various conditions.

[0062] Further, in an optional implementation, continue to refer to Figure 4 Before step S30, the method further includes step S26: recording the file library of the design under test used by each datapath module in a library mapping file. The library mapping file (libmap file) records the file library used by the instance. If the library mapping file already contains data, after instantiating the datapath module, the correspondence between the instance of the datapath module and the file library recorded in the library mapping file needs to be updated to ensure that the simulation tool can correctly find the file library where the datapath module is located when calling the datapath module.

[0063] Furthermore, during the execution of the data path module, each data path module is controlled by its own module verification environment. In the verification of the complete chip, one verification environment corresponds to one complete chip. Therefore, the module verification environments of multiple heterogeneous data path modules can be merged into a higher-level top-level verification environment.

[0064] Specifically, in an optional implementation, refer to Figure 5 An optional flow chart of step S30 is shown, wherein step S30 includes

[0065] Step S31: Create a top-level verification environment.

[0066] Step S32: configuring module verification environments corresponding to the multiple data path modules in the top-level verification environment.

[0067] Specifically, the creation of the top-level env structure is as follows Figure 6As shown, taking the example of splitting a single CPU into two modules, core die and io die, in the design to be tested, core die corresponds to CDD (driver device), io die corresponds to IOD (input and output data), Figure 4 cpu_df_env is the top-level verification environment, i.e., the top-level env: cpu_df_env, which includes two proxy modules, namely cdd_df_env corresponding to CDD (driver device) and iod_df_env corresponding to IOD (input and output data). The cdd_df_env controls the env of the data path module of CDD, and the iod_df_env controls the env of the data path module of IOD. At this time, for the CPU, the design under test only includes one env, namely cpu_df_env, while for CDD and IOD, the design under test also includes the env corresponding to controlling CDD and the env corresponding to controlling IOD.

[0068] In an optional implementation, the proxy modules cdd_df_env and iod_df_env can directly reuse the code of the CDD env and IOD env, without redesigning the env data structure. In this case, cdd_df_env also includes the CDD scoreboard, CDD monitor, and CDD driver. iod_df_env also includes the iod scoreboard, iod monitor, and iod driver.

[0069] Furthermore, in an optional implementation, the design to be tested includes an incentive management component. Specifically, the incentive management component includes a main sequence, and the main sequence includes the multiple module verification incentives corresponding to the data path modules. It should be noted that the main sequence (Main Sequence) of the design to be tested is responsible for generating, configuring and managing multiple sub-sequences (Sub-sequences) within the design to be tested, thereby realizing complex test scenarios and verification tasks. In this embodiment of the present application, the sub-sequence is the module verification incentive of the data path module of the multiple core particles.

[0070] The data path module further includes a sequencer, which is used to execute the module verification stimulus; the module verification stimulus includes an initialization sequence and a test sequence.

[0071] Because each heterogeneous datapath module also includes a sequence, during the verification process of the datapath module, the sequence generates stimuli and drives the verification of the datapath module. The transactions and stimuli generated by the sequence are passed to the driver through a sequencer. The sequencer is used to manage and schedule transactions generated during the verification process and pass these transactions to the driver to drive the design under test (DUT).

[0072] Sequencers include physical and virtual sequencers. A physical sequencer is a sequencer directly connected to a driver and is responsible for passing transactions from the sequence to a specific driver. A virtual sequencer coordinates and controls the execution of sequences across multiple physical sequencers. When heterogeneous datapath modules are present, each datapath module has its own virtual sequencer. Each virtual sequencer manager verifies the stimuli and transactions generated by the sequence.

[0073] Accordingly, in the step of executing verification of the data path modules of multiple cores in the design to be tested, after starting the virtual sequencer corresponding to the module verification stimulus, the virtual sequencer of each data path module transmits these transactions and stimuli to the physical sequencer and hands them over to the DUT for execution.

[0074] Furthermore, for heterogeneous datapath modules, during the coregrain verification process, there are no name conflicts when executing the verification stimulus for each heterogeneous module. Therefore, the corresponding sequences and sequencers of the heterogeneous datapath modules can be directly reused for coregrain verification. In this case, because there are multiple sequences within the coregrain, before executing each sequence, it is necessary to first identify the datapath module to which the currently executing sequence belongs.

[0075] Correspondingly, the step of obtaining the data path modules of multiple core particles in the design to be tested and the module verification environment corresponding to the data path modules also includes: obtaining the top-level verification stimulus of the design to be tested, and the top-level verification stimulus includes the module verification stimulus.

[0076] Furthermore, refer to Figure 7An optional flow chart of step S40 is shown, wherein step S40 may further include step S41: starting the virtual sequencer in the top-level verification stimulus of the design to be tested. It should be noted that the main sequence corresponding to the top-level verification stimulus may be started first. The main sequence is the top-level sequence in the verification environment and is used to drive the entire verification process. The main sequence is responsible for generating and managing multiple sub-sequences (Sub-sequences) to achieve complex test scenarios and verification tasks. Among them, the sub-sequences are the verification stimuli of each heterogeneous module. Afterwards, the virtual sequencer in the top-level verification stimulus may be started.

[0077] Step S42: confirm the data path module to which the currently started virtual sequencer belongs.

[0078] As can be seen from the above, each datapath module has a corresponding virtual sequencer, which is used to manage transactions and stimulus delivery within the sequence-generating datapath module during testing. Furthermore, for the main sequence, it directly controls the datapath module's virtual sequencer manager, rather than directly controlling the subsequences. Therefore, to determine the datapath module to which the currently executing virtual sequence belongs, the datapath module to which the currently executing virtual sequencer belongs can be confirmed.

[0079] Step S43: Start the determined initialization sequence and test sequence of the data path module.

[0080] It should be noted that in coregrain testing, to reduce the complexity of each sequence, the multiple steps of the datapath module during the coregrain testing process are grouped into multiple tasks, and a sequence is generated for each task. Each sequence corresponds to the operations required to perform the coregrain testing under a task. For example, the coregrain testing process of the target datapath module can be grouped into initialization tasks and test tasks, and corresponding initialization sequences and test sequences are generated. This simplifies the design of a single sequence and makes it easier for the computing device to understand the sequence.

[0081] Specifically, in an optional implementation, taking the example of splitting a single CPU into two modules, core die and io die, in the design to be tested, core die corresponds to CDD (driver device) and io die corresponds to IOD (input and output data). After starting the main sequence, the step of identifying the target data path module to which the current sequencer belongs is: identifying whether the current virtual sequencer belongs to CDD or IOD. Taking the example of the current virtual sequencer belonging to CDD, if the current virtual sequencer belongs to CDD, the initialization sequence of CDD is started, and then the test sequence of CDD is started; if the current virtual sequencer does not belong to CDD, the initialization sequence of IOD is started, and then the test sequence of IOD is started.

[0082] Further, in order to improve the verification efficiency of the design to be tested and simplify the code of the design to be tested, in an optional implementation, continue to refer to Figure 5 After step S30, the method further includes step S33: connecting the register model of the design to be tested with the top-level verification stimulus corresponding to the top-level verification environment. In this way, the register model of the design to be tested and the top-level verification stimulus corresponding to the top-level verification environment can be integrated so that the top-level verification stimulus corresponding to the top-level verification environment can access registers through the register model. The register model is an abstract description of all registers in the design, which usually includes information such as the register address, bit field, read and write permissions, and reset value.

[0083] It is understandable that if the corresponding connection is not made and the module verification stimulus corresponding to the data path module is directly used to generate the stimulus for accessing the register, this method will make the stimulus code for accessing the register complex, prone to errors, and difficult to reuse. In the embodiment of the present application, register access is performed through the register model (reg_model), which can make the code during access clear and easy to maintain. The register model can also automatically handle corresponding address mapping, constraints, and other matters.

[0084] Specifically, the register model and the module verification stimulus corresponding to the datapath module can be connected via a register adapter (reg_adapter). The register adapter is used to convert register-level access requests into specific bus transactions and process bus responses, so that the register model can adapt to different bus protocols.

[0085] The module verification stimulus can only handle specific transactions and cannot directly handle access requests to registers. Furthermore, by using a register adapter (reg_adapter), register access requests can be converted into specific bus transactions and sent to the module verification stimulus, so that the module verification stimulus within the top-level verification stimulus can handle the register access requests.

[0086] In this way, by integrating the multiple module verification stimuli and register models, the verification efficiency of the design under test can be improved, the code of the design under test can be simplified, and the maintainability of the design under test can be enhanced during the core particle verification process.

[0087] Specifically, the process of connecting the register model of the design to be tested with the top-level verification stimulus corresponding to the top-level verification environment includes: modifying the interface of the register model so that the module verification stimulus in the top-level verification stimulus accesses and operates registers through the register model.

[0088] It's important to note that after connecting the module verification stimulus to the register model, the design under test can automatically execute register read and write operations using the top-level verification stimulus, reducing manual intervention. Furthermore, using sequences as verification stimuli, combined with sequence randomization and coverage-driven methods, ensures that all register functions and boundary conditions are fully verified. Furthermore, the reusability and configurability of sequences facilitate the implementation of diverse test scenarios and verification strategies, ensuring that no scenarios are lost and that all existing verification scenarios are preserved.

[0089] The present application also provides a core particle verification device that connects multiple heterogeneous data path modules to verify multiple heterogeneous data path modules simultaneously, thereby improving the accuracy and efficiency of core particle verification. As an optional implementation, Figure 8 The schematic diagram of the structure of the chip verification device provided in the embodiment of the present application is shown. Figure 8 As shown, the chip verification device provided in the embodiment of the present application includes the following structure.

[0090] The data path module acquisition module 100 is used to acquire data path modules of multiple corelets in the design to be tested and module verification environments corresponding to the data path modules; the data path modules of the multiple corelets are heterogeneous designs; the module verification environments are used to indicate the verification environments corresponding to the data path modules;

[0091] The data path module conversion module 200 is used to compile the acquired data path modules of each core particle into different file libraries and connect them to the top-level module of the design to be tested.

[0092] The verification environment merging module 300 is used to merge the obtained module verification environments corresponding to the data path modules of each core particle into a top-level verification environment;

[0093] The stimulus verification module 400 is configured to verify the datapath modules of the plurality of corelets in the design under test based on the top-level verification stimulus of the top-level verification environment.

[0094] Optionally, the data path module acquisition module 100 is further configured to: acquire a module verification stimulus corresponding to the data path module; the module verification stimulus corresponding to the data path module is used to generate a verification stimulus corresponding to the data path module;

[0095] The stimulus verification module 400 is further configured to generate a top-level verification stimulus corresponding to the top-level verification environment based on the obtained module verification stimulus of the data path module of each core particle.

[0096] Optionally, the data path module conversion module 200 is further configured to generate matching parameters and interface configurations for the multiple data path modules.

[0097] Optionally, the data path module conversion module 200 is further configured to record, in a library mapping file, a file library of the design to be tested used by each data path module.

[0098] Optionally, the verification environment merging module 300 is configured to merge the obtained module verification environments corresponding to the data path modules of each core particle into a top-level verification environment, including:

[0099] Create a top-level verification environment;

[0100] Module verification environments corresponding to the multiple data path modules are configured in the top-level verification environment.

[0101] Optionally, the verification environment merging module 300 is further configured to connect the register model of the design to be tested with the top-level verification stimulus corresponding to the top-level verification environment.

[0102] Optionally, the verification environment merging module 300 is used to connect the register model of the design to be tested with the top-level verification stimulus corresponding to the top-level verification environment, specifically by modifying the interface of the register model so that the module verification stimulus within the top-level verification stimulus accesses and operates registers through the register model.

[0103] Optionally, the data path module conversion module 200 is configured to compile the acquired data path modules of each core particle into different file libraries and connect them to the top-level module of the design to be tested, including:

[0104] A data path module compiling module 210 is configured to compile the data path modules of the plurality of core particles into a plurality of different file libraries;

[0105] The data path module expansion module 220 is used to expand the data path modules in the file library of the data path modules of each core particle to the top-level module.

[0106] Optionally, the module verification stimulus is controlled and executed by a sequencer; the module verification stimulus includes an initialization sequence and a test sequence;

[0107] The data path module acquisition module 100 is used to obtain the data path modules of multiple core particles in the design to be tested and the module verification environment corresponding to the data path modules, and also includes: obtaining the top-level verification stimulus of the design to be tested, and the top-level verification stimulus includes the module verification stimulus.

[0108] Optionally, the stimulus verification module 400 is configured to verify the datapath modules of the plurality of corelets in the design to be tested based on the top-level verification stimulus of the top-level verification environment, including the following steps:

[0109] Starting a virtual sequencer in a top-level verification stimulus of the design under test;

[0110] Confirm the data path module to which the currently started virtual sequencer belongs;

[0111] An initialization sequence and a test sequence of the determined data path module are started.

[0112] Thus, for a chip with multiple heterogeneous datapath modules, the components controlling the verification environments of the datapath modules, i.e., the module verification environments, can be merged into a top-level verification environment, ensuring that only one top-level verification environment is included within the chip. Within the top-level verification environment, each datapath module is controlled by its corresponding module verification environment. Furthermore, when verifying a core containing multiple heterogeneous datapath modules, the chip can be directly verified, allowing for complete verification of the chip design under test, including multiple heterogeneous datapath modules, without the need to verify each heterogeneous datapath module separately. This ensures test accuracy for test scenarios across heterogeneous datapath modules, making chip verification more comprehensive and test scenarios more tailored to the actual chip conditions, thereby improving chip verification efficiency.

[0113] An embodiment of the present application further provides a computer device, including a processor and a memory, wherein the memory stores computer instructions, and the processor executes the computer instructions to implement the chip verification method as described above.

[0114] An embodiment of the present application further provides a storage medium, wherein the storage medium stores one or more computer-executable instructions, and the one or more computer-executable instructions are used to execute the chip verification method as described above.

[0115] An embodiment of the present application further provides a computer program, which is executed to implement the chip verification method described above.

[0116] Although the embodiments of the present application are disclosed above, the present application is not limited thereto. Any person skilled in the art may make various changes and modifications without departing from the spirit and scope of the present application. Therefore, the scope of protection of the present application shall be based on the scope defined by the claims.

Claims

1. A chip verification method, characterized in that: include: Acquire data path modules of a plurality of corelets in a design to be tested and module verification environments corresponding to the data path modules; the data path modules of the plurality of corelets are heterogeneous designs; the module verification environments are used to indicate verification environments corresponding to the data path modules; Compile the data path modules of each core particle obtained into different file libraries and connect them to the top-level module of the design to be tested; Merging the module verification environments corresponding to the data path modules of each core particle obtained into a top-level verification environment; Verification of datapath modules of a plurality of corelets in the design under test is performed based on the top-level verification stimulus of the top-level verification environment.

2. The chip verification method according to claim 1, wherein: The step of obtaining data path modules of a plurality of core particles in the design to be tested and module verification environments corresponding to the data path modules further includes: obtaining module verification stimuli corresponding to the data path modules; the module verification stimuli corresponding to the data path modules are used to generate verification stimuli corresponding to the data path modules; Before the step of performing verification on the datapath modules of the plurality of corelets in the design to be tested based on the top-level verification stimulus of the top-level verification environment, the method further comprises: Based on the obtained module verification stimulus of the data path module of each core particle, a top-level verification stimulus corresponding to the top-level verification environment is generated.

3. The chip verification method according to claim 1 or 2, wherein: After the step of compiling the acquired data path modules of each coregrain into different file libraries and connecting them to the top-level module of the design to be tested, before the step of performing verification of the data path modules of the plurality of coregrains in the design to be tested based on the top-level verification stimulus of the top-level verification environment, the method further includes: Matching parameters and interface configurations are generated for the plurality of datapath modules.

4. The chip verification method according to claim 1 or 2, wherein: Before the step of merging the module verification environments corresponding to the data path modules of each core particle obtained into a top-level verification environment, the method further includes: The file library of the design under test used by each datapath module is recorded in the library mapping file.

5. The chip verification method according to claim 1 or 2, wherein: The step of merging the module verification environments corresponding to the data path modules of each core particle obtained into a top-level verification environment includes: Create a top-level verification environment; Module verification environments corresponding to the multiple data path modules are configured in the top-level verification environment.

6. The chip verification method according to claim 5, wherein: After the step of configuring the module verification environments corresponding to the multiple data path modules within the top-level verification environment framework, the method further includes: connecting the register model of the design to be tested with the top-level verification stimulus corresponding to the top-level verification environment.

7. The chip verification method according to claim 6, wherein: The connecting of the register model of the design to be tested with the top-level verification stimulus corresponding to the top-level verification environment is specifically: modifying the interface of the register model so that the module verification stimulus in the top-level verification stimulus accesses and operates registers through the register model.

8. The chip verification method according to claim 1 or 2, wherein: The data path modules of each core particle obtained are compiled into different file libraries and connected to the top-level module of the design to be tested, including: Compiling the data path modules of the plurality of core particles into a plurality of different file libraries respectively; Expand the data path modules in the file library of the data path modules of each core particle to the top-level module.

9. The chip verification method according to claim 1 or 2, wherein: The module verification stimulus is controlled and executed by a sequencer; the module verification stimulus includes an initialization sequence and a test sequence; The step of obtaining data path modules of multiple core particles in the design to be tested and the module verification environment corresponding to the data path modules further includes: obtaining a top-level verification stimulus of the design to be tested, wherein the top-level verification stimulus includes the module verification stimulus.

10. The chip verification method according to claim 9, wherein: The top-level verification stimulus based on the top-level verification environment performs verification on datapath modules of multiple corelets in the design to be tested, including: Starting a virtual sequencer in a top-level verification stimulus of the design under test; Confirm the data path module to which the currently started virtual sequencer belongs; An initialization sequence and a test sequence of the determined data path module are started.

11. A chip verification device, characterized in that: include: a data path module acquisition module, configured to acquire data path modules of a plurality of corelets in a design to be tested and module verification environments corresponding to the data path modules; the data path modules of the plurality of corelets are heterogeneous designs; and the module verification environments are configured to indicate verification environments corresponding to the data path modules; A data path module conversion module is used to compile the acquired data path modules of each core particle into different file libraries and connect them to the top-level module of the design to be tested; A verification environment merging module, configured to merge the module verification environments corresponding to the data path modules of each core particle obtained into a top-level verification environment; A stimulus verification module is used to verify the data path modules of multiple core particles in the design under test based on the top-level verification stimulus of the top-level verification environment.

12. A computer device, characterized in that: The device comprises a processor and a memory, wherein the memory stores computer instructions, and the processor executes the computer instructions to implement the chip verification method according to any one of claims 1 to 10.

13. A storage medium, characterized in that: The storage medium stores one or more computer-executable instructions, and the one or more computer-executable instructions are used to execute the chip verification method according to any one of claims 1 to 10.

14. A computer program, characterized in that The computer program is executed to implement the chip verification method according to any one of claims 1 to 10.

Images