Code conversion method and device, electronic equipment and computer readable storage medium

Abstract

This application discloses a code conversion method, apparatus, electronic device, and computer-readable storage medium, relating to the field of digital integrated circuit design automation technology. The method includes: parsing the SystemVerilog code to be converted to obtain an initial abstract syntax tree; parsing the type mapping relationships of the initial abstract syntax tree and establishing a global type mapping table based on the parsing results; performing semantic equivalence transformations on the syntax nodes in the initial abstract syntax tree based on the global type mapping table to obtain an intermediate abstract syntax tree; optimizing the intermediate abstract syntax tree to obtain a target abstract syntax tree; and generating Verilog code corresponding to the SystemVerilog code based on the target abstract syntax tree. This application can generate standardized, high-quality Verilog code while ensuring functional consistency, and can improve the accuracy, reliability, and overall efficiency of code conversion.

Description

Technical Field

[0001] This application relates to the field of digital integrated circuit design automation technology, and more specifically, to a code conversion method, apparatus, electronic device, and computer-readable storage medium. Background Technology

[0002] With the continuous expansion of integrated circuit design scale and the increasing complexity of design, hardware description languages ​​are playing an increasingly prominent role in digital system development. Among them, SystemVerilog, due to its rich syntax features and excellent integrated design and verification capabilities, is widely used in complex chip and FPGA design flows. Verilog, as a mature and stable standard language, is still relied upon by many synthesis tools, back-end processes, and some design environments. Therefore, in practical engineering, how to achieve efficient and accurate conversion from SystemVerilog code to Verilog code has become a crucial link in ensuring a smooth design flow and is of great significance for improving design efficiency and tool compatibility.

[0003] However, existing technologies for SystemVerilog to Verilog code conversion typically rely on simple syntax substitution or single-stage processing mechanisms. These methods struggle to accurately handle complex syntactic structures and type dependencies, easily introducing semantic biases or missing information during the conversion process. Particularly when dealing with multi-module designs, composite type definitions, and cross-scope references, existing methods fail to establish unified type associations, leading to inconsistencies or errors in the conversion results. In other words, existing technologies suffer from insufficient semantic preservation, inconsistent type handling, low conversion accuracy, and low-quality resulting code during SystemVerilog to Verilog code conversion. Summary of the Invention

[0004] In the summary section of this application, the relevant technical solutions are described in general terms, and a series of simplified concepts are introduced. These concepts will be further elaborated in the detailed embodiments section. This summary section should not be construed as limiting the key or essential technical features of the claimed solutions, nor is it intended to limit the scope of protection of the claimed solutions.

[0005] The code conversion method, apparatus, electronic device, and computer-readable storage medium provided in this application can generate standardized, high-quality Verilog code while ensuring functional consistency by structuring and parsing SystemVerilog code into an abstract syntax tree, and combining global type mapping, semantic equivalence conversion, and subsequent optimization processing. This can improve the accuracy, reliability, and overall efficiency of code conversion.

[0006] In a first aspect, this application provides a code conversion method, comprising: parsing the SystemVerilog code to be converted to obtain an initial abstract syntax tree; parsing the type mapping relationship of the initial abstract syntax tree and establishing a global type mapping table based on the parsing result; performing semantic equivalence conversion on the syntax nodes in the initial abstract syntax tree based on the global type mapping table to obtain an intermediate abstract syntax tree; optimizing the intermediate abstract syntax tree to obtain a target abstract syntax tree; and generating Verilog code corresponding to the SystemVerilog code based on the target abstract syntax tree.

[0007] In some implementations, the step of parsing the SystemVerilog code to be transformed to obtain an initial abstract syntax tree includes: extracting lexical units from the SystemVerilog code to obtain a sequence of lexical units; and parsing the sequence of lexical units using a recursive descent analysis algorithm based on preset syntax rules to generate the initial abstract syntax tree with a structured representation.

[0008] In some implementations, the syntax nodes in the initial abstract syntax tree include package nodes, enumeration definition nodes, structure definition nodes, and type definition nodes; the step of parsing the type mapping relationship of the initial abstract syntax tree and establishing a global type mapping table based on the parsing result includes: parsing the package nodes in the initial abstract syntax tree to obtain a first mapping relationship between the package name information and package definition information in the package nodes, wherein the package definition information includes type aliases, enumeration definitions, structure definitions, local constants, and function definitions; parsing the enumeration definition nodes in the initial abstract syntax tree to obtain the enumeration name and enumeration definition information in the enumeration definition nodes. The second mapping relationship is as follows: the enumeration definition information includes a list of enumeration variant constants and an enumeration bit width determined based on the enumeration variants; the structure definition node in the initial abstract syntax tree is parsed to obtain the third mapping relationship between the structure name and the structure definition information in the structure definition node, wherein the structure definition information includes a list of fields and field types; the type definition node in the initial abstract syntax tree is parsed to obtain the fourth mapping relationship between the type alias and the original type in the type definition node; based on the first mapping relationship, the second mapping relationship, the third mapping relationship, and the fourth mapping relationship, the global type mapping table is established.

[0009] In some implementations, the step of performing semantic equivalence transformation on the syntax nodes in the initial abstract syntax tree based on the global type mapping table to obtain an intermediate abstract syntax tree includes: traversing the syntax nodes in the initial abstract syntax tree; and for each current syntax node traversed from the initial abstract syntax tree, performing semantic equivalence transformation on the syntax node based on the global type mapping table and according to the transformation method corresponding to the node type of the current syntax node to obtain the intermediate abstract syntax tree.

[0010] In some implementations, the step of performing semantic equivalence transformation on the syntax node based on the global type mapping table and according to the transformation method corresponding to the node type of the current syntax node to obtain the intermediate abstract syntax tree includes: if the current syntax node is a basic type declaration node, then determining the reference scenario information of the variable identifier corresponding to the basic type declaration node in the initial abstract syntax tree, and replacing the basic type declaration node with the corresponding net type declaration node or register type declaration node based on the reference scenario information; if the current syntax node is an enumeration-related node, then performing semantic equivalence transformation on the enumeration definition node, enumeration variable node, and enumeration reference node in the enumeration-related node based on the first mapping relationship in the global type mapping table; if the current syntax node is a structure-related node... Based on the second mapping relationship in the global type mapping table, semantic equivalence conversions are performed on the structure definition nodes, structure variable nodes, and structure magnitude nodes in the structure-related nodes, respectively. If the current syntax node is an interface-related node, semantic equivalence conversions are performed on the interface definition nodes, interface port nodes, interface method nodes, and interface instantiation nodes in the structure-related nodes, respectively, based on the global type mapping table. If the current syntax node is a type alias reference node, the type alias reference node is replaced with the corresponding basic type node based on the third mapping relationship in the global type mapping table. If the current syntax node is a package reference node, the package-defined elements referenced by the package reference node are inlined into the package reference node based on the fourth mapping relationship in the global type mapping table.

[0011] In some implementations, the step of performing semantic equivalence transformation on the syntax node based on the global type mapping table and according to the transformation method corresponding to the node type of the current syntax node to obtain the intermediate abstract syntax tree further includes: if the current syntax node is a timing logic block node, then in response to the timing block subtype attribute of the timing logic block node being an edge-sensitive attribute, retaining the edge-sensitive list in the timing logic block node and modifying the node type identifier to a general timing logic identifier; in response to the timing block subtype attribute being a level-sensitive attribute, replacing the sensitivity list of the timing logic block node with a preset fully sensitive identifier and modifying the node type identifier to the general timing logic identifier; if the current syntax node is a delay-continuous assignment node, obtaining the delay type feature of the delay information field in the delay-continuous assignment node, and based on the delay type feature, keeping the value or reference relationship of the delay information field unchanged, performing fixed-value delay conversion or parameterized variable delay conversion on the delay-continuous assignment node.

[0012] In some implementations, the step of performing semantic equivalence transformation on the syntax node based on the global type mapping table and according to the transformation method corresponding to the node type of the current syntax node to obtain the intermediate abstract syntax tree further includes: if the current syntax node is a port simplified declaration node, then deleting the preset type keyword in the port simplified declaration node and retaining the port direction information and port bit width information in the port simplified declaration node to generate a standard port declaration node; if the current syntax node is an indefinite-width constant node, then replacing the indefinite-width constant node with a constant value literal node with a definite bit width based on the assignment target bit width information of the indefinite-width constant node in the initial abstract syntax tree.

[0013] In some implementations, optimizing the intermediate abstract syntax tree to obtain the target abstract syntax tree includes: performing a first traversal operation, a second traversal operation, and a third traversal operation on the intermediate abstract syntax tree to obtain the target abstract syntax tree; wherein, if a constant expression node is detected in the intermediate abstract syntax tree based on the first traversal operation, the constant expression node is evaluated to obtain an evaluation result, and the constant expression node is replaced with a literal node corresponding to the evaluation result; if a conflicting identifier is detected based on the second traversal operation, the conflicting identifier is renamed according to a preset suffix generation rule; if a redundant node not referenced by other nodes is detected in the intermediate abstract syntax tree based on the third traversal operation, the redundant node is deleted.

[0014] In some implementations, generating Verilog code corresponding to the SystemVerilog code based on the target abstract syntax tree includes: traversing each syntax node in the target abstract syntax tree according to a preset node processing order, wherein the preset node processing order is, in order, module node, port node, declaration node, assignment node, and timing logic node; converting each syntax node traversed from the target abstract syntax tree into a code fragment conforming to a preset Verilog syntax specification based on a preset mapping relationship between node types and Verilog syntax templates; and performing format optimization processing on the code fragment to obtain the Verilog code.

[0015] In some implementations, the step of format optimization of the code snippets to obtain the Verilog code includes: generating a corresponding hierarchical indentation prefix for each code snippet based on a preset unit indentation amount and the hierarchical depth information of each syntax node in the target abstract syntax tree; inserting newline characters at preset operator positions for consecutive assignment expressions and conditional branch expressions in the code snippets that satisfy preset line break conditions; adding transformation source annotation information to the syntax nodes generated by semantic equivalence transformations in the code snippets, wherein the transformation source annotation information is used to indicate the syntax type of the SystemVerilog code corresponding to the syntax structure; and using the code snippets with the added hierarchical indentation prefix, the newline character insertion processing, and the added transformation source annotation information as the Verilog code.

[0016] In some embodiments, the code conversion method further includes: acquiring a first simulation output waveform corresponding to the SystemVerilog code and a second simulation output waveform corresponding to the Verilog code; performing a clock-cycle bit-level comparison on the first simulation output waveform and the second simulation output waveform to obtain a first verification result; performing expression conversion processing on the SystemVerilog code and the Verilog code respectively to obtain a first constraint solution expression corresponding to the SystemVerilog code and a second constraint solution expression corresponding to the Verilog code; performing logical equivalence proof on the first constraint solution expression and the second constraint solution expression to obtain a second verification result; and generating a functional equivalence verification report based on the first verification result and the second verification result, wherein the functional equivalence verification report is used to indicate whether the Verilog code meets preset equivalence conversion requirements.

[0017] Secondly, this application also provides a code conversion apparatus, comprising: a syntax parsing unit for parsing the SystemVerilog code to be converted to obtain an initial abstract syntax tree; a mapping establishment unit for parsing the type mapping relationship of the initial abstract syntax tree and establishing a global type mapping table based on the parsing result; an equivalence conversion unit for performing semantic equivalence conversion on the syntax nodes in the initial abstract syntax tree based on the global type mapping table to obtain an intermediate abstract syntax tree; a compatibility optimization unit for optimizing the intermediate abstract syntax tree to obtain a target abstract syntax tree; and a code generation unit for generating Verilog code corresponding to the SystemVerilog code based on the target abstract syntax tree.

[0018] Thirdly, this application also provides an electronic device, including: a memory and a processor, wherein the processor is configured to implement the code conversion method described in the first aspect when executing a computer program stored in the memory.

[0019] Fourthly, this application also provides a computer-readable storage medium storing computer-executable instructions or a computer program, wherein when the computer-executable instructions or the computer program are executed by a processor, they implement the steps of the code conversion method described in the first aspect.

[0020] Fifthly, this application also provides a computer program product, including a computer program or computer executable instructions, wherein when the computer program or computer executable instructions are executed by a processor, the steps of the code conversion method provided in the embodiments of this application are implemented.

[0021] In summary, this application parses the SystemVerilog code to be converted and generates an initial abstract syntax tree, transforming the original code from text to a structured syntactic representation. Based on this, subsequent processing no longer relies on simple string matching or text replacement, but rather on analysis and processing based on the syntactic structure. This avoids syntactic ambiguity and incomplete parsing, providing a unified and accurate data foundation for subsequent conversions, thus improving the correctness and stability of the overall conversion process. By parsing the type mapping relationships of the initial abstract syntax tree and establishing a global type mapping table, various data types form a unified semantic association across different scopes and modules. Based on this global mapping relationship, issues of ambiguous type dependencies or inconsistent cross-module references can be eliminated during the conversion process, ensuring the completeness and consistency of type processing. This helps improve adaptability in complex design scenarios and avoids problems caused by insufficient type parsing. The conversion errors are addressed by performing semantic equivalence conversion on the syntax nodes in the abstract syntax tree based on a global type mapping table. This ensures that the original SystemVerilog syntax structure can be systematically mapped to a semantically consistent target representation. The conversion is based on the core principle of "semantic equivalence," rather than simple syntax replacement, thus maintaining the original design logic and ensuring that the code before and after the conversion remains consistent at the functional level, thereby improving the reliability of the conversion results. By optimizing the intermediate abstract syntax tree and generating the target abstract syntax tree, and then generating the corresponding Verilog code from it, the output results achieve better standardization and conciseness while satisfying semantic consistency. This reduces redundant structures and improves code quality, making the generated Verilog code easier for subsequent tools to parse and apply. Under the premise of ensuring functional equivalence, a complete closed loop from structure parsing, semantic conversion to code generation can be achieved, which is beneficial to improving the efficiency and usability of code conversion. In summary, the code conversion method provided in this application generates standardized, high-quality Verilog code by structuring SystemVerilog code into an abstract syntax tree, and combines global type mapping, semantic equivalence conversion, and subsequent optimization processing. This improves the accuracy, reliability, and overall efficiency of code conversion. Attached Figure Description

[0022] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit this specification. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings: Figure 1 A flowchart illustrating a code conversion method provided in an embodiment of this application; Figure 2 This is a schematic diagram of the composition structure of a code conversion device provided in an embodiment of this application; Figure 3 This is a schematic diagram of the composition structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0023] The terms used in the specification, claims, and drawings of this application, such as "first," "second," "third," "fourth," etc. (if any), are used to distinguish similar objects and not to describe a specific order or sequence. Therefore, it is to be understood that these terms can be used interchangeably where appropriate, allowing the described embodiments to be used in different orders, unless specifically required by the illustrations or description. Furthermore, the terms "is" and "has," and any variations thereof, are intended to cover, non-exclusively, all possible constituent elements. For example, a process, method, system, product, or apparatus comprising several steps or units is not necessarily limited to the steps or units explicitly listed, but may also include other steps or units not explicitly listed, or steps or units inherent to the process, method, product, or apparatus.

[0024] In this application, a "module" or "unit" refers to a computer program or part of a computer program that has a specific function and works in conjunction with other related parts to achieve a predetermined goal. These modules or units can be implemented by software, hardware (e.g., processing circuitry or memory), or a combination of both. One or more processors or memories can implement one or more modules or units. Furthermore, each module or unit can also be part of a larger module or unit.

[0025] The technical solutions of this application will be described in detail below with reference to the accompanying drawings of the embodiments. It should be noted that the described embodiments are only a part of this application, and not all embodiments. In the following description, the "some embodiments" mentioned are only a subset of all possible embodiments, which may be the same or different subsets, and different embodiments can be combined with each other without conflict.

[0026] Figure 1 This is a flowchart illustrating a code conversion method provided in an embodiment of this application. For example, see [link to example]. Figure 1 The code conversion method provided in this application embodiment may include the following steps 101 to 105: Step 101: Perform syntax parsing on the SystemVerilog code to be transformed to obtain the initial abstract syntax tree.

[0027] In some examples, the SystemVerilog code to be converted is the original input object of the code conversion method in this application embodiment. Specifically, it refers to the synthesizable subset of SystemVerilog design code that follows the IEEE 1800 standard in the scenario of digital integrated circuit design automation. It only contains design syntax that can be mapped to actual hardware circuits, and removes non-synthesizable syntax content that is only used for simulation debugging and cannot generate hardware logic. It can accept digital chip and field-programmable gate array engineering design files imported by users. The file extension is uniformly "sv". It supports the import of single independent design files and the batch import of multi-file modular engineering files. For example, the front-end hardware design source code used to implement chip data registers, bus signal interaction, combinational and timing logic operations are all SystemVerilog code to be converted adapted to this application embodiment.

[0028] Syntax parsing is a fundamental processing step in the compilation and conversion of integrated circuit code. It refers to the automated process of performing layer-by-layer verification, semantic decomposition, and structural analysis on SystemVerilog design code in text form based on official standardized syntax rules. It is used to identify valid semantic units in the code, eliminate invalid and redundant characters, and complete the initial conversion of unstructured text code into structured semantic data. It can rely on a preset SystemVerilog syntax rule library and use a recursive descent analysis algorithm to complete the fully automated syntax parsing task. For example, the syntax parsing process can accurately identify core syntax structures in the design code such as module definitions, port declarations, internal variable assignments, and basic timing logic definitions, and accurately distinguish valid hardware design syntax from invalid auxiliary characters such as code comments, whitespace, and line breaks.

[0029] The initial abstract syntax tree (AST) is an abstract syntax tree generated after the syntax parsing process. It is a tree-shaped carrier that completely replicates the original SystemVerilog code's syntax structure, hierarchical relationships, and basic hardware semantics, without undergoing any subsequent processing such as type mapping, semantic conversion, or code optimization. It can be automatically constructed and generated by the parsing tool based on the code's hierarchical nesting relationships and semantic associations after the syntax parsing verification is passed. For example, the initial abstract syntax tree can fully carry various syntax nodes such as top-level modules, external ports, internal signal declarations, and basic logic assignments, strictly replicating the hierarchical structure and basic functional semantics of the original design code.

[0030] For example, the system can first read the user-imported SystemVerilog project design file, batch screen and filter all comments and whitespace characters in the source code to completely avoid invalid characters interfering with the accuracy of syntax parsing; then, it calls the preset syntax rule library to verify the syntax legality of the design code line by line and segment by segment. For syntax errors such as missing keywords and abnormal symbol matching, it outputs the precise error location and error reason in real time and terminates the parsing process; after confirming that the code syntax is fully compliant, the device decomposes the code into independent semantic units layer by layer and builds the hierarchical association and reference relationship between each semantic unit; finally, based on all the parsed semantic units, it constructs an initial abstract syntax tree that is structurally complete, semantically accurate, and without secondary processing.

[0031] By implementing step 101, the SystemVerilog code to be transformed is parsed and an initial abstract syntax tree is generated. The original code is transformed from an unstructured text form into a representation with clear hierarchical relationships and semantic structure. This allows subsequent processing to be based on syntactic units rather than character-level content, effectively avoiding syntactic ambiguity and incomplete parsing. It provides a unified and accurate data foundation for subsequent transformations, thereby improving the correctness and stability of the overall transformation process.

[0032] Step 102: Parse the type mapping relationship of the initial abstract syntax tree and establish a global type mapping table based on the parsing result.

[0033] In some examples, type mapping parsing involves a global traversal scan of the initial abstract syntax tree (API), identifying all type definition class syntax nodes within the tree, and extracting information such as attribute parameters, definition rules, hierarchical affiliation, and cross-node relationships for various custom types. This process only reads and parses data; it does not modify or replace the node structure or syntactic semantics of the API, and is considered a pre-processing data acquisition step. This step can rely on the pre-defined SystemVerilog synthesizable subset syntax standard to perform targeted traversal retrieval of the complete API, accurately filtering four core types of nodes: package definitions, enumeration definitions, structure definitions, and type alias definitions, and completing information parsing. For example, type mapping parsing can collect all variant names, corresponding constant values, and adapted hardware bit widths of enumeration structures, as well as all field names, basic field types, and bit width attributes contained in structure structures.

[0034] The global type mapping table is a structured data table used to centrally store and uniformly manage the correspondence between all custom types within the current overall design project. It can cover all type data in single-file designs and multi-file modular designs, and serves as a global data carrier throughout the overall code conversion process. This data table is used to eliminate local type identification biases, unify the type judgment standard for the entire project, and solve the problems of chaotic type identification and failure of cross-module type associations in traditional conversion schemes. It can classify, filter, validate, structure, and uniformly input all the original type data obtained from parsing the type mapping relationship to obtain the global type mapping table. For example, the global type mapping table can independently store the correspondence between package structure and functions, constants, and custom types within the package, and independently store the matching relationship between type aliases and SystemVerilog native basic types, which can be used for global calls and queries in subsequent processing flows.

[0035] For example, the first step is to perform package parsing; traverse the package nodes inside the initial abstract syntax tree, extract all semantic units contained in the package body such as Typedef (type alias node), EnumDef (enumeration definition node), StructDef (structure definition node), LocalParam (local constant node), and Function (custom function node), register all kinds of semantic units to the global type mapping table, and mark the corresponding package name. For custom functions in the package, extract the function operation logic completely, convert it into a function node that adapts to the Verilog standard, and completely preserve the function's input and output ports and operation logic; for various custom type definitions in the package, construct the binding mapping relationship between "package name + type name" and type parameter details; for example, for the typedef logic [7:0] byte_t type alias defined in package sv_pkg, establish the mapping relationship "sv_pkg::byte_t → WireType(8)", solve the technical pain points of traditional EDA tools being unable to parse cross-package type references and having weak adaptability to modular design. The second step involves parsing composite types. This involves traversing the enumeration definition nodes, structure definition nodes, and type definition nodes in the initial abstract syntax tree, collecting parameter information for various composite types in batches, and iteratively supplementing and improving the global type mapping table. For enumeration definition nodes, core parameters such as enumeration name, enumeration variant identifier, and custom enumeration type are extracted. Based on the number of enumeration variants, the minimum bit width adapted to hardware storage is automatically calculated, constructing a mapping relationship of "enumeration name - minimum bit width - enumeration variant constant list". For structure definition nodes, the structure name, all internal field names, and corresponding field data types are collected, generating a structure-specific field list and type mapping relationship. For type definition nodes, the correspondence between type aliases and native basic types is matched, completing the alias type mapping entry. For example, for the definition `typedef enum {A,B} enum_t`, the mapping relationship "enum_t → EnumDef(A=0,B=1, bit width 1)" is generated, improving upon the shortcomings of existing tools in terms of coarse parsing of composite types and incomplete parameter collection. The third step is to perform type dependency verification. A full traversal of all syntax nodes in the initial abstract syntax tree is performed to verify whether the custom types referenced by each node have been fully defined and included. If undefined package types, enumeration types, or other abnormal type references are detected, precise error messages are output immediately, and the code conversion process is terminated. If circular dependency issues such as nested structures are detected, corresponding warning messages are output, and compatibility optimization is performed, uniformly disassembling structures with circular dependencies into independent signal nodes and supplementing them with corresponding signal connection logic.After completing the preprocessing steps of full parsing and verification, the output is an initial abstract syntax tree with a global type mapping table, which is then transferred to the subsequent core transformation steps, completely solving the core problem that existing EDA tools cannot handle complex type dependencies and cross-module type association failures.

[0036] By implementing step 102, the initial abstract syntax tree is parsed for type mapping relationships and a global type mapping table is established. This enables unified management and association of type information in different scopes and modules, eliminating problems such as unclear type dependencies and inconsistent type references across modules. It ensures the consistency and integrity of type processing, thereby improving adaptability in complex design scenarios and reducing the conversion risks caused by insufficient type parsing.

[0037] Step 103: Based on the global type mapping table, perform semantic equivalence transformation on the syntax nodes in the initial abstract syntax tree to obtain the intermediate abstract syntax tree.

[0038] In some examples, semantic equivalence conversion, in the context of automated code conversion for digital integrated circuit design, strictly adheres to the principle of hardware circuit function fidelity. It involves transforming the non-standard SystemVerilog syntax structure specific to the initial abstract syntax tree into a node processing process that adapts to a general syntax structure compatible with the Verilog 2005 standard. This process only adapts the structure type and expression of the syntax nodes, without altering the hardware operation logic, signal relationships, or circuit behavior characteristics corresponding to the original code. For example, this process can use the type parameters stored in the global type mapping table to equivalently convert a SystemVerilog custom composite syntax structure into a general basic hardware syntax structure, ensuring complete consistency of circuit function before and after the conversion.

[0039] The intermediate abstract syntax tree (ISBN) is a transitional structured tree data carrier that has undergone complete semantic equivalence transformation of the initial abstract syntax tree but has not yet been optimized. This ISBN has removed all SystemVerilog-specific syntax nodes, and all syntax structures are compatible with the Verilog 2005 standard, while fully preserving all hardware semantics and circuit logic of the original design. Using a global type mapping table as a unified data benchmark, all differentiated syntax nodes within the initial ISBN can be traversed and identified, and corresponding equivalence transformation rules can be matched to complete node reconstruction, ultimately outputting the ISBN. For example, the ISBN no longer contains SystemVerilog-specific nodes such as enumerations, structures, and custom types; all have been replaced with signal declarations and logic assignment nodes that conform to general standards.

[0040] For example, the already constructed global type mapping table can be retrieved as the sole criterion to fully traverse all syntax nodes within the initial abstract syntax tree; for each SystemVerilog-specific syntax structure, the corresponding type parameters and definition rules in the mapping table are matched, and equivalent replacements and structural reconstructions are performed on each syntax node; the standardized transformation of all syntax nodes is continuously completed through iteration, unifying the syntax specifications and type standards of the entire tree; finally, an intermediate abstract syntax tree that is grammatically compliant, semantically accurate, and structurally complete is generated.

[0041] By implementing step 103, semantic equivalence transformation is performed on the syntax nodes in the abstract syntax tree based on the global type mapping table, so that various syntax structures in SystemVerilog can be systematically mapped to semantically consistent target representations. The transformation process focuses on semantic consistency rather than simple syntax replacement, which can avoid the generation of logical deviations, ensure that the code before and after the transformation remains consistent at the functional level, and improve the reliability and accuracy of the transformation results.

[0042] Step 104: Optimize the intermediate abstract syntax tree to obtain the target abstract syntax tree.

[0043] In some examples, optimization processing is a lossless structural regularization operation performed on the intermediate abstract syntax tree in the context of automated code conversion for digital integrated circuit design. This operation strictly follows the principle of hardware functional equivalence, and only uniformly corrects and simplifies redundant structures, non-standard identifiers, and unresolved constants within the syntax tree. It does not change the circuit operation logic, signal connection relationships, and timing behavior corresponding to the original SystemVerilog code. For example, optimization processing can perform regularization operations such as pre-computation evaluation of static constant expressions, conflict correction of global signal identifiers, and deletion of invalid syntax nodes that are not referenced.

[0044] The target abstract syntax tree (AST) is the standardized, lightweight structured tree data carrier generated after the intermediate abstract syntax tree has undergone all lossless optimization processing. This AST is fully compatible with the Verilog 2005 syntax standard, eliminating defects such as code redundancy, naming conflicts, and non-standard constant formats. It has a complete structure and pure logic, and can be directly used to drive the final code generation process. The semantically transformed intermediate abstract syntax tree can be used as the sole processing object, and a standardized post-optimization pipeline can be used to complete structural regularization, defect repair, and redundancy reduction, outputting a target abstract syntax tree that can be directly used for code generation. For example, all constants within the target abstract syntax tree are deterministic literals, all signal identifiers are globally unique, and there are no dangling invalid nodes or redundant assignment structures.

[0045] For example, the intermediate abstract syntax tree after semantic equivalence transformation is read, and multiple rounds of independent global traversal optimization operations are initiated; static evaluation of constant expressions, global identifier conflict detection and renaming, and screening and deletion of redundant and invalid nodes are performed in sequence; the hardware logic integrity of the syntax tree is verified throughout the process to ensure that all optimization operations are lossless regularization processing; finally, a target abstract syntax tree with a concise structure, standardized format, and logical fidelity is generated and fully adapted to commercial design processes is generated.

[0046] By implementing step 104, the intermediate abstract syntax tree is optimized, which can eliminate redundant structures, standardize the expression form, improve the simplicity and standardization of the syntax tree, make it more suitable for subsequent code generation needs, reduce the complexity of generated code, improve the overall conversion efficiency, and lay the foundation for generating high-quality target code.

[0047] Step 105: Generate Verilog code corresponding to the SystemVerilog code based on the target abstract syntax tree.

[0048] In some examples, the Verilog code corresponding to the SystemVerilog code is synthesizable hardware design code that fully complies with the Verilog 2005 official standard, and whose hardware circuit functions, signal interconnection logic, and timing behavior are completely consistent with the original SystemVerilog code to be converted. This code is compatible with various mainstream electronic design automation tools and can be directly used in logic synthesis, circuit simulation, and chip prototyping processes. Using the fully optimized and regularized target abstract syntax tree as the sole data template, through processing logic such as global node traversal, standard syntax template matching, and code fragment splicing and integration, the structured tree data can be automatically converted into standard text-format hardware design code, that is, the Verilog code corresponding to the SystemVerilog code.

[0049] For example, the system can read the solidified target abstract syntax tree, traverse all syntax nodes in an orderly manner according to the hierarchical specifications of integrated circuit hardware design, call the preset standard syntax mapping template, convert different types of tree-shaped syntax nodes into corresponding Verilog code snippets one by one and complete the splicing and integration, perform regularization and verification of the overall code structure to ensure that all output statements fully comply with the Verilog 2005 standard, and finally generate standardized Verilog hardware design code that is syntactically correct, functionally equivalent, and ready for commercial use.

[0050] By implementing step 105, the corresponding Verilog code is generated based on the target abstract syntax tree, so that the final output has good standardization and readability while maintaining semantic equivalence. This facilitates subsequent tools to parse, synthesize or verify, reduces the need for manual intervention, partially realizes the complete conversion process from syntax parsing to code generation, and improves the overall practicality and usability of the method.

[0051] In summary, this embodiment of the application performs syntax parsing on the SystemVerilog code to be converted and generates an initial abstract syntax tree, transforming the original code from text form into a structured syntactic representation. Based on this, subsequent processing no longer relies on simple string matching or text replacement, but rather on analysis and processing based on the syntactic structure. This avoids syntactic ambiguity and incomplete parsing, providing a unified and accurate data foundation for subsequent conversions, thus improving the correctness and stability of the overall conversion process. By parsing the type mapping relationships of the initial abstract syntax tree and establishing a global type mapping table, various data types form a unified semantic association across different scopes and modules. Based on this global mapping relationship, problems such as ambiguous type dependencies or inconsistent cross-module references can be eliminated during the conversion process, ensuring the completeness and consistency of type processing. This helps improve adaptability in complex design scenarios and avoids problems caused by insufficient type parsing. This approach avoids conversion errors. It performs semantic equivalence conversion on the syntax nodes in the abstract syntax tree based on a global type mapping table, ensuring that the original SystemVerilog syntax structure can be systematically mapped to a semantically consistent target representation. The conversion prioritizes semantic equivalence over simple syntax replacement, maintaining the original design logic and ensuring functional consistency between the code before and after conversion, thus improving the reliability of the conversion results. Furthermore, by optimizing the intermediate abstract syntax tree and generating the target abstract syntax tree, and then generating the corresponding Verilog code, the output achieves better standardization and conciseness while maintaining semantic consistency. This reduces redundant structures and improves code quality, making the generated Verilog code easier for subsequent tools to parse and apply. While ensuring functional equivalence, it achieves a complete closed loop from structure parsing and semantic conversion to code generation, improving the efficiency and usability of code conversion. In summary, the code conversion method provided in this application converts SystemVerilog code into an abstract syntax tree in a structured manner, and combines global type mapping, semantic equivalence conversion, and subsequent optimization processing to generate standardized, high-quality Verilog code while ensuring functional consistency. This improves the accuracy, reliability, and overall efficiency of code conversion.

[0052] In some embodiments, step 101 may include: extracting lexical units from SystemVerilog code to obtain a sequence of lexical units; and parsing the sequence of lexical units using a recursive descent analysis algorithm based on preset syntax rules to generate an initial abstract syntax tree for structured representation.

[0053] In some examples, lexical unit extraction is a pre-processing step that involves scanning the entire SystemVerilog design source code in text form, character by character, to identify the smallest code units with independent semantics and filter out invalid auxiliary characters. This process is only responsible for splitting and filtering the code content and does not perform syntax structure matching or logic parsing. This processing can automatically traverse the complete SystemVerilog design source code implementation based on a preset lexical rule library. For example, lexical unit extraction can accurately identify design keywords, custom identifiers, operators, numerical constants, and statement delimiters in the source code, while uniformly filtering comments, spaces, and newline characters in the source code.

[0054] A lexical unit sequence is a collection of all valid minimum semantic units arranged in the original writing order of the code after lexical unit extraction. This sequence completely preserves the writing order and basic semantics of the original code, removes all invalid and redundant characters, and ensures the accuracy and orderliness of subsequent syntax parsing. This sequence can be automatically generated by extracting lexical units from SystemVerilog source code and sorting them according to the order of the code. For example, after extracting and sorting a piece of port assignment design code, an ordered lexical unit sequence consisting of port keywords, signal names, assignment operators, and constant values ​​can be formed.

[0055] Recursive descent parsing is a top-down structured syntax analysis algorithm used to match the structural hierarchy of input data layer by layer according to standard syntax rules. It completes the identification and modeling of multi-level syntax structures by recursively calling the corresponding syntax subroutines. This algorithm can accurately adapt to the modular and nested hardware design syntax features of SystemVerilog. For example, recursive descent parsing can identify the top-level module structure, port declaration structure, internal signal definition structure, and nested logic operation structure within the module layer by layer.

[0056] The process of parsing a sequence of lexical units using a recursive descent analysis algorithm based on preset grammar rules to generate an initial abstract syntax tree with a structured representation is a complete parsing process. This process uses the preset grammar rules corresponding to the IEEE 1800 standard as the basis for judgment, calls the recursive descent analysis algorithm to traverse and match the complete sequence of lexical units, identifies the nesting and association relationships of various grammatical structures, and finally constructs a tree-structured data. This process realizes the transformation from a one-dimensional text semantic sequence to a two-dimensional hierarchical syntax tree, completely restoring the hierarchical architecture of the hardware design. For example, this process can match the module definitions, timing logic, and compositional assignments corresponding to the sequence of lexical units according to preset grammar rules, and build an initial abstract syntax tree with complete hierarchical relationships.

[0057] For example, the lexical analysis stage relies on the Flex tool to build a pre-defined lexical rule base, performing a character-by-character full-domain scan of the SystemVerilog design source code. This breaks down the unstructured source code text into the smallest lexical units with independent semantics, covering keywords (logic, enum, struct, interface, always_ff, etc.), custom identifiers (variable names, module names, enumeration values, etc.), operators (+, -, &, |, etc.), numeric and string constants, and statement separators (;, (), {}, etc.). This stage uniformly filters out single-line comments ( / / ), multi-line comments ( / *...* / ), and all invalid auxiliary characters such as spaces, newlines, and tabs, avoiding irrelevant content from interfering with the accuracy of subsequent syntax parsing. Simultaneously, it performs standardized preprocessing, converting numeric constants with varying formats to the built-in standard format and normalizing the lowercase of custom keywords with inconsistent capitalization, comprehensively ensuring the consistency and accuracy of subsequent syntax parsing. Compared to the limitations of existing technologies that only support simulation-type syntax parsing, the embodiments of this application can fully cover the synthesizable subset of SystemVerilog, achieving full and complete lexical analysis, and finally outputting a standardized ordered sequence of lexical units as the core input data for subsequent syntax analysis processes. In the syntax analysis stage, a preset syntax rule library adapted to the IEEE 1800 (SystemVerilog) official standard is constructed using the Bison tool. It receives the standardized sequence of lexical units output by the lexical analysis, and combines it with a recursive descent analysis algorithm to complete the full-domain structured parsing, generating an initial abstract syntax tree. The initial abstract syntax tree is a structured tree-like data carrier of the SystemVerilog source code. Each syntax node corresponds to a unique and independent hardware semantic unit. Core syntax node types include Module, Port, Decl, Assign, Always, EnumDef, StructDef, Interface, Package, Identifier, and Literal. During the parsing process, the lexical unit sequence and standard grammar rules are recursively matched from top to bottom to generate corresponding grammar nodes, and the hierarchical nesting, subordinate and related relationships between the nodes are accurately established. For example, module nodes are associated with subordinate port nodes and assignment nodes, and structure nodes are associated with subordinate field nodes.If the parsing process detects syntax errors such as missing keywords or mismatched brackets, it will accurately output the error location and cause, and terminate the current code conversion process. If all syntax checks are compliant, it will output a complete, hierarchical, and semantically accurate original initial abstract syntax tree, which will then be transferred to the subsequent AST semantic conversion process. This effectively solves the technical defects of traditional EDA tools, such as incomplete syntax parsing coverage and omission of complex syntax recognition.

[0058] Through the implementation of the above embodiments, lexical units are extracted first, and then an initial abstract syntax tree is generated based on preset syntax rules using a recursive descent analysis algorithm. This enables SystemVerilog code to be accurately parsed into a structured syntax representation, avoiding parsing errors and ambiguities that are prone to occur in complex syntax scenarios using traditional text matching methods. It also provides a high-precision input foundation for subsequent type mapping and semantic conversion, improving the reliability and stability of the overall conversion process.

[0059] In some embodiments, the syntax nodes in the aforementioned initial abstract syntax tree may include package nodes, enumeration definition nodes, structure definition nodes, and type definition nodes; the aforementioned step 102 may include: parsing the package nodes in the initial abstract syntax tree to obtain a first mapping relationship between package name information and package definition information in the package nodes, wherein the package definition information may include type aliases, enumeration definitions, structure definitions, local constants, and function definitions; parsing the enumeration definition nodes in the initial abstract syntax tree to obtain a second mapping relationship between enumeration names and enumeration definition information in the enumeration definition nodes, wherein the enumeration definition information may include a list of enumeration variant constants and an enumeration bit width determined based on the enumeration variants; parsing the structure definition nodes in the initial abstract syntax tree to obtain a third mapping relationship between structure names and structure definition information in the structure definition nodes, wherein the structure definition information may include a list of fields and field types; parsing the type definition nodes in the initial abstract syntax tree to obtain a fourth mapping relationship between type aliases and primitive types in the type definition nodes; and establishing a global type mapping table based on the first, second, third, and fourth mapping relationships.

[0060] In some examples, a package node is a modular syntax node in the initial abstract syntax tree used to encapsulate various custom types, constant parameters, and custom functions. It is a top-level syntax structure specific to SystemVerilog, used to achieve type reuse and modular management of design code. Package nodes can be obtained by performing a full traversal search of the initial abstract syntax tree and filtering out the top-level syntax units belonging to the package definition structure. For example, in digital integrated circuit bus design projects, the modular structure used to uniformly encapsulate bus parameters, signal types, and operation functions is the package node identified by the initial abstract syntax tree.

[0061] Enumeration definition nodes are dedicated syntax nodes in the initial abstract syntax tree used to define enumeration data types. They are used to define discrete state parameters with custom naming conventions, improving code readability. They belong to SystemVerilog composite type definition nodes. The initial abstract syntax tree can be traversed to accurately match the tree node units corresponding to the enumeration structure definition statements to obtain enumeration definition nodes. For example, the syntax nodes corresponding to the state enumeration structures used to define the chip's working state and transmission state are all enumeration definition nodes.

[0062] Structure definition nodes are composite syntax nodes in the initial abstract syntax tree used to integrate multiple sets of signals with different bit widths and functions. They can encapsulate multiple independent signals into a whole data structure and are often used in data message and bus data encapsulation scenarios. Structure definition nodes can be obtained by retrieving the structured node units corresponding to all structure structures in the initial abstract syntax tree. For example, the syntax node corresponding to the message structure used to encapsulate data validity flags, data content, and data check bits is a structure definition node.

[0063] Type definition nodes are syntax nodes in the initial abstract syntax tree used to create custom type aliases. They can rename and define the system's native basic data types or composite data types to adapt to the standardized type calling requirements of different modules. Type definition nodes can be obtained by traversing and identifying all the node units corresponding to the type alias definition statements within the initial abstract syntax tree. For example, the syntax nodes corresponding to the custom alias definitions of 8-bit data types and 16-bit address types are all type definition nodes.

[0064] The first mapping relationship between the packet name information and the packet definition information in the packet node is based on the unique identifier of the packet as an index, corresponding to the data table relationship of all defined resources within the packet. This allows for accurate indexing of all custom resources within the packet by the packet name. The mapping relationship can be automatically generated by parsing the top-level identifier of a single packet node and all its child node resources, binding the index and resource data. For example, by using the packet name of the bus configuration packet, the defined bus data types, status constants, and verification functions within the packet can be indexed; this correspondence constitutes the first mapping relationship. Type aliases, enumeration definitions, structure definitions, local constants, and function definitions are all synthesizable design resources that can be encapsulated and stored within the packet node. Among them, type aliases are user-defined data type identifiers, enumeration definitions are encapsulated status enumeration structures within the packet, structure definitions are encapsulated data composite structures within the packet, local constants are fixed hardware parameter values, and function definitions are combinational logic functions used for hardware operations. For example, the message type, device status enumeration, message structure, baud rate constant, and data verification function encapsulated within the bus design packet correspond to the above five types of packet definition information.

[0065] The second mapping relationship between enumeration names and enumeration definition information in the enumeration definition node uses the custom name of the enumeration structure as an index to correspond to the data mapping relationship of all attribute parameters of the enumeration structure, which is used to unify the identification standard of global enumeration types. It can parse the top-level identifier of the enumeration definition and all its subordinate enumeration attribute child nodes to complete the index and parameter binding and generate this mapping relationship. For example, using the device working state enumeration name as an index, one can query the idle state, running state, error state, and corresponding hardware bit width parameters contained in the enumeration; this correspondence is the second mapping relationship. The enumeration variant constant list and the enumeration bit width determined based on the enumeration variants are the main definition parameters of the enumeration structure. The enumeration variant constant list is a collection of all custom state names and corresponding constant values ​​within the enumeration structure, used to represent the logical values ​​corresponding to different hardware states. The enumeration bit width is the minimum hardware storage bit width calculated based on the total number of enumeration variants, used to adapt to the hardware register storage specifications. For example, an enumeration structure containing three device states has a variant constant list containing three state constants, and the calculated minimum enumeration bit width is two bits.

[0066] The third mapping relationship between the structure name and structure definition information in the structure definition node is a data mapping relationship that associates all field attributes within the structure with the custom structure name as an index, enabling unified retrieval of global structure parameters. It can parse the top-level structure identifier and all its subordinate field definition child nodes to complete the index binding and generate this mapping relationship. For example, using the data packet structure name as an index, all parameters of the valid signals, data signals, and check signals contained within the structure can be retrieved; this corresponding association is the third mapping relationship. The field list and field types are the main components of the structure definition. The field list is the set of names of all independent signals encapsulated within the structure, and the field type is the hardware data type and bit width parameter corresponding to each independent signal. For example, the data validity field, data content field, and check field within the packet structure constitute the field list, and the corresponding one-bit Boolean type and eight-bit data type are the corresponding field types.

[0067] The fourth mapping relationship between type aliases and primitive types in the type definition node is an index that corresponds to the mapping relationship of SystemVerilog native basic data types or composite data types. It is used to eliminate type recognition errors caused by custom aliases. This mapping relationship can be generated by parsing the alias identifier of the type definition node and the bound primitive data type. For example, the corresponding binding relationship between the native logical data type corresponding to the custom eight-bit data alias is the fourth mapping relationship.

[0068] The process of establishing a global type mapping table based on the first, second, third, and fourth mapping relationships is an integrated process that summarizes all mapping data of modular package resources, enumeration structures, structure structures, and type aliases, performs unified organization, categorized storage, and global indexing, and constructs a standardized type data table covering the entire human-computer interaction design document. This process can unify the type resolution standard of the entire design document, eliminate local resolution deviations, and automatically summarize four independent mapping data and complete structured encapsulation and storage. For example, this process can uniformly enter the correspondence of all package resources, state enumerations, data structures, and custom types in the project into the data table for unified use in subsequent global syntax conversion.

[0069] For example, the initial abstract syntax tree is traversed after loading, and all package nodes, enumeration definition nodes, structure definition nodes, and type definition nodes are retrieved and identified one by one. For each type of syntax node, hierarchical parsing is performed independently to accurately extract the top-level identifier and all internal sub-resource information, generating four independent mapping relationships. All mapping data is validated for compliance, invalid mapping data with missing definitions is removed, and the data storage format is unified. The validated four types of mapping data are integrated and categorized, and a unified global search index is set. Finally, a global type mapping table that covers the entire design project, has unified type standards, and can be called globally is constructed.

[0070] Through the implementation of the above embodiments, multi-dimensional mapping relationships are established for key syntax nodes such as packages, enumerations, structures, and type definitions, and a unified global type mapping table is constructed. This enables centralized management and unified parsing of type information scattered across different modules and scopes, effectively solving the problems of inconsistent cross-module type references and difficult type dependency parsing in complex designs, improving the consistency and integrity of type processing, and providing a basic guarantee for high-precision semantic conversion.

[0071] In some embodiments, step 103 may include: traversing the syntax nodes in the initial abstract syntax tree; for each current syntax node traversed from the initial abstract syntax tree, performing a semantic equivalence transformation on the syntax node based on the global type mapping table and according to the transformation method corresponding to the node type of the current syntax node, to obtain an intermediate abstract syntax tree.

[0072] In some examples, the process of traversing the syntax nodes in the initial abstract syntax tree is to perform a full-domain, full-coverage structured search scan of the complete initial abstract syntax tree, accessing all levels and types of syntax units within the syntax tree from top to bottom, and fully including all synthesizable syntax nodes in the design project; for example, this traversal process can fully retrieve all structured units such as module definition nodes, type definition nodes, signal declaration nodes, and logical assignment nodes in the initial abstract syntax tree.

[0073] The current syntax node is a single, independent syntax unit that is precisely located and awaits semantic transformation processing in a single traversal loop. It is the smallest processing object for semantic equivalence transformation operations. All current syntax nodes captured during the traversal process originate from the original initial abstract syntax tree, fully preserving the original design's syntax attributes and hardware semantics. For example, basic type declaration nodes, custom type definition nodes, and module internal logic nodes captured in a single traversal iteration all belong to the current syntax node corresponding to a single loop.

[0074] Based on the global type mapping table, the process of semantically converting syntax nodes according to the conversion method corresponding to the node type of the current syntax node to obtain an intermediate abstract syntax tree uses the pre-built global type mapping table as a unified judgment benchmark to identify the structural attributes and type affiliation of the current syntax node, match the node's exclusive preset standardized conversion rules, and complete the syntactic structural equivalence reconstruction and type adaptation for a single syntax node. Under the premise of maintaining the hardware circuit function, signal correlation and timing behavior unchanged throughout the process, the standardized conversion is completed for all syntax nodes one by one, and finally the reconstructed data is aggregated to generate a transitional syntax tree adapted to the Verilog 2005 standard. For example, this process can use the custom type parameters stored in the global type mapping table to match the corresponding conversion rules and rewrite the custom type nodes exclusive to SystemVerilog into universally recognizable standard syntax nodes to complete the semantic equivalence adaptation of a single node.

[0075] For example, a depth-first traversal program can be started first to perform a full-domain, layer-by-layer scan of the complete initial abstract syntax tree, continuously capturing independent syntax nodes at each level; for each captured syntax node, the global type mapping table is immediately retrieved to verify the type definition and attribute parameters of the node; according to the node's preset classification rules, the corresponding standardized conversion strategy is matched to independently complete the semantic equivalence reconstruction and syntax adaptation of a single node; the process is continuously iterated and looped to traverse and cover all syntax units of the entire tree, completing the standardized conversion of all nodes; and all rewritten compliant syntax nodes are integrated to reconstruct an intermediate abstract syntax tree with a complete structure, standard syntax, and lossless semantics.

[0076] By implementing the above embodiments, the abstract syntax tree is traversed, and the corresponding conversion method is called for different types of syntax nodes, realizing a systematic semantic equivalence conversion based on node type. This transforms the conversion process from indiscriminate processing to refined processing, avoiding semantic deviation problems caused by uniform rules, ensuring that all types of syntax structures can be accurately converted, and improving the overall conversion accuracy and adaptability.

[0077] In some embodiments, the aforementioned semantic equivalence conversion of syntax nodes based on the global type mapping table and the conversion method corresponding to the node type of the current syntax node to obtain an intermediate abstract syntax tree may include: if the current syntax node is a basic type declaration node, then determining the reference scenario information of the variable identifier corresponding to the basic type declaration node in the initial abstract syntax tree, and replacing the basic type declaration node with the corresponding net type declaration node or register type declaration node based on the reference scenario information; if the current syntax node is an enumeration-related node, then performing semantic equivalence conversion on the enumeration definition node, enumeration variable node, and enumeration reference node in the enumeration-related node based on the first mapping relationship in the global type mapping table; if the current syntax node is a structure-related node, ... Based on the second mapping relationship in the global type mapping table, semantic equivalence conversions are performed on the structure definition nodes, structure variable nodes, and structure magnitude nodes in the structure-related nodes, respectively. If the current syntax node is an interface-related node, semantic equivalence conversions are performed on the interface definition nodes, interface port nodes, interface method nodes, and interface instantiation nodes in the structure-related nodes, respectively, based on the global type mapping table. If the current syntax node is a type alias reference node, the type alias reference node is replaced with the corresponding basic type node based on the third mapping relationship in the global type mapping table. If the current syntax node is a package reference node, the package-defined elements referenced by the package reference node are inlined into the package reference node based on the fourth mapping relationship in the global type mapping table.

[0078] In some examples, basic type declaration nodes are syntactic units within the initial abstract syntax tree used to declare SystemVerilog-specific basic data types. They are used to define basic signal objects in hardware design and are the most fundamental signal definition structures in digital integrated circuit design. Basic type declaration nodes can be obtained by traversing the initial abstract syntax tree and filtering out signal declaration syntactic units containing SystemVerilog-specific basic types such as logic types, bit types, and byte types. For example, logic type declaration units used to define single-bit signals and eight-bit bus signals in chip timing logic design are all basic type declaration nodes.

[0079] Reference scenario information refers to the custom variable identifiers corresponding to the basic type declaration nodes. It represents the global call and mounting scenario characteristics in the overall initial abstract syntax tree, and is used to characterize whether a signal belongs to combinational logic or sequential logic, serving as the basis for determining the signal's hardware attributes. The global syntax tree can be traversed and searched to collect the mounting location, participating logic structure, and assignment method of the corresponding variable identifiers, and then the reference scenario information is generated. For example, the scenario information of a variable mounted on a module input port and participating in continuous assignment operations, as well as the scenario information of a variable mounted inside a sequential logic block and participating in clock-triggered assignment, all belong to the reference scenario information corresponding to the variable.

[0080] The process of replacing basic type declaration nodes with corresponding net type declaration nodes or register type declaration nodes based on reference scenario information is a refined conversion process that abandons the traditional fixed type replacement strategy. It determines the signal hardware attributes based on the global reference scenario of the variable and adaptively replaces the SystemVerilog-specific basic type syntax structure with net type or register type syntax nodes supported by the Verilog 2005 standard. For example, logical type variables used for port input and combination assignment are replaced with net type declaration nodes, and logical type variables used for clock timing registers are replaced with register type declaration nodes.

[0081] Enumeration-related nodes are a collection of all syntactic units associated with enumeration-defined types within the initial abstract syntax tree, covering the entire syntactic structure of enumeration definition, variable declaration, and logical reference. The initial abstract syntax tree can be searched across the entire domain to filter all definition nodes, variable mounting nodes, and logical operation reference nodes belonging to the enumeration structure to obtain enumeration-related nodes. For example, the chip working state definition structure, state variable declaration structure, and state reference structure in conditional statements together form a complete set of enumeration-related nodes.

[0082] Based on the first mapping relationship in the global type mapping table, the process of semantically converting the enumeration definition nodes, enumeration variable nodes, and enumeration reference nodes in the enumeration-related nodes is based on pre-stored package type mapping data. It unifies the variant constants, bit-width parameters, and definition attributes of the enumeration structure, and completes the overall conversion process of enumeration structure definition rewriting, enumeration variable type replacement, and enumeration logical reference replacement in layers. For example, a custom enumeration definition structure can be converted into a local constant definition structure, and all enumeration variables and enumeration judgment statements in the code can be synchronously replaced with standard constant logical structures.

[0083] Structure-related nodes are collections of all syntax units generated based on custom structure types within the initial abstract syntax tree. These include syntax units such as structure definitions, variable instantiation, overall structure assignments, and field assignments. Structure-related nodes can be obtained by traversing the initial abstract syntax tree and filtering all structure definitions, structure variables, and structure assignment syntax units. For example, the syntax nodes corresponding to data message definition structures, message signal instance variables, and overall message assignment statements all belong to structure-related nodes.

[0084] Based on the second mapping relationship in the global type mapping table, the process of semantically converting the structure definition node, structure variable node, and structure assignment node in the structure-related nodes is carried out by relying on the structure field attributes, field widths, and field type data stored in the global type mapping table. This process completes the structure unregistration, structure variable splitting, and overall structure assignment decomposition step by step. For example, the overall message structure variable can be split into independent valid signals and data signals, and the overall structure assignment statement can be decomposed into multiple independent field assignment statements.

[0085] Interface-related nodes are a set of dedicated syntax units within the initial abstract syntax tree used to implement module interconnection and bus interaction. They encapsulate bus signals, port directions, and interaction logic, and form the structure for modular interconnection in SystemVerilog. Interface-related nodes can be obtained by retrieving the syntax units corresponding to interface definitions, port mounting, method definitions, and module instantiation within the initial abstract syntax tree. For example, the syntax structures corresponding to bus interaction interface definitions, module interface port mounting, interface read / write methods, and top-level interface instantiation all belong to interface-related nodes.

[0086] Based on the global type mapping table, the process of semantically converting the interface definition nodes, interface port nodes, interface method nodes, and interface instantiation nodes in the interface-related nodes is carried out layer by layer. This process relies on the interface signal directions, port definitions, and logical attributes stored in the global type mapping table to complete the interface structure expansion, port direction inheritance, interface method inlining, and instance connection reconstruction. For example, the overall bus interface structure can be expanded into independent module ports, and the internal read and write logic of the interface can be inlined to the corresponding module to complete the standardized adaptation of the interface logic.

[0087] Type alias reference nodes are syntactic units that call custom type aliases within the initial abstract syntax tree. They are type reference structures generated by users after secondary encapsulation based on native data types and are widely used in standardized engineering type reuse scenarios. Type alias reference nodes can be obtained by traversing the initial abstract syntax tree and filtering all variable declarations and type reference syntax units that call custom type aliases. For example, reference syntax nodes for custom 8-bit data types and 16-bit address types that are reused in many places in the project are all type alias reference nodes.

[0088] The process of replacing type alias reference nodes with corresponding base type nodes based on the third mapping relationship in the global type mapping table relies on the correspondence between aliases and native types stored in the global type mapping table to remove the encapsulation of custom types and restore the secondary encapsulated alias types to the SystemVerilog native base types, thus eliminating the type identification ambiguity caused by custom aliases. For example, custom eight-bit bus data alias types can be uniformly restored to standard eight-bit logical data base type nodes.

[0089] Package reference nodes are syntactic units within the initial abstract syntax tree used for external calls to package resources. They are used for cross-module calls to the types, constants, and functions encapsulated within a package and are an important reference structure for modular design. Package reference nodes can be obtained by retrieving syntactic units within the initial abstract syntax tree that contain package imports and package resource calls. For example, a syntactic node that calls constants and data types within the bus configuration package across modules is a package reference node.

[0090] Based on the fourth mapping relationship in the global type map, the process of inlining the package-defined elements referenced by the package reference node into the package reference node relies on the package resource mapping data stored in the global type map. This process directly embeds the package-defined types, constants, and function resources called externally into the current referencing module, eliminating the conversion process of external package dependencies and adapting to the Verilog 2005 syntax specification without a package structure. For example, the baud rate constants and check functions in the external bus configuration package can be directly inlined into the top-level design module, replacing the original package reference call structure.

[0091] For example, the process involves traversing and capturing all syntax nodes within the initial abstract syntax tree, and accurately identifying the structural category of each current syntax node. For different categories of syntax nodes, the mapping parameters corresponding to the global type mapping table are retrieved, and standardized conversion rules specific to each type of node are matched. Fine-grained semantic equivalence replacement and structural reconstruction are performed on basic types, enumerations, structures, interfaces, type aliases, and package reference nodes one by one, fully preserving the original hardware signal attributes and interaction logic. During the conversion process, the node relationships are continuously verified to avoid cross-node logical omissions and semantic offsets. After completing the targeted conversion of all categories of syntax nodes, all standardized syntax units are uniformly integrated to finally generate a grammatically compliant and logically complete intermediate abstract syntax tree.

[0092] For example, the conversion of basic type declaration nodes is used to achieve semantic equivalence adaptation from SystemVerilog-specific basic types to standard Verilog types, and can complete the precise conversion of logic, bit, and byte types to wire and reg types. The basic data types such as logic, bit, and byte provided by SystemVerilog make up for the shortcomings of traditional Verilog type definitions being vague and having low attribute distinguishability, and can accurately define hardware signal attributes. However, the corresponding solutions of existing EDA tools generally adopt a fixed type mapping strategy, which is very easy to cause circuit logic deviations. The embodiments of this application adopt a context-sensitive type inference mechanism, which adaptively completes the type equivalence conversion based on the global reference scenario of variables, effectively avoiding the functional defects caused by fixed mapping. The specific conversion process is as follows: First, perform node matching: traverse all declaration nodes in the initial abstract syntax tree, accurately match the syntax units whose child node types are logic type, bit type, and byte type, and filter out the corresponding logic, bit, and byte basic type declaration nodes. The second step is context analysis: A full-domain search is performed to collect all mounting and referencing scenarios of the corresponding variable identifier within the initial abstract syntax tree. Based on scenario characteristics, the standard hardware type corresponding to the variable is determined: if the variable is mounted on a port node in the input direction, or participates in combinational logic assignment operations corresponding to the assignment operation node, it is determined to be a combinational signal without storage attributes and uniformly converted to a net type; if the variable is mounted inside a timing block node, and clock-triggered assignment is completed using timing structures such as always_ff and always_latch, it is determined to be a timing signal with data storage capabilities and uniformly converted to a register type. For fixed-width integer signals such as bit and byte, based on the corresponding reference scenario, the net type or register type with the corresponding bit width and sign attribute is matched and generated. For example, the 8-bit signed signal corresponding to byte and the n-bit binary signal corresponding to bit can both be accurately adapted and converted. The third step is to perform node replacement: replace the basic type sub-nodes in the original declaration node with wire type sub-nodes or register type sub-nodes that match the scenario inference results, while fully preserving core parameters such as variable identifiers, signal bit widths, and initial assignment information; for example, for the original declaration node Decl(Var(LogicType(8), Identifier("din"), None)), if the din variable participates in the combined assignment node operation, it is converted to Decl(Var(WireType(8), Identifier("din"), None)); if the din variable is mounted inside the timing block node and participates in timing assignment, it is converted to Decl(Var(RegType(8), Identifier("din"),None)).This conversion method abandons the crude and rigid strategy of uniformly converting the logic type to the reg type by default in related technologies, avoids hardware semantic deviations caused by basic type conversion from the root, and ensures that the circuit functions are completely equivalent before and after the conversion.

[0093] For example, enumeration node conversion is performed on enumeration-related nodes to achieve semantic equivalence adaptation from SystemVerilog enumeration custom structures to standard Verilog syntax. This can complete the splitting and conversion of enumeration definition nodes into local constant nodes and ordinary variable declaration nodes. Enumeration-related nodes belong to the lightweight syntax structure of SystemVerilog and have no corresponding hardware circuit logic. They are mainly used to standardize the definition of state parameters, avoid design magic numbers, and improve code readability. Existing solutions simply replace enumeration variants with numerical constants, which cannot generate standardized local constant nodes. This results in technical defects such as poor code readability, non-standard parameter definitions, and low logic recognizability after conversion. This application embodiment uses a systematic enumeration splitting and conversion mechanism to equivalently decompose the enumeration structure into local constant definitions and regular signal declaration structures, ensuring complete consistency of hardware logic and parameter definitions before and after conversion. The specific conversion process is as follows: First, node matching is performed: the initial abstract syntax tree is traversed in its entirety to accurately capture all enumeration definition nodes and variable declaration nodes referencing enumeration custom types. All enumeration-related syntax units are screened to ensure no nodes are missed. The second step is to perform enumeration definition transformation: extract core parameters such as enumeration name, enumeration variant identifier, and custom assigned values ​​from the enumeration definition node, and generate a corresponding local constant node for each enumeration variant. For enumeration variants without manual assignment, constant values ​​are automatically configured according to the rule of incrementing from 0; for enumeration variants with manually assigned parameters, custom values ​​are fully preserved to ensure that parameter semantics are not lost. At the same time, based on the maximum constant value of all enumeration variants, the minimum hardware bit width that can fully cover the parameter range is calculated, and all generated local constant nodes are mounted into the module node corresponding to the original enumeration structure. The third step is to perform enumeration variable transformation: replace the variable declaration nodes referencing enumeration types in the initial abstract syntax tree with standard basic type declaration nodes that match the corresponding bit width, and rely on the context-sensitive type inference mechanism to adaptively determine whether the variable is a net type or a register type based on the global reference scenario. If an enumeration variable carries an initial assignment parameter, the enumeration variant identifier in the initial assignment statement will be uniformly replaced with the corresponding matching local constant value. For example, the original syntax node Decl(Var(EnumRef("state_t"), Identifier("curr_state"), Some(Identifier("IDLE")))) will be converted to Decl(Var(RegType(1), Identifier("curr_state"), Some(Literal(0)))), and standardized local constant nodes corresponding to enumeration variants such as IDLE and RUN will be added simultaneously.The fourth step is to perform a global reference update: A global traversal of all syntactic units in the initial abstract syntax tree is performed, and all enumeration variant references in logical structures such as assignment statements and conditional statements are uniformly replaced with their corresponding local constant values, fully preserving the original design's state transitions and logical judgment relationships. This conversion method solves the shortcomings of traditional tools in enumeration conversion, such as poor standardization, low code readability, and unclear logical presentation. While ensuring 100% hardware functional equivalence, it maximizes adaptation to the Verilog 2005 standard syntax specification.

[0094] For example, struct node conversion is performed on struct-related nodes to achieve semantic equivalence adaptation from SystemVerilog struct composite types to standard Verilog syntax. This can complete the decoupling conversion of struct definition decomposition, struct variable splitting, and struct assignment logic. Struct-related nodes are custom composite syntax structures in SystemVerilog used to aggregate multiple types of signals. They can integrate hardware signals with different attributes and bit widths, simplifying modular interconnect design. However, the Verilog 2005 standard does not support struct syntax. Existing solutions generally suffer from technical defects such as incomplete struct splitting, ignoring nested struct fields, and missing assignment logic, making them unsuitable for complex struct design scenarios. This application embodiment employs a systematic structure decomposition and conversion mechanism to equivalently split the overall structure node into independent signal declarations and independent field assignment logic, ensuring complete consistency in hardware signal connections and operational logic before and after conversion. The specific conversion process is as follows: First, node matching: A full traversal of the initial abstract syntax tree is performed to accurately capture structure definition nodes, variable declaration nodes referencing structure types, and assignment operation nodes corresponding to overall structure assignments and field assignments. All structure-related syntax units are comprehensively screened to ensure no node omissions or logical gaps. Second, structure definition conversion: Core parameters such as the structure name, all structure fields, field names, and native field types within the structure definition node are extracted. The global type mapping table is retrieved to match the standard basic types corresponding to each field, establishing a structured mapping relationship of "structure variable name - all field list - field attribute parameters." Subsequently, the native structure definition nodes within the initial abstract syntax tree are unregistered, and the type, bit width, and attribute data of all structure fields are entered into the global type mapping table, providing data support for subsequent variable decomposition and logical conversion, thus solving the problem that traditional tools cannot identify nested structure fields. The third step is to perform structure variable conversion: retrieve the declaration nodes corresponding to all structure type variables in the initial abstract syntax tree, delete the original structure type declaration nodes, and generate an independent standard declaration node for each field of the structure based on the field parameters stored in the global type mapping table.The structure split signals uniformly adopt the standardized naming rule of "structure variable name_field name". At the same time, relying on the context-sensitive type inference mechanism, the global reference scenario of each field variable is adaptively determined to be a wire net type or a register type, and the original field's signal bit width, initial assignment and other attribute parameters are fully preserved. For example, for the original declaration node Decl(Var(StructRef("pkt_t"), Identifier("pkt"), None)), if the pkt_t structure contains a 1-bit valid signal valid and an 8-bit data signal data, it is split into independent declaration nodes Decl(Var(WireType(1), Identifier("pkt_valid"), None)) and Decl(Var(WireType(8), Identifier("pkt_data"), None)). The fourth step is to perform structure assignment and reference conversion: For the overall structure assignment nodes in the initial abstract syntax tree, the overall structure assignment logic is broken down into independent assignment operation nodes corresponding to the number of structure fields. The assignment logic, operation relationship and assignment value of each field are replicated one by one to ensure that the field assignment rules are completely consistent with the original design. For example, the original structure assignment node Assign(Identifier("pkt"), StructLit([("valid", Literal(1)), ("data", Literal(8'h55))])) is broken down into independent assignment operation nodes Assign(Identifier("pkt_valid"), Literal(1)) and Assign(Identifier("pkt_data"), Literal(8'h55)). At the same time, the structure member reference syntax unit is searched globally, and all nested reference methods of structure fields are uniformly replaced with the split independent signal identifiers to ensure that the global signal reference logic is consistent. This conversion method completely solves the technical pain points of existing EDA tools, such as incomplete structure conversion, missing nested field recognition, and easy omission of assignment logic. It is fully adapted to the modular design scenarios of complex nested structures and does not require manual secondary correction.

[0095] For example, interface node conversion is performed on interface-related nodes to achieve semantic equivalence adaptation from the SystemVerilog interface modular structure to standard Verilog syntax. This can complete the overall interface structure expansion, interface port splitting, modport direction inheritance, and interface method inlining conversion. Interface-related nodes are the core modular syntax structure for SystemVerilog to implement module interconnection and bus interaction. They can encapsulate multiple interaction signals, port direction constraints, and custom interaction logic, greatly simplifying multi-module interconnection design. However, the Verilog 2005 standard does not support interface syntax structures. Existing solutions only support the expansion of basic interface signals, cannot recognize inherited modport port direction definitions, and completely ignore built-in interface methods and task logic, resulting in technical defects such as incomplete interface conversion and loss of module interconnection logic. This application embodiment utilizes a systematic interface decomposition and logic inlining mechanism to equivalently expand the overall interface structure into independent module ports and standard connection logic, completely replicating the original port constraints and interaction logic. The specific conversion process is as follows: First, node matching: A full traversal of the initial abstract syntax tree is performed to accurately capture all interface definition nodes, module port nodes that mount interfaces, and interface instantiation nodes. All interface-related syntax units are comprehensively screened, fully including interface definition parameters, port mounting relationships, and module reference logic, ensuring no nodes or logic omissions. Second, interface definition parsing: All subordinate syntax units of the interface definition node are traversed and parsed, extracting core parameters such as built-in interaction signals, global clock signals, modport port direction constraints, custom interface methods, and task logic, establishing a structured correspondence of "interface name - signal list - port direction mapping". For the modport definition, the input, output, and bidirectional attributes of each signal are accurately recorded to form standardized port direction mapping rules. For the custom read / write methods and interactive task logic built into the interface, their input / output parameters and operation logic are decomposed and identified, and they are equivalently converted into assignment operation nodes and timing logic nodes supported by the Verilog standard, and then inlined into the corresponding calling module, effectively improving the defect of existing technologies that ignore interface functional logic. The third step is to perform module interface port conversion: the native interface port nodes within the module port are unregistered, and independent standard port nodes are generated for each signal inside the interface, uniformly adopting the standardized naming rule of "interface name_signal name", and fully inheriting the port direction attributes defined by the modport constraints. For the global clock signal built into the interface, an independent module clock port is generated separately, fully preserving the original clock driving logic and timing constraints. For example, if the top-level module top is attached to the bus interface bus_if, and the modport master defines clk as input and valid and data as output, after conversion, the input clock port clk and the output signal ports bus_valid and bus_data are generated, fully inheriting the original port direction constraints.The fourth step is to perform interface instantiation conversion: traverse all interface instantiation nodes within the initial abstract syntax tree, unregister the original interface instantiation syntax structure, and based on the interface signal mapping rules, decompose the overall connection relationship of the interface instance into multiple independent signal connection logics, generating corresponding assignment operation nodes. Match the connection relationship between the module port and the instance signal one by one, completely replicating the module interconnection topology and signal interaction logic. For example, for the bus_if type interface instance bus_if inst(.clk(clk)), after conversion, batch generate independent signal connection assignment nodes such as inst_clk and inst_bus_valid, completing the module signal interconnection adaptation. This conversion method completely solves the technical pain points of existing EDA tools, such as incomplete interface conversion coverage, lost port direction, and missing interface method logic. It fully preserves the modular bus interaction logic, adapts to various complex bus interface design scenarios, and requires no manual secondary correction.

[0096] Through the implementation of the above embodiments, differentiated conversion strategies are formulated for various complex syntax structures such as basic types, enumerations, structures, interfaces, type aliases, and package references. This achieves comprehensive coverage and refined processing of the key features of SystemVerilog. Especially in the case of complex data structures and modular design scenarios, it can effectively avoid information loss or semantic simplification, thereby ensuring the integrity and consistency of the converted code in terms of structure and logic, and improving the conversion reliability of complex designs.

[0097] In some embodiments, the aforementioned semantic equivalence conversion of syntax nodes based on the global type mapping table and the conversion method corresponding to the node type of the current syntax node to obtain an intermediate abstract syntax tree may further include: if the current syntax node is a timing logic block node, then in response to the timing block subtype attribute of the timing logic block node being an edge-sensitive attribute, the edge-sensitive list in the timing logic block node is retained and the node type identifier is modified to a general timing logic identifier; in response to the timing block subtype attribute being a level-sensitive attribute, the sensitivity list of the timing logic block node is replaced with a preset fully sensitive identifier and the node type identifier is modified to a general timing logic identifier; if the current syntax node is a delay-continuous assignment node, then the delay type feature of the delay information field in the delay-continuous assignment node is obtained, and based on the delay type feature, the numerical value or reference relationship of the delay information field is kept unchanged, and the delay-continuous assignment node is subjected to fixed numerical delay conversion or parameterized variable delay conversion.

[0098] In some examples, a sequential logic block node is a dedicated syntax unit in the initial abstract syntax tree used to describe the sequential and combinational logic behavior of digital integrated circuit hardware. It can define the signal triggering method, data register rules, and logic operation timing of the hardware circuit, and is the syntax structure for chip timing design and combinational logic design. The initial abstract syntax tree can be traversed in its entirety to filter logic syntax units with the sequential block subtype attribute to obtain a sequential logic block node. For example, the data register syntax unit used to describe edge-triggered registers and the logic syntax unit used to describe level-triggered combinational operations are both sequential logic block nodes.

[0099] When a timing logic block is identified as an edge-triggered timing structure, the sensitivity list consisting of trigger conditions such as clock rising edge and clock falling edge defined in the original code is fully preserved. At the same time, the proprietary timing block type identifiers of SystemVerilog are uniformly replaced with general timing logic identifiers adapted to the Verilog 2005 standard. This ensures that the hardware edge-triggered behavior remains completely unchanged while adapting to the standard syntax. For example, for edge-triggered timing logic blocks used to implement register data synchronization, the clock edge trigger conditions are fully preserved, and only the proprietary timing block identifier is replaced with a general timing identifier to ensure that the register sampling logic does not shift.

[0100] When a sequential logic block is identified as a level-triggered combinational logic structure, the custom local sensitivity list of SystemVerilog is discarded and replaced with a preset fully sensitive identifier. At the same time, the subdivided specific sequential block identifiers are rewritten as general sequential logic identifiers to adapt to the Verilog 2005 combinational logic standard syntax specification. For example, for level-sequential logic blocks of data combination operations and multiplexing decoding, the fully sensitive identifier is uniformly used to cover the original local sensitivity list, completely avoiding the latching risk caused by the omission of combinational logic sensitivity list.

[0101] Delay-continuous assignment nodes are continuous assignment syntax units in the initial abstract syntax tree that carry delay information parameters. They are used to define the delay characteristics in the signal transmission process of integrated circuits, characterize the timing and duration of signal assignment delays, and are important syntax structures for ensuring chip timing convergence and signal timing matching. Delay-continuous assignment nodes can be obtained by traversing the initial abstract syntax tree and filtering continuous assignment syntax units that carry delay information fields. For example, the syntax units corresponding to bus data transmission delay assignment and port signal output delay assignment are both delay-continuous assignment nodes.

[0102] It can read the attribute characteristics of the internal delay information field of the delay continuous assignment node, distinguish between two types of delay: fixed constant delay and parameterized variable delay. Under the premise of preserving the original delay value, parameter reference relationship and timing characteristics throughout the process, it can equivalently convert the SystemVerilog-specific delay assignment syntax into a delay assignment syntax structure that conforms to the Verilog 2005 standard. For example, for signal transmission delay with a fixed value, the delay value is kept constant to complete the syntax conversion, and for variable delay with parameter definition, the parameter reference relationship is preserved, realizing lossless equivalent adaptation of the two types of delay structures.

[0103] For example, the timing block node conversion for timing logic blocks is used to achieve semantic equivalence adaptation from SystemVerilog's subdivided explicit timing logic blocks to standard Verilog timing blocks. It can accurately convert the three proprietary timing syntax structures—always_ff, always_comb, and always_latch—to the general always-timing syntax structure. The always_ff, always_comb, and always_latch explicit timing logic blocks set by SystemVerilog can accurately distinguish the hardware behavior of trigger-based sequential logic, combinational logic, and latch logic, effectively avoiding logic confusion problems. However, the Verilog 2005 standard only supports general always-timing logic blocks, and existing EDA tools generally have technical defects such as incomplete timing block sensitivity lists and misidentification of logic, which can lead to circuit functional deviations. This solution employs a conversion strategy of categorized adaptation, precise replication of trigger logic, and automatic completion of the sensitivity list to ensure complete consistency in hardware timing behavior before and after conversion. The specific conversion process is as follows: First, node matching: A full traversal of all timing logic block nodes within the initial abstract syntax tree is performed, precisely filtering syntax units whose subtypes are edge-triggered timing blocks, combinational logic timing blocks, and latch timing blocks, completing the classification, identification, and matching of various subdivided timing structures. Second, edge-triggered timing block conversion: Edge-triggered timing blocks correspond to flip-flop register logic, with the core relying on clock edge signals to trigger data sampling. During the conversion process, the edge sensitivity lists such as clock rising edge and clock falling edge of the original syntax nodes are fully preserved. Edge-triggered timing block nodes are uniformly replaced with general timing logic block nodes, and the sub-level logic structures such as condition judgments and assignment operations within the nodes are fully retained without deletion or modification. For example, the original syntax node Always(AlwaysFF, Edge(Posedge, Identifier("clk")), Block([Assign(Identifier("dout"), Identifier("din"))])) is transformed into Always(AlwaysEdge, Edge(Posedge, Identifier("clk")), Block([Assign(Identifier("dout"), Identifier("din"))])). If an edge-triggered timing block node is found to lack a clock edge sensitive condition, it is determined to be an illegal syntax structure, and a precise error message is output in a timely manner, terminating the conversion process to ensure the legality of the timing logic. The third step is to perform combinational logic timing block conversion: combinational logic timing blocks are used to implement combinational operation logic triggered by pure levels.During the conversion process, combinational logic timing block nodes are replaced with general timing logic block nodes, and a preset fully sensitive identifier @(*) is uniformly configured as a global sensitive list. Simultaneously, all input variables within the timing block are traversed and parsed to verify the completeness of the fully sensitive list coverage, preventing circuit logic deviations caused by missing sensitive variables. For example, the original syntax node Always(AlwaysComb, Block([Assign(Identifier("dout"), BinOp(And, Identifier("din1"), Identifier("din2")))])) is converted to Always(AlwaysStar, Block([Assign(Identifier("dout"), BinOp(And, Identifier("din1"), Identifier("din2")))])). The fourth step is to perform latch timing block conversion: latch timing blocks are used to implement level-triggered hardware latching logic. During the conversion process, latch timing block nodes are replaced with general timing logic block nodes, configured with preset fully sensitive identifiers @(*), and automatically generated with the exclusive comment " / / Latch logic converted from always_latch". This accurately marks the latch hardware attributes, avoiding misjudgment by backend synthesis tools as ordinary combinational logic and ensuring accurate replication of latch circuit functionality. For example, for the original syntax node Always(AlwaysLatch, Block([If(Identifier("en"), Assign(Identifier("q"),Identifier("d")))])), the conversion generates Always(AlwaysStar, Block([If(Identifier("en"),Assign(Identifier("q"),Identifier("d")))])), with an accompanying latch logic tracing comment. This finely categorized timing block conversion method effectively improves the technical defects of existing EDA tools, such as incomplete timing structure adaptation, missing sensitive lists, and hardware logic offsets, achieving lossless equivalent conversion of various timing, combinational, and latch logic.

[0104] For example, delay assignment conversion is performed on continuous delay assignment nodes to achieve lossless equivalence adaptation from SystemVerilog continuous delay assignment syntax to Verilog 2005 standard syntax, covering delay assignment structures for all scenarios, including fixed numerical delay, parameterized delay, and variable delay. SystemVerilog supports continuous delay assignment syntax with delay parameters preceding assignment statements, which can accurately describe the delay characteristics of hardware circuit signal transmission. This syntax structure is also compatible with the Verilog 2005 standard. However, existing EDA tools lack targeted delay syntax adaptation logic, resulting in significant technical defects: some tools only retain delay text characters, failing to adapt to the standard Verilog syntax specification; some tools directly discard delay parameter information, easily causing the loss of hardware timing characteristics. This solution adds a dedicated mechanism for identifying and converting continuously assigned delay nodes, fully preserving the timing characteristics of the original design and ensuring grammatical compliance and lossless timing. The specific conversion process is as follows: First, node matching: A full traversal of all assignment nodes within the initial abstract syntax tree is performed to accurately identify continuously assigned delay nodes carrying delay fields, distinguishing them from ordinary assignment syntax units without delay. This comprehensively covers various delay assignment scenarios, including fixed numerical delays and parameterized variable delays, achieving accurate capture of nodes across all scenarios. Second, delay information extraction: For the matched continuously assigned delay nodes, core timing parameters are uniformly parsed and extracted. Three types of delay features are identified and distinguished: fixed numerical delays, parameterized delays, and custom variable delays. The signal relationships and logical operation structures within the assignment statements are simultaneously retained, ensuring that delay parameters and assignment logic are bound together and not disconnected. For example, for the delay assignment statement assign #10 dout = din&en, the fixed-value delay parameter 10 and the corresponding AND operation assignment logic are extracted; for the parameterized delay statement assign #DELAY addr = addr_in, the global parameter DELAY and the corresponding signal assignment relationship are extracted.The third step is to perform equivalent conversion and adaptation: based on the type characteristics of the delay information field, match the corresponding standardized conversion rules, and complete the equivalent conversion under the premise of strictly following the Verilog 2005 syntax standard: (1) Fixed value delay conversion: for delay assignment nodes carrying fixed values ​​and decimal values, retain the original delay values ​​and syntax structure, replace the SystemVerilog exclusive delay assignment nodes with standard Verilog delay assignment nodes, and only standardize the syntax format to adapt to the standard specification; for example, convert the original node DelayAssign(Delay(Literal(10)), Identifier("dout"), BinOp(And, Identifier("din"), Identifier("en"))) to generate the standard assignment node Assign(Delay(Literal(10)), Identifier("dout"), BinOp(And, Identifier("din"),Identifier("en"))), and generate the corresponding compliant code assign #10 dout = din&en, completely replicating the original timing and operation logic. (2) Parameterization / Variable Delay Conversion: For delay assignment nodes carrying custom parameters and variables, first check whether the corresponding parameters and variables have been included in the global type mapping table and module parameter definition. If there is an undefined exception, the error message will be output immediately and the conversion process will be terminated. If the parameters are valid, the reference relationship of the parameters and variables will be completely preserved, and the standardization conversion of the delay assignment node will be completed. For example, the original node DelayAssign(Delay(Identifier("DELAY")), Identifier("addr"), Identifier("addr_in")) will be converted into the standard assignment node Assign(Delay(Identifier("DELAY")), Identifier("addr"), Identifier("addr_in")) to adapt to the Verilog 2005 parameterized delay syntax specification. The fourth step is to perform reference consistency verification: After completing the node conversion, all related syntax units in the initial abstract syntax tree are traversed in the entire domain to verify the consistency of delay parameter values, variable reference relationships, and signal assignment logic. This prevents problems such as delay loss, signal association disorder, and logic omission during the conversion process, and completely solves the technical pain points of existing EDA tools such as non-standard delay adaptation, loss of timing information, and the need for manual secondary correction, ensuring that the timing behavior and functional logic of the circuit before and after the conversion are completely equivalent.

[0105] Through the implementation of the above embodiments, combined with the specific reference scenarios of syntax nodes, targeted semantic conversion is performed on sequential logic blocks and continuous assignments with delays, so that edge-sensitive, level-sensitive and delay characteristics are accurately preserved in the conversion process, avoiding the problems of missing sensitivity lists or loss of delay information in traditional methods. This ensures that the timing behavior and delay characteristics remain consistent before and after the conversion, and improves the accuracy of the conversion results at the actual hardware behavior level.

[0106] In some embodiments, the aforementioned semantic equivalence transformation of the syntax node based on the global type mapping table and the transformation method corresponding to the node type of the current syntax node to obtain an intermediate abstract syntax tree may further include: if the current syntax node is a port simplified declaration node, then the preset type keyword in the port simplified declaration node is deleted, while the port direction information and port bit width information in the port simplified declaration node are retained to generate a standard port declaration node; if the current syntax node is an indefinite-width constant node, then based on the assignment target bit width information of the indefinite-width constant node in the initial abstract syntax tree, the indefinite-width constant node is replaced with a constant value literal node with a definite bit width.

[0107] In some examples, simplified port declaration nodes are exclusive port syntax units in the initial abstract syntax tree that define only the port direction and port width, omitting explicit data type keywords. They belong to the lightweight port definition structure unique to SystemVerilog and are often used in scenarios involving the batch declaration of ports in large-scale modules. The initial abstract syntax tree can be traversed to filter out syntax units in port declaration statements that are missing standard type keywords and only contain port direction and width parameters to obtain simplified port declaration nodes. For example, port declaration syntax units formed by writing simplified syntax for digital chip data input ports and control signal output ports are both simplified port declaration nodes.

[0108] It can target the lightweight port declaration structure in SystemVerilog, remove exclusive simplified type keywords that only fit the SystemVerilog syntax system, fully retain the direction parameters and bit width parameters that determine the electrical attributes of the hardware port, and reconstruct and generate standardized port syntax nodes that fully conform to the Verilog 2005 syntax specification. It only simplifies redundant syntax identifiers and does not modify the hardware interaction attributes and signal transmission capabilities of the port. After identifying the simplified port declaration node, it can call preset port standardization rules to automatically complete keyword removal and node reconstruction. For example, it can remove exclusive modifier keywords in the simplified port declaration, retain the input / output direction and eight-bit bus width parameters, and generate a standard port declaration node that can be directly adapted to synthesis tools.

[0109] Indefinite-width constant nodes are constant syntax units in the initial abstract syntax tree that only define constant values ​​and do not explicitly annotate hardware bit-width parameters. They are a simplified constant definition structure supported by SystemVerilog. These nodes do not have a fixed bit-width attribute; the bit-width depends on the target hardware structure for adaptive matching. If directly migrated to the Verilog 2005 syntax system, bit-width ambiguity will occur. Indefinite-width constant nodes can be obtained by traversing the initial abstract syntax tree and filtering out numerical constant syntax units without explicit bit-width definitions. For example, the simplified definition syntax units of chip reset threshold constants and logic enable constants are both indefinite-width constant nodes.

[0110] It can locate the target hardware signal corresponding to the variable-width constant, read the inherent hardware bit-width parameter of the target signal, and use this as the sole standard to supplement the bit-width limitation attribute of the native variable-width constant. It can equivalently convert the semantically ambiguous simple constant structure into a standard literal constant node with a clear bit-width and grammatically compliant structure, which can completely eliminate the circuit logic deviation caused by constant bit-width mismatch and ensure that the assignment logic is accurately aligned with the original design. It can retrieve the bit-width attribute of the constant assignment associated node and complete the node replacement by matching the constant standardization rules. For example, based on the bit-width parameter of an eight-bit data signal, a logic constant with no bit width can be rewritten as an eight-bit standard literal constant, ensuring that the bit width of the constant assignment is completely matched with the bit width of the hardware signal.

[0111] For example, the initial abstract syntax tree is traversed to accurately identify all simplified port declaration nodes and variable-width constant nodes; redundant keywords are removed from simplified port declaration nodes to fully preserve the core hardware attributes of the ports and complete the reconstruction of standard port nodes; for variable-width constant nodes, the corresponding assignment target signals are traced and matched to extract the standard bit-width parameters of the target signals; the constant structure is standardized and rewritten based on the obtained bit-width parameters to eliminate bit-width semantic ambiguity; the port interaction logic and constant assignment logic remain unchanged throughout the process, and finally the lossless equivalent conversion of the two types of special syntax nodes is completed, improving the syntax standardization transformation of the intermediate abstract syntax tree.

[0112] For example, the conversion between simplified port declarations and variable-width constant nodes is used to standardize the adaptation of two types of lightweight SystemVerilog special syntaxes, achieving semantic equivalence conversion from simplified port declaration structures and variable-width constant structures to Verilog 2005 standard syntax. SystemVerilog supports simplified port declaration syntax with port direction superposition data types and variable-width constant syntax without bit width limitations, which can reduce the amount of code written. However, this type of lightweight syntax belongs to SystemVerilog-specific syntax structures and cannot be directly recognized by the Verilog 2005 standard. Moreover, existing EDA tools have weak adaptation capabilities for this type of syntax, with technical defects such as constant bit width matching errors, redundant keywords in port declarations, and the need for manual secondary correction. This solution designs dedicated standardized conversion rules for the two types of syntax structures to achieve fully automatic lossless syntax adaptation. The specific conversion process is as follows: First, simplified port declaration conversion. The process involves two main steps: First, traversing simplified port declaration nodes within the initial abstract syntax tree. This involves removing SystemVerilog-specific type modifiers like `logic` while preserving core hardware attributes such as input / output direction and signal width parameters. The result is a reconstructed standard port declaration node conforming to the Verilog 2005 specification. For example, for simplified port declarations like `input logic clk` with type modifiers, the `logic` keyword is removed, the port input direction attribute is retained, and a standard port declaration `input clk` is generated. This standardization and adaptation of port syntax is achieved without altering the port's hardware interaction logic, eliminating the need for manual correction. Second, variable-width constant conversion. This involves traversing all variable-width constant nodes within the initial abstract syntax tree, tracing and matching the target assignment signal corresponding to the constant, reading the inherent hardware width parameters of the target signal, and using the target width to supplement the native widthless constant with precise width constraints. This transforms semantically ambiguous variable-width constant nodes such as '0', '1', and 'x' into precisely width-compliant literal constant nodes. For example, the variable-width zero-value constant assigned to an 8-bit signal is converted to an 8'h00 standard constant, and the variable-width all-1 constant assigned to a 16-bit signal is converted to a 16'hffff standard constant. This completely solves the technical pain points of existing EDA tools, such as non-standard variable-width constant conversion, incorrect bit width adaptation, and parsing errors, and ensures that the constant assignment logic is completely equivalent to the original design.

[0113] By implementing the above embodiments, the syntax of simplified port declarations and variable-width constants is standardized, so that the converted code conforms to the standard Verilog syntax requirements. At the same time, necessary information is completed according to the context to avoid parsing errors caused by syntax differences. This can improve the standardization and compatibility of the generated code, reduce the difficulty of subsequent EDA tool processing, and improve the usability in engineering applications.

[0114] In some embodiments, step 104 may include: performing a first traversal operation, a second traversal operation, and a third traversal operation on the intermediate abstract syntax tree to obtain a target abstract syntax tree; wherein, if a constant expression node is detected in the intermediate abstract syntax tree based on the first traversal operation, the constant expression node is evaluated to obtain an evaluation result, and the constant expression node is replaced with a literal node corresponding to the evaluation result; if a conflicting identifier is detected based on the second traversal operation, the conflicting identifier is renamed according to a preset suffix generation rule; if a redundant node not referenced by other nodes is detected in the intermediate abstract syntax tree based on the third traversal operation, the redundant node is deleted.

[0115] In some examples, the first traversal operation is a specialized global scan operation designed specifically for the constant expression structure within the intermediate abstract syntax tree. It is only used to identify, capture, and process constant operation structures across the entire tree, without performing identifier detection or redundant node screening, ensuring that each traversal has a single function and accurate processing. The second traversal operation is a specialized global search operation designed specifically for the globally custom identifiers of the intermediate abstract syntax tree. It is only used to detect naming duplication and naming conflicts of module names, port names, variable names, and parameter names across the entire project, independent of the constant optimization and redundant deletion process. The third traversal operation is a specialized verification traversal operation designed specifically for the node reference relationships of the intermediate abstract syntax tree. It is only used to count the global reference count of each syntax node and screen for invalid nodes without parent calls, assignment associations, or port attachments.

[0116] If a constant expression node is detected in the intermediate abstract syntax tree based on the first traversal operation, the constant expression node is calculated and evaluated to obtain the evaluation result. The process of replacing the constant expression node with the literal node corresponding to the evaluation result relies on the first traversal operation to complete the constant structure identification. All operational expressions composed of multiple constants and static parameters are statically evaluated at compile time, and the dynamic operation structure is equivalently replaced with a fixed single literal. This can reduce the computational overhead of the back-end logic synthesis stage and simplify the circuit compilation logic. For example, the bus threshold expression formed by the superposition of multi-bit-width constants can be statically calculated into a fixed numerical literal and replace the original multi-layer operation expression node.

[0117] If a conflicting identifier is detected based on the second traversal operation, the process of renaming the conflicting identifier according to the preset suffix generation rules involves redefining the identifier by adding a unique suffix after detecting a globally duplicated identifier, following a unified and standardized naming rule. This eliminates global naming conflicts while preserving the signal function and hardware semantics, and can solve compilation errors and logical inconsistencies caused by signals with the same name in multi-module design scenarios. For example, for valid data signal identifiers that are repeatedly defined in multiple modules, a new unique identifier is generated by adding a module-specific suffix, ensuring that global identifiers are not duplicated.

[0118] If redundant nodes not referenced by other nodes are detected in the intermediate abstract syntax tree based on the third traversal operation, the process of deleting redundant nodes is based on the global reference statistics of nodes. It accurately removes idle syntax nodes that have no logical connection and no functional contribution, simplifies the overall syntax tree structure, does not delete effective hardware logic nodes, only removes invalid residual nodes, and reduces the resource overhead of subsequent code generation and logic synthesis. For example, it deletes idle port nodes and invalid parameter nodes that have not participated in bus interaction and data operation after definition.

[0119] For example, three types of specialized traversal optimization processes are executed sequentially to standardize and refine the intermediate abstract syntax tree after conversion. These processes include constant folding operations, identifier conflict correction, and redundant node removal, comprehensively optimizing the syntax tree structure and code standardization. The specific steps are as follows: First, constant folding optimization is performed based on the first traversal operation. Through a specialized full-domain scan traversal of the intermediate abstract syntax tree, various constant expression nodes, such as enumeration values, variable-width constants, and arithmetic expressions, are uniformly identified. Static pre-evaluation is performed during the compilation phase, uniformly replacing dynamic expression structures with standard literal nodes of fixed values. For example, variable-width zero-value constant nodes are converted into specified-width literal nodes such as 8'h00 and 16'h0000 based on the target signal bit width. Simultaneously, binary arithmetic constant expressions like 3+5 are directly statically evaluated and merged into single-value literal nodes. This method significantly simplifies subsequent code generation and EDA tool parsing, fundamentally avoiding issues such as constant parsing anomalies and operational logic offsets. Second, naming conflict resolution is performed based on the second traversal operation. The process involves a full traversal of all identifier nodes within the intermediate abstract syntax tree (MTB), with a focus on detecting name conflicts between field signals generated from structure splitting, port signals generated from interface expansion, and native module signals. Upon detecting a global naming duplicate, the identifier is renamed according to the preset naming rule of "original name_numeric suffix". For example, the structure splitting signal `pkt_valid`, which conflicts with the basic signal `valid`, is renamed to `pkt_valid_1`. Simultaneously, all associated reference nodes are updated globally to ensure the continuity and integrity of the signal reference chain, preventing compilation and parsing errors caused by naming conflicts. This effectively addresses the technical deficiency in the US9569562B2 scheme where naming conflicts require manual intervention. The third step involves deleting redundant nodes based on the third traversal operation. A full-domain verification and statistical analysis of the global reference relationships of all syntax nodes in the intermediate abstract syntax tree is performed. Invalid and redundant nodes without any external references or logical connections are accurately screened and batch-removed. This includes local constant nodes corresponding to enumeration variants that have not been called, structure field declaration nodes that have not participated in logical operations after splitting, and redundant assignment nodes with completely repeated logic. By precisely removing invalid and idle syntax nodes, the overall syntax tree hierarchy is streamlined, reducing the redundancy of the final output code, optimizing the overall performance of the backend logic, and addressing the technical shortcomings of existing solutions, such as large code redundancy and low engineering adaptation efficiency. The three specialized traversal optimizations are independent of each other and each performs its own function, without altering the original hardware circuit logic and timing behavior throughout the process. The final output is a concise, well-named, and logically flaw-free target abstract syntax tree.

[0120] Through the implementation of the above embodiments, multiple rounds of traversal perform optimization operations such as constant folding, naming conflict resolution, and redundant node deletion on the intermediate abstract syntax tree, making the generated target abstract syntax tree more concise and efficient. This not only reduces redundant logic and improves code execution efficiency, but also avoids parsing problems caused by naming conflicts, thereby improving the quality and maintainability of the final generated code.

[0121] In some embodiments, step 105 may include: traversing each syntax node in the target abstract syntax tree according to a preset node processing order, wherein the preset node processing order is module node, port node, declaration node, assignment node, and timing logic node; converting each syntax node traversed from the target abstract syntax tree into a code fragment conforming to a preset Verilog syntax specification based on a preset mapping relationship between node types and Verilog syntax templates; and performing format optimization processing on the code fragment to obtain Verilog code.

[0122] In some examples, the default node processing order is module node, port node, declaration node, assignment node, and timing logic node, which is a fixed traversal priority sequence customized to adapt to the official Verilog 2005 syntax writing specification. The module node is the top-level framework unit of the hardware design, the port node is responsible for the external signal interaction of the module, the declaration node defines the internal hardware signal resources of the module, the assignment node implements combinational logic signal operations, and the timing logic node completes the construction of timing register logic. This order is completely consistent with the code writing specifications of commercial chip design.

[0123] The pre-defined mapping between node types and Verilog syntax templates is a one-to-one correspondence between pre-established structured syntax units and standard code statement templates. It is used to define the standardized writing format corresponding to different types of tree-shaped syntax nodes. This mapping covers all synthesizable syntax nodes within the target abstract syntax tree and can provide a dedicated and compliant syntax translation standard for each type of syntax structure.

[0124] Based on the preset mapping relationship between node types and Verilog syntax templates, the process of converting each syntax node traversed from the target abstract syntax tree into code snippets conforming to the preset Verilog syntax specifications is a compilation process that establishes a standardized correspondence between node semantics and standard code statements. For different types of syntax nodes, a dedicated Verilog 2005 syntax template is invoked to translate the structured tree-like syntax units one-to-one into standard code snippets in text form. This process ensures that each type of syntax node can generate code statements with a unified format and grammatical compliance, avoiding syntax translation errors. For example, after the system identifies a timing logic node, it matches the corresponding timing register syntax template to generate a standard clock trigger logic code snippet; after identifying an assignment node, it matches the combined assignment syntax template to generate a compliant signal operation code snippet.

[0125] Format optimization is a post-processing step involving standardized typesetting and structural regularization of the scattered original code fragments generated from the translation of syntax templates. This process optimizes only the code's writing format, layout structure, and overall regularity, without altering the hardware logic or syntactic semantics. It addresses the technical problems of messy typesetting, unclear hierarchy distinctions, and poor readability in the original translated code. After translating individual syntax nodes to obtain independent code fragments, this process can perform overall regularization, format calibration, and structural integration of scattered code statements. For example, this step can perform overall typesetting and regularization of scattered port code, assignment code, and timing logic code, integrating them into standardized Verilog hardware design code with a complete structure, unified format, and ready for direct use in integrated simulation.

[0126] For example, the system retrieves the fixed node processing priority rules and traverses the target abstract syntax tree layer by layer in the order from the top-level framework to the internal logic. For each syntax node obtained during the traversal, it accurately matches the corresponding Verilog syntax template and independently translates and generates standardized code snippets. It continuously iterates through all syntax nodes to complete the batch generation and collection of code snippets for the entire module. It performs unified format calibration and structural integration on all scattered code snippets and eliminates formatting defects. Finally, it outputs complete Verilog hardware design code that is grammatically compliant, has a clear structural hierarchy, and fully preserves hardware semantics.

[0127] By implementing the above embodiments, the target abstract syntax tree is traversed in a preset order, and code snippets are generated based on the mapping relationship between node types and Verilog syntax templates. This ensures that the code generation process has clear structural rules and syntactic constraints, and that the generated Verilog code is clear in structure and standardized in syntax, which is conducive to the smooth execution of subsequent EDA processes such as synthesis and simulation.

[0128] In some embodiments, the aforementioned format optimization processing of code snippets to obtain Verilog code may include: generating a corresponding hierarchical indentation prefix for each code snippet based on a preset unit indentation amount and the hierarchical depth information of each syntax node in the target abstract syntax tree; inserting newline characters at preset operator positions for continuous assignment expressions and conditional branch expressions in the code snippet that satisfy preset line break conditions; adding transformation source annotation information to the syntax nodes generated by semantic equivalence transformations in the code snippet, wherein the transformation source annotation information is used to indicate the syntax type of the SystemVerilog code corresponding to the syntax structure; and using the code snippet with added hierarchical indentation prefixes, newline character insertion processing, and added transformation source annotation information as Verilog code.

[0129] In some examples, the process of generating corresponding hierarchical indentation prefixes for each code segment based on preset unit indentation and the hierarchical depth information of each syntax node in the target abstract syntax tree relies on pre-fixed single-level indentation standard parameters. Combined with the nesting level attributes inherent in each syntax node of the target abstract syntax tree, the module nesting depth of each code segment is determined, and indentation character prefixes with matching lengths are automatically generated. This achieves a format optimization process that visually distinguishes code levels. This process only adjusts the code layout style and does not modify the code logic or syntactic semantics. For example, the top-level definition code of a module matches the lowest level depth and generates no indentation prefix; the sequential logic code inside the module matches the middle level nesting depth and generates a first-level indentation prefix; and the assignment statements inside the sequential block match the deep nesting depth and generate a second-level indentation prefix.

[0130] The process of inserting newline characters at preset operator positions for continuous assignment expressions and conditional branch expressions in code snippets that meet preset line break conditions is based on built-in statement length thresholds and statement complexity judgment rules. It identifies continuous assignment statements and multi-way conditional branch statements within the code snippet that exceed the single-line length limit or have excessive nesting levels. Newline markers are inserted at pre-specified standard operator positions, effectively breaking down long, stacked single-line statements into hierarchical multi-line statements. This process effectively solves the problem of complex logical statements being crowded and difficult to read and understand. For example, for multi-way selection conditional expressions containing multi-level judgment logic, after identifying statements that exceed the length limit, the system splits the statements line by line at the condition judgment operator positions to achieve hierarchical display of branch logic.

[0131] The source annotation information is textual traceability information specifically used to annotate the original design structure corresponding to the Verilog standard code. It is used to accurately identify the original SystemVerilog syntax type corresponding to the current standardized syntax structure. This type of annotation information is only used as an engineering auxiliary traceability field and will not participate in hardware circuit synthesis, simulation and timing analysis, and will not have any impact on chip hardware functions and circuit behavior.

[0132] The process of adding source annotations to syntax nodes generated by semantic equivalence transformations in code snippets involves a post-processing step that iterates through all non-native standard syntax code snippets that have undergone semantic reconstruction and syntax adaptation rewriting, retrieves the original SystemVerilog syntax attributes corresponding to the syntax nodes, and automatically adds standardized source annotations near the corresponding code statements. This step only applies to code rewritten across syntax standards; no annotations are needed for code natively adapted to the Verilog 2005 standard. For example, annotations are automatically added to port code generated by interface structure expansion and basic type code generated by type alias replacement, indicating that the code was generated by SystemVerilog-specific syntax transformation.

[0133] It can aggregate all standardized code snippets that have undergone hierarchical formatting optimization, splitting of excessively long statements, and addition of source comments. It can also perform global code formatting verification, statement integration, and structure splicing, ultimately outputting complete, standardized Verilog 2005 standard hardware design code that can be directly used in integrated circuit development, i.e., Verilog code.

[0134] For example, the system can batch read the hierarchical depth attributes of all syntax nodes within the target abstract syntax tree, and combine them with fixed unit indentation parameters to accurately generate indentation prefixes that adapt to the nesting level for each code snippet; it can scan all generated code snippets across the entire domain, accurately filter excessively long continuous assignment statements and multi-branch conditional statements, and automatically insert line break markers at compliant operator positions to complete statement splitting; it can traverse all code nodes that have undergone semantic equivalence transformation, retrieve the corresponding original syntax type information, and add standardized traceability comments line by line; it can uniformly splice and verify the integrity of all scattered code snippets that have completed multi-dimensional format optimization; it can maintain complete consistency between the hardware circuit logic, timing behavior and the original design throughout the process, and finally generate standardized Verilog hardware design code that is hierarchical, well-formatted, and highly traceable.

[0135] By implementing the above embodiments, the generated code snippets are optimized in terms of indentation, line breaks, and comments, so that the final output Verilog code has good readability and maintainability. At the same time, the code traceability is enhanced by adding source conversion comments, which makes it easier for designers to understand the conversion logic and perform subsequent debugging, thereby improving the human-computer friendliness and engineering practical value of the code.

[0136] In some embodiments, the aforementioned code conversion method may further include: acquiring a first simulation output waveform corresponding to SystemVerilog code and a second simulation output waveform corresponding to Verilog code; performing a clock-cycle bit-level comparison on the first simulation output waveform and the second simulation output waveform to obtain a first verification result; performing expression conversion processing on the SystemVerilog code and the Verilog code respectively to obtain a first constraint solution expression corresponding to the SystemVerilog code and a second constraint solution expression corresponding to the Verilog code; performing logical equivalence proof on the first constraint solution expression and the second constraint solution expression to obtain a second verification result; generating a functional equivalence verification report based on the first verification result and the second verification result, wherein the functional equivalence verification report is used to indicate whether the Verilog code meets the preset equivalence conversion requirements.

[0137] In some examples, the first simulation output waveform is a timing signal output file generated by an electronic design automation simulation tool after loading simulation test stimuli onto the SystemVerilog design code to be converted. It completely records the level state and change pattern of all signals in the original design in each clock cycle. The first simulation output waveform can be automatically exported after loading general test stimuli onto the original SystemVerilog design code, compiling and simulating it using commercial simulation tools. For example, the signal timing output waveform generated after loading read and write test stimuli onto the SystemVerilog design code corresponding to the chip data register module and bus transmission module is the first simulation output waveform.

[0138] The second simulation output waveform is the converted Verilog 2005 standard design code. After loading simulation test stimuli that are completely identical to the original design, the timing signal output file generated by running the electronic design automation simulation tool is used as standard reference data for the behavior of the converted hardware circuit. The second simulation output waveform can maintain complete consistency with the test stimulus parameters and simulation running environment. The output Verilog code is subjected to the same simulation compilation and running, and the timing output waveform data is automatically generated. For example, the converted Verilog code corresponding to the aforementioned bus transmission module, loaded with the timing waveform file generated by running the same read and write test stimuli, is the second simulation output waveform.

[0139] Clock cycle-by-clock bit-level comparison is a refined comparison method that uses the hardware design clock cycle as the smallest verification unit to compare and verify each bit level of all signals within two sets of simulated output waveforms. It can accurately capture subtle signal differences within a single cycle and a single bit, and can screen for hidden logical deviations that macroscopic comparisons cannot identify. Clock cycle-by-clock bit-level comparison can have a built-in waveform comparison program that automatically traverses all clock cycles and signal bits to complete the difference retrieval; for example, this comparison method can accurately identify the level difference of the lowest bit of the data signal within a single clock cycle, precisely locating subtle semantic deviations caused by conversion.

[0140] The first verification result is the dynamic simulation verification conclusion data generated by summarizing all signal difference points, the number of differences, and the type of differences after completing the bit-level comparison of the dual waveforms clock cycle. This data is used to characterize whether the dynamic timing operation behavior of the design before and after the conversion is consistent. For example, waveform comparison data without any signal bit differences can generate the simulation equivalent first verification result, while the presence of periodic signal level disorder will generate the simulation inconsistent first verification result.

[0141] Expression transformation is a preprocessing step that involves syntactically deconstructing and logically purifying the hardware design source code. It removes redundant internal formatting, timing auxiliary statements, and comments, and abstracts hardware logic operations, constraints, and branch judgment rules into standardized mathematical constraint expressions. It is the foundational process for formal logic verification. For example, it involves deconstructing and abstracting multi-branch decoding logic and timing data latching logic, stripping away irrelevant syntactic structures, and generating standardized logical constraint expressions.

[0142] The first constraint expression is a standardized logical constraint mathematical expression abstracted from the original SystemVerilog design code after expression transformation. It fully solidifies all hardware logic constraints, branch decision conditions, and operation rules of the original design. For example, the standardized logical expressions corresponding to chip data sampling enable constraints and port data bit width matching constraints are the first constraint expression. The second constraint expression is a standardized logical constraint mathematical expression abstracted from the transformed Verilog design code after expression transformation. It fully solidifies the hardware logic rules and constraints of the transformed design. For example, the transformed standardized logical expression corresponding to the original data sampling constraints is the second constraint expression.

[0143] Logical equivalence proof is a static verification process that relies on formal verification algorithms to bidirectionally traverse and compare the logical coverage, input-output mapping relationship, and boundary constraint conditions of two sets of constraint-solving expressions. It mathematically proves whether the two sets of expressions are logically completely equivalent. This process does not rely on simulation stimulation and can achieve logical coverage verification of the entire input scenario. For example, by traversing all input boundary conditions through the solver, the consistency of branch judgment logic and data operation logic before and after the transformation can be verified.

[0144] The second verification result is a static formal verification conclusion generated by summarizing all logical verification data after proving the logical equivalence of the two sets of constraint solution expressions. It is used to characterize whether the underlying mathematical logic and constraint rules of the design before and after the transformation are completely consistent. For example, if the logic of the full input scenario is completely matched, a logically equivalent second verification result can be generated. If there is a lack of local boundary logic, a logically inequivalent second verification result can be generated.

[0145] The functional equivalence verification report is a standardized document that integrates dynamic simulation verification results and static formal verification results. It is used to fully record the equivalence verification process, difference points, and final judgment results of this code conversion, and to intuitively determine whether the output code meets the preset conversion accuracy and semantic fidelity requirements. It can automatically summarize the first verification results and the second verification results, and generate functional equivalence verification reports in batches according to preset report templates. For example, if both bidirectional verifications are equivalent, a functional equivalence verification report with qualified conversion can be generated. If any verification fails, a conversion failure report with anomaly points marked will be generated.

[0146] For example, a unified simulation stimulus can be applied to both the original SystemVerilog code and the converted Verilog code, and the simulation program can be run to obtain two sets of standard timing simulation waveforms. A refined waveform comparison program can be started to verify the state of all signals clockwise and bitwise, complete the dynamic behavior equivalence verification, and generate the first verification result. Logical abstraction processing can be performed synchronously on the two types of design code to remove redundant syntax structures and generate two sets of constraint solution expressions. A formal solver can be used to complete the global logical equivalence proof and output the second verification result. All data and verification conclusions of the two-layer verification can be integrated, the data format can be automatically standardized, and abnormal information can be recorded. Finally, a functional equivalence verification report with complete content, unified judgment criteria, and usable for engineering verification can be generated, completing the closed-loop verification of the entire code conversion process.

[0147] By implementing the above embodiments, combining simulation verification and formal verification, multi-dimensional functional equivalence verification is performed on the code before and after the conversion. This not only allows for the discovery of actual operational differences through waveform comparison, but also enables the logical proof to cover the entire input space, thus comprehensively ensuring the functional correctness of the conversion results. This addresses the problem of insufficient coverage by a single verification method and significantly improves the reliability of the conversion method in high-reliability chip design scenarios.

[0148] Furthermore, as an implementation of the foregoing method embodiments, this application also provides a code conversion apparatus for implementing the foregoing method embodiments. This apparatus embodiment corresponds to the foregoing method embodiments. For ease of reading, this code conversion apparatus embodiment will not repeat the details of the foregoing method embodiments one by one, but it should be understood that the apparatus in this application embodiment can correspondingly implement all the contents of the foregoing method embodiments. For example... Figure 2 As shown, the code conversion device 20 includes: a syntax parsing unit 201, a mapping establishment unit 202, an equivalence conversion unit 203, a compatibility optimization unit 204, and a code generation unit 205. The syntax parsing unit 201 parses the SystemVerilog code to be converted to obtain an initial abstract syntax tree (API). The mapping establishment unit 202 parses the type mapping relationships of the initial API and establishes a global type mapping table based on the parsing results. The equivalence conversion unit 203 performs semantic equivalence conversion on the syntax nodes in the initial API based on the global type mapping table to obtain an intermediate API. The compatibility optimization unit 204 optimizes the intermediate API to obtain a target API. The code generation unit 205 generates Verilog code corresponding to the SystemVerilog code based on the target API.

[0149] In some embodiments, the syntax parsing unit 201 is further configured to extract lexical units from the SystemVerilog code to obtain a sequence of lexical units; and to parse the sequence of lexical units using a recursive descent analysis algorithm based on preset syntax rules to generate an initial abstract syntax tree for structured representation.

[0150] In some embodiments, the syntax nodes in the initial abstract syntax tree include package nodes, enumeration definition nodes, structure definition nodes, and type definition nodes; the mapping establishment unit 202 is further configured to parse the package nodes in the initial abstract syntax tree to obtain a first mapping relationship between package name information and package definition information in the package nodes, wherein the package definition information includes type aliases, enumeration definitions, structure definitions, local constants, and function definitions; parse the enumeration definition nodes in the initial abstract syntax tree to obtain a second mapping relationship between enumeration names and enumeration definition information in the enumeration definition nodes, wherein the enumeration definition information includes a list of enumeration variant constants and an enumeration bit width determined based on the enumeration variants; parse the structure definition nodes in the initial abstract syntax tree to obtain a third mapping relationship between structure names and structure definition information in the structure definition nodes, wherein the structure definition information includes a list of fields and field types; parse the type definition nodes in the initial abstract syntax tree to obtain a fourth mapping relationship between type aliases and primitive types in the type definition nodes; and establish a global type mapping table based on the first, second, third, and fourth mapping relationships.

[0151] In some embodiments, the equivalence conversion unit 203 is further configured to traverse the syntax nodes in the initial abstract syntax tree; for each current syntax node traversed from the initial abstract syntax tree, based on the global type mapping table, the syntax node is semantically equivalently converted according to the conversion method corresponding to the node type of the current syntax node to obtain an intermediate abstract syntax tree.

[0152] In some embodiments, the equivalence conversion unit 203 is further configured to: if the current syntax node is a basic type declaration node, determine the reference scenario information of the variable identifier corresponding to the basic type declaration node in the initial abstract syntax tree, and replace the basic type declaration node with the corresponding net type declaration node or register type declaration node based on the reference scenario information; if the current syntax node is an enumeration-related node, perform semantic equivalence conversion on the enumeration definition node, enumeration variable node, and enumeration reference node in the enumeration-related node based on the first mapping relationship in the global type mapping table; if the current syntax node is a structure-related node, perform semantic equivalence conversion on the structure-related node based on the second mapping relationship in the global type mapping table. Semantic equivalence conversion is performed on the structure definition nodes, structure variable nodes, and structure magnitude nodes in the body-related nodes. If the current syntax node is an interface-related node, semantic equivalence conversion is performed on the interface definition nodes, interface port nodes, interface method nodes, and interface instantiation nodes in the structure-related nodes based on the global type mapping table. If the current syntax node is a type alias reference node, the type alias reference node is replaced with the corresponding basic type node based on the third mapping relationship in the global type mapping table. If the current syntax node is a package reference node, the package-defined elements referenced by the package reference node are inlined into the package reference node based on the fourth mapping relationship in the global type mapping table.

[0153] In some embodiments, the equivalence conversion unit 203 is further configured to: if the current syntax node is a timing logic block node, then in response to the timing block subtype attribute of the timing logic block node being an edge-sensitive attribute, retain the edge-sensitive list in the timing logic block node and modify the node type identifier to a general timing logic identifier; in response to the timing block subtype attribute being a level-sensitive attribute, replace the sensitivity list of the timing logic block node with a preset fully sensitive identifier and modify the node type identifier to a general timing logic identifier; if the current syntax node is a delay-continuous assignment node, obtain the delay type feature of the delay information field in the delay-continuous assignment node, and based on the delay type feature, keep the value or reference relationship of the delay information field unchanged, and perform fixed value delay conversion or parameterized variable delay conversion on the delay-continuous assignment node.

[0154] In some embodiments, the equivalence conversion unit 203 is further configured to, if the current syntax node is a port simplified declaration node, delete the preset type keyword in the port simplified declaration node and retain the port direction information and port bit width information in the port simplified declaration node to generate a standard port declaration node; if the current syntax node is an indefinite-width constant node, replace the indefinite-width constant node with a constant value literal node with a definite bit width based on the assignment target bit width information of the indefinite-width constant node in the initial abstract syntax tree.

[0155] In some embodiments, the compatibility optimization unit 204 is further configured to perform a first traversal operation, a second traversal operation, and a third traversal operation on the intermediate abstract syntax tree respectively to obtain a target abstract syntax tree; wherein, if a constant expression node is detected in the intermediate abstract syntax tree based on the first traversal operation, the constant expression node is evaluated to obtain an evaluation result, and the constant expression node is replaced with a literal node corresponding to the evaluation result; if a conflicting identifier is detected based on the second traversal operation, the conflicting identifier is renamed according to a preset suffix generation rule; if a redundant node not referenced by other nodes is detected based on the third traversal operation, the redundant node is deleted.

[0156] In some embodiments, the code generation unit 205 is further configured to traverse each syntax node in the target abstract syntax tree according to a preset node processing order, wherein the preset node processing order is module node, port node, declaration node, assignment node and timing logic node in sequence; based on the preset mapping relationship between node type and Verilog syntax template, each syntax node traversed from the target abstract syntax tree is converted into a code fragment conforming to the preset Verilog syntax specification; the code fragment is then format-optimized to obtain Verilog code.

[0157] In some embodiments, the code generation unit 205 is further configured to generate a corresponding hierarchical indentation prefix for each code segment based on a preset unit indentation amount and the hierarchical depth information of each syntax node in the target abstract syntax tree; perform newline insertion processing on continuous assignment expressions and conditional branch expressions in the code segment that satisfy preset newline conditions at preset operator positions; add transformation source annotation information to the syntax nodes generated by semantic equivalence transformation in the code segment, wherein the transformation source annotation information is used to indicate the syntax type of the SystemVerilog code corresponding to the syntax structure; and use the code segment with added hierarchical indentation prefix, newline insertion processing, and added transformation source annotation information as Verilog code.

[0158] In some embodiments, the code conversion device 20 further includes a code verification unit, configured to acquire a first simulation output waveform corresponding to the SystemVerilog code and a second simulation output waveform corresponding to the Verilog code; perform a clock-cycle bit-level comparison of the first simulation output waveform and the second simulation output waveform to obtain a first verification result; perform expression conversion processing on the SystemVerilog code and the Verilog code respectively to obtain a first constraint solution expression corresponding to the SystemVerilog code and a second constraint solution expression corresponding to the Verilog code; perform logical equivalence proof on the first constraint solution expression and the second constraint solution expression to obtain a second verification result; and generate a functional equivalence verification report based on the first verification result and the second verification result, wherein the functional equivalence verification report is used to indicate whether the Verilog code meets the preset equivalence conversion requirements.

[0159] This application also provides a computer-readable storage medium storing computer-executable instructions or computer programs, which, when executed by a processor, will cause the processor to perform any step of the code conversion method provided in this application.

[0160] In some embodiments, the computer-readable storage medium may be a random access memory (RAM), a read-only memory (ROM), flash memory, a magnetic surface memory, an optical disc or a compact disc read-only memory (CD-ROM), or other such memory; it may also be a variety of devices that include one or any combination of the above-mentioned memories.

[0161] In some embodiments, computer-executable instructions may take the form of programs, software, software modules, scripts, or code, written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and may be deployed in any form, including as stand-alone programs or as modules, components, subroutines, or other units suitable for use in a computing environment.

[0162] In some embodiments, computer-executable instructions may, but do not necessarily, correspond to files in a file system, and may be stored as part of a file that holds other programs or data, for example, in one or more scripts in a HyperText Markup Language (HTML) document, in a single file dedicated to the program in question, or in multiple co-located files (e.g., files that store one or more modules, subroutines, or code sections).

[0163] In some embodiments, computer-executable instructions may be deployed to execute on an electronic device, or on multiple electronic devices located at one location, or on multiple electronic devices distributed across multiple locations and interconnected via a communication network.

[0164] like Figure 3 As shown, this application also provides an electronic device 30, including a memory 310, a processor 320, and a computer program 311 stored in the memory 310 and executable on the processor. When the processor 320 executes the computer program 311, it implements any step of the above-described code conversion method.

[0165] This application also provides a computer program product comprising a computer program or computer-executable instructions stored in a computer-readable storage medium. A processor of an electronic device reads the computer program or computer-executable instructions from the computer-readable storage medium and executes the computer program or computer-executable instructions, causing the electronic device to perform any step of the code conversion method described above.

[0166] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A code conversion method, characterized in that, include: The SystemVerilog code to be transformed is parsed to obtain an initial abstract syntax tree; The initial abstract syntax tree is parsed for type mapping relationships, and a global type mapping table is established based on the parsing results; Based on the global type mapping table, semantic equivalence transformation is performed on the syntax nodes in the initial abstract syntax tree to obtain an intermediate abstract syntax tree. The intermediate abstract syntax tree is optimized to obtain the target abstract syntax tree; Based on the target abstract syntax tree, generate Verilog code corresponding to the SystemVerilog code.

2. The code conversion method according to claim 1, characterized in that, The SystemVerilog code to be transformed is parsed to obtain an initial abstract syntax tree, including: Lexical units are extracted from the SystemVerilog code to obtain a sequence of lexical units; The lexical unit sequence is parsed using a recursive descent analysis algorithm based on preset grammar rules to generate the initial abstract syntax tree with a structured representation.

3. The method according to claim 1, characterized in that, The syntax nodes in the initial abstract syntax tree include package nodes, enumeration definition nodes, structure definition nodes, and type definition nodes; the step of parsing the type mapping relationship of the initial abstract syntax tree and establishing a global type mapping table based on the parsing result includes: Parse the package nodes in the initial abstract syntax tree to obtain the first mapping relationship between the package name information and the package definition information in the package nodes, wherein the package definition information includes type aliases, enumeration definitions, structure definitions, local constants and function definitions; Parse the enumeration definition node in the initial abstract syntax tree to obtain a second mapping relationship between the enumeration name and the enumeration definition information in the enumeration definition node, wherein the enumeration definition information includes a list of enumeration variant constants and an enumeration bit width determined based on the enumeration variant; Parse the structure definition node in the initial abstract syntax tree to obtain a third mapping relationship between the structure name and the structure definition information in the structure definition node, wherein the structure definition information includes a field list and field types; Parse the type definition nodes in the initial abstract syntax tree to obtain the fourth mapping relationship between the type aliases in the type definition nodes and the original types; Based on the first mapping relationship, the second mapping relationship, the third mapping relationship, and the fourth mapping relationship, the global type mapping table is established.

4. The code conversion method according to claim 3, characterized in that, The step of performing semantic equivalence transformation on the syntax nodes in the initial abstract syntax tree based on the global type mapping table to obtain an intermediate abstract syntax tree includes: The syntax nodes in the initial abstract syntax tree are traversed. For each current syntax node traversed from the initial abstract syntax tree, based on the global type mapping table, the syntax node is semantically equivalently transformed according to the transformation method corresponding to the node type of the current syntax node to obtain the intermediate abstract syntax tree.

5. The code conversion method according to claim 4, characterized in that, The step of performing semantic equivalence transformation on the syntax node based on the global type mapping table and according to the transformation method corresponding to the node type of the current syntax node to obtain the intermediate abstract syntax tree includes: If the current syntax node is a basic type declaration node, then determine the reference scenario information of the variable identifier corresponding to the basic type declaration node in the initial abstract syntax tree, and replace the basic type declaration node with the corresponding net type declaration node or register type declaration node based on the reference scenario information. If the current syntax node is an enumeration-related node, then based on the first mapping relationship in the global type mapping table, semantic equivalence conversion is performed on the enumeration definition node, enumeration variable node and enumeration reference node in the enumeration-related node respectively; If the current syntax node is a structure-related node, then based on the second mapping relationship in the global type mapping table, semantic equivalence conversion is performed on the structure definition node, structure variable node and structure magnitude node in the structure-related node respectively; If the current syntax node is an interface-related node, then based on the global type mapping table, semantic equivalence conversion is performed on the interface definition node, interface port node, interface method node and interface instantiation node in the structure-related node respectively; If the current syntax node is a type alias reference node, then based on the third mapping relationship in the global type mapping table, the type alias reference node is replaced with the corresponding basic type node; If the current syntax node is a package reference node, then based on the fourth mapping relationship in the global type mapping table, the package-defined elements referenced by the package reference node are inlined into the package reference node.

6. The code conversion method according to claim 5, characterized in that, The step of performing semantic equivalence transformation on the syntax node according to the transformation method corresponding to the node type of the current syntax node based on the global type mapping table to obtain the intermediate abstract syntax tree further includes: If the current syntax node is a timing logic block node, then in response to the timing block subtype attribute of the timing logic block node being an edge-sensitive attribute, the edge-sensitive list in the timing logic block node is retained and the node type identifier is modified to a general timing logic identifier; in response to the timing block subtype attribute being a level-sensitive attribute, the sensitivity list of the timing logic block node is replaced with a preset fully sensitive identifier and the node type identifier is modified to the general timing logic identifier. If the current syntax node is a continuous delay assignment node, then the delay type feature of the delay information field in the continuous delay assignment node is obtained, and based on the delay type feature, the numerical value or reference relationship of the delay information field is kept unchanged, and the continuous delay assignment node is subjected to fixed numerical delay conversion or parameterized variable delay conversion.

7. The code conversion method according to claim 6, characterized in that, The step of performing semantic equivalence transformation on the syntax node according to the transformation method corresponding to the node type of the current syntax node based on the global type mapping table to obtain the intermediate abstract syntax tree further includes: If the current syntax node is a port simplified declaration node, then delete the preset type keyword in the port simplified declaration node, and retain the port direction information and port bit width information in the port simplified declaration node to generate a standard port declaration node; If the current syntax node is an indefinite-width constant node, then based on the assignment target bit width information of the indefinite-width constant node in the initial abstract syntax tree, the indefinite-width constant node is replaced with a constant value literal node with a definite bit width.

8. The code conversion method according to claim 1, characterized in that, The optimization process of the intermediate abstract syntax tree to obtain the target abstract syntax tree includes: The first traversal operation, the second traversal operation, and the third traversal operation are performed on the intermediate abstract syntax tree respectively to obtain the target abstract syntax tree; Specifically, if a constant expression node in the intermediate abstract syntax tree is detected based on the first traversal operation, the constant expression node is evaluated to obtain an evaluation result, and the constant expression node is replaced with a literal node corresponding to the evaluation result; if a conflicting identifier is detected based on the second traversal operation, the conflicting identifier is renamed according to a preset suffix generation rule; if a redundant node not referenced by other nodes is detected based on the third traversal operation, the redundant node is deleted.

9. The code conversion method according to claim 1, characterized in that, The process of generating Verilog code corresponding to the SystemVerilog code based on the target abstract syntax tree includes: The target abstract syntax tree is traversed and processed according to a preset node processing order, wherein the preset node processing order is module node, port node, declaration node, assignment node and timing logic node in sequence. Based on the preset mapping relationship between node types and Verilog syntax templates, each syntax node traversed from the target abstract syntax tree is converted into a code fragment that conforms to the preset Verilog syntax specification. The code snippet is then formatted to obtain the Verilog code.

10. The code conversion method according to claim 9, characterized in that, The process of optimizing the format of the code fragment to obtain the Verilog code includes: Based on the preset unit indentation amount and the hierarchical depth information of each syntax node in the target abstract syntax tree, a corresponding hierarchical indentation prefix is ​​generated for each code segment; For consecutive assignment expressions and conditional branch expressions in the code snippet that meet the preset newline conditions, newline characters are inserted at the preset operator positions; Add transformation source annotation information to the syntax nodes generated by semantic equivalence transformation in the code snippet, wherein the transformation source annotation information is used to indicate the syntax type of the SystemVerilog code corresponding to the syntax structure; The code snippet with the aforementioned hierarchical indentation prefix, the aforementioned newline insertion processing, and the aforementioned transformation source comment information is used as the Verilog code.

11. The code conversion method according to claim 1, characterized in that, The code conversion method also includes: Obtain the first simulation output waveform corresponding to the SystemVerilog code and the second simulation output waveform corresponding to the Verilog code; A clock-cycle bit-level comparison is performed between the first simulated output waveform and the second simulated output waveform to obtain the first verification result; The SystemVerilog code and the Verilog code are respectively subjected to expression transformation processing to obtain the first constraint solution expression corresponding to the SystemVerilog code and the second constraint solution expression corresponding to the Verilog code; Logical equivalence proof is performed on the first constraint solution expression and the second constraint solution expression to obtain the second verification result; A functional equivalence verification report is generated based on the first verification result and the second verification result, wherein the functional equivalence verification report is used to indicate whether the Verilog code meets the preset equivalence transformation requirements.

12. A code conversion device, characterized in that, include: The syntax parsing unit is used to parse the SystemVerilog code to be transformed to obtain an initial abstract syntax tree; The mapping establishment unit is used to parse the type mapping relationship of the initial abstract syntax tree and establish a global type mapping table based on the parsing result; An equivalence conversion unit is used to perform semantic equivalence conversion on the syntax nodes in the initial abstract syntax tree based on the global type mapping table to obtain an intermediate abstract syntax tree; A compatibility optimization unit is used to optimize the intermediate abstract syntax tree to obtain the target abstract syntax tree; The code generation unit is used to generate Verilog code corresponding to the SystemVerilog code based on the target abstract syntax tree.

13. An electronic device, comprising: A memory and a processor, characterized in that the processor, when executing a computer program stored in the memory, implements the steps of the code conversion method as described in any one of claims 1 to 11.

14. A computer-readable storage medium having stored thereon computer-executable instructions or a computer program, characterized in that, When the computer-executable instructions or the computer program are executed by a processor, the steps of the code conversion method as described in any one of claims 1 to 11 are implemented.

Images