Inspector control method, verification system, computer device, and storage medium

Abstract

Embodiments of the present application provide a checker control method, a verification system, a computer device and a storage medium, and the method comprises the following steps: obtaining a checker control parameter, the checker control parameter defining a controlled path of a checker in a verification environment and a control command; determining a target design module in the verification environment based on the controlled path; and controlling the checker in a verification interface bound to a design interface of the target design module based on the control command. The embodiments of the present application simplify the control process of the checker and improve the verification efficiency.

Description

Technical Field

[0001] This application relates to the field of simulation verification technology, and in particular to an inspector control method, verification system, computer equipment, and storage medium. Background Technology

[0002] Chip design refers to the design of integrated circuits such as ASICs (Application Specific Integrated Circuits) and SOCs (System-On-Chip). To verify whether a chip design meets expectations, it needs to be verified; for example, a verification environment is built and used to verify the code of the chip design, thereby verifying whether the code of the chip design conforms to expectations.

[0003] In the verification process of chip designs, checkers can be used to inspect whether the design modules function as expected within the verification environment. As a crucial component in the verification environment for chip design verification, checkers require control to more efficiently complete the verification process. Therefore, how to provide a checker control scheme to optimize checker control and improve verification efficiency has become a pressing technical problem for those skilled in the art. Summary of the Invention

[0004] In view of this, embodiments of this application provide an inspector control method, a verification system, a computer device, and a storage medium. Embodiments of this application simplify the control process of the inspector and improve verification efficiency.

[0005] To achieve the above objectives, the embodiments of this application provide the following technical solutions.

[0006] In a first aspect, embodiments of this application provide an inspector control method, including:

[0007] Obtain the inspector control parameters, which define the controlled path and control commands of the inspector in the verification environment;

[0008] Based on the controlled path, the target design module in the verification environment is determined;

[0009] And, based on the control command, control the checker in the verification interface bound to the design interface of the target design module;

[0010] The verification environment instantiates a verification component instance based on the verification component; the verification interface of the verification component defines an inspector definition file for instantiating inspectors, and the verification interface instantiated by the verification component instance is bound to the design interface of the design module corresponding to the verification component instance; the verification interface instantiated by the verification component instance correspondingly instantiates an inspector based on the inspector definition file.

[0011] Secondly, embodiments of this application provide a verification system, including:

[0012] Verification environment; the verification environment instantiates a verification component instance based on the verification component; the verification interface of the verification component defines an inspector definition file for instantiating the inspector, and the verification interface instantiated by the verification component instance is bound to the design interface of the design module corresponding to the verification component instance;

[0013] The verification interface instantiated by the verification component instance is correspondingly instantiated with an inspector based on the inspector definition file; the inspector is controlled based on the inspector control method described in the first aspect.

[0014] Thirdly, embodiments of this application provide a computer device for design simulation verification. The computer device includes at least one memory and at least one processor. The memory stores one or more computer-executable instructions, and the processor invokes the one or more computer-executable instructions to execute the checker control method as described in the first aspect above.

[0015] Fourthly, embodiments of this application provide a storage medium storing one or more computer-executable instructions for simulation verification of a design. When the one or more computer-executable instructions are executed, the checker control method described in the first aspect above is implemented.

[0016] This application discloses a checker control method, including obtaining checker control parameters, which define the controlled path and control commands of the checker in a verification environment; determining the target design module in the verification environment based on the controlled path; and controlling the checker in the verification interface bound to the design interface of the target design module based on the control commands. In this application, a checker definition file is defined on the verification interface corresponding to the Universal Verification component (UVC), thereby enabling control of checkers in different verification interface instances based on the same checker definition file. This avoids modifying checkers in different verification interface instances one by one in different checker definition files, simplifying the checker control process and improving verification efficiency. Attached Figure Description

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

[0018] Figure 1 Optional example diagram for verifying the environment;

[0019] Figure 2 A schematic diagram of the architecture for verifying design modules in the design using an inspector;

[0020] Figure 3 This is a schematic diagram of the inspector control architecture in an embodiment of this application;

[0021] Figure 4 This is a schematic diagram of a verification component instance instantiated from a verification component in an embodiment of this application;

[0022] Figure 5 This is a schematic diagram of an optional architecture for inspector component A in an embodiment of this application;

[0023] Figure 6 This is an optional schematic diagram of the inspector control method provided in the embodiments of this application;

[0024] Figure 7 This is a schematic diagram illustrating the steps for obtaining the inspector control parameters in an embodiment of this application;

[0025] Figure 8 This is a flowchart illustrating the process of dividing multiple arrays in an embodiment of this application;

[0026] Figure 9 This is another optional schematic diagram of the inspector control method in the embodiments of this application;

[0027] Figure 10 This is a schematic diagram of the process of controlling the inspector based on the control command in an embodiment of this application;

[0028] Figure 11 This is a schematic diagram of another step of the inspector control method in the embodiments of this application;

[0029] Figure 12 This is an optional block diagram of the computer device in the embodiments of this application. Detailed Implementation

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

[0031] As SOC chip designs become larger and more complex, verification models are also becoming more complex. More and more checkers are being added to the verification models. Therefore, it is very important to use checkers to check whether the chip design meets expectations, improve the visibility of the chip design and the debuggability of the verification model.

[0032] When verifying chip designs, checkers can be used to inspect whether design modules (e.g., IP modules) in the verification environment function as expected through design interfaces. It's important to note that design modules (e.g., IP modules) are functional modules within the chip design. The underlying IP verification environment can be used for verification at the design module level. A design module can be instantiated and verified in one or more IP verification environments, and each design module corresponds to at least one design interface. For example, a relatively simple design module can be instantiated in one IP verification environment and verified through its design interface; a more complex design module can be instantiated in verification environments at different levels and verified through different levels of design interfaces. Furthermore, a design module may be instantiated multiple times in an IP verification environment to simulate specific verification scenarios. In multi-level verification environments, the number of IP verification environments may be one or more.

[0033] The intermediate-level subsystem verification environment can be used to verify subsystems formed by the instantiation of multiple IP modules, thereby verifying the collaborative operation of multiple IP modules; in a multi-level verification environment, the number of subsystem verification environments may be one or more. The system-level verification environment can be used to verify the interconnection and communication of multiple subsystems, where the instantiation of multiple IP modules can form a subsystem; in a multi-level verification environment, the number of system-level verification environments is generally one.

[0034] For ease of understanding, let's take a multi-IP authentication environment and a subsystem authentication environment as an example. Figure 1 An optional example diagram for verifying the environment, as an example, is shown below. Figure 1As shown, there can be multiple IP verification environments, namely IP verification environment A0, IP verification environment B0, IP verification environment C0, and IP verification environment D0. Subsystem verification environment X0 includes subsystems instantiated from design modules A, B, C, and D. This subsystem verification environment X0 can be used to verify the subsystems instantiated from design modules A, B, C, and D. These subsystems can be considered as a design X containing design modules A, B, C, and D. Therefore, subsystem verification environment X0 can instantiate design modules A, B, C, and D at the top level of design X, and verify the design X formed by the instantiated design modules A, B, C, and D to verify the collaborative work between multiple design modules A, B, C, and D.

[0035] When verifying a design, checkers can be generated within the verification environment. These checkers can then functionally verify whether the design functions as expected. For example, for design modules instantiated in various verification environments (e.g., design modules instantiated in various IP verification environments, design modules instantiated in various subsystem verification environments, and design modules instantiated in a system-level verification environment), each verification environment can generate checkers to perform functional verification on the instantiated design modules. The checkers instantiated in the verification environment can be one or more types of checkers, specifically including CDC (Clock Domain Crossing), assertion checkers, and force (forced assignment), etc. Among these, CDC (Clock Domain Crossing) is crucial because, with the increasing scale of chip designs, the number of clocks within chips is growing, and synchronization circuits across clock domains are very common. Therefore, chip design and verification must ensure the correctness of CDC, making CDC synchronizer checking a vital part of chip design verification.

[0036] Assertion-based verification, or simply assertion, is used to describe the properties that a chip design must have correctly for certain interfaces, timings, or special functions. The main purpose of property verification (such as assertion verification) is to ensure that the chip design is consistent with the design specifications.

[0037] Force (force assignment), including force / release / deposit, is collectively referred to as force; force exists in the verification environment to create special stimuli, such as to simulate power connection, to accelerate initialization in simulation, to simulate metastable propagation, for switch checkers, and some temporary strain methods, etc. Using force can quickly achieve the verification goal.

[0038] Therefore, the relationship between the inspector and the verification environment in this application can be referred to... Figure 1 As shown. Figure 1 The top-level generation of IP verification environment A0 includes checker a0, used to perform functional verification on instantiated design module A; the top-level generation of IP verification environment B0 includes checker b0, used to perform functional verification on instantiated design module B; the top-level generation of IP verification environment C0 includes checker c0, used to perform functional verification on instantiated design module C; the top-level generation of IP verification environment D0 includes checker d0, used to perform functional verification on instantiated design module D; and the top-level generation of subsystem verification environment X0 includes checker x0, used to perform functional verification on subsystems instantiated at the top level of design X. Each subsystem instantiates design modules A, B, C, and D, and checker x0 performs verification on design modules A, B, C, and D.

[0039] Based on the above, during the verification process, if the simulation behavior of a certain design module does not meet the description expectations, an error message will be displayed in the corresponding IP verification environment. Verification personnel can quickly locate the design module in the IP verification environment based on the error message to identify the design module in design X that does not exhibit the expected behavior. Therefore, it is evident that a correct description of the checker can help engineers locate the design module that does not meet the expectations more quickly during the verification process.

[0040] In complex chip design, when verifying design X, there may be design modules in design X that correspond to the same protocol. Therefore, when verifying design modules, the same checker needs to be used. Thus, for design modules with the same protocol, multiple identical checker definition files need to be written so that the checker instantiated in the verification interface through the checker definition file can check the bound IP interface to determine whether the design modules corresponding to multiple IP interfaces meet the expected described behavior.

[0041] However, when the control checker verifies a design module, it sometimes controls the enabling or disabling of certain checker attributes to determine which checker is used to verify the design module. In one embodiment, there may be a need to disable a certain type of checker attribute. To achieve this, the checker control parameters indicating the checker attributes in the checker definition file need to be modified one by one, thereby controlling the checker attributes corresponding to the checkers in the verification interface bound to the design interface of the design module. However, currently, when changing the checker control parameters in the checker definition file, it is often necessary to re-establish the verification environment. In the newly established verification environment, based on the modified checker control parameters, the controlled checker is used to verify design X.

[0042] Figure 2This is a schematic diagram illustrating the architecture used to verify design modules within the design using an inspector. (Reference) Figure 2 As shown, in order to verify design X, typically the IP modules of design X (such as...) are... Figure 2 Establish corresponding IP interfaces (e.g., for design modules A, B, C, and D) in the design module. Figure 2 Design interfaces A, B, C, and D in design X. To validate the different design interfaces in design X, a corresponding inspector component (such as...) is typically set up. Figure 2 This refers to inspector component A corresponding to design interface A, inspector component B corresponding to design interface B, inspector component C corresponding to design interface C, and inspector component D corresponding to design interface D. Inspector components are generally instantiated from inspector definition files. Therefore, to facilitate modification of the inspector state of different inspection groups, different inspector definition files are set (e.g., ...). Figure 2 The inspector definition files A, B, C, and D are used to instantiate different inspector components.

[0043] To verify design X, such as Figure 2 As shown, typically, inspector component A is instantiated based on inspector definition file A, and inspector component A is bound to design interface A of design module A; inspector component B is instantiated based on inspector definition file B, and inspector component B is bound to design interface B of design module B; inspector component C is instantiated based on inspector definition file C, and inspector component C is bound to design interface C of design module C; and inspector component D is instantiated based on inspector definition file D, and inspector component D is bound to design interface D of design module D.

[0044] Combination Figure 2 As can be seen, each design module's design interface corresponds to an inspector component to check whether the current design module meets the protocol and functional requirements. When multiple design modules in the design have many interfaces with the same protocol that need to use the same inspector, many inspector definition files need to be written repeatedly. Furthermore, the design interfaces of each design module in the design may have some special inspector control requirements, such as disabling one or more inspector properties. Based on these special inspector control requirements, a large number of inspector definition files need to be written and maintained, which will bring a lot of development and maintenance work.

[0045] It is evident that, currently, the control methods for different inspector components are not flexible in the process of verifying a design by instantiating multiple inspector components from multiple inspector definition files.

[0046] Based on the above, this application provides an inspector control method, including: acquiring inspector control parameters, wherein the inspector control parameters define a controlled path and control command for an inspector in a verification environment; determining a target design module in the verification environment based on the controlled path; and controlling the inspector in the verification interface bound to the design interface of the target design module based on the control command; wherein the verification environment instantiates a verification component instance based on a verification component; an inspector definition file for instantiating inspectors is defined on the verification interface of the verification component, and the verification interface instantiated by the verification component instance is bound to the design interface of the design module corresponding to the verification component instance; the verification interface instantiated by the verification component instance correspondingly instantiates an inspector based on the inspector definition file. In this application embodiment, when an inspector definition file for instantiating inspectors is defined on the verification interface of the verification component, control of inspectors in different verification interface instances can be achieved through a single inspector definition file, avoiding the need to modify inspectors in different verification interface instances one by one in different inspector definition files, simplifying the control process of inspectors and improving verification efficiency.

[0047] Figure 3 This is a schematic diagram of the inspector control architecture in an embodiment of this application. The control process of the inspector is explained using a general verification component and an interface as an example. (Refer to...) Figure 3 As shown, the verification component can be a universal verification component (UVC), and the interface of UVC defines an inspector definition file for instantiating the inspector. Verification component instances based on the universal verification component are instantiated in the verification environment (verification component instance UVC1 and verification component instance UVC2, respectively), and interface interfaces based on the universal verification component are instantiated in the verification environment. The instantiated verification component instance UVC1 corresponds to Interface instance 1 and verification component instance UVC2 corresponds to Interface instance 2. Among them, the interface instance 1 corresponding to the verification component instance UVC1 is bound to the design interface A of design module A, and the interface instance 2 corresponding to the verification component instance UVC2 is bound to the design interface B of design module B.

[0048] Furthermore, Figure 4 This is a schematic diagram of a verification component instance instantiated from a verification component in an embodiment of this application. (Reference) Figure 4As shown, in this embodiment, `soc_uvc` is a general verification component. Based on `soc_uvc`, `inst_a_env`, `inst_b_env`, etc., can be instantiated. `inst_a_env`, as one of the verification component instances, specifically includes two main parts: an Agent (verification component instance) and an Interface instance (also known as a verification interface instance). The Agent (verification component instance) includes at least a sequencer, a driver, a monitor, and a scoreboard. The sequencer generates continuous stimulus transactions and ultimately sends them to the driver via the TLM port. The driver acquires transactions, transforms them, and then applies timing stimulus to the design in the Interface. The monitor monitors the data in the Interface. The scoreboard provides data comparison reports, such as comparing data from the monitor with data from the reference_model to verify consistency. The TLM port is declared in the scoreboard for the monitor to transmit data. The Interface instance includes an Inspector component A. The inspector is controlled through the inspector properties indicated in Inspector component A, thereby enabling the verification of the design.

[0049] Furthermore, the Interface instance contains an inspector component. Figure 5 This is a schematic diagram of an optional architecture for inspector component A in an embodiment of this application. (In conjunction with...) Figure 5 As shown, the inspector component A contains one or more inspector attributes. The inspector attributes contained in the inspector component A can be inspector attribute A1, inspector attribute A2, inspector attribute A3, etc. The inspector component A in this embodiment may also contain other optional methods, which will not be described in detail here.

[0050] The steps of the checker control method for the corresponding checker architecture are explained below.

[0051] Figure 6 This is an optional schematic diagram of the inspector control method provided in an embodiment of this application. (See reference...) Figure 6 As shown, the steps of the inspector control method can specifically include:

[0052] Step S11: Obtain the inspector control parameters, which define the controlled path and control commands of the inspector in the verification environment.

[0053] Inspector control parameters are used to control the inspectors. The verification environment instantiates a verification component instance based on the verification component. The verification interface of the verification component defines an inspector definition file for instantiating inspectors, and the verification interface instantiated by the verification component instance is bound to the design interface of the design module corresponding to the verification component instance. The verification interface instantiated by the verification component instance correspondingly instantiates inspectors based on the inspector definition file. The inspector control parameters are used to control the inspectors instantiated in the verification interface corresponding to the verification component instance. An inspector may include one or more inspector properties, and the inspector control parameters can control one or more inspector properties of the inspector.

[0054] The verification component can be a universal verification component based on the Universal Verification Methodology (UVM), used to verify whether the design conforms to the corresponding design specifications. The verification interface of the verification component defines an inspector definition file, and an instance of the verification component is instantiated in the verification environment based on the verification component.

[0055] A validation interface is used to encapsulate a collection of checker components with certain validation functions. Properties, methods, events, and structures can be declared in the validation interface, allowing the validation interface to be bound to the design interface of the design to achieve design validation.

[0056] The inspector definition file can instantiate different inspectors in the verification interface of the verification environment, thereby verifying the design module corresponding to the bound verification component instance through the instantiated inspectors.

[0057] The controlled path of the checker refers to the path information from the top level of the verification environment to the checker in the verification component instance. When the verification interface of the verification component instance is bound to the corresponding design interface, the checker can be controlled based on the controlled path, and then the controlled checker can be used to verify the design through the design interface.

[0058] The control command of the inspector is a command to change the state of a target attribute in the inspector. The control command includes the target attribute of the controlled inspector and the state of the target attribute. The target attribute indicates any one of the inspector attributes of the controlled inspector, the controlled inspector is one of the inspectors instantiated from the verification interface, and the target attribute state is the status information corresponding to the target attribute, which can be an enabled state or a disabled state.

[0059] In optional instances, inspectors are typically identified by inspector properties. An inspector has one or more inspector properties. Upon receiving a control command, based on the target property and target property status of the controlled inspector indicated in the control command, and according to the controlled path corresponding to the controlled inspector, the target property in the controlled inspector is changed to the target property status, thereby realizing the state control of the controlled inspector.

[0060] Step S12: Based on the controlled path, determine the target design module in the verification environment;

[0061] The target design module can be a part or all of the design modules in the design under test. A controlled path can be used to indicate a target design module in the verification environment. If the controlled path is the path that controls inst_a_env, it can be determined that inst_a_env is the target design module in the verification environment under that controlled path.

[0062] Step S13: Based on the control command, control the checker in the verification interface bound to the design interface of the target design module.

[0063] The control commands are used to control the inspectors in the verification interface. The control commands include the target attribute of the controlled inspector and the target attribute status. The target attribute is any one of the inspector attributes, and the target attribute status is the corresponding status information, such as an enabled or disabled state. By controlling the target attribute status of the inspector, the inspector can be controlled.

[0064] In this embodiment, an inspector definition file is defined on the verification interface corresponding to the verification component UVC. Therefore, based on the same inspector definition file, the same inspector component can be instantiated in verification interface instances corresponding to different verification component instances. For any type of inspector, the attribute state of the inspector can be controlled through a single inspector definition file. An inspector can include one or more inspector attributes. In other words, this application can control different attributes of inspectors in different verification interface instances using a single inspector definition file, avoiding the need to modify inspectors in different verification interface instances one by one in different inspector definition files. This simplifies the control process for inspectors, reduces the maintenance work of the verification environment, and improves verification efficiency.

[0065] To facilitate understanding of the inspector control method provided in the embodiments of this application, the specific steps of the inspector control method in this application will be described in more detail. Figure 7This is a schematic diagram illustrating the steps for obtaining the inspector control parameters in an embodiment of this application.

[0066] refer to Figure 7 As shown, the steps for obtaining the inspector control parameters can specifically include:

[0067] Step S21: Obtain the checker control parameters from the command line parameters.

[0068] The command-line parameters are implemented based on a simulation tool. Optionally, by entering checker control parameters in the command-line parameters of the simulation tool, the checker can be controlled through the newly entered checker control parameters.

[0069] Step S22: Divide the inspector control parameters into multiple subarrays; the multiple subarrays include a subarray of the controlled path, a subarray indicating the type of the controlled inspector, a subarray indicating the target attribute, and a subarray indicating the status of the target attribute.

[0070] Figure 8 This is a schematic diagram illustrating the process of dividing multiple arrays in an embodiment of this application. (Reference) Figure 8 As shown, in one optional implementation, step S22 may specifically include:

[0071] Step S221: Determine the command line string corresponding to the checker control parameters based on the code content of the verification component;

[0072] Optionally, the code content of the verification component is obtained by using a command-line parsing tool to extract the command-line parameters of the simulation tool into the Verilog code of the UVM verification component of the verification model, and the Verilog code of the verification component is determined as the code content of the verification component.

[0073] In one embodiment, the command line string is a string variable used to store the code content of the verification component.

[0074] Step S222: Split the command line string into multiple subarrays.

[0075] The command-line string stores the code content of the verification component. In one embodiment, the command-line string can be parsed and split into multiple subarrays using the uvm_split_string function, and the split command-line strings can be stored in different subarrays. The split arrays can be subarrays indicating the controlled path, subarrays indicating the controlled checker type, subarrays indicating the target attribute, and subarrays indicating the target attribute status. The controlled path subarray indicates the controlled path of the checker; the controlled checker type subarray indicates the checker type of the controlled checker; the target attribute subarray indicates the target attribute in the controlled checker; and the target attribute status subarray indicates the target attribute status corresponding to the target attribute in the controlled checker.

[0076] After step S222, which splits the command line string into multiple subarrays, the method further includes:

[0077] Step S223: Determine whether the path of the current verification component instance corresponds to the controlled path indicated by the subarray of the controlled path;

[0078] If not, proceed to step S224; if yes, proceed to step S225.

[0079] Step S224: Ignore the control commands indicated by the subarray of target attributes and the subarray of target attribute status.

[0080] The controlled path subarray indicates the controlled path of the checker. If the path of the current validation component instance is the same as the controlled path indicated by the controlled path subarray, then other subarray members are evaluated. If the controlled paths are different, the checkers in the current controlled path are not processed further. For example, if the controlled path subarray is `inst_a_env`, but the current control path is the control path corresponding to `inst_b_env`, the controlled paths are different. Therefore, the control commands indicated by the target attribute subarray and the target attribute status subarray corresponding to the current validation component instance are ignored.

[0081] Step S225: Based on the control command, control the checker in the verification interface bound to the design interface of the target design module.

[0082] For example, if the subarray of the controlled path is inst_a_env, and the current control path is the control path corresponding to inst_a_env, it means that the controlled paths corresponding to the two are the same, and then the subsequent steps to control the inspector in the Interface are executed.

[0083] In other words, in this application, the inspector in the Interface corresponding to the current verification component instance is controlled only when it is determined that the path of the current verification component instance corresponds to the controlled path indicated by the subarray of the controlled path. In this way, by verifying whether the controlled path is consistent in advance, the accuracy of the verification can be further guaranteed.

[0084] In optional embodiments of this application, the checker control method may also include defining circuit behavior, adding control signal conditions, and configuring hash functions. Figure 9 This is another optional schematic diagram of the inspector control method in this application embodiment. Specifically, the inspector control method further includes:

[0085] Step S31: For any attribute of the inspector, define circuit behavior for the switching control of the attribute, the circuit behavior being controlled by a control signal.

[0086] Step S32: Add a control signal condition to the attribute triggering condition of the inspector, wherein each attribute of the inspector uses a different control signal;

[0087] Step S33: Record the index information corresponding to the control signal and the name of the attribute controlled by the control signal in the hash function.

[0088] Furthermore, Figure 10 This is a schematic diagram illustrating the process of controlling the inspector based on the control commands in an embodiment of this application. (Reference) Figure 10 As shown, controlling the checker in the verification interface bound to the design interface of the target design module based on control commands includes:

[0089] Step S41: Based on the control command, determine the control signal corresponding to the target attribute;

[0090] In this context, the control signal for the target attribute corresponds to the target attribute. The target attribute is controlled by a control signal, which can be assert_en[n], where n equals the number of inspector attributes. For example, different inspector attributes can be controlled by assert_en[1], assert_en[2], assert_en[3], etc.

[0091] In a further embodiment of this application, the specific steps of determining the control signal corresponding to the target attribute in step S41 include:

[0092] Determine the name of the target attribute;

[0093] Based on the hash function, determine the control signal corresponding to the name of the target attribute.

[0094] Optionally, the hash function is configured based on a subarray of the target attribute and a subarray of the target attribute state. The configured hash function pre-configured with the correspondence between the attribute names and index information of the checker, and the index information has a conversion relationship with the control signal. Therefore, the corresponding control signal can be determined based on the name of the target attribute according to the index information.

[0095] Step S42: Using the control signal, control the target attribute of the inspector to be in the target attribute state.

[0096] The target attribute status is the status information of the target attribute of the inspector, and the target attribute status uniquely represents the target status corresponding to the inspector.

[0097] Figure 11 This is a schematic diagram of another step in the inspector control method in an embodiment of this application. (See reference) Figure 11 As shown, the inspector control method, before acquiring the inspector control parameters, includes:

[0098] Step S51: Perform simulation verification on the design;

[0099] Step S52: Check the simulation verification results. The control parameters of the checker are modified based on the inspection results of the simulation verification results.

[0100] Step S53: The checker control parameters are input via the command line of the simulation tool;

[0101] After step S53, continue to execute steps S11-S13, which are the same as described above and will not be repeated here.

[0102] Furthermore, in combination Figure 3 This example illustrates how the UVC verification component instances UVC1 and UVC2, instantiated in the verification environment, are bound to design interfaces A and B of the design module, respectively. (Reference) Figure 3 As shown, the UVC verification component and the corresponding Interface are instantiated in the verification environment as verification component instance UVC1 and corresponding Interface instance 1 (verification interface instance 1), and verification component instance UVC2 and corresponding Interface instance 2 (verification interface instance 2). Interface instance 1 is bound to design interface A of design module A, and Interface instance 2 is bound to design interface B of design module B.

[0103] When you enter checker control parameters in the command line arguments of the simulation tool, the checker control parameters will be divided into multiple subarrays. These subarrays include a subarray of the controlled path, a subarray indicating the type of the controlled checker, a subarray indicating the target attribute, and a subarray indicating the status of the target attribute.

[0104] The soc_uvc in the subarray of the controlled path is the top-level UVM verification environment in the SOC verification environment. inst_a_env is one of the verification component instances instantiated based on UVC in soc_uvc. Based on the verification model uvc, many verification component instances can be instantiated in soc_uvc. Verification component instances can be, for example, inst_a_env, inst_b_env, inst_c_env, etc.

[0105] This embodiment uses `inst_a_env` as an example for illustration. `inst_a_env` has its corresponding verification environment layer within the verification environment. In the verification component instance `UVC1` instantiated from the verification component `UVC`, during the build phase, it is determined whether the verification environment layer of `UVC1` itself is the same as the controlled path indicated in the command-line parameters. If so, the inspector in `inst_a_env` is configured, thereby controlling the inspector according to the control commands indicated in the command-line parameters. During the determination process, the assertion corresponding to the verification component instance `inst_a_env` is disabled, while the assertion in `inst_b_env` is unaffected; that is, the `inst_b_env` verification component instance retains its default value.

[0106] Determine whether the path of the current verification component instance corresponds to the controlled path indicated by the subarray of controlled paths. If so, configure the inspector attributes of the current level based on the subarray of controlled inspector type (set_assertion) and then execute the subsequent steps. If not, do not configure the inspector attributes of the current level, that is, ignore the control commands indicated by the subarray of target attributes and the subarray of target attribute status.

[0107] It's also important to note that configuration steps based on the inspector type will not be executed when the controlled paths are different. For example, the controlled path corresponding to inst_a_env will not configure the inspector attributes under the controlled path inst_b_env.

[0108] Furthermore, after the judgment is passed, the subarrays of the target attributes and the subarrays of the target attribute states can be parsed and configured into the hash function of the aforementioned retrieval checker attributes. Here, the subarray of the target attributes indicates the attribute name of the checker to be configured, and the subarray of the target attribute states indicates the state of the target attribute in the controlled checker.

[0109] The target attribute states in the subarray of the target attribute states include: 0 or 1, where 0 represents turning off the target attribute in the controlled inspector and 1 represents turning on the target attribute in the controlled inspector.

[0110] In one alternative implementation, taking the checker as an assertion as an example, the method of asserting to check whether the bus interface behavior in the design conforms to protocol requirements is explained. The specific steps to determine whether it conforms to protocol requirements are as follows:

[0111] Step 1: Define the assertion attribute name bus_assert_ack, and encapsulate the assertion entity logic in the attribute.

[0112] Step 2: Control whether to enable or disable iff using the disable iff statement. When SlaveReq is in rising latency, if assert_en[0] = 0, the check stops, i.e., assertions are disabled. If assert_en[0] = 1, assertions are enabled (assertions are turned on), and the next check is performed.

[0113] Step 3: When the reset signal is equal to 1, MasterAck should be equal to 0. If it is equal to 1, the assertion fails, and an error will be reported in the verification environment. Additionally, the two signals SlaveReq and MasterAck in the bus defined by the assertion attributes have corresponding protocol relationships.

[0114] Furthermore, the steps for controlling the inspector may include: determining the target attribute state corresponding to the target attribute name from the hash function based on the target attribute name indicated by the subarray of target attributes; and executing the control signal corresponding to the target attribute state from the determined control signals based on the target attribute state indicated by the subarray of target attribute states.

[0115] The above configuration is completed in the UVM build phase. During simulation, different configuration requirements exist depending on the test cases. There is no need to recompile the verification environment. You can directly input the checker control parameters in the command line parameters of the simulation tool to control the checker in the instantiated Interface.

[0116] In this embodiment, an inspector definition file is defined on the verification interface corresponding to the verification component UVC. This allows control of inspectors in different verification interface instances based on the same inspector definition file, avoiding the need to modify inspectors individually in different verification interface instances within different inspector definition files. This simplifies the inspector control process and improves verification efficiency. Furthermore, when instantiating inspectors in a verification interface instance, default values ​​can be set for the inspectors, specifying only the assertions that need to be enabled. This reduces the maintenance work of the verification environment. Additionally, inspector control parameters in the command-line arguments can be modified. By using a hash function to pass and parse command-line arguments, the specified assertions of the design interface can be controlled. For test cases with different assertion requirements, only the inspector control parameters in the command-line arguments need to be modified to control the target attribute state of the inspector, without modifying the verification environment code, greatly improving the flexibility and convenience of the verification environment. Moreover, in ultra-large-scale SOC environments, recompiling and modifying the verification environment takes a long time. The inspector control method provided in this embodiment avoids recompiling the verification environment, significantly improving verification efficiency.

[0117] This application embodiment also provides a verification system, including: a verification environment; the verification environment instantiates a verification component instance based on the verification component; the verification interface of the verification component defines a checker definition file for instantiating a checker, and the verification interface instantiated by the verification component instance is bound to the design interface of the design module corresponding to the verification component instance;

[0118] The verification interface instantiated by the verification component instance is correspondingly instantiated with an inspector based on the inspector definition file; the inspector is controlled based on the inspector control method provided in the embodiments of this application.

[0119] This application also provides a computer device that can be used for simulation verification of a design, as an optional implementation. Figure 12 This is an optional block diagram of the computer device in the embodiments of this application, such as... Figure 12 As shown, the computer device may include: at least one processor 1, at least one communication interface 2, at least one memory 3, and at least one communication bus 4.

[0120] In this embodiment, the number of processor 1, communication interface 2, memory 3, and communication bus 4 is at least one, and processor 1, communication interface 2, and memory 3 communicate with each other through communication bus 4.

[0121] Optionally, communication interface 2 can be an interface for a communication module used for network communication.

[0122] Optionally, processor 1 may be a CPU (Central Processing Unit), GPU (Graphics Processing Unit), NPU (Embedded Neural Network Processor), FPGA (Field Programmable Gate Array), TPU (Tensor Processing Unit), AI chip, ASIC (Application Specific Integrated Circuit), or one or more integrated circuits configured to implement the embodiments of this application.

[0123] Memory 3 may include high-speed RAM memory, and may also include non-volatile memory, such as at least one disk storage device.

[0124] The memory 3 stores one or more computer-executable instructions, and the processor 1 calls the one or more computer-executable instructions to execute the checker control method provided in the embodiments of this application.

[0125] This application embodiment also provides a storage medium that stores one or more computer-executable instructions for simulation verification of a design. When the one or more computer-executable instructions are executed, the checker control method provided in this application embodiment is implemented.

[0126] The foregoing describes multiple embodiment schemes provided by the embodiments of this application. The optional methods described in each embodiment scheme can be combined and cross-referenced with each other without conflict, thereby extending to a variety of possible embodiment schemes. These can all be considered as the embodiment schemes disclosed and published by the embodiments of this application.

[0127] While the embodiments disclosed in this application are as described above, the present invention is not limited thereto. Any person skilled in the art can make various modifications and alterations without departing from the spirit and scope of the invention; therefore, the scope of protection of the present invention should be determined by the scope defined in the claims.

Claims

1. An inspector control method characterized by comprising: The method comprises: obtaining checker control parameters, the checker control parameters defining a controlled path of a checker in a verification environment and a control command; determining a target design module in the verification environment based on the controlled path; controlling the checker in a verification interface bound to a design interface of the target design module based on the control command; and wherein the verification environment instantiates a plurality of verification component instances based on a verification component; a checker definition file for instantiating the checker is defined on a verification interface of the verification component, and a plurality of verification interfaces instantiated by the plurality of verification component instances are all bound to design interfaces of design modules corresponding to the verification component instances; a verification interface instantiated by any of the verification component instances instantiates different checkers based on the same checker definition file; the checker comprises one or more checker attributes; the control command comprises a target attribute of the controlled checker and a target attribute state, the target attribute indicating any of the checker attributes of the checker, and the target attribute state indicating an on state of the target attribute or an off state of the target attribute.

2. The inspector control method of claim 1, wherein, The controlling the checker in the verification interface bound to the design interface of the target design module based on the control command comprises: determining a control signal corresponding to the target attribute based on the control command; and controlling the target attribute of the checker to be in the target attribute state by using the control signal.

3. The inspector control method of claim 2, wherein, The determining the control signal corresponding to the target attribute comprises: determining a name of the target attribute; and determining the control signal corresponding to the name of the target attribute according to a hash function, wherein a correspondence relationship between attribute names of the checker and index information is pre-configured in the hash function, and the index information has a conversion relationship with the control signal.

4. The inspector control method of claim 3, wherein, The method further comprises: defining a circuit behavior for the on-off control of any attribute of the checker, the circuit behavior being controlled by a control signal; adding a control signal condition to a trigger condition of an attribute of the checker, wherein different control signals are used for each attribute of the checker; and recording index information corresponding to the control signal and a name of the attribute controlled by the control signal in the hash function.

5. The inspector control method of claim 1, wherein, The obtaining the checker control parameters comprises: obtaining the checker control parameters from command line parameters; and dividing the checker control parameters into a plurality of subarrays, wherein the plurality of subarrays include a subarray indicating the controlled path, a subarray indicating a type of the controlled checker, a subarray indicating the target attribute, and a subarray indicating the target attribute state.

6. The inspector control method of claim 5, wherein, The dividing the checker control parameters into the plurality of subarrays comprises: determining a command line string corresponding to the checker control parameters according to code content of a verification component; and splitting the command line string into the plurality of subarrays.

7. The inspector control method of claim 6, wherein, The splitting the command line string into the plurality of subarrays comprises: Split the command line string into a sub-array of controlled paths, a sub-array of controlled checker types, a sub-array of target attributes, and a sub-array of target attribute states, wherein the sub-array of controlled paths is used to indicate the controlled path of the checker; the sub-array of controlled checker types is used to indicate the checker type of the controlled checker; the sub-array of target attributes is used to indicate the target attribute in the controlled checker; and the sub-array of target attribute states is used to indicate the target attribute state corresponding to the target attribute in the controlled checker.

8. The inspector control method of claim 7, wherein, The obtaining of the checker control parameter further comprises: determining whether the path of the current verification component instance corresponds to the controlled path indicated by the sub-array of controlled paths; if not, ignoring the control command indicated by the sub-array of target attributes and the sub-array of target attribute states; if yes, performing the step of controlling the checker in the verification interface bound to the design interface of the target design module based on the control command.

9. The inspector control method of claim 8, wherein, The step of controlling the checker in the verification interface bound to the design interface of the target design module based on the control command comprises: determining the target attribute state corresponding to the target attribute name from the hash function according to the target attribute name indicated by the sub-array of target attributes; executing the control signal corresponding to the target attribute state from the determined control signal according to the target attribute state indicated by the sub-array of target attribute states.

10. The inspector control method of claim 1, wherein, Before the obtaining of the checker control parameter, further comprising: performing simulation verification on the design; checking the simulation verification result, modifying the checker control parameter based on the checking result of the simulation verification result, and inputting the checker control parameter through the command line of the simulation tool.

11. A verification system, comprising: comprising: a verification environment; the verification environment instantiates a verification component instance based on a verification component; the verification interface of the verification component defines a checker definition file for instantiating a checker, and the verification interface instantiated by the verification component instance is bound to the design interface of the design module corresponding to the verification component instance; wherein the verification interface instantiated by the verification component instance instantiates a checker based on the checker definition file; and the checker is controlled based on the checker control method of any one of claims 1-10.

12. A computer device, comprising: The computer device is used for simulation verification of a design, and comprises at least one memory and at least one processor, the memory stores one or more computer executable instructions, and the processor invokes the one or more computer executable instructions to execute the checker control method of any one of claims 1-10.

13. A storage medium, characterized by The storage medium stores one or more computer executable instructions for simulation verification of a design, and the one or more computer executable instructions, when executed, implement the checker control method of any one of claims 1-10.

Images