Architectural structure of a process netlist design tool

[0002] 1. Technical Field

[0003] The present invention generally relates to electronic circuit fabrication. More particularly, the present invention relates to a computer-based method and architecture that automatically transforms a behavioral description of a circuit into a hardware level representation of the circuit.

[0004] 2. Discussion

[0005] In order to fabricate an electronic circuit such as an application specific integrated circuit (ASIC) or a field programmable gate array (FPGA), a number of time critical processes must be completed. For example, the first step is to design the circuit at a “behavioral” level. The behavioral level can be viewed as a top level of a hierarchy, in which the hardware level of the hierarchy characterizes the circuit in terms of actual hardware components and is positioned at the bottom of the hierarchy. The behavioral description therefore might be a block diagram or netlist that describes the various functions of the circuit in relatively general terms.

[0006] Characterizing the circuit at the hardware level based on the behavioral description is critical in the circuit fabrication process. This is because the generally described functions in the behavioral description do not have enough specificity to fully enable the circuit manufacturer to implement the design. The conventional approach is therefore to manually generate an electronic file that characterizes the circuit at the hardware level in a desired programming language such as the well-known hardware description language (HDL). Thus, a design engineer with intricate knowledge of the electronic principles contained in the circuit as well as the desired programming language must go through the behavioral description on a component-by-component basis and generate the necessary code sets in the desired programming language. It is easy to understand that such an approach is quite labor intensive and subject to human error. It is therefore desirable to provide a mechanism for automatically characterizing a circuit at a hardware level.

[0007] Once the electronic file has been manually generated, a complex verification process is also required. Thus, operation of the circuit is simulated by providing the electronic file with a set of predefined inputs. The simulation results are compared with known output values that should have resulted from the simulation process. In the case of the ASIC, a model of the circuit in the well known C programming language is also manually generated to provide a cross-verification mechanism. This is typically required due to the complex nature of the ASIC fabrication process and the resulting need for a high level of certainty as to the functionality of the electronic file. Once again, the manual generation of the C model requires detailed knowledge of the C programming language and results in a significant increase in the labor costs associated with the overall fabrication process. Once the electronic file has been verified, it is typically converted into a format that is conducive to the equipment of the manufacturer using one or more well-known conversion programs such as commercially available Synopsis. After the electronic file has been converted, the manufacturer can engage in various fabrication processes such as liquid or plasma etching in order to fabricate the circuit.

[0008] It will be appreciated that the above manual processes add to both the lead time and fabrication costs associated with the circuit. It is therefore desirable to provide a mechanism for mapping known circuit components to a code set for a desired programming language in order to characterize a circuit at a hardware level in the desired programming language based on a behavioral description of the circuit.

[0009] The above and other objectives are provided by a computer-implemented method for characterizing a circuit at a hardware level in accordance with the present invention. The method includes the step of receiving a description of the circuit, where the description characterizes the circuit at a behavioral level of a hierarchy. The method further provides for receiving a set of predefined computer-based commands requesting desired modifications in the description of the circuit. An electronic file is then generated based on the computer-based commands such that the electronic file characterizes the circuit at a hardware level in a desired programming language. The hardware level is at a lower level in the hierarchy than the behavioral level. The use of computer-based commands to automatically generate the electronic file reduces manual labor requirements to levels unachievable through conventional approaches.

[0010] Further in accordance with the present invention, a computer-implemented method for generating an electronic file is provided. The method includes the step of implementing desired modifications in a description of a circuit with a set of predefined modules based on computer-based commands and a library of foundry primitives. The foundry primitives map known components to code sets for a desired programming language. A hierarchical netlist is also generated, where the hierarchical netlist represents the circuit at each level in a hierarchy. The method further provides for repeatedly updating the hierarchical netlist in accordance with the modifications.

[0011] In another aspect of the invention, a computer-implemented design tool architecture is provided. The architecture includes a medium for storing a description of an application specific integrated circuit (ASIC), where the description describes the ASIC at a behavioral level of a hierarchy. The architecture further includes a library of foundry primitives and a command interpreter. The foundry primitives map known ASIC components to code sets for a hardware description language (HDL). The command interpreter generates an electronic file based on a set of predefined computer-based commands such that the electronic file characterizes the circuit at a hardware level. The hardware level is at a lower level in the hierarchy than the behavioral level.

[0012] It is to be understood that both the foregoing general description and the following detailed description are merely exemplary of the invention, and are intended to provide an overview or framework for understanding the nature and character of the invention as it is claimed. The accompanying drawings are included to provide a further understanding of the invention, and are incorporated in and constitute part of this specification. The drawings illustrate various features and embodiments of the invention, and together with the description serve to explain the principles and operation of the invention.

[0013] The present invention will become more fully understood from the detailed description and the accompanying drawings, wherein:

[0014] FIG. 1 is a flowchart of a computer-implemented method for characterizing a circuit at a hardware level in accordance with the principles of the present invention;

[0015] FIG. 2 is a flowchart of a process for implementing desired modifications with a set of predefined modules in accordance with one embodiment of the present invention;

[0016] FIG. 3A is a block diagram of an original architecture of a circuit before application of an architecture sharing command in accordance with principles of the present invention;

[0017] FIG. 3B is a block diagram of a reduced architecture resulting after application of an architecture sharing command to the original architecture of FIG. 3A in accordance with principles of the present invention;

[0018] FIG. 4 is a block diagram generally illustrating reduction of control logic in accordance with principles of the present invention;

[0019] FIG. 5A is a block diagram of a path in accordance with the principles of the present invention;

[0020] FIG. 5B is a block diagram of a set of parallel paths in accordance with principles of the present invention;

[0021] FIG. 6 is a block diagram showing a two-way multiplex control counter in accordance with principles of the present invention;

[0022] FIG. 7A is a block diagram of an original component before application of an implementation assignment command in accordance with principles of the present invention;

[0023] FIG. 7B is a block diagram showing implementation components after application of an implementation assignment command to the original component shown in FIG. 7A; and

[0024] FIG. 8 is a block diagram illustrating delay shifting in accordance with principles of the present invention.

[0025] The following description of the preferred embodiment(s) is merely exemplary in nature and is in no way intended to limit the invention, its application, or uses.

[0026] Turning now to FIG. 1, it can be seen that the present invention generally provides a computer-implemented method 20 for characterizing a circuit (not shown) at a hardware level. It is important to note that the circuit is preferably an application specific integrated circuit (ASIC), but other types of circuits such as a field programmable gate array (FPGA) can also benefit from the present invention. Furthermore, the particular application in which the circuit is used is not critical. Thus, the method 20 has a wide range of expected uses.

[0027] Generally, the method 20 includes an initialization step 22 wherein a description 21 of the circuit is received. The description 21 characterizes the circuit at a behavioral level of a hierarchy, and is preferably in the form of either a block diagram or a descriptive netlist. A netlist is a list of names of symbols or parts and their connections to points which are logically connected in each net of a circuit. Netlists can ordinarily be captured from properly prepared schematic drawing files of an electrical computer aided engineering (CAE) application.

[0028] Upon receiving a new command at step 24 (from a source such as a user keyboard or script driver input), the predefined computer-based command is interpreted at step 28, where the command requests a desired modification in the description of the circuit. An example modification might be a request to replace a digital filter with a delay chain and multipliers. At step 30, an electronic file is generated based on the computer-based command such that the electronic file characterizes the circuit at the hardware level in a desired programming language. It is important to note that the method 20 is an iterative one, and that the electronic file is “built-up” as commands are received. It is also important to note that the hardware level is located at a lower level in the hierarchy (typically the bottom) than the behavioral level.

[0029] Although the desired programming language is preferably the well known hardware description language (HDL), it will be appreciated that the present invention is not so limited. Particularly, in the case of an ASIC, it may be desirable to provide a verification mechanism in the form of a C language file. Simulating the operation of the circuit with the C language file therefore provides a mechanism for crosschecking the HDL file. In such cases, the desired programming language is the C programming language. It is important to note, however, that the present invention provides confirmation algorithms that (depending on the confidence requirements of the application) might obviate the need for the C language file.

[0030] Turning now to FIG. 2, it can be seen that the preferred approach to the step 28 of interpreting the commands provides many useful features. For example, when a replacement command is received at step 40, an original component (e.g., digital filter) of the circuit residing at an original level in the hierarchy will be replaced at step 38 with one or more replacement components (e.g., delay chain and multipliers) residing at a lower level in the hierarchy. Step 38 also provides for confirming that the replacement components are functionally equivalent to the original component with regard to the circuit. Detailed confirmation algorithms will be discussed in greater detail below. At step 26 the hierarchical netlist is transformed (or updated) in accordance with the modifications.

[0031] It will be appreciated that an important aspect of ASIC design is the concept of architecture sharing. Architecture sharing generally provides a mechanism for the sharing of physical processing paths by symbolic (logical) processing in order to conserve resources. For example, a block diagram of a circuit at a behavioral level might call for ten multipliers each being clocked at 1 MHz, whereas architecture sharing permits the use of one multiplier operating at 10 MHz. Thus, when it is determined at step 32 that an architecture sharing command has been entered, an original architecture of the circuit is reduced at step 42 such that a reduced architecture results. Furthermore, it can be seen that step 42 provides for confirming that the reduced architecture is functionally equivalent to the original architecture with regard to the circuit.

[0032] The process of confirming that the reduced architecture is functionally equivalent to the original architecture with regard to the circuit will now be described in greater detail. With continuing reference to FIGS. 3A and 3B, the original architecture 34 will be described for an arbitrary n as follows: $\begin{array}{cc}X\left(n\right)=F\left[x\left(n\right)\right];& X\left(n-1\right)=F\left[x\left(n-1\right)\right]\\ Y\left(n\right)=F\left[y\left(n\right)\right];& Y\left(n-1\right)=F\left[y\left(n-1\right)\right]\\ Z\left(n\right)=F\left[z\left(n\right)\right];& Z\left(n-1\right)=F\left[z\left(n-1\right)\right].\end{array}$

[0033] If the reduced architecture 36 is defined as $A\left(n\right)=\{\begin{array}{cc}X\left(\frac{n}{3}\right)& \text{When}n\mathrm{mod}3=0\\ Y\left(\frac{n-1}{3}\right)& \mathrm{When}n\mathrm{mod}3=1\\ Z\left(\frac{n-2}{3}\right)& \mathrm{When}n\mathrm{mod}3=2\end{array}$

[0034] Then

[0035] C(n)=F[A(3n−3)]=X(n−1)

[0036] D(n)=F[A(3n−2)]=Y(n−1)

[0037] E(n)=F[A(3n−1)]=Z(n−1)

[0038] thus, the original architecture 34 is equivalent to the reduced architecture 36. Specifically, it can be seen that interpolators 44 (or up converters) and decimators 46 (or down converters) permit the use of an instantaneous function F to be reduced by a factor of 3.

[0039] Returning now to FIG. 2, it can be seen that the present invention also provides for control logic reduction. This feature is particularly important in cases where architecture sharing results in an increase in control logic. Thus, when it is determined that a control logic reduction command has been received at step 48, redundant control logic of the circuit is eliminated and necessary control logic is modified at step 50 such that a reduced logic architecture results.

[0040] FIG. 4 illustrates the transformation of a general cloud of logic 52 into a rate change component (or reduced logic architecture) 54. It will be appreciated that the cloud of logic 52 contains various rate change components such as delays, multiplexers, interpolators and decimators. It will further be appreciated that the cloud of logic 52 can be defined as a set of path lists interconnecting a set of inputs to a set of outputs. FIGS. 5A and 5B demonstrate a single path 56 and a set of paths 58, respectively. The single path 56 between points A and B is therefore characterized by,

[0041] corresponding to the single path 56 of FIG. 5A.

[0042] A path list is therefore made up of a set of paths 58 from point A to point B such that each path has the same ↓N and ↑M. It will be appreciated that in order to ensure that two outputs do not arrive concurrently, the set of paths 58 in constrained by, (Kri−KRj) MOD M≠O for any i≠j. Thus, a rate change component 54 can be defined as a set of path lists, interconnecting the set of inputs, as shown in FIG. 4.

[0043] The various multi-rate components can therefore be represented as

[0044] Furthermore, FIG. 6 illustrates that a 2-way counter-controlled mux 60 can be given by the counter representation 62. In order to resolve two paths in series we have

[0045] Specifically, the algorithm is given by

[0046] Algorithm:

[0047] (1)

[0048] L(M₁,N₂)

[0049] (2)

[0050] If(K_R1+K_L2)MOD L≠O

[0051] Delete path

[0052] Go to “DONE” $\begin{array}{cc}{\stackrel{\_}{M}}_1=\frac{M_1}{L};{\stackrel{\_}{N}}_2=\frac{N_2}{L};& \left(3\right)\end{array}$

[0053] (4) Use Euclid's algorithm to find P₁, P₂, such that

[0054] P₁{overscore (M)}₁+P₂{overscore (N)}₂=1

[0055] (5) Define the equivalent values for the new path $K_{\mathrm{Leq}}=K_{\mathrm{L1}}+N_1{K}_{M_1}+\frac{K_{\mathrm{R1}}+K_{\mathrm{L2}}}{L}{P}_1{N}_1$ $K_{\mathrm{Req}}=K_{\mathrm{R2}}+M_2{K}_{M_2}+\frac{K_{\mathrm{R1}}+K_{\mathrm{L2}}}{L}{P}_2{M}_2$  K_Meq=0

[0056] N_eq=N₁{overscore (N)}₂

[0057] M_eq={overscore (M)}₁M₂

[0058] (6) “DONE”

[0059] Returning now to FIG. 2, it can be seen that the present invention further provides for determining whether an implementation assignment command has been received at step 64. Step 66 therefore provides for replacing an original component of the circuit with one or more implementation components based on the implementation assignment command. Specifically, FIGS. 7A and 7B illustrate that an original component 68 (although not necessarily a component of the behavioral description) has one or more implementation components 70 that are equivalent to the original component 68. It will be appreciated that the implementation components 70 are contained within the library of foundry primitives and have unambiguous HDL descriptions associated with them. Typically, the implementation components are adders and multipliers. For example, if implementation component 70ais a multiplier that multiplies two 5-bit numbers and produces a 10-bit result, this component can be readily represented in HDL.

[0060] returning now to FIG. 2, it can be further be seen that the present invention provides for determining whether a delay shifting command has been received at step 72. Thus, provides for moving a delay component from a first location in the circuit to a second location in the circuit based on the delay shifting command. Specifically, FIG. 8 illustrates the rearrangement of an original architecture 76 by moving a delay component 78 from a first location in the circuit to a second location. Thus, the resulting architecture 80 has a total delay that is maintained.

[0061] It is important to note that the hierarchical netlist has a unique file structure that is represented in several equivalent forms throughout the transformation process. It is preferred that an element in the netlist is represented by a N-tuple, defining:

[0062] The design tool architecture therefore accepts inputs at the behavioral level, and automatically generates both compilable code at the HDL level, and C-code for efficient system simulation. When the tool architecture is script driven, automatic transformation of the behavioral description (either block diagram or netlist) into a structural HDL form is possible. In the structural HDL form, realizable foundry library components (such as adders and multipliers) are substituted for idealized components and architecture sharing and bit precision are defined. The automated code generation and associated file structure produced by the tool architecture allow the design time from system concept to delivery of compiled code for the resulting ASIC to be reduced by as much as a factor of 10.

[0063] It is important to note that the file structure allows for efficient 2-way travel through the hierarchical netlist when executing the transformations. Furthermore, the tool architecture allows for a systematic hierarchical proof of equivalence at every transformation, rather than requiring a much more complex (and often infeasible) proof of overall equivalence at the completion of compilation. The command sets (i.e., transformations) are preferably script driven, and are intended to be reusable to efficiently optimize a given problem architecture as well as to solve similar functional problems.

[0064] Those skilled in the art can now appreciate from the foregoing description that the broad teachings of the present invention can be implemented in a variety of forms. Therefore, while this invention can be described in connection with particular examples thereof, the true scope of the invention should not be so limited since other modifications will become apparent to the skilled practitioner upon a study of the drawings, specification and following claims.