Improving coverage in functional verification by coordinated randomization of variables across multiple classes

Abstract

A description of an excitation used for functional verification of a circuit design is received. The description includes a class of variables, and the variables include random variables. A coverage model for functional verification of the circuit design is also received. The coverage model includes a coverage target as a function of a variable. As follows, the processing device generates an incentive for a plurality of iterations of the functional verification. Context values are maintained, including values of random variables for excitation. The values of the random variables in a single class are randomized, and the randomization of the random variables in the single class is biased to hit the coverage target given context values of the random variables outside the single class. It is determined whether the generated incentive hits a coverage target.

Description

Technical Field

[0001] This disclosure relates to the functional verification of circuit designs, and more specifically, to improving the generation of sufficient stimuli to adequately verify the design. Background Technology

[0002] Functional verification is the process of determining whether a circuit design functions as expected. Coverage refers to the range of different stimulus practices (or coverages) applied to a circuit design to demonstrate the expected or specified functionality. Coverage convergence is the process of developing a set of stimuli that covers enough circuit design to adequately test it.

[0003] However, one challenge in coverage convergence is the ability to generate stimuli for rare functionalities of the practice circuits. In a constrained stochastic verification setting, some stimuli are modeled as random variables. The values ​​of these stimuli are randomly selected, resulting in a certain distribution of test cases being practiced. Frequently occurring test cases are frequently hit (practice) by randomly generated stimuli, and moderately common test cases are hit with a moderate frequency. However, some test cases may be hit very rarely. These low-frequency hits consume a disproportionate number of processing cycles to achieve coverage convergence. Summary of the Invention

[0004] In some aspects, one method includes the following: receiving a description of stimuli for functional verification of a circuit design. The description includes classes of variables, and the variables include random variables. It also receives a coverage model for functional verification of the circuit design. The coverage model includes a coverage target as a function of the variables. A processing device generates stimuli for multiple iterations of functional verification, as described below. It maintains context values, which include the values ​​of the random variables used for the stimuli. It randomizes the values ​​of the random variables in a single class and biases the randomization of the random variables in that single class to hit the coverage target given context values ​​of random variables outside that single class. It determines whether the generated stimuli hit the coverage target.

[0005] On the other hand, a system includes a compiler and a verification test platform. The compiler receives a coverage model for functional verification of a circuit design. The coverage model includes coverage targets as functions of variables used for functional verification. These variables include random variables. The compiler determines and stores context connection information from the coverage model, which identifies which coverage targets depend on which random variables. The verification test platform performs multi-stage constrained stochastic verification on the circuit design. Each stage is for a selected set of coverage targets and a selected class of variables. For each stage, the context connection information is accessed to identify the random variables on which the selected set of coverage targets depends. Context values ​​from previous stages for values ​​of random variables outside the selected classes are accessed. The values ​​of random variables in the selected classes are randomized for multiple iterations, but this randomization is biased to hit the coverage targets given context values ​​for random variables outside the selected classes. The context values ​​are updated.

[0006] Other aspects include components, devices, systems, improvements, methods, processes, applications, computer-readable media, and other technologies related to any of the foregoing aspects. Attached Figure Description

[0007] This disclosure will be more fully understood from the detailed description given below and the accompanying drawings of embodiments thereof. The drawings are provided to give an understanding of embodiments of this disclosure and are not intended to limit the scope of this disclosure to these specific embodiments. Furthermore, the drawings are not necessarily drawn to scale.

[0008] Figure 1 This is a flowchart for generating test stimuli according to some embodiments of the present disclosure.

[0009] Figure 2 Parts of a verification test platform and coverage model according to some embodiments of this disclosure are shown.

[0010] Figure 3A and Figure 3B This is another flowchart for generating test stimuli according to some embodiments of the present disclosure.

[0011] Figure 4A and Figure 4B Experimental results for generating test stimuli according to some embodiments of this disclosure are shown.

[0012] Figure 5 Flowcharts depict various processes used during integrated circuit design and manufacturing according to some embodiments of the present disclosure.

[0013] Figure 6 A schematic diagram of an example computer system in which embodiments of the present disclosure may operate is depicted. Detailed Implementation

[0014] Various aspects of this disclosure relate to improving coverage in functional verification by coordinating randomization across multiple classes of variables. In a verification methodology, stimuli are applied to a circuit design. The operation of the circuit is simulated or otherwise analyzed, and the resulting behavior is compared to the expected behavior to determine whether the circuit will function correctly. Different stimuli practice different test cases, which may be referred to as coverage targets. If the stimuli practice the test cases, it is said that the coverage target has been hit or covered. Coverage convergence is the process of developing sufficient stimuli to hit all desired coverage targets.

[0015] In constrained stochastic verification, some of the stimuli are represented as random variables. The values ​​of these variables are randomly chosen to generate different stimuli. Variables can be grouped into classes, with random variables being randomized one class at a time. In other words, during the simulation process, the random variables of each class are randomized individually.

[0016] However, generating an incentive set that covers all coverage objectives using this method can be very time-consuming. Some coverage objectives may depend on random variables from different classes, but these random variables from different classes are not randomized together. Only the variables in the current class are randomized, without considering the current values ​​of variables outside the current class. This can result in many combinations of random variables that do not increase coverage, especially when trying to hit a coverage objective that occurs very rarely given a default distribution for randomization.

[0017] In one respect, coverage convergence can be accelerated through biased randomization. Instead of using the default distribution and constraints, biased randomization can be used to increase the chances of hitting coverage targets by considering the current coverage (e.g., which coverage targets have not yet been hit) and the values ​​of other variables that also affect these coverage targets. Given the values ​​of these other variables, randomization can be biased toward increasing the chances of hitting certain coverage targets.

[0018] The conditions under which randomization occurs can be called the context. The values ​​of other variables can be called context values, and other variables can be called context variables. Which variables are context variables depends on the class being randomized and the coverage target being considered.

[0019] In one implementation, variables of different classes are randomized one class at a time during different stages of constraint randomization validation, and a data structure is used to store and pass context between these stages. Prior to runtime, a compiler (e.g., implemented using a processing device that executes instructions) can analyze the coverage model to determine which coverage targets depend on which random variables, and this context connectivity information can be stored in a database. At runtime, as constraint randomization validation proceeds, the values ​​of random variables and coverage (e.g., blind spots in coverage) can be tracked. At each stage, which random variables are relevant to the current coverage target can be determined from the context connectivity information, and the current values ​​of random variables outside the currently randomized class can be determined from the tracked context values. Then, given the context values ​​for variables outside the class, the randomization of the selected class can be biased to hit blind spots in the coverage target.

[0020] The technical advantages of this disclosure include, but are not limited to, the following: Automated coverage convergence enables teams to accelerate and improve the quality of the verification and overall design process. Bias randomization increases the chance of generating stimuli that will hit coverage blind spots. This reduces the number of stimuli generated to achieve coverage convergence or other coverage goals. This reduces the total time required to generate enough stimuli to achieve coverage convergence. It also reduces the total time required for functional verification using stimuli. With fewer stimuli, the associated processor, memory, and data bandwidth requirements are also reduced. Simulating test cases with fewer stimuli requires fewer processor cycles, storing fewer stimuli and their simulation results requires less memory, and moving all this data requires less data bandwidth.

[0021] Figure 1 This is a flowchart of a process for generating test stimuli according to some embodiments of the present disclosure. The process generates stimuli that will be used for functional verification of a circuit design. The process receives input (stimuli) descriptions for functional verification, which are defined by variables. Variables 115 are grouped into class 110. Figure 1 In the example, class 1 includes variables {var1, var2, ..., rand1, rand2, ...}, where rand... It is random variable 117, class 2, class 3, and so on.

[0022] A class is a description of different objects or constructs used in a circuit design. For example, a class can exist defined for a group. It might have command fields, addresses, serial numbers, timestamps, and group payloads. Furthermore, various actions can be performed on the group: initializing the group, setting commands, reading the group status, or checking the serial number. Each group is different, but as a class, the group possesses certain inherent characteristics that can be captured in the class definition. The class definition includes variables used to describe the class. In other words, a class is a user-defined data type that encapsulates data and the functions associated with that data.

[0023] The validation process has coverage targets to be achieved, which are defined in coverage model 120. Coverage model 120 defines coverage targets 130 as a function of variables 115. Some of the variables in variables 115 can be random variables 117. The values ​​of the random variables are randomly selected according to a certain probability distribution and are subject to value constraints.

[0024] For the verification process, the value of the random variable is randomly selected based on the probability distribution of the variable and subject to the constraints of the variable. Figure 1 Multiple iterations 150 for generating stimuli for verification are shown. Figure 1 The process biases randomization to improve validation coverage. At 160, the validation context is tracked. This includes maintaining the current values ​​of random variables. At 170, the values ​​of some random variables are randomized. Different random variables or classes(s) of random variables can be randomized during different iterations. The remaining random variables that are not randomized for the current iteration are the context variables for that iteration. The randomization at 170 is biased at 175 to hit the coverage target, given the values ​​of the context variables. For example, if there are blind spots in the coverage generated by previous stimuli, bias randomization at 175 can be used to hit those blind spots, thus improving overall coverage.

[0025] At point 180, the current coverage is determined. This includes determining which coverage targets are hit by the newly generated stimuli. At point 185, if coverage convergence has not yet been achieved (e.g., based on a threshold convergence target), more iterations are run and more stimuli are generated. Figure 1 The diagram shows a single loop for iteration 150, but the process can be implemented using multiple loops. For example, steps 180 and 185 might not be checked after each new stimulus is generated. Instead, a set of stimuli could be generated, and then steps 180 and 185 could be performed once for the entire set.

[0026] Figure 2Parts of a verification test platform and coverage model according to some embodiments of this disclosure are shown. In this SystemVerilog test platform example, random variables r1 and r2 are data members of classes C1 and C2, respectively, as defined in line 210. These random variables are connected by line 220 to the coverage target CR1 of the coverage group CG. In this specific example, the coverage target CR1 is the cross product of random variables r1 and r2.

[0027] In the procedural code 270A and 270B of this example, class objects (C1_obj of class C1) and (C2_obj of class C2) are randomized, and the coverage group CG is sampled after each randomization. However, these two classes are randomized separately at different stages of the verification. Line 270A implements the randomization of random variable r1, and line 270B implements the randomization of random variable r2. Without some context sharing, each randomization will be performed without knowing that random variables r1 and r2 are both connected to the coverage target CR1, resulting in slow coverage convergence. By utilizing context sharing, biased randomization can be used to accelerate coverage convergence. Context-based bias can be implemented in the code of the randomize() method.

[0028] Different types of biases can be implemented. Consider a simple example where random variables v1 and v2 are integers constrained to fall within the range [0:10]. Let the coverage target CT be the sum of v1 and v2, so the target CT has a possible range of [0:20]. The previously generated stimulus covers CT values ​​from [0:15], so there is currently a coverage blind zone of (15:20) for CT. Assume the two variables v1 and v2 are in different classes, so only one of the two variables will be randomized during any phase. For the current phase, let v1 be the variable to be randomized, and let v2 = 8.

[0029] Without context sharing, v1 would be randomized within the range [0:10]. However, lower v1 values ​​would not fill any coverage blind spots and would unnecessarily increase the time required for coverage convergence. By leveraging context sharing and knowledge of coverage blind spots in the CT, v1 can be constrained to the range (7,10], ensuring that any random value will hit some blind spot in the coverage. In this example, the bias is achieved by temporarily modifying the constraint on v1, changing its value range from [0:10] to (7,10]. This modification is temporary because different conditions in other stages can lead to different constraints.

[0030] In alternative approaches, instead of modifying the constraints, the probability distribution for randomization can be temporarily modified. For example, randomization for v1 uses a uniform distribution over [0:10]. This can be modified to slope towards the higher end of the range, thus increasing the chance of hitting uncovered targets. In some cases, multiple coverage targets may exist that interact in different ways. They may have overlapping or conflicting requirements for the randomization variables. Modifying the probability distribution is one way to address multiple potentially conflicting requirements.

[0031] Figure 3A and Figure 3B This is another flowchart for generating test stimuli according to some embodiments of the present disclosure. The process comprises two parts: in... Figure 3A The compilation that occurred before the verification test platform ran, as shown, and Figure 3B The verification runtime is shown.

[0032] exist Figure 3A In the compiler, coverage model 320 is received, for example, by Figure 2 The classes "C1", "C2", and "Coverage" are defined in the code. At point 325, the compiler analyzes the coverage model to determine which coverage targets depend on which random variables. Figure 2 In the example, the coverage objective "CR1" depends on random variables "r1" and "r2". This information connects different coverage objectives to different contexts. It will be referred to as context connection information 329. The dependency of the coverage objective on the random variables can be one-to-many, one-to-one, and / or many-to-one. Context connection information 329 can be stored in a database for use at runtime.

[0033] Verify runtime, such as Figure 3B As shown. In addition to context connection information 329, the runtime also accesses the values ​​of random variables from previous stages (context value 362) and the current coverage range 364. In this example, the current coverage 364 is represented by a coverage blind scoreboard that tracks blind spots in the current coverage. This scoreboard can be stored as a database.

[0034] Validation runs in phase 340. Each phase performs constraint-randomized validation against a specific set of coverage targets and randomizes random variables for specific classes. The coverage targets and the randomized classes can vary from phase to phase.

[0035] Each phase 340 proceeds as follows. At 342, the coverage blind scoreboard 364 is accessed to determine the coverage target for the current phase. At 344, context connectivity information 329 is accessed to determine which random variables constitute the context for the selected set of coverage targets. Figure 2In the example, if the current stage includes the coverage target "CR1", the context connectivity information indicates that "CR1" depends on random variables "r1" and "r2". The coverage target cg1.CR1 has the context {C1::r1, C2::r2}. Assuming class "C1" is the randomization class for the current stage, then "r1" is the randomization variable, and "r2" is the context variable for that stage. At 346, the values ​​for the context variables are retrieved from the context value database 362.

[0036] At 350, multiple validation iterations are performed using randomized values ​​for variables in the randomization class. Continuing the example above, the value of "r1" is randomized. However, given a context value for a context variable (e.g., the value of "r2" retrieved from the context value database 362), this randomization is biased to hit the selected coverage target (e.g., blind spots in the coverage of "CR1").

[0037] At 355, the value of "r1" in the context value database is updated. The value of "r2" can also change, even though it hasn't been randomized, and these values ​​are also updated. Context values ​​can change due to class randomization. They can also change due to variable assignments during validation. At 355, the coverage blind spot scoreboard 364 is also updated.

[0038] At point 340, the process is repeated for the next stage. Let class "C2" be the randomized class for the next stage. Then "r2" will be the randomization variable, and "r1" will be the context variable. The process can execute stages sequentially, proceeding through classes one at a time. Alternatively, different stages can be executed in parallel, with each stage updating various databases 362 and 364 as it progresses.

[0039] Each stage can be performed by the SystemVerilog constraint solver. The constraint solver treats randomized variables as random and context variables as non-randomized state variables. It solves for the random variable values ​​that hit the specified coverage objective.

[0040] Consider the following example. Random variable “a” is a 4-bit variable with a value range of [0:15]. Internal constraints on “a” specify that the effective value range for this variable is [0:10]. The constraint solver collects this information and then solves for suitable values ​​for “a”. Because the constraint solver is unaware that the random variables of the class are connected to the coverage objective, the generated solver solution may be insufficient for efficient convergence to the coverage objective.

[0041] The context value database 362 can be organized in different ways. Within a method, it can be organized by class. For each class, the database maintains context values ​​for random variables outside that class. It can also be organized by coverage target. For each coverage target, the database maintains context values ​​for the random variables that the coverage target depends on.

[0042] Figure 4A and Figure 4B Experimental results for generating test stimuli according to some embodiments of this disclosure are shown. Both graphs plot the coverage percentage as a function of the number of iterations (the number of stimuli generated).

[0043] Figure 4A The example has two SystemVerilog classes that contain random variables and are concatenated to a coverage group. Each random variable is 6 bits in size and can take 64 possible values. The cross product can take 64 x 64 = 4096 values. However, each random variable is randomlyized independently because they are in different classes. Curve 410 shows the coverage convergence using the method described in this paper. The value of each cross product is hit within 4098 cumulative randomizations of the class. As shown by curve 411, without this technique, it would typically require more than 20,000 cumulative randomizations on average. The lack of available context during randomization, and its disregard, leads to redundancy in value generation during the randomization process.

[0044] Figure 4B An example using three classes, all connected to a coverage group, is shown. This coverage group has approximately 256,000 bins. A bin is a value or range of values ​​for the coverage target. Curve 420 refers to the method described in this paper. It achieves coverage convergence in approximately 265,000 iterations. In contrast, the method of Curve 421, without context sharing, achieves only 61% coverage in 300,000 iterations and would require over 1,500,000 iterations to achieve full convergence.

[0045] Figure 5The illustration depicts an example set of processes 500 used during the design, verification, and manufacturing of an article of art, such as an integrated circuit, to convert and verify design data and instructions representing that integrated circuit. Each of these processes can be built and enabled as multiple modules or operations. The term "EDA" stands for "Electronic Design Automation." These processes begin with the creation of a product concept 510, where information provided by the designer is converted to create an article of art using the EDA process set 512. Once the design is complete, it is tape-out 534, at which point the layout (e.g., geometry) for the integrated circuit is sent to a manufacturing plant to create a mask set, which is then used to manufacture the integrated circuit. After tape-out, the semiconductor chip is manufactured 536, and packaging and assembly processes 538 are performed to produce a finished chip 540.

[0046] The specification scope for circuits or electronic structures can range from low-level transistor material placement to high-level description languages. High-level representations can be used to design circuits and systems using Hardware Description Languages ​​(HDLs), such as VHDL, Verilog, SystemVerilog, SystemC, MyHDL, or OpenVera. HDL descriptions can be translated into logic-level register-transfer-level (RTL) descriptions, gate-level descriptions, placement-level descriptions, or mask-level descriptions. Each lower level of representation is a more detailed description, adding more useful details to the design description, such as more details about the modules included in that description. Lower-level representations that provide more detailed descriptions can be computer-generated, derived from design libraries, or created by another design automation process. An example of a specification language used to specify a lower-level representation language for more detailed descriptions is SPICE, which is used for detailed descriptions of circuits with many analog components. The description at each level is enabled for use by the corresponding system at that layer (e.g., a formal verification system). The design process can use... Figure 5 The sequence described. The process described is enabled by an EDA product (or EDA system).

[0047] During system design phase 514, the functionality of the integrated circuit to be manufactured is specified. The design can be optimized for desired characteristics such as power consumption, performance, area (physical and / or lines of code), and cost reduction. The design can be divided into different types of modules or components at this stage.

[0048] During logic design and functional verification 516, modules or components in a circuit are specified in one or more description languages, and the functional accuracy of that specification is checked. For example, it can be verified that components of the circuit produce outputs that match the specification requirements of the designed circuit or system. Functional verification can be performed using simulators and other programs, such as testbed generators, static HDL checkers, and formal verifiers. In some embodiments, a dedicated system of components referred to as a 'simulator' or 'prototype system' is used to accelerate functional verification.

[0049] During the synthesis and design 518 for testing, HDL code is converted into a netlist. In some embodiments, the netlist may be a graph structure, where the edges of the graph structure represent components of the circuit, and the nodes of the graph structure represent how the components are interconnected. Both HDL code and netlist are layered artifacts that EDA products can use to verify that the integrated circuit performs as specified in the design when it is manufactured. The netlist can be optimized for a target semiconductor manufacturing technology. Additionally, the completed integrated circuit can be tested to verify that it meets specification requirements.

[0050] During netlist verification (520), the netlist is checked for compliance with timing constraints and consistency with the HDL code. During design planning (522), an overall placement plan for the integrated circuit is constructed, and its timing and top-level routing are analyzed.

[0051] During layout or physical implementation 524, physical placement (the location of circuit components, such as transistors or capacitors) and wiring (the connection of circuit components through multiple conductors) occur, and cells can be selected from a library to implement specific logic functions. As used herein, the term "cell" can specify a set of transistors, other components, and interconnections that provide Boolean logic functions (such as AND, OR, NOT, XOR) or storage functions (such as flip-flops or latches). As used herein, a circuit "block" can refer to two or more cells. Both cells and circuit blocks can be referred to as modules or components and are enabled as physical structures and in simulation. Parameters (such as size) are specified for the selected cells (based on "standard cells") and are accessible in a database for use by EDA products.

[0052] During the analysis and extraction phase 526, circuit functionality is verified at the layout level, allowing for refinement of the layout design. During physical verification 528, the layout design is checked to ensure correct manufacturing constraints, such as DRC constraints, electrical constraints, and lithographic constraints, and that the circuit functionality matches the HDL design specifications. During resolution enhancement 530, the geometry of the layout is transformed to improve how the circuit design is manufactured.

[0053] During the tape-out process, data is created to be used (if appropriate, after the application of lithography enhancement) to produce a photomask. During mask data preparation 532, the 'tape-out' data is used to produce a photomask for use in the manufactured integrated circuit.

[0054] Computer systems (such as) Figure 6 The storage subsystem of the computer system (600) can be used to store programs and data structures used by some or all of the EDA products described herein, as well as products used for library unit development and physical and logical designs for using the library.

[0055] Figure 6 An example machine of computer system 600 is illustrated, within which an instruction set can be executed to cause the machine to perform any or more of the methods discussed herein. In alternative embodiments, the machine may be connected to other machines in a LAN, intranet, extranet, and / or the Internet (e.g., networked). The machine may operate as a server or client machine in a client-server network environment, as a peer-to-peer machine in a peer-to-peer (or distributed) network environment, or as a server or client machine in a cloud computing infrastructure or environment.

[0056] The machine can be a personal computer (PC), tablet PC, set-top box (STB), personal digital assistant (PDA), cellular phone, network device, server, network router, switch, or bridge, or any machine capable of executing a set of instructions (sequential or otherwise) specifying the actions to be taken by the machine. Furthermore, while a single machine is illustrated, the term "machine" should also be understood to include any collection of machines that individually or jointly execute a set (or more) of instructions to perform any one or more of the methods discussed herein.

[0057] Example computer system 600 includes processing device 602, main memory 604 (e.g., read-only memory (ROM), flash memory, dynamic random access memory (DRAM), such as synchronous DRAM (SDRAM)), static memory 606 (e.g., flash memory, static random access memory (SRAM), etc.) and data storage device 618, which communicate with each other via bus 630.

[0058] Processing device 602 represents one or more processors, such as microprocessors, central processing units, etc. More specifically, the processing device may be a Complex Instruction Set Computing (CISC) microprocessor, a Reduced Instruction Set Computing (RISC) microprocessor, a Very Long Instruction Word (VLIW) microprocessor, or a processor implementing other instruction sets, or a processor implementing combinations of instruction sets. Processing device 602 may also be one or more special-purpose processing devices, such as application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), network processors, etc. Processing device 602 may be configured to execute instructions 626 to perform the operations and steps described herein.

[0059] The computer system 600 may further include a network interface device 608 for communication via a network 620. The computer system 600 may also include a video display unit 610 (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)), an alphanumeric input device 612 (e.g., a keyboard), a cursor control device 614 (e.g., a mouse), a graphics processing unit 622, a signal generation device 616 (e.g., a speaker), a graphics processing unit 622, a video processing unit 628, and an audio processing unit 632.

[0060] Data storage device 618 may include machine-readable storage medium 624 (also known as non-transitory computer-readable medium) having stored thereon one or more sets of instructions 626 or software embodying any one or more of the methods or functions described herein. Instructions 626 may also reside wholly or at least partially in main memory 604 and / or reside in processing device 602 during their execution by computer system 600, both of which also constitute machine-readable storage media.

[0061] In some embodiments, instruction 626 includes instructions for implementing functions corresponding to this disclosure. While machine-readable storage medium 624 is shown as a single medium in the example embodiments, the term "machine-readable storage medium" should be considered to include a single medium or multiple media (e.g., a centralized or distributed database, and / or associated caches and servers) storing one or more sets of instructions. The term "machine-readable storage medium" should also be considered to include any medium capable of storing or encoding a set of instructions for execution by a machine and causing the machine and processing device 602 to perform any one or more methods of this disclosure. Therefore, the term "machine-readable storage medium" should be considered to include, but is not limited to, solid-state memories, optical media, and magnetic media.

[0062] Some of the parts described in detail above have been presented based on algorithms and symbolic representations of data bit manipulations within computer memory. These algorithmic descriptions and representations are the most effective way for those skilled in the art of data processing to communicate the essence of their work to others skilled in the art. An algorithm can be a sequence of operations that leads to a desired result. These operations are operations that require physical manipulation of physical quantities. These quantities can take the form of electrical or magnetic signals that can be stored, combined, compared, and otherwise manipulated. These signals can be referred to as bits, values, elements, symbols, characters, items, numbers, etc.

[0063] However, it should be remembered that all these and similar terms are associated with appropriate physical quantities and are merely convenient labels applied to those quantities. Unless otherwise stated, it is apparent from this disclosure that, throughout the specification, certain terms refer to the actions and processes of a computer system or similar electronic computing device, the manipulation and conversion of data represented as physical (electronic) quantities within computer system registers and memories into other data similarly represented as physical quantities within computer system memory or registers or other such information storage devices.

[0064] This disclosure also relates to an apparatus for performing the operations described herein. The apparatus may be specifically constructed for its intended purpose, or it may comprise a computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program may be stored in a computer-readable storage medium, such as, but not limited to, any type of disk including floppy disks, optical disks, CD-ROMs, and magneto-optical disks, read-only memory (ROM), random access memory (RAM), EPROM, EEPROM, magnetic cards, or optical cards, or any type of medium suitable for storing electronic instructions, each medium coupled to a computer system bus.

[0065] The algorithms and displays presented herein are not inherently related to any particular computer or other device. Various other systems may be used with the programs taught herein, or it may be convenient to construct more specialized devices to perform the methods. Furthermore, this disclosure is not described with reference to any particular programming language. It should be understood that the teachings of this disclosure described herein can be implemented using a variety of programming languages.

[0066] This disclosure may be provided as a computer program product or software, which may include a machine-readable medium having instructions stored thereon that can be used to program a computer system (or other electronic device) to perform processes according to this disclosure. A machine-readable medium includes any mechanism that stores information in a machine-readable (e.g., computer-readable) form. For example, machine-readable (e.g., computer-readable) media include machine-readable (e.g., computer-readable) storage media, such as read-only memory (“ROM”), random access memory (“RAM”), disk storage media, optical storage media, flash memory devices, etc.

[0067] In the foregoing disclosure, embodiments of the present disclosure have been described with reference to specific exemplary embodiments. It is apparent that various modifications may be made thereto without departing from the broader spirit and scope of the embodiments set forth in the following claims. When certain elements are referred to in the singular in this disclosure, more than one element may be depicted in the drawings, and the same elements are labeled with the same numbers. Therefore, this disclosure and the drawings should be considered illustrative rather than restrictive.

Claims

1. A method comprising: Receive a description of the stimulus used for functional verification of the circuit design, the description including a class of variables, the variables including random variables; as well as Receive a coverage model for functional verification of the circuit design; the coverage model includes a coverage target as a function of the variables; The stimulus is generated by the processing device through multiple iterations of the functional verification, including: Maintain context values, which include the values ​​of the random variables used for the stimulus; Randomize the values ​​of the random variables in a single class; and The randomization of the random variable within the single class is biased to hit the coverage target given the context value of the random variable outside the single class; and Determine whether the coverage target is hit by the generated stimulus.

2. The method according to claim 1, further comprising: Maintain coverage blind zone data, which indicates which coverage targets have not yet been hit by previously generated stimuli, wherein the randomization of the random variable is biased based on the coverage blind zone data to hit the missed coverage targets.

3. The method of claim 1, wherein biasing the randomization of the random variable includes applying a temporary constraint to the randomization of the random variable.

4. The method of claim 1, wherein biasing the randomization of the random variable includes temporarily modifying the probability distribution used for the randomization.

5. The method of claim 1, wherein the multiple iterations of generating stimuli for the functional verification further include randomizing the value of the random variable one class at a time.

6. The method according to claim 1, further comprising: Based on the coverage model, identify which coverage targets depend on which random variables.

7. The method of claim 1, wherein the class is a user-defined data type that encapsulates data and functions associated with the data.

8. A system comprising a compiler and a verification test platform, wherein: The compiler is configured as follows: Receive a coverage model for functional verification of circuit design; the coverage model includes a coverage target as a function of variables of an stimulus used for the functional verification, the stimulus including random variables; as well as From the coverage model, context connectivity information is determined and stored, which identifies which coverage targets depend on which random variables; as well as The verification test platform is configured to perform multi-stage constrained stochastic verification of the circuit design, each stage targeting a selected set of coverage objectives and a selected class of variables; each stage includes: Access the context connection information to identify the random variables on which the selected coverage target set depends; Access the context value of a random variable from a previous stage that is outside the selected class; Perform multiple iterations to randomize the values ​​of random variables in the selected class, wherein the randomization is biased to hit the coverage target given the context value of the random variable outside the selected class; and Update the context value.

9. The system of claim 8, wherein the values ​​of the random variables are randomized one class at a time during the execution of the plurality of stages.

10. The system of claim 9, wherein the plurality of stages are executed in parallel.

11. The system of claim 8, wherein the context connectivity information includes one-to-many, one-to-one, and many-to-one dependencies of the coverage target on the random variable.

12. The system according to claim 8, wherein the verification test platform includes a SystemVerilog constraint solver.

13. The system of claim 12, wherein the random variable other than the selected class is treated as a state variable by the SystemVerilog constraint solver.

14. The system of claim 8, wherein the verification test platform includes a database containing the context connection information and the context values ​​from previous stages.

15. The system of claim 8, wherein the verification test platform includes a database containing context values ​​for random variables outside the class for each class.

16. The system of claim 8, wherein the verification test platform includes a database containing context values ​​for random variables on which the coverage target depends for each coverage target.

17. A non-transitory computer-readable medium comprising stored instructions, which, when executed by a processing device, cause the processing device to perform a plurality of stages: Determine the random variables on which the coverage target set depends; wherein the random variables are stimuli for functional verification of the circuit design, and the coverage target is a coverage target for the functional verification; Determine the class of the random variables to be randomized in the current phase; Retrieve the value of a random variable outside the class mentioned above; Perform the following multiple iterations: The values ​​of the random variables in the class are randomized, wherein the randomization is biased to hit the coverage target given the values ​​of the random variables outside the class; as well as The functional verification is performed using the randomized value of the random variable within the class and the value retrieved for a random variable outside the class.

18. The non-transitory computer-readable medium of claim 17, wherein the coverage target comprises the cross product of random variables in the class and random variables outside the class.

19. The non-transitory computer-readable medium of claim 17, wherein the random variable is user-defined and subject to user-defined constraints on the value of the random variable.

20. The non-transitory computer-readable medium of claim 17, wherein the class is a user-defined data type that encapsulates data and functions associated with the data.

Images