A register model file conversion method, device and electronic equipment

Abstract

The application provides a register model file conversion method and device and electronic equipment, and relates to the chip design and verification technical field. First, a SystemVerilog format register model file is acquired, then the SystemVerilog format register model file is parsed, then according to a preset syntax mapping rule, the extracted attribute information is converted into a Trace32 PER format syntax sentence, and finally, according to the converted syntax sentence, a Trace32 PER format register model file is generated. The scheme provided in the application has the advantages of good information consistency, high efficiency, strong compatibility and lower maintenance cost.

Description

Technical Field

[0001] This application relates to the field of chip design and verification technology, and more specifically, to a register model file conversion method, apparatus and electronic device. Background Technology

[0002] In current chip development workflows, the front-end EDA verification stage commonly uses SystemVerilog combined with the UVM (Universal Verification Methodology) to build register models. UVM provides a standardized register modeling framework, using a three-layer architecture of uvm_reg_block, uvm_reg, and uvm_reg_field to complete register modeling, simulation verification, and coverage acquisition. This standardized modeling approach enables the front-end verification team to efficiently verify the correctness of register functionality.

[0003] In the bare-metal testing phase after chip tape-out (manufacturing), engineers typically use the Trace32 debugger for hardware debugging. Trace32 is a mainstream hardware debugging tool from Lauterbach, widely used for debugging and analyzing embedded systems. However, this tool only supports dedicated PER format register model files and cannot directly read UVM format SystemVerilog register models.

[0004] The closest existing approach in the industry is as follows: engineers manually compile information such as the name, address, bit fields, and permissions of the front-end UVM register model, and write the PER register model file line by line according to the syntax specification of the Trace32 PER file. The file is then imported into the Trace32 tool for register reading, writing, configuration, and debugging. In some scenarios, a simple script is used to extract some register address information, and then the syntax, bit fields, and hierarchical content are manually completed. However, a standardized and fully automated conversion process has not been formed.

[0005] However, manual conversion of register model files generally suffers from problems such as poor information consistency, extremely low efficiency of manual writing, poor compatibility, and high maintenance costs. Summary of the Invention

[0006] The purpose of this application is to provide a register model file conversion method, apparatus, and electronic device to solve the problems of poor information consistency, extremely low efficiency of manual writing, poor compatibility, and high maintenance cost in the existing register model file conversion technology.

[0007] To achieve the above objectives, the technical solutions adopted in the embodiments of this application are as follows: In a first aspect, embodiments of this application provide a register model file conversion method, which includes the following steps: Obtain a register model file in SystemVerilog format; wherein the register model file in SystemVerilog format contains register groups described using the uvm_reg_block class, registers described using the uvm_reg class, and bit fields described using the uvm_reg_field class; The SystemVerilog format register model file is parsed, and the attribute information of the register group, the register, and the bit field is extracted based on the uvm_reg_block class, the uvm_reg class, and the uvm_reg_field class, respectively. According to the preset syntax mapping rules, the extracted attribute information is converted into Trace32 PER format syntax statements. The preset syntax mapping rules include: mapping the uvm_reg_block class to TREE syntax blocks, mapping the uvm_reg class to LINE.LONG statements, and mapping the uvm_reg_field class to BITFLD.LONG statements. Based on the converted syntax statements, a register model file in Trace32 PER format is generated.

[0008] Optionally, after the step of obtaining the register model file in SystemVerilog format, the method further includes: The SystemVerilog format register model file is verified; the verification includes at least the following: Determine whether the SystemVerilog format register model file contains complete uvm_reg_block module definitions, uvm_reg register instances, and uvm_reg_field bit field definitions; determine whether all register address, bit width, permissions, and hierarchical relationship configurations are complete.

[0009] Optionally, before the step of obtaining the register model file in SystemVerilog format, the method further includes: Deploy the Python runtime environment, load the Python conversion script, and configure the input and output paths of the conversion script. The input path points to the SystemVerilog format register model file to be converted, and the output path points to the Trace32 PER format register model file to be generated after conversion.

[0010] Optionally, the step of parsing the SystemVerilog format register model file and extracting the attribute information of the register group, the register, and the bit field based on the uvm_reg_block class, the uvm_reg class, and the uvm_reg_field class respectively includes: The SystemVerilog format register model file is scanned line by line, and the keywords uvm_reg_block, uvm_reg, and uvm_reg_field in the SystemVerilog format register model file are identified by keyword matching technology. In response to the keyword, the corresponding attribute information is extracted and cached; wherein, for the uvm_reg_block keyword, the extracted attribute information includes module name, base address and hierarchical affiliation; For the uvm_reg keyword, the extracted attribute information includes register name, module, offset address, and read / write permissions; For the uvm_reg_field keyword, the extracted attribute information includes the bit name, the register it belongs to, the start bit, the end bit, the access attribute, and the default value.

[0011] Optionally, the step of extracting and caching the corresponding attribute information in response to the keyword includes: Filter invalid content; wherein, the invalid content includes at least comments and blank lines.

[0012] Optionally, the step of converting the extracted attribute information into Trace32 PER format syntax statements according to preset syntax mapping rules includes: For each of the extracted register groups, a TREE syntax block in the PER format is generated to define the hierarchical container, and a BASE statement is configured in the TREE syntax block to set the base address of the register group; For each of the extracted registers, a corresponding LINE.LONG statement is generated within the TREE syntax block corresponding to the register group. The LINE.LONG statement contains at least the offset address and register name of the register. For each extracted bit field, a corresponding BITFLD.LONG statement is generated below the LINE.LONG statement corresponding to the register. The BITFLD.LONG statement contains at least the start bit, end bit, and bit field name of the bit field.

[0013] Optionally, the step of converting the extracted attribute information into Trace32 PER format syntax statements further includes: Error detection is performed on the converted Trace32 PER format syntax statements, and in response to the detected errors, the errors are automatically repaired to ensure that the final output PER format register model file is free of syntax errors; wherein, the error detection includes: Hierarchical indentation formatting: Based on the nested structure between the register group, the register, and the bit field, the hierarchical relationship between each element is automatically identified, and uniform indentation formatting is performed on the statements inside the TREE syntax block, so that the TREE syntax block, the LINE.LONG statement, and the BITFLD.LONG statement present a hierarchical indentation relationship corresponding to the nested structure in the PER format register model file; Address format standardization: The base address of the register group, the offset address of the register, and the position parameters of the bit field are uniformly converted into the hexadecimal format supported by the Trace32 debugging tool, and bit width padding and vertical alignment operations are performed on all address fields. Syntax element standardization: Perform operations to unify the case, symbol separation, and field spacing of the PER format syntax keywords, and standardize the quotation mark enclosed, comma separated, and comment symbols of the name string; Real-time syntax checking and automatic repair: Real-time detection of errors in the PER format syntax statements, including duplicate definitions, missing terminators, out-of-bounds addresses, reversed start and end bits of bit fields, mismatched levels, missing symbols, and abnormal spaces.

[0014] Optionally, after the step of generating the Trace32 PER format register model file, the register model file conversion method further includes: Automatically complete the file header configuration statements required by the Trace32 PER format, which include at least the CONFIG and WIDTH configuration items; The register model file in Trace32 PER format is verified; wherein the verification includes at least checking for address conflicts, missing syntax, and hierarchical errors.

[0015] Secondly, embodiments of this application also provide a register model file conversion apparatus, the register model file conversion apparatus comprising: The input module is used to obtain a register model file in SystemVerilog format; wherein, the register model file in SystemVerilog format contains register groups described using the uvm_reg_block class, registers described using the uvm_reg class, and bit fields described using the uvm_reg_field class. The parsing module is used to parse the SystemVerilog format register model file and extract the attribute information of the register group, the register and the bit field based on the uvm_reg_block class, the uvm_reg class and the uvm_reg_field class respectively. The conversion module is used to convert the extracted attribute information into Trace32PER format syntax statements according to preset syntax mapping rules, wherein the preset syntax mapping rules include: mapping the uvm_reg_block class to TREE syntax blocks, mapping the uvm_reg class to LINE.LONG statements, and mapping the uvm_reg_field class to BITFLD.LONG statements; The output module is used to generate a register model file in Trace32 PER format based on the converted syntax statement.

[0016] Thirdly, embodiments of this application also provide an electronic device, the electronic device comprising: Memory; Processor; and A computer program stored in memory and executable on a processor, wherein the processor, when executing the program, implements the register model file conversion method described above.

[0017] Compared with the prior art, this application has the following advantages: This application provides a register model file conversion method, apparatus, and electronic device. First, a SystemVerilog format register model file is obtained. Then, the SystemVerilog format register model file is parsed. Next, the extracted attribute information is converted into Trace32 PER format syntax statements according to a preset syntax mapping rule. Finally, a Trace32 PER format register model file is generated based on the converted syntax statements.

[0018] The method provided in this application directly reuses the SystemVerilog model that has passed front-end verification, eliminating information bias caused by manual coding. Front-end and back-end register parameters are completely synchronized, eliminating debugging errors. There is no need to maintain manual synchronization between two independent files, fundamentally solving the problem of information inconsistency. Simultaneously, it automatically generates Trace32 PER format register model files, saving significant time on manual sorting and proofreading, greatly accelerating baremetal test startup speed, and shortening the overall chip development cycle. Furthermore, fixed mapping rules and automatic verification mechanisms ensure that the generated PER files fully comply with Trace32 syntax specifications, with no parsing errors, and can be directly loaded and used, avoiding common syntax errors in handwritten files. In addition, after register design iterations and modifications, simply rerunning the script quickly generates updated PER files with zero synchronization errors, completely eliminating omissions and errors that easily occur during manual synchronization.

[0019] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

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

[0021] Figure 1 An exemplary flowchart of the register model file conversion method provided in this application embodiment.

[0022] Figure 2 This is another exemplary flowchart of the register model file conversion method provided in the embodiments of this application.

[0023] Figure 3 An exemplary flowchart of the sub-step S104 provided in the embodiments of this application.

[0024] Figure 4 This is a schematic diagram illustrating a register model file conversion example provided in this application.

[0025] Figure 5 This is a schematic diagram of the register model file conversion device provided in an embodiment of this application.

[0026] Figure 6 A schematic diagram of the modules of an electronic device provided in an embodiment of this application.

[0027] In the picture: 100 - Electronic device; 101 - Processor; 102 - Memory; 103 - Communication interface; 200 - Register model file conversion device; 210 - Input module; 220 - Parsing module; 230 - Conversion module; 240 - Output module. Detailed Implementation

[0028] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. The components of the embodiments of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations.

[0029] Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0030] It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. Furthermore, in the description of this application, terms such as "first," "second," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0031] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Some embodiments of this application are described in detail below with reference to the accompanying drawings. Unless otherwise specified, the following embodiments and features can be combined with each other.

[0032] In the development of integrated circuits (chips), registers are the basic storage units inside the chip used to control hardware behavior and store state information. A complex chip typically contains tens of thousands of registers, and each register may contain multiple bit fields, each controlling different hardware functions. To effectively manage these registers, the industry typically uses a register model to uniformly describe the name, address, bit width, bit field division, read / write permissions, and other attribute information of all registers.

[0033] Register models play a crucial role in the entire chip development process. They serve not only as the design basis for front-end designers, but also as the foundation for functional simulation verification by verification personnel, and an essential reference for hardware debugging by back-end testers. Therefore, the accuracy and consistency of register models directly impact the quality and efficiency of chip development.

[0034] As described in the background section, manual conversion methods for register model file conversion have the following problems: 1. The front-end and back-end register models cannot be reused, resulting in poor information consistency. The front-end UVM register model and the PER file used by Trace32 are independent of each other, and there is no automatic synchronization mechanism between the two files. Manual programming is highly susceptible to errors such as misspelled names, incorrect addresses, and inconsistencies between bit field definitions and the front-end design. Such inconsistencies can lead to debugging errors and even misoperations. Debuggers may perform read / write operations based on incorrect register addresses, resulting in incorrect hardware status updates or misreading of error messages. In severe cases, this can damage the chip or cause debugging failure.

[0035] 2. Manual coding is extremely inefficient and involves a huge workload. Chips contain a vast number of registers with complex hierarchical structures. For example, a medium-sized SoC chip typically has hundreds to thousands of registers, each potentially containing multiple bit fields. Manually writing PER files can take days or even weeks, especially in large-scale chip projects, requiring significant manpower and severely extending the baremetal test preparation cycle, thus impacting the overall project schedule.

[0036] 3. Lack of unified syntax mapping rules, resulting in poor compatibility. The syntax structures of UVM and PER formats differ significantly, lacking fixed syntax correspondence rules. When writing documents manually, engineers need to repeatedly consult the PER syntax specification, which can easily lead to formatting errors, keyword spelling mistakes, and sentence structure errors. This can cause Trace32 to fail to parse the file correctly, hindering debugging efforts.

[0037] 4. High maintenance costs and prone to errors. Register design is not static during chip development. As the design iterates and functions are added or removed, register specifications will inevitably change. Once the register design is modified, engineers need to manually modify the PER file to keep it synchronized. This synchronization operation is extremely difficult and prone to problems such as omissions (forgetting to update a register) and incorrect modifications (changing the wrong address or bit field), further reducing debugging efficiency.

[0038] In view of this, in order to solve the above problems, this application provides a register model file conversion method. For one implementation method, please refer to... Figure 1 The register model file conversion method includes: S102, obtain the SystemVerilog format register model file; wherein, the SystemVerilog format register model file contains register groups described using the uvm_reg_block class, registers described using the uvm_reg class, and bit fields described using the uvm_reg_field class.

[0039] S104 parses the SystemVerilog format register model file and extracts the attribute information of register groups, registers and bit fields based on the uvm_reg_block class, uvm_reg class and uvm_reg_field class respectively.

[0040] S106. According to the preset syntax mapping rules, the extracted attribute information is converted into Trace32 PER format syntax statements. The preset syntax mapping rules include: mapping the uvm_reg_block class to TREE syntax blocks, mapping the uvm_reg class to LINE.LONG statements, and mapping the uvm_reg_field class to BITFLD.LONG statements.

[0041] S108 generates a Trace32 PER format register model file based on the converted syntax statements.

[0042] Understandably, given the shortcomings of existing technologies such as low efficiency, inconsistent information, and lack of standardized conversion processes when manually writing code, this application provides a fully automated register model file conversion method based on Python scripts. It eliminates the tedious process of manual sorting and proofreading, directly reuses the UVM format SystemVerilog register model verified by the front-end EDA, and achieves automated parsing and syntax conversion of all information such as register level, address, bit field, and permissions through pre-defined unique syntax mapping rules. Finally, it generates a PER register model file that conforms to the Trace32 tool specification. The entire process requires no manual intervention and is perfectly adapted to the register debugging needs in baremetal testing scenarios.

[0043] Compared with existing manual writing and semi-manual completion methods, the core difference of this application lies in the establishment of a standardized and immutable three-layer syntax mapping system, coupled with a fully automated script execution process, which completely solves various problems caused by manual operation; at the same time, it accurately matches all attributes of the register model without losing any key information, ensuring that the converted file can be directly recognized and called by Trace32.

[0044] It should be noted that the register model file conversion method provided in this application is not aimed at general format conversion tasks, but rather focuses on the long-standing structural gap between the front-end and back-end toolchains in the chip verification and debugging process. In practical applications, the front-end EDA verification stage uses SystemVerilog language in conjunction with UVM (Universal Verification Methodology) to construct the register model. This model naturally has a three-layer structure: the top layer is encapsulated by the uvm_reg_block class, which is used to divide the chip functional modules and carry the base address and hierarchical relationship; the middle layer is defined by the uvm_reg class, which defines a single register entity, including operational attributes such as offset address, bit width, and read / write permissions; the bottom layer is characterized by the uvm_reg_field class, which describes the functional division of each segment of bits inside the register, and clarifies the start bit, end bit, access attributes, and default values. This structure has been fully solidified through simulation verification, constituting an authoritative expression of the chip design intent.

[0045] During the baremetal testing phase after chip tape-out, engineers rely on the Trace32 debugger for hardware-level debugging. This tool only accepts register model files in its proprietary PER (Peripheral Register Description) format. This format organizes the hierarchy using TREE syntax blocks, declares registers using LINE.LONG statements, and describes bit fields using BITFLD.LONG statements; these three elements are strictly nested and indispensable. Currently, engineers can only manually extract information from the UVM model item by item and then rewrite it according to the PER syntax rules. This process is prone to problems such as spelling errors, address calculation errors, bit field range reversals, and incorrect hierarchy assignments. The consequences are not limited to file loading failures; they can also lead to register misreads, bit field out-of-bounds writes, and even abnormal hardware states during debugging, severely slowing down the problem localization process.

[0046] In this process, the method adopted in this embodiment can be understood as a structure-aligned automated bridging mechanism. It first obtains a SystemVerilog format register model file that has passed front-end verification, which necessarily contains register groups described using the uvm_reg_block class, registers described using the uvm_reg class, and bit fields described using the uvm_reg_field class. These class names are themselves structure identifiers, independent of specific naming or comments, thus possessing strong parsing stability. Subsequently, the parsing operation strictly follows the syntactic boundaries and nesting relationships of these three types of structured objects, extracting their respective attribute information: for uvm_reg_block, extracting the module name, base address, and hierarchical affiliation; for uvm_reg, extracting the register name, module, offset address, and read / write permissions; for uvm_reg_field, extracting the bit field name, register, start bit, end bit, access attribute, and default value. These attributes are not isolated data points, but are naturally bound to the context of the corresponding class instance in the original code, thus ensuring accurate hierarchical relationships in the extraction results.

[0047] Next, the pre-defined syntax mapping rules are not empirical configuration tables, but rather a one-to-one correspondence established based on the essential characteristics of two modeling paradigms: uvm_reg_block, as a module-level container, has encapsulation and scope that perfectly match the hierarchical wrapping capability of TREE syntax blocks; uvm_reg, as an addressable operation unit, has its offset address and name information directly mapped to the address and identifier fields required by the LINE.LONG statement; uvm_reg_field, as a bit-level semantic unit, must have its start and end bits and functional meaning attached to its own register, perfectly matching the syntax constraint that the BITFLD.LONG statement must be placed below LINE.LONG. This mapping is not a simple keyword replacement, but rather involves synchronously injecting BASE statements to set the base address when generating TREE blocks, automatically associating the context of the TREE block when generating LINE.LONG, and strictly limiting the binding relationship between its indentation position and the parent register when generating BITFLD.LONG. The resulting Trace32 PER format register model file is no longer manually pieced together text, but a debugging resource that is naturally derived from the original UVM model structure and has complete syntactic validity and semantic consistency.

[0048] This method allows for the one-click reuse of register definitions that have passed front-end verification, eliminating any information bias caused by manual transcription. This makes them directly usable during the baremetal testing phase, reducing the manual coding work that previously took days to a matter of minutes, significantly shortening the test preparation cycle. Simultaneously, fixed mapping rules ensure that the generated PER file can be directly loaded by Trace32 without secondary verification, avoiding interruptions to the debugging process due to syntax errors. When the register design is iteratively updated, simply rerunning this method will output a fully synchronized new PER file, ensuring zero omissions and zero mismatches in the maintenance process. Furthermore, after importing into Trace32, engineers can intuitively expand the register tree structure and click on any bit field to read or modify its value in real time. Debugging operations are transformed from line-by-line command input to visual interaction, significantly improving the efficiency of troubleshooting during the baremetal phase.

[0049] As one implementation method, please refer to Figure 2 Prior to S102, the method further includes: S101 deploys the Python runtime environment, loads the Python conversion script, and configures the input and output paths of the conversion script. The input path points to the SystemVerilog format register model file to be converted, and the output path points to the Trace32 PER format register model file to be generated after conversion.

[0050] In practical applications, this operation unfolds in an executable manner, comprising three interrelated steps: deploying the Perl runtime environment, loading the conversion script, and configuring input / output paths. Deploying the Perl runtime environment involves installing and verifying the availability of the Perl interpreter on the target computer system, ensuring its version compatibility with the syntax features and regular expression processing capabilities called in the script. Loading the conversion script involves loading a pre-written Perl script file with complete parsing and conversion logic into the current runtime context, enabling the execution of keyword recognition rules, attribute extraction functions, syntax mapping logic, and error correction mechanisms defined in the script. Configuring input / output paths explicitly specifies the storage location of the objects to be processed and the generated results. Specifically, the input path points to one or more SystemVerilog format register model files that have passed front-end verification. These files typically have the ".sv" extension and contain complete uvm_reg_block module definitions, uvm_reg register instances, and uvm_reg_field bit field definitions. The output path points to the expected location of the PER format register model file required by the Trace32 debugging tool. The final generated file in this path has the extension ".per" and can be directly recognized and loaded by Trace32.

[0051] During this process, all path configurations are passed as strings to the script's runtime parameters or configuration files, without relying on hard coding, thus supporting flexible adaptation to different project directory structures. After the script starts, it reads the source file according to the configured input path, parses its content line by line, and writes the generated PER format syntax statements to the target file specified by the configured output path after completing all conversion logic. The entire process requires no manual intervention in the script's internal logic, nor does it require manual modification of paths or redirection of output during runtime. Only a one-time environment deployment and path setting are needed in the initial stage to support any number of subsequent repeated conversion tasks. This ensures the determinism and reproducibility of the conversion process and allows the same script to run consistently in different chip projects and different developer work environments, avoiding parsing failures or abnormal output due to environmental differences.

[0052] After the Python conversion script obtains the SystemVerilog format register model file, the method also includes: S103, Verify the SystemVerilog format register model file; the verification content includes at least: determining whether the SystemVerilog format register model file contains a complete uvm_reg_block module definition, uvm_reg register instance, and uvm_reg_field bit field definition; and determining whether the configuration of all register addresses, bit widths, permissions, and hierarchical relationships is complete.

[0053] In practical applications, this verification action occurs after obtaining the SystemVerilog format register model file and before formal parsing. Its purpose is to confirm that the input source file has complete modeling capabilities and can support the accurate execution of the subsequent three-layer mapping logic.

[0054] Specifically, the verification focuses on two interrelated aspects: First, it needs to be determined whether the file contains complete uvm_reg_block module definitions, uvm_reg register instances, and uvm_reg_field bit field definitions; these three structures form the skeleton of the UVM register model and are indispensable. The uvm_reg_block module definition encapsulates the register set and carries the base address and hierarchy; the uvm_reg register instance describes independently addressable operation units; and the uvm_reg_field bit field definition refines the functional division of each bit segment within the register. Second, it needs to further confirm whether the addresses, bit widths, read / write permissions, and hierarchy configurations of all registers are complete. These parameters are not optional comments but are key attributes that directly affect whether registers in Trace32 can be correctly located, read / written, and parsed. For example, if a register lacks an offset address definition, the subsequently generated LINE.LONG statement will be unable to fill in a valid address field; if a bit field does not declare a start and end bit, the corresponding BITFLD.LONG statement will lose its syntactic basis; if the hierarchy is missing, the nested structure within the TREE syntax block cannot be reconstructed.

[0055] During this process, the verification is completed using the script's built-in structure recognition mechanism. It does not rely on manual code reading but instead scans keywords and their context boundaries to determine if the three core objects exist and possess the necessary fields. Only when all the above elements are identified as existing and fully configured does the script proceed to the next parsing step; otherwise, execution is halted and missing items are indicated, preventing the generation of erroneous PER files due to input defects. This prevents uncontrollable output caused by invalid input and ensures the entire conversion process is based on a reliable, stable, and traceable model. This guarantees that the final generated Trace32 PER format register model file accurately reflects the chip design intent and meets the stringent requirements of baremetal testing for the accuracy and consistency of register operations.

[0056] As one implementation method, please refer to Figure 3 S104 includes: S1041, scan the SystemVerilog format register model file line by line, and identify the keywords uvm_reg_block, uvm_reg, and uvm_reg_field in the SystemVerilog format register model file through keyword matching technology.

[0057] S1042, in response to the keyword, extract and cache the corresponding attribute information; among them, for the uvm_reg_block keyword, the extracted attribute information includes module name, base address and hierarchical affiliation; for the uvm_reg keyword, the extracted attribute information includes register name, module, offset address and read / write permissions; for the uvm_reg_field keyword, the extracted attribute information includes bit name, register, start bit, end bit, access attribute and default value.

[0058] S1043, Filter invalid content; wherein, the invalid content includes at least comment content and blank lines.

[0059] Understandably, the script enters a deep analysis phase of the SystemVerilog source code upon startup. This phase reads the SV register model source code line by line, without relying on pre-compilation or abstract syntax tree construction. Instead, it uses lightweight keyword matching technology to accurately identify three core object declaration statements: "uvm_reg_block", "uvm_reg", and "uvm_reg_field". The identification process is not a simple string search, but rather a determination of whether a statement constitutes a valid class instance definition based on contextual boundaries. For example, "uvm_reg_block" must appear in a class declaration or instantiation statement and be followed by base address assignment or submodule mounting logic; "uvm_reg" must be within a "uvm_reg_block" scope and have offset addresses and permission settings; and "uvm_reg_field" must be attached to a "uvm_reg" instance and have explicitly defined start and end bits.

[0060] In response to the keyword recognition results, the script immediately extracts the corresponding attribute information and stores it in a structured cache: for each "uvm_reg_block", it extracts its module name, base address, and its hierarchical relationship; for each "uvm_reg", it extracts its register name, the module it belongs to, its offset address relative to the module's base address, and its read / write permission identifier; for each "uvm_reg_field", it extracts its bitname name, the register it belongs to, its start bit, end bit, access attribute, and reset default value. All extraction actions are strictly bound to the original code structure to ensure that attributes correspond one-to-one with their semantic carriers, avoiding cross-scope misreading or field mismatches.

[0061] During this process, the script synchronously performs filtering operations, automatically skipping comments and blank lines in the source code, excluding them from keyword matching and attribute extraction. This filtering mechanism does not simply delete text lines, but rather identifies comment start characters (such as " / / " or " / *") and whitespace sequences through preset syntax patterns, completing logical isolation before parsing. This ensures that only valid information actually involved in register modeling is retained in the cache. In this way, redundant data is avoided from interfering with subsequent mapping logic, and the entire parsing process is unaffected by code formatting style, comment density, or documentation. Even if a large number of explanatory comments are added when the same register model file is circulated between different teams, it does not affect the script's accurate identification and structured organization of its core modeling elements.

[0062] As one implementation, S106 includes: For each of the extracted register groups, a TREE syntax block in the PER format is generated to define the hierarchical container, and a BASE statement is configured in the TREE syntax block to set the base address of the register group; For each of the extracted registers, a corresponding LINE.LONG statement is generated within the TREE syntax block corresponding to the register group. The LINE.LONG statement contains at least the offset address and register name of the register. For each extracted bit field, a corresponding BITFLD.LONG statement is generated below the LINE.LONG statement corresponding to the register. The BITFLD.LONG statement contains at least the start bit, end bit, and bit field name of the bit field.

[0063] Furthermore, the converted Trace32 PER format syntax statements are subjected to error detection, and in response to the detected errors, the errors are automatically repaired to ensure that the final output PER format register model file is free of syntax errors; wherein, the error detection described in this application includes: Hierarchical indentation formatting: Based on the nested structure between the register group, the register, and the bit field, the hierarchical relationship between each element is automatically identified, and uniform indentation formatting is performed on the statements inside the TREE syntax block, so that the TREE syntax block, the LINE.LONG statement, and the BITFLD.LONG statement present a hierarchical indentation relationship corresponding to the nested structure in the PER format register model file; Address format standardization: The base address of the register group, the offset address of the register, and the position parameters of the bit field are uniformly converted into the hexadecimal format supported by the Trace32 debugging tool, and bit width padding and vertical alignment operations are performed on all address fields. Syntax element standardization: Perform operations to unify the case, symbol separation, and field spacing of the PER format syntax keywords, and standardize the quotation mark enclosed, comma separated, and comment symbols of the name string; Real-time syntax checking and automatic repair: Real-time detection of errors in the PER format syntax statements, including duplicate definitions, missing terminators, out-of-bounds addresses, reversed start and end bits of bit fields, mismatched levels, missing symbols, and abnormal spaces.

[0064] In practical applications, the script performs conversions strictly according to the three-level mapping rules based on the structured register information in the cache: for each uvm_reg_block, an independent and closed TREE syntax block is generated, which starts with TREE and ends with TREE.END, forming an expandable and foldable hierarchical container in Trace32; and a BASE statement is configured immediately after the block to fill in the base address value carried by uvm_reg_block, which serves as the unified reference origin for all register addressing under this module.

[0065] For each uvm_reg, the script maps its logical affiliation to a physical nesting location. Specifically, within the TREE block generated for the corresponding uvm_reg_block, a LINE.LONG statement is generated, accurately filling in the offset of the register relative to the module's base address and the register name. This allows Trace32 to locate the specific register based on this address and perform read / write operations. For each uvm_reg_field, the script strictly maintains its hierarchical relationship in the original UVM model, placing the generated BITFLD.LONG statement directly below the LINE.LONG statement of its corresponding uvm_reg, without crossing lines or skipping levels. The script also fully fills in the start bit, end bit, and bit name of the field, ensuring that Trace32 can correctly identify the boundaries and functional meaning of the bit segment during parsing.

[0066] In this process, syntax standardization is not an additional embellishment, but an integral part of the conversion process. Based on the inherent nested structure of the register model—that is, register groups contain registers, and registers contain bit fields—the script automatically identifies the hierarchical relationships between levels and applies uniform indentation to all statements within the TREE block accordingly: the TREE keyword is written at the top left, BASE statements are indented by two spaces, each LINE.LONG statement is indented by two spaces, and each BITFLD.LONG statement is further indented by two spaces. This naturally forms a visually clear and logically rigorous tree-like indentation hierarchy in the final generated PER file, allowing for unambiguous restoration of the original modeling structure whether viewed manually or analyzed by tools.

[0067] Furthermore, all numerical parameters involving addresses or locations, including the base address of uvm_reg_block, the offset address of uvm_reg, and the start and end bits of uvm_reg_field, are uniformly converted to hexadecimal format supported by the Trace32 debugging tool. During conversion, automatic padding to the standard display width is performed (e.g., 32-bit addresses are padded with 8 hexadecimal characters), a lowercase "0x" prefix is ​​uniformly used, and the column widths of all address fields are aligned to ensure neat alignment and easy comparison when arranged vertically in the PER file. The script also performs uniform case processing (converting all to uppercase), uniform symbol separation (e.g., adding a space after a comma, adding a space on both sides of an equal sign), and uniform field spacing for all PER keywords, including TREE, BASE, LINE.LONG, BITFLD.LONG, and TREE.END. It also automatically adds English double quotes to register names, bit names, and other string content, and uses semicolons to guide comments, avoiding Trace32 parsing failures or misjudgments due to loose formatting.

[0068] Simultaneously, the script initiates a real-time validation mechanism while generating syntax statements line by line, rather than waiting for all statements to be generated before performing an overall check. This mechanism can instantly identify and respond to various common error types: if a TREE block is missing a TREE.END terminator, it is automatically added to the end of the block; if a register address exceeds the range supported by Trace32 or goes out of bounds, the valid address is recalculated based on the original configuration context, and the corresponding BASE and LINE.LONG fields are updated; if the start bit of a bit field is greater than the end bit, the two values ​​are automatically swapped while keeping the bit field name and access attributes unchanged; if a BITFLD.LONG statement does not appear after its corresponding LINE.LONG statement, or if a LINE.LONG statement is not nested within a TREE block, the statement position is automatically adjusted according to the scope relationship in the original UVM code; it can also accurately locate and correct keyword spelling errors, missing necessary symbols (such as colons, commas, or quotation marks), extra spaces, or invisible control characters. All repairs are completed by backtracking the original cached data without changing the register function definition, only correcting the expression form. Therefore, the final output PER format register model file has out-of-the-box syntactic completeness and structural rigor, and can be directly loaded into the Trace32 tool for baremetal debugging without manual secondary editing.

[0069] As one implementation, S108 includes: S1081, automatically completes the file header configuration statements required by the Trace32 PER format, which must include at least the CONFIG and WIDTH configuration items.

[0070] S1082 verifies the register model file in Trace32 PER format; the verification includes at least checking for address conflicts, missing syntax, and hierarchical errors.

[0071] Specifically, after generating all the syntax statements, the script automatically adds the necessary file header configuration statements for the Trace32 debugging tool. These include at least two basic configuration items: CONFIG and WIDTH. CONFIG is used to declare the overall file parsing mode (such as byte order, address space type, etc.), while WIDTH is used to specify the register operation width (usually 32 bits). Together, they constitute the initial parsing context when Trace32 loads a file. The absence of either one will cause the tool to be unable to recognize the file structure or misjudge the register size.

[0072] Furthermore, the script iterates through the base address and offset address combinations of all registers, calculates the actual location of each register in the physical address space, and performs uniqueness checks on all results. If duplicate definitions, address overlaps, or out-of-bounds errors are found, the script automatically finds free and valid alternative addresses based on the register's module, design priority, and chip address space planning strategy, while preserving the original functional semantics. It then synchronously updates the offset fields in the corresponding BASE statement within the TREE block and the associated LINE.LONG statement. The script also rigorously compares the generated PER statement structure with the hierarchical relationships in the original SystemVerilog code. If a LINE.LONG statement is not nested within any TREE block, or a BITFLD.LONG statement exists independently of its associated LINE.LONG statement, it is considered a hierarchical error. The script automatically adjusts the statement positions and corrects indentation based on the original scope relationships in the UVM source code. Simultaneously, the script scans all register names and bitnames, automatically identifying spaces, Chinese characters, hyphens, periods, or other illegal symbols not supported by Trace32, and uniformly replacing them with underscores or removing them altogether.

[0073] After generating the Trace32 PER format register model file, the method also includes file output and tool import steps: the script outputs a register model file with the standard .per extension. Engineers only need to put the file into the directory specified by the Trace32 project and execute the load command in the Trace32 command line to complete the import of the register model. They can then directly perform register configuration, value reading, bit field debugging, status monitoring, and other operations in baremetal testing without having to modify the file content.

[0074] In summary, this application tailors three sets of one-to-one syntax mapping rules for the three-layer architecture of the UVM register model. Each layer has a unique PER syntax to match it, without mixing or omission, ensuring the structural integrity and information accuracy of the register model. The specific mapping rules are as follows: (1) Register group hierarchy mapping: In SystemVerilog, the uvm_reg_block class is used to encapsulate the module-level register set, which is used to divide the register groups of chip functional modules. It contains core information such as module name, base address, sub-level relationship, and internal register list, and is the top-level framework of the entire register model. This structure uniquely corresponds to the TREE syntax block in the Trace32 PER file. The TREE block is used as a hierarchy container, starting with the TREE keyword and ending with the TREE.END keyword. Sub-modules and registers can be nested within the block, completely replicating the module hierarchy and address space of uvm_reg_block, ensuring that the converted register grouping is clear and the hierarchy is distinct.

[0075] (2) Single Register Entity Mapping: In SystemVerilog, the uvm_reg class is used to define a single independent register, which includes parameters such as register name, relative offset address, bit width, read / write permissions, and reset value. It is the smallest unit of register operation. This structure uniquely corresponds to the LINE.LONG statement in the Trace32 PER file. The LINE.LONG statement is used to declare a single register, carrying the register offset address, name, and function remarks. It adapts to the 32-bit register addressing format of Trace32, ensuring accurate register address positioning and enabling normal read / write operations.

[0076] (3) Register bit field mapping: In SystemVerilog, the uvm_reg_field class is used to describe the bit fields inside the register. This is used to split the function of the register's bits and define the start and end positions, name, read and write attributes, enumeration values, and reset status of each bit field. This structure corresponds to the BITFLD.LONG syntax under the LINE.LONG statement. Each uvm_reg_field corresponds to a line of BITFLD.LONG statement, which is attached to the LINE.LONG statement of the register it belongs to. It fully preserves the start and end bits, functional meaning, and legal value range of the bit field, so that Trace32 can recognize and operate on each independent bit field.

[0077] Please see Figure 4This is an example of register model file conversion provided in this application. It should be noted that in the SystemVerilog file, class...uvm_reg_block defines a register group (module), the "..." part is the specific module name, default_map=create_map(...) creates an address mapping for this register group, and the parentheses usually contain information such as the base address and address width; endclass indicates the end of the definition of this register group.

[0078] `class...uvm_reg` defines a specific register, where "..." is the register name, `build()` is the function that performs initialization work such as register creation, address allocation, and bit field addition, and `endclass` indicates the end of this register definition.

[0079] `class...uvm_reg_field` defines a bit field, where "..." is the bit field name, `config(...)` configures the attributes of this bit field: width, start position, access permissions, reset value, etc., and `endclass` indicates the end of this bit field.

[0080] In the PER file, TREE "DDR_REG" indicates the creation of a top-level container (large module) named "DDR_REG", TREE "DDR0_REG" indicates the creation of a sub-level container "DDR0_REG" inside DDR_REG, and TREE "ddrsys_axu_reg_block" indicates the creation of a sub-level container inside DDR0_REG. The names correspond to the register group names in UVM. BASE ad:0x250000000 indicates that the base address of this level is set to 0x250000000.

[0081] The mapping relationship between SystemVerilog files and PER files is as follows: In the SystemVerilog file, `class ... uvm_reg_block` corresponds to `TREE "..."` in the PER file, indicating that the register bank corresponds to a `TREE` level block. In the SystemVerilog file, `default_map = create_map(..., base address, ...)` corresponds to `BASE ad: base address` in the PER file, indicating that the base address corresponds to the `BASE` statement. In the SystemVerilog file, `class ... uvm_reg` corresponds to `LINE.LONG offset address "register name"` in the PER file, indicating that the register corresponds to the `LINE.LONG` statement. In the SystemVerilog file, `class ... uvm_reg_field` corresponds to `bitfld.long start bit end bit "bit field name"` in the PER file, indicating that the bit field corresponds to the `BITFLD.LONG` statement (located below `LINE.LONG`).

[0082] Based on this, the method provided in this application has the following beneficial effects: 1. Achieve one-click reuse of register models to ensure complete information consistency: Directly reuse the SystemVerilog model that has passed front-end verification, eliminate information deviation caused by manual coding, ensure complete synchronization of register parameters between the front-end and back-end, and eliminate debugging errors.

[0083] 2. Significantly improve efficiency and reduce labor costs: The work of handwriting PER files, which used to take several days, can now be completed in just a few minutes, saving a lot of time on manual sorting and proofreading, and speeding up the baremetal test startup.

[0084] 3. Precise and error-free syntax with excellent compatibility: Fixed mapping rules ensure that the generated PER file fully conforms to Trace32 syntax, with no parsing errors, and can be loaded and used directly.

[0085] 4. Convenient post-maintenance: After register design iteration, simply rerun the script to quickly generate the updated PER file with zero synchronization error.

[0086] 5. Simplified debugging operations: After importing the model, Trace32 can visually display the register hierarchy and bit fields, supporting quick read and write operations and parameter configuration, greatly improving the ease of debugging baremetal.

[0087] Based on the above implementation method, please refer to Figure 5 This application also provides a register model file conversion device 200, which includes: Input module 210 is used to obtain a register model file in SystemVerilog format; wherein, the register model file in SystemVerilog format contains register groups described using the uvm_reg_block class, registers described using the uvm_reg class, and bit fields described using the uvm_reg_field class.

[0088] The parsing module 220 is used to parse the SystemVerilog format register model file and extract the attribute information of register groups, registers and bit fields based on the uvm_reg_block class, uvm_reg class and uvm_reg_field class respectively.

[0089] The conversion module 230 is used to convert the extracted attribute information into Trace32PER format syntax statements according to preset syntax mapping rules. The preset syntax mapping rules include: mapping the uvm_reg_block class to TREE syntax blocks, mapping the uvm_reg class to LINE.LONG statements, and mapping the uvm_reg_field class to BITFLD.LONG statements. Output module 240 is used to generate a register model file in Trace32 PER format based on the converted syntax statement.

[0090] Please see Figure 6 This application provides an electronic device 100, which includes at least one processor 101 and at least one memory 102. The processor 101 and the memory 102 are directly connected to each other, or communicate with each other through a communication interface 103, or are electrically connected through one or more communication buses or signal lines to realize data transmission or interaction. The memory 102 stores program instructions that can be executed by the processor 101. The processor 101 can call the program instructions to execute the program instructions to implement any of the register model file conversion methods provided by the above-described implementation methods.

[0091] The memory 102 may be, but is not limited to, random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), etc.

[0092] Processor 101 can be an integrated circuit chip with signal processing capabilities. Processor 101 can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0093] Understandable. Figure 6 The structure shown is for illustrative purposes only; the electronic device may also include components that are more advanced than those shown. Figure 6 The more or fewer components shown, or having the same Figure 6 The different configurations shown. Figure 6 The components shown can be implemented using hardware, software, or a combination thereof.

[0094] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

[0095] It will be apparent to those skilled in the art that this application is not limited to the details of the exemplary embodiments described above, and that this application can be implemented in other specific forms without departing from the spirit or essential characteristics of this application. Therefore, the embodiments should be considered illustrative and non-limiting in all respects, and the scope of this application is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of equivalents of the claims are intended to be included within this application. No reference numerals in the claims should be construed as limiting the scope of the claims.

Claims

1. A method for converting register model files, characterized in that, The register model file conversion method includes the following steps: Obtain a register model file in SystemVerilog format; wherein the register model file in SystemVerilog format contains register groups described using the uvm_reg_block class, registers described using the uvm_reg class, and bit fields described using the uvm_reg_field class; The SystemVerilog format register model file is parsed, and the attribute information of the register group, the register, and the bit field is extracted based on the uvm_reg_block class, the uvm_reg class, and the uvm_reg_field class, respectively. According to the preset syntax mapping rules, the extracted attribute information is converted into Trace32 PER format syntax statements. The preset syntax mapping rules include: mapping the uvm_reg_block class to TREE syntax blocks, mapping the uvm_reg class to LINE.LONG statements, and mapping the uvm_reg_field class to BITFLD.LONG statements. Based on the converted syntax statements, a register model file in Trace32 PER format is generated.

2. The register model file conversion method according to claim 1, characterized in that, After obtaining the SystemVerilog format register model file, the method further includes: The SystemVerilog format register model file is verified; the verification includes at least the following: Determine whether the SystemVerilog format register model file contains complete uvm_reg_block module definitions, uvm_reg register instances, and uvm_reg_field bit field definitions; determine whether all register address, bit width, permissions, and hierarchical relationship configurations are complete.

3. The register model file conversion method according to claim 1, characterized in that, Prior to the step of obtaining the SystemVerilog format register model file, the method further includes: Deploy the Python runtime environment, load the Python conversion script, and configure the input and output paths of the conversion script. The input path points to the SystemVerilog format register model file to be converted, and the output path points to the Trace32 PER format register model file to be generated after conversion.

4. The register model file conversion method according to claim 1, characterized in that, The steps of parsing the SystemVerilog format register model file and extracting the attribute information of the register group, the register, and the bit field based on the uvm_reg_block class, the uvm_reg class, and the uvm_reg_field class respectively include: The SystemVerilog format register model file is scanned line by line, and the keywords uvm_reg_block, uvm_reg, and uvm_reg_field in the SystemVerilog format register model file are identified by keyword matching technology. In response to the keyword, the corresponding attribute information is extracted and cached; wherein, for the uvm_reg_block keyword, the extracted attribute information includes module name, base address and hierarchical affiliation; for the uvm_reg keyword, the extracted attribute information includes register name, module, offset address and read / write permissions; for the uvm_reg_field keyword, the extracted attribute information includes bit name, register, start bit, end bit, access attribute and default value.

5. The register model file conversion method according to claim 4, characterized in that, The steps of extracting and caching the corresponding attribute information in response to the keyword include: Filter invalid content; wherein, the invalid content includes at least comments and blank lines.

6. The register model file conversion method according to claim 1, characterized in that, The steps for converting the extracted attribute information into Trace32 PER format syntax statements according to preset syntax mapping rules include: For each of the extracted register groups, a TREE syntax block in the PER format is generated to define the hierarchical container, and a BASE statement is configured in the TREE syntax block to set the base address of the register group; For each of the extracted registers, a corresponding LINE.LONG statement is generated within the TREE syntax block corresponding to the register group. The LINE.LONG statement contains at least the offset address and register name of the register. For each extracted bit field, a corresponding BITFLD.LONG statement is generated below the LINE.LONG statement corresponding to the register. The BITFLD.LONG statement contains at least the start bit, end bit, and bit field name of the bit field.

7. The register model file conversion method according to claim 6, characterized in that, The step of converting the extracted attribute information into Trace32 PER format syntax statements further includes: Error detection is performed on the converted Trace32 PER format syntax statements, and in response to the detected errors, the errors are automatically repaired to ensure that the final output PER format register model file is free of syntax errors; wherein, the error detection includes: Hierarchical indentation formatting: Based on the nested structure between the register group, the register, and the bit field, the hierarchical relationship between each element is automatically identified, and uniform indentation formatting is performed on the statements inside the TREE syntax block, so that the TREE syntax block, the LINE.LONG statement, and the BITFLD.LONG statement present a hierarchical indentation relationship corresponding to the nested structure in the PER format register model file; Address format standardization: The base address of the register group, the offset address of the register, and the position parameters of the bit field are uniformly converted into the hexadecimal format supported by the Trace32 debugging tool, and bit width padding and vertical alignment operations are performed on all address fields. Syntax element standardization: Perform uniform capitalization, uniform symbol separation, and uniform field spacing on PER format syntax keywords, and standardize the quotation mark enclosed, comma separated, and comment symbols of name strings; Real-time syntax checking and automatic repair: Real-time detection of errors in PER format syntax statements, including duplicate definitions, missing terminators, out-of-bounds addresses, reversed start and end bits of bit fields, mismatched levels, missing symbols, and abnormal spaces.

8. The register model file conversion method according to claim 1, characterized in that, After the step of generating the Trace32PER format register model file, the register model file conversion method further includes: Automatically complete the file header configuration statements required by the Trace32 PER format, which include at least the CONFIG and WIDTH configuration items; The register model file in Trace32 PER format is verified; wherein the verification includes at least checking for address conflicts, missing syntax, and hierarchical errors.

9. A register model file conversion device, characterized in that, The register model file conversion device includes: The input module is used to obtain a register model file in SystemVerilog format; wherein, the register model file in SystemVerilog format contains register groups described using the uvm_reg_block class, registers described using the uvm_reg class, and bit fields described using the uvm_reg_field class. The parsing module is used to parse the SystemVerilog format register model file and extract the attribute information of the register group, the register and the bit field based on the uvm_reg_block class, the uvm_reg class and the uvm_reg_field class respectively. The conversion module is used to convert the extracted attribute information into Trace32 PER format syntax statements according to preset syntax mapping rules, wherein the preset syntax mapping rules include: mapping the uvm_reg_block class to TREE syntax blocks, mapping the uvm_reg class to LINE.LONG statements, and mapping the uvm_reg_field class to BITFLD.LONG statements; The output module is used to generate a register model file in Trace32 PER format based on the converted syntax statement.

10. An electronic device, characterized in that, The electronic device includes: Memory; Processor; and A computer program stored in memory and executable on a processor, wherein the processor, when executing the program, implements the register model file conversion method as described in any one of claims 1 to 8.

Images