Hardware description language code generation system based on TypeScript

Abstract

The invention provides a hardware description language code generation system based on TypeScript, comprising a configuration conversion unit, a type verification unit, a parameter calculation unit, an intermediate representation construction unit and a code generation unit, through a type system of TypeScript, type inconformity can be effectively captured in a coding stage, illegal configuration with parameter type inconformity is effectively intercepted, and the code generation efficiency is improved. Therefore, the design error risk and the later debugging cost are reduced; meanwhile, based on the object-oriented characteristic of the TypeScript, the target hardware description language code with the structured hierarchy can be generated, so that the readability of the target hardware description language code is high, and then the maintainability and development efficiency of hardware design are improved.

Description

Technical Field

[0001] This application relates to the field of hardware design, and more specifically, to a TypeScript-based hardware description language code generation system. Background Technology

[0002] In the field of integrated circuit (IC) design, designers typically employ two technical paths to implement circuit design: one is to directly use hardware description languages, such as Verilog or SystemVerilog, for circuit description and compilation; the other is to generate corresponding hardware description languages ​​through hardware construction languages, such as Chisel or SpinalHDL, which are based on Scala, and convert them into corresponding hardware description languages.

[0003] However, due to the lack of a strong type system in hardware description languages, key parameters are often presented in raw numerical form. For example, bit width (e.g., 32 / 64 / 128 bits) is usually presented directly as raw numbers (e.g., directly writing 32, 64, 128). Such designs cannot effectively intercept illegal configurations during the coding phase, leading to errors that are not exposed until the compilation or simulation phase, significantly increasing debugging costs. At the same time, although existing hardware construction languages, such as Chisel, have introduced type systems, they rely on Scala's complex type inference mechanism, resulting in a steep learning curve and high debugging costs. In multi-person collaborative scenarios, the complex type inference mechanism is prone to misunderstandings or misuse, and still cannot reduce design risks. Summary of the Invention

[0004] This application provides at least one hardware description language code generation system based on TypeScript. By utilizing TypeScript's type system, it can effectively capture type mismatches during the coding stage and effectively intercept illegal configurations with mismatched parameter types, thereby reducing the risk of design errors and the cost of later debugging. At the same time, relying on the object-oriented features of TypeScript, it can generate target hardware description language code with a structured hierarchy, making the target hardware description language code more readable, thereby improving the maintainability and development efficiency of hardware design.

[0005] This application provides a TypeScript-based hardware description language code generation system, including:

[0006] The configuration conversion unit is used to parse and process the original configuration file to obtain a structured parameter interface, which is used to describe the target hardware object.

[0007] The type validation unit is used to perform static type checks on the configuration parameters included in the parameter interface structure code based on the TypeScript type system: if the parameter type of the configuration parameter matches the preset type declaration, it is determined to be a valid parameter; if the parameter type of the configuration parameter conflicts with the preset type declaration, a type exception signal is generated.

[0008] The parameter calculation unit is used to perform hardware configuration calculations based on the verified valid parameters and generate a hardware implementation parameter set.

[0009] Intermediate representation construction units are used to convert hardware implementation parameter sets into intermediate representations that conform to the TypeScript specification through constructor functions;

[0010] The code generation unit is used to convert intermediate representations into target hardware description language code.

[0011] In one possible implementation, the configuration parameters include required parameters and optional parameters.

[0012] In one possible implementation, the system further includes a parameter verification unit for verifying whether the required parameters and the optional parameters conform to a preset security agreement.

[0013] In one possible implementation, the effective parameters include bus type, register mapping, register definition, pipeline definition, and submodule list. The parameter calculation unit is used to generate input / output port definitions and signals based on bus type, register mapping, register definition, pipeline definition, and submodule list, and to generate corresponding combinational logic code, sequential logic code, and instanced submodules for different paths.

[0014] In one possible implementation, the system is configured to interface with JSON Schema.

[0015] In one possible implementation, the system further includes a structure verification unit for performing signal lookup, name duplication check, bit width alignment verification, and submodule port connection verification operations.

[0016] In one possible implementation, the original configuration file is in a structured text data format;

[0017] The configuration conversion unit is used to parse the original configuration file using a structured text parsing tool to obtain a structured parameter interface.

[0018] In one possible implementation, the system further includes:

[0019] The instance instantiation unit is used to parse the original hardware description language code and generate corresponding submodule instance instantiations.

[0020] In one possible implementation, the target hardware description language code is SystemVerilog code.

[0021] In one possible implementation, the system includes a module class and at least one subclass that inherits from the module class.

[0022] In summary, this application provides a TypeScript-based hardware description language code generation system, comprising: a configuration conversion unit for parsing and processing the original configuration file to obtain a structured parameter interface, wherein the parameter interface is used to describe a target hardware object; a type validation unit for performing static type checks on the configuration parameters included in the parameter interface based on the TypeScript type system: if the parameter type of the configuration parameter matches a preset type declaration, it is determined to be a valid parameter; if the parameter type of the configuration parameter conflicts with a preset type declaration, a type exception signal is generated; a parameter calculation unit for performing hardware configuration calculations based on the validated valid parameters to generate a hardware implementation parameter set; an intermediate representation construction unit for converting the hardware implementation parameter set into an intermediate representation conforming to the TypeScript specification through a constructor function; and a code generation unit for converting the intermediate representation into target hardware description language code. Through the aforementioned system, TypeScript's type system can effectively capture type mismatches during the coding phase, effectively intercepting illegal configurations with incorrect parameter types, thereby reducing the risk of design errors and the cost of later debugging. At the same time, relying on TypeScript's object-oriented features, it can generate target hardware description language code with a structured hierarchy, making the target hardware description language code more readable, thereby improving the maintainability and development efficiency of hardware design.

[0023] Other advantages of this application will be explained in more detail in conjunction with the following description and figures.

[0024] It should be understood that the above description is merely an overview of the technical solution of this application, so as to enable a general understanding of the technical means of this application and to implement it in accordance with the contents of the specification. In order to make the above and other objects, features and advantages of this application more apparent and understandable, specific embodiments of this application are illustrated below. Attached Figure Description

[0025] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly described below. The accompanying drawings are incorporated in and constitute a part of this specification. These drawings illustrate embodiments conforming to this application and are used together with the specification to explain the technical solutions of this application. It should be understood that the drawings only illustrate certain embodiments of this application and should not be considered as a limitation on the scope of protection. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort. Furthermore, the same reference numerals denote the same components throughout the drawings. In the drawings:

[0026] Figure 1 A schematic diagram of the structure of a TypeScript-based hardware description language code generation system provided in this application embodiment;

[0027] Figure 2 This application provides an example of attributes and methods in a module class. Detailed Implementation

[0028] Exemplary embodiments of this application will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of this application are shown in the drawings, it should be understood that this application can be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided to enable a more thorough understanding of this application and to fully convey the scope of this application to those skilled in the art.

[0029] In the description of embodiments of this application, it should be understood that terms such as “comprising” or “having” are intended to indicate the presence of the disclosed features, figures, steps, behaviors, components, portions or combinations thereof in this specification, and do not exclude the possibility of the presence of one or more other features, figures, steps, behaviors, components, portions or combinations thereof.

[0030] Unless otherwise stated, " / " means "or". For example, A / B can mean A or B. In this article, "and / or" is merely a way of describing the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can mean: A alone, A and B at the same time, and B alone.

[0031] The terms "first," "second," etc., are used only for ease of description to distinguish identical or similar technical features and should not be construed as indicating or implying the relative importance or number of these technical features. Therefore, a feature defined by "first," "second," etc., may explicitly or implicitly include one or more of that feature. In the description of embodiments of this application, unless otherwise stated, the term "multiple" means two or more.

[0032] In the field of integrated circuit (IC) design, designers typically employ two technical paths to implement circuit design: one is to directly use hardware description languages, such as Verilog or SystemVerilog, for circuit description and compilation; the other is to generate corresponding hardware description languages ​​through hardware construction languages, such as Chisel or SpinalHDL, which are based on Scala, and convert them into corresponding hardware description languages.

[0033] However, due to the lack of a strong type system in hardware description languages, key parameters are often presented in raw numerical form. For example, bit width (e.g., 32 / 64 / 128 bits) is usually presented directly as raw numbers (e.g., directly writing 32, 64, 128). Such designs cannot effectively intercept illegal configurations during the coding phase, leading to errors that are not exposed until the compilation or simulation phase, significantly increasing debugging costs. At the same time, although existing hardware construction languages, such as Chisel, have introduced type systems, they rely on Scala's complex type inference mechanism, resulting in a steep learning curve and high debugging costs. In multi-person collaborative scenarios, the complex type inference mechanism is prone to misunderstandings or misuse, and still cannot reduce design risks.

[0034] In view of this, this application provides a hardware description language code generation system based on TypeScript. By utilizing TypeScript's type system, it can effectively capture type mismatches during the coding stage and effectively intercept illegal configurations with mismatched parameter types, thereby reducing the risk of design errors and the cost of later debugging. At the same time, relying on the object-oriented characteristics of TypeScript, it can generate target hardware description language code with a structured hierarchy, making the target hardware description language code more readable, thereby improving the maintainability and development efficiency of hardware design.

[0035] The following examples illustrate the TypeScript-based hardware description language code generation system provided in this application. Figure 1 As shown, Figure 1 This application provides a schematic diagram of the structure of a TypeScript-based hardware description language code generation system 100, which includes:

[0036] The configuration conversion unit 101 is used to parse and process the original configuration file to obtain a structured parameter interface, which is used to describe the target hardware object.

[0037] Specifically, the original configuration file refers to the original configuration file used for hardware design, and the parameter interface is used to describe the target hardware object, which includes registers, fields, ports, etc.

[0038] In practical applications, the original configuration file can be in tabular form, meaning a table can be input. For example, a register table can include information such as Register Name, Register Offset, Access Mode, Repeat, Write Out, UseBuffer, Field Out, Register Width, Field, Bits, Access Type, and Reset Value. Correspondingly, the generated structured parameter interface can be:

[0039] "CTRL":{

[0040] "startAddr":"0x4",

[0041] "packName":"CTRL_t",

[0042] type":"RW",

[0043] "weOut":true,

[0044] "useBuf":true,

[0045] "reserved":[[30,24],[7,3]],

[0046] "reset":"0x00010001"

[0047] In practical applications, shell commands can also be submitted, and the address width and data width in the structured parameter interface can be set using the "aw" and "w" options. For example, the address width can be adjusted to 16 and the data width to 32 using ". / tsRegBlk. / PCIE_Reg.csv-aw 16-w 32".

[0048] For the existing Chisel, generating interface structure code using configuration files such as YAML and comma-separated values ​​(CSV) still requires manual script processing. Furthermore, Scala's parsing of these files relies on complex third-party libraries. Moreover, Chisel is difficult to integrate efficiently with other hardware description language tools, resulting in efficiency bottlenecks in multi-language collaboration.

[0049] In one possible implementation, the original configuration file is in a structured text data format.

[0050] The configuration conversion unit is used to parse the original configuration file using a structured text parsing tool to obtain a structured parameter interface.

[0051] Specifically, the original configuration file can be a structured text data format such as YAML or CSV. Existing structured text parsing tools such as js-yaml and csv-parse can be used to parse and process the structured text data format such as YAML or CSV directly, so that there is no need to write a parser or rely on a third-party heavy toolchain. It can be used to directly generate the required target hardware description language code from register tables, input / output (IO) lists and other data.

[0052] In one possible implementation, the system can be configured to interface with JSON Schema.

[0053] Specifically, existing signal bundle representation module interface structures in Chisel and SpinalHDL are cumbersome and unsuitable for expressing complex structures such as heterogeneous registers, parameterized ports, and dynamic fields. Furthermore, the interface structure heavily relies on hard-coded code, hindering automatic generation, configuration management, and pattern verification. In contrast, the system in this application uses parameterized interfaces to describe clearly structured hardware objects such as registers, fields, and ports. Moreover, VSCode natively supports JSON Schema, meaning designers can directly use JSON Schema to verify and dynamically generate configuration parameters, thereby improving the efficiency and reliability of configurable hardware design.

[0054] The type verification unit 102 is used to perform static type checks on the configuration parameters included in the parameter interface based on the TypeScript type system: if the parameter type of the configuration parameter matches the preset type declaration, it is determined to be a valid parameter; if the parameter type of the configuration parameter conflicts with the preset type declaration, a type exception signal is generated.

[0055] Specifically, due to TypeScript's powerful type system, it can perform static type checking on configuration parameters, which enables error prevention and correction in hardware design. This allows for effective capture of type mismatches during the coding phase. When the parameter type of a configuration parameter conflicts with the default type declaration, a type exception signal can be generated. For example, an exception can be thrown for importing unreasonable bus types or parameters, thereby effectively intercepting illegal configurations with mismatched parameter types, preventing the accumulation of logical errors, and achieving efficient parameterization of hardware modules, reducing the risk of design errors and the cost of later debugging.

[0056] Existing languages ​​such as Verilog or SystemVerilog lack automatic verification mechanisms. For example, they cannot verify whether signals have duplicate names, whether I / O bit widths are consistent, or whether parameter configurations conform to specifications. These issues still rely on manual inspection or later simulation to discover the problems. At the same time, for the existing Chisel, auxiliary functions such as signal completion, finding submodule I / O, and parameter verification still need to be implemented manually, and there is a lack of general tool support.

[0057] In one possible implementation, the system may further include a structure verification unit for performing signal lookup, name duplication check, bit width alignment verification, and submodule port connection verification operations. For example, the code for name duplication check is shown below:

[0058]

[0059] The code for bit-width alignment verification is shown below:

[0060]

[0061] In this embodiment, low-level but high-frequency errors that are troublesome and time-consuming in traditional hardware integration, such as duplicate names, bit width errors, and incorrect wiring, can be eliminated at the coding stage, greatly reducing the pain and rework in the integration stage, thereby improving integration efficiency.

[0062] In one possible implementation, configuration parameters may include required parameters and optional parameters.

[0063] In one possible implementation, the system may further include a parameter verification unit for verifying whether required and optional parameters conform to a preset security convention.

[0064] Specifically, preset safety rules can be set by designers as needed to verify whether parameters conform to preset safety rules. For example, it can check whether required parameters are empty and check whether optional parameters contradict required parameters. That is, the parameter verification unit can verify whether required parameters are filled in and whether optional parameters contradict required parameters.

[0065] The parameter calculation unit 103 is used to perform hardware configuration calculations based on the verified valid parameters and generate a hardware implementation parameter set.

[0066] Specifically, after type validation of the parameter interface, hardware configuration calculations can be performed based on the validated valid parameters to obtain the hardware implementation parameter set. The hardware implementation parameter set refers to the set of hardware implementation parameters used in subsequent circuit design. In practical applications, the hardware implementation parameter set may include reset values, address masks, enable modes, etc.

[0067] In one possible implementation, valid parameters may include bus type, register mapping, register definition, pipeline definition, and submodule list. The parameter calculation unit is used to generate input / output port definitions and signals based on the bus type, register mapping, register definition, pipeline definition, and submodule list. The input / output port definitions and signals can declare signals and registers on internal paths. That is, by generating input / output port definitions and signals, signal and I / O management can be realized, and corresponding combinational logic code, sequential logic code, and instanced submodules can be generated for different paths so that the target hardware description language code can be generated in the end.

[0068] It should be noted that in practical applications, designers can set the effective parameters required for hardware design as needed, and are not limited to the bus type, register mapping, register definition, pipeline definition and submodule list involved in this embodiment.

[0069] Intermediate representation construction unit 104 is used to convert the hardware implementation parameter set into an intermediate representation that conforms to the TypeScript specification through the constructor.

[0070] The code generation unit 105 is used to convert the intermediate representation into target hardware description language code.

[0071] Specifically, the target hardware description language code is the Register Transfer Level Code (RTL) code that needs to be generated. After obtaining the RTL code, it can be integrated into the system.

[0072] It's worth noting that traditional hardware description languages ​​or Scala-based hardware construction languages ​​lack flexibility in code generation, name concatenation, and dynamic module construction. For example, in Chisel, signal naming often automatically generates intermediate variables like "_T_15," which are difficult to trace and hinder signal tracking and verification. To address this, TypeScript leverages its object-oriented features—specifically, its native support for template strings and object operations—to generate target hardware description language code with a structured hierarchy. This significantly improves the readability of the target hardware description language code. For instance, it can generate highly readable code like "assign cfg_wptr=reg_wptr;," avoiding meaningless signal names like "_T_15," thereby enhancing the maintainability and development efficiency of hardware design.

[0073] In one possible implementation, the target hardware description language code can be SystemVerilog code.

[0074] In one possible implementation, the system may further include:

[0075] The instance instantiation unit is used to parse the original hardware description language code and generate corresponding submodule instance instantiations.

[0076] Specifically, the system can parse existing raw hardware description language code, such as existing SystemVerilog files, to extract port definitions and automatically generate corresponding sub-module instantiations. These sub-module instantiations can then be directly called to implement the corresponding functions, thereby enabling module-level assembly, parameter configuration, and signal binding. This supports multi-language collaborative integration and improves the flexibility of system-level design.

[0077] In one possible implementation, the system may include a module class and at least one subclass that inherits from the module class.

[0078] Specifically, in practical applications, the core class of this system is the Module class. As a base class, it encapsulates the module's attributes and methods, such as... Figure 2 As shown, the attributes of this class can include internal signals and input / output port definitions (IOs) for declaring signals and ports, as well as configurable parameters (params) for storing module parameters. Methods include functions such as adding a sequence block (addSequentialLogic) and instantiating a submodule (addSonModule). In practical use, these attributes and methods can be frequently called to implement corresponding functions. In practical applications, multiple subclasses inheriting from the Module class can be generated. These subclasses are suitable for different application scenarios; that is, the system can be easily extended and integrated through the Module class and at least one subclass inheriting from the Module class.

[0079] It should be noted that the Chisel toolchain relies on the Scala Simple Build Tool (SBT), Flexible Intermediate Representation for RTL (FIRRTL), and the Scala compiler. Its installation is complex and builds slowly, limiting its lightweight use and cross-platform deployment feasibility. Furthermore, its integrated development environment (IDE) support is limited, with poor code navigation, completion, and type hints. In contrast, the system provided in this application can run on a Node.js environment, builds with zero dependencies on Scala or SBT, and supports real-time type checking, documentation hints, and automatic navigation in IDEs such as VS Code.

[0080] Therefore, this application provides a TypeScript-based hardware description language code generation system, comprising: a configuration conversion unit for parsing and processing the original configuration file to obtain a structured parameter interface, wherein the parameter interface is used to describe the target hardware object; a type validation unit for performing static type checks on the configuration parameters included in the parameter interface based on the TypeScript type system: if the parameter type of the configuration parameter matches the preset type declaration, it is determined to be a valid parameter; if the parameter type of the configuration parameter conflicts with the preset type declaration, a type exception signal is generated; a parameter calculation unit for performing hardware configuration calculations based on the validated valid parameters to generate a hardware implementation parameter set; an intermediate representation construction unit for converting the hardware implementation parameter set into an intermediate representation conforming to the TypeScript specification through a constructor function; and a code generation unit for converting the intermediate representation into target hardware description language code. Through the aforementioned system, TypeScript's type system can effectively capture type mismatches during the coding phase, effectively intercepting illegal configurations with incorrect parameter types, thereby reducing the risk of design errors and the cost of later debugging. At the same time, relying on TypeScript's object-oriented features, it can generate target hardware description language code with a structured hierarchy, making the target hardware description language code more readable, thereby improving the maintainability and development efficiency of hardware design.

[0081] In the description of this specification, references to terms such as "some possible implementations," "some implementations," "example," "specific example," or "some examples" indicate that a specific feature, structure, material, or characteristic described in connection with that implementation or example is included in at least one implementation or example of this application, and the aforementioned terms do not necessarily refer to the same implementation or example. Furthermore, the described specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more implementations or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different implementations or examples described in this specification, as well as the features of different implementations or examples.

[0082] While the spirit and principles of this application have been described above with reference to several specific embodiments, it should be understood that this application is not limited to the disclosed specific embodiments, and the division of aspects does not imply that features in these aspects cannot be combined. This application is intended to cover various modifications and equivalent arrangements included within the spirit and scope of the appended claims.

Claims

1. A hardware description language code generation system based on TypeScript, characterized in that, include: A configuration conversion unit is used to parse and process the original configuration file to obtain a structured parameter interface, which is used to describe the target hardware object; The type validation unit is used to perform static type checks on the configuration parameters included in the parameter interface based on the TypeScript type system: if the parameter type of the configuration parameter matches the preset type declaration, it is determined to be a valid parameter; if the parameter type of the configuration parameter conflicts with the preset type declaration, a type exception signal is generated. The parameter calculation unit is used to perform hardware configuration calculations based on the verified valid parameters and generate a hardware implementation parameter set. An intermediate representation construction unit is used to convert the hardware implementation parameter set into an intermediate representation that conforms to the TypeScript specification through a constructor function; The code generation unit is used to convert the intermediate representation into target hardware description language code.

2. The hardware description language code generation system according to claim 1, characterized in that, The configuration parameters include required parameters and optional parameters.

3. The hardware description language code generation system according to claim 2, characterized in that, The system further includes a parameter verification unit for verifying whether the required parameters and the optional parameters conform to a preset security agreement.

4. The hardware description language code generation system according to claim 1, characterized in that, The effective parameters include bus type, register mapping, register definition, pipeline definition, and submodule list. The parameter calculation unit is used to generate input / output port definitions and signals based on bus type, register mapping, register definition, pipeline definition, and submodule list, and to generate corresponding combinational logic code, sequential logic code, and instanced submodules for different paths.

5. The hardware description language code generation system according to claim 1, characterized in that, The system is configured to interface with JSON Schema.

6. The hardware description language code generation system according to claim 1, characterized in that, The system further includes a structure verification unit for performing signal lookup, name duplication check, bit width alignment verification, and submodule port connection verification operations.

7. The hardware description language code generation system according to claim 1, characterized in that, The original configuration file is in a structured text data format; The configuration conversion unit is used to parse the original configuration file using a structured text parsing tool to obtain a structured parameter interface.

8. The hardware description language code generation system according to claim 1, characterized in that, The system further includes: The instance instantiation unit is used to parse the original hardware description language code and generate corresponding submodule instance instantiations.

9. The hardware description language code generation system according to claim 1, characterized in that, The target hardware description language code is SystemVerilog code.

10. The hardware description language code generation system according to any one of claims 1 to 9, characterized in that, The system includes a module class and at least one subclass that inherits from the module class.

Images