Verification environment generation method and apparatus, and electronic device

Abstract

Embodiments of the invention provide a verification environment generation method and apparatus, and an electronic device. The method comprises the steps that according to a document format of a design document corresponding to a chip to be tested, the design document is recognized, and a recognition document is obtained; the recognition document is analyzed, multiple pieces of register information corresponding to the multiple registers are obtained, and the register information comprises register identifiers, boundary information and field line indexes; based on the design document, standardizing the register information corresponding to each register to generate a standardized data structure, the standardized data structure comprising a plurality of sub-data structures corresponding to the plurality of registers; based on the standardized data structure, generating a verification code meeting a verification environment specification; and integrating the verification code into the target verification environment to complete a verification task of the to-be-tested chip. The method is used for achieving the effect of improving the chip verification efficiency.

Description

Technical Field

[0001] This application relates to the field of testing technology, and in particular to a method, apparatus, and electronic device for generating a verification environment. Background Technology

[0002] After the chip design is completed, simulation verification is required to ensure the correctness of the design code.

[0003] In existing technologies, verification engineers need to extract key configuration information (such as register names, bit widths, configuration values, etc.) from the design specification documents (such as Excel, Word, TXT, etc.) provided by the designer, and manually write verification environment code to build a simulation environment to test the design functions, which makes the chip verification inefficient. Summary of the Invention

[0004] This application provides a method, apparatus, and electronic device for generating a verification environment, which can improve the efficiency of chip verification.

[0005] In a first aspect, embodiments of this application provide a method for generating a verification environment, comprising:

[0006] According to the document format of the design document corresponding to the chip under test, the design document is identified to obtain the identified document;

[0007] The identified document is parsed to obtain multiple register information corresponding to multiple registers. The register information includes register identifier, boundary information and field row index.

[0008] Based on the design document, the register information corresponding to each register is standardized to generate a standardized data structure, which includes multiple sub-data structures corresponding to the multiple registers.

[0009] Based on the standardized data structure, verification code conforming to the verification environment specifications is generated;

[0010] The verification code is integrated into the target verification environment to complete the verification task of the chip under test.

[0011] In one possible implementation, based on the design document, the register information corresponding to each register is standardized to generate a standardized data structure, including:

[0012] Obtain the standardization rules corresponding to the register information. The standardization rules include field standardization rules and register standardization rules.

[0013] Based on the standardization rules, the design document, and the register information corresponding to each register, determine the sub-data structure corresponding to each register;

[0014] The sub-data structures corresponding to each register are sorted and assembled to obtain the standardized data structure.

[0015] In one possible implementation, for any given register, a sub-data structure is determined based on the standardization rules, the design document, and the register information corresponding to the register, including:

[0016] Based on the field standardization rules and the register information, the field standardization data is obtained;

[0017] Register standardization data is generated based on the aforementioned register standardization rules and register information;

[0018] The normalized register data and the normalized field data are concatenated to obtain the sub-data structure.

[0019] In one possible implementation, the field normalization data includes a field bit width; the register information includes a bit field; determining the field bit width according to the field normalization rules and the bit field includes:

[0020] The bit field is parsed to obtain the low-order bit value and the high-order bit value;

[0021] The field width is determined based on the low-order byte value and the high-order byte value.

[0022] In one possible implementation, based on the standardized data structure, verification code conforming to the verification environment specifications is generated, including:

[0023] Based on the verification environment specifications, generate task prefixes and signal declarations;

[0024] The verification code is obtained by filling the placeholders in the code template with the task prefix, the signal declaration, and the standardized data structure.

[0025] In one possible implementation, the identified document is parsed to obtain register information corresponding to multiple registers, including:

[0026] The identified document is processed to extract fields, resulting in valid field row information;

[0027] In the valid field row information, determine the start row number and end row number corresponding to each register;

[0028] For any register, the register information is generated based on the valid field row information and the start and end row numbers corresponding to the register.

[0029] In one possible implementation, for any given register; determining the start and end line numbers corresponding to the register from the valid field line information includes:

[0030] Based on the starting line determination criteria, the starting line of the register is determined in the valid field lines of the identified document;

[0031] Based on the end-line determination condition, the end line of the register is determined in the valid field line following the start line.

[0032] Secondly, embodiments of this application provide a verification environment generation apparatus, including an identification processing module, a parsing processing module, a standardization processing module, a generation module, and an integration module:

[0033] The identification processing module is used to identify the design document according to the document format of the design document corresponding to the chip under test, and obtain the identification document.

[0034] The parsing processing module is used to parse the identified document to obtain multiple register information corresponding to multiple registers. The register information includes register identifiers, boundary information, and field row indexes.

[0035] The standardization processing module is used to standardize the register information corresponding to each register based on the design document, and generate a standardized data structure, wherein the standardized data structure includes multiple sub-data structures corresponding to the multiple registers.

[0036] The generation module is used to generate verification code that conforms to the verification environment specifications based on the standardized data structure.

[0037] The integration module is used to integrate the verification code into the target verification environment to complete the verification task of the chip under test.

[0038] In one possible implementation, the standardization processing module is specifically used for:

[0039] Obtain the standardization rules corresponding to the register information. The standardization rules include field standardization rules and register standardization rules.

[0040] Based on the standardization rules, the design document, and the register information corresponding to each register, determine the sub-data structure corresponding to each register;

[0041] The sub-data structures corresponding to each register are sorted and assembled to obtain the standardized data structure.

[0042] In one possible implementation, for any given register, the normalization processing module is specifically used for:

[0043] Based on the field standardization rules and the register information, the field standardization data is obtained;

[0044] Register standardization data is generated based on the aforementioned register standardization rules and register information;

[0045] The normalized register data and the normalized field data are concatenated to obtain the sub-data structure.

[0046] In one possible implementation, the field normalization data includes the field bit width; the register information includes a bit field; and the normalization processing module is specifically used for:

[0047] The bit field is parsed to obtain the low-order bit value and the high-order bit value;

[0048] The field width is determined based on the low-order byte value and the high-order byte value.

[0049] In one possible implementation, the generation module is specifically used for:

[0050] Based on the verification environment specifications, generate task prefixes and signal declarations;

[0051] The verification code is obtained by filling the placeholders in the code template with the task prefix, the signal declaration, and the standardized data structure.

[0052] In one possible implementation, the parsing processing module is specifically used for:

[0053] The identified document is processed to extract fields, resulting in valid field row information;

[0054] In the valid field row information, determine the start row number and end row number corresponding to each register;

[0055] For any register, the register information is generated based on the valid field row information and the start and end row numbers corresponding to the register.

[0056] In one possible implementation, for any given register, the parsing module is specifically used for:

[0057] Based on the starting line determination criteria, the starting line of the register is determined in the valid field lines of the identified document;

[0058] Based on the end-line determination condition, the end line of the register is determined in the valid field line following the start line.

[0059] Thirdly, embodiments of this application provide a chip, the chip including instructions for a processor, the processor being configured to execute computer execution instructions to implement the first aspect and / or various possible implementations of the first aspect.

[0060] Fourthly, embodiments of this application provide an electronic device, including: a memory and a processor;

[0061] The memory stores computer-executed instructions;

[0062] The processor executes computer execution instructions stored in the memory, causing the processor to perform the first aspect and / or various possible implementations of the first aspect as described above.

[0063] Fifthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the first aspect and / or various possible implementations of the first aspect.

[0064] Sixthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the first aspect and / or various possible implementations of the first aspect.

[0065] The verification environment generation method, apparatus, and electronic device provided in this application can identify and process a design document according to its document format to obtain an identified document, and then parse the identified document to obtain multiple register information. Based on the design document, the register information corresponding to each register can be standardized to generate a standardized data structure, and then verification code conforming to the verification environment specification can be generated. The verification code can be integrated into the verification environment to complete the verification task of the chip under test. The verification task of the chip under test can be automatically executed without manual processing, thereby improving the efficiency of chip verification. Attached Figure Description

[0066] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0067] Figure 1 A schematic diagram illustrating the application scenarios provided in the embodiments of this application;

[0068] Figure 2 A flowchart illustrating a method for generating a verification environment provided in an embodiment of this application;

[0069] Figure 3 A flowchart illustrating another method for generating a verification environment provided in this application embodiment;

[0070] Figure 4 A schematic diagram of the architecture of a method for generating a verification environment provided in an embodiment of this application;

[0071] Figure 5 A schematic diagram of a verification environment generation device provided in an embodiment of this application;

[0072] Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0073] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0074] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0075] Figure 1 This is a schematic diagram illustrating an application scenario provided in an embodiment of this application. Please refer to [link / reference]. Figure 1 The specific application scenarios of this application may include the chip to be tested 101 and the test equipment 102.

[0076] The chip under test 101 is a completed chip design, which can be a mobile phone chip, TV chip, automotive chip, or industrial-grade chip, etc. After the design of the chip under test 101 is completed, the correctness of the design code needs to be verified through simulation. A simulation environment can be set up in the test equipment 102 to execute the verification code corresponding to the design document of the chip under test 101, and test the functions designed in the chip under test 101. The design code of the chip under test 101 is recorded in the design document.

[0077] In existing technologies, verification engineers need to extract key configuration information (such as register names, bit widths, configuration values, etc.) from the design specification documents (such as Excel, Word, TXT, etc.) provided by the designer, and manually write verification environment code to build a simulation environment to test the design functions, which makes the chip verification inefficient.

[0078] The verification environment generation method provided in this application embodiment can: first, identify the design document according to the document format of the design document corresponding to the chip under test to obtain an identified document; second, parse the identified document to obtain multiple register information corresponding to multiple registers, the register information including register identifiers, boundary information, and field row indexes; third, standardize the register information corresponding to each register based on the design document to generate a standardized data structure, the standardized data structure including multiple sub-data structures corresponding to multiple registers; fourth, generate verification code that conforms to the verification environment specification based on the standardized data structure; and fifth, integrate the verification code into the verification environment to complete the verification task of the chip under test.

[0079] In the above execution process, the generated verification code can be integrated into the verification environment, and the verification task of the chip under test can be automatically executed in the simulation environment of the test equipment without manual processing, which can improve the efficiency of chip verification. At the same time, it can reduce human error and improve the accuracy of chip verification.

[0080] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will be described below with reference to the accompanying drawings.

[0081] Figure 2 This is a flowchart illustrating a method for generating a verification environment according to an embodiment of this application. Please refer to [link / reference]. Figure 2 The method may include:

[0082] S201. Based on the document format of the design document corresponding to the chip under test, the design document is identified to obtain the identified document.

[0083] The execution entity in this application embodiment can be a test device or a chip of a test device, or it can be a verification environment generation device disposed in the test device or the chip of the test device. The verification environment generation device can be implemented by software or by a combination of software and hardware.

[0084] The design document can be the design specification document of the chip under test, which records key design information such as register definitions, field configurations, and functional logic of the chip under test.

[0085] Document formats can include Excel spreadsheets, Word documents, and plain text files (TXT), allowing users to flexibly choose the format based on their actual design output.

[0086] A rules engine can be used to uniformly identify and process design documents of different document formats.

[0087] The rules engine can be built-in with rules for document format recognition, key field matching, and data cleaning, automatically adapting to different document structures and extracting standardized intermediate data without the need for manual intervention in format adaptation.

[0088] In some embodiments, the design document can be pre-validated in terms of document format. After the document format pre-validation passes, the recognition process is performed. The pre-validation may include verifying the document's legality and format compatibility.

[0089] When validating the validity of a document, you can check if the design document is corrupted (e.g., .xlsx files cannot be opened, .docx tables have a disordered structure, .txt files are empty). If corruption is found, an error message will be triggered (e.g., "Document is corrupted, please upload a valid design document").

[0090] When verifying format compatibility, you can determine whether the document extension belongs to a supported format (.xlsx / .docx / .txt). If it is not a supported format (such as .pdf / .csv), the message "Only Excel / Word / TXT formats are currently supported. Please convert and upload" will be displayed.

[0091] After the pre-validation is passed, different document formats will be identified according to the following rules:

[0092] If the document format is Excel (i.e., the design document has the .xlsx extension), the openpyxl library can be used to open the design document, locate the target worksheet (the default first sheet or a user-specified sheet), read all rows of data (including the header), store them as a two-dimensional list (row index - column index - cell value), and obtain the recognized document.

[0093] If the document format is Word (i.e., the design document has a .docx extension), you can use the python-docx library to extract all tables in the document, filter tables containing key fields such as "RegName", "Register Name", "Offset", and "Offset" as target tables, read all rows of data in the table, convert them into a two-dimensional list (row index - column index - cell value), and obtain the recognized document.

[0094] If the document format is TXT (i.e., the design document has a .txt extension): Open the file in read-only mode, read all the content line by line, filter out lines with only spaces, store it as a one-dimensional list (line index - line content string), and record the original line number to obtain the recognized document.

[0095] After designing and processing documents of different document formats, the resulting recognized documents have a unified structured data format (two-dimensional list or one-dimensional list), which can ensure that subsequent parsing steps can be performed based on a unified data structure without repeated format adaptation.

[0096] This application supports the parsing of various document formats (such as Excel, Word, and TXT). A rules engine can uniformly process different document formats, reducing manual adaptation costs and improving document processing efficiency. Furthermore, through pre-validation and exception notification mechanisms, process interruptions caused by invalid documents can be avoided in advance, significantly improving the efficiency and reliability of document processing.

[0097] S202. The document is parsed to obtain multiple register information corresponding to multiple registers.

[0098] Register information may include register identifier, boundary information, and field row index.

[0099] Register identifiers are used to distinguish registers. A register identifier can be a register name (RegName) (e.g., cfg_mode, status_flag) and / or an offset address (Offset / Addr) (e.g., 0x00, 0x04). At least one of these must exist to ensure register uniqueness.

[0100] Boundary information is an identifier for the data range of a single register in the identification document, used to define the data boundaries of all fields corresponding to the register.

[0101] Boundary information may include a start line number and an end line number. The start line number is the index of the line where the register identifier first appears, and the end line number is the index of the line where the last valid field of the register is located.

[0102] For the field row of the last register in the design document, the field range is determined by obtaining the maximum number of lines in the document. That is, its ending line number is directly mapped to the maximum line index of the document, ensuring that all fields of the last register are fully included.

[0103] The field row index is a list of indexes of all valid field rows under this register in the identification document. It directly maps to the specific data rows in the identification document, making it easier to extract details such as field width and configuration value later.

[0104] In some embodiments, the identified document is processed by field extraction to obtain valid field line information; in the valid field line information, the start line number and end line number corresponding to each register are determined; for any register, register information is generated based on the valid field line information and the start line number and end line number corresponding to the register.

[0105] The valid field row information is information that identifies redundant rows in the document and includes multiple valid field rows.

[0106] In this application, multiple register information is obtained by using the valid field row information corresponding to each register. This enables precise binding between registers and fields, dynamic delineation of register data boundaries, automatic removal of invalid and redundant data, and avoids confusion between fields of different registers. Furthermore, it eliminates the need for manual location of register ranges, improving the efficiency and accuracy of register information extraction.

[0107] S203. Based on the design document, standardize the register information corresponding to each register to generate a standardized data structure.

[0108] Standardization processing transforms register information into a structured, standardized data format that can be directly used for code generation by using standardization rules, thereby eliminating inconsistencies caused by document differences.

[0109] In some embodiments, the standardization rules corresponding to the register information can be obtained; based on the standardization rules, design documents, and register information corresponding to each register, the sub-data structure corresponding to each register can be determined; and the sub-data structures corresponding to each register can be sorted and assembled to obtain the standardized data structure.

[0110] Standardization rules are preset by the rule engine and can cover a unified set of specifications for registers and fields across all dimensions. Standardization rules include field standardization rules and register standardization rules.

[0111] Field standardization rules are detailed rules for register fields, including bit width calculation rules, configuration value format standardization rules, field name standardization rules, and field constraint structure rules.

[0112] Register standardization rules are specifications for registers as a whole, including register name standardization rules, offset address format standardization rules, register total bit width derivation rules, and access attribute mapping rules.

[0113] Standardized field data is structured data that has been processed by field standardization rules, including standardized field names, field widths, standardized configuration values, standardized bit ranges, field function descriptions, and structured constraints.

[0114] Register normalized data is structured data that is processed by register normalization rules after register identifiers and boundary information are processed. It includes normalized register name, normalized offset address, total register bit width, normalized access attributes, register function description, original document location (for tracing), etc.

[0115] A sub-data structure is a complete normalized data unit of a single register, consisting of the normalized data of the register and the normalized data of all fields under that register. It is the basic building block of the normalized data structure.

[0116] The standardized data structure contains top-level structured data of all register-corresponding sub-data structures, which can be directly parsed by the code generation module.

[0117] In this application, by using standardized rules, data differences caused by different design document formats and different description methods can be eliminated, and a unified standard for register and field information can be achieved, avoiding code generation errors caused by chaotic data formats.

[0118] S204. Generate verification code that conforms to the verification environment specifications based on standardized data structures.

[0119] Verification environment specifications refer to the code syntax, structure format, interface protocol, and naming rules agreed upon by the verification platform or simulation tool, including but not limited to task / function definition specifications, signal type declaration specifications (such as bit / logic), register read / write interface format, debug printing format, and comment specifications.

[0120] The verification platform can be UVM, SystemVerilog Testbench, etc., and the simulation tool can be MentorQuesta, Synopsys VCS, etc.

[0121] The verification code is an executable code automatically generated according to the verification environment specifications based on a standardized data structure. It can include register configuration tasks, field bit width binding, configuration value assignment, platform adaptation logic, debugging printing, etc. It can be directly called by the verification environment to perform register configuration and functional verification.

[0122] For example, the verification code is in SystemVerilog, but scripts such as Python are also supported.

[0123] In some embodiments, task prefixes and signal declarations can be generated according to the verification environment specifications; the task prefixes, signal declarations, and standardized data structures are then filled into the placeholders corresponding to the code template to obtain the verification code.

[0124] In this application, the syntax, structure and interface of the code are standardized by verifying the environment, which ensures that the generated code can be directly integrated into the target verification environment without manual modification. The code generation and formatting are completed automatically, which greatly shortens the development cycle of verification code and improves the efficiency and reliability of code generation.

[0125] S205. Integrate the verification code into the target verification environment to complete the verification task of the chip under test.

[0126] When integrating the verification code into the target verification environment, the generated verification code can be stored according to the file directory structure of the verification environment (e.g., in the tb / reg_cfg / directory of the UVM environment), and the environment's compilation scripts (e.g., Makefile, CMake script) can be updated to add the file to the list of compilation files to ensure that it can be correctly recognized during compilation.

[0127] The verification code file format can be reg_cfg_task.sv.

[0128] Since the verification environment may have different framework types, we can obtain the target framework type corresponding to the target verification environment, adopt the integration logic corresponding to the target framework type, and integrate the verification code into the target verification environment to ensure that the code can be called normally without destroying the original environment structure.

[0129] The verification environment generation method provided in this application can identify the design document according to its document format, obtain an identified document, and parse the identified document to obtain multiple register information. Based on the design document, the register information corresponding to each register can be standardized to generate a standardized data structure, and then verification code conforming to the verification environment specification can be generated. The verification code can be integrated into the verification environment to complete the verification task of the chip under test. It can automatically execute the verification task of the chip under test without manual processing, thus improving the efficiency of chip verification. At the same time, it can reduce human error and improve the accuracy of chip verification.

[0130] Figure 3 This is a flowchart illustrating another method for generating a verification environment provided in an embodiment of this application. Please refer to... Figure 3 In this embodiment Figure 2 Based on the examples, the method for generating the verification environment is described in detail, and the method includes:

[0131] S301. Based on the document format of the design document corresponding to the chip under test, the design document is identified to obtain the identified document.

[0132] The execution process of S301 can be found in the execution process of S201, and will not be repeated here.

[0133] S302. Perform field extraction processing on the identified document to obtain valid field row information.

[0134] The document to be recognized can be a two-dimensional list in Excel or Word format, or a one-dimensional list in TXT format.

[0135] If the document is identified as a two-dimensional list, then each row of data is traversed, and rows with "RegName / Offset field not empty" or "Field / bit field not empty" are filtered out, and invalid rows with all core fields (RegName, Offset, Field, Bit) being empty are removed.

[0136] Invalid lines can be plain whitespace lines, comment lines without key fields, etc.

[0137] If the document is identified as a one-dimensional list, then regular expressions are used to match rows containing keywords such as "RegName:", "Offset:", "Field:", and "Bit:", which are considered valid field rows, and redundant rows without key information are removed.

[0138] S303. In the valid field row information, determine the start row number and end row number corresponding to each register.

[0139] Since there are a large number of registers to be configured, it is necessary to accurately associate each register (REG) with its corresponding field to avoid confusion and misuse of fields from different registers.

[0140] Specifically, the range of all rows describing the register is located by the register identifier (offset address or register name RegName column). For example, it can identify that rows 3 to 6 in the document correspond to the cfg_0 register, rows 7 to 9 correspond to the cfg_4 register, etc., where rows 3 and 7 are the first rows of the corresponding registers (i.e. the starting rows that need to be determined later), so as to achieve precise binding between registers and fields.

[0141] For any given register, the starting line of the register can be determined from the valid field lines of the document based on the starting line determination condition; and the ending line of the register can be determined from the valid field lines following the starting line based on the ending line determination condition.

[0142] When determining the starting line of a register, any of the following conditions can be met: the register name field (RegName) is not empty and its content conforms to the naming convention (a combination of letters, numbers, and underscores, without invalid special characters); the offset address field (Offset) is not empty (e.g., 0x00, decimal 8) and does not repeat the offset address of the previous line; the Field field is not empty, but the register name / offset field appears for the first time.

[0143] The original index of each starting line can be recorded as the line number and the corresponding register name. If there is an offset address, it should also be recorded as a unique identifier for that register to avoid confusion with other registers.

[0144] When determining the end line of a register, you can traverse backwards from the start line of that register. The register is considered the end line if any of the following conditions are met: a new valid start line appears (triggering a new register identifier, the previous line is the end line of the previous register); the content of the register name / offset address field changes (field expansion of different registers); traversal reaches the end of the identified document (no subsequent data, the current line is the end line of the last register); no valid field data for a preset number of consecutive lines (e.g., a configurable threshold of 3) (determined as a data interruption, the previous line is the end line).

[0145] It is worth noting that if the same register has multiple rows of fields (i.e., a single register corresponds to multiple rows of valid fields), the end row determination should skip rows where "only the Field / bit / Value fields have changed and the register identifier has not changed" to ensure that all associated fields are included in the scope of the register and to avoid field omissions.

[0146] In this application, by clearly defining the start line determination conditions and the end line determination conditions, the field data boundaries of a single register can be quickly and accurately defined, the association and binding of registers and fields can be automatically completed, redundant and invalid data can be eliminated, and the confusion between fields of different registers or the omission of key fields can be avoided; thereby improving the accuracy of register information extraction and the efficiency of automated processing.

[0147] S304. For any register, generate register information based on the valid field row information and the start and end row numbers corresponding to the register.

[0148] The register can be associated with the start and end line numbers to form the register's boundary information, which includes start_row (start line number, i.e., the original index of the valid start line) and end_row (end line number, i.e., the original index of the valid end line), which can clearly define the data range of the register in the document being identified.

[0149] From the valid field row information, filter out all valid field rows whose row numbers are between the start and end row numbers, organize the original indexes of these rows (which correspond one-to-one with the row numbers of the identified document) into an ordered list, and determine them as the field row indexes of the register.

[0150] The register identifier corresponding to the register, the boundary information generated above, and the field row index are associated and bound to form a complete register information structure.

[0151] S305, Obtain the standardized rules corresponding to register information.

[0152] The rules engine can load preset standardized rules and support users to extend custom rules according to the needs of the verification environment. At the same time, it automatically adapts the execution details of the rules by combining the original format of the design document (such as the bit range string parsing logic of TXT documents being consistent with Excel), ensuring the compatibility of rule execution.

[0153] S306. Based on the standardization rules, design documents, and register information corresponding to each register, determine the sub-data structure corresponding to each register.

[0154] Specifically, based on the field standardization rules and register information, field-standardized data is obtained; based on the register standardization rules and register information, register-standardized data is generated; and the register-standardized data and field-standardized data are concatenated to obtain a sub-data structure.

[0155] In this application, register identifiers, boundary information, and field details are standardized through unified standardization rules, thereby achieving structured and standardized integration of register and field information, which improves the consistency of data format and the reliability of code generation.

[0156] In some embodiments, register normalization data can be generated through the following steps:

[0157] Register name normalization: Remove invalid special characters such as spaces and commas from the original names and convert them to a uniform format of "lowercase letters and underscores". For example, "Cfg Mode" is normalized to "cfg_mode";

[0158] Offset address normalization: Convert the original offset address (decimal / hexadecimal with 0x prefix) to an uppercase hexadecimal string. For example, "8" is normalized to "08", and "0x10" is normalized to "10".

[0159] Determining the total bit width of the register: Prioritize using the RegWidth field directly provided in the design document; if not provided, deduce it based on the bit range of all fields under that register. And verify it against the sum of the field widths; if they are inconsistent, record a warning log.

[0160] Access attribute standardization: Descriptive text in documents (such as "readable and writable", "write-only", "write 1 clear 0") are uniformly mapped to standardized identifiers (such as "R / W", "W", "W1C"). When there is no explicit access attribute, it is marked as "R / W" by default.

[0161] Integrate the original traceability information: retain the start and end line numbers of the register in the original document for subsequent problem location; finally, integrate the above information to generate standardized register data.

[0162] In some embodiments, field-normalized data can be generated through the following steps:

[0163] Field name normalization: Same as register name normalization, for example, "IRQ_EN" is normalized to "irq_en", and "Mode-Sel" is normalized to "mode_sel";

[0164] Field bit range and bit width standardization: Parsing raw bit fields (i.e., Bit fields) strings with unified parsing logic supporting various common formats:

[0165] For the "high-low digit" format (such as "31-24" and "15-8"): directly extract the numbers before and after "-" using regular expressions, and use them as the high-digit and low-digit values ​​respectively;

[0166] For the format "[high byte:low byte]" (such as "[7:0]" "[3:1]"): use regular expressions to match the content separated by "[", "]" and ":", extract the numbers before and after ":", and use them as the high byte and low byte values ​​respectively;

[0167] After extracting the high-order and low-order values ​​through the above parsing logic, they are uniformly converted into the "high-order-low-order" format (for example, "[7:0]" is standardized to "7-0", and "15" is standardized to "15-15").

[0168] For other abnormal formats (such as "31_24" and "7.0"): mark as parsing failure, log the exception and mark the field as "invalid".

[0169] To determine the field width based on the low-order and high-order byte values, please refer to the following formula:

[0170]

[0171] For example, “31-24” is standardized to 8, “[7:0]” is standardized to 8, and “15” is standardized to 1. If parsing fails (e.g., due to an invalid string format), the field is marked as invalid.

[0172] Configuration value standardization: Supports conversion of raw values ​​in multiple formats—decimal (e.g., "255") is standardized to uppercase hexadecimal ("FF"), hexadecimal with 0x / 0X prefix (e.g., "0x0F" or "0XFF") is standardized to remove the prefix and uppercase ("0F" or "FF"), and binary (e.g., "0b1111") is standardized to first convert to decimal and then to hexadecimal ("0F"); null values ​​are filled with default values ​​(e.g., "00") according to document conventions and marked "default filling";

[0173] Field constraint structuring: Converts constraints described in natural language in the original document into standardized constraint expressions, and marks the absence of constraints as "no special constraints";

[0174] Integrate field descriptions with original locations: retain field function descriptions, record the line number of the field in the original document, and generate standardized field data; if the field width calculation fails or the configuration value is invalid, mark the field as "invalid" and exclude it from subsequent code generation.

[0175] S307. Sort and assemble the sub-data structures corresponding to each register to obtain a standardized data structure.

[0176] It can sort all the sub-data structures of the registers in ascending order of register offset address and assemble them into a final standardized data structure. It supports output in formats such as JSON and Python dictionaries, which are convenient for subsequent code generation modules to parse directly.

[0177] S308. Generate task prefixes and signal declarations according to the verification environment specifications.

[0178] The task prefix refers to the task naming prefix and definition format that conforms to the verification environment specifications. It includes the task keyword, scenario name, parameter list (optional), and end marker (endtask). It is used to encapsulate the configuration logic of a set of related registers to ensure that the task can be directly called by the verification environment.

[0179] Signal declarations refer to general-purpose signals (such as address and data storage signals) declared within a task or globally for register configuration. The signal type and bit width must conform to the syntax specifications of the verification environment (such as bit / logic type) and support multi-simulation platform adaptation to avoid signal definition conflicts or syntax errors.

[0180] The verification environment specification defines the code syntax, naming rules, interface protocols, and signal type requirements agreed upon by the verification platform, including but not limited to task definition format, signal declaration specifications, and register read / write interface parameter format. It is the core basis for generating integrable code.

[0181] Based on the configuration requirements in the design document, scenario keywords can be extracted, and a fixed prefix can be added before the scenario keywords according to the verification environment specifications to obtain scenario-based names (i.e., task names).

[0182] If the verification environment requires the task to support dynamic configuration (such as switching configuration modes), generate a parameter list according to the specification, such as input bit [1:0] mode (mode selection parameter). The parameter type and bit width must match the environment interface requirements.

[0183] Combine the task keyword, scenario name, and parameter list (optional) to generate a complete task prefix.

[0184] Signal declarations can follow a unified declaration and global reuse approach, avoiding repeated declarations in individual register configurations. The specific generation rules are as follows:

[0185] (1) Signal type selection rules: Prioritize following the default signal type specifications of the target verification environment; if the environment explicitly requires a pure simulation type, the bit type (without X / Z state, suitable for high-speed simulation) can be selected; for multi-simulation platform adaptation scenarios, the type differences are encapsulated through conditional compilation macros (ifdef UVM_ENV logic else bit `endif) to ensure cross-platform compatibility.

[0186] (2) Signal bit width adaptation rules: The bit width must strictly match the total bit width of the register or the requirements of the environment interface, specifically divided into three scenarios:

[0187] Address storage signal: The bit width is adapted to the address bus width of the target verification environment (e.g., [31:0] for a 32-bit address space). If the environment is not explicitly specified, it is deduced by the maximum offset address of the register by default (bit width = ceil (log2 (maximum offset address + 4)) to ensure coverage of all register address ranges).

[0188] Data storage signal: The bit width is consistent with the total bit width of the register (e.g., if the total bit width of the register is 32 bits, it is declared as [31:0]). If there are registers with different bit widths, the maximum total bit width of the register is declared (the data of a single register is accurately assigned through the field-level bit width mask to avoid data truncation caused by bit width mismatch).

[0189] Status identifier signals (such as configuration completion flag, read / write enable): The default value is 1 bit ([0:0]). If the environment requires multiple status identifiers, it can be extended to multiple bits according to the scenario requirements (such as [1:0] supporting 4 states).

[0190] (3) Example of core signal declaration: Declare the necessary general signals for register configuration according to the above rules, including but not limited to:

[0191] Address storage signal: logic [31:0] reg_addr; / / Stores the register offset address, adapting to the 32-bit address space;

[0192] Data storage signal: logic [31:0] reg_wdata; / / Write data to the storage register, adapting to the total width of the 32-bit register;

[0193] Status indicator signal: logic reg_cfg_done; / / Register configuration complete flag, 1-bit status indicator.

[0194] (4) Commenting standard: Automatically add signal function comments, clearly indicating the purpose of the signal and the basis for bit width adaptation (such as "adapt to 32-bit address space" and "match the maximum total bit width of the register"), to ensure code readability and maintainability.

[0195] S309. Fill the placeholders in the code template with the task prefix, signal declaration, and standardized data structure to obtain the verification code.

[0196] It can load code templates corresponding to the target verification environment and match the pre-set placeholders such as task frameworks, signal declarations, and register configurations in the template.

[0197] Fill the corresponding placeholders with the task prefix and signal declaration to build the basic code structure.

[0198] Traverse the standardized data structure, extract the address, name, bit range, configuration value, description and other information of each register, and fill them into register-level and field-level placeholders according to the template rules to generate single register configuration logic.

[0199] Finally, all single register configuration logics are batch-assembled according to register order, and endtask is added to complete the syntax loop. After formatting, the complete verification code is obtained.

[0200] S310. Integrate the verification code into the target verification environment to complete the verification task of the chip under test.

[0201] The execution process of S310 can be found in the execution process of S205, and will not be repeated here.

[0202] The verification environment generation method provided in this application embodiment can achieve full-link automation of the verification process through refined field extraction, precise definition of register data boundaries, standardized data format, automated code generation and environment integration, etc., which can significantly reduce the cost of manual intervention, improve the generation efficiency and compatibility of verification code, and at the same time ensure the reliability of verification tasks and the localization of problems through data traceability and anomaly marking mechanisms.

[0203] Figure 4 This is a schematic diagram illustrating the architecture of a method for generating a verification environment provided in an embodiment of this application. Please refer to [link / reference]. Figure 4The process begins by inputting the design document, followed by an input recognition stage. This stage uses different recognition methods depending on the document format (e.g., Excel, Word, TXT). For example, it might use the openpyxl library to parse Excel, the python-docx library to parse Word, or regular expressions or line-by-line reading to parse TXT. After recognizing the design document, extracting fields, and parsing register information, the process moves to the Python environment code generation stage. This stage combines environment code matching requirements to transform the parsed standardized data structure into verification code that conforms to the verification environment specifications. Finally, it outputs generated files (e.g., verification code files like reg_cfg_task.sv), thus automating the generation of the verification environment.

[0204] Figure 5 This is a schematic diagram of a verification environment generation apparatus provided in an embodiment of this application. Please refer to... Figure 5 The verification environment generation device 500 includes an identification processing module 501, a parsing processing module 502, a standardization processing module 503, a generation module 504, and an integration module 505.

[0205] The identification processing module 501 is used to identify the design document according to the document format of the design document corresponding to the chip under test, and obtain the identification document.

[0206] The parsing and processing module 502 is used to parse and process the recognized document to obtain multiple register information corresponding to multiple registers. The register information includes register identifiers, boundary information, and field row indexes.

[0207] The standardization processing module 503 is used to standardize the register information corresponding to each register based on the design document, and generate a standardized data structure. The standardized data structure includes multiple sub-data structures corresponding to multiple registers.

[0208] The generation module 504 is used to generate verification code that conforms to the verification environment specifications based on a standardized data structure.

[0209] The integration module 505 is used to integrate verification code into the target verification environment to complete the verification task of the chip under test.

[0210] In one possible implementation, the standardization processing module 503 is specifically used for:

[0211] Obtain the standardization rules corresponding to register information. The standardization rules include field standardization rules and register standardization rules.

[0212] Based on standardization rules, design documents, and register information corresponding to each register, determine the sub-data structure corresponding to each register;

[0213] The sub-data structures corresponding to each register are sorted and assembled to obtain a standardized data structure.

[0214] In one possible implementation, for any given register, the normalization processing module 503 is specifically used for:

[0215] Based on the field standardization rules and register information, the field-standardized data is obtained;

[0216] Register standardization data is generated based on register standardization rules and register information;

[0217] The register-normalized data and field-normalized data are concatenated to obtain a sub-data structure.

[0218] In one possible implementation, the field normalization data includes the field bit width; the register information includes bit fields; and the normalization processing module 503 is specifically used for:

[0219] The bit field is parsed to obtain the low-order and high-order values;

[0220] The field width is determined based on the low-order and high-order digits.

[0221] In one possible implementation, the generation module 504 is specifically used for:

[0222] Generate task prefixes and signal declarations according to the verification environment specifications;

[0223] Fill the placeholders in the code template with the task prefix, signal declaration, and standardized data structure to obtain the verification code.

[0224] In one possible implementation, the parsing processing module 502 is specifically used for:

[0225] The recognized document is processed to extract fields, and valid field row information is obtained.

[0226] In the valid field row information, determine the start and end row numbers corresponding to each register;

[0227] For any register, register information is generated based on the valid field row information and the start and end row numbers corresponding to the register.

[0228] In one possible implementation, for any given register, the parsing processing module 502 is specifically used for:

[0229] Based on the starting line determination criteria, the starting line of the register is determined among the valid field lines of the recognized document;

[0230] Based on the end-line determination condition, the end line of the register is determined in the valid field lines following the start line.

[0231] The verification environment generation device provided in this embodiment can execute the method provided in the above method embodiment. Its implementation principle and technical effect are similar, and will not be described in detail here.

[0232] Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Please refer to... Figure 6 The electronic device 600 may include a processor 601 and a memory 602. Exemplarily, the processor 601 and the memory 602 are interconnected via a bus 603.

[0233] Memory 602 stores computer-executed instructions;

[0234] The processor 601 executes computer execution instructions stored in the memory 602, causing the processor 601 to execute the verification environment generation method as shown in the above embodiment.

[0235] Electronic devices can include chips, modules, integrated development environments (IDEs), etc.

[0236] Accordingly, this application provides a chip that includes at least one processor, which executes computer execution instructions to implement the verification environment generation method of the above method embodiments.

[0237] Accordingly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the verification environment generation method of the above-described method embodiments.

[0238] Accordingly, embodiments of this application may also provide a computer program product, including a computer program, which, when executed by a processor, can implement the method for generating the verification environment shown in the above method embodiments.

[0239] The computer-readable storage medium and computer program product of the present application embodiments can execute the methods provided in the above embodiments. The specific implementation process and beneficial effects are described above and will not be repeated here.

[0240] All or part of the steps in the above embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a readable memory. When the program is executed, it performs the steps included in the above embodiments; and the aforementioned memory (storage medium) includes: read-only memory (ROM), random access memory (RAM), flash memory, hard disk, solid-state drive, magnetic tape, floppy disk, optical disk, and any combination thereof.

[0241] This application describes embodiments with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processing unit of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processing unit of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0242] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0243] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0244] 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 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 generating a verification environment, characterized in that, include: According to the document format of the design document corresponding to the chip under test, the design document is identified to obtain the identified document; The identified document is parsed to obtain multiple register information corresponding to multiple registers. The register information includes register identifier, boundary information and field row index. Based on the design document, the register information corresponding to each register is standardized to generate a standardized data structure, which includes multiple sub-data structures corresponding to the multiple registers. Based on the standardized data structure, verification code conforming to the verification environment specifications is generated; The verification code is integrated into the target verification environment to complete the verification task of the chip under test.

2. The method according to claim 1, characterized in that, Based on the design document, the register information corresponding to each register is standardized to generate a standardized data structure, including: Obtain the standardization rules corresponding to the register information. The standardization rules include field standardization rules and register standardization rules. Based on the standardization rules, the design document, and the register information corresponding to each register, determine the sub-data structure corresponding to each register; The sub-data structures corresponding to each register are sorted and assembled to obtain the standardized data structure.

3. The method according to claim 2, characterized in that, For any given register; based on the standardization rules, the design document, and the register information corresponding to the register, determine the sub-data structure, including: Based on the field standardization rules and the register information, the field standardization data is obtained; Register standardization data is generated based on the aforementioned register standardization rules and register information; The normalized register data and the normalized field data are concatenated to obtain the sub-data structure.

4. The method according to claim 3, characterized in that, The standardized field data includes the field bit width; the register information includes bit fields; determining the field bit width according to the standardized field rules and the bit fields includes: The bit field is parsed to obtain the low-order bit value and the high-order bit value; The field width is determined based on the low-order byte value and the high-order byte value.

5. The method according to claim 1, characterized in that, Based on the standardized data structure, verification code conforming to the verification environment specifications is generated, including: Based on the verification environment specifications, generate task prefixes and signal declarations; The verification code is obtained by filling the placeholders in the code template with the task prefix, the signal declaration, and the standardized data structure.

6. The method according to claim 1, characterized in that, The identified document is parsed to obtain multiple register information corresponding to multiple registers, including: The identified document is processed to extract fields, resulting in valid field row information; In the valid field row information, determine the start row number and end row number corresponding to each register; For any register, the register information is generated based on the valid field row information and the start and end row numbers corresponding to the register.

7. The method according to claim 6, characterized in that, For any given register; in the valid field row information, determine the start row number and end row number corresponding to the register, including: Based on the starting line determination criteria, the starting line of the register is determined in the valid field lines of the identified document; Based on the end-line determination condition, the end line of the register is determined in the valid field line following the start line.

8. An apparatus for generating a verification environment, characterized in that, It includes an identification processing module, a parsing processing module, a standardization processing module, a generation module, and an integration module: The identification processing module is used to identify the design document according to the document format of the design document corresponding to the chip under test, and obtain the identification document. The parsing processing module is used to parse the identified document to obtain multiple register information corresponding to multiple registers. The register information includes register identifiers, boundary information, and field row indexes. The standardization processing module is used to standardize the register information corresponding to each register based on the design document, and generate a standardized data structure, wherein the standardized data structure includes multiple sub-data structures corresponding to the multiple registers. The generation module is used to generate verification code that conforms to the verification environment specifications based on the standardized data structure. The integration module is used to integrate the verification code into the target verification environment to complete the verification task of the chip under test.

9. A chip, characterized in that, The chip includes at least one processor, the processor being configured to execute computer execution instructions to perform the method according to any one of claims 1 to 7.

10. An electronic device, characterized in that, include: Processor, memory; The memory stores computer programs; The processor invokes the computer program stored in the memory, causing the electronic device to perform the method according to any one of claims 1 to 7.

Images