A register management method and device, electronic equipment and storage medium

Abstract

Embodiments of the present application disclose a register management method and device, electronic equipment and a storage medium, and relate to the technical field of electronic design automation, wherein the method comprises: constructing a RALF parser to extract four-level parameters of a register description file and convert them into a unified data source, eliminating inconsistencies in multiple sources, constructing mapping rules between the four levels and verification models, header files and specification documents, ensuring that the output strictly corresponds to the specifications, one-key generation of UVM models, register description header files and structured specification books, and realizing full-process output of documents, verification and software. Finally, the output files are checked for syntax, properties and integrity, and compared for consistency of addresses, bit widths, access permissions and data sources, supplemented by address alignment, bit width summation and predictor configuration conflict checking, to ensure that there is no mismatch risk between RTL design, verification models and software definition. The present application effectively solves the problems of low manual maintenance efficiency, inconsistent data and long iteration cycle in the prior art.

Description

Technical Field

[0001] This invention relates to the field of electronic design automation technology, and in particular to a register management method, apparatus, electronic device, and storage medium. Background Technology

[0002] As the complexity of integrated circuit design continues to rise, the number of registers in system-on-a-chip (SoC) is exploding, making register management a critical aspect of the chip front-end design process. Current technology organizes register specifications based on a four-layer structure: system layer, module layer, register layer, and domain layer. However, traditional register management methods primarily rely on designers manually writing and maintaining register files, which reveals numerous shortcomings as the number of registers increases.

[0003] High labor costs mean designers must maintain the same register specifications in three places simultaneously: design documents, general verification methodologies and verification models, and software code. Any modification at any stage requires manual synchronization to the other two, exponentially increasing workload. Manual operation is highly prone to errors in address allocation, bit field partitioning, and access permission settings, and it's difficult to guarantee consistency between design documents, register transfer-level code, and verification models. When register definitions are modified, engineers may overlook updates, leading to hardware-software mismatches, a significant contributing factor to chip tape-out failures.

[0004] Furthermore, after register specifications change, engineers need to manually modify multiple files, such as the verification environment and RTL code, one by one. This process is tedious and prone to omissions, significantly lengthening the design iteration cycle. Moreover, some electronic design automation tools are often limited to a single output scenario and lack a systematic solution that connects the entire "documentation-verification-software" process. The output files remain fragmented, failing to fundamentally solve the problem of data inconsistency.

[0005] Therefore, there is an urgent need for a register management method that can automatically generate multiple types of register output files based on a unified input and ensure strict consistency between the outputs. Summary of the Invention

[0006] The present invention provides a register management method to address the problems of high labor costs, large repetitive workload, susceptibility to errors in manual operation, cumbersome and easily overlooked file updates, and long iteration cycles in existing technologies. The technical solution is as follows: According to one aspect of the present invention, a register management method includes: reading a RALF format register description file through a customized parser, extracting parameter information from four levels—system layer, module layer, register layer, and domain layer—and converting it into a unified data structure as a data source; the parameter information includes address, bit width, access permissions, and reset value; constructing mapping rules between the system layer, module layer, register layer, domain layer, and the target file based on the data attributes of the parameter information and the generation rules of the target file; the target file includes a UVM verification model, a register description header file, and a specification document; generating a UVM register model, a register description header file, and a structured register specification as output files based on the data source and the mapping rules; the UVM register model includes a hardware description and verification language; the register description header file includes a global base address macro, a register offset address macro, a mask macro, a shift macro, and a reset value macro; performing syntax validity verification, attribute verification, and integrity verification on the output file, comparing whether the address, bit width, and access permissions in the output file are consistent with the corresponding data in the data source, and if they are inconsistent, regenerating or modifying the output file.

[0007] In one embodiment, a custom parser reads a RALF-formatted register description file, extracts parameter information from four levels—system layer, module layer, register layer, and domain layer—and converts it into a unified data structure as a data source. This is achieved through the following steps: A RALF parser is constructed to read a standard RALF-formatted register description file, extracting the four levels and their corresponding parameter information; the parameter information from the system layer, module layer, register layer, and domain layer is converted into structured internal class data to construct a software object model, forming a unified internal data structure as a data source; the RALF parser is used to parse keywords in the register description file syntax.

[0008] In one embodiment, the mapping rules between the system layer, module layer, register layer, domain layer, and target file are constructed based on the data attributes of the parameter information and the generation rules of the target file through the following steps: If the target file is a UVM verification model, the mapping rule is to map the system layer and module layer to register blocks, the register layer to registers, and the domain layer to register fields, and configure the bit width, reset value, and access type of the register fields in the construction function; if the target file is a register description header file, the mapping rule is to map the system layer to a global base address macro definition, the module layer to a module offset address macro relative to the system layer, the register layer to a register absolute address macro, and the domain layer to a field mask macro, shift macro, and reset value macro; if the target file is a documentation, the mapping rule is to map the system layer, module layer, register layer, and domain layer to structured chapters and table entries in the documentation; the mapping rules are constructed based on the data attributes of the parameter information at each level and the generation syntax of the target file.

[0009] In one embodiment, generating a UVM register model, register description header file, and structured register specification as output files based on the data source and the mapping rules is achieved through the following steps: traversing the module layer list to generate register blocks based on the data source and the mapping rules, traversing the register layer list to generate registers, traversing the domain layer list to configure the configuration parameters of the register domains in the constructor function, generating standard-compliant Hardware Description and Verification Language register model code, and outputting the UVM register model file.

[0010] In one embodiment, generating a UVM register model, register description header file, and structured register specification as output files based on the data source and mapping rules is achieved through the following steps: A header file template is written based on the embedded software development requirements according to the data source and mapping rules; the system layer is defined as a global base address macro, and the module layer is defined as an offset address macro relative to the system layer, according to the register description header file generation logic; the register layer is defined as an absolute register address macro; the field layer defines mask macros, shift macros, and reset value macros; register mapping is defined using volatile structures; each field layer is defined using bit fields; and the register description header file is output in conjunction with the header file template.

[0011] In one embodiment, generating a UVM register model, register description header file, and structured register specification as output files based on the data source and the mapping rules is achieved through the following steps: reading parameter information at each level according to the data source and the mapping rules; the parameter information includes register offset address, name, width, read / write attributes, reset value, and detailed function description; filling the parameter information into the register specification template using a template engine to generate a structured register specification as output files; the register specification template includes Word or HTML templates.

[0012] In one embodiment, the output file undergoes syntax validity, attribute validation, and integrity validation. This involves comparing the addresses, bit widths, and access permissions in the output file with the corresponding data in the data source. If inconsistencies are found, the output file is regenerated or modified. This is achieved through the following steps: performing syntax validity validation on the output file using a validation function; performing attribute validation on the output file by extracting register attribute parameters from the output file and comparing them one-to-one with the parameters corresponding to the data source to verify consistency; checking whether all levels and attributes in the register description file have been completely generated into the output file. If any validation reveals inconsistencies, the corresponding output file is regenerated or modified. The validation also includes address alignment, whether the total domain bit width meets requirements, and whether there are conflicts between the configuration and the software definition.

[0013] According to one aspect of the present invention, a register management apparatus includes: a data source parsing and construction module, configured to read a RALF format register description file using a custom parser, extract parameter information from four levels—system layer, module layer, register layer, and domain layer—and convert it into a unified data structure as a data source; the parameter information includes address, bit width, access permissions, and reset value; and a mapping rule configuration module, configured to construct mapping rules between the system layer, module layer, register layer, domain layer, and the target file based on the data attributes of the parameter information and the target file generation rules; the target file includes a UVM verification model, a register description header file, and a... The document includes a multi-file generation module, used to generate a UVM register model, register description header file, and structured register specification as output files based on the data source and mapping rules; the UVM register model includes a hardware description and verification language; the register description header file includes global base address macros, register offset address macros, mask macros, shift macros, and reset value macros; and a file multi-verification module, used to perform syntax validity verification, attribute verification, and integrity verification on the output files, comparing the addresses, bit widths, and access permissions in the output files with the corresponding data in the data source, and regenerating or modifying the output files if they are inconsistent.

[0014] According to one aspect of the present invention, an electronic device includes at least one processor and at least one memory, wherein computer-readable instructions are stored on the memory; the computer-readable instructions are executed by one or more of the processors to cause the electronic device to implement the register management method as described above.

[0015] According to one aspect of the present invention, a storage medium has computer-readable instructions stored thereon, which are executed by one or more processors to implement the register management method described above.

[0016] The beneficial effects of the technical solution provided by this invention are: In the above technical solution, this invention constructs a RALF parser to read standard RALF format register description files, extracts parameter information from four levels—system layer, module layer, register layer, and domain layer—and converts it into a unified data structure as a single data source. Based on the data attributes of the parameter information at each level and the generation rules of the target file, it constructs mapping rules between the four levels and the general verification methodology verification model, register description header file, and documentation, ensuring that the generation logic of each output file strictly corresponds to the register specification. Based on the unified data source and mapping rules, it generates register model code conforming to the general verification methodology standard, a register description header file containing global base address macros, register offset address macros, mask macros, shift macros, and reset value macros, and a structured register specification document generated by a template engine with one click, achieving a complete "documentation-verification-software" output process. The output file undergoes syntax validity, attribute validation, and integrity checks. The addresses, bit widths, and access permissions in the output file are compared with those of the data source. If inconsistencies are found, the file is regenerated or modified. Additional checks include address alignment, domain-level bit width, and conflict verification between the verification model predictor configuration and the software definition, ensuring no mismatch risks between the register transfer-level design, the verification model, and the software definition. This invention achieves full automation and data consistency assurance in register management, significantly reducing labor costs and eliminating the risk of errors from manual operations. It also drastically shortens the iteration cycle when register specifications change, effectively solving the prominent problems of low efficiency in manual maintenance, data inconsistency between multiple files, and long iteration cycles in existing technologies. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments of the present invention will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention, and those skilled in the art can obtain other drawings based on these drawings without creative effort.

[0018] Figure 1 This is a flowchart illustrating a register management method according to an exemplary embodiment; Figure 2 This is a flowchart illustrating a register management method in an application scenario; Figure 3 This is a block diagram illustrating a register management apparatus according to an exemplary embodiment; Figure 4 This is a hardware structure diagram of an electronic device according to an exemplary embodiment; Figure 5 This is a block diagram illustrating an electronic device according to an exemplary embodiment. Detailed Implementation

[0019] Embodiments of the present invention are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present invention, and should not be construed as limiting the present invention.

[0020] Those skilled in the art will understand that, unless specifically stated otherwise, the singular forms “a,” “an,” “the,” and “the” used herein may also include the plural forms. It should be further understood that the term “comprising” as used in this disclosure means the presence of the stated features, integers, steps, operations, elements, and / or components, but does not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof. It should be understood that when we say an element is “connected” or “coupled” to another element, it can be directly connected or coupled to the other element, or there may be intermediate elements. Furthermore, “connected” or “coupled” as used herein can include wireless connections or wireless coupling. The term “and / or” as used herein includes all or any units and all combinations of one or more associated listed items.

[0021] This invention provides a register management method that uses RALF files as a single data source to establish hierarchical mapping rules and generate verification models, header files, and specifications with a single click. Supplemented by triple consistency checks, it achieves full automation and data closure in register management, solving the problems of low efficiency, easy mismatch between multiple files, and long iteration cycles in existing technologies. This register management method is applicable to register management devices, which can be electronic devices. The register management method in this invention can be applied to various scenarios, such as register management.

[0022] Please see Figure 1 This invention provides a register management method applicable to electronic devices.

[0023] In the following method embodiments, for ease of description, the execution subject of each step of the method is an electronic device, but this does not constitute a specific limitation.

[0024] like Figure 1 As shown, the method may include the following steps: Step 110: Read the RALF format register description file through a custom parser, extract parameter information from the four levels of system layer, module layer, register layer and domain layer, and convert it into a unified data structure as the data source.

[0025] In one possible implementation, a RALF parser is constructed. The RALF parser reads the standard RALF format register description file to extract the four levels of system layer, module layer, register layer, and domain layer, as well as their corresponding parameter information. The parameter information of the system layer, module layer, register layer, and domain layer is then transformed into structured internal class data to construct a software object model, forming a unified internal data structure as the data source.

[0026] The RALF parser is used to parse keywords in the register description file syntax; the system layer is used to define the global base address; the module layer is used to define the offset address relative to the system layer; the register layer is used to define the offset address relative to the module layer; the domain layer is used to define the least significant and most significant bits, access permissions, reset values, and descriptions within the registers; parameter information includes address, bit width, access permissions, reset values, etc., none of which are specified here.

[0027] Specifically, a parser is constructed to parse keywords such as register file, register, and field in RALF syntax. The parser takes a register description file in .ralf format as input and outputs a JSON or Python dictionary object containing a list of objects.

[0028] Furthermore, the parser reads the standard RALF file and extracts parameter information from four levels: system layer, module layer, register layer, and domain layer. The system layer defines the global base address, which serves as the address reference for all lower-level modules; the module layer defines the offset address relative to the system layer, supporting independent addressing of multiple modules; the register layer defines the offset address relative to the module layer, which must meet bit width alignment (32-bit registers are aligned to 4 bytes); the domain layer defines the core attributes of registers, such as bit fields (least significant bit / most significant bit), access permissions (covering 26 types including read / write, write-only, read-only, etc.), reset values, and functional descriptions.

[0029] Furthermore, the extracted four-level parameter information is transformed into structured inner classes to construct a software object model, forming a unified internal data structure. This data structure serves as a single data source, acting as a bridge between inputs and various output templates, ensuring that all subsequent output files originate from the same data definition.

[0030] In the above process, the embodiments of the present invention extract four-level parameters by constructing a RALF parser and converting them into a unified data source, so that register specification information only needs to maintain one RALF file, eliminating the hidden danger of inconsistency of multi-source data from the source, providing a data foundation for full-process automation, and realizing the data management goal of defining once and using everywhere.

[0031] Step 120: Construct mapping rules between the system layer, module layer, register layer, domain layer and target file based on the data attributes of the parameter information and the generation rules of the target file.

[0032] In one possible implementation, if the target file is a UVM verification model, the mapping rule is to map the system layer and module layer to register blocks, the register layer to registers, and the domain layer to register domains, and configure the bit width, reset value, and access type of the register domains in the constructor function.

[0033] In one possible implementation, if the target file is a register description header file, the mapping rules are as follows: the system layer is mapped to global base address macro definitions, the module layer is mapped to module offset address macros relative to the system layer, the register layer is mapped to register absolute address macros, and the field layer is mapped to field mask macros, shift macros, and reset value macros. In one possible implementation, if the target file is a documentation document, the mapping rule is to map the system layer, module layer, register layer, and domain layer to the structured chapters and table entries in the documentation document.

[0034] The mapping rules are constructed based on the data attributes of the parameter information at each level and the generation syntax of the target files; the target files include the UVM verification model, register description header files, documentation, etc., which are not specified here.

[0035] Specifically, the configuration tool outputs a file hierarchy mapping rule, which establishes the correspondence between the four levels of RALF and each level of the output file—mapping the system layer, module layer, register layer, and domain layer of RALF to the corresponding structural units in the target file.

[0036] Furthermore, if the target file is a UVM verification model, the mapping rule is to map the system layer and module layer to register blocks, the register layer to registers, and the domain layer to register domains. In the constructor, the bit width, reset value, access type and other parameters of the register domain are configured to generate SystemVerilog register model code that conforms to the UVM standard.

[0037] Furthermore, if the target file is a register description header file, the mapping rules are as follows: the system layer is mapped to a global base address macro definition, the module layer is mapped to a module offset address macro relative to the system layer, the register layer is mapped to a register absolute address macro, and the field layer is mapped to a field mask macro, shift macro, and reset value macro. At the same time, the volatile structure can be used to define register mappings and bit fields can be used to define each field layer.

[0038] Furthermore, if the target file is a documentation document, the mapping rule is to map the system layer, module layer, register layer, and domain layer to structured chapters and table entries in the documentation document, including information such as register offset address, name, width, read / write attributes, reset value, and detailed functional description.

[0039] In the above process, the embodiments of the present invention construct differentiated mapping rules according to the data attributes of each level and the target file generation syntax, so that the same data source can be automatically adapted to the corresponding expression form according to the needs of engineers in different positions, providing flexible and scalable multi-target output capabilities, and realizing accurate conversion from RALF general description to the "dialects" of design, verification and software fields.

[0040] Step 130: Generate the UVM register model, register description header file, and structured register specification as output files based on the data source and mapping rules.

[0041] In one possible implementation, register blocks are generated by traversing the module layer list based on the data source and mapping rules, registers are generated by traversing the register layer list, configuration parameters of register fields are configured in the constructor function by traversing the domain layer list, hardware description and verification language register model code conforming to the standard is generated, and UVM register model file is output.

[0042] In one possible implementation, a header file template is written based on the embedded software development requirements according to the data source and mapping rules. According to the register description header file generation logic, the system layer is defined as a global base address macro, the module layer is defined as an offset address macro relative to the system layer, the register layer is defined as an absolute register address macro, and the field layer is defined as a mask macro, shift macro, and reset value macro. A volatile structure is used to define the register mapping, and bit fields are used to define each field layer. The register description header file is then output in combination with the header file template.

[0043] In one possible implementation, parameter information at each level is read according to the data source and mapping rules. The parameter information includes register offset address, name, width, read / write attributes, reset value, and detailed function description. The parameter information is then populated into the register specification template through a template engine to generate a structured register specification as the output file.

[0044] The UVM register model includes a hardware description and verification language; the register description header file includes global base address macros, register offset address macros, mask macros, shift macros, and reset value macros; the register specification template includes Word or HTML templates, etc., none of which are specified here.

[0045] Specifically, based on the data source and UVM mapping rules, the module layer list is traversed to generate register blocks, the register layer list is traversed to generate registers, and the domain layer list is traversed to configure the register field's bit width, reset value, access type, and other configuration parameters in the constructor function. This generates SystemVerilog hardware description and verification language register model code that conforms to the UVM standard, and outputs the UVM register model file.

[0046] Furthermore, based on the data source and register description header file mapping rules, a header file template is written according to the embedded software development requirements. Global base address macros, module relative offset macros, register absolute address macros, as well as field mask macros, shift macros, and reset value macros are defined sequentially according to the generation logic. The register description header file is then output in combination with the template.

[0047] Furthermore, based on the data source and documentation mapping rules, the parameter information of each level (including register offset address, name, width, read / write attributes, reset value, detailed function description, etc.) is read, and the data is populated into a Word or HTML template through the template engine to generate a structured register specification.

[0048] In the above process, the embodiments of the present invention generate three types of output files—verification model, header file, and specification document—with one click based on a unified data source and differentiated mapping rules. This transforms the repetitive work that originally required designers to manually maintain the documentation, verification environment, and software code into fully automated batch generation. It provides a one-click solution for the entire closed-loop process of "documentation-verification-software," achieving the goals of significantly reducing labor costs, eliminating human error, and shortening the iteration cycle.

[0049] Step 140: Perform syntax validity, attribute validation, and integrity validation on the output file. Compare the addresses, bit widths, and access permissions in the output file with the corresponding data in the data source. If they are inconsistent, regenerate or modify the output file.

[0050] In one possible implementation, a validation function is used to perform syntax validation on the output file. This function checks the syntax validity of the output file, performs attribute validation on the output file, extracts register attribute parameters from the output file and compares them one by one with the parameters corresponding to the data source to verify whether the two are consistent. It also checks whether all levels and attributes in the register description file have been completely generated into the output file. If any validation is inconsistent, the corresponding output file is regenerated or modified.

[0051] The verification also includes whether the address is aligned, whether the total bit width of the domain layer meets the requirements, and whether there are conflicts between the configuration and the software definition, etc., which are not specified here.

[0052] Specifically, by using the validation function embedded in the generation logic, the output file is first validated for grammatical validity. This checks whether the syntax of the generated file conforms to the standard requirements of its respective language, ensuring that the output file is grammatically correct.

[0053] Furthermore, register attribute parameters (including address, bit width, access permissions, etc.) are extracted from the output file and compared one by one with the corresponding parameters in the data source to verify whether the two are strictly consistent. In addition, the verification also includes checking whether the address is aligned and whether the sum of the domain layer bit widths is an integer multiple of 8, 16, or 32.

[0054] Furthermore, check whether all levels and attributes in the RALF register description file have been completely generated into the output file, ensuring that no register definition information is missing. Also, verify whether there are any conflicts between the predictor configuration in the UVM validation model and the software definition.

[0055] In the above process, the embodiments of the present invention perform triple checks on the output file (syntax, attributes, and integrity) and supplement them with address alignment, bit width compliance, and predictor configuration conflict checks, so that any generation deviation can be detected in time and trigger regeneration or modification. This provides a comprehensive guarantee mechanism for output quality and achieves the quality goal of no mismatch risk between register transfer level design, verification model, and software definition.

[0056] Through the above process, this embodiment of the invention extracts the four-level parameters of the register description file by constructing a RALF parser and converts them into a unified data source. It establishes differentiated mapping rules between the four levels and the UVM verification model, register description header file, and documentation, generating three types of output files with a single click and supplementing them with triple checks of syntax, attributes, and integrity. This achieves full automation of register management and a closed-loop data consistency mechanism. It fundamentally eliminates the risk of mismatch between multiple files under traditional manual maintenance methods, transforming repetitive maintenance work in documentation, verification, and software into one-click batch generation. Simultaneously, a multi-dimensional verification mechanism ensures strict consistency between RTL design, verification model, and software definition, significantly reducing labor costs, eliminating the error risks introduced by manual operation, and greatly shortening the iteration cycle when register specifications change. It effectively solves the prominent problems of low efficiency, data inconsistency, and long iteration cycles in existing technologies, providing an efficient, reliable, and scalable solution for register management.

[0057] In one application scenario, taking the register management of a system-on-a-chip (SoC) project that includes three functional modules—clock control, reset control, and power management—as an example, the first step is to write a register description file according to the RALF syntax specification based on the chip specifications. The register management method of this invention is then used for register management.

[0058] like Figure 2 As shown, the specific steps may include: Step S1: The user imports the RALF file and extracts the register object model.

[0059] Specifically, users import .ralf files through the tool interface. The constructed RALF parser reads the file and parses keywords such as register file, register, and field in the RALF syntax. The parser extracts the global base address 0x40000000 from the system layer, the names of each module and their offset addresses relative to the system layer from the module layer, the names, offset addresses, and bit widths of each register from the register layer, and the names, least significant bits, most significant bits, read / write access permissions, and reset values ​​of each field from the field layer.

[0060] Furthermore, the parser transforms all extracted parameter information into structured internal class data—the system layer is encapsulated as the System class, the module layer as the Block class, the register layer as the Register class, and the domain layer as the Field class. The four-level membership relationship is maintained through the reference relationship between objects, ultimately forming a unified internal data structure as the data source, presented in tabular form.

[0061] In the above process, the embodiments of the present invention construct a RALF parser to automatically parse the register description file and extract four-level parameters, so that the register specification information can be efficiently accessed by subsequent processes in the form of a structured object model, providing a unified and reliable data foundation.

[0062] Step S2: Write the extracted register object model into an Excel spreadsheet structure.

[0063] Specifically, this invention automatically writes the extracted register object model into an Excel spreadsheet. This spreadsheet includes module and register tabs: the module tab is organized at two levels, system layer and module layer, listing the name, base address, offset address, and description of each module; the register tab is organized at three levels, module layer, register layer, and domain layer, detailing the register offset address, name, bit width, least significant and most significant bits of each domain layer, read / write access permissions, reset value, and function description. This Excel data is synchronized in real-time with a unified data source to ensure consistency between the two.

[0064] In the above process, the embodiments of the present invention write the register object model into a structured Excel spreadsheet, enabling designers to intuitively view and confirm register specification information in a familiar table format, providing a user-friendly data visualization and review interface.

[0065] Step S3: Generate UVM verification files, header files, and documentation.

[0066] Specifically, based on a unified data source and pre-configured hierarchical mapping rules, this invention generates three types of output files in parallel. Regarding UVM verification file generation, it traverses the module layer list to generate register blocks for each module, traverses the register layer list to generate registers, and traverses the domain layer list to configure parameters such as bit width, reset value, and access type in the constructor function, outputting SystemVerilog register model code that conforms to the general verification methodology standard.

[0067] In terms of header file generation, the system layer is defined as a global base address macro, the module layer as an offset macro, the register layer as an absolute address macro, and the field layer as a mask macro, shift macro, and reset value macro, according to the generation logic. At the same time, volatile structures are used to define register mappings and bit fields to define each field layer, and the output register description header file is used.

[0068] Regarding documentation generation, a document generation library is used to read parameter information from each level of the data source, and a template engine is used to populate a Word template to generate a structured register specification. All three types of output files are organized based on a four-level hierarchical relationship to ensure strict correspondence with the data source.

[0069] In the above process, the embodiments of the present invention generate three types of output files with one click, completely freeing designers from the repetitive maintenance of documents, verification environment and software code, and realizing full automation of the "document-verification-software" process.

[0070] Step S4: Quality verification.

[0071] Specifically, after generating the three types of output files, quality checks are performed. First, a syntax validity check is performed, verifying the correctness of the SystemVerilog syntax in the UVM verification files, the syntax rules of the header files, and the format of the documentation. Second, attribute checks are performed, extracting attributes such as address, bit width, and access permissions from each output file and comparing them one by one with the data source. Simultaneously, it is verified whether register addresses are aligned to 4 bytes, whether the total bit width of each domain layer is a multiple of 8 / 16 / 32, and whether there are any conflicts between the UVM predictor configuration and the software definition.

[0072] Finally, an integrity check is performed to verify that all levels and attributes in RALF have been completely generated into the three types of output files. If any check fails, a regeneration or modification is triggered until all checks pass.

[0073] In the above process, the embodiments of the present invention use a triple verification mechanism supplemented by special checks to ensure the consistency between RTL design, UVM verification model and register header file definition, fundamentally eliminating the risk of software and hardware mismatch.

[0074] Through the above process, this embodiment of the invention demonstrates the entire process from RALF file import to output file quality verification, using SoC chip register management, which includes three functional modules, as an application scenario. After the user imports the RALF file, the parser automatically extracts parameter information from four levels: system layer, module layer, register layer, and domain layer, and converts it into a unified data source. The data source is then presented in an Excel spreadsheet for easy review. Subsequently, based on the unified data source and differentiated mapping rules, a UVM verification model, register description header file, and structured register specification are generated with one click, achieving full automation of the document-verification-software process. Finally, triple verification of syntax, attributes, and integrity ensures output quality. This invention completely replaces the cumbersome traditional method of manually maintaining register specifications in three separate locations. When register specifications change, only one RALF file needs to be modified, and the generation and verification processes need to be re-executed to synchronize all output files. This significantly reduces labor costs, eliminates the risk of human error, and greatly shortens the iteration cycle, providing an efficient, reliable, and scalable solution for register management in SoC chip front-end design.

[0075] The following are embodiments of the apparatus of the present invention, which can be used to execute the register management method involved in the present invention. For details not disclosed in the embodiments of the apparatus of the present invention, please refer to the method embodiments of the register management method involved in the present invention.

[0076] Please see Figure 3 This invention provides a register management device 800.

[0077] The register management device 800 includes, but is not limited to: a data source parsing and construction module 810, a mapping rule configuration module 830, a multi-type file generation module 850, and a file multi-verification module 870.

[0078] Among them, the data source parsing construction module 810 is used to read the RALF format register description file through a custom parser, extract parameter information from the four levels of system layer, module layer, register layer and domain layer, and convert it into a unified data structure as the data source; the parameter information includes address, bit width, access permission and reset value.

[0079] The mapping rule configuration module 830 is used to construct mapping rules between the system layer, module layer, register layer, domain layer and target file based on the data attributes of the parameter information and the generation rules of the target file; the target file includes the UVM verification model, register description header file and documentation.

[0080] The multi-file generation module 850 is used to generate UVM register models, register description header files, and structured register specifications as output files based on data sources and mapping rules. The UVM register model includes hardware description and verification languages. The register description header file includes global base address macros, register offset address macros, mask macros, shift macros, and reset value macros.

[0081] The file multi-validation module 870 is used to perform syntax validity, attribute validation, and integrity validation on the output file. It compares the address, bit width, and access permissions in the output file with the corresponding data in the data source. If they are inconsistent, the output file is regenerated or modified.

[0082] It should be noted that the register management provided in the above embodiments is only an example of the division of the above functional modules. In actual applications, the above functions can be assigned to different functional modules as needed. That is, the internal structure of the register management device will be divided into different functional modules to complete all or part of the functions described above.

[0083] Furthermore, the register management device and the register management method provided in the above embodiments belong to the same concept, and the specific way in which each module performs operations has been described in detail in the method embodiments, and will not be repeated here.

[0084] Figure 4 A schematic diagram of the structure of an electronic device according to an exemplary embodiment is shown.

[0085] It should be noted that this electronic device is merely an example adapted to the present invention and should not be construed as providing any limitation on the scope of use of the present invention. Furthermore, this electronic device should not be interpreted as requiring or depending on any particular feature. Figure 4 One or more components of the exemplary electronic device 2000 shown.

[0086] The hardware structure of electronic devices 2000 can vary significantly due to differences in configuration or performance, such as... Figure 4 As shown, the electronic device 2000 includes: a power supply 210, an interface 230, at least one memory 250, and at least one central processing unit (CPU) 270.

[0087] Specifically, power supply 210 is used to provide operating voltage for various hardware devices on electronic device 2000.

[0088] Interface 230 includes at least one wired or wireless network interface 231 for interacting with external devices. Of course, in other examples adapted to this invention, interface 230 may further include at least one serial-to-parallel conversion interface 233, at least one input / output interface 235, and at least one USB interface 237, etc. Figure 4 As shown, this does not constitute a specific limitation.

[0089] The memory 250 serves as a carrier for resource storage and can be a read-only memory, random access memory, disk, or optical disk, etc. The resources stored on it include the operating system 251, application programs 253, and data 255, etc., and the storage method can be temporary storage or permanent storage.

[0090] The operating system 251 is used to manage and control the various hardware devices and application programs 253 on the electronic device 2000, so as to enable the central processing unit 270 to perform calculations and processing on the massive data 255 in the memory 250. It can be Windows Server™, Mac OS X™, Unix™, Linux™, FreeBSD™, etc.

[0091] Application 253 is a computer-readable instruction based on operating system 251 that performs at least one specific task, and may include at least one module ( Figure 4 (Not shown), each module may contain computer-readable instructions for the electronic device 2000. For example, the register management device may be considered as application program 253 deployed on the electronic device 2000.

[0092] Data 255 may be signal information, etc., and is stored in memory 250.

[0093] The central processing unit 270 may include one or more processors and is configured to communicate with the memory 250 via at least one communication bus to read computer-readable instructions stored in the memory 250, thereby performing operations and processing on massive amounts of data 255 stored in the memory 250. For example, the register management method may be implemented by the central processing unit 270 reading a series of computer-readable instructions stored in the memory 250.

[0094] Furthermore, the present invention can also be implemented through hardware circuits or a combination of hardware circuits and software. Therefore, the implementation of the present invention is not limited to any specific hardware circuit, software, or combination thereof.

[0095] Please see Figure 5 This invention provides an electronic device 4000, which may include: a desktop computer, a laptop computer, a server, etc., with sensor recognition capabilities.

[0096] exist Figure 5 In this context, the electronic device 4000 includes at least one processor 4001 and at least one memory 4003.

[0097] The data interaction between the processor 4001 and the memory 4003 can be achieved through at least one communication bus 4002. This communication bus 4002 may include a path for transmitting data between the processor 4001 and the memory 4003. The communication bus 4002 may be a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus, etc. The communication bus 4002 can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 5 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0098] Optionally, the electronic device 4000 may further include a transceiver 4004, which can be used for data interaction between the electronic device and other electronic devices, such as sending and / or receiving data. It should be noted that in practical applications, the transceiver 4004 is not limited to one type, and the structure of the electronic device 4000 does not constitute a limitation on the embodiments of the present invention.

[0099] Processor 4001 may be a CPU (Central Processing Unit), a general-purpose processor, a DSP (Digital Signal Processor), an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It can implement or execute the various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this invention. Processor 4001 may also be a combination that implements computing functions, such as including one or more microprocessor combinations, a combination of a DSP and a microprocessor, etc.

[0100] The memory 4003 may be a ROM (Read Only Memory) or other type of static storage device capable of storing static information and instructions, RAM (Random Access Memory) or other type of dynamic storage device capable of storing information and instructions, or an EEPROM (Electrically Erasable Programmable Read Only Memory), CD-ROM (Compact Disc Read Only Memory) or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital universal optical discs, Blu-ray discs, etc.), magnetic disk storage media or other magnetic storage devices, or any other medium capable of carrying or storing desired program instructions or code in the form of instructions or data structures and accessible by the electronic device 4000, but not limited thereto.

[0101] The memory 4003 stores computer-readable instructions, and the processor 4001 can read the computer-readable instructions stored in the memory 4003 through the communication bus 4002.

[0102] The computer-readable instructions are executed by one or more processors 4001 to implement the register management methods in the above embodiments.

[0103] Furthermore, this embodiment of the invention provides a storage medium storing computer-readable instructions, which are executed by one or more processors to implement the register management method described above.

[0104] This invention provides a computer program product including computer-readable instructions stored in a storage medium. One or more processors of an electronic device read the computer-readable instructions from the storage medium, load and execute the computer-readable instructions, thereby enabling the electronic device to implement the register management method described above.

[0105] Compared with related technologies, the beneficial effects of the present invention are: 1. This invention can significantly reduce labor costs and improve design efficiency. By building a RALF parser, it automatically converts four-level parameter information into a unified data source and generates UVM verification models, register description header files, and structured register specifications with one click based on mapping rules. This transforms the repetitive work that originally required designers to manually maintain documents, verification environments, and software code into fully automated batch generation, completely eliminating the inefficient mode of manually writing register files one by one. It greatly shortens the design cycle of register management and allows engineers to focus their energy on higher-value design work.

[0106] 2. This invention can fundamentally eliminate the risk of data inconsistency between multiple files. By using the RALF file as the sole input data source, all output files (verification model, header file, documentation) originate from the same data definition. This avoids the data synchronization problem caused by manual operation when the design document, RTL code, and verification model are maintained independently in the traditional way. When the register specifications change, only one RALF file needs to be modified and the generation process needs to be re-executed to achieve synchronous updates of all output files. This completely eliminates the mismatch between hardware and software specifications caused by missing an update, and ensures the consistency and correctness of data from a mechanism level.

[0107] 3. This invention can effectively guarantee the quality and reliability of the output file. By performing a triple mechanism of syntax validity verification, attribute verification, and integrity verification on the generated file, the address, bit width, and access permissions in the output file are compared with the data source one by one. At the same time, it is supplemented by address alignment checks, checks on whether the total bit width of the domain layer is an integer multiple of 8 / 16 / 32, and checks on whether there are conflicts between the UVM verification model predictor configuration and the software definition. This ensures that any generation deviation can be detected in time and trigger regeneration or modification. It provides comprehensive protection for output quality from three dimensions: syntax correctness, data accuracy, and content integrity.

[0108] 4. This invention has good versatility and scalability; by establishing differentiated mapping rules between the four levels of RALF and each target file, the conversion logic of each level can be defined according to the generation syntax and data expression requirements of different output files (UVM verification model, register description header file, and documentation). When a new output type needs to be added, only the corresponding mapping rules and templates need to be added to achieve the expansion, without changing the core parsing and data management framework, so that it can flexibly adapt to the diverse needs of different chip projects for register management tools.

[0109] 5. This invention can effectively shorten the chip design iteration cycle. By providing a fully automated "one-click generation" solution from RALF input to multiple types of file output, when register specifications change during the chip design iteration process, engineers do not need to open multiple files one by one for manual synchronous modification. They only need to update the RALF file and re-execute the generation and verification process to obtain all updated output files in a short time. This greatly speeds up the response speed to design changes, thereby significantly shortening the iteration cycle of the entire chip front-end design and providing a strong guarantee for timely project delivery.

[0110] It should be understood that although the steps in the flowcharts of the accompanying figures are shown sequentially as indicated by the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the accompanying figures may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times, and their execution order is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0111] The above description is only a partial embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A register management method, characterized in that, The method includes: A custom parser reads the RALF format register description file, extracts parameter information from four levels: system layer, module layer, register layer, and domain layer, and converts it into a unified data structure as the data source; the parameter information includes address, bit width, access permissions, and reset value; Based on the data attributes of the parameter information and the generation rules of the target file, a mapping rule is constructed between the system layer, module layer, register layer, domain layer and the target file; the target file includes a UVM verification model, a register description header file, and a documentation file; The UVM register model, register description header file, and structured register specification are generated as output files based on the data source and the mapping rules. The UVM register model includes hardware description and verification language. The register description header file includes global base address macros, register offset address macros, mask macros, shift macros, and reset value macros. The output file is subjected to syntax validity, attribute validation, and integrity validation. The address, bit width, and access permissions in the output file are compared with the corresponding data in the data source. If they are inconsistent, the output file is regenerated or modified.

2. The register management method as described in claim 1, characterized in that, The process of reading RALF format register description files through a custom parser, extracting parameter information from four levels—system layer, module layer, register layer, and domain layer—and converting it into a unified data structure as a data source includes: Construct a RALF parser, and use the RALF parser to read the standard RALF format register description file to extract the four levels of system layer, module layer, register layer, and domain layer and their corresponding parameter information; The parameter information of the system layer, module layer, register layer, and domain layer is transformed into structured internal class data to construct a software object model, forming a unified internal data structure as a data source; the RALF parser is used to parse keywords in the register description file syntax.

3. The register management method as described in claim 1, characterized in that, The step of constructing the mapping rules between the system layer, module layer, register layer, domain layer, and target file based on the data attributes of the parameter information and the generation rules of the target file includes: If the target file is a UVM verification model, the mapping rule is to map the system layer and module layer to register blocks, the register layer to registers, and the domain layer to register fields, and configure the bit width, reset value, and access type of the register fields in the constructor function; If the target file is a register description header file, the mapping rule is to map the system layer to global base address macro definitions, the module layer to module offset address macros relative to the system layer, the register layer to register absolute address macros, and the field layer to field mask macros, shift macros, and reset value macros. If the target file is a documentation document, the mapping rule is to map the system layer, module layer, register layer, and domain layer to the structured chapters and table entries in the documentation document; the mapping rule is constructed based on the data attributes of the parameter information at each level and the generation syntax of the target file.

4. The register management method as described in claim 1, characterized in that, The step of generating a UVM register model, register description header file, and structured register specification as output files based on the data source and the mapping rules includes: Based on the data source and mapping rules, the module layer list is traversed to generate register blocks, the register layer list is traversed to generate registers, the domain layer list is traversed to configure the register domain configuration parameters in the constructor function, the standard-compliant Hardware Description and Verification Language register model code is generated, and the UVM register model file is output.

5. The register management method as described in claim 1, characterized in that, The step of generating a UVM register model, register description header file, and structured register specification as output files based on the data source and the mapping rules also includes: Based on the data source and mapping rules, a header file template is written according to the embedded software development requirements. According to the register description header file generation logic, the system layer is defined as a global base address macro, and the module layer is defined as an offset address macro of the module relative to the system layer. The register layer is defined as an absolute register address macro, the field layer is defined as a mask macro, a shift macro, and a reset value macro, a volatile structure is used to define register mapping, the bit fields are used to define each field layer, and the register description header file is output in conjunction with the header file template.

6. The register management method as described in claim 1, characterized in that, The step of generating a UVM register model, register description header file, and structured register specification as output files based on the data source and the mapping rules also includes: The parameter information of each level is read according to the data source and the mapping rules; the parameter information includes register offset address, name, width, read / write attributes, reset value, and detailed function description; The parameter information is populated into the register specification template using a template engine to generate a structured register specification as the output file; the register specification template includes Word or HTML templates.

7. The register management method as described in claim 1, characterized in that, The process of performing syntax validity, attribute validation, and integrity checks on the output file, comparing the addresses, bit widths, and access permissions in the output file with the corresponding data in the data source, and if they do not match, regenerating or modifying the output file, includes: The output file is subjected to syntax validity checks by a validation function. The output file is checked for syntax validity. The output file is also subjected to attribute checks. Register attribute parameters are extracted from the output file and compared one by one with the parameters corresponding to the data source to verify whether the two are consistent. Check whether all levels and attributes in the register description file have been completely generated into the output file. If any check is inconsistent, regenerate or modify the corresponding output file. The check also includes whether the address is aligned, whether the total bit width of the domain layer meets the requirements, and whether there is a conflict between the configuration and the software definition.

8. A register management device, characterized in that, The device includes: The data source parsing module is used to read RALF format register description files through a custom parser, extract parameter information from four levels: system layer, module layer, register layer, and domain layer, and convert it into a unified data structure as the data source; the parameter information includes address, bit width, access permissions, and reset value; The mapping rule configuration module is used to construct mapping rules between the system layer, module layer, register layer, domain layer and the target file based on the data attributes of the parameter information and the generation rules of the target file; the target file includes a UVM verification model, a register description header file and a documentation file; A multi-file generation module is used to generate UVM register models, register description header files, and structured register specifications as output files based on the data source and the mapping rules; the UVM register model includes hardware description and verification languages; the register description header file includes global base address macros, register offset address macros, mask macros, shift macros, and reset value macros; The file multi-validation module is used to perform syntax validity, attribute validation, and integrity validation on the output file. It compares the address, bit width, and access permissions in the output file with the corresponding data in the data source. If they are inconsistent, the output file is regenerated or modified.

9. An electronic device, characterized in that, include: At least one processor and at least one memory, wherein, The memory stores computer-readable instructions; The computer-readable instructions are executed by one or more of the processors, causing the electronic device to implement the register management method as described in any one of claims 1 to 7.

10. A storage medium having computer-readable instructions stored thereon, characterized in that, The computer-readable instructions are executed by one or more processors to implement the register management method as described in any one of claims 1 to 7.

Images