The presented invention relates to defining a hardware description language to specify the design of an electronic design, and to methods to translate the hardware description language to a standard hardware description language, such as Verilog-HDL or VHDL.
The standardized and well-accepted hardware description languages, Verilog-HDL and VHDL are defined primarily for verifying an electronic design. They emphasize the clarity of the behavior of the design coded in such languages. This emphasis requires the behavior details of a commonly used logic block being described every time such a logic block is written. It is time-consuming and error-prone to repeat such behavior description in the design process. A designer's primary interest to use a commonly used logic block is to connect them in the design, rather than to specify their behavior in the design. A designer wants to specify the behavior of a logic block only if the block is a customized block in the design.
The solution to this problem in the standard HDL is to use module instantiation. The behavior of an instantiated module need not be specified each time when it is instantiated. Only the connections of the instantiated module need to be specified. However, the module instantiation has the following drawbacks: (1) the instantiation of a logic block with a modest complexity requires as much code as specifying the behavior of the logic block; (2) the instantiation requires that the connection of every connected port being explicitly specified, while many of such connections are not of the primary interest of the designers; (3) the need to use a large number of variations of a commonly-used logic block pushes the proliferation of the modules in the design library to be instantiated.
One example of the drawback (1) above is a D-flip-flop. Writing an instantiation of a D-flip-flop is about as tedious as writing the behavior model of the D-flip-flop.
Examples of the drawback (2) above are the clock signal and the reset signal, which are very common in the port list of the sequential logic modules. Even though the connections of these signals are essential for the correct behavior of the modules, the repetitive typing of these port names and the signal names, to which they are connected, is counter-productive and is not the primary focus of the design work.
One example of the drawback (3) above is a family of decoders. If a designer may use binary decoders with input signals having a width from two bits to 8 bits, it is necessary to have seven decoder modules ready to be instantiated in the design library. The module proliferation can easily be too excessive if there is more than one variable of interest.
The current standard HDL does not have solutions for the drawbacks (1) and (2). The solution in the standard HDL for the drawback (3) is to use parameterized modules to create variations of a module to be instantiated. However, the parameterization has its limitations in such verification-centric standard HDL. For example, the module port name variations cannot be parameterized. The hardware description language of the present invention addresses the issues of all of these three drawbacks.
The present invention solves the problems in the drawbacks of the current standard HDL.
The invention defines a hardware description language to include a growable set of object commands. An object command can be used to describe a design object, simple or complex. The required information needed to write the object command is limited to such that are typically different from instance to instance. The information, which is typically identical among the instances in a design, is obtained from the predefined values of system variables, or from the values of user-defined variables, or from the information-generation mechanism defined by the command. Such information can also be specified in an object command instance when necessary.
The object command does not necessarily contain the information of the object behavior so that the repetitive coding of the behavior of a commonly used design object can be eliminated.
The object command does not necessarily require the information of the complete set of port connections between the object and the rest of the logic in the module, so that the coding of certain trivial port connections may be eliminated.
The object command may have a set of command options so that the instances of the object may vary from one to another, without the proliferation of the object commands.
The RTL design using the hardware description language is significantly simplified because much of the required information for the behavior of the objects in a conventional hardware description language is not needed for the RTL design using the hardware description language in this invention.
The behavior of an object is defined by the object command in the hardware description language. The definition of an object command and its command options is presented to users in a manual. A user writes an object command with confidence that the translation of the source code in the hardware description language will produce a code in a second hardware description language, with a behavior description as promised by the object command definition in the said manual.
For example, an object command Pedetect, is defined by the language as a logic block that detects the positive edge of a signal, with the input to the block being the signal to be detected and the output from the block being a signal carrying the result of the detection. The output signal uses a pulse, with a width of one clock cycle, to indicate the detection of a positive edge, on the cycle when the input signal making the low-to-high transition.
Given this definition, a positive-edge detector can be coded with only three pieces of information: (1) the object command name, i.e., Pedetect, (2) the input signal name, and (3) the output signal name. A method in this invention converts the given information to a full behavior description of the positive-edge detector in the targeted standard HDL language.
The features of the invention are set forth in the claims. The invention in an illustrative embodiment may be best understood by reference to the following detailed description of the invention, taken in conjunction with the accompanying drawings, wherein:
While this invention may be applied in the embodiments of various forms, it is shown in the drawings and will herein be described in specific embodiments. The detailed description in these specific embodiments is to be considered as examples of the invention and not to limit the invention in these embodiments as shown and described.
The present invention relates to a hardware description language that can be translated to a second hardware description language, such as Verilog-HDL or VHDL. The source codes may contain only the language constructs of the hardware description language, such as shown in 101 of
The codes in 104 can then be simulated and synthesized through the conventional design flow.
The source codes in 201 of
The first line of the source codes in 201 is an object command Module. The Module command defines the characteristics of a module. The command option -ai indicates that the module should automatically generate input signals. The identifier sys_intf_cntl_pipeline is the name of the module.
The second line of the source codes in 201 is an object command Dff. The Dff command defines design objects D-flip-flops. There are two options in the command. The -r option indicates that the D-flip-flops defined by this command need to have synchronous reset. The -o option indicates that the generated q-port signal of each D-flip-flop is to be the output port of this module. Each of the two signal names, sys rd and sys wr, is a signal to be connected to the input d-port signal of a D-flip-flop.
The third line of the source codes in 201 is an object command Endmodule. The Endmodule command indicates the end of the source codes for the module.
With this information, the translator 103 generates Verilog-HDL codes that imply two D-flip-flops, as shown in 202. The clock signal name, clk, and the reset signal name, rst_n, are obtained from the default values of a system variable $_clk and a system variable $_r, respectively. The triggering edge is chosen to be “posedge” in the event expression of the always_construct in 202 based on the value of a system variable $_clkedge. The reset values of the D-flip-flops are based on the default value of a system variable $_rval.
The signal name of the q-port of a D-flip-flop is derived from the given signal name of the d-port, appended with a suffix _f which is obtained from the value of a system variable $_dff_sfx.
The input port names are derived by getting the names of all of the signals not generated in this module. The output port names are derived according to the -o option of the Dff command. The “reg” declarations are generated based on the information in the always_construct in the translated Verilog-HDL.
The source codes in 301 of
There are only two lines of codes, which are in the hardware description language, in 301 of
The object command Declare in 301 indicates where the translated declaration codes should be placed. They are placed where the Declare command is, i.e., after the module declaration and before the input port declaration for the signal clk, in this example.
The object command Dff in 301 indicates a set of D-flip-flops is to be generated where the command is located.
After the source code 301 is translated, the Declare command is replaced by two reg declarations. The Dff command is replaced by an always_construct. The Verilog-HDL codes in the source codes are unchanged.
Note that there is no Module command in the source codes in this example. Hence, there is no automatic generation of the input port declarations. There is no -o option in the Dff command. Hence, there is no automatic generation of the output port declarations. There is no -r option in the Dff command. Hence, there is no reset code generated for the D-flip-flops.
The hardware description language constructs 401 of
A list of object command keywords is shown in 402. More object command keywords can be added to extend the language. Each object command defines a type of design object. The listed object command keywords are in the first keyword style of claim 4.
A list of compile command keywords is listed in 403. The compile commands do not define any specific design object. They assist to recognize, to include, to exclude, to set characteristics of, and to debug object commands. The listed compile command keywords are in the second keyword style of claim 5.
Three types of comments are listed in 404. The one-line-comment and the block comment are conventional comments. The macro-comment is in the present invention of claim 23.
Each keyword in 501 of
The module name Dff is in conflict with an object command keyword Dff of this hardware description language. To avoid mistakenly interpreting the module name Dff as an object command keyword Dff, a compile command ALT_KEYWORD_ON is added before the Verilog-HDL instantiation. After the compile command, the translator recognizes only the alternative keywords. The module name Dff is not recognized as an object command keyword since it is not an alternative keyword. Hence, the word Dff is regarded as a foreign text and it is not translated. After the instantiation, an alternative keyword _Dff is recognized as the start of an object command. To return back to regular keyword mode, a compile command _ALT_KEYWORD_OFF is issued. The object command Assign_ff is then recognized since it has a regular keyword.
In the object command Assign_ff in 502, the -cke option illustrates that a command option may have an optional assigned value, as claimed in claim 10.
The object command Pedetect in 502 of
The source codes in 601 of
The object commands Dff and Assign_ff use a default clock signal, which is obtained from the system variable $_clk. The value of the variable $_clk has been set to sys_clk. Hence, the event expressions in the always_constructs use sys_clk as the clock signal.
The example in 701 of
A number is an integer number or a real number. The example shows an integer 8 assigned to a variable $i. The variable is used in the second derivative assignment in the Assign_ff command, as the index of the bus_bit_select sys_data f[$i]. The bus_bit_select is translated to sys_data f[8] as shown in the translated codes in 702 of
The example in 701 shows a string enclosed by a pair of double-quotes. It is assigned to a variable $message. The variable is used in the compile command PRINT. During the translation, the string is printed out to the standard output of the computer system, which is typically the monitor of the system.
The third variable value type in the example in 701 is a simple-identifier. The variable $dir_signal is set to a simple-identifier sys_dir. The variable is used in the right-hand-side of the second derivative assignment in the Assign_ff command. As shown in 702, the variable $dir_signal is substituted by its value during translation. It is also used in the right-hand-side of the last derivative assignment in the command, in a concatenation.
The fourth variable value type in the example in 701 is a bus sys_data[7:0]. This value indicates that the identifier of the bus is sys_data. The most-significant-bit of the bus is 7 and the least-significant-bit of the bus is 0. The bus is assigned to a variable $dbus. The bus is used on the right-hand-side of the first derivative assignment and the last derivative assignments in the Assign_ff command. As shown in 702, the variable $dbus is substituted by its value during translation.
The fifth variable value type in the example in 701 is a bus_bit_select sys_data_f[9]. This value indicates that the identifier of the bus_bit_select is sys_data_f. The bit index is 9. The bus_bit_select is assigned to a variable $parity. The variable is used in the last derivative assignment of the Assign_ff command. As shown in 702, the variable $parity is substituted by its value.
In the object command Assign_ff in 701, a -clkedge option specifies the triggering edge to be the negative edge of the clock signal by the option value neg. As shown in 702, the event expression in the always_construct uses negedge instead of the default value posedge, which is stored in the system variable $_clkedge. This illustrates the claim 20. The value of a system variable is used in an object command if the value is not locally specified. In this example, the value of the system variable $_clkedge is locally specified. The locally specified value overrides the system variable value.
The
The modified code is shown in 802 of
The codes in 802 are translated to the codes shown in 803 of
The macro comment provides an easy way to clean up old codes through the translation. It also makes the translated codes more readable.
The step 901 of
If the step 904 determines that the token is not the start of a comment, the process goes to the step 906 to determine if the token is a keyword to start an object command. If it is, the step 940 is executed to handle the object command. The details of the step 940 are in
If the step 906 determines that the token is not the start of an object command, the process goes to the step 908 to determine if the token is a keyword to start a compile command. If it is, the step 960 is executed to handle the compile command. The details of the step 960 are in
If the step 908 determines that the token is not the start of a compile command, the process goes to the step 910 to determine if the token is the end-of-file. If it is not, the token is not recognized as the start of a construct in the hardware description language. The token is considered a foreign text. In this case, the step 980 is executed to handle the foreign text. The details of the step 980 are in
If the step 910 determines that the token is the end-of-file, the process goes to the step 990 to handle the end of the file. The details of the step 990 are in
The step 921 of
After the step 923 or the step 924, the comment handling is complete. The process goes back to the step 902.
The step 941 of
The keywords shown in the example in
If the result of any of the checks in the steps of the previous paragraph is affirmative, the step 948 is taken to handle each of the specific object command. The first step in handling the specific object command is to check if there is any command option following the object command keyword. The check is done in the step 949. If the check in the step 949 determines there is command option, the step 950 is taken to handle the command option. In the step 950, each command option is parsed, and the values of the appropriate system variables are locally modified according to the parsed command option. The command option is parsed one-by-one until the command options are exhausted. The scope of the locally modified values is only the current command. The modification does not effect other commands.
After the step 950 is complete, or after the check in the step 949 determines that there is no command option for the object command, the process proceeds to the step 951, which starts to process the command syntax body.
In processing the command syntax body, the first step is to parse the command syntax body, as shown in the step 952. The syntax body is command dependent and is defined by the hardware description language in its documentation. After the syntax is parsed, the syntax is translated and written out to the translated output file, as shown in the step 953.
The translation in the step 953 has two methods. For the method of the claim 24, the object command is translated into Verilog-HDL primitive gates and instantiated library modules. For the method of the claim 25, the object command is translated into the constructs of a second hardware description language.
After the step 953, the process goes back to the step 902.
If the token does not match any object command keyword, the process goes to error handling in the step 947. In this step, the process reports the error. After the step 947, the process goes back to the step 902.
The step 961 of
The keywords shown in the example in
If the result of any of the checks in the steps of the previous paragraph is affirmative, the step 968 is taken to handle each of the specific compile command.
The first step in the compile-command processing is to parse the command, as shown in the step 969. The compile command is parsed based on the syntax defined for the specific compile command being processed.
After the compile command is successfully parsed, the compile command is executed, as shown in the step 970. The execution is done based on the definition of the specific compile command being executed.
In the step 970, the execution flow of some conditional compile commands, such as the IF command, depends on the evaluation result of the conditional expression. If the result is true, the block of commands in the IF-clause is active and is translated. If the result is false, the block of commands is inactive and is not translated. The inactive commands do not induce the generation of port declaration or signal type declaration.
After the step 970, the process goes back to the step 902.
If the token does not match any compile command keyword, the process goes to error handling in the step 967. In this step, the process reports the error. After the step 967, the process goes back to the step 902.
The step 981 of
The step 991 of
In the step 993, a module port declaration file is generated. The file contains only module port declaration information. The file is read when the module is instantiated by an object command Inst. The information in this file supplements the information in the Inst command so that the Inst command can be simplified.
After the step 993, the process goes back to the step 902.
If the check in the step 992 is negative, a second check is done in the step 994. In this step, the process checks if there is a Declare command encountered in the source file. If there is a Declare command, the step 995 is taken. In the step 995, the generated declarations are written out to the output file at the location where the Declare command is found.
In the step 995, a module port declaration file is generated. The file contains only module port declaration information. The file is read when the module is instantiated by an object command Inst. The information in this file supplements the information in the Inst command so that the Inst command can be simplified.
After the step 995, the process goes back to the step 902.
If the check in the step 994 is negative, the step 996 is taken. In this step, an error message is generated to report that there is no information to determine where the generated declarations to be written.
After the step 996, the process goes back to the step 902.
The foregoing describes the present invention and its preferred embodiments. There are numerous modifications and variations are expected to occur to those skilled in the art, in the practice of this invention. Therefore, the embodiments described herein should be taken as illustrative and not restrictive.