Chip verification code uniform generation method and system

Abstract

The application provides a chip verification code unified generation method and system, and relates to the technical field of chip verification. User input is received based on a predefined CSV specification table, which realizes unified description of three verification requirements of ordinary coverage points, cross coverage and timing coverage. In the generation process, functional coverage rate code and assertion checker code are simultaneously generated, which realizes the unification of coverage rate collection and runtime violation checking. Meanwhile, the application simplifies the definition of multi-signal cross coverage through columns such as cross_with, cross_illegal and cross_ignore in the specification table, and automatically generates the assertion checker of illegal combinations, thereby ensuring the completeness of white-box verification.

Description

Technical Field

[0001] This application relates to the field of chip verification technology, and more specifically, to a unified method and system for generating chip verification codes. Background Technology

[0002] In the field of chip white-box verification, functional coverage is the core indicator for measuring verification completeness, and internal checkers are a key means to ensure design correctness. Current technologies primarily employ manual coding, requiring verification engineers to directly write coverage code and assertion checker code separately using SystemVerilog, including defining interface files, coverage groups, coverage points, cross-coverage, and SVA timing assertions. This approach has the following drawbacks: First, it lacks sufficient timing behavior verification capabilities, requiring engineers to have in-depth knowledge of complex SVA syntax to describe timing scenarios such as request-response delays and handshake protocols. Second, coverage and checkers are maintained separately; the coverage target and illegal check rules for the same signal must be defined in two separate sets of code, easily leading to information redundancy and inconsistency. Third, cross-coverage definition is cumbersome; writing illegal and ignored boxes for multiple signal combinations is complex and makes it difficult to guarantee the completeness of white-box verification. Fourth, it has a high professional threshold; although RTL design engineers understand design behavior best, they cannot directly participate in the definition of verification specifications due to unfamiliarity with verification syntax. Fifth, development efficiency is low; manually writing a large amount of repetitive code is time-consuming and error-prone, resulting in high maintenance costs when design changes occur. Existing template-based or EDA tool-assisted methods can only handle simple scenarios and cannot achieve unified specification descriptions and automated generation of coverage and inspectors. Summary of the Invention

[0003] The purpose of this application is to provide a unified method and system for generating chip verification codes, so as to solve the above-mentioned technical problems.

[0004] Firstly, this application provides a unified method for generating chip verification codes, including:

[0005] The system receives user-inputted validation requirements based on a predefined CSV specification table to obtain a configured specification table file. The specification table file contains at least one validation requirement, which includes one or more of ordinary coverage points, cross coverage, and time-series coverage, and at least includes an illegal value field for defining illegal behavior.

[0006] Based on the specification table file, a unified verification specification data structure is constructed, which includes at least a signal list, a coverage point list, a cross-coverage list, and a timing item list.

[0007] Based on the verification specification data structure, SystemVerilog format functional coverage code and assertion checker code are generated. The functional coverage code includes coverage groups, coverage points, cross coverage and their corresponding illegal boxes and ignored boxes. The assertion checker is used to detect violations in real time during the simulation and output error reports.

[0008] The SystemVerilog binding file is output based on the coverage code and assertion checker code, which is then used by simulation tools for white-box verification.

[0009] In an optional implementation, the specification table file includes at least one of the following: a coverpoint_type column, a bins_spec column, and an illegal_bins column for defining normal coverage points and their illegal checks; a cross_with column, a cross_illegal column, and a cross_ignore column for defining cross coverage and its illegal combination checks; and a cover_type column, a sequence_expr column, and a property_expr column for defining temporal coverage and its temporal constraint checks.

[0010] In an optional implementation, the timing coverage is defined through the sequence_expr column, where the core timing logic expression filled in by the user is received in the sequence_expr column; clock edge and reset disable conditions are filled in through separate columns; the core timing logic expression includes one or more of the following scenarios: request-response delay, handshake protocol integrity, cross-cycle data matching, and state transition sequence;

[0011] The process of generating SystemVerilog format functional coverage code based on the specification sheet file includes: identifying signal names in the core timing logic expression and adding interface prefixes; identifying and protecting local variable declarations and references in the core timing logic expression; and generating clock edge and reset condition codes based on independent clock and reset columns.

[0012] In an optional implementation, the illegal value field includes illegal values ​​defined in the illegal_bins column and illegal combinations defined in the cross_illegal column; the assertion checker code includes an assert property statement generated for each illegal value or illegal combination, and outputs an error report when a violation occurs, the error report containing the signal path, the violation value, the simulation timestamp, and predefined descriptive information.

[0013] In an optional implementation, the cross-over is defined by the cross_with column to cross multiple signals, and by the cross_illegal and cross_ignore columns to define illegal and ignored combinations using Boolean expressions, respectively.

[0014] In an optional implementation, the specification table file also includes a sample_event column for defining the sampling conditions for cross-coverage. These sampling conditions are applied to the generated cross-coverage code to ensure that coverage sampling and violation checks are performed only under valid conditions.

[0015] In an optional implementation, when generating SystemVerilog code, an interface prefix is ​​added to all referenced signals, the interface prefix being determined based on the interface name in the specification file or a default rule.

[0016] In an optional implementation, identifying and protecting local variables in the core sequential logic expression includes: when the sequence_expr contains variable declaration and assignment statements, identifying the variable as a local variable, not adding an interface prefix when referencing it subsequently, and automatically declaring and using it correctly in the generated SVA sequence.

[0017] In an optional implementation, the method further includes: automatically calculating the total number of coverage points after the crossover based on the bins definition of each coverage point, and outputting the result to the user to evaluate the rationality of the coverage target.

[0018] Secondly, this application provides a unified chip verification code generation system, including:

[0019] The user input layer is used to receive user input validation requirements based on a predefined CSV specification table to obtain a configured specification table file; the specification table file contains at least one validation requirement, which includes one or more of ordinary coverage points, cross coverage, and time-series coverage, and at least includes an illegal value field for defining illegal behavior;

[0020] The parsing and processing layer is used to construct a unified verification specification data structure based on the specification table file. The verification specification data structure includes at least a signal list, a coverage point list, a cross-coverage list, and a timing item list.

[0021] The code generation layer is used to generate SystemVerilog format functional coverage code and assertion checker code based on the verification specification data structure. The functional coverage code includes coverage groups, coverage points, cross coverage and their corresponding illegal boxes and ignored boxes. The assertion checker is used to detect violations in real time during the simulation and output error reports.

[0022] The output layer is used to output SystemVerilog binding files based on coverage code and assertion checker code, for simulation tools to perform white-box verification.

[0023] This application receives user input based on a predefined CSV specification table, enabling a unified description of three verification requirements: ordinary coverage points, cross coverage, and timing coverage. This allows RTL design engineers to directly define verification specifications without needing to master complex SystemVerilog syntax, significantly lowering the professional threshold. During the generation process, this application simultaneously generates functional coverage code and assertion checker code based on the same specification table. The coverage code includes coverage groups, coverage points, cross coverage, and their corresponding illegal and ignored boxes, while the checker code automatically generates assertions based on the illegal value field and timing constraints in the specification table. The property statement unifies coverage collection and runtime violation checking, eliminating information redundancy and inconsistency caused by the separate maintenance of two sets of code in traditional methods. Simultaneously, this application simplifies the definition of multi-signal cross-coverage through columns such as cross_with, cross_illegal, and cross_ignore in the specification table, and automatically generates assertion checkers for illegal combinations, ensuring the completeness of white-box verification. The final output coverage code and assertion checker code files can be directly used by simulation tools, significantly improving the development efficiency, maintainability, and correctness of verification code. This allows design engineers to directly participate in the definition of verification specifications, ensuring a high degree of consistency between verification objectives and design intent. Attached Figure Description

[0024] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0025] Figure 1 This application provides a schematic flowchart of a unified chip verification code generation method.

[0026] Figure 2 A schematic diagram of another unified chip verification code generation method provided in this application embodiment;

[0027] Figure 3 This application provides a schematic diagram of a unified chip verification code generation system architecture.

[0028] Figure 4 This is a schematic diagram of the electronic device structure provided in an embodiment of this application. Detailed Implementation

[0029] The technical solutions in the embodiments of this application will now be described with reference to the accompanying drawings.

[0030] The core technical problem this application aims to solve is: how to enable RTL design engineers without a SystemVerilog verification background to quickly and accurately define functional coverage and internal checker specifications, and automatically generate compliant SystemVerilog code, thereby achieving more complete white-box verification.

[0031] Specifically, this application needs to address the following sub-problems: how to support complex timing behavior coverage and inspection using simplified specification descriptions, thereby lowering the professional threshold for timing verification; how to unify functional coverage and internal checkers (illegal checks) within a single specification description system, enabling illegal_bins to be used as a true internal checker; how to simplify the definition of cross-coverage, supporting complex scenarios such as multi-signal cross-coverage, illegal combination exclusion, and ignoring combination definitions, thus achieving more complete white-box verification; how to design a user-friendly specification table format, allowing design engineers to accurately express verification requirements without learning complex verification syntax; and how to ensure the correctness, consistency, and maintainability of the generated code.

[0032] This application proposes a specification table-driven method for automating functional coverage and internal checker code generation. The core idea is to transform the complex process of writing SystemVerilog coverage and checker code into a simple table entry process. Users only need to fill in the verification requirements in a CSV-formatted specification table, and the code generation tool provided in this application can automatically parse the specification table content and generate complete SystemVerilog code files that can be directly used for simulation.

[0033] This method simplifies the expression of timing coverage and checks, enabling users to describe complex timing verification requirements in a near-natural language manner. Supported timing scenarios include: request-response delay coverage and checks (e.g., "an ack must be received within 1-3 cycles after a req"); handshake protocol integrity verification (e.g., "a complete valid-ready handshake process"); cross-cycle data matching verification (e.g., "the sent ID and the returned ID must match"); and state transition sequence coverage (e.g., "a specific state transition path").

[0034] It automatically converts simplified syntax into standard SVA sequence and cover property code, so users don't need to learn complex SVA syntax.

[0035] This method unifies the coverage and internal checker framework. The `illegal_bins` mechanism is extended to a complete internal checker function. By defining `illegal_bins` and `cross_illegal` in the specification table, the tool not only generates coverage code but also automatically generates corresponding assertion checker code. When illegal values ​​or combinations are detected during simulation, the tool generates detailed error reports, including the name of the violation signal, the violation value, and the violation time. This allows for unified management of functional coverage collection and internal checks within the same specification system.

[0036] This method provides comprehensive cross-over support. Specifically, it supports: cross-over of any number of signals (e.g., A×B×C×D); flexible illegal combination exclusion (defined via the cross_illegal column); flexible ignored combination definition (defined via the cross_ignore column); conditional sampling (defined via the sample_event column); and automatic generation of cross-over assertion checkers.

[0037] These capabilities enable verification teams to define more comprehensive white-box verification specifications, ensuring that all important signal combination scenarios are covered and checked.

[0038] Figure 1 This is a schematic flowchart illustrating a unified chip verification code generation method provided in an embodiment of this application. Figure 1 As shown, the method may include:

[0039] S110, based on a predefined CSV specification table, receive user-inputted validation requirements to obtain a configured specification table file; the specification table file contains at least one validation requirement, which includes one or more of ordinary coverage points, cross coverage, and time-series coverage, and at least contains an illegal value field for defining illegal behavior.

[0040] The specification table file may include at least one of the following: the coverpoint_type column, bins_spec column, and illegal_bins column for defining ordinary coverage points and their illegal checks; the cross_with column, cross_illegal column, and cross_ignore column for defining cross coverage and its illegal combination checks; and the cover_type column, sequence_expr column, and property_expr column for defining timing coverage and its timing constraint checks.

[0041] Cross-over is defined by using the cross_with column to define multiple signals to cross, and by using the cross_illegal and cross_ignore columns to define illegal and ignored combinations using Boolean expressions, respectively.

[0042] Timing coverage is defined through the sequence_expr column. The sequence_expr column receives the core timing logic expression filled in by the user; clock edge and reset disable conditions are filled in through separate columns; the core timing logic expression includes one or more of the following scenarios: request-response delay, handshake protocol integrity, cross-cycle data matching, and state transition sequence.

[0043] The specification sheet also includes a sample_event column, which defines the sampling conditions for cross-coverage. These sampling conditions are applied to the generated cross-coverage code to ensure that coverage sampling and violation checks are performed only under valid conditions.

[0044] S120, based on the specification table file, construct a unified verification specification data structure. This verification specification data structure should at least include a signal list, a coverage point list, a cross-coverage list, and a timing item list.

[0045] In some embodiments, a CSV file can be read and its format validated, automatically handling the BOM header, comment lines, and blank lines, detecting delimiters, and checking whether the file is empty, has necessary columns, and whether the number of fields in each row is consistent. If a format error occurs, an error message is output and processing is terminated. Then, the table header is parsed, verifying that it contains 18 predefined columns describing the three validation requirements, checking if column names match, and reporting any missing column names and stopping execution. After successful validation, the index positions of each column are recorded. Data is parsed row by row, extracting data from each row by column and storing it in a temporary data structure starting from the second row, assigning default values ​​to empty fields, and checking the validity of key fields. Based on the `cover_type`, processing is categorized as follows: if it's empty or `bins`, `bins_spec` is parsed and converted to SystemVerilog syntax, recording the bins name and value range; `illegal_bins` is parsed as illegal bins for coverage points and prepared to generate an assertion checker; if it's `cross`, `cross_with`, `cross_illegal`, `cross_ignore`, and `sample_event` are parsed to identify signal names, associate coverage points, and check expression syntax; if it's `sequence` or `property`, `sequence_expr` or `property_expr` is parsed, automatically adding signal prefixes, protecting local variables, and separating clock and reset information. The parsed information is integrated into a unified internal data structure, including a signal list, coverage point list, cross-coverage list, and timing item list, laying the foundation for subsequent code generation and achieving unified management of verification requirements. As an example, such as... Figure 2 As shown, step S120 can be implemented through the following step AE:

[0046] Step A: Read the CSV file and verify its format.

[0047] First, the user-filled CSV format specification sheet file is read. This file can be created by any spreadsheet editing tool (such as Microsoft Excel, LibreOffice Calc, or a text editor). During the reading process, the following cases are automatically processed:

[0048] BOM header: Automatically detects and skips the Byte Order Mark (Unicode byte order mark) in the file header to avoid parsing errors.

[0049] Comment lines: Ignore lines that begin with # to make it easier for users to add comments.

[0050] Blank line: Skip lines that are empty in the file.

[0051] Delimiter detection: Automatically determines whether a file uses commas (CSV standard) or tabs (TSV) as delimiters and parses accordingly.

[0052] Format validation includes checking if the file is empty, if necessary columns exist (the number of columns will be verified in detail in subsequent steps), and if the number of fields in each row is consistent. If a format error is found, a clear error message is output and processing terminates.

[0053] Step B: Parse the table header and verify that all 18 columns are complete.

[0054] The first row of the CSV file is read as the header, and the column names contained therein are parsed. According to the design of this application, the specification table needs to contain 18 predefined columns to fully describe the three validation requirements. These 18 columns are:

[0055] Basic signal column: signal (signal name), description (description)

[0056] Common coverage point related columns: coverpoint_type, bins_spec, illegal_bins

[0057] Cross-coverage related columns: cross_with, cross_illegal, cross_ignore, sample_event

[0058] Timing coverage related columns: cover_type, sequence_expr, property_expr, clock, reset

[0059] Other auxiliary columns: module_name, interface_name, file_name, option

[0060] It can check if the table header contains all 18 columns, allowing different column orders, but column names must match exactly. If a necessary column is missing, it reports the missing column name and stops execution. After successful verification, it records the index position of each column for subsequent row-by-row parsing.

[0061] Step C: Parse the data line by line.

[0062] The CSV file is read line by line, starting from the second line. Each line represents a validation item (which could be a coverage point, a cross-coverage, or a time-series description). During parsing, the data in each line is extracted column by column and stored in a temporary data structure. Empty fields are assigned default values ​​(such as empty strings or null). Simultaneously, the validity of key fields is checked, for example:

[0063] The signal field cannot be empty (unless it is a crossover line, in which case the signal field may not be filled in, but multiple signals may be specified by cross_with).

[0064] If the cover_type field is sequence or property, then sequence_expr or property_expr must be filled in.

[0065] The contents of fields such as illegal_bins and cross_illegal must conform to the basic syntax of Boolean expressions.

[0066] Step D: Process according to cover_type.

[0067] The `cover_type` field for each row determines the type of validation requirement for that row. Based on the value of `cover_type` (which can be empty, bins, cross, sequence, property, etc.), the data is distributed to different processing branches:

[0068] Branch 1: Parsing bins_spec (normal overlay point).

[0069] If `cover_type` is empty or `bins`, it is considered a normal cover point. Parse the contents of the `bins_spec` column, which defines the specific value range of the cover point. The following syntax is supported:

[0070] Single value: such as 5;

[0071] Value list: Enclosed in curly braces and separated by commas, such as {0,1,2};

[0072] Range: Represented by square brackets, such as {[0:15]} representing all values ​​from 0 to 15;

[0073] Mixed: e.g., {0, [1:3], 7};

[0074] The parsed bins definitions are converted into SystemVerilog bins construction syntax, and the name and value range of each bin are recorded. Additionally, if the `illegal_bins` column contains content, the illegal value definitions for that column are parsed, using the same syntax as `bins_spec`. Illegal values ​​will be used in subsequent assertion checker generation.

[0075] Branch 2: Analyze illegal_bins.

[0076] The `illegal_bins` column is expanded into a complete internal checker. When the `illegal_bins` column is not empty, it is not only recorded as an illegal bin for the coverage point, but also illegal value information is extracted to prepare for the subsequent generation of the assertion checker. For example, if the `illegal_bins` column is filled with `{256}`, the illegal value of the signal `fifo_data` will be recorded as 256, and an assert property statement will be generated for this value in a subsequent step.

[0077] Branch 3: Analyze cross_with / cross_illegal.

[0078] If `cover_type` is `cross`, it is considered a cross-over. The parsing is as follows:

[0079] `cross_with`: A comma-separated list of signal names, representing multiple signals that need to be crossed. For example, `size,burst` means crossing the signals `size` and `burst`.

[0080] `cross_illegal`: A Boolean expression that defines an illegal combination. For example, `size>4&&burst==WRAP` means that the combination is illegal when `size` is greater than 4 and `burst` is of type `WRAP`.

[0081] cross_ignore: A boolean expression that defines combinations to be ignored and not included in coverage statistics.

[0082] sample_event: The sampling condition expression, such as valid&&ready, will only sample the cross-over if the condition is true.

[0083] When parsing these Boolean expressions, the tool identifies signal names within the expressions and associates them with predefined overlay points. Simultaneously, the tool automatically checks the syntax of the expressions and supports basic operators (==, !=, >, <, &&, ||, !, etc.).

[0084] Branch 4: Parsing sequence_expr.

[0085] If `cover_type` is `sequence` or `property`, it is considered a timing coverage. The core timing logic expression in the `sequence_expr` column (or `property_expr` column) is parsed. This expression uses simplified SVA syntax; the user only needs to describe the core logic of the timing relationship, for example:

[0086] req |->##[1:3] ack (A response must be received within 1-3 cycles after the request);

[0087] int id; (req_valid, id=req_id)##[1:5] (rsp_valid&&rsp_id==id) (cross-period ID matching);

[0088] During the parsing process, the following steps are performed:

[0089] Automatic signal prefix addition: Identifies and records all signal names (such as req, ack) in expressions. These signal names are then automatically added as interface prefixes (such as cov_if) during subsequent code generation.

[0090] Local variable protection: Identifies local variable declarations (such as `int id;`) in expressions and adds the declared variable names to the local variable list. When these variables are referenced subsequently (e.g., `id == saved_id`), no interface prefix is ​​added, and these variables are correctly declared and used in the generated SVA sequence.

[0091] Clock and reset are separated: the clock and reset columns are filled in independently, for example, posedge clk and !rst_n. The tool combines this information with the core expression to generate a complete SVA context.

[0092] Step E: Construct a unified verification specification data structure.

[0093] After the above classification process, all the parsed information is integrated into a unified internal data structure. This data structure contains the following main parts:

[0094] Signal list: All relevant signals and their attributes (bit width, interface prefix, etc.).

[0095] Coverage point list: Name of each normal coverage point, associated signal, bins definition, and illegal value definition.

[0096] Cross-coverage list: Name of each cross-coverage, list of signals involved in the cross, illegal combination expressions, ignored combination expressions, and sampling conditions.

[0097] Timing item list: The type (sequence or property) of each timing overridden element, core expression, clock, reset, and list of local variables.

[0098] This data structure forms the basis for subsequent code generation, ensuring that all verification requirements are managed uniformly within the same set of specification descriptions, eliminating redundancy and inconsistencies.

[0099] S130 generates SystemVerilog format functional coverage code and assertion checker code based on the verification specification data structure. The functional coverage code includes coverage groups, coverage points, cross-coverages and their corresponding illegal and ignored boxes. The assertion checker is used to detect violations in real time during simulation and output error reports.

[0100] For timing coverage, when generating SystemVerilog format functional coverage code based on the specification sheet file, it can identify signal names in the core timing logic expression and add interface prefixes, identify and protect local variable declarations and references in the core timing logic expression, and generate clock edge and reset condition codes based on independent clock and reset columns.

[0101] Among these measures, identifying and protecting local variables in core sequential logic expressions includes: when a sequence_expr contains variable declaration and assignment statements, the variable is identified as a local variable, no interface prefix is ​​added when it is referenced subsequently, and it is automatically and correctly declared and used in the generated SVA sequence.

[0102] When generating SystemVerilog code, you can add an interface prefix to all referenced signals. The interface prefix is ​​determined based on the interface name in the specification file or the default rules.

[0103] In conjunction with the foregoing examples, in some embodiments, such as Figure 2 As shown, step S130 can be implemented through the following step FG:

[0104] Step F: Generate the Interface file (xxx_if.sv).

[0105] Generate a SystemVerilog interface file based on all signals referenced in the specification table. This interface encapsulates all the necessary RTL signals and provides a declaration for each signal. The interface name can be specified through the interface_name column in the specification table; otherwise, a default name (such as cov_if) is used.

[0106] This interface will then be referenced by the coverage group and inspector modules, and also needs to be bound to the design under test (DUT).

[0107] Step G: Generate the Covergroup + Checker file (xxx_cg.sv).

[0108] Based on the data structure constructed in step E, a SystemVerilog file is generated, which contains:

[0109] Cover group definition: Each cover group corresponds to a functional module or a set of related signals. A cover group contains:

[0110] Coverpoint: Generates a corresponding coverpoint for each ordinary coverpoint, including bins definition and illegal_bins definition.

[0111] Cross coverage: Generates cross statements for each cross coverage, including ignore_bins and illegal_bins.

[0112] Sampling event: Generate sampling trigger conditions for the covergroup based on sample_event.

[0113] The assertion checker generates corresponding assertproperty statements for each illegal value, illegal combination, and timing constraint. These assertions are monitored in real time during simulation, and detailed error information is reported immediately upon violation. The illegal value field includes illegal values ​​defined in the `illegal_bins` column and illegal combinations defined in the `cross_illegal` column. The assertion checker code includes the assert property statements generated for each illegal value or illegal combination, and outputs an error report upon violation. The error report includes the signal path, the violating value, the simulation timestamp, and predefined descriptive information.

[0114] The generated assertion checker features enhanced error reporting capabilities, including: the complete path of the violation signal; the actual value of the violation (displayed in decimal and hexadecimal); the simulation timestamp of the violation; and predefined descriptive information (from the description column).

[0115] Furthermore, the assertion checker supports runtime-configurable error handling behavior. Users can control the checker's behavior through simulation parameters, such as: immediately stopping the simulation when a violation is severe; only reporting violations without stopping; counting the number of violations and generating a report.

[0116] The severity of violations is dynamically assessed based on factors such as frequency, type, and stage of the project, and appropriate handling methods are recommended (the specific implementation is supported by scripts in the simulation environment).

[0117] Calculate the completeness of cross-coverage: Evaluate the rationality of the coverage definition by comparing the ratio of the actual number of cross-coverage points generated to the theoretical maximum number of combinations. For example, if two signals have 8 and 4 bins respectively, the theoretical maximum number of combinations is 32. If the user defines ignoring combinations and excludes 8 combinations, the actual number of coverage points is 24, and the coverage rate is 75%. Output a prompt message to help the user determine whether the coverage definition needs to be adjusted.

[0118] S140 outputs SystemVerilog binding files based on coverage code and assertion checker code for simulation tools to perform white-box verification.

[0119] Generate SystemVerilog binding files, which are used to non-intrusively attach the generated interface files, functional coverage code files, and assertion checker code files to the design under test; output the generated interface files, functional coverage code files, assertion checker code files, and binding files for simulation tools to perform white-box verification.

[0120] In conjunction with the foregoing examples, in some embodiments, such as Figure 2 As shown, step S130 can be specifically implemented through the following step H:

[0121] Step H: Generate the Bind Module file (xxx_bind.sv).

[0122] To attach the generated coverage group and checker to the design under test (DUT), a bind module file is created. This file uses SystemVerilog's bind statement to instantiate the interface and bind the coverage group module to a specified instance of the DUT. Users only need to include this bind file in the simulation environment to automatically attach the verification module without modifying the original RTL code.

[0123] In some embodiments, the method further includes: automatically calculating the total number of coverage points after the crossover based on the bins definition of each coverage point, and outputting the result to the user to evaluate the rationality of the coverage target.

[0124] This application receives user input based on a predefined CSV specification table, enabling a unified description of three verification requirements: ordinary coverage points, cross coverage, and timing coverage. This allows RTL design engineers to directly define verification specifications without needing to master complex SystemVerilog syntax, significantly lowering the professional threshold. During the generation process, this application simultaneously generates functional coverage code and assertion checker code based on the same specification table. The coverage code includes coverage groups, coverage points, cross coverage, and their corresponding illegal and ignored boxes, while the checker code automatically generates assertions based on the illegal value field and timing constraints in the specification table. The property statement unifies coverage collection and runtime violation checking, eliminating information redundancy and inconsistency caused by the separate maintenance of two sets of code in traditional methods. Simultaneously, this application simplifies the definition of multi-signal cross-coverage through columns such as cross_with, cross_illegal, and cross_ignore in the specification table, and automatically generates assertion checkers for illegal combinations, ensuring the completeness of white-box verification. The final output coverage code and assertion checker code files can be directly used by simulation tools, significantly improving the development efficiency, maintainability, and correctness of verification code. This allows design engineers to directly participate in the definition of verification specifications, ensuring a high degree of consistency between verification objectives and design intent.

[0125] Timing behavior verification is the most complex part of chip functional verification, and traditional methods require verification engineers to have in-depth knowledge of SVA syntax to write the code. This application, through an innovative simplified syntax design, enables design engineers to easily define complex timing verification requirements.

[0126] Table 1. Comparison of innovations in time-series coverage:

[0127]

[0128] Among them, the simplified syntax design principle of temporal coverage is as follows:

[0129] Retain core timing operators: Users can directly use SVA's timing operators (such as `##N`, `##[M:N]`, `|->`, `|=>`), which are the core syntax for describing timing behavior. They are concise and clear, and do not require further simplification.

[0130] Automatic signal reference handling: Users only need to enter the RTL signal name, and the tool automatically adds the interface prefix. This eliminates the need for users to understand the interface mechanism.

[0131] Intelligent recognition of local variables: When an expression contains variable declarations (such as `int saved_id;`) and assignment statements (such as `saved_id=req_id`), the tool automatically recognizes these variables as local variables and does not add an interface prefix when referencing them subsequently. This makes cross-period data matching and verification simple and intuitive.

[0132] Separate clock and reset conditions: Clock edge and reset disable conditions are filled in through separate columns, avoiding users repeatedly writing template code like `@(posedge clk) disable iff (!rst_n)`.

[0133] Table 2 Supported timing verification scenarios:

[0134]

[0135] In traditional methods, functional coverage code and internal checker code are written and maintained separately. This application innovatively unifies both within the same specification table system, making illegal_bins a truly usable internal checker.

[0136] Table 3 Comparison of Traditional Method vs. This Application Method:

[0137]

[0138] The internal inspector generated in this application has the following enhancements compared to SystemVerilog's native illegal_bins:

[0139] Detailed error reporting: When an illegal value is detected, the report includes: the complete hierarchical path of the violation signal; the actual value of the violation (hexadecimal and binary formats); the simulation timestamp of the violation; and a predefined error description (from the description column of the specification sheet).

[0140] Configurable error handling: Supports control of inspector behavior via command-line arguments or runtime variables: immediately stop simulation (for critical errors); report only without stopping (for debugging phases); count violations (for evaluating design quality).

[0141] Linkage with coverage: When an illegal value is detected, the illegal_bins count in the coverage statistics is updated simultaneously to facilitate the analysis of violation frequency.

[0142] Furthermore, cross-coverage is a key method for verifying multi-signal combination scenarios, but traditional methods are complex to define and involve a large amount of code. This application simplifies the cross-coverage definition syntax, enabling users to easily define complete white-box verification specifications.

[0143] Table 4. Comparison of simplified cross-coverage syntax:

[0144]

[0145] This application can automatically generate complete cross-coverage code, including: cross-coverage definition; illegal_bins for illegal combinations; ignore_bins for ignoring combinations; and assertion checker for illegal combinations.

[0146] This application ensures the integrity of cross-coverage through the following mechanisms:

[0147] Automatic calculation of coverage points: Based on the bins definition of each signal, the total number of coverage points after the crossover is automatically calculated to help users evaluate the rationality of the coverage target.

[0148] Automatic illegal combination check: Combinations defined in `cross_illegal` are not only excluded from coverage, but corresponding assertion checkers are also generated. When these combinations occur in the simulation, an error is reported immediately.

[0149] Ignore combination records: Combinations defined in cross_ignore will be recorded but not included in the coverage, which is convenient for later analysis to determine whether the coverage needs to be expanded.

[0150] Sampling conditions linkage: The sampling conditions defined by sample_event are applied to the entire cross coverage to ensure that sampling only occurs in valid scenarios.

[0151] Cross-coverage is a key method for achieving complete white-box verification. Through the simplified syntax of this application, the verification team can:

[0152] Comprehensive coverage of control signal combinations: Ensure that all valid combinations of various control signals (such as opcodes, magnitudes, modes, etc.) are tested;

[0153] Discover hidden design flaws: Some flaws only become apparent under specific signal combinations, and cross-over coverage can ensure that these combinations are tested;

[0154] Verify the correctness of constraints: By defining illegal combinations, verify whether the design correctly prevents these combinations from occurring;

[0155] Quantitative verification completeness: Cross-coverage provides a measure of verification completeness in the signal combination dimension.

[0156] This application simplifies timing expression syntax, allowing RTL design engineers to define complex timing verification requirements without needing in-depth knowledge of SVA syntax. This improves the efficiency of timing coverage definition several times over, while reducing debugging time due to syntax errors. More importantly, design engineers, as those most familiar with the design's timing behavior, can directly participate in defining timing verification specifications, ensuring that verification goals align with design intent. Figure 1 To.

[0157] By extending `illegal_bins` into a complete internal checker, this application achieves a unified approach to functional coverage collection and runtime violation checking. Users define coverage targets and checking rules in the same specification table, and the tool automatically generates corresponding coverage code and checker code. This eliminates the problem of separate maintenance of two sets of code in traditional methods, ensuring consistency while reducing workload.

[0158] With a simplified cross-over definition syntax, users can easily define complex scenarios such as multi-signal cross-over, illegal combination exclusion, and ignore combination definitions. This enables verification teams to define more complete white-box verification specifications, ensuring that important signal combination scenarios are not overlooked. Illegal combination definitions for cross-over also automatically generate corresponding checkers, further improving verification reliability.

[0159] The specification table approach in this application allows RTL design engineers to directly participate in the definition of coverage and checkers. Design engineers do not need to learn complex SystemVerilog verification syntax; they can simply fill in the table according to intuitive rules. This breaks down the professional barriers between design and verification in traditional methods, enabling those who understand the design best to directly define verification objectives.

[0160] Automated code generation eliminates a significant amount of repetitive manual coding work. For example, a module containing 100 coverage points, 20 cross-coverages, and 10 timing coverages might take a week or more to write manually, while this application only requires filling out a form and running a command once, completing the process in minutes. When the design changes, only the relevant fields in the specification table need to be modified, and the code can be regenerated, significantly reducing maintenance costs.

[0161] The automatically generated code follows a consistent style guide, with a clear structure and consistent naming. Strict consistency is maintained between coverage code and checker code, eliminating inconsistencies that might be introduced manually. The generated code undergoes syntax validation, reducing debugging time.

[0162] Based on the same inventive concept, this application also provides a unified chip verification code generation system. For example... Figure 3 As shown, the system includes:

[0163] User input layer 301 is used to receive user input verification requirements based on a predefined CSV specification table to obtain a configured specification table file; the specification table file contains at least one verification requirement, which includes one or more of ordinary coverage points, cross coverage and time-series coverage, and at least includes an illegal value field for defining illegal behavior.

[0164] The parsing processing layer 302 is used to construct a unified verification specification data structure based on the specification table file. The verification specification data structure includes at least a signal list, a coverage point list, a cross-coverage list, and a timing item list.

[0165] The code generation layer 303 is used to generate SystemVerilog format functional coverage code and assertion checker code according to the verification specification data structure. The functional coverage code includes coverage groups, coverage points, cross coverage and their corresponding illegal boxes and ignored boxes. The assertion checker is used to detect violations in real time during the simulation and output error reports.

[0166] Output layer 304 is used to output SystemVerilog binding files based on coverage code and assertion checker code for simulation tools to perform white-box verification.

[0167] In some embodiments, the parsing processing layer 302 is specifically used to read the CSV file and verify its format; parse the header and verify the integrity of the 18 columns; parse the data row by row; classify and process the data according to cover_type; and construct a unified verification specification data structure. The code generation layer 303 is specifically used to generate the Interface file; and generate the Covergroup+Checker file (xxx_cg.sv).

[0168] Output layer 304 is specifically used to generate the Bind Module file (xxx_bind.sv).

[0169] See Figure 4 As shown, the electronic device 400 provided in this application embodiment includes at least: a processor 401, a memory 402, and a computer program stored in the memory 402 and executable on the processor 401. When the processor 401 executes the computer program, it implements the method provided in this application embodiment.

[0170] The electronic device 400 provided in this application embodiment may further include a bus 403 connecting different components (including processor 401 and memory 402). The bus 403 represents one or more types of bus structures, including memory bus, peripheral bus, local area bus, etc.

[0171] Memory 402 may include a readable storage medium in the form of volatile memory, such as random access memory (RAM) 4021 and / or cache memory 4022, and may further include read-only memory (ROM) 4023. Memory 402 may also include a program tool 4025 having a set (at least one) of program modules 4024, including but not limited to an operating subsystem, one or more application programs, other program modules, and program data, each or some combination of these examples may include an implementation of a network environment.

[0172] Processor 401 can be a single processing element or a collective term for multiple processing elements. For example, processor 401 can be a central processing unit (CPU) or one or more integrated circuits configured to implement the methods provided in the embodiments of this application. Specifically, processor 401 can be a general-purpose processor, including but not limited to CPUs, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.

[0173] Electronic device 400 can communicate with one or more external devices 404 (e.g., keyboard, remote control, etc.), and also with one or more devices that enable a user to interact with electronic device 400 (e.g., mobile phone, computer, etc.), and / or with any device that enables electronic device 400 to communicate with one or more other electronic devices 400 (e.g., router, modem, etc.). This communication can be performed through input / output (I / O) interface 405. Furthermore, electronic device 400 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) through network adapter 406. Figure 4 As shown, network adapter 406 communicates with other modules of electronic device 400 via bus 403. It should be understood that, although... Figure 4As not shown, other hardware and / or software modules may be used in conjunction with electronic device 400, including but not limited to: microcode, device drivers, redundant processors, external disk drive arrays, Redundant Arrays of Independent Disks (RAID) subsystems, tape drives, and data backup storage subsystems.

[0174] It should be noted that, Figure 4 The electronic device 400 shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0175] The computer-readable storage medium provided in the embodiments of this application is described below. The computer-readable storage medium provided in the embodiments of this application stores computer instructions, which, when executed by a processor, implement the methods provided in the embodiments of this application. Specifically, the computer instructions may be built into or installed in a processor, so that the processor can implement the methods provided in the embodiments of this application by executing the built-in or installed computer instructions.

[0176] Furthermore, the method provided in this application embodiment can also be implemented as a computer program product, which includes program code that implements the method provided in this application embodiment when run on a processor.

[0177] The computer program product provided in this application embodiment may employ one or more computer-readable storage media, which may be, but is not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination thereof. Specifically, more specific examples (a non-exhaustive list) of computer-readable storage media include: electrical connections having one or more wires, portable disks, hard disks, RAM, ROM, erasable programmable read-only memory (EPROM), optical fibers, portable compact disc read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0178] The computer program product provided in this application embodiment can be a CD-ROM and include program code, and can also run on electronic devices such as computers. However, the computer program product provided in this application embodiment is not limited thereto. In this application embodiment, the computer-readable storage medium can be any tangible medium that contains or stores program code, which can be used by or in conjunction with an instruction execution system, device, or apparatus.

[0179] It should be noted that although several units or sub-units of the device have been mentioned in the detailed description above, this division is merely exemplary and not mandatory. In fact, according to embodiments of this application, the features and functions of two or more units described above can be embodied in one unit. Conversely, the features and functions of one unit described above can be further divided and embodied by multiple units.

[0180] Furthermore, although the operations of the method of this application are described in a specific order in the accompanying drawings, this does not require or imply that these operations must be performed in that specific order, or that all the operations shown must be performed to achieve the desired result. Additionally or alternatively, certain steps may be omitted, multiple steps may be combined into one step, and / or one step may be broken down into multiple steps.

[0181] Although preferred embodiments of this application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of this application.

[0182] Obviously, those skilled in the art can make various modifications and variations to the embodiments of this application without departing from the spirit and scope of the embodiments of this application. Therefore, if these modifications and variations to the embodiments of this application fall within the scope of the claims of this application and their equivalents, this application also intends to include these modifications and variations.

Claims

1. A method for uniformly generating a chip verification code, the method comprising: generating a chip verification code by using a chip verification code generation algorithm; and transmitting the chip verification code to a chip. include: The system receives user input verification requirements based on a predefined CSV specification table and obtains a configured specification table file. The specification document contains at least one verification requirement, which includes one or more of normal coverage points, cross coverage, and timing coverage, and at least includes an illegal value field for defining illegal behavior. The timing coverage is defined through the sequence_expr column, which receives the core timing logic expression filled in by the user. Clock edge and reset disable conditions are filled in through separate columns, and the illegal value field includes illegal values ​​defined in the illegal_bins column and illegal combinations defined in the cross_illegal column. Based on the specification table file, a unified verification specification data structure is constructed. This verification specification data structure includes at least a signal list, a coverage point list, a cross-coverage list, and a timing item list. Specifically, the first line of the specification table file is read as the header, and the column names it contains are parsed. Starting from the second line, the content of the specification table file is read line by line, with each line representing a verification item. The data in each line is extracted by column and stored in a temporary data structure. For empty fields, default values ​​are assigned. Based on the `cover_type` field of each line, the data is split into different processing branches: Branch 1 is used to parse ordinary coverage points; if `cover_type` is empty or `bins`, it is considered an ordinary coverage point. Branch 2 is used to parse illegal_bins and expand them into complete internal checkers. Branch 3 is used to parse cross-coverage; if `cover_type` is `cross`, it is considered a cross-coverage. Branch 4 is used to parse timing coverage; if `cover_type` is `sequence` or `property`, it is considered a timing coverage. All parsed information is integrated into a unified verification specification data structure. Based on the verification specification data structure, SystemVerilog format functional coverage code and assertion checker code are generated. The functional coverage code includes coverage groups, coverage points, cross coverages, and their corresponding illegal boxes and ignored boxes. The assertion checker code is used to detect violations in real time during simulation and output error reports. The assertion checker code includes assert property statements generated for each illegal value or illegal combination, and outputs an error report when a violation occurs. The error report includes the signal path, the violation value, the simulation timestamp, and predefined descriptive information. The SystemVerilog binding file is output based on the coverage code and assertion checker code, which is then used by simulation tools for white-box verification.

2. The method according to claim 1, characterized in that, The specification table file includes at least one of the following: a coverpoint_type column, bins_spec column, and illegal_bins column for defining ordinary coverage points and their illegal checks; a cross_with column, cross_illegal column, and cross_ignore column for defining cross coverage and its illegal combination checks; and a cover_type column, sequence_expr column, and property_expr column for defining timing coverage and its timing constraint checks.

3. The method according to claim 2, characterized in that, The core timing logic expression includes one or more of the following scenarios: request-response delay, handshake protocol integrity, cross-cycle data matching, and state transition sequence. The process of generating SystemVerilog format functional coverage code based on the specification table file includes: identifying signal names in the core timing logic expression and adding interface prefixes, and identifying and protecting local variable declarations and references in the core timing logic expression. Clock edge and reset condition codes are generated based on independent clock and reset columns.

4. The method according to claim 3, characterized in that, The identification and protection of local variables in the core timing logic expression includes: when sequence_expr contains variable declaration and assignment statements, sequence_expr is identified as a local variable, no interface prefix is ​​added when it is referenced in the future, and it is automatically and correctly declared and used in the generated SVA sequence.

5. The method according to claim 2, characterized in that, The cross-over is defined by using the cross_with column to define multiple signals to cross, and by using the cross_illegal and cross_ignore columns to define illegal and ignored combinations using Boolean expressions, respectively.

6. The method according to claim 5, characterized in that, The specification table file also includes a sample_event column, which defines the sampling conditions for cross-coverage. These sampling conditions are applied to the generated cross-coverage code to ensure that coverage sampling and violation checks are performed only under valid conditions.

7. The method according to claim 5, characterized in that, Also includes: The system automatically calculates the total number of coverage points after the crossover based on the bins definition of each coverage point, and outputs the result to the user to evaluate the rationality of the coverage target.

8. The method according to claim 1, characterized in that, When generating functional coverage code in SystemVerilog format, an interface prefix is ​​added to all referenced signals. The interface prefix is ​​determined based on the interface name in the specification file or a default rule.

9. A unified chip verification code generation system, characterized in that, include: The user input layer is used to receive user input validation requirements based on a predefined CSV specification table to obtain the configured specification table file. The specification document contains at least one verification requirement, which includes one or more of normal coverage points, cross coverage, and timing coverage, and at least includes an illegal value field for defining illegal behavior. The timing coverage is defined through the sequence_expr column, which receives the core timing logic expression filled in by the user. Clock edge and reset disable conditions are filled in through separate columns, and the illegal value field includes illegal values ​​defined in the illegal_bins column and illegal combinations defined in the cross_illegal column. The parsing and processing layer is used to construct a unified verification specification data structure based on the specification table file. The verification specification data structure includes at least a signal list, a coverage point list, a cross-coverage list, and a timing item list. The code generation layer generates SystemVerilog format functional coverage code and assertion checker code based on the verification specification data structure. The functional coverage code includes coverage groups, coverage points, cross-coverages, and their corresponding illegal and ignored boxes. The assertion checker code detects violations in real-time during simulation and outputs error reports. Specifically, it reads the first line of the specification table file as the header and parses the column names contained within. Starting from the second line, it reads the specification table file line by line, each line representing a verification item. It extracts the data from each line by column and stores it in a temporary data structure, assigning default values ​​to empty fields. Based on the `cover_type` field of each line, it branches the data to different processing branches. Branch one is used to parse ordinary coverage points; if `cover_t`... If ype is empty or bins, it is considered a normal coverage point. Branch 2 is used to parse illegal_bins and expand illegal_bins into a complete internal checker. Branch 3 is used to parse cross coverage. If cover_type is cross, it is considered a cross coverage. Branch 4 is used to parse timing coverage. If cover_type is sequence or property, it is considered a timing coverage. All the parsed information is integrated into a unified verification specification data structure. The assertion checker code includes an assertproperty statement generated for each illegal value or illegal combination, and outputs an error report when a violation occurs. The error report includes the signal path, the violation value, the simulation timestamp, and predefined descriptive information. The output layer is used to output SystemVerilog binding files based on coverage code and assertion checker code, for simulation tools to perform white-box verification.

Images