Method to translate UDPs using gate primitives

Attached hereto is a microfiche appendix to the present invention, listing source code for an embodiment of the present invention. The total number of microfiche is 18 pages and the total number of frames is 19 frames.

1. Field of Invention

The present invention relates generally to a method of translating User Defined Primitives (UDPs) in the Verilog format into another format.

2. Description of Related Art

Modern digital design of complex circuits and systems, which can contain millions of interconnected gates, involves a number of techniques for manageable design. Tools using computer-aided design (CAD), hardware description languages (HDL), logic synthesis, and hierarchy design are employed.

A hardware description language (HDL) representation of a circuit is a representation of a circuit in text rather than graphically, enabling a more uniform, portable representation of the circuit, one that can be manipulated by a computer program. Currently, Verilog and VHDL are two IEEE standards of HDLs. The Verilog standard evolves over time, and the present invention is designed to work with the current version, though it is adaptable to work with future versions of the Verilog IEEE standard. HDL may be stylized into “structural” (e.g. at the gate-level), “behavioral” or “dataflow” (typically at the higher level description of a circuit), or any combination of the above. HDL representations are used in logic synthesis, the conversion of a high-level electronic circuit description into a list of logic gates and their interconnections, called the “netlist”.

An HDL description of a system can be written at an intermediate level referred to as a register transfer language (RTL). A subset of RTL that is used by logic synthesis tools is known as “snythesizable RTL”. A logic synthesis tool with a library of components can convert a RTL description into an interconnection of primitive components that implements the circuit, subject to any specified constraints, such as timing, speed, power consumption and area constraints. The output of the logic synthesis tool, after an optimization process referred to as technology mapping, is a so-called netlist of interconnected storage elements, gates, and other functional blocks (note the term “net” is also a keyword in Verilog, and represents a data type comprising a physical connection between structural elements). The netlist output serves as input to physical design tools that physically place the logic elements and route the interconnections between them to produce a manufacturing circuit layout. When programmable parts are employed, such as field-programmable gate arrays, binary information is produced by design tools to program the logic within the parts.

User-defined primitives (UDP) in the Verilog HDL language are user-defined primitive gates that lie outside the “built-in” primitive gates provided by Verilog, such as “and”, “nand”, “nor”, “or”, “xor”, “xnor”, “buf”, “not”, “cmos”, “pmos”, “nmos”, “tran” and the like. Oftentimes, a designer may wish to translate a Verilog UDP into another format, such as a LogicVision model format.

LogicVision (LV) is a company that produces a suite of test insertion tools that take a netlist, insert structures, and convert the netlist and into a form suitable for testing purposes. The LogicVision suite performs such functions as boundary scan insertion, automatic test pattern generation, logic and memory BIST (Built-In Self Test) insertion. LogicVision uses a particular format, which can be viewed as a subset of the Verilog HDL. The entire Verilog HDL is not understood by LogicVision, and a Verilog model has to be translated into a LogicVision model before it can be used by a LogicVision test insertion tool. The LogicVision model format is easy to describe once the Verilog HDL is translated into basic logic gate descriptions. Thus, concerning the present invention, by translating a circuit described in a Verilog format, having UDPs (User Defined Primitives), into its constituent logic gates, a LogicVision format is easily obtainable, thus making the original circuit description suitable to a test insertion tool such as found in the LogicVision suite.

The present invention relates generally to a method of translating Verilog User Defined Primitives (UDP) to basic logic gates, i.e., gate level primitives, which can be used in another format, such as the LogicVision model format.

Accordingly, an aspect of the present invention is to provide a software program to translate a Verilog UDP (User Defined Primitive) into basic logic gates, in order to allow easier porting into other HDL languages and non-Verilog models, such as the LogicVision model. LogicVision libraries and many other libraries rely primarily on Verilog models, such as the Verilog XL 3.0 library, thus the present invention has value in providing UDP translation for such non-Verilog models.

In a preferred embodiment, the program is in Perl script, and reads in a Verilog source file. On finding a UDP, the script writes out a gate level description of the UDP.

The advantages of the present invention are:

(1) providing a unique method to translate UDPs into gate primitives;

(2) converting into a lowest common denominator between standards, by way of a gate description of a Verilog UDP, enabling porting of a Verilog UDP into another model, such as a LogicVision model;

(3) allowing better handling of ‘x’ states and event scheduling by using gate level primitives;

(4) providing an interface for other software tools that have difficulty reading in Verilog UDPs.

The above described features and many other features and attendant advantages of the present invention will become apparent from a consideration of the following detailed description when considered in conjunction with the accompanying drawings.

Detailed description of preferred embodiments of the invention will be made with reference to the accompanying drawings.

FIG. 1 is a top-level flowchart depicting a preferred embodiment of the invention.

Disclosed herein is a detailed description of the best presently known mode of carrying out the invention. This description is not to be taken in a limiting sense, but is made merely for illustrating the general principles of the invention. The section titles and overall organization of the present detailed description are not intended to limit the present invention.

User-defined primitives (UDP) in the Verilog HDL language are user-defined primitive gates that lie outside the “built-in” primitive gates provided by Verilog, such as “and”, “nand”, “nor”, “or”, “xor”, “xnor”, “buf”, “not”, “cmos”, “pmos”, “nmos”, “tran” and the like. UDP allow a user more flexibility in defining a primitive circuit. A UDP can be described as either combinational or sequential (edge-triggered and level-sensitive). A UDP is instantiated the same way as a built-in Verilog primitive gate, and declared using the following syntax (keywords are in bold):

A UDP definition does not depend on a module definition and thus appears outside of a module definition, and can be in a separate text file. Further, a UDP can have only one output and may have one or more inputs. The first port must be the output port, which can have the value 0, 1 or x. The behavior of a UDP is described in the form of a table.

Two kinds of behavior can be described in a UDP: (1) combinational and (2) sequential (edge-triggered and level-sensitive).

An example of a combinational UDP circuit is a 2-to-1 multiplexer, e.g.:

with the ? character representing a don't-care condition (any of 0, 1 or x), and the order of the input ports matching the order of entries in the table.

An example of a sequential circuit UDP might be the following level-sensitive sequential UDP that models a D-type latch. With the clock at 0, the data passes from input to output, otherwise the value remains latched. The—character implies no change, and the state of the UDP is stored in register Q.

The goal of the present invention is to decompose and translate these UDPs into their constituent gate-level primitives (e.g., nand, nor, xor gates), all the while preserving the functionality of the UDPs.

Turning now to FIG. 1, there is shown a top-level flowchart for carrying out a generalized software driven tool employing the principles of the present invention. The software tool may be written in any computer language, preferably Perl, and run by a general purpose computer system, preferably a computer with ample primary and secondary memory storage, or any specialized hardware or firmware. Depending on the language used to construct and implement the translation tool software, the software may have any number of classes, functions, subroutines, objects, variables, templates, module(s), lines of code, portions of code and constructs (collectively and generally, and as depicted by the flowcharts herein, “a process step”, “step”, “block”, “block step” or “software module”, with the understanding “module” is also a keyword in Verilog) to carry out the invention in successive stages as described and taught herein, and may be either a standalone software application, or employed inside of or called by another software application. The software process or software module may be constructed so that one portion of code in the application performs a plurality of functions, as for instance in Object Oriented programming (e.g., an overloaded process). The converse is also true in that a plurality of software modules or process steps may be constructed to perform the function of a single process step described herein, without loss of generality for the present invention. At any stage of the process step of the present invention, intermediate values, variables and data may be stored for later use by the program. The software of the present invention is preferably designed to work with the present Verilog IEEE standard, and in particular with Verilog XL 3.0. Verilog XL 3.0 is a Cadence simulator of the Verilog HDL. However, in general, using the principles disclosed herein, it is possible to adapt the software to work with future standards of the Verilog HDL, and future simulators of Verilog, as they may evolve.

Referring now to the top-level flowchart of the invention in FIG. 1, and to the source code in the Perl programming language attached hereto as a microfiche appendix, a preferred embodiment of the invention will be described.

Generally, the invention can be broadly broken down into three portions. Software module(s) open for reading an input file containing source code describing a Verilog model circuit, and open for writing an output file that will contain the LogicVision model code. Second, software module(s) go through the Verilog model, which is described in one long string, and remove portions of the string that relate to various features in Verilog. The features are stored in a data structure that uses a hash function to store the features. Software module(s) translate and decompose the Verilog portions of the string into constituent parts that comprise primitives and portions of a netlist that may be used to translate the Verilog model into the LogicVision model. Finally, suitable software module(s) clean up the data structure and output the LogicVision model in a suitable format that a user may utilize. In the present invention, one or more software modules may be combined to perform the same task, and a software module may be broken up into several other software modules to collectively perform a given task, without detracting from the generality of the invention and the description herein.

Turning attention now to FIG. 1, there is shown in a first process step, the Verilog HDL model (the source code describing a circuit in Verilog HDL) is opened to be read by the software program, as disclosed by step 1 - 10 in FIG. 1 . This step corresponds in the Perl source code of the microfiche appendix as program lines 112 on pg. 2, in the line marked “open (INFILE,“<$verfile”) . . . ” In Perl, binary data can be treated as a string. In general, a string can include alphanumeric text and/or binary data, as the case arises.

Similarly, the LV model (LogicVision model) that is to be written to with the gate primitives is opened by the program of the present invention for a write operation, as indicated in step 1 - 10 in FIG. 1, and corresponding to the Perl source program lines 116, on pg. 2, in the line marked “open (OUTFILE, “>$lv_file”) . . . ”.

After reading the Verilog model source code (i.e., the Verilog HDL netlist description of the circuit), all behavioral codes, which have no bearing on a UDP, comments and compiler directives are stripped out of the string that has been read, as indicated in step 1 - 20 of FIG. 1, which corresponds in the Perl source code as program lines 120-126 on pg. 2, in the lines marked “if ($file=˜/initial|always . . . if ($file=˜/specify.+endspecify . . . ”.

In decision block step 1 - 30 , the script ensures that it has completed processing the Verilog model that was read in. The Verilog model is contained in one long string, and the script removes portions of the string as it completes processing that section of the model. Once the string is empty, the script knows that the Verilog model has been completely processed. If the Verilog model has been processed, and the string is empty, the decision block 1 - 30 is satisfied (which can be thought of as satisfying a predetermined condition), and flow chart control is passed to block step 1 - 190 of FIG. 1; otherwise, if the string is not empty, control passes to decision block step 1 - 40 . In the Perl source code this step corresponds to program lines 128, on pg. 2, in the line marked “while ($file) . . . ”.

In decision block step 1 - 40 , the Verilog module declaration is checked; the Verilog keyword “module” is searched for, along with the proper port list that must follow. A port list gives the list of ports (input, output or inout) through which a module communicates with external modules. If there is a valid Verilog module declaration, the decision block 1 - 40 is satisfied, and control is passed to step block 1 - 50 , otherwise, control is passed to decision block 1 - 60 labeled “Port Declaration”. The decision block step 1 - 60 corresponds in the Perl source code to program lines 132, on pg. 2, in the line marked “if ($file=˜/{circumflex over ( )}module . . . ”.

In step block 1 - 50 , the variables are initialized, ports are checked for correct syntax, and a Perl data structure is set up for cell information. The Perl data structure used is a hash of information as illustrated below (% indicates a Perl hash structure):

%module

name=>verilog module name

ports=>list of all verilog module ports

inports=>list of verilog module input ports

outports=>list of verilog module output ports

inoutports=>list of verilog module inout (bidirectional) ports

%primitives

primname=>name of verilog gate primitive

ports=>ordered list of verilog gate primitive ports

%udps

udpname=>name of verilog udp

ports=>ordered list of verilog udp ports

In the Perl source code this step corresponds to program lines 134-154, on pp. 2-3, in the lines marked %module=( ) . . . $module{ports}=&parse_and_check_ports ($2, $module{inports}. . . ”. After this step, control is passed once again back to decision block 1 - 30 , where the program continues in a loop until the Verilog model has been completely processed.

Assuming no Verilog module declaration, control is passed by the program of the present invention to decision block 1 - 60 , where the Verilog HDL model is checked for port declarations. In the Perl source code this step corresponds to program line 160, on pg. 3, in the line marked if “($file=˜/{circumflex over ( )}(input|output|inout) . . . ”.

If there is such a port declaration, decision block 1 - 60 is satisfied, and control is passed to step block 1 - 70 , where the input/output/inout port information of the Verilog model is added to the data structure described in section block 1 - 50 . In the Perl source code this step corresponds to program lines 164-166, on pg. 3, in the lines marked “if ($1 eq “input) . . . elsif ($1 eq “inout”) . . . ”. Control is then passed back to decision block 1 - 30 , where the program continues to loop.

If there are no more port declarations in the Verilog model, control is passed to decision block 1 - 80 by the program of the present invention, where Verilog primitives that are supported natively by the LV model are checked to see if they are present. In the Perl source code this step corresponds to program line 198, on pg. 3, in the line marked “if ($file=˜(/{circumflex over ( )}($primlist) . . . ”. If these LV supported Verilog primitives are present, control is passed to step block 1 - 90 , where the Verilog primitive is added to the data structure without any need for modification. In the Perl source code this step corresponds to program line 208, on pg. 4, in the line marked “push @{$module{primitives}}. . . ”. Control is then passed back to decision block 1 - 30 .

If there are no LV supported Verilog primitives, control is passed to decision block 1 - 100 . In the Perl source code this step corresponds to program lines 172, 185, on pg. 3, in the lines marked “if ($file=˜/{circumflex over ( )}nmos . . . and if ($file=˜/{circumflex over ( )}(pmos|rpmos) . . . ”. The Verilog model is checked for Verilog primitives unsupported by the LV model. If such LV unsupported Verilog primitives are found, decision block 1 - 100 is satisfied, and control is passed to step block 1 - 110 , where the LV unsupported Verilog primitives are translated into and changed to LV supported primitives. In the Perl source code this step corresponds to program lines 179, 192, on pg. 3, in the lines which are both marked “push @{$module{primitives}}”. Control is then passed back to decision block 1 - 30 .

Assuming no unsupported Verilog primitives are found, control is passed by the program of the present invention to decision block 1 - 120 , where the Verilog model is checked for the presence of LSI Flexstream 2.0 supported UDPs. LSI Flexstream 2.0 is a design kit that provides all tools and libraries necessary to complete an ASIC (Application Specific Integrated Circuit) design. LSI Flexstream 2.0 provides Verilog UDPs referenced by the Verilog library. In the Perl source code this step corresponds to program lines 214-225, on pg. 4, in the lines marked “if ($file=˜/{circumflex over ( )}(LSI_MUX21\b|LSI_UDP —MUX 2\b . . . LSI_UDP_SB_AND_RB_ACTIVE . . . ”. If such LSI Flexstream 2.0 supported UDPs are found, decision block 1 - 120 is satisfied, and control is passed to step block 1 - 130 , where the UDP ports are checked for correct syntax and added to the data structure. In the Perl source code this step corresponds to program line 229, on pg. 4, in the line marked “$ports=&parse_and_check_ports . . . ”. Control is then passed back to the loop at point 1 - 140 , where the next decision block 1 - 150 is encountered.

In decision block 1 - 150 , LSI Flexstream 2.0 UDP names are recognized. In the Perl source code this step corresponds to program lines 235, 250, 258, . . . , on pg. 4 and onward, in the line marked “if ($file=˜/{circumflex over ( )}LSI_UDP_MUX21\b . . . ”. If such individual UDP names are present, decision block 1 - 150 is satisfied, and control is passed to step block 1 - 160 , where the gate level equivalent of such individual UDP names are stored in the Perl data structure. In the Perl source code this step corresponds to program line 239, 252, 260, . . . , on pg. 4 and onward, in the lines marked “push@{$module{udps}. . . ”. Control is then passed back to decision block 1 - 30 , where the program returns to the loop.

If no individual UDP names are recognized in decision block 1 - 150 , control is passed by the program of the present invention to decision block 1 - 170 , where the Verilog model is checked for LSI Flexstream 2.0 UDPs that are used for modeling reduced pessimism and aiding in timing checks. Modeling reduced pessimism and aiding timing checks are structures that are not required by LSI Flexstream 2.0 supported test tools such as LogicVision. In LSI Flexstream 2.0 test tools, a UDP is deemed unsupported on a case-by-case basis.

In the Perl source code the step of decision block 1 - 170 corresponds to program line 942, on pg. 15, in the line marked “if ($file=˜/{circumflex over ( )}($extraudps) . . . ”. If such LSI Flexstream 2.0 test tool unsupported UDPs are found, then decision block 1 - 170 is satisfied, and control is passed back to decision block 1 - 30 , where the program returns to the loop. If such UDPs are absent, then control of the program is passed to the portion of software shown by block 1 - 180 , and an error message is outputted or printed for the presence of an unknown statement, as indicated by step block 1 - 180 . This serves as a catch all for preventing any unexpected statements or definitions from being translated. In the Perl source code this step corresponds to program line 946, on pg. 15, in the line marked “if ($file=˜/{circumflex over ( )}(\w+.+?;) . . . ”. This last step, 1 - 180 , forms the last part of the loop comprising blocks 1 - 30 through 1 - 180 , which may be though of as similar to a nested ‘if-then’, ‘switch’ and ‘case’ statement, with the last block, 1 - 180 , forming the default case statement when all other conditions are not met.

Turning to step block 1 - 190 , this statement is reached when, at decision block 1 - 30 , the Verilog model has been completely processed. The Verilog model has additional gates used for aiding timing checks that are not needed by test tool models. These additional gates were previously connected to the UDPs that were removed in the previous step. After blocks 1 - 30 through 1 - 180 are completed, these gates will show up in the data structure as being unconnected from the rest of the module. At step block 1 - 190 , the gates that are unconnected are removed from the data structure. In the Perl source code this step corresponds to program line 951, on pg. 15, in the line marked “&remove_extra_logic ($module{primitives}. . . ”.

After step 1 - 190 , control is passed by the software of the present invention to step block 1 - 200 , where the LV model is outputted or printed, using typical I/O devices such as a monitor or printer, from the data structure. The output may also be in the form of electronic data such as HDL source code stored on a hard drive. In the Perl source code this step corresponds to program lines 957-989, on pg. 15, in the lines marked “print OUTFILE “{acute over ( )}celldefine . . . print OUTFILE“{acute over ( )}endcelldefine . . . ”.

Finally, when the output from the program is complete, the software terminates, as indicated by the EXIT statement block 1 - 210 .

Though the preferred embodiments are disclosed in the present invention, alternative mechanisms may be employed without departing from the scope of the invention. For example, the use of LSI Flexstream 2.0 supported UDPs could be replaced with another version of LSI Flexstream UDP, or any other UDP, without loss of generality. It is to be understood that while the invention has been described above in conjunction with preferred specific embodiments, the description and examples are intended to illustrate and not limit the scope of the invention, which is defined by the scope of the appended claims.