Chip verification method and device

Abstract

The invention discloses a chip verification method and device, and relates to the technical field of integrated circuit design verification. The method comprises the following steps: determining an environment data class and an environment configuration class in a current verification environment; determining a reference algorithm class corresponding to the environment configuration class from algorithm classes of a pre-constructed transaction-level algorithm library according to the environment configuration class, and instantiating the reference algorithm class to obtain a reference model; constructing a reference model system comprising a reference model based on a common interface of a reference algorithm class and an object handle declared by the common interface; obtaining an environment data class and an environment configuration class through a model input agent of the reference model system, determining input of a reference model and a to-be-tested design, and obtaining final reference output of the reference model system and final test output of the to-be-tested design; and comparing the final reference output with the final test output to verify the chip. According to the embodiment, cross-level verification multiplexing can be realized, and the reusability and transportability of the reference model are improved.

Description

Technical Field

[0001] This invention relates to the field of integrated circuit design verification technology, and in particular to a chip verification method and apparatus. Background Technology

[0002] In the field of integrated circuit design, with the continuous increase in design complexity, verification has become the most time-consuming and critical part of the entire design process. Currently, verification methods mainly include using hardware description and verification languages ​​for behavioral-level modeling, and then performing verification based on the constructed model.

[0003] However, chip verification requires different levels of verification environments, each with varying content and focus. The aforementioned verification methods are often designed for a specific level, resulting in poor model reusability and portability across different levels. This necessitates repeated modeling, increasing verification complexity and reducing efficiency. Furthermore, the verification process involves numerous interactive interfaces. To meet diverse design requirements and the setup of different verification environments, these interfaces are designed with excessive flexibility, leading to inconsistencies. Significant time and effort are required for interface adaptation during verification, greatly increasing costs and impacting the accuracy and reliability of the results. Summary of the Invention

[0004] In view of this, embodiments of the present invention provide a chip verification method and apparatus, construct a transaction-level algorithm library with a unified interface, realize cross-level verification reuse, and improve the reusability and portability of the reference model.

[0005] To achieve the above objectives, according to one aspect of the present invention, a chip verification method is provided, comprising:

[0006] Determine the environment data class and environment configuration class in the current verification environment;

[0007] Based on the above environment configuration class, a reference algorithm class corresponding to the above environment configuration class is determined from the algorithm classes of the pre-built transaction-level algorithm library, and the above reference algorithm class is instantiated to obtain a reference model; wherein, the algorithm classes of the transaction-level algorithm library have a unified interface;

[0008] Based on the public interface of the aforementioned reference algorithm class and the object handles declared therein, a reference model system is constructed that includes the aforementioned reference model; wherein, the aforementioned reference model system includes at least one of the aforementioned reference models;

[0009] The above-mentioned environmental data class and environment configuration class are obtained through the model input agent of the above-mentioned reference model system to determine the input of the above-mentioned reference model and the design under test, and the final reference output of the above-mentioned reference model system and the final test output of the above-mentioned design under test are obtained respectively.

[0010] The chip is verified by comparing the final reference output and the final test output.

[0011] Optionally, the construction method of the above transaction-level algorithm library includes:

[0012] Each pre-built target programming language algorithm is statically encapsulated to obtain several statically encapsulated algorithms.

[0013] The original algorithm components of each of the above target programming language algorithms are summarized to build an algorithm base library, and the above algorithm base library is statically encapsulated to obtain a static algorithm base library.

[0014] The static encapsulation algorithm and the static algorithm base library mentioned above are imported into the package using the direct programming interface of the target verification language. The static encapsulation algorithm is abstracted into an algorithm class, and the static algorithm base library is abstracted into a base library class, resulting in a transaction-level algorithm library containing the base library class and several of the algorithm classes. At the same time, the association relationship between each configuration class and each algorithm class is defined.

[0015] Optionally, the above-mentioned algorithm base library is statically encapsulated to obtain a static algorithm base library, including:

[0016] For each original algorithm component in the aforementioned algorithm base library, static encapsulation is performed to obtain a static algorithm base library that includes static algorithm components; wherein, the aforementioned original algorithm components include custom data types, functions, and methods.

[0017] Optionally, the above-mentioned static encapsulation of the algorithm base library includes:

[0018] Add a preset prefix to the name of the above static algorithm component to distinguish it from the corresponding original algorithm component.

[0019] Optionally, the above method further includes:

[0020] Each of the above static encapsulation algorithms is compiled into a corresponding dynamic link library;

[0021] Build a library list based on the above dynamic link libraries, and specify the library paths using simulation tools.

[0022] Optionally, the above-mentioned static encapsulation of each pre-built target programming language algorithm includes: statically encapsulating the top-level function and the execution entry function of each target programming language algorithm.

[0023] Optionally, each of the above algorithm classes provides the same public interface, and each of the above algorithm classes declares an object handle pointing to the corresponding algorithm class.

[0024] Optionally, when the reference model system includes two or more reference models, the above-mentioned environmental data class and environmental configuration class are obtained through the model input agent of the reference model system to determine the input of the reference model and the design under test, and the final reference output of the reference model system and the final test output of the design under test are obtained respectively, including the following steps N1 to N4:

[0025] Step N1: Obtain the above-mentioned environment configuration class and environment data class through the model proxy of the first reference model, so as to convert the above-mentioned environment configuration class and environment data class into the reference input of the first reference model and the test input of the first design to be tested.

[0026] Step N2: Obtain the test output of the first design under test and send it to the next design under test as the input of the next design under test;

[0027] Step N3: Sample the test output of the first design under test from the model input proxy of the next reference model, and combine it with the reference output of the first reference model as the reference input of the next reference model;

[0028] Step N4: Repeat steps N2 and N3 above until the reference output of the last reference model in the above reference model system is obtained as the final reference output, and the test output of the last design to be tested is obtained as the final test output.

[0029] Optionally, when the reference model system includes two or more reference models, the above-mentioned environmental data class and environmental configuration class are obtained through the model input agent of the reference model system to determine the input of the reference model and the design under test, and the final reference output of the reference model system and the final test output of the design under test are obtained respectively, including the following steps M1 to M4:

[0030] Step M1: Obtain the above-mentioned environment configuration class and environment data class through the model proxy of the first reference model, so as to convert the above-mentioned environment configuration class and environment data class into the reference input of the first reference model and the test input of the first design to be tested.

[0031] Step M2: Obtain the test output of the first design under test and send it to the next design under test as the input of the next design under test;

[0032] Step M3: Send the test output of the first design to be tested and the reference output of the first model to the model output agent of the first reference model, and then determine the input of the next model through the model input agent of the next reference model;

[0033] Step M4: Repeat steps M2 and M3 above until the reference output of the last reference model in the above reference model system is obtained as the final reference output, and the test output of the last design to be tested is obtained as the final test output.

[0034] To achieve the above objectives, according to another aspect of the present invention, a chip verification apparatus is provided, comprising:

[0035] The first determination module is used to determine the environment data class and environment configuration class in the current verification environment;

[0036] The second determining module is used to determine a reference algorithm class corresponding to the environment configuration class from the algorithm classes of the pre-built transaction-level algorithm library based on the environment configuration class, and instantiate the reference algorithm class to obtain a reference model; wherein, the algorithm classes of the transaction-level algorithm library have a unified interface;

[0037] The first construction module is used to construct a reference model system that includes the above-mentioned reference model based on the public interface of the above-mentioned reference algorithm class and the object handles declared therein; wherein the above-mentioned reference model system includes at least one of the above-mentioned reference models;

[0038] The acquisition module is used to acquire the environmental data class and the environmental configuration class through the model input agent of the reference model system to determine the input of the reference model and the design to be tested, and to acquire the final reference output of the reference model system and the final test output of the design to be tested, respectively.

[0039] The comparison module is used to compare the final reference output and the final test output to verify the chip.

[0040] To achieve the above objectives, according to another aspect of the present invention, an electronic device for chip verification is provided.

[0041] An electronic device for chip verification according to an embodiment of the present invention includes: one or more processors; and a storage device for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement a chip verification method according to an embodiment of the present invention.

[0042] To achieve the above objectives, according to another aspect of the present invention, a computer-readable storage medium is provided.

[0043] An embodiment of the present invention provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements a chip verification method according to an embodiment of the present invention.

[0044] To achieve the above objectives, according to another aspect of the present invention, a computer program product is provided.

[0045] A computer program product according to an embodiment of the present invention includes a computer program that, when executed by a processor, implements a chip verification method according to an embodiment of the present invention.

[0046] An embodiment of the above invention has the following advantages or beneficial effects: It determines the environment data class and environment configuration class under the current verification environment; based on the environment configuration class, it determines the reference algorithm class corresponding to the environment configuration class from the algorithm classes in the pre-built transaction-level algorithm library, instantiates the reference algorithm class, and obtains a reference model; based on the public interface of the reference algorithm class and its declared object handles, it constructs a reference model system including the reference model; wherein the reference model system includes at least one of the reference models; it obtains the environment data class and environment configuration class through the model input proxy of the reference model system to determine the input of the reference model and the design under test, and obtains the final reference output of the reference model system and the final test output of the design under test respectively; it compares the final reference output and the final test output to verify the chip, thereby unifying the interface of the algorithm classes in the transaction-level algorithm library. Through transaction-level encapsulation and object-oriented programming interface calls, it reduces the difficulty of interface integration. Furthermore, since the algorithm classes have a unified interface, a reference model system with a unified structure can be quickly and efficiently constructed to meet the verification requirements of different levels.

[0047] The reference model configuration also uses a class-based approach, featuring inheritance capabilities. This allows for the creation of a reference model system with multiple reference models, enabling intelligent management and efficient scheduling of these models. This achieves cross-level verification reuse, significantly improving the efficiency and accuracy of verification work. Through this cross-level reuse mechanism, the verification platform can not only quickly adapt to the needs of different verification levels but also effectively reduce verification costs and enhance the reliability and stability of verification results.

[0048] The further effects of the aforementioned unconventional alternative methods will be explained below in conjunction with specific implementation methods. Attached Figure Description

[0049] The accompanying drawings are provided to better understand the invention and are not intended to unduly limit the scope of the invention. Wherein:

[0050] Figure 1 This is a schematic flowchart of a chip verification method according to an embodiment of the present invention;

[0051] Figure 2 This is a flowchart illustrating the method for constructing a transaction-level algorithm library according to an embodiment of the present invention;

[0052] Figure 3 This is a schematic diagram of the structure of a reference model system including a reference model according to an embodiment of the present invention;

[0053] Figure 4 This is a schematic diagram of the structure of a reference model system including three reference models according to the first embodiment of the present invention.

[0054] Figure 5 This is a schematic diagram of the structure of a reference model system including three reference models according to the second embodiment of the present invention.

[0055] Figure 6 This is a schematic diagram illustrating the construction process of a transaction-level algorithm library according to another embodiment of the present invention;

[0056] Figure 7 This is a schematic diagram of the main modules of a chip verification device according to an embodiment of the present invention;

[0057] Figure 8 This is a schematic diagram of the structure of a computer system suitable for implementing the chip verification method and apparatus of the present invention. Detailed Implementation

[0058] The following description, in conjunction with the accompanying drawings, illustrates exemplary embodiments of the present invention, including various details to aid understanding. These details should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of the invention. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0059] It should be noted that, unless otherwise specified, the embodiments of the present invention and the technical features thereof can be combined with each other.

[0060] like Figure 1 As shown, the chip verification method of this invention mainly includes the following steps S101 to S105:

[0061] Step S101: Determine the environment data class and environment configuration class in the current verification environment;

[0062] In integrated circuit chip verification, the verification environment refers to the simulated real-world operating scenario of the chip. Within this environment, the data class is a dedicated class that describes data formats and behaviors, used to uniformly manage all transmitted data and data processing logic during verification, preventing data format confusion. The configuration class is a dedicated class that uniformly manages configurable parameters, used to store and transmit environment parameters.

[0063] Different stages of integrated circuit design exist at different levels, such as unit level, module level, subsystem level, and chip level. The verification environment differs at each level.

[0064] After determining the verification level, the current verification environment can be identified, and further, the environment data class and environment configuration class within that environment can be determined. Then, transaction-level objects sent by verification environment components at the current or other levels are obtained. Transaction-level preparation for the data class is performed based on the environment data class, and transaction-level preparation for the configuration class is performed based on the environment configuration class.

[0065] Step S102: Based on the above environment configuration class, determine the reference algorithm class corresponding to the above environment configuration class from the algorithm classes of the pre-built transaction-level algorithm library, instantiate the above reference algorithm class, and obtain the reference model; wherein, the algorithm classes of the transaction-level algorithm library have a unified interface;

[0066] Each algorithm class in the transaction-level algorithm library is configured with a unique algorithm identifier. The configuration class defines an algorithm selection field to store the algorithm identifier.

[0067] After the transaction-level algorithm library is built, the association between each configuration class and each algorithm class in the transaction-level algorithm library can be predefined. For each configuration class, the algorithm identifier of the corresponding algorithm class is stored in the algorithm selection field of the configuration class. Thus, after determining the environment configuration class corresponding to the current verification environment, the reference algorithm class to be used in the current verification environment can be specified through the algorithm identifier in the environment configuration class.

[0068] Step S103: Based on the public interface of the above-mentioned reference algorithm class and its declared object handle, construct a reference model system including the above-mentioned reference model; wherein, the above-mentioned reference model system includes at least one of the above-mentioned reference models;

[0069] Each of the aforementioned algorithm classes provides the same public interface, meaning the transaction-level algorithm library has a unified public interface that allows for the construction of a reference model with a unified structure. Because the algorithm classes have a unified public interface, when dealing with different verification environments, there is no need to concern oneself with the internal logic of the algorithm; simply calling the interface is sufficient, thus achieving the reuse of the reference model.

[0070] The aforementioned transaction-level algorithm library with a unified public interface is suitable for verification environments at different levels, such as unit level, module level, subsystem level, and chip level. It supports the unification of verification methods, enables the reuse of reference models, avoids the repetitive adaptation and integration of interfaces in verification work, and improves verification efficiency.

[0071] A reference model system may include one or more reference models, the specifics of which can be determined based on the current level of the verification environment. For example, for a unit-level verification environment, verification can generally be achieved with a single reference model, meaning the reference model system includes one reference model. For higher-level verification environments such as module-level, subsystem-level, or chip-level, multiple different reference models may need to be coupled together to complete the verification, meaning the reference model system includes multiple reference models.

[0072] Each of the above algorithm classes declares an object handle pointing to the corresponding algorithm class. This object handle is the only way to access the reference model stored in memory.

[0073] Therefore, by defining functional specifications through the public interface of the aforementioned reference algorithm class and associating the reference model with object handles, a reusable and scalable reference model system can be constructed.

[0074] Step S104: Obtain the above-mentioned environment data class and environment configuration class through the model input agent of the above-mentioned reference model system to determine the input of the above-mentioned reference model and the design to be tested, and obtain the final reference output of the above-mentioned reference model system and the final test output of the above-mentioned design to be tested respectively.

[0075] Among them, the model input agent refers to the In Agent, which is mainly responsible for acquiring environmental data classes (stimulus) and environmental configuration classes, and transforming the environmental configuration classes into configuration signals of the design under test, and the environmental data classes into physical signals of the design under test.

[0076] The above configuration signal and the above physical signal are used as inputs to the reference model and the design under test, respectively, so as to obtain the final reference output of the reference model system and the final test output of the design under test.

[0077] Optionally, when the reference model system includes multiple reference models, the configuration signals converted from the environment configuration class and the physical signals converted from the environment data class can be used as reference inputs for the first reference model and test inputs for the first design under test. The final reference output of the reference model system is the reference output of the last reference model, and the final test output of the design under test is the test output of the last design under test.

[0078] Generally, the number of reference models in a reference model system is the same as the number of designs to be tested in the current verification environment.

[0079] Step S105: Compare the final reference output and the final test output to verify the chip.

[0080] The chip is verified by comparing the final reference output with the final test output using a scoring board.

[0081] The aforementioned transaction-level algorithm library with a unified interface enables the rapid and efficient construction of a reference model system with a unified structure, suitable for building verification platforms at different levels, and achieving unified implementation of verification methods.

[0082] In one alternative embodiment, such as Figure 2 As shown, the construction method of the above transaction-level algorithm library includes the following steps S201 to S203:

[0083] Step S201: Statically encapsulate each pre-built target programming language algorithm to obtain several statically encapsulated algorithms;

[0084] Step S202: Summarize the original algorithm components of each of the above target programming language algorithms, build an algorithm base library, and statically encapsulate the above algorithm base library to obtain a static algorithm base library;

[0085] Step S203: Using the direct programming interface of the target verification language, import the above static encapsulation algorithm and the above static algorithm base library into the package, and abstract the above static encapsulation algorithm into an algorithm class, and abstract the above static algorithm base library into a base library class, to obtain a transaction-level algorithm library containing the above base library class and several of the above algorithm classes; at the same time, define the association relationship between each configuration class and each algorithm class.

[0086] It should be noted that the transaction-level algorithm library uses two system-level development languages: the target programming language and the target verification language. These two languages ​​complement each other's strengths.

[0087] Preferably, the target programming language can be C or C++; the target verification language can be SystemVerilog (SV). Since using C or C++ alone cannot directly interface with the SV hardware model or directly perceive hardware timing, it is prone to becoming disconnected from the real hardware environment. Therefore, in this embodiment of the invention, C or C++ is not used alone to build the transaction-level algorithm library. Furthermore, because SV is inefficient in implementing randomized scenarios, does not support complex floating-point operations and dynamic data structures, cannot simulate software-layer logic, and has weak processing capabilities, its use alone results in incomplete verification scenarios. Therefore, in this embodiment of the invention, C or C++ is integrated with SV to build a transaction-level algorithm library with lower cost and simpler algorithm logic, providing more comprehensive verification scenario coverage and significantly improving the verification efficiency of integrated circuit chips.

[0088] Corresponding to different system-level development languages, the transaction-level algorithm library includes the target programming language side and the target verification language side.

[0089] On the target programming language side, there are multiple target programming language algorithms pre-built in the target programming language, as well as an algorithm base library containing the original algorithm components shared by all target programming language algorithms. The original algorithm components include custom data types, variables, functions, and methods that are uniformly called by different target programming language algorithms. These are mainly used to adapt to the intermediate operations and execution of different algorithms, and therefore contain a large number of custom data types and interfaces.

[0090] The static encapsulation approach and method for target programming language algorithms and algorithm base libraries can be different.

[0091] Specifically, there can be multiple pre-built target programming language algorithms. Each target programming language algorithm undergoes precise static encapsulation, ensuring that each algorithm is encapsulated as an independent and unique static encapsulated algorithm. Specifically, the algorithm's execution process is meticulously decomposed into multiple functional modules, ensuring that each module is independent and reusable. Each target programming language algorithm is statically encapsulated in the wrapper layer, forming a corresponding static encapsulated algorithm. This unifies the input / output interface of the static encapsulated algorithm, allowing its input / output operations to be executed only through its declared object handles, reducing data transfer complexity. Furthermore, it unifies the Direct Programming Interface (DPI) of the target verification language and the target programming language's interface. Since the DPI interface of the target verification language can only call static objects and methods of the target programming language, the above static encapsulation process is necessary for the DPI to call the static encapsulated algorithm, as will be explained in detail later. Each target programming language algorithm corresponds to a separate wrapper. By statically encapsulating each target programming language algorithm in a wrapper layer, the independence of each target programming language algorithm is maintained, mutual interference between algorithms is avoided, and the accuracy and stability of the reference model subsequently constructed are ensured.

[0092] Furthermore, the above-mentioned static encapsulation of each pre-built target programming language algorithm may include: statically encapsulating the top-level function and the execution entry function of each target programming language algorithm.

[0093] In step S202 above, the above-mentioned static encapsulation of the algorithm base library to obtain a static algorithm base library includes: statically encapsulating each original algorithm component in the algorithm base library to obtain a static algorithm base library including static algorithm components.

[0094] Specifically, for each original algorithm component in the algorithm base library, a unified class encapsulation and object handle management are adopted. For general data structure objects used to store structured data or aggregatable configuration parameter objects used for aggregation configuration, different use cases are encapsulated using independent methods. This establishes corresponding static methods on the target programming language side. In particular, dynamic objects and methods corresponding to each custom data type are all staticized. These static methods belong to static algorithm components. Through static encapsulation, the algorithm base library upon which the target programming language algorithm depends is transformed into a common static algorithm base library, which can then be called by the target verification language side through object handles. This solves the compatibility issues of calling different algorithms across languages ​​and building verification environments at different levels. By encapsulating different use cases of objects using the above mutually independent methods, with input / output parameters using handles of the same object, but each static method implementing only one dedicated logic without depending on other methods, it ensures that the logic of different scenarios does not interfere with each other. It also avoids the duplication of data structures or configuration structures for different algorithms, and performs transaction-level reuse and transfer of the data and configuration required before and after algorithm execution, improving object reusability. As an example, for the buff object, corresponding static methods such as new, delete, get, put, save, and load are created based on different data types and encapsulated in the wrapper layer.

[0095] Furthermore, the above-mentioned static encapsulation of the algorithm base library may also include: adding a preset prefix to the name of the static algorithm component to distinguish the static algorithm component from the corresponding original algorithm component.

[0096] To distinguish between static algorithm components in the wrapper layer of the static algorithm base library and the original algorithm components in the algorithm base library that are not statically encapsulated, a preset prefix can be added to each static algorithm component to avoid incorrect calls.

[0097] As an example, for the original algorithm component buff object, its corresponding static algorithm components include new, delete, get, put, save, and load. After adding the prefix buff_ to the above static algorithm components, they are stored in the wrapper layer as buff_new, buff_delete, buff_get, buff_put, buff_save, and buff_load, respectively.

[0098] On the target validation language side, the DPI of the target validation language can map the static algorithm base library and each statically encapsulated algorithm to importable functions of the target validation language, encapsulate them in classes, and import them into a package, thereby achieving the connection between the target programming language side and the target validation language side. The mapping mechanism can use `import`, which is a keyword in modular languages ​​for importing external code.

[0099] On the target verification language side, the static encapsulation ideas and methods can differ between the static algorithm base library and the static encapsulation algorithm.

[0100] For classes in the static algorithm base library, each static method corresponding to the object in the wrapper layer of the target programming language is uniformly imported into the class corresponding to the object through import. Then, the same name encapsulation and handle calling are performed on the target verification language side to obtain the base library class, so as to realize the flexible calling of the algorithm base library of the target programming language side by the target verification language side.

[0101] As an example, for the `buff` object in the wrapper layer of the static algorithm base library on the target programming language side, its corresponding `new` and `delete` methods are uniformly imported into the `class dpi_buff` using the `import "DPI-C"` method. Then, on the target validation language side, the same name is encapsulated and handles are used for invocation. The code implementation process is shown below.

[0102] import “DPI-C” function chandle buff_new(int deep, int width);

[0103] import “DPI-C” function void buff_delete(chandle inst);

[0104] class dpi_buff;

[0105] chandle inst;

[0106] int deep, width, char_n;

[0107] string name;

[0108] function new(int deep, int width, string name=”dpi_buff”);

[0109] $display(“[DPI-SV] Preparing to new buff[%s]...”, name);

[0110] inst = buff_new(deep, width);

[0111] this.name = name;

[0112] endfunction

[0113] function void delete();

[0114] buff_delete(inst);

[0115] endfunction

[0116] endclass

[0117] For statically encapsulated algorithms, since the static encapsulation process on the target programming language side only involves the top-level function and the entry point function, on the target verification language side, the same name encapsulation can be performed on the corresponding top-level function and entry point function of the statically encapsulated algorithm. An object instance is then created using the `new` function to obtain the algorithm class. For this algorithm class, indirect calls to the top-level function and entry point function of the statically encapsulated algorithm on the target programming language side are achieved through object handles. Furthermore, these object handles are handles to the objects that call the statically encapsulated algorithm library, storing the input data and configuration required during algorithm execution. The output structure of the algorithm is also returned through object handles, ensuring efficient transmission of algorithm results to other reference model systems, guaranteeing data integrity and consistency during transmission, and providing conditions for cross-level verification and verification environments. Through the above-mentioned static encapsulation, instantiation, and object handle invocation methods, the target verification language side can flexibly invoke the static encapsulation algorithm of the target programming language side, ensuring the independence and reusability of each static encapsulation algorithm. This makes the constructed reference model system have good flexibility and efficiency even when facing complex verification environments and different verification levels.

[0118] After encapsulating the static algorithm base library and statically wrapped algorithms, all base library classes and algorithm classes can be imported into a single package. Each custom data type used can then be renamed for unified management of the base library classes and algorithm classes. As an example, the custom data types used may include various enumeration types.

[0119] Through the above-described process of building the transaction-level algorithm library, a transaction-level encapsulation and object-oriented programming (OOP) interface call were performed for the basic algorithm library and each target programming language algorithm through object handles, forming a unified and highly integrated transaction-level algorithm library.

[0120] In addition, by adopting a wrapper strategy that corresponds to that of the target programming language on the target verification language side, the consistency and compatibility of the DPI interface on the target verification language side can be ensured.

[0121] In an optional embodiment, the method further includes: compiling each of the static encapsulation algorithms into a corresponding dynamic link library; constructing a library list based on the dynamic link libraries; and specifying the library path using a simulation tool.

[0122] On the target programming language side, after statically encapsulating the target programming language algorithm and algorithm base library, the source code of each statically encapsulated algorithm (along with its wrapper layer) and the static algorithm base library (along with its wrapper layer) can be compiled into corresponding dynamic link libraries, and each dynamic link library is independent of the others.

[0123] Then, all dynamic link libraries are compiled and a library list is built. This list is used to specify the library paths during the subsequent compilation and simulation stages using Electronic Design Automation (EDA) simulation tools, and to uniformly import all statically encapsulated algorithms.

[0124] In one optional embodiment, the target programming language algorithm typically has multiple hierarchical functions, including but not limited to low-level utility functions for atomic operations, mid-level logic functions for local logic composition, an execution entry function for the core execution of the algorithm in text-based interactive forms, and a top-level function for adapting to the environment and process orchestration. Here, the execution entry function refers to the algorithm execution layer entry function; the top-level function refers to the top-level top function.

[0125] For each target programming language algorithm, its top-level function and execution entry function are statically encapsulated. Specifically, this can include: in the process of statically encapsulating the target programming language algorithm, only its top-level function and execution entry function can be statically encapsulated. The top-level function is used for environment adaptation, and the execution entry function is used to implement the core execution of the algorithm. This exposes only the minimum interface that can be directly combined with the two, reducing the cost of external use and facilitating calls from the target verification language side.

[0126] For the top-level function encapsulation, since the algorithm data class and algorithm configuration class of the target programming language algorithm are already defined and implemented in the algorithm base library, the target programming language algorithm only needs to create objects of the algorithm data class and algorithm configuration class and obtain the corresponding object handles. Data reading and writing and configuration can then be achieved through these object handles, completing the algorithm's input and output. The interface after top-level function encapsulation is mainly used for transaction-level transmission, allowing different objects to be directly transmitted and executed between the target programming language side and the target validation language side.

[0127] As an example, the top-level function interface of a target programming language algorithm is named _top(pa_in.inst, pa_out.inst, cfg_in.inst, cfg_out.inst), where pa_in.inst represents the handle of the input data object; pa_out.inst represents the handle of the output data object; cfg_in.inst represents the handle of the input configuration object; and cfg_out.inst represents the handle of the output configuration object.

[0128] For the execution entry function, assuming that the algorithm data class and algorithm configuration class of the target programming language algorithm have been defined and implemented in the algorithm base library, determine the handles of the input data, output data, input configuration, output configuration, input file, output file, and state isolation flag of the execution entry function. By modifying the function with static, domain isolation is achieved to prevent accidental external calls.

[0129] As an example, the execution entry function of a target programming language algorithm is named `_entry(InDataPath, CfgInPath, OutDataPath, InFileName, CfgOutFileName, OutFileName, FrameID)`. Here, `InDataPath` represents the path address of the input data; `CfgInPath` represents the path address configured for the input; `OutDataPath` represents the path address of the output data; `InFileName` represents the path address of the input file; `CfgOutFileName` represents the path address configured for the output; `OutFileName` represents the path address of the output file; and `FrameID` represents a unique code for each data processing iteration during multiple iterations of the algorithm, serving as a state isolation identifier. `InDataPath`, `CfgInPath`, `OutDataPath`, `InFileName`, `CfgOutFileName`, and `OutFileName` are generally passed as strings for text interaction; `FrameID` is typically passed as an integer data type.

[0130] By statically encapsulating the top-level function and execution entry function of each target programming algorithm, it is ensured that each dynamic method and function is encapsulated in an independent static encapsulation algorithm. The static encapsulation algorithm only performs input and output operations through object handles, which provides a foundation for the subsequent generation of reference models and facilitates the calling of static encapsulation algorithms by the target verification language side.

[0131] In one optional embodiment, the construction and application of the reference model system mainly includes an algorithm preparation stage, an algorithm execution stage, and an algorithm output stage.

[0132] During the algorithm preparation phase, based on the configuration of the reference model system and the verification environment, the objects required by the reference model are created and instantiated. The system then waits to receive transaction-level objects from the verification environment components at the current or other levels, converting them into transaction-level objects of the relevant data and configuration classes required by the current reference model system. This completes the transaction-level object preparation. Transaction-level object preparation includes data class preparation and configuration class preparation.

[0133] During the algorithm execution phase, a reference model system can be constructed based on the top-level methods or functions (serving as handle interfaces) and the execution entry methods or functions (serving as text interfaces) within a predefined algorithm class. The inputs and outputs of the top-level methods or functions utilize the algorithm class and configuration class obtained in the previous algorithm preparation phase. The inputs and outputs of the execution entry methods or functions use the same data format as the current algorithm class, interacting through the same algorithm class and configuration class via text or handle interfaces. Both the aforementioned top-level methods or functions and execution entry methods or functions can be used for algorithm debugging and integration.

[0134] During the algorithm output phase, the execution results of the algorithm class can be stored in the output data object and configuration object respectively, based on the different methods or functions called by the previous stage. If other reference model systems require this, the aforementioned data object and configuration object can be repackaged and sent via a transaction-level transport interface, or as an event-based point-to-point or point-to-multipoint broadcast transaction-level object, to facilitate algorithm execution by subsequent reference model systems.

[0135] In an optional embodiment, when the above-described reference model system includes a reference model, the structure of the reference model system can be as follows: Figure 3As shown, based on stimulus 1, the environmental data class under the current verification environment can be determined. The environmental configuration class and environmental data class are converted into configuration signals and physical signals of the design under test (DUT) through the model input agent in active mode, respectively. The above configuration signals and physical signals serve as inputs to the reference model and the DUT. The design under test and the instantiated reference algorithm class (reference model) are executed respectively, and the methods in the reference algorithm class object are executed. The reference output of the reference model is sent to the scoring board, and the design output of the DUT is obtained through the model output agent in passive mode and sent to the scoring board. The scoring board compares the reference output of the reference model with the design output of the DUT, thereby verifying the chip.

[0136] Reference outputs and design outputs include output data and data objects. If subsequent stages need to connect to other reference model systems, reference outputs and design outputs can also include configuration objects and configuration classes, thereby transferring data objects and configuration objects to subsequent reference model systems.

[0137] Once the reference algorithm class is determined, it can be instantiated to generate a reference model and obtain an object handle for the reference algorithm class. The reference model is then accessed through the unified interface of the transaction-level algorithm library (i.e., the public interface of the reference algorithm class) and the object handle declared by the reference algorithm class, thus constructing a reference model system that includes the reference model.

[0138] Model proxies, including model input proxies and model output proxies, generally have two modes: active mode and passive mode. In active mode, the model proxies can actively generate stimuli and drive the DUT through a driver; in passive mode, they only passively acquire the DUT's input or output signals without driving the DUT.

[0139] It should be noted that in the reference model system, the configuration agent and data agent can be merged, that is, the model input agent can be used to handle the work of the originally separate configuration agent and data agent, thereby integrating the model agent in the verification environment and simplifying the interface.

[0140] In an optional embodiment, when the reference model system includes two or more reference models, the process of obtaining the environment data class and the environment configuration class through the model input agent of the reference model system to determine the input of the reference model and the design under test, and obtaining the final reference output of the reference model system and the final test output of the design under test respectively, includes the following steps N1 to N4:

[0141] Step N1: Obtain the above-mentioned environment configuration class and environment data class through the model proxy of the first reference model, so as to convert the above-mentioned environment configuration class and environment data class into the reference input of the first reference model and the test input of the first design to be tested.

[0142] Step N2: Obtain the test output of the first design under test and send it to the next design under test as the input of the next design under test;

[0143] Step N3: Sample the test output of the first design under test from the model input proxy of the next reference model, and combine it with the reference output of the first reference model as the reference input of the next reference model;

[0144] Step N4: Repeat steps N2 and N3 above until the reference output of the last reference model in the above reference model system is obtained as the final reference output, and the test output of the last design to be tested is obtained as the final test output.

[0145] In this embodiment of the invention, multiple reference models are sequentially connected by using transaction-level data object passing and configuration object passing. Between adjacent reference models, the model output proxy of the previous reference model is used as the model input proxy of the next reference model, and the reference output of the last reference model and the design output of the last DUT are obtained as the final reference output and the final design output, respectively. Until this point, the final reference output and the final design output are sent to the scoring board for comparison. The entire reference model system includes only one scoring board.

[0146] Adjacent reference models achieve seamless transfer of data objects and configuration objects through an efficient transaction-level communication mechanism, thereby ensuring the efficient operation of the reference model system.

[0147] As an example, the reference model system includes three reference models, such as... Figure 4As shown, when the current level is subsystem level, the environment configuration class of the subsystem-level verification environment (ST ENV) is determined, and the environment data class of ST ENV is obtained through subsystem-level stimulus. The environment configuration class and environment data class are converted into configuration signals and physical signals of DUT1 by model agent 1 of reference model 1, which is currently in active mode, and the above configuration signals and physical signals are used as inputs to reference model 1 and DUT1. The configuration object output by DUT1 and the configuration class of ST ENV are obtained, and converted into configuration signals of reference model 2 by model agent 2. Combined with the data object output by reference model 1, they are used as inputs to reference model 2. The configuration object output by DUT3 and the configuration class of ST ENV are obtained, and converted into configuration signals of reference model 3 by model agent 3. Combined with the data object output by reference model 2, they are used as inputs to reference model 3. The model output agent (Out) in passive mode is used as inputs to DUT1. The Agent obtains the design output of DUT3 as the final design output of the current reference model system, obtains the reference output of reference model 3 as the final reference output of the current reference model system, and sends the final design output and the final reference output together to the scoring board for subsystem-level verification.

[0148] In an optional embodiment, when the reference model system includes two or more reference models, the process of obtaining the environment data class and the environment configuration class through the model input agent of the reference model system to determine the input of the reference model and the design under test, and obtaining the final reference output of the reference model system and the final test output of the design under test respectively, includes the following steps M1 to M:

[0149] Step M1: Obtain the above-mentioned environment configuration class and environment data class through the model proxy of the first reference model, so as to convert the above-mentioned environment configuration class and environment data class into the reference input of the first reference model and the test input of the first design to be tested.

[0150] Step M2: Obtain the test output of the first design under test and send it to the next design under test as the input of the next design under test;

[0151] Step M3: Send the test output of the first design to be tested and the reference output of the first model to the model output agent of the first reference model, and then determine the input of the next model through the model input agent of the next reference model;

[0152] Step M4: Repeat steps M2 and M3 above until the reference output of the last reference model in the above reference model system is obtained as the final reference output, and the test output of the last design to be tested is obtained as the final test output.

[0153] In this embodiment of the invention, multiple different verification environments can be cascaded through environment configuration. The reference model system includes several reference model subsystems, each of which has a structure similar to a reference model system containing a reference model. Adjacent reference model subsystems pass configuration objects and data objects through model input agents and model output agents. The model input agents and model output agents can switch between active and passive modes according to different configurations.

[0154] As an example, the reference model system includes three reference models, such as... Figure 5 As shown, the current level is the subsystem level, and the overall verification environment is the subsystem-level verification environment (ST ENV). Each reference model subsystem corresponds to the unit level, and its corresponding verification environment is the unit-level verification environment (UT ENV). Through the coupled configuration of the unit-level verification environment and transaction-level configuration objects, a reference model system capable of supporting multi-level verification environments is formed. Specifically, the environment configuration class of the ST ENV is determined, and the environment data class of the ST ENV is obtained through subsystem-level stimuli. Under UT ENV1, the environment configuration class and environment data class are converted into configuration signals and physical signals of reference model 1 and DUT1 by the active mode model input agent 1 of the first reference model subsystem. These configuration signals and physical signals are then used as inputs to reference model 1 and DUT1, respectively. DUT1 and reference model 1 are executed, and the reference output of reference model 1 is sent to scoreboard 1. The test output of DUT1 is obtained by the passive mode model output agent 1 and sent to scoreboard 1. Under UT ENV2, the data object output by DUT1 is obtained by the passive mode model input agent 2 of the second reference model subsystem and converted into physical signals of reference model 2. The configuration object output by reference model 1 is also obtained and used as inputs to reference model 2. DUT2 and reference model 2 are executed, and the reference output of reference model 2 is sent to scoreboard 2. The test output of DUT2 is obtained by the passive mode model output agent 2 and sent to scoreboard 2. Under ENV3, the passive mode model input agent 3 of the third reference model subsystem obtains the data object output by DUT3 and converts it into the physical signal of reference model 3. It also obtains the configuration object output by reference model 2 and uses them together as the input of reference model 3. DUT3 and reference model 3 are executed respectively. The reference output of reference model 3 is used as the final reference output. The passive mode model output agent 3 obtains the test output of DUT3 as the final test output. The final reference output and the final test output are sent to the scoring board 3 to verify ST ENV, UTENV1, UT ENV2 and UT ENV3.

[0155] The aforementioned reference model system, comprising multiple reference model subsystems, can support and be compatible with both low-level and high-level verification environments. Each low-level reference model subsystem is encapsulated as a unified or inheritable transaction-level object. If the low-level verification environments have a cascading relationship, the input and output transaction-level objects of the reference model subsystems need to be interface compatible.

[0156] It should be noted that when a reference model system includes multiple reference models, these reference models can be connected in series, parallel, or in a mesh structure. During the construction of the transaction-level algorithm library, the statically encapsulated algorithms are encapsulated on the target validation language side. Both input and output use the same algorithm data class and algorithm configuration class from the static algorithm base library; only the values ​​of the instantiated data objects and configuration objects differ. Therefore, the aforementioned reference model system can achieve compatibility across different levels during transaction-level transmission.

[0157] According to the chip verification method of the present invention, the following steps are taken: First, an environment data class and an environment configuration class are determined under the current verification environment. Then, a reference algorithm class corresponding to the environment configuration class is determined from the algorithm classes in a pre-built transaction-level algorithm library. This reference algorithm class is instantiated to obtain a reference model. Based on the public interface of the reference algorithm class and its declared object handles, a reference model system including the reference model is constructed. The reference model system includes at least one reference model. The environment data class and the environment configuration class are obtained through the model input proxy of the reference model system to determine the inputs of the reference model and the design under test. The final reference output of the reference model system and the final test output of the design under test are obtained respectively. The final reference output and the final test output are compared to verify the chip. This method unifies the interfaces of the algorithm classes in the transaction-level algorithm library. Through transaction-level encapsulation and object-oriented programming interface calls, the difficulty of interface integration is reduced. Furthermore, since the algorithm classes have unified interfaces, a reference model system with a unified structure can be quickly and efficiently constructed to meet verification requirements at different levels.

[0158] The reference model configuration also uses a class-based approach, featuring inheritance capabilities. This allows for the creation of a reference model system with multiple reference models, enabling intelligent management and efficient scheduling of these models. This achieves cross-level verification reuse, significantly improving the efficiency and accuracy of verification work. Through this cross-level reuse mechanism, the verification platform can not only quickly adapt to the needs of different verification levels but also effectively reduce verification costs and enhance the reliability and stability of verification results.

[0159] The following specific example further illustrates the construction method of the transaction-level algorithm library.

[0160] In the method for constructing the transaction-level algorithm library in this embodiment of the invention, C or C++ is used as the target programming language algorithm, and System Verilog is used as the target verification language.

[0161] like Figure 6 As shown, on the C / C++ side, C / C++ algorithms are constructed using C or C++ language, including Algorithm 1, Algorithm 2 and Algorithm 3, and the original algorithm components of each target programming language algorithm are summarized to form an algorithm base library.

[0162] The static encapsulation process on the C / C++ side mainly includes four parts: algorithm base library, algorithm data preparation, algorithm configuration preparation, and algorithm function execution. Each part can be separated at the transaction level using class encapsulation and object handle invocation. Specifically, it is necessary to analyze the C / C++ algorithm in advance to determine the dynamic methods and functions to be encapsulated, as well as the data and configuration that need to be instantiated and passed via handles, thereby realizing algorithm data preparation and algorithm configuration preparation.

[0163] Algorithms 1, 2, and 3 are statically encapsulated using classes within their respective wrapper layers, resulting in statically encapsulated Algorithm 1, statically encapsulated Algorithm 2, and statically encapsulated Algorithm 3. During encapsulation, only the top-level function and the entry point function can be encapsulated, and different use cases corresponding to each object can be encapsulated independently. Object handles are used as input and output parameters to achieve efficient data and configuration transfer and efficient algorithm execution.

[0164] Meanwhile, in the wrapper layer, each original algorithm component in the aforementioned algorithm base library is statically encapsulated to obtain a static algorithm base library that includes statically encoded algorithm components.

[0165] Regarding algorithm execution, by statically encapsulating the target programming language algorithm, each core function of the algorithm is implemented as an independent static method. When calling the algorithm, there is no need to directly manipulate the target programming language algorithm. Instead, a specific instance can be associated through the object handle. Each static method encapsulates the algorithm execution logic, and a single call can realize the complete algorithm execution logic, ensuring the atomicity of algorithm operations and improving algorithm execution efficiency.

[0166] In the static encapsulation on the C / C++ side, the interfaces between the algorithm base library, algorithm data preparation, algorithm configuration preparation, and algorithm function execution are clear, facilitating maintenance and expansion. These parts can form a highly modular algorithm execution system through transaction-level separation. This ensures that each module can run independently while efficiently sharing data and configuration through object handles, improving the stability and scalability of the reference model system. Based on this, the reference model can be freely combined and invoked in different levels of verification environments and verification schemes.

[0167] Each statically encapsulated algorithm is compiled into a corresponding *.so dynamic link library. Each *.so dynamic link library is independent of the others. A file sv_liblist.f, which includes a list of all *.so dynamic link libraries, is constructed as the algorithm DPI library list for all *.so dynamic link libraries. This list is used by EDA simulation tools to uniformly import all algorithm DPI libraries during the compilation and simulation phases.

[0168] On the SV side, statically encapsulated algorithms and static algorithm base libraries are mapped to importable functions in SV via import, statically encapsulated by creating classes, and imported into a package. Specifically, the static algorithm base library is statically encapsulated to form a base library class; statically encapsulated Algorithm 1, Algorithm 2, and Algorithm 3 are statically encapsulated to form Algorithm Class 1, Algorithm Class 2, and Algorithm Class 3, respectively.

[0169] The above process forms a transaction-level algorithm library. In the subsequent construction of the reference model system, reference models can be formed through the public interface of each algorithm class and its declared object handles. For example, algorithm class 1 can form reference model 1, algorithm class 2 can form reference model 2, and algorithm class 3 can form reference model 3. Due to the unified interface, these reference models can be arbitrarily combined, achieving flexibility in building reference model systems for different levels of verification environments and improving the reusability and portability of the reference models. Furthermore, the unified interface between the C / C++ side and the SV side fully supports the instantiation and complete execution of each algorithm function, reducing the difficulty of interface integration between algorithms and hardware description languages, and improving verification efficiency and accuracy.

[0170] like Figure 7As shown, the chip verification device 700 of this embodiment includes: a first determining module 701, used to determine an environment data class and an environment configuration class under the current verification environment; a second determining module 702, used to determine a reference algorithm class corresponding to the environment configuration class from the algorithm classes of a pre-built transaction-level algorithm library according to the environment configuration class, instantiate the reference algorithm class, and obtain a reference model; wherein the algorithm classes of the transaction-level algorithm library have a unified interface; a first constructing module 703, used to construct a reference model system including the reference model based on the public interface of the reference algorithm class and its declared object handle; wherein the reference model system includes at least one of the reference models; an acquisition module 704, used to acquire the environment data class and the environment configuration class through the model input proxy of the reference model system to determine the input of the reference model and the design to be tested, and acquire the final reference output of the reference model system and the final test output of the design to be tested respectively; and a comparison module 705, used to compare the final reference output and the final test output to verify the chip.

[0171] In an optional embodiment of the present invention, the chip verification device 700 further includes: a second construction module, configured to statically encapsulate each pre-built target programming language algorithm to obtain several statically encapsulated algorithms; summarize the original algorithm components of each target programming language algorithm to construct an algorithm base library, and statically encapsulate the algorithm base library to obtain a static algorithm base library; import the statically encapsulated algorithms and the static algorithm base library into a package using the direct programming interface of the target verification language, and abstract the statically encapsulated algorithms into algorithm classes and the static algorithm base library into a base library class to obtain a transaction-level algorithm library containing the base library class and several algorithm classes; and define the association relationship between each configuration class and each algorithm class.

[0172] In an optional embodiment of the present invention, the first building module is further configured to statically encapsulate each original algorithm component in the algorithm base library to obtain a static algorithm base library including static algorithm components; wherein the original algorithm components include custom data types, functions, and methods.

[0173] In an optional embodiment of the present invention, the first construction module is further configured to add a preset prefix to the name of the static algorithm component to distinguish the static algorithm component from the corresponding original algorithm component.

[0174] In an optional embodiment of the present invention, the chip verification device 700 further includes: a compilation module, used to compile each of the above-mentioned static packaging algorithms into a corresponding dynamic link library; to construct a library list based on the above-mentioned dynamic link libraries; and to specify the library path through a simulation tool.

[0175] In an optional embodiment of the present invention, the above-mentioned static encapsulation of each pre-built target programming language algorithm includes: statically encapsulating the top-level function and the execution entry function of each target programming language algorithm.

[0176] In an optional embodiment of the present invention, each of the above-mentioned algorithm classes provides the same public interface, and each of the above-mentioned algorithm classes declares an object handle pointing to the corresponding algorithm class.

[0177] In an optional embodiment of the present invention, when the reference model system includes two or more reference models, the acquisition module 704 is further configured to perform the following steps N1 to N4: Step N1, acquire the environment configuration class and the environment data class through the model proxy of the first reference model, so as to convert the environment configuration class and the environment data class into the reference input of the first reference model and the test input of the first design under test; Step N2, acquire the test output of the first design under test and send it to the next design under test as the input of the next design under test; Step N3, sample the test output of the first design under test through the model input proxy of the next reference model, and combine it with the reference output of the first reference model as the reference input of the next reference model; Step N4, repeat the above steps N2 and N3 until the reference output of the last reference model in the reference model system is acquired as the final reference output, and the test output of the last design under test is acquired as the final test output.

[0178] In an optional embodiment of the present invention, when the reference model system includes two or more reference models, the acquisition module 704 is further configured to perform the following steps M1 to M4: Step M1, acquire the environment configuration class and the environment data class through the model proxy of the first reference model, so as to convert the environment configuration class and the environment data class into the reference input of the first reference model and the test input of the first design under test; Step M2, acquire the test output of the first design under test and send it to the next design under test as the input of the next design under test; Step M3, send the test output of the first design under test and the reference output of the first model to the model output proxy of the first reference model, and then determine the input of the next model through the model input proxy of the next reference model; Step M4, repeat the above steps M2 and M3 until the reference output of the last reference model in the reference model system is acquired as the final reference output, and the test output of the last design under test is acquired as the final test output.

[0179] According to an embodiment of the present invention, a chip verification apparatus determines an environment data class and an environment configuration class under the current verification environment; determines a reference algorithm class corresponding to the environment configuration class from the algorithm classes of a pre-built transaction-level algorithm library based on the environment configuration class, instantiates the reference algorithm class, and obtains a reference model; constructs a reference model system including the reference model based on the public interface of the reference algorithm class and its declared object handles; wherein the reference model system includes at least one reference model; obtains the environment data class and the environment configuration class through the model input proxy of the reference model system to determine the input of the reference model and the design under test, and obtains the final reference output of the reference model system and the final test output of the design under test respectively; compares the final reference output and the final test output to verify the chip, thereby unifying the interface of the algorithm classes in the transaction-level algorithm library, reducing the interface integration difficulty through transaction-level encapsulation and object-oriented programming interface calls, and, since the algorithm classes have a unified interface, can quickly and efficiently construct a reference model system with a unified structure to meet the verification requirements of different levels.

[0180] The reference model configuration also uses a class-based approach, featuring inheritance capabilities. This allows for the creation of a reference model system with multiple reference models, enabling intelligent management and efficient scheduling of these models. This achieves cross-level verification reuse, significantly improving the efficiency and accuracy of verification work. Through this cross-level reuse mechanism, the verification platform can not only quickly adapt to the needs of different verification levels but also effectively reduce verification costs and enhance the reliability and stability of verification results.

[0181] The following is for reference. Figure 8 It shows a schematic diagram of the structure of a computer system 800 suitable for implementing the chip verification method and apparatus of the present invention. Figure 8 The computer system 800 shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of the present invention.

[0182] like Figure 8 As shown, the computer system 800 includes a central processing unit (CPU) 801, which can perform various appropriate actions and processes based on programs stored in read-only memory (ROM) 802 or programs loaded from storage section 808 into random access memory (RAM) 803. The RAM 803 also stores various programs and data required for the operation of the computer system 800. The CPU 801, ROM 802, and RAM 803 are interconnected via a bus 804. An input / output (I / O) interface 805 is also connected to the bus 804.

[0183] The following components are connected to I / O interface 805: an input section 806 including a keyboard, mouse, etc.; an output section 807 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 808 including a hard disk, etc.; and a communication section 809 including a network interface card such as a LAN card, modem, etc. The communication section 809 performs communication processing via a network such as the Internet. A drive 810 is also connected to I / O interface 805 as needed. A removable medium 811, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on drive 810 as needed so that computer programs read from it can be installed into storage section 808 as needed.

[0184] In particular, according to the embodiments disclosed in this invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this invention include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 809, and / or installed from removable medium 811. When the computer program is executed by central processing unit (CPU) 801, it performs the functions defined above in the system of this invention.

[0185] It should be noted that the computer-readable medium shown in this invention can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this invention, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this invention, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media can also be any computer-readable medium other than computer-readable storage media, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0186] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0187] The modules described in the embodiments of the present invention can be implemented in software or hardware. The described modules can also be housed in a processor; for example, a processor can be described as including a first determining module, a second determining module, a first constructing module, an acquisition module, and a comparison module. The names of these modules do not necessarily limit the module itself; for example, the first determining module can also be described as "a module for determining the environment data class and environment configuration class under the current verification environment".

[0188] In another aspect, the present invention also provides a computer-readable medium, which may be included in the device described in the above embodiments; or it may exist independently and not assembled into the device. The computer-readable medium carries one or more programs, which, when executed by the device, cause the device to include: determining an environment data class and an environment configuration class under the current verification environment; determining a reference algorithm class corresponding to the environment configuration class from algorithm classes in a pre-built transaction-level algorithm library based on the environment configuration class, instantiating the reference algorithm class to obtain a reference model; wherein the algorithm classes in the transaction-level algorithm library have a unified interface; constructing a reference model system including the reference model based on the public interface of the reference algorithm class and its declared object handles; wherein the reference model system includes at least one of the reference models; obtaining the environment data class and the environment configuration class through a model input proxy of the reference model system to determine the input of the reference model and the design under test, obtaining the final reference output of the reference model system and the final test output of the design under test respectively; and comparing the final reference output and the final test output to verify the chip.

[0189] According to the technical solution of the present invention, the following steps are taken: First, determine the environment data class and environment configuration class under the current verification environment. Then, determine the reference algorithm class corresponding to the environment configuration class from the algorithm classes in a pre-built transaction-level algorithm library, instantiate the reference algorithm class, and obtain a reference model. Based on the public interface of the reference algorithm class and its declared object handles, construct a reference model system including the reference model. The reference model system includes at least one reference model. Second, obtain the environment data class and environment configuration class through the model input proxy of the reference model system to determine the input of the reference model and the design under test. Third, obtain the final reference output of the reference model system and the final test output of the design under test, respectively. Fourth, compare the final reference output and the final test output to verify the chip. This unifies the interfaces of the algorithm classes in the transaction-level algorithm library. Through transaction-level encapsulation and object-oriented programming interface calls, the difficulty of interface integration is reduced. Furthermore, since the algorithm classes have a unified interface, a reference model system with a unified structure can be quickly and efficiently constructed to meet the verification requirements of different levels.

[0190] The reference model configuration also uses a class-based approach, featuring inheritance capabilities. This allows for the creation of a reference model system with multiple reference models, enabling intelligent management and efficient scheduling of these models. This achieves cross-level verification reuse, significantly improving the efficiency and accuracy of verification work. Through this cross-level reuse mechanism, the verification platform can not only quickly adapt to the needs of different verification levels but also effectively reduce verification costs and enhance the reliability and stability of verification results.

[0191] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can occur depending on design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

[0192] In summary, the embodiments of the present invention provide the following technical solutions:

[0193] Technical Solution 1: A chip verification method, comprising:

[0194] Determine the environment data class and environment configuration class in the current verification environment;

[0195] Based on the above environment configuration class, a reference algorithm class corresponding to the above environment configuration class is determined from the algorithm classes of the pre-built transaction-level algorithm library, and the above reference algorithm class is instantiated to obtain a reference model; wherein, the algorithm classes of the above transaction-level algorithm library have a unified interface;

[0196] Based on the public interface of the aforementioned reference algorithm class and the object handles declared therein, a reference model system is constructed that includes the aforementioned reference model; wherein, the aforementioned reference model system includes at least one of the aforementioned reference models;

[0197] The above-mentioned environmental data class and environment configuration class are obtained through the model input agent of the above-mentioned reference model system to determine the input of the above-mentioned reference model and the design under test, and the final reference output of the above-mentioned reference model system and the final test output of the above-mentioned design under test are obtained respectively.

[0198] The chip is verified by comparing the final reference output and the final test output.

[0199] Technical Solution 2: Based on the chip verification method described in Technical Solution 1, the method for constructing the aforementioned transaction-level algorithm library includes:

[0200] Each pre-built target programming language algorithm is statically encapsulated to obtain several statically encapsulated algorithms.

[0201] The original algorithm components of each of the above target programming language algorithms are summarized to build an algorithm base library, and the above algorithm base library is statically encapsulated to obtain a static algorithm base library.

[0202] The static encapsulation algorithm and the static algorithm base library mentioned above are imported into the package using the direct programming interface of the target verification language. The static encapsulation algorithm is abstracted into an algorithm class, and the static algorithm base library is abstracted into a base library class, resulting in a transaction-level algorithm library containing the base library class and several of the algorithm classes. At the same time, the association relationship between each configuration class and each algorithm class is defined.

[0203] Technical Solution 3: Based on the chip verification method described in Technical Solution 2, the aforementioned algorithm base library is statically encapsulated to obtain a static algorithm base library, including:

[0204] For each original algorithm component in the aforementioned algorithm base library, static encapsulation is performed to obtain a static algorithm base library that includes static algorithm components; wherein, the aforementioned original algorithm components include custom data types, functions, and methods.

[0205] Technical Solution 4: Based on the chip verification method described in Technical Solution 3, the above-mentioned algorithm base library is statically encapsulated, including:

[0206] Add a preset prefix to the name of the above static algorithm component to distinguish it from the corresponding original algorithm component.

[0207] Technical Solution 5: According to the chip verification method described in Technical Solution 2, the method further includes:

[0208] Each of the above static encapsulation algorithms is compiled into a corresponding dynamic link library;

[0209] Build a library list based on the above dynamic link libraries, and specify the library paths using simulation tools.

[0210] Technical Solution 6: According to the chip verification method described in Technical Solution 2, the above-mentioned static encapsulation of each pre-built target programming language algorithm includes:

[0211] For each target programming language algorithm, its top-level function and execution entry function are statically encapsulated.

[0212] Technical Solution 7: According to the chip verification method described in Technical Solution 2, each of the above algorithm classes provides the same public interface, and each of the above algorithm classes declares an object handle pointing to the corresponding algorithm class.

[0213] Technical Solution 8: According to the chip verification method described in Technical Solution 1, when the reference model system includes two or more reference models, the environmental data class and the environmental configuration class are obtained through the model input agent of the reference model system to determine the input of the reference model and the design under test, and the final reference output of the reference model system and the final test output of the design under test are obtained respectively, including the following steps N1 to N4:

[0214] Step N1: Obtain the above-mentioned environment configuration class and environment data class through the model proxy of the first reference model, so as to convert the above-mentioned environment configuration class and environment data class into the reference input of the first reference model and the test input of the first design to be tested.

[0215] Step N2: Obtain the test output of the first design under test and send it to the next design under test as the input of the next design under test;

[0216] Step N3: Sample the test output of the first design under test from the model input proxy of the next reference model, and combine it with the reference output of the first reference model as the reference input of the next reference model;

[0217] Step N4: Repeat steps N2 and N3 above until the reference output of the last reference model in the above reference model system is obtained as the final reference output, and the test output of the last design to be tested is obtained as the final test output.

[0218] Technical Solution 9: According to the chip verification method described in Technical Solution 1, when the reference model system includes two or more reference models, the environmental data class and the environmental configuration class are obtained through the model input agent of the reference model system to determine the input of the reference model and the design under test, and the final reference output of the reference model system and the final test output of the design under test are obtained respectively, including the following steps M1 to M4:

[0219] Step M1: Obtain the above-mentioned environment configuration class and environment data class through the model proxy of the first reference model, so as to convert the above-mentioned environment configuration class and environment data class into the reference input of the first reference model and the test input of the first design to be tested.

[0220] Step M2: Obtain the test output of the first design under test and send it to the next design under test as the input of the next design under test;

[0221] Step M3: Send the test output of the first design to be tested and the reference output of the first model to the model output agent of the first reference model, and then determine the input of the next model through the model input agent of the next reference model;

[0222] Step M4: Repeat steps M2 and M3 above until the reference output of the last reference model in the above reference model system is obtained as the final reference output, and the test output of the last design to be tested is obtained as the final test output.

[0223] Technical Solution 10: A chip verification device, comprising:

[0224] The first determination module is used to determine the environment data class and environment configuration class in the current verification environment;

[0225] The second determining module is used to determine the reference algorithm class corresponding to the environment configuration class from the algorithm classes of the pre-built transaction-level algorithm library based on the environment configuration class, instantiate the reference algorithm class, and obtain the reference model; wherein, the algorithm classes of the transaction-level algorithm library have a unified interface.

[0226] The first construction module is used to construct a reference model system that includes the above-mentioned reference model based on the public interface of the above-mentioned reference algorithm class and the object handles declared therein; wherein the above-mentioned reference model system includes at least one of the above-mentioned reference models;

[0227] The acquisition module is used to acquire the environmental data class and the environmental configuration class through the model input agent of the reference model system to determine the input of the reference model and the design to be tested, and to acquire the final reference output of the reference model system and the final test output of the design to be tested, respectively.

[0228] The comparison module is used to compare the final reference output and the final test output to verify the chip.

[0229] Technical Solution 11: An electronic device for chip verification, comprising:

[0230] One or more processors;

[0231] Storage device for storing one or more programs.

[0232] When the above one or more programs are executed by the above one or more processors, the above one or more processors implement the method as described in any of technical solutions 1-9.

[0233] Technical Solution 12: A computer-readable medium having a computer program stored thereon, wherein the program, when executed by a processor, implements the method described in any one of Technical Solutions 1-9.

[0234] Technical Solution 13: A computer program product, comprising a computer program, wherein the computer program, when executed by a processor, implements the method described in any one of Technical Solutions 1-9.

Claims

1. A chip verification method characterized by, include: Determine the environment data class and environment configuration class in the current verification environment; Based on the environment configuration class, a reference algorithm class corresponding to the environment configuration class is determined from the algorithm classes in the pre-built transaction-level algorithm library, and the reference algorithm class is instantiated to obtain a reference model; wherein, the algorithm classes in the transaction-level algorithm library have a unified interface; Based on the public interface of the reference algorithm class and the object handles declared therein, a reference model system is constructed that includes the reference model; wherein, the reference model system includes at least one of the reference models; The environment data class and the environment configuration class are obtained through the model input agent of the reference model system to determine the input of the reference model and the design under test, and the final reference output of the reference model system and the final test output of the design under test are obtained respectively. The final reference output and the final test output are compared to verify the chip.

2. The chip verification method according to claim 1, wherein The construction method of the transaction-level algorithm library includes: Each pre-built target programming language algorithm is statically encapsulated to obtain several statically encapsulated algorithms. The original algorithm components of each target programming language algorithm are summarized to build an algorithm base library, and the algorithm base library is statically encapsulated to obtain a static algorithm base library; The static encapsulation algorithm and the static algorithm base library are imported into a package using the direct programming interface of the target verification language. The static encapsulation algorithm is abstracted into an algorithm class, and the static algorithm base library is abstracted into a base library class, resulting in a transaction-level algorithm library containing the base library class and several algorithm classes. At the same time, the association relationship between each configuration class and each algorithm class is defined.

3. The chip verification method according to claim 2, characterized in that, The static encapsulation of the algorithm base library to obtain a static algorithm base library includes: For each original algorithm component in the algorithm base library, static encapsulation is performed to obtain a static algorithm base library including static algorithm components; wherein, the original algorithm components include custom data types, functions, and methods.

4. The chip verification method according to claim 3, characterized in that, The static encapsulation of the algorithm base library includes: Add a preset prefix to the name of the static algorithm component to distinguish it from the corresponding original algorithm component.

5. The chip verification method according to claim 1, characterized in that, When the reference model system includes two or more reference models, the step of obtaining the environment data class and the environment configuration class through the model input agent of the reference model system to determine the input of the reference model and the design under test, and obtaining the final reference output of the reference model system and the final test output of the design under test respectively, includes the following steps N1 to N4: Step N1: Obtain the environment configuration class and the environment data class through the model proxy of the first reference model, so as to convert the environment configuration class and the environment data class into the reference input of the first reference model and the test input of the first design to be tested; Step N2: Obtain the test output of the first design under test and send it to the next design under test as the input of the next design under test; Step N3: Sample the test output of the first design under test from the model input proxy of the next reference model, and combine it with the reference output of the first reference model as the reference input of the next reference model; Step N4: Repeat steps N2 and N3 above until the reference output of the last reference model in the reference model system is obtained as the final reference output, and the test output of the last design to be tested is obtained as the final test output.

6. The chip verification method according to claim 1, characterized in that, When the reference model system includes two or more reference models, the step of obtaining the environment data class and the environment configuration class through the model input agent of the reference model system to determine the input of the reference model and the design under test, and obtaining the final reference output of the reference model system and the final test output of the design under test respectively, includes the following steps M1 to M4: Step M1: Obtain the environment configuration class and the environment data class through the model proxy of the first reference model, so as to convert the environment configuration class and the environment data class into the reference input of the first reference model and the test input of the first design to be tested; Step M2: Obtain the test output of the first design under test and send it to the next design under test as the input of the next design under test; Step M3: Send the test output of the first design to be tested and the reference output of the first model to the model output agent of the first reference model, and then determine the input of the next model through the model input agent of the next reference model; Step M4: Repeat steps M2 and M3 above until the reference output of the last reference model in the reference model system is obtained as the final reference output, and the test output of the last design to be tested is obtained as the final test output.

7. A chip verification device, characterized in that, include: The first determination module is used to determine the environment data class and environment configuration class in the current verification environment; The second determining module is used to determine a reference algorithm class corresponding to the environment configuration class from the algorithm classes of a pre-built transaction-level algorithm library based on the environment configuration class, and instantiate the reference algorithm class to obtain a reference model; wherein, the algorithm classes of the transaction-level algorithm library have a unified interface; The first construction module is used to construct a reference model system including the reference model based on the public interface of the reference algorithm class and the object handles declared therein; wherein the reference model system includes at least one of the reference models; The acquisition module is used to acquire the environment data class and the environment configuration class through the model input agent of the reference model system, so as to determine the input of the reference model and the design to be tested, and to acquire the final reference output of the reference model system and the final test output of the design to be tested, respectively. A comparison module is used to compare the final reference output with the final test output to verify the chip.

8. An electronic device for chip verification, characterized in that, include: One or more processors; Storage device for storing one or more programs. When the one or more programs are executed by the one or more processors, the one or more processors implement the method as described in any one of claims 1-6.

9. A computer-readable medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the method as described in any one of claims 1-6.

10. A computer program product comprising a computer program that, when executed by a processor, implements the method as described in any one of claims 1-6.

Images