Register design verification file generation method

Abstract

The invention relates to a register design verification file generation method, which comprises the following steps of: performing deep analysis and detailed processing by acquiring structured register description information and applying a built-in LR (Local Register) syntactic analyzer with context-dependent dynamic analysis capability; according to the method, accurate and consistent RTL design codes, RAL verification models and register description documents can be automatically and synchronously generated, the automation level and quality of register related work are effectively improved, the chip design verification period is shortened, the risk that errors are introduced due to information inconsistency is reduced, and human input is saved.

Description

Technical Field

[0001] The present application relates to the technical field of digital chip design, and in particular to a method for generating a register design verification file. Background Art

[0002] Registers, as core hardware units in digital integrated circuits like central processing units (CPUs) and systems-on-chips (SoCs), carry the critical responsibility of storing status information, configuring parameters, and controlling various chip functions. As modern digital chip designs continue to expand in scale and increase in functional complexity, the number of integrated registers has grown exponentially, with a medium-to-large chip often containing thousands or even tens of thousands of registers. Therefore, ensuring the correct design of these registers, achieving efficient verification, and generating clear and accurate specification documents have become cornerstones of successful chip development and on-time delivery.

[0003] However, in the traditional chip development process, design engineers must manually write register hardware description language (RTL) code based on specifications to accurately implement the register's storage logic, read / write control mechanisms, and interaction logic with standard bus interfaces (such as AMBA's AHB or APB protocols). Verification engineers, meanwhile, must create corresponding register abstraction layer (RAL) models to perform comprehensive functional simulation and behavioral testing of these registers within complex verification platforms (such as those based on UVM). Furthermore, to support subsequent software development, system integration, and end-user use, detailed technical documentation, including register functional descriptions, address mapping tables, and access protocols, must be written and maintained. This series of fragmented and manual tasks is not only time-consuming and labor-intensive, but also easily leads to inconsistencies between the RTL code, verification models, and documentation during design iterations and requirement changes, potentially leading to functional defects or verification omissions.

[0004] To address these challenges, a common improvement approach is to automate the process using simple scripting tools (such as Perl or Python-based scripts). These scripts typically read a register list in a predefined format and generate partial RTL code or verification model fragments based on text processing, regular expression matching, or a simple template replacement mechanism. While these scripts alleviate repetitive work to a certain extent, they often struggle with complex register organization structures, multi-level nesting, flexible attribute inheritance and overwriting mechanisms, complex address expressions involving dynamic calculations, conditional compilation instructions, and sophisticated error detection and recovery requirements. When design requirements change frequently, the maintenance and expansion costs of these scripts may increase rather than decrease, and their versatility is also greatly limited, making them often only suitable for specific projects or relatively simple application scenarios.

[0005] Another approach is to use register management solutions provided by large commercial electronic design automation (EDA) tool suites. While these tools are generally comprehensive, their introduction and deployment typically requires experienced engineers to invest significant time in tool evaluation, learning, configuration, and process integration to initially generate outputs that meet project requirements. Furthermore, ongoing maintenance and new staff training are required throughout project iterations to expand the tools and processes to other projects, resulting in significant initial investment. Summary of the Invention

[0006] In order to solve the above problems, the present application provides a register design verification file generation method that saves labor costs, consistently generates RTL, RAL and documents, and improves chip design verification efficiency and quality.

[0007] In order to achieve the above-mentioned purpose, the register design verification file generation method designed by the present application includes the following steps: S100. Obtain register description information, the register description information including module information and register definition information; wherein the module information includes module name, project name, base address, address decoding width, clock signal, reset signal and parameter configuration; the register definition information includes offset address, register name, bit width, bit segment range, bit segment name, read / write attributes, reset value and function description; S200. Construct an RDL model that complies with the SystemRDL standard based on the acquired register description information; S300 parses the RDL model using a preconfigured LR parser, wherein the LR parser adopts a bottom-up analysis approach and can dynamically adjust the application of grammar rules according to the current parsing scope; S400. Based on the result of the analysis process, simultaneously generate RTL design code, RAL verification model and register description document.

[0008] Preferably, the register description information in step S100 is provided in the form of an Excel spreadsheet file in a predetermined format.

[0009] Preferably, the LR parser in step S300 is further used to: When a syntax error is encountered during parsing, an error node is generated and the subsequent register description information is parsed; All detected syntax errors are collected and an error report is generated, wherein the error report includes error location information and error type information.

[0010] Preferably, the LR parser in step S300 pre-creates a symbol table during the parsing process to record component types and attribute names.

[0011] Preferably, the parsing process in step S300 includes: S310. Calculate the absolute address of each register: S311. Traverse all register components and collect static attribute information including alignment requirements, stride and bit width; S312. Calculate the absolute address of each register based on the hierarchy and array index, combined with the base address and offset address; S313. Use a lazy evaluation strategy to delay the evaluation of expressions that depend on parameters until all dependencies are resolved; S320. Processing register and bit segment attributes inheritance and overwriting: S321. Build a hierarchical symbol table to record the default values ​​of attributes of each scope; S322. Search up the scope chain level by level for undefined properties; S323. Processing attribute inheritance according to preset priority rules, the priority rules are: instance attributes have higher priority than parent default attributes, and parent default attributes have higher priority than global default attributes; S330. Detect bit field conflicts within registers: S331. For each register, check whether the bit ranges of the segments it contains overlap; S332. Verify whether the total bit width of all bit segments exceeds the bit width limit of the corresponding register; S340. Handling instantiation dependencies across components: S341. Parse all register description information and build a global symbol table that records all component definitions; S342. Use graph traversal algorithm to topologically sort the dependency relationships of component instantiations.

[0012] Preferably, the parameter configuration in step S100 includes UVM output parameters, and the UVM output parameters include at least one of a coverage enable parameter and a base address coverage parameter, which are used to customize the behavioral characteristics of the RAL verification model generated in step S300.

[0013] Preferably, the RTL design code generated in step S400 includes the following modules: Top-level encapsulation module: named after the module name, providing a unified external interface; Bus interface module: including AHB interface module and APB interface module, used to convert AMBA bus protocol into register read and write operations; Register control logic module: including an address decoder and register logic instance generated based on the offset address; Register implementation module: register hardware implementation generated based on RDL specifications.

[0014] Preferably, the RAL verification model generated in step S400 includes: Register bit segment class: inherited from the uvm_reg_field class, generated according to the bit segment range and bit segment name, corresponding to each functional bit segment in the hardware; Register class: inherited from the uvm_reg class, generated according to the register name, corresponding to each register in the hardware; Address mapping class: inherited from the uvm_reg_map class, calculates the absolute address of each register according to the base address and offset address; Register block class: inherited from the uvm_reg_block class, as the top-level container containing all registers and address mapping objects.

[0015] Preferably, the register description document generated in step S400 includes: A register address mapping table generated based on the base address and the offset address; Functional descriptions of each register and bit segment generated based on the functional description; A register access characteristic description is generated based on the read / write attributes and reset value.

[0016] The register design verification file generation method designed in this application obtains structured register description information and uses a built-in LR syntax analyzer with context-sensitive dynamic parsing capabilities for in-depth parsing and detailed processing. It can automatically and synchronously generate accurate and consistent RTL design code, RAL verification model and register description documents, effectively improving the automation level and quality of register-related work, shortening the chip design verification cycle, reducing the risk of errors introduced due to inconsistent information, and saving manpower investment. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] Figure 1 This is a flow chart of the register design verification file generation method provided in an embodiment of the present application.

[0018] Figure 2 This is a schematic diagram of the memory description information provided in an embodiment of the present application.

[0019] Figure 3 It is a module block diagram of the RTL design code provided in the embodiment of this application.

[0020] Figure 4 This is a structural block diagram of the RAL verification model provided in an embodiment of the present application.

[0021] Figure 5This is a schematic diagram of a register description document provided in an embodiment of the present application. DETAILED DESCRIPTION

[0022] The preferred embodiments of the present application are described below in conjunction with the accompanying drawings. It should be understood that the preferred embodiments described herein are only used to illustrate and explain the present application and are not used to limit the present application.

[0023] like Figure 1 As shown, the register design verification file generation method described in this embodiment is intended to solve the problems of low efficiency and document inconsistency in the digital chip design and verification process, and effectively improve the efficiency and accuracy of design and verification. In one possible embodiment, the method is implemented by a computer program, which runs on a computing device equipped with a processor and memory, and when executed by the processor, the steps of the method are implemented. The specific implementation process of the method includes the following steps: S100. Obtain register description information. The system obtains register description information containing complete register definitions. This information serves as the data source for the entire process and provides basic data support for subsequent model construction and code generation.

[0024] Specifically, the register description information includes module information and register definition information. The module information includes the module name, project name, base address, address decoding width, clock signal, reset signal, and parameter configuration, including bus type configuration (AHB / APB). The register definition information includes the offset address, register name, bit width, bit segment range, bit segment name, read / write attributes, reset value, and function description. Read / write attributes include RW (read-and-write), RO (read-only), WC (write-1-clears-0), and WO (write-only) to meet different hardware design requirements.

[0025] In some embodiments, the memory description information is provided in a spreadsheet file in a predetermined format, such as Figure 2 The Excel spreadsheet file format shown is shown. This method greatly simplifies the operator input process. Operators do not need to learn complex professional tools or specific descriptive language syntax; they only need to master basic spreadsheet skills to complete register information entry. Specifically, functions such as copying, pasting, and formula calculations can quickly complete the definition of large numbers of registers. Specifically, when parsing the spreadsheet, the system accurately extracts the complete definition information for each register by identifying the table's specific column headers (such as "Register Name," "Offset Address," "Bit Width," etc.) and row structure. It also reads the data content row by row, performing format verification and logic checks. If any data errors or omissions are found, error messages are generated to guide the operator in making corrections.

[0026] S200. Based on the acquired register description information, an RDL model that complies with the SystemRDL (System Register Description Language) standard is constructed. Through this standardized conversion process, the original tabular data is converted into an RDL model with a strict grammatical structure, providing a unified data foundation for subsequent automated processing.

[0027] S300. Parse the RDL model using a preconfigured LR parser.

[0028] The LR parser employs a bottom-up analysis approach. For example, the parser reads the character stream from the RDL model file and decomposes the character sequence into meaningful tokens, such as keywords (addrmap, reg, field, etc.), identifiers, numeric constants, and operators, according to the lexical rules of SystemRDL. Starting from the bottom layer of the token stream, it gradually reduces it according to the grammatical rules of SystemRDL to construct a complete parse tree. Furthermore, the LR parser can dynamically adjust the application of grammatical rules based on the current parsing scope. For example, after processing the "module name," the parser knows that subsequent "base address" and "address decoding width" attributes should follow the grammatical rules for module-level attributes. However, when entering a specific "register name" definition, it switches to applying register-level grammatical rules for "bit width," "offset address," and "bit segment definition." This context-sensitive dynamic rule adjustment capability enables the method to accurately process register descriptions with hierarchical structures and complex dependencies.

[0029] In some embodiments, the LR parser in step S300 is further configured to: generate an error node and continue parsing subsequent register description information when a syntax error is encountered during the parsing process; and generate an error report after collecting all detected syntax errors, wherein the error report includes error location information and error type information. For example, when a spelling error such as "Enable_Ctrl" is found instead of the expected "Enable_Control", the LR parser will immediately mark an error node internally, but will not interrupt the entire parsing process. Instead, it will attempt to continue parsing subsequent register definitions to avoid interrupting the entire process due to a single error. After the complete parsing process is completed, a summary error report in a TXT or HTML file is output at one time, which lists in detail the location (e.g., sheet name, row number, column number of an Excel spreadsheet) and error type (e.g., unknown bit segment name, incomplete syntax) of all detected syntax errors, greatly helping operators quickly locate and correct all problems.

[0030] Furthermore, to improve the efficiency of subsequent processing and support more complex semantic analysis, the LR parser in step S300 pre-establishes a symbol table during the parsing process to record component types and attribute names. For example, when the parser recognizes the beginning of a new register definition, it registers the register name in the symbol table. When parsing a bit segment definition within the register, it also stores the bit segment name, the register to which it belongs, and any resolved static attributes in the symbol table. This provides a basic data structure for subsequent semantic checking and attribute inheritance. This reduces repeated scanning of the input during the subsequent semantic elaboration phase or when other parts need to be referenced, thereby speeding up the entire processing flow.

[0031] S400. Based on the results of the parsing process, RTL design code, RAL verification model, and register description document are simultaneously generated. Specifically, based on the parsed and detailed register definitions, RTL code is automatically generated that complies with standard hardware description languages ​​(such as Verilog HDL). This code can be directly used for subsequent logic synthesis and chip physical implementation. Similarly, based on the processed register information, RAL model code (such as SystemVerilog classes) is automatically generated that complies with mainstream verification methodologies such as UVM. These models provide verification engineers with a high-level register access interface for functional verification of the RTL design in a simulation environment. The register description document automatically formats all parsed register attributes, function descriptions, address mappings, and other information into a clearly structured document, such as a Word document or HTML document.

[0032] In practical applications, the aforementioned register design verification file generation method is usually implemented in the form of a computer program product. The computer program contains a series of instructions, which are designed to be able to fully implement the entire operation process described in the aforementioned steps S100 to S300 when executed on a processor in a computer system. This means that in the complex chip design iteration process, after the operator changes the register description information provided by the Excel spreadsheet, it is only necessary to re-execute the complete processing flow through the computer program to ensure that the three types of key output files, namely the newly generated RTL design code, RAL verification model and register description document, are fully and real-time synchronized updates. This synchronous update mechanism fundamentally guarantees a high degree of consistency in information between hardware design (RTL), verification model (RAL) and technical documents, and effectively eliminates the risk of inconsistency caused by multi-point maintenance, information transmission lag or human negligence in traditional manual or semi-automatic processes.

[0033] In some embodiments, the parameter configuration in step S100 includes UVM output parameters, and the UVM output parameters include at least one of a coverage enable parameter and a base address coverage parameter, which are used to customize the behavioral characteristics of the RAL verification model generated in step S300.

[0034] Specifically, the operator can set UVM output parameters in the module information provided in step S100 through a specific parameter configuration file or in the parameter configuration area of ​​an Excel spreadsheet. For example, if include_address_coverage=true and base_address_override=0x80000000, when generating the RAL verification model in step S300, if include_address_coverage is true, the generated RAL model will automatically include UVM coverage groups and coverage point codes for each register address for collecting address access coverage during simulation; at the same time, the address mapping in the generated RAL model will use 0x80000000 as its base address, rather than other base addresses that may be defined in the original module information, which allows the verification environment to flexibly relocate the address space of the register block.

[0035] In some embodiments, the parsing process in step S300 includes: S310. Calculate the absolute address of each register. This step ensures that each register has a unique and correct address in the final hardware and verification model.

[0036] S311. Traverse all register components and collect static attribute information including alignment requirements, stride and bit width.

[0037] S312. Calculate the absolute address of each register based on the hierarchical structure and array index, combined with the base address and the offset address.

[0038] S313. Use a lazy evaluation strategy to delay the evaluation of parameter-dependent expressions (such as addr_offset = BaseAddr + 0x100) until all dependencies are resolved. For example, the offset address of a register might be defined as previous_reg_offset + previous_reg_size + gap. Its evaluation is then delayed until all dependencies, previous_reg_offset and previous_reg_size, have been determined and resolved. This helps handle complex address dependencies.

[0039] S320. Process the inheritance and overwriting of registers and their bit segment attributes.

[0040] S321. Build a hierarchical symbol table to record the default values ​​of attributes for each scope.

[0041] S322. Searching up the scope chain for undefined attributes. When parsing a specific bit segment or register, if an attribute (such as read or write permissions) is not explicitly defined at that level, the system searches up the scope chain until it finds a parent scope that defines the attribute and inherits its value.

[0042] S323. Process attribute inheritance according to the preset priority rule, which is: instance attributes have higher priority than parent default attributes, and parent default attributes have higher priority than global default attributes. This ensures the accuracy of the definition.

[0043] S330. Detect bit field conflicts in the bit segments within the register.

[0044] S331. For each register, check whether the bit ranges of the bit segments it contains overlap.

[0045] S332. Verify whether the total bit width of all bit segments exceeds the bit width limit of the corresponding register. Ensure that the bit ranges of the fields do not overlap and meet the register bit width limit.

[0046] S340. Handle instantiation dependencies across components.

[0047] S341. Parse all register description information and build a global symbol table that records all component definitions. This global symbol table enables the original definition of a component to be found when instantiating it.

[0048] S342. Use a graph traversal algorithm to topologically sort the dependencies of component instantiations. Ensure that dependencies are resolved first to avoid errors caused by unresolved dependencies.

[0049] In some embodiments, as Figure 3 As shown, the RTL design code generated in step S400 includes the following modules: Top-level encapsulation module (${module_name}_rf_wrap.v): named after the module name, providing a unified external interface; Bus interface module (Ahb2reg_intf / Apb2reg_intf.v): includes AHB interface module and APB interface module, used to convert AMBA bus protocol into register read and write operations; Register control logic module (${module_name}_rf.v): contains the address decoder and register logic instance generated based on the offset address; Register implementation module (${module_name}_rf_logic.v): Generates register hardware implementation based on the RDL specification. This structured RTL code generation approach not only ensures accurate correspondence with the definition but also improves code readability, maintainability, and reusability.

[0050] In some embodiments, as Figure 4 As shown, the RAL verification model generated in step S400 includes: Register bit segment class: inherited from the uvm_reg_field class, generated according to the bit segment range and bit segment name, corresponding to each functional bit segment in the hardware; Register class: inherited from the uvm_reg class, generated according to the register name, corresponding to each register in the hardware; Address mapping class: inherited from the uvm_reg_map class, calculates the absolute address of each register according to the base address and offset address; Register block class: inherited from the uvm_reg_block class, as the top-level container containing all registers and address mapping objects.

[0051] That is, according to the register information described in the Excel table, a series of classes are generated for each register, which are inherited from the UVM library's class uvm_reg_field / class uvm_reg / class uvm_reg_map / class uvm_mem / class uvm_reg_block, etc., so that the registers defined in the table can be uniformly accessed using the interface provided by UVM. Verification engineers can directly use the API provided by UVM to perform efficient and high-level abstraction tests on these registers.

[0052] In some embodiments, as Figure 5 As shown, the register description document generated in step S400 includes a register address mapping table generated based on the base address and offset address, a functional description of each register and bit segment generated based on the functional description, and a register access characteristic description generated based on the read / write attributes and reset value. The automatically generated document ensures information synchronization with the RTL design and RAL model, avoiding errors and delays that may be introduced by manually writing documents.

[0053] The register design verification file generation method provided in the embodiment of the present application obtains structured register description information and uses a built-in LR syntax analyzer with context-sensitive dynamic parsing capabilities for in-depth parsing and detailed processing. It can automatically and synchronously generate accurate and consistent RTL design code, RAL verification model and register description documents, effectively improving the automation level and quality of register-related work, shortening the chip design verification cycle, reducing the risk of errors introduced due to inconsistent information, and saving manpower investment.

[0054] In the description of this application, it should be noted that the terms "vertical", "up", "down", "horizontal", etc. indicate orientations or positional relationships based on the orientations or positional relationships shown in the accompanying drawings. They are only for the convenience of describing this application and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation. Therefore, they cannot be understood as limitations on this application.

[0055] It should also be noted that, in the description of this application, unless otherwise expressly specified or limited, the terms "disposed," "installed," "connected," and "connected" should be understood in a broad sense. For example, they can refer to fixed connections, detachable connections, or integral connections; they can refer to mechanical connections or electrical connections; they can refer to direct connections or indirect connections through an intermediate medium; and they can refer to internal connections between two components. Those skilled in the art will understand the specific meanings of the above terms in this application based on specific circumstances.

[0056] Finally, it should be noted that the above description is merely a preferred embodiment of the present application and is not intended to limit the present application. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art may still modify the technical solutions described in the aforementioned embodiments or substitute equivalents for some of the technical features therein. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present application shall be included within the scope of protection of the present application.

Claims

1. A register design verification file generation method, characterized in that: The following steps are involved: S100. Obtain register description information, the register description information including module information and register definition information; wherein the module information includes module name, project name, base address, address decoding width, clock signal, reset signal and parameter configuration; the register definition information includes offset address, register name, bit width, bit segment range, bit segment name, read / write attributes, reset value and function description; S200. Construct an RDL model that complies with the SystemRDL standard based on the acquired register description information; S300. Parsing the RDL model through a pre-configured LR parser to obtain structured data of registers; wherein the LR parser adopts a bottom-up analysis method and can dynamically adjust the application of grammar rules according to the current parsing scope; S400. Based on the result of the analysis process, simultaneously generate RTL design code, RAL verification model and register description document.

2. The register design verification file generation method according to claim 1, characterized in that: The register description information in step S100 is provided in the form of an Excel spreadsheet file in a predetermined format.

3. The register design verification file generation method according to claim 1, characterized in that: The LR parser in step S300 is further used to: When a syntax error is encountered during parsing, an error node is generated and the subsequent register description information is parsed; All detected syntax errors are collected and an error report is generated, wherein the error report includes error location information and error type information.

4. The register design verification file generation method according to claim 1, characterized in that: The LR parser in step S300 pre-creates a symbol table during the parsing process to record component types and attribute names.

5. The register design verification file generation method according to claim 1, characterized in that: The analysis process in step S300 includes: S310. Calculate the absolute address of each register: S311. Traverse all register components and collect static attribute information including alignment requirements, stride and bit width; S312. Calculate the absolute address of each register based on the hierarchy and array index, combined with the base address and offset address; S313. Use a lazy evaluation strategy to delay the evaluation of expressions that depend on parameters until all dependencies are resolved; S320. Processing register and bit segment attributes inheritance and overwriting: S321. Build a hierarchical symbol table to record the default values ​​of attributes of each scope; S322. Search up the scope chain level by level for undefined properties; S323. Processing attribute inheritance according to preset priority rules, the priority rules are: instance attributes have higher priority than parent default attributes, and parent default attributes have higher priority than global default attributes; S330. Detect bit field conflicts within registers: S331. For each register, check whether the bit ranges of the segments it contains overlap; S332. Verify whether the total bit width of all bit segments exceeds the bit width limit of the corresponding register; S340. Handling instantiation dependencies across components: S341. Parse all register description information and build a global symbol table that records all component definitions; S342. Use graph traversal algorithm to topologically sort the dependency relationships of component instantiations.

6. The register design verification file generation method according to claim 1, characterized in that: The parameter configuration in step S100 includes UVM output parameters, and the UVM output parameters include at least one of a coverage enable parameter and a base address coverage parameter, which are used to customize the behavioral characteristics of the RAL verification model generated in step S300.

7. The register design verification file generation method according to claim 1, characterized in that: The RTL design code generated in step S400 includes the following modules: Top-level encapsulation module: named after the module name, providing a unified external interface; Bus interface module: including AHB interface module and APB interface module, used to convert AMBA bus protocol into register read and write operations; Register control logic module: including an address decoder and register logic instance generated based on the offset address; Register implementation module: register hardware implementation generated based on RDL specifications.

8. The register design verification file generation method according to claim 1, characterized in that: The RAL verification model generated in step S400 includes: Register bit segment class: inherited from the uvm_reg_field class, generated according to the bit segment range and bit segment name, corresponding to each functional bit segment in the hardware; Register class: inherited from the uvm_reg class, generated according to the register name, corresponding to each register in the hardware; Address mapping class: inherited from the uvm_reg_map class, calculates the absolute address of each register according to the base address and offset address; Register block class: inherited from the uvm_reg_block class, as the top-level container containing all registers and address mapping objects.

9. The register design verification file generation method according to claim 1, characterized in that: The register description document generated in step S400 includes: A register address mapping table generated based on the base address and the offset address; Functional descriptions of each register and bit segment generated based on the functional description; A register access characteristic description is generated based on the read / write attributes and reset value.

Images