Adaptable Constraint Extraction for ML in Design Verification

Minh Luu -

In recent years, the use of AI in design verification has become increasingly popular due to the growing complexity of designs and the need for more efficient verification methods. AI can help automate constraint optimization, optimize stimulus generation, and speed up root-cause analysis. However, beyond developing more intelligent methods, it is equally important to develop adaptable data extraction methods for AI to ensure effective integration into various verification workflows.

In this blog post, we will explore VerifAI constraint extraction tool and how it can efficiently extract various constraints from designs. We will discuss considerations for developing adaptable data extraction methods for AI in design verification.

Constraints

Constraints are essential in design verification, defining the legal behavior of a design. They specify desired outcomes, guide the verification process, and outline timing requirements, legal signal values, relationships between signals, and permissible operation sequences. Consequently, constraints are utilized in various verification tasks, including formal verification, emulation, and simulation. This blog, specifically, focuses on constraints written in Verilog/SystemVerilog.

Constraint Expressions

A constraint must conform to a set of rules defined by the language in which it is written. For example, in SystemVerilog, constraints are written using the constraint keyword followed by a name and a set of expressions enclosed in curly braces. The expressions can include logical operators, arithmetic operators, and relational operators. They may also include distribution probabilities and permitted values. Constraint definitions are then used by the constraint solver to generate the final values of random variables.

A constraint using relational operators <=. In this case, three non-overlapping sections of the mbus_addr_array must adhere to different conditions.
A constraint that specifies a range of values permitted for the op variable. In this case, the randomization can only generate values between 0 and 3.
A constraint using distribution keyword dist to inform the constraint the solver that these values have different probabilities of being generated. In this case, 000 is a NOP code and it has a specific probability of being generated relative to other permitted values.

VerifAI RL Engine and Constraint Extraction

At VerifAI, we have developed an RL engine to speed up coverage closure quickly. By treating constraints as a set of knobs, we can optimize the constraints to maximize coverage. Manually converting constraints into a format that can be used by the RL engine is time-consuming and error-prone. To address this, we developed a constraint extraction tool that automatically extracts constraints from a design. This tool can extract constraints written in Verilog/SystemVerilog and convert them into a format that can be used by the RL engine. Furthermore, with adaptability in mind, in the near future, users can upload their own .v/.sv source files to the VerifAI web app and get back a file of extracted constraints for specific data analysis and/or ML applications.

The overall workflow for V/SV constraint extraction and optimization.

The challenge with constraint extraction is that constraints can be written in various ways, making it difficult to develop a tool to extract all constraints. This is where an AST can be useful.

Abstract Syntax Tree (AST)

An Abstract Syntax Tree (AST) is highly effective for extracting SystemVerilog constraints because it provides a structured representation of the code, capturing syntax and semantics consistently. By organizing code elements into nodes, the AST enables our extractor to recognize constraints regardless of specific syntax or style, handling various constraint formats uniformly and improving extraction results.

VerifAI Constraint Extraction

At the time of writing, our tool supports the constraints of the types of writing in this blog post: simple expressions, inside/inverted inside operators, and weighted distributions. Let's walk through some examples.

Simple Expressions

For simple expressions, we took an .sv file from the OpenTitan project, an open-source repository of IP RTL with a UVM-based testbench. This way, we can show the capability of the constraint extractor on a testbench that is comparable to commercial ones.

For this type of constraint, our current approach is to break the expression down into expressions and operators. This format can then be formatted further to generate a final knob that can be used by the RL agent. Bidirectional constraint expressions are extracted similarly.

A virtual sequence that contains three constraints with simple expressions.
The extracted version of the first and second constraints from the above example. The header contains the exact location each expression and operator.
The extracted version of the bidirectional constraint (along with an inside constraint). All comments are ignored.

Inside/Inverted Inside Operators

For the inside operator, we tested our extractor on a 4-core MESI design from OpenCore with an in-house UVM testbench. The approach is to break down the inside expression into multiple values that can be used to change or append later by the RL Engine. For the inverted inside constraint, we simply indicate on the header with the word not, making it easier to read.

The first constraint contains an inside operator with multiple values. The second one contains the ! operator, indicating an inverted inside constraint.
For each constraint, the naming scheme is the constraint's name, the inside or not_inside operator, and the numbering to distinguish between multiple values.

Weighted Distributions

The constraint extractor supports both := and :/ operators for weight distribution constraints. The format retains the

Similar extraction pattern and header naming is used. This is for dist constraint with :\ operator.
This is for dist constraint with := operator.

Complex Constraints
There might be a question about the subconst prefix in many header texts. The reason is there could be multiple types combined into one complex constraint, like the picture below. While it looks complicated, breaking the constraint down into multiple sub-constraints allows the extractor to use the same extraction techniques from the example above to process complex constraints.

Multiple types of expression within the same constraint.
By having specific header, the RL engine can control specific knob that it wants, even for complicated constraint.

Knob Generation

The final step needed is to convert the extracted dataset into controllable knobs that can be exported. Here, we are doing it in three steps, as shown in an example below:

Original written SystemVerilog constraints
  • Extraction: This step is described in the previous section, where the written constraints are analyzed, and data is put into a tabular format for further analysis. The header contains additional information needed for easy identification. Furthermore, a template json file is generated containing the information for knob generation and constraint optimization later.
Extraction data for the first constraints
JSON config files for user control
  • JSON file editing:
    - The label and name are default knob names that users can edit freely for their needs.
    - The raw name allows the knob generate to identify the location of a constraint definition that can be used for the next step.
    - Default value can be modified freely.
    - The value range gives the VerifAI RL agent a range of values to intelligently generate.
  • Generate knobs and modify RTL: Using the header (raw_name), the knob generator can generate a constraints_define file that contains the knobs and their default values. These knobs also replace the values written within the constraint. This way, the RL agent does not have to deal with modifying the constraints directly, instead focusing on controlling the knobs.
Knob generator creates a new knob file and replaces written values with knobs

Conclusion

In this blog, we introduced adaptability in data extraction methods for ML in Design Verification (DV). Specifically, we introduced Verilog/SystemVerilog constraint extraction method with support from VerifAI's AST (Abstract Syntax Tree) based on OpenSource Verible's parsers. We first introduced constraint and its roles in DV, intelligent coverage optimization, and the importance of having an automatic constraint extractor as part of the optimization process.

Thanks to using an Abstract Syntax Tree (AST) as a pre-processing method, we can ensure all written constraints conform to a standard easily processed by the extractor, as demonstrated by various constraint types successfully extracted by our extractor, including one written in UVM testbenches. Our goal is to continue improving our extractor and integrate it into our VerifAI web app in the future so users can try it out. We cannot wait!

  1. https://opentitan.org/
  2. https://github.com/chipsalliance/verible
  3. M. R. Kulkarni, et al., “Improving coverage of simulation-based design verification using machine learning techniques,” 2019, Master’sthesis, University of Texas at Austin.
  4. Z. Aref, R. Suvarna, W. Hughes, S. Srinivasan, and N. Mandayam, “Advanced Reinforcement Algorithms to optimize Design Verification,” IEEE Design Automation Conference (DAC), San Francisco, USA, June 2024, pp. 1-6.
  5. W. Hughes, S. Srinivasan, R. Suvarna, and M. R. Kulkarni, “Optimizing Design Verification using Machine Learning: Doing better than Random,” unpublished.
  6. R. S. Sutton, and A. G. Barto, Reinforcement Learning: An introduction, 2018, MIT press.
  7. D. Silver, et al., “Deterministic Policy Gradient Algorithms,” International conference on Machine Learning (ICML), Beijing, China, June 2014, pp. 387-395.