Methods, systems, and media for generating or processing hardware description language code

Abstract

Methods, systems, and media for generating or processing hardware description language code are disclosed. The method includes: obtaining an input code written in a host programming language, where the input code includes a plurality of constructions defined by a library associated with the host programming language, the constructions being syntax mapped to respective constructions of a target HDL; executing the input code using an interpreter or runtime environment of the host programming language, where the executing includes dynamically parsing, via the interpreter or runtime environment, the plurality of constructs within the input code based on an execution stream of the input code, constructing an internal representation of a hardware design specified by the input code; and after the execution, generating output code of the target HDL based at least in part on the internal representation, the output code representing the hardware design. According to the scheme, the efficiency and reliability of hardware design can be improved.

Description

Technical Field

[0001] This disclosure relates in various aspects to computer-aided design, and more specifically, to methods, systems, and media for generating or processing hardware description language code. Background Technology

[0002] In the current field of integrated circuit design, especially in the design of System-on-a-Chip (SoC), Hardware Description Languages ​​(HDLs), such as Verilog, SystemVerilog, and VHDL, play a crucial role. Design engineers use these languages ​​to describe complex digital circuits and systems. To translate these HDL descriptions into actual hardware or perform simulation verification, a complex set of Electronic Design Automation (EDA) toolchains is required. These toolchains typically include operations such as parsing, compiling, simulating, and synthesizing HDL code. Traditional EDA tools, when processing HDL code, usually employ compiler front-end technologies based on lexical analysis (such as Lex) and syntax analysis (such as Yacc) to parse the code, construct an internal representation, and perform subsequent processing based on this representation.

[0003] However, existing design flows based on traditional HDL and EDA toolchains have some inherent limitations. First, standard hardware description languages ​​themselves lack the expressive power and flexibility of modern software programming languages, making it difficult to directly utilize high-level programming paradigms to improve the modularity and reusability of designs. Second, traditional EDA tool processing flows often strictly separate the parsing, semantic analysis, inspection, and code generation stages. This not only increases the complexity of tool development but may also lead to design errors (such as basic syntax or reference errors) being discovered only at a later stage of the design flow, thereby reducing the efficiency of design iteration.

[0004] While there are methods that attempt to generate HDL code from high-level language code (such as Chisel based on Scala), these methods often introduce a steep learning curve, and the relationship between the generated HDL code and its high-level language source code may not be direct enough, posing new challenges for debugging and verification.

[0005] Therefore, there is a need for an improved method, system, and medium for generating or processing hardware description language code. Summary of the Invention

[0006] The embodiments of this disclosure are made to solve the aforementioned technical problems, and their purpose is to provide an improved method, system, and medium for generating or processing hardware description language code. The embodiments of this disclosure utilize the execution environment of the host programming language to dynamically parse and process the construction mapped to the target HDL, thereby achieving a more efficient, flexible, and reliable hardware design process.

[0007] According to a first aspect of this disclosure, a computer-implemented method for generating Hardware Description Language (HDL) code is provided, the method comprising: acquiring input code written in a host programming language, wherein the input code includes a plurality of constructs defined by a library associated with the host programming language, the constructs being syntactically mapped to corresponding constructs in a target HDL, the target HDL including at least one of Verilog, SystemVerilog, or VHDL; executing the input code using an interpreter or runtime environment of the host programming language, wherein the execution includes: dynamically parsing the plurality of constructs within the input code based on the execution flow of the input code via the interpreter or runtime environment to construct an internal representation of a hardware design specified by the input code; and generating output code of the target HDL representing the hardware design, at least in part based on the internal representation.

[0008] According to a further embodiment of this disclosure, dynamically parsing multiple constructs within input code includes: parsing the target HDL semantic type of a construct defined within the input code that represents at least one of a nested structure or a multidimensional array.

[0009] According to a further embodiment of this disclosure, dynamically parsing multiple constructs within input code includes: verifying hierarchical references to elements within instantiated module constructs or entity constructs based on target HDL semantics defined within the input code.

[0010] According to a further embodiment of this disclosure, the execution further includes performing at least one of a type check or a bit-width check on one or more elements within the internal representation during execution.

[0011] According to a further embodiment of this disclosure, at least one of performing a type check or a bit-width check is applied to port connections during the instantiation of a module construction or entity construction within the input code.

[0012] According to a further embodiment of this disclosure, performing at least one of type checking or bit-width checking includes performing symbol checking, wherein one or more parameters or generic parameters defined in the input code are treated as symbolic variables during the checking process.

[0013] According to a further embodiment of this disclosure, performing symbol checking includes utilizing a satisfiability modulus (SMT) solver.

[0014] According to a further embodiment of this disclosure, performing at least one of type checking or bit-width checking includes enforcing the following rules: the corresponding operands of binary arithmetic operators or binary bitwise operators in the input code have the same bit width; the corresponding operands of Boolean operators in the input code have a bit width of 1.

[0015] According to a further embodiment of this disclosure, the host programming language is Python.

[0016] According to a further embodiment of this disclosure, at least one of the plurality of constructs utilizes Python's with statement to define a scope corresponding to at least one of the following in the target HDL: Verilog or

[0017] In SystemVerilog, this can be an always block, a conditional block, or a generate block, or in VHDL, a process block.

[0018] According to further embodiments of this disclosure, multiple constructs include overloaded operators of the host programming language, which correspond to arithmetic operators or bitwise operators of the target HDL.

[0019] According to a further embodiment of this disclosure, multiple constructs include named functions that correspond to HDL operators that cannot be directly mapped to operators of the host programming language. The named functions include functions for at least one of the following: ternary conditional selection, reduction operation, or target HDL-specific logical shift operation.

[0020] According to further embodiments of this disclosure, multiple constructs include constructs for defining and accessing members of a structure type, the structure type simulating a structure type in a target HDL, wherein member access utilizes dot notation; or multiple constructs include constructs for defining and accessing a multidimensional array, the multidimensional array simulating a multidimensional array in a target HDL, wherein array access utilizes index notation.

[0021] According to further embodiments of this disclosure, multiple constructs include representing HDL literals as strings within input code, and wherein the execution includes parsing the string to determine values ​​and bit widths according to HDL semantics.

[0022] According to a further embodiment of this disclosure, generating output code includes generating code that maintains a one-to-one structural correspondence with the hardware design specified by the input code.

[0023] According to a further embodiment of this disclosure, the internal representation includes an abstract syntax tree (AST).

[0024] According to a further embodiment of this disclosure, when the target HDL is VHDL, the plurality of constructs further include corresponding host language constructs for defining the entity construct and the architecture construct of the VHDL.

[0025] According to a second aspect of this disclosure, a computer-implemented method for processing Hardware Description Language (HDL) source code is provided, the method comprising: receiving target HDL source code, the target HDL source code including at least one of Verilog source code, SystemVerilog source code, or VHDL source code; translating the target HDL source code into intermediate code written in a host programming language, wherein the intermediate code includes a plurality of constructs defined by libraries associated with the host programming language, the constructs being syntactically mapped to corresponding constructs in the target HDL; executing the intermediate code using an interpreter or runtime environment of the host programming language, wherein the execution includes dynamically resolving the plurality of constructs, constructing an internal representation, and performing checks based on the target HDL semantics; and generating output, at least in part based on the internal representation or the result of the performance checks, the output including at least one of generated HDL code or an error report.

[0026] According to a third aspect of this disclosure, a system for generating a Hardware Description Language (HDL) is provided, the system comprising: one or more memories; and one or more processors coupled to the one or more memories, the one or more processors being configured to perform the methods provided in this disclosure.

[0027] According to a fourth aspect of this disclosure, a non-transient computer-readable storage medium is provided having instructions stored thereon that, when executed by a processor, cause the processor to perform the methods provided in this disclosure.

[0028] Through the technical solutions of the various embodiments of this disclosure, one or more of the following technical effects can be achieved:

[0029] By designing a method to generate HDL code using a host programming language, the efficiency and reliability of hardware design can be improved. Syntactic mapping between the host programming language and the corresponding constructs of the target HDL reduces learning costs and increases intuitiveness. Maintaining a one-to-one structural correspondence between input code and generated target HDL code simplifies debugging and verification processes. Dynamically parsing and verifying HDL semantic types and hierarchical references during execution allows for the timely detection and reporting of errors related to type, structure access, or module references early in the design process and even during coding, improving coding efficiency and the timeliness of error detection. Integrated type and bit-width checking, particularly symbol checking capabilities and stricter checking rules, can uncover potential design flaws (such as bit-width mismatches) that are difficult to detect with traditional tools or only discovered later, improving design reliability. By providing a complete workflow for translating and processing existing HDL code into a host programming language format, the advantages of the embodiments of this disclosure can be applied to existing design projects. Attached Figure Description

[0030] To more clearly illustrate the embodiments of this disclosure, the accompanying drawings used in the embodiments will be briefly described below. Obviously, the drawings described below are merely some embodiments of this disclosure, and those skilled in the art can obtain other drawings based on these drawings without any creative effort.

[0031] Figure 1 This is a block diagram of an exemplary computer system that can be used to implement methods according to some embodiments of this disclosure.

[0032] Figure 2 This is a functional block diagram of an exemplary system for generating HDL code according to some embodiments of the present disclosure.

[0033] Figure 3 This is a flowchart of an example method for generating HDL code according to some embodiments of the present disclosure.

[0034] Figure 4 This is a flowchart of another example method for generating HDL code according to some embodiments of this disclosure.

[0035] Figure 5 This is a flowchart of an example method for processing HDL source code according to some embodiments of the present disclosure.

[0036] Figure 6 This is a flowchart of another example method for processing HDL source code according to some embodiments of this disclosure.

[0037] Figure 7 This is an exemplary illustration of the syntax mapping and structural correspondence between the host programming language code construct and the target HDL code it generates, according to some embodiments of this disclosure.

[0038] Figure 8 This is another exemplary illustration, according to some embodiments of the present disclosure, showing the syntax mapping and structural correspondence between the host programming language code construct and the target HDL code it generates.

[0039] Figure 9 These are exemplary illustrations showing dynamic verification during the execution of host programming language code, according to some embodiments of this disclosure. Detailed Implementation

[0040] Certain aspects and embodiments of this disclosure are provided below. Some of these aspects and embodiments may be applied independently, and some may be combined, as will be apparent to those skilled in the art. Specific details are set forth in the following description for purposes of explanation in order to provide a thorough understanding of the various embodiments of this application. However, it will be apparent, however, that the various embodiments may be practiced without these specific details. The accompanying drawings and descriptions are not intended to be limiting.

[0041] The following description provides only exemplary embodiments and is not intended to limit the scope, applicability, or configuration of this disclosure. Rather, the subsequent description of exemplary embodiments will provide those skilled in the art with enabling descriptions for implementing the exemplary embodiments. It should be understood that various changes may be made to the function and arrangement of the elements without departing from the spirit and scope of this application as set forth in the appended claims.

[0042] As mentioned above, there is a need to use high-level programming languages ​​to write or generate HDL code. However, existing methods for generating HDL code from high-level programming language code have shortcomings such as steep learning curves and insufficiently direct relationships between target code and high-level language source code.

[0043] The embodiments of this disclosure provide a scheme for generating Hardware Description Language (HDL) code, which utilizes the mapping between the construct of the host programming language and the construct of the target HDL (e.g., Verilog, SystemVerilog, or VHDL) to overcome the shortcomings of existing schemes.

[0044] Figure 1 This is a block diagram of an exemplary computer system 100 that can be used to implement methods according to some embodiments of this disclosure. The computer system 100 can be a variety of computing devices, such as, but not limited to, a desktop computer, a laptop computer, a server, a workstation, or any other device capable of executing instructions to process data. The computer system 100 provides a hardware platform for performing the methods described in this disclosure.

[0045] like Figure 1 As shown, a computer system 100 typically includes at least one processor 110 and at least one memory 120 coupled to the at least one processor. The processor 110 may be a central processing unit (CPU), a microprocessor (MPU), a graphics processing unit (GPU), or any other control logic circuit capable of processing data and executing instructions. The processor 110 can be used to execute instructions (e.g., instructions stored in memory) to implement the functions described in this disclosure.

[0046] The computer system 100 also includes at least one memory 120. Memory 120 can be any computer-readable storage medium and any combination thereof, including volatile memory (e.g., random access memory RAM) and non-volatile memory (e.g., read-only memory ROM, flash memory, hard disk drive HDD, solid-state drive SSD, etc.). Memory 120 is communicatively coupled to processor 110 (e.g., via bus 150).

[0047] Memory 120 may be configured to store data and instructions 122. When instructions 122 are executed by processor 110, processor 110 may perform the methods described herein. For example, instructions 122 may include an operating system, an application program, and specific instruction modules that implement the operations described herein. Specifically, memory 120 may store an interpreter or runtime environment 123 of a host programming language (e.g., a Python runtime environment) for executing input code. Memory 120 may also store data to be processed, such as input code 124 written in the host programming language, and an internal representation 126 of a hardware design dynamically constructed during the execution of input code 124 (e.g., an abstract syntax tree). Furthermore, memory 120 may also store output code 128 (e.g., target HDL code) generated by the method, and target HDL source code 129 that serves as input when implementing the complete workflow.

[0048] The computer system 100 may also optionally include interfaces for communicating with external devices or networks. For example, it may include an input interface 130 (e.g., connected to a keyboard, mouse, file system interface, network interface card) to receive user input or code files, and an output interface 140 (e.g., connected to a monitor, printer, file system interface, network interface card) to present results or output generated files.

[0049] Processor 110, memory 120, input interface 130, output interface 140, and other components in the system (if present) can be interconnected via one or more buses 150. Bus 150 can be any type of bus structure, such as address bus, data bus, control bus, etc.

[0050] It should be understood that Figure 1 The computer system 100 shown is merely an exemplary configuration. Those skilled in the art can modify or extend this configuration according to actual application needs. For example, it may include multiple processors, a distributed storage system, a dedicated hardware accelerator, or a virtual computing system, a cloud computing system, or various combinations thereof, all of which are within the scope of this disclosure.

[0051] Now refer to Figure 2A block diagram of an exemplary system 200 for generating HDL code according to some embodiments of the present disclosure is shown. The functionality of system 200 can be achieved, for example, through... Figure 1 The computer system 100 shown executes instructions 122 stored in memory 120 to achieve this.

[0052] System 200 may include an input receiver 210. Input receiver 210 may be configured to receive code to be processed (e.g., from user input, a file system, or a network interface). Depending on the embodiment or workflow, input receiver 210 may receive input code 124 written in a host programming language, or receive target HDL source code 129 (e.g., Verilog source code, SystemVerilog source code, or VHDL source code). Hereinafter, input code written in a host programming language and to be converted to target HDL source code is sometimes referred to as Xlog code, and the library defining the associated constructs is referred to as an Xlog library.

[0053] In some preferred embodiments of this disclosure, system 200 may include an optional translator 215. Translator 215 may receive target HDL source code 129 provided by input receiver 210 and parse and / or translate it into functionally equivalent intermediate code written in the host programming language (e.g., which may further serve as input code 124 to be converted into final HDL code), which is then processed. This translation process is intended to convert existing HDL designs into a format that can be processed by the core execution engine of system 200, thereby allowing, for example, processing of existing HDL implications, combining HDL code with high-level language code, and so on.

[0054] System 200 may include a host execution environment 220. Host execution environment 220 corresponds to an interpreter or runtime environment 123 of the host programming language in computer system 100, such as a Python interpreter. Host execution environment 220 may receive input code 124 (whether directly provided or generated by translator 215, as described above) and may be used to execute that code according to the rules of the host programming language. Host execution environment 220 may be used to execute input code.

[0055] System 200 may include a dynamic parser and validator 230. The dynamic parser and validator 230 may be integrated with or work in conjunction with the host execution environment 220. The dynamic parser and validator 230 is triggered when the host execution environment 220 encounters a construct defined by a specific library in the input code 124. It can parse (e.g., parse in real-time) the meaning of these constructs based on the current execution flow and context to dynamically parse multiple constructs within the input code. Furthermore, preferably, the dynamic parser and validator 230 is also used to perform HDL semantic verification during the parsing process, such as parsing the type of nested structures or multidimensional arrays, verifying hierarchical references to elements within instantiated modules, etc. By performing dynamic parsing and verification during execution, immediate error detection can be achieved.

[0056] The results of dynamic parsing can be used to construct or update an internal representation 126 of the hardware design, which may be stored, for example, in an internal representation storage 240. Preferably, the internal representation 126 includes an abstract syntax tree (AST). Alternatively, the internal representation can be other data structures suitable for representing the structure and semantics of the hardware design. The internal representation 126 can capture information about the hardware design specified by the input code 124.

[0057] In some examples, system 200 may include an optional symbol checker 250. The symbol checker 250 may be invoked by the dynamic resolver and verifier 230 during execution, for example, or may operate on the internal representation 126 at a specific stage of execution. It can be used to perform more in-depth type and / or bit-width checks, such as symbol checking (e.g., utilizing an SMT solver), and optionally enforce specific strict rules. This checking can be applied to various aspects of the hardware design, including port connections at module instantiation.

[0058] After execution, the HDL code generator 260 can generate output code 128 of the target HDL (e.g., Verilog, SystemVerilog, or VHDL) based on the final determined internal representation 126 in the internal representation storage 240. Preferably, the HDL code generator 260 can be configured to generate code that maintains a one-to-one structural correspondence with the design represented by the input code 124.

[0059] Output generator 270 can be used to generate the final output. Depending on the execution flow, if the flow is intended to generate HDL code, output generator 270 can output output code 128 generated by HDL code generator 260. If an error is detected during execution (e.g., by dynamic parser and validator 230 or symbol checker 250), or if the execution flow is intended to perform checks, output generator 270 can generate an error report 229 containing error information. In other words, the output of output generator 270 can be at least one of the generated output code 128 or error report 229.

[0060] Figure 2 The components described herein represent an exemplary logical partition of system 200. Depending on specific needs, system 200 may include more or fewer components, and these components may be combined and / or partitioned in various ways. In a practical implementation, these components may be embodied as hardware, software (such as different portions or sets of instructions 122 stored in memory 120 and executed by processor 110), firmware, or any combination thereof. Specific details regarding the operation of each component can be found in the description below.

[0061] Figure 3 This is a flowchart of an example method 300 for generating HDL code according to some embodiments of the present disclosure.

[0062] Reference Figure 3 Method 300 may include: operation 310, obtaining input code (e.g., input code 124) written in a host programming language. The input code includes multiple constructs defined by libraries associated with the host programming language, which are syntactically mapped to corresponding constructs in the target HDL. The target HDL includes at least one of Verilog, SystemVerilog, or VHDL. Preferably, the host programming language is Python. Alternatively, the host programming language may be other high-level programming languages, such as Go, Rust, etc.

[0063] Method 300 may also include: operation 320, using an interpreter or runtime environment of the host programming language (such as...) Figure 1 The interpreter or runtime environment (123) is used to execute the input code. Figure 1 Input code 124).

[0064] Operation 320 includes: Operation 330, which, via an interpreter or runtime environment, dynamically parses multiple constructs (such as...) within the input code based on the execution flow of the input code. Figure 3 Operation 330 is shown; and operation 340 constructs (or updates) the internal representation of the hardware design specified by the input code. Figure 1 (internal representation 126).

[0065] Preferably, the parsing operation includes resolving the target HDL semantic type (such as Verilog, SystemVerilog, or VHDL semantic type) of a construct defined within the input code, representing at least one of nested structures or multidimensional arrays. Preferably, the parsing operation also includes verifying hierarchical references to elements within instantiated module or entity constructs based on the HDL semantics (such as Verilog, SystemVerilog, or VHDL semantics) defined within the input code.

[0066] Figure 3 The diagram illustrates one possible implementation of this execution process. Specifically, operation 320 can be an iterative process. In each iteration, the constructions encountered by the current execution flow are dynamically parsed (operation 330), and the internal representation is constructed or updated based on the parsing results (operation 340). Subsequently, the process can be modified by judging operations (such as...). Figure 3 Operation 345 determines whether the input code has finished executing. If it has not finished (operation 345 determines "no"), the flow can return to operation 320 to continue executing the next part of the code. Dynamic processing of the code is allowed by interleaving parsing and internal representation construction during execution.

[0067] It should be understood that in some cases, iterative execution is not necessary.

[0068] After the input code has been executed (e.g., operation 345 determines "yes"), method 300 includes: operation 370, which, after execution, is at least partially based on the final constructed internal representation.

[0069] 126 generates output code 128 for the target HDL. This output code 128 indicates that the input code...

[0070] The hardware design described in 124. Although the examples above show output code being generated after execution, in some examples, output code may also be generated during execution.

[0071] Figure 4 This is a flowchart of another example method 400 for generating HDL code according to some embodiments of this disclosure. Compared with method 300, method 400 includes optional inspection operations.

[0072] Reference Figure 4 Method 400 may include: operation 410, obtaining input code written in the host programming language. This operation is related to... Figure 3 The operation is similar to 310.

[0073] Method 400 may further include: operation 420, using an interpreter or runtime environment of the host programming language to execute the input code. This operation is related to... Figure 3The operation is similar to 320.

[0074] During operation 420, method 400 may include: operation 430, dynamically resolving multiple constructs within the input code. This operation is related to... Figure 3 The operation is similar to 330.

[0075] During operation 420, immediately following operation 430, method 400 may include: operation 440, constructing or updating an internal representation of the hardware design. This operation is related to... Figure 3 The operation is similar to 340.

[0076] After constructing or updating the internal representation 126, during execution, method 400 preferably includes operation 450 to determine whether to perform a check. Operation 450 is used to determine whether a check needs to be performed on the currently processed element or the constructed internal representation 126.

[0077] If the result of operation 450 is "yes", then method 400 may include: operation 460, performing a check. Preferably, the check includes performing at least one of a type check or a bit-width check on one or more elements within the internal representation. Preferably, the check is applied to port connections during the instantiation of a module construction or entity construction within the input code. Preferably, the check includes performing a symbol check, wherein one or more parameters or generic parameters defined in the input code are treated as symbolic variables during the check. Preferably, the check is performed using a Satisfaction Modular Theory (SMT) solver. Preferably, a specific rule regarding operand bit-width is enforced; for example, the bit-width of the corresponding operand of a Boolean operator within the input code may be forced to be 1. Preferably, hierarchical references may be verified; or the target HDL semantic type may be resolved.

[0078] After performing check operation 460, or if the result of operation 450 is "no" (i.e., no check is performed), method 400 may proceed to operation 465 to determine if there is any more code to execute, thereby determining whether input code 124 has been executed completely. If it has not been executed completely (operation 465 determines "yes"), the process returns to operation 420 to continue execution.

[0079] If input code 124 has been executed (operation 465 is determined to be "no"), then method 400 may include: operation 470, after execution, generating the output code of the target HDL based at least in part on the final constructed internal representation. This operation is related to... Figure 3 The operation is similar to 370.

[0080] Figure 5 This is a flowchart of an example method 500 for processing HDL source code according to some embodiments of the present disclosure.

[0081] Reference Figure 5 Method 500 may include: operation 510, receiving target HDL source code (such as target HDL source code 129). The target HDL source code may be existing Verilog source code, SystemVerilog source code, or other source code written by the designer or others that requires processing or inspection.

[0082] VHDL source code.

[0083] Method 500 may then include: operation 520, translating the target HDL source code into intermediate code written in a host programming language (e.g., Python) (i.e., as input code 124). This translation operation can be performed by, for example... Figure 2 The translator 215 shown is executed. The generated intermediate code includes multiple constructs defined by libraries associated with the host programming language and syntactically mapped to corresponding constructs in the target HDL.

[0084] Method 500 may then include: operation 530, using an interpreter or runtime environment of the host programming language (e.g., interpreter or runtime environment 123) to execute intermediate code.

[0085] Operation 530 includes multiple sub-operations that are performed during the execution of the intermediate code. Specifically, operation 530 may include: operation 532, dynamically resolving multiple constructs within the intermediate code; operation 534, constructing / updating the internal representation of the hardware design (such as internal representation 126) based on the resolution results; and operation 536, performing checks based on HDL semantics. These checks may include, for example, type checking, bit-width checking, symbol checking, hierarchical reference verification, etc., as described above.

[0086] Figure 5 The diagram illustrates one possible implementation of this execution process, in which a judgment (as shown in operation 538) determines whether the intermediate code has finished executing. If it has not finished executing (operation 538 determines "no"), the process can return to operation 530 to continue execution.

[0087] Once the intermediate code has finished executing (operation 538 determines "yes"), method 500 may include: operation 540, generating output. This output is generated at least in part based on the internal representation constructed during execution or the result of checks performed in operation 536.

[0088] The output can take several forms. In some examples, the output may include the generated...

[0089] HDL code (such as) Figure 5As shown in Operation 542, this code can be a processed or validated target HDL representation. In other examples, such as when the process is primarily used for checking or when an error is detected, the output may include an error report (e.g., Figure 5 As shown in operation 544), the error report can, for example, indicate a problem found in the source code. In some other examples, the output may include both the generated HDL code and the error report. Figure 5 In the example shown, the output type is determined by operation 541, such as selectively outputting HDL code or error reports based on specific conditions (e.g., whether an error is detected or a preset goal of the process).

[0090] Figure 6 This is a flowchart of another example method 600 for processing HDL source code according to some embodiments of this disclosure. This flowchart may, for example, be a... Figure 5 A simplified representation of the flowchart.

[0091] Reference Figure 6 Method 600 may include: operation 610, receiving the target HDL source code. This operation is related to... Figure 5 The operation is similar to 510.

[0092] Method 600 may then include: operation 620, translating the target HDL source code into intermediate code. This operation is related to... Figure 5 The operation is similar to 520.

[0093] Method 600 may then include operation 630, executing the intermediate code. This operation may, for example, use an interpreter or runtime environment 123 of the host programming language.

[0094] During the execution of operation 630, method 600 may include: operation 632, dynamically resolving multiple constructs within intermediate code; operation 634, building / updating the internal representation of the hardware design; and operation 636, performing checks based on HDL semantics. These operations 632, 634, and 636 are respectively related to... Figure 5 The corresponding operations 532, 534, and 536 are similar.

[0095] Similarly, the execution process can be an iterative loop until the intermediate code has finished executing.

[0096] After the intermediate code has finished executing, method 600 may include operation 640, generating output. This output is also generated based on the internal representation or the result of the execution check.

[0097] For example, it can output HDL code, error reports, or a combination of both, depending on the implementation or user configuration. Similarly, the output type can be optionally selected.

[0098] The overall flow of the embodiments of this disclosure has been described in detail in the above examples, but some specific details of the operations have been omitted. The specific details of each operation will be described in detail below.

[0099] Figure 7 and Figure 8 These are exemplary illustrations illustrating the syntactic mapping and structural correspondence between host programming language code and the generated target HDL code, according to some embodiments of this disclosure. These illustrations aid in understanding the operation of the methods described in this disclosure, i.e., how constructs in the input code are syntactically mapped to corresponding constructs in the target HDL, and how the generated output code maintains a structural correspondence with the hardware design specified by the input code.

[0100] Figure 7 and Figure 8 The diagram schematically illustrates input code snippets 710 and 810 (e.g., Xlog code snippets). These input code snippets 710 and 810 represent code snippets written in the host programming language (e.g., Xlog).

[0101] A portion of the input code written in Python. Figure 7 and Figure 8 As shown, input code snippets 710 and 810 can contain multiple constructs defined by the Xlog library, such as statements for defining modules, ports, parameters, structs, multidimensional arrays, always blocks (e.g., using with statements), conditional logic, instantiation, or assignment or operations using overloaded operators / named functions. Although these constructs are written in the host programming language, their syntax is designed to mimic the corresponding constructs in the target HDL (e.g., Verilog, SystemVerilog, or VHDL).

[0102] By executing the input code containing input code fragments 710 and 810 (e.g., according to...) Figure 3 or Figure 4 The method performs processing on the syntax mapping. This syntax mapping is implicitly or explicitly completed during runtime dynamic resolution (e.g., operation 330) and / or internal representation construction (e.g., operation 340), where the construction of the host programming language is interpreted and converted into the corresponding hardware semantic structure in the internal representation 126.

[0103] Based on the final constructed internal representation, the HDL code generator can generate target HDL code snippets 720 and 820. Target HDL code snippets 720 and 820 represent a portion of the output code of the target HDL. Since the high-level programming language constructs are syntactically mapped to the target HDL constructs, the generated target HDL code snippets 720 and 820 typically maintain a clear and direct structural correspondence with the input code snippets 710 and 810. Preferably, this correspondence is one-to-one.

[0104] Figure 7 and Figure 8 The diagram also schematically illustrates this one-to-one structural correspondence (as shown by double-headed arrows 725 or 825). This correspondence means that designers can more easily understand the functionality of the code, debug it, and associate the output code with the design intent by comparing the input code snippets 710 and 810 with the target HDL code snippets 720 and 820.

[0105] For example, if input code snippet 810 defines a structure using `typedef.struct`, then the generated target HDL code snippet 820 will contain the corresponding `typedef struct packed` definition (for Verilog or SystemVerilog) or an equivalent VHDL record type definition (for VHDL). If input code snippet 710 uses the `with always_ff.posedge(clk):` block to describe sequential logic, then the generated target HDL code snippet 720 will contain the corresponding `always@(posedge clk)begin...end` block.

[0106] Figure 9 This is an exemplary illustration showing verification performed during the execution of host programming language code, according to some embodiments of this disclosure. As described above, this verification may include, for example, type resolution and / or hierarchical reference verification. This illustration helps to understand how the methods described in this disclosure can detect errors related to HDL semantics in real time during code execution, thereby improving design efficiency.

[0107] In some cases, the input code snippets in the input code may contain operations that require semantic validation, such as complex accesses to nested structures or multidimensional arrays, or hierarchical references to signals within the instantiated module. For example, the input code snippets may contain statements like cx[3][4][5].center.x = 1 or assign b = a.readptr[3:0].

[0108] When executing input code containing this input code fragment (operation 920, for example, corresponding to, for example...) Figure 3 Operation 320 or Figure 5 When performing operation 530, dynamic verification (operation 930) can be executed.

[0109] Operation 930 is, for example Figure 2 The dynamic parser and verifier 230 in the process are executed.

[0110] Operation 930 can be executed during code execution. For example, when execution reaches a statement that accesses nested structure members or multidimensional array elements, Operation 930 resolves the target HDL semantic type of the involved variables or expressions in real time, ensuring that the access is type-safe and conforms to the target HDL rules. Similarly, when execution reaches a statement involving hierarchical references (such as accessing the internal signal readptr of instance a), Operation 930 checks whether the reference path is valid, i.e., whether instance a actually exists and contains a signal named readptr, and whether the bit width of the access is appropriate.

[0111] If the validation in operation 930 passes, execution continues with subsequent code (as shown in operation 950). Preferably, if the validation in operation 930 fails (e.g., array index out of bounds, access to a non-existent structure member, invalid hierarchical reference, type mismatch, etc.), an immediate error report is triggered (as shown in operation 940). Immediate error reporting ensures that errors are detected and reported immediately when the code reaches the problematic point (e.g., reported to the user), rather than waiting until the entire file or design has been processed. Immediate error reporting can significantly shorten the debugging cycle and improve development efficiency.

[0112] Dynamic execution and resolution mechanism

[0113] The following sections will describe in detail the dynamic execution and parsing mechanisms according to the disclosed embodiments, which drive the processing of hardware design information by executing host programming language code.

[0114] As described in previous step 310, input code written in the host programming language (such as input code 124) can be obtained. The special feature of this input code is that it contains multiple "constructs". These constructs are defined by a specific library associated with the host programming language (e.g., a Python library called "Xlog"). These constructs are designed to syntactically mimic or map to corresponding constructs in the target HDL (e.g., Verilog, SystemVerilog, or VHDL). For example, the library might provide names like module, input, output, assign, and always_ff (used for...).

[0115] Functions, classes, or context managers such as Verilog / SystemVerilog, entity, port, architecture, process (for VHDL), etc., make the input code similar in form to the target HDL (e.g., ...). Figure 7 exemplified).

[0116] As described in the previous operation 320, the input code can be in the interpreter or runtime environment of the host programming language (such as interpreter or runtime environment 123) (e.g., Figure 2 The code is executed in a host execution environment 220. Unlike conventional methods, embodiments of this disclosure do not first perform a complete, independent parsing pass on the input code. Instead, the extraction of hardware design information occurs dynamically along with the execution of the code.

[0117] During execution, this execution action can be triggered when the interpreter or runtime environment 123 executes a specific construct in the input code 124 (e.g., calling a library-provided module() function, or accessing a library-provided with always_ff(...) block). Figure 2 The dynamic parser and verifier 230 (which corresponds to) Figure 3 Operation 330). The dynamic resolver and verifier 230 "dynamically resolve" the hardware semantics of the construct based on the current execution flow (e.g., which function is called, what parameters are passed, and which scope the code is executed in).

[0118] For example, when the Python code `dut = module('my_module')` is executed, the dynamic parser and validator 230 will understand that this is the beginning of a module definition, with the module name 'my_module', and will record this information. When `dut.clk = input()` is executed, it will understand that this defines an input port named 'clk' within the current module scope (represented by the `dut` object).

[0119] Based on the results of these dynamic parsings, the dynamic parser and verifier 230 can construct or update the internal representation 126 of the hardware design in real time (which corresponds to...). Figure 3 (Operation 340), the internal representation 126 is stored in the internal representation storage 240. Preferably, the internal representation 126 can be an abstract syntax tree (AST). Alternatively, the internal representation can be a graph-like data structure containing objects, attributes, and relationships, used to capture hardware design information such as modules, ports, connections, instances, assignments, and behavioral logic.

[0120] Dynamic type resolution and validation

[0121] This dynamic resolution process involves not only identifying the construct, but also understanding and verifying the target HDL semantics, especially for handling complex types and references.

[0122] In some examples, dynamically resolving multiple constructs within the input code includes: resolving the target construct defined within the input code that represents at least one of nested structures or multidimensional arrays.

[0123] HDL semantic types (such as Verilog, SystemVerilog, or VHDL semantic types). For example, when input code 124 defines a nested structure type similar to a Verilog struct (e.g., using a library-provided typedef.struct) or a record type in VHDL, or defines a multidimensional array with packed and unpacked dimensions, the dynamic parser and validator 230 can understand the structure and dimensions of these types during execution. When subsequent code attempts to access members of these complex types (e.g., my_struct.field_a) or array elements at specific indices (e.g., my_array[i][j]), the dynamic parser and validator 230 can resolve the target HDL semantic type of the variables (my_struct, my_array) involved in the access in real time, determining whether the access conforms to the defined structure (e.g., whether field_a is a member of my_struct, whether indices i, j are within array boundaries, etc.).

[0124] In other examples, dynamically resolving multiple constructs within the input code includes: verifying hierarchical references to elements within instantiated module constructs (in Verilog / SystemVerilog) or entity constructs (in VHDL, such as component instantiation) based on the target HDL semantics (e.g., Verilog, SystemVerilog, or VHDL semantics) defined within the input code. For example, when input code 124 contains a module / entity instantiation (e.g., the host language equivalent of instance_a = MyModule(...) or instance_a: MyEntity port map(...)) and subsequent code attempts to access signals or ports defined internally by that instance (e.g., instance_a.internal_signal), the dynamic parser and verifier 230 (e.g., ... Figure 9Operation 930) can verify the validity of the hierarchical reference when the access statement is executed. Verification may include checking whether the instance_a is indeed an instance of type MyModule (or, in VHDL, a component instance of type MyEntity), and whether an element named internal_signal exists in the definition of MyModule (or inside the port or architecture of MyEntity).

[0125] Dynamic type resolution and hierarchical reference verification performed during execution (such as...) Figure 9 Operation 930 provides immediacy. If parsing or validation fails (e.g., accessing a non-existent member, index out of bounds, referencing a non-existent internal signal, type mismatch, etc.), an error report can be generated immediately (e.g., ...). Figure 9 (As shown in operation 940), without waiting for the entire design process to complete. Optionally, the error report can include the line of code where the problem occurs. This can significantly improve debugging efficiency.

[0126] Through the above operations, after the entire execution process is completed, internal representation 126 contains complete, dynamically parsed, and preliminarily verified hardware design information. Subsequently, as... Figure 3 As shown in operation 370, the output code 128 of the target HDL can be generated based on this internal representation 126.

[0127] To achieve tight syntax mapping, embodiments of this disclosure utilize the characteristics of the host programming language.

[0128] The following description uses Python as an example of the host programming language. However, it should be understood that similar methods can be used to perform syntax mapping when using other high-level programming languages ​​as the host language.

[0129] In examples where Python is used as the host programming language, at least one of several constructs can utilize Python's `with` statement to define a scope corresponding to a specific block in the target HDL. For example, `with always_ff.posedge(clk):` can be used to define a sequential logic block that functionally and structurally corresponds to the `always_ff@(posedgeclk)begin...end` block in Verilog. In some embodiments, when the target HDL is VHDL, the host programming language constructs can use Python's context manager (the `with` statement) to define a `process` block corresponding to the VHDL. For example, the following host language code snippet:

[0130] with process(clk,rst):

[0131] If(rst)(

[0132] Assign(q.next,0)

[0133] ).Elif(rising_edge(clk))(

[0134] Assign(q.next,d) )

[0136] After being processed by the dynamic parser and validator 230 during execution, the construct can be used by the HDL code generator 260 to generate corresponding VHDL code, for example:

[0137]

[0138] Similarly, conditional logic can be represented using `with If(condition):`, `with Elif(condition):`, and `with Else():` (corresponding to `if`, `else if`, and `else`, respectively), and `with generate:` and `with For(...)` can be used to represent `generate` blocks (in Verilog / SystemVerilog) or similar generation structures in VHDL (such as `generate` statements). This use of `with` statements makes the scope of code blocks appear natural and clear in Python syntax.

[0139] Furthermore, one or more constructs can include overloaded operators from the host programming language, which may correspond to arithmetic or bitwise operators in the target HDL. For example, Python's +, -, *, &, |, ^, ~, <<, >> and comparison operators (==, !=, <, >, <=, >=) can be overloaded by this library (e.g., the Xlog library), allowing them to simulate the corresponding Verilog operations when executed in the host programming language (e.g., Xlog code), and to handle Verilog's bit width and type semantics. This makes the expression syntax very close to Verilog's native syntax.

[0140] For target HDL operators that cannot be directly mapped to host programming language operators, one or more constructs may include named functions. These named functions provide a way to implement specific HDL operations. For example, they may provide a way to implement ternary conditional selection (simulating the ?: operator, e.g.)

[0141] Named functions for SELECT(cond,true_val,false_val)), reduction operations (e.g., reduce_and(vector), reduce_or(vector)), target HDL-specific logical shift operations (e.g., tri_rshift, tri_lshift for arithmetic right / left shift respectively), or equivalence comparisons (e.g., tri_eq, tri_neq for === / !== respectively).

[0142] Embodiments of this disclosure support the definition and access to complex data types and structures similar to the target HDL. When the target HDL is VHDL, the multiple constructs may further include host language representations for VHDL-specific data types (e.g., std_logic, std_logic_vector, integer, boolean, enumeration types, etc.). The dynamic parser and verifier 230 is able to parse the declarations and uses of these types during execution and determine their bit width or range. For example, for a construct representing std_logic_vector(7 down to 0) in the host language, its bit width can be determined to be 8, and its compatibility with other signals or operations can be verified. For enumeration types, it can be verified whether the assignment is a valid enumeration member.

[0143] These multiple constructs can include constructs for defining and accessing members of a structure type that mimics a structure type in the target HDL. For example, a structure type containing multiple fields (with specified types and bit widths) can be defined using the library-provided `typedef.struct` construct, similar to Verilog's `typedef struct packed{...}` or VHDL's `record` type definition. For example, the host language can provide the following construct:

[0144] MyRecordType=typedef.record(

[0145] field1=std_logic_vector(7,'downto',0),

[0146] field2 = integer(0, 'to', 255) )

[0148] my_var = MyRecordType()

[0149] After definition, members of the structure type variable can be accessed using standard dot notation (.), such as my_struct_var.my_field or my_var.field1. The dynamic parser and validator 230 can verify the validity of the member access during execution.

[0150] Similarly, these multiple constructs can include constructs for defining and accessing multidimensional arrays that mimic multidimensional arrays in the target HDL, including packed and unpacked dimensions (in Verilog / SystemVerilog) or multidimensional arrays in VHDL (e.g., array(integer range<>)of std_logic_vector). Array dimensions and array elements can be defined and accessed using the indexing notation of the host programming language (e.g., Python's square brackets [], which can be overloaded by the Xlog library). For example, a variable of type MyType[7:0][3:0].unpacked[15:0] can be defined and its elements accessed in the form my_array_var[i][j][k]. The dynamic parser and validator 230 can verify the validity of the indexes during execution.

[0151] For literals in the target HDL, these multiple constructs can be represented as strings within input code 124. For example, Verilog's 4'b1010 or 8'hFF can be directly written as the Python strings '4'b1010' or '8'hFF'. Similarly, VHDL literals, such as character literals '0', '1', 'Z', bit string literals X"AF", or integer / real number literals, can also be represented by appropriate string representations or host language native types combined with specific constructs. During execution, when these strings are used in a context requiring numerical values ​​(e.g., in assignments or operations), the dynamic parser and validator 230 or related processing logic can parse the string to determine its numerical value and bit width according to the target HDL semantics.

[0152] When the target HDL is VHDL, these multiple constructs may further include corresponding host language constructs for the entity construct and architecture construct used to define the VHDL.

[0153] The dynamic parser and verifier 230 is able to identify during execution the constructs used to declare entities and their ports, as well as the constructs used to define one or more architectures and their internal logic associated with the entity, and establish the correct associations and hierarchies between them in the internal representation 126.

[0154] As mentioned above, preferably, generating output code includes generating a one-to-one structural correspondence with the hardware design specified by input code 124 (e.g., Figure 7 The code shown in Figure 725 illustrates the structural correspondence. In other words, the generated HDL code reflects the structure of the input code as closely as possible in terms of module structure, signal naming, and logic block division, thereby minimizing logic optimization or structural reorganization, unlike traditional solutions. This one-to-one correspondence contributes to code readability, debuggability, and consistency with the original design intent.

[0155] In addition to dynamically parsing and constructing internal representations, the methods and systems of embodiments of this disclosure preferably integrate robust checking mechanisms during execution to detect potential errors early in the design process. (See also...) Figure 2 , Figure 4 and Figure 9 Now, these inspection mechanisms will be described in detail.

[0156] Type checking or bit-width checking that can be performed during execution can be applied to multiple aspects of the hardware design. Preferably, at least one of the type checking or bit-width checking is applied to port connections during the instantiation of a module construction (corresponding to a module in Verilog / SystemVerilog) or an entity construction (corresponding to an entity in VHDL, such as during component instantiation) within the input code. This means that when a module is instantiated in the input code (e.g., instance_a = MyModule(port_a = signal_a, port_b = signal_b)) or a component is instantiated in VHDL, the host language equivalent representation is instance_a:MyEntity port map(port_a => ...

[0157] When signal_a, port_b => signal_b), the system can check whether the type and bit width of the signal (signal_a, signal_b) connected to the instance port (port_a, port_b) match or are compatible with the type and bit width of the corresponding port in the module definition.

[0158] To handle parameterized designs, the checking mechanism preferably includes performing symbolic checks. In symbolic checks, one or more parameters defined in the input code (e.g., the bit-width parameter WIDTH of a module (in Verilog / SystemVerilog), or generic parameters (in VHDL)) are treated as symbolic variables rather than specific numerical values ​​during the check. This means the system can deduce and check the bit widths of signals and expressions, and their compatibility, without knowing the specific values ​​of the parameters. For example, if an operation requires two operands to have the same bit width, and both operands' bit widths depend on a symbolic parameter WIDTH (e.g., both WIDTH-1:0), a symbolic check can determine they are a match without knowing the specific value of WIDTH. Conversely, if one operand has a bit width of WIDTH-1:0, while the other has a fixed 7:0, a symbolic check can identify potential mismatches unless it can be proven that WIDTH is identically equal to 8.

[0159] More preferably, to further enhance sign checking capabilities, performing sign checking may include utilizing a satisfiability modulus theory (SMT) solver. Bit-width matching and type compatibility requirements can be converted into SMT formulas (containing sign parameters as variables), and then an SMT solver (e.g., Z3) can be used to prove whether these formulas are satisfiable. If the formulas are not satisfiable, it indicates a potential design flaw.

[0160] To further improve error detection capabilities, the inspection mechanism disclosed herein can enforce stricter rules than the target HDL (e.g., Verilog or standard VHDL behavior) standard.

[0161] In a preferred embodiment, performing at least one of type checking or bit-width checking includes enforcing the rule that the operands of binary arithmetic operators (e.g., +, -, *) or binary bitwise operators (e.g., &, |, ^) within the input code have the same bit width. This avoids potential problems arising from implicit bit-width expansion or truncation that may occur in Verilog, forcing designers to explicitly handle bit-width matching.

[0162] In another preferred aspect, performing at least one of type checking or bit-width checking includes enforcing the following rule: Boolean operators (e.g., logical AND, logical OR) within the input code.

[0163] The operands of OR and NOT operations have a bit width of 1. This ensures that the operands of logical operations are indeed Boolean in nature, avoiding ambiguity or errors that might arise from directly using multi-bit vectors for logical judgments.

[0164] These inspection mechanisms, combined with dynamic execution, enable the solutions of the embodiments of this disclosure to detect errors that may be missed by traditional processes with greater accuracy early in the design process, thereby significantly improving design quality and efficiency. As mentioned above, the inspection results can be used to generate error reports.

[0165] In many cases, there is a need to leverage existing HDL source code using high-level programming languages ​​to perform checks, modify functions, add new features, and facilitate collaboration on older HDL source code. Accordingly, in addition to directly processing input code written in the host programming language, embodiments of this disclosure also provide a complete workflow for processing existing target HDL source code. (Refer to...) Figure 2 , Figure 5 and Figure 6 .

[0166] In a preferred example, such as Figure 5 Operation 510 and Figure 6 As shown in operation 610, the method first receives target HDL source code 129. Target HDL source code 129 includes at least one of Verilog source code, SystemVerilog source code, or VHDL source code.

[0167] Preferably, the method further includes translating the target HDL source code 129 written in the target HDL into input code 124 written in the host programming language before acquiring (or executing) the input code. This translation operation corresponds to Figure 5 Operation 520 and Figure 6 Operation 620 in the middle can be performed by Figure 2 The translator 215 in the middle is executed. The translator 215 is a parser capable of parsing the target HDL source code 129, which converts the HDL construct into host programming language code (i.e., intermediate code or input code 124) that is functionally equivalent to the construct defined using the library (e.g., the Xlog library) described in this disclosure.

[0168] After obtaining the translated intermediate code, the system then executes that intermediate code, as described above (for example...). Figure 5 Operation 530 or Figure 6 Operation 630 includes dynamic parsing (operations 532 / 632), constructing the internal representation (operations 534 / 634), and performing checks (operations 536 / 636).

[0169] Finally, in operations 540 / 640, output is generated based on internal representation 126 or the inspection results. This output can be the generated, possibly validated or modified, target HDL code (operations 542 / 642), or an error report indicating problems found in the original HDL source code (operations 544 / 644).

[0170] Therefore, this disclosure provides a computer-implemented method for processing Hardware Description Language (HDL) source code. The method includes: receiving target HDL source code; translating the target HDL source code into intermediate code written in a host programming language, wherein the intermediate code includes a plurality of constructs defined by libraries associated with the host programming language, the constructs being syntactically mapped to corresponding constructs in the target HDL; executing the intermediate code using an interpreter or runtime environment of the host programming language, wherein the execution includes dynamically parsing the plurality of constructs to construct an internal representation and performing checks based on the target HDL semantics; and generating output, at least in part based on the internal representation or the result of the execution checks, the output including at least one of generated HDL code or an error report.

[0171] This disclosure also provides a system for generating a Hardware Description Language (HDL). The system includes: one or more memories; and one or more processors coupled to the one or more memories, the one or more processors being configured to perform any of the methods described above (e.g., methods involving executing input code) or methods for processing HDL source code (e.g., methods involving translation and execution). Figure 1 and Figure 2 One possible hardware architecture and functional module architecture of the system are shown respectively.

[0172] This disclosure also provides a non-transitory computer-readable storage medium. Instructions are stored thereon that, when executed by a processor, cause the processor to perform any of the methods described above (e.g., methods involving executing input code) or methods for processing HDL source code (e.g., methods involving translation and execution). The non-transitory computer-readable storage medium may be... Figure 1 The memory 120 shown may be in any form, such as RAM, ROM, flash memory, hard disk drive, solid-state drive, optical disk, etc.

[0173] One or more embodiments of this disclosure provide an innovative approach to hardware design code processing through the methods, systems, and media described above. By leveraging the execution of the host programming language to drive dynamic parsing, verification, and checking, it enables immediate error detection and reporting, significantly improving design and debugging efficiency. The dynamic parsing and verification capabilities for complex types (such as nested structures, multidimensional arrays, including Verilog / SystemVerilog structs and VHDL records) and hierarchical references enhance the expressiveness and security of the language. Integrated symbol checking capabilities (e.g., applied to...)

[0174] The use of Verilog / SystemVerilog parameters or VHDL generic parameters and optional stringent checking rules improves the detection of potential design flaws, especially bit-width issues in parametric designs. Maintaining a one-to-one structural correspondence between input and output code simplifies code understanding and verification. A complete translation workflow is provided, enabling easy application of this technology to existing designs. Overall, the methods and systems disclosed herein effectively combine the flexibility of modern programming languages ​​with the rigor of HDL design, providing a powerful tool for improving hardware design productivity, automation, and design quality. The methods and systems disclosed herein can be applied to hardware description languages ​​with strict type and bit-width definitions, including but not limited to Verilog, SystemVerilog, VHDL, and any suitable HDL language.

[0175] Other advantages and modifications will readily occur to those skilled in the art. Therefore, more broadly, the invention is not limited to the specific details and representative embodiments shown and described herein. Thus, modifications can be made without departing from the spirit or scope of the overall inventive concept as defined by the appended claims and their equivalents.

Claims

1. A computer-implemented method for generating Hardware Description Language (HDL) code, characterized in that, The method includes: Obtain input code written in a host programming language, wherein the input code includes a plurality of constructs defined by a library associated with the host programming language, the constructs being syntactically mapped to corresponding constructs in a target HDL, the target HDL including at least one of Verilog, SystemVerilog, or VHDL; The input code is executed using an interpreter or runtime environment of the host programming language, wherein the execution includes: dynamically parsing the plurality of constructs within the input code based on the execution flow of the input code via the interpreter or runtime environment, and constructing an internal representation of the hardware design specified by the input code; and The output code of the target HDL, representing the hardware design, is generated based at least in part on the internal representation.

2. The method of claim 1, wherein dynamically parsing the plurality of constructs within the input code comprises: For the construct defined within the input code that represents at least one of nested structures or multidimensional arrays, parse its target HDL semantic type.

3. The method according to claim 1 or 2, wherein dynamically parsing the plurality of constructs within the input code comprises: Based on the target HDL semantics defined in the input code, verify the hierarchical references to elements within the instantiated module construct or entity construct.

4. The method according to claim 1, characterized in that, The execution also includes: During the execution, at least one of a type check or a bit width check is performed on one or more elements within the internal representation.

5. The method of claim 4, wherein at least one of the execution type check or bit width check is applied to port connections during the instantiation of the module construction or entity construction within the input code.

6. The method according to claim 4, characterized in that, Performing at least one of the type check or bit-width check includes performing a sign check, wherein one or more parameters or generic parameters defined in the input code are treated as sign variables during the check.

7. The method according to claim 6, characterized in that, Performing the symbol check involves using a satisfiability modulus (SMT) solver.

8. The method according to claim 4, characterized in that, Performing at least one of the type check or bit width check includes enforcing the following rules: The corresponding operands of the binary arithmetic operators or binary bitwise operators within the input code have the same bit width; and / or The bit width of the corresponding operand of the Boolean operator in the input code is 1.

9. The method according to claim 1, characterized in that, The host programming language is Python.

10. The method according to claim 9, characterized in that, At least one of the plurality of constructs utilizes Python's with statement to define a scope corresponding to at least one of the following in the target HDL: an always block, conditional block, or generate block in Verilog or SystemVerilog, or a process block in VHDL.

11. The method according to claim 1, characterized in that, The plurality of constructs include overloaded operators of the host programming language, which correspond to arithmetic operators or bitwise operators of the target HDL.

12. The method according to claim 1, characterized in that, The plurality of constructs include named functions corresponding to HDL operators that cannot be directly mapped to operators of the host programming language, the named functions including functions for at least one of the following: ternary conditional selection, reduction operation, or logical shift operation specific to the target HDL.

13. The method according to claim 1, characterized in that: The plurality of constructs include constructs for defining and accessing members of a structure type, the structure type simulating a structure type in the target HDL, wherein member access utilizes dot notation; or The plurality of constructs include constructs for defining and accessing multidimensional arrays that simulate multidimensional arrays in the target HDL, wherein array access utilizes index notation.

14. The method according to claim 1, characterized in that, The plurality of constructs include representing HDL literals as strings within the input code, and the execution includes parsing the strings to determine values ​​and bit widths according to HDL semantics.

15. The method according to claim 1, characterized in that, Generating the output code includes generating code that maintains a one-to-one structural correspondence with the hardware design specified by the input code.

16. The method according to claim 1, characterized in that, The internal representation includes an Abstract Syntax Tree (AST).

17. The method of claim 1, wherein when the target HDL is VHDL, the plurality of constructs further include corresponding host language constructs for defining the entity construct and the architecture construct of the VHDL.

18. A computer-implemented method for processing Hardware Description Language (HDL) source code, the method comprising: Receive target HDL source code, wherein the target HDL source code includes at least one of Verilog source code, SystemVerilog source code, or VHDL source code; The target HDL source code is translated into intermediate code written in a host programming language, wherein the intermediate code includes multiple constructs defined by libraries associated with the host programming language, the constructs being syntactically mapped to corresponding constructs in the target HDL; The intermediate code is executed using an interpreter or runtime environment of the host programming language, wherein the execution includes dynamically resolving the plurality of constructs, constructing an internal representation, and performing checks based on the target HDL semantics; and Output is generated, at least in part, based on the internal representation or the result of the execution check, the output including at least one of generated HDL code or error report.

19. A system for generating a Hardware Description Language (HDL), the system comprising: One or more memory units; as well as One or more processors coupled to the one or more memories, the one or more processors being configured to perform the method of any one of claims 1 to 17 or the method of claim 18.

20. A non-transient computer-readable storage medium having instructions stored thereon, which, when executed by a processor, cause the processor to perform the method of any one of claims 1 to 17 or the method of claim 18.

Images