The present invention relates to software tools for designing digital integrated circuits, and more specifically, to a system or method for generating hardware design language assertions from waveform diagrams.
Designers of digital integrated circuits (ICs) use various software tools to design an IC. The design engineer writes code in a Hardware Design Language (HDL), also known as a Register Transfer Language (RTL). The IC designer then runs a simulator which tests the design using the HDL code as input. After fixing any problems found in the code by the simulation process, the HDL code is then used as input by a synthesizer. The synthesizer translates the HDL code into a physical representation of an IC, which can then be produced as a physical IC in the form of an Field Programmable Gate Array (FPGA), Application-Specific Integrated Circuit (ASIC), or custom silicon IC.
During the simulation process, a verification engineer instruments the HDL code with assertions to verify that the HDL code is an accurate implementation of the intended design. An assertion is a statement that expresses how a particular design feature should or should not behave. For example, the code for a particular logic block may assume that only one of two input signals is active at any one time. As another example, a logic block may assume that an input will never be larger than a certain maximum value. As yet another example, a logic block may assume that a request signal will remain asserted until after an acknowledge signal is asserted. Each of these assumptions made by the designer can be expressed as assertion.
Assertions may be written in a variety of languages. Some HDL languages provide native support for assertions, for example, VHDL and SystemVerilog. Languages have also been developed specifically to express assertions, for example, Vera, Jeda, e, and Property Specification Language (PSL).
Using existing tools and methods, a verification or design engineer must infer timing relationships from waveform diagrams, and write assertions such to express the relationships. This is a time-consuming and error-prone process because it is a manual, rather than an automated, process. In addition, a verification or design engineer may be required to learn several different assertion languages (e.g., SystemVerilog, Vera, e, PSL, etc.), because different development tools support different languages. Therefore, a better method for generating assertions is needed.
Systems and methods for generating a Hardware Design Language (HDL) assertion from a waveform diagram are disclosed. One method comprises: identifying a timing relationship between first and second signals in the diagram; and generating an HDL assertion corresponding to the relationship. The relationship comprises a portion of the first signal, a portion of the second signal, and an interval between the portions. Another method comprises: identifying a combinatorial relationship between two input signals and an output signal in the diagram; and generating an HDL assertion corresponding to the relationship. One system comprises logic for performing the steps of: receiving a plurality of signal descriptions, each describing one of a plurality of signals; receiving a description of a timing or combinatorial relationship between at least two of the plurality of signals; generating a waveform diagram including a representation of the relationship; and generating an HDL assertion corresponding to the relationship.
Many aspects of the invention can be better understood with reference to the following drawings. The components in the drawings are not necessarily to scale, emphasis instead being placed upon clearly illustrating the principles of the present invention.
One skilled in the art will realize that several timing relationships between signal req 102 and signal gnt 103 are implied by the diagram. In natural language, one of the relationships is expressed as “req goes high and gnt goes high one clock period later.” In a timing relationship, the action of one signal (the “follower”) is dependent on the action of another signal (the “antecedent”). Here, req is the antecedent and gnt is the follower.
The presence of this first timing relationship is explicitly indicated in the diagram with timing relationship indicator 107. In one embodiment, the timing relationship indicator 107 is generated by the method based on user input. In another embodiment, the method operates on timing relationship indicators that are generated by some other means or program.
Timing relationship indicator 107 defines the relationship as follows. One edge of indicator 107 is aligned with the portion (104) of the antecedent signal that transitions from low to high, while the other edge is aligned with the portion (105) of the follower signal that transitions from low to high. The indicator 107 spans the two signal portions, or segments, that describe the timing relationship. The indicator 107 also includes an indication of the number of clock periods that are allowed to occur between the two signal transitions. In some embodiments, the number of cycles may be a range, for example, 1-4.
A second timing relationship between signal req 102 and signal gnt 103 (“req goes low one clock period after gnt goes high”) is also implied by the diagram and explicitly indicated with another timing relationship indicator (108). In this second relationship, gnt is the antecedent and req is the follower. One edge of indicator 108 is aligned with the portion (105) of the antecedent that transitions from low to high, and the other edge is aligned with the portion 106 of the follower that transitions from high to low. The timing relationship indicator 107 in
The timing relationship expressed by the indicators are mapped by the method to assertions: the relationship defined by indicator 107 is mapped to assertion 109; and the relationship defined by indicator 108 is mapped to assertion 110. Each assertion expresses the timing relationship as a condition that must hold true. The assertions generated by the method can then be used by the engineer during simulation or formal verification, where a violation of an assertion is typically recorded and flagged as an error. One skilled in the art will understand the use of assertions to express timing relationships without further explanation. One skilled in the art will also understand that the method can support many different assertion languages. Furthermore, one embodiment may simultaneously support multiple languages, with the user selecting which language is currently in use.
In one embodiment, multiple timing relationships are combined into a single assertion when the timing relationships are sequential in time. The relationship between transitions 104 and 105 and the relationship between transitions 105 and 106 are sequential: they share a common clock transition 105. The combination of these two sequential timing relationships can be expressed by the single assertion 111. In some embodiments, the user can override this behavior of combining sequential relationships into a single assertion, and the override can occur on a per-relationship basis.
Indicator 107 defines a timing relationship between a transition on the antecedent and a transition on the follower. Therefore, assertion 109 also expresses a timing relationship using two signal transitions. In this example, the method generates assertions in the SystemVerilog language. Therefore, the SystemVerilog keyword rose is used in assertion 109 to express the timing relationship using signal transitions: rose (req) # # rose (gnt). When using other assertion languages, the method uses signal transition keywords appropriate to the chosen language.
Another embodiment of the method for generating assertions using waveforms, shown in
The diagram of
The method generates assertions corresponding to the identified timing relationships: the relationship corresponding to transitions 404 and 405 is mapped to assertion 407; and the relationship corresponding to transitions 405 and 406 is mapped to assertion 408. Each assertion expresses the timing relationship as a condition that must hold true.
The user defines signals and relationships using a group of buttons 501, using the sequences of user interactions shown in
The second signal, gnt, is defined in a similar manner. The example signal gnt goes high in the second clock period and stays high. To draw the waveform for this gnt signal, the SIGNAL button 601 is activated, and the signal name (gnt) is entered in the signal description dialog 602. When the signal description dialog 602 is dismissed, the program generates a signal label 612. The user then activates the LOW button 605 and clicks at point 613, which results in initial waveform segment 614 that is low from the start to point 613. The second segment 615 is generated by activating the HIGH button 604 then clicking at point 616.
To define this relationship, the RELATION button 701 is activated. The program creates a timing relationship indicator 702 consisting of a bracket with two edges and a number within the bracket. The user first positions timing relationship indicator 702 along the base of the gnt signal waveform. The user then drags the left edge of timing relationship indicator 702 to align with point 606, where req transitions from low to high, and drags the right edge of timing relationship indicator 702 to align with point 613, where gnt transitions from low to high. The number inside the bracket of timing relationship indicator 702 represents the number of clock periods allowed for the transition, which in this example is 1.
The third relationship to be defined is “the value of gnt after the transition of req to low is a don't care.” This third relationship is defined by activating the DON'T CARE button 802, which produces a block 803. The user positions block 803 along the gnt signal waveform, then drags the left and right edges of block 803 to define the time span for which the value is a don't care. In
After one or more timing relationships are created using the procedure illustrated in
Now that the process of capturing a timing relationship between two or more signals has been described in detail, one skilled in the art will understand how to map between the captured timing relationships and assertions in a particular language. Therefore, only a few example mappings will be given here. One skilled in the art will realize also that a single timing relationship can sometimes be expressed in a given language by more than one assertion, so the mapping between timing relationship and assertion is not necessarily one-to-one.
The three timing relationships illustrated in
timing relationship indicator 702==>(req ## req && gnt)
timing relationship indicator 801==>(req && gnt ## !req)
The three timing relationships illustrated in
timing relationship indicator 702==>(req; req & & gnt)
timing relationship indicator 801==>(req && gnt ; req)
To define a logical relationship, a logical operator is selected using one of the logical operator pushbuttons 1201. In this example, the AND operator is chosen and the method generates an AND relationship symbol 1202. A node for signal_a (1203) is created by selecting signal_a from the SIGNAL list control 1204. Similarly, a node for signal_b (1205) is created by selecting signal_b from the SIGNAL list control 1204. The nodes are connected (e.g., by a dragging motion) to the two inputs of the AND relationship symbol 1202. An “AND” relationship between signal_a and signal_b is thus defined.
A second combinatorial relationship is defined in
After one or more combinatorial relationships are created using the procedure illustrated in
One embodiment of the method for generating assertions using waveforms identifies combinatorial relationships that aren't explicitly defined by a relationship symbol. The inputs and outputs of a waveform can be analyzed using existing techniques, such as truth tables and Karnaugh maps, to derive combinatorial relationships between signals. This embodiment generates assertions for combinatorial relationships that are identified in this manner, as well as for relationships that are explicitly defined by a symbol.
Then input signals rd 1505 and wr 1506 are defined and a combinatorial relationship is defined using those two signals as input. In this embodiment, a process like the one described in connection with
Next, timing relationship indicator 1510 is added, using the process described in connection with
ASSERT(rose(req) & rose(rd|wr) ## rose(gnt)).
Many variations on the user interfaces illustrated in
The processor 1702 is a hardware device for executing software, particularly that stored in memory 1703. The processor 1702 can be any custom made or commercially available processor, a central processing unit (CPU), an auxiliary processor among several processors associated with the computer 1701, a semiconductor based microprocessor (in the form of a microchip or chip set), a microprocessor, or generally any device for executing software instructions.
The memory 1703 can include any one or combination of volatile memory elements (e.g., random access memory (RAM, such as DRAM, SRAM, SDRAM, etc.)) and nonvolatile memory elements (e.g., ROM, hard drive, tape, CDROM, etc.). Moreover, the memory 1703 may incorporate electronic, magnetic, optical, or other types of storage media. Note that the memory 1703 can have a distributed architecture, where various components are situated remote from one another, but can be accessed by the processor 1702.
The software in memory 1703 may include one or more separate programs, each of which comprises an ordered listing of executable instructions for implementing logical functions. In this example embodiment, software in memory 1703 includes one or more components of the system for generating assertions using waveforms 1706, and a suitable operating system 1707. The operating system 1707 essentially controls the execution of other computer programs, such as the method for merging assertions with an HDL source file, and provides scheduling, input-output control, file and data management, memory management, and communication control and related services.
The method is a source program, executable program (object code), script, or any other entity comprising a set of instructions to be performed. When a source program, then the program needs to be translated via a compiler, assembler, interpreter, or the like, which may or may not be included within memory 1703, so as to operate properly in connection with the operating system 1707.
The peripherals 1704 may include input devices, for example but not limited to, a keyboard, mouse, scanner, microphone, etc. Furthermore, the peripherals 1704 may also include output devices, for example but not limited to, a printer, display, facsimile device, etc. Finally, the peripherals 1704 may further include devices that communicate both inputs and outputs, for instance but not limited to, a modulator/demodulator (modem; for accessing another device, system, or network), a radio frequency (RF) or other transceiver, a telephone interface, a bridge, a router, etc.
If the computer 1701 is a PC, workstation, or the like, the software in the memory 1703 may further include a basic input output system (BIOS). The BIOS is a set of essential software routines that initialize and test hardware at startup, start the operating system 1707, and support the transfer of data among the hardware devices. The BIOS is stored in the ROM so that the BIOS can be executed when the computer 1701 is activated.
When the computer 1701 is in operation, the processor 1702 is configured to execute software stored within the memory 1703, to communicate data to and from the memory 1703, and to generally control operations of the computer 1701 in accordance with the software. The system for generating assertions using waveforms 1706 and the operating system 1707, in whole or in part, but typically the latter, are read by the processor 1702, and perhaps buffered within the processor 1702, and then executed.
It should be noted that the method can be stored on any method for use by or in connection with any computer related system or method. In the context of this document, a “computer-readable medium” can be any means that can store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, system, or device. The computer-readable medium can be, for example but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, system, device, or propagation medium. A non-exhaustive example set of the computer-readable medium would include the following: an electrical connection having one or more wires, a portable computer diskette, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM, EEPROM, or Flash memory), and a portable compact disc read-only memory (CDROM). Note that the computer-readable medium could even be paper or another suitable medium upon which the program is printed, as the program can be electronically captured, via for instance optical scanning of the paper or other medium, then compiled, interpreted or otherwise processed in a suitable manner if necessary, and then stored in a computer memory.
In an alternative embodiment, where the method is implemented in hardware, it can be implemented with any or a combination of the following technologies, which are each well known in the art: a discrete logic circuit(s) having logic gates for implementing logic functions upon data signals, an application specific integrated circuit(s) (ASIC) having appropriate combinatorial logic gates, a programmable gate array(s) (PGA), a field programmable gate array(s) (FPGA), etc.
The foregoing description has been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise forms disclosed. Obvious modifications or variations are possible in light of the above teachings. The embodiments discussed, however, were chosen and described to illustrate the principles of the invention and its practical application to thereby enable one of ordinary skill in the art to utilize the invention in various embodiments and with various modifications as are suited to the particular use contemplated. All such modifications and variation are within the scope of the invention as determined by the appended claims when interpreted in accordance with the breadth to which they are fairly and legally entitled.