Many aspects of the invention can be better understood with reference to the following drawings. The entities in the drawings are not necessarily to scale, emphasis instead being placed upon clearly illustrating the principles of the present invention.
The method of transferring software assertions into HDL code disclosed herein: examines software code in conjunction with HDL code that was translated from the software code; translates software assertions in the examined software code into HDL assertions; and inserts the HDL assertions into the translated HDL code.
Importantly, the translated hardware code 130 does not contain HDL assertions translated from the software language. However, it may contain other assertions, produced by the translation tool 120, or added manually after the translation process.
The two input files are processed by the assertion transfer tool 140, a computer program that implements the method of transferring software assertions into HDL code. The assertion transfer tool 140 produces hardware code 150 that contains the original HDL code as well as assertions translated from the software language. The method reads software language assertions in the software code 110, translates the software assertions into HDL assertions, and places the HDL assertions in the appropriate location within the translated hardware code 130. The hardware code containing assertions 150 can then be used as input by an HDL simulator 160.
One skilled in the art of software development will realize that the assertion transfer tool 140 can be implemented in a variety of languages, both scripted and compiled. A non-limiting list of scripting languages includes per1, awk, shell script, and VBScript. A non-limiting list of compiled languages includes C, C++, C#, Java, and Visual Basic.
Although contained in more than one file, the software code 110 when considered as a whole forms a hierarchy of software entities. Similarly, hardware code 130 is contained in more than one file, but when considered a whole forms a hierarchy of hardware entities. In Verilog these entities are modules. In C, these entities are functions. In C++, these entities are classes, and classes contain functions.
An entity at a particular level can create, or instantiate, other entities at the next lower level. In the example in
Importantly, the name of hardware module 220H (“H_MUX”) can be derived from the name of software class 220S (“S_MUX”), because the process which translated the C/C++ software code 110 into the Verilog hardware code 130 (either automated or manually) follows a predetermined naming scheme. When transferring software assertions into HDL code, the method disclosed herein examines the files that make up the software code 110 to discover the software code hierarchy, and examines the files that make up the hardware code 130 to discover the hardware code hierarchy. The predetermined naming scheme then allows the method to discover the correspondence between the two hierarchies.
In the embodiment of
Each function block 310 or module block 320 contains one or more sequence blocks 330. A hardware module can contain another kind of block, a process block 340, which has no counterpart in a software class.
Within a sequence block 330, statements are executed sequentially. A control block 350 is used to transfer control out of the sequence. Although syntax varies among languages, most software and hardware programming languages include conditional control blocks (e.g. IF) and repetitive control block (e.g., FOR, WHILE). In
As mentioned earlier, the method of transferring software assertions into HDL code translates software assertions into HDL assertions, and places the HDL assertions in the appropriate location within the hardware code 130. The method uses the blocks described in connection with
For example, if a software assertion was identified as being located between block X and block Y in the software code 110, then the location for the HDL assertion might be between corresponding blocks X′ and Y′ in the hardware code 130. One of ordinary skill in the art of HDL code translation should recognize that the structure of translated HDL code can be much different than the software code from which it is translated. Therefore, the appropriate location for the HDL assertion in this example might be after blocks X′ and Y′, or possibly even within block X′ or Y′, depending on the structure of hardware code 130 and software code 110.
The software function 410S also contains one assertion: “ASSERT(!(read & m_empty))” (450). This assertion is located before the first control block 420S. As can be seen in
The example in
In the example of
The method disclosed herein translates the software assertion 610 into the Verilog assertion 650. This example uses a variation of Verilog called System Verilog with Assertions (SVA), which includes language constructs for assertions. One of these constructs is a property. An important distinction between software code and hardware code is that hardware code is clocked. Software can simply test the value of a variable to determine if a boolean expression is true. But in hardware, the variable is a signal, and must be tested with reference to a clock.
Therefore, the method disclosed herein implements a Verilog assertion in two portions: a property definition 660, which allows clocking references; and an ASSERT statement 670. The property definition 660 defines a Verilog named property, which in this case has the generic name “fifol.” The property definition 660 includes an ALWAYS block which contains a clocking reference, and within the ALWAYS block, the boolean expression 680 which is expected to hold true.
The ASSERT statement 670 follows the property definition 660. The condition that is expected to hold true is the named property, defined above, where the property definition in turn contains the boolean expression 680. If the named property does not hold true, the ASSERT statement 670 includes the Verilog $FATAL statement (690) and the output string 695. The $FATAL statement 690 displays the output string 695 and terminates the simulation with an error code.
Use of the $FATAL statement here corresponds to the severity level of CRITICAL in the software assertion 610. A severity level of NORMAL in a software assertion would instead map to the Verilog $ERROR or $WARNING statement, which will display the output string 695 but will not terminate the simulation.
Another type of software assertion, used with a SWITCH or CASE control statement, does not explicitly include a boolean expression. Instead, the location of the assertion within the control statement implies a boolean expression. An example of this can be seen in the code below:
Here, the assertion under the DEFAULT label will be executed only if access_type is not equal to Read or Write. This is equivalent to a boolean condition:
((access_type !=Read) && access_type !=Write))
However, this boolean condition is implied by the location of the assertion within the SWITCH/CASE control block, and thus it is unnecessary to included the expression as a parameter to the ASSERT macro. This specialized type of software assertion can be efficiently mapped to the $INSET operator supported by the System Verilog property statement. The equivalent System Verilog assertion is therefore:
First locate logic 720 determines the location of the software assertion (450) relative to one or more blocks (420S, 430S) within the software module (410S). In one embodiment, the location in the software file (110) is captured by first locate logic 720 in terms of the code within the blocks. Since this code indicates a software location, the location can be viewed as comprising software indicating codes (725). First locate logic 720 maintains, or sets, a software block (727) which includes the software assertion (450) and the software indicating codes (725).
Second locate logic 730 searches the hardware source file (150) to find a hardware block (420H) which corresponds to the software block (420S). In one embodiment, the location of the corresponding hardware block (420H) is captured in terms of code within the block, i.e., in terms of hardware indicating codes (735). Thus, the software indicating codes (725) correspond to the hardware indicating codes (735). Second locate logic 730 maintains, or sets, a hardware block (737) which includes the hardware indicating codes (735).
Translate logic 740 translates the software assertion (450) into an hardware assertion (510). Third locate logic 750 uses the hardware indicating codes (735), which describe a location within hardware module (420H), to determine a location within the HDL file (130) for insertion of the translated assertion (510). The determined location is relative to the hardware indicating codes (735).
Insertion logic 760 inserts the translated hardware assertion (510) at the determined location within the HDL source file (130). The end result is a hardware source file (150) containing translated assertions which correspond to the assertions in the software source file (130).
This location can be within the module (a technique called “inline assertions”) or external. In the inline case, the insertion location is relative to blocks within the module, and is based on the location of software assertion within the software module/function. However, allowances are made for differences between the software function and its translated form in the hardware module, as would be understood by one of ordinary skill in the art of program translation.
Any process descriptions or blocks in flowcharts should be understood as representing modules, segments, or portions of code which include one or more executable instructions for implementing specific logical functions or steps in the process. As would be understood by those of ordinary skill in the art of the software development, alternate implementations are also included within the scope of the disclosure. In these alternate implementations, functions may be executed out of order from that shown or discussed, including substantially concurrently or in reverse order, depending on the functionality involved.
The systems and methods for transferring software assertions into HDL code can be implemented in software, hardware, or a combination thereof. In some embodiments, the system and/or method is implemented in software that is stored in a memory and that is executed by a suitable microprocessor (UP) situated in a computing device. However, the systems and methods can be embodied in any computer-readable medium for use by or in connection with an instruction execution system, apparatus, or device. Such instruction execution systems include any computer-based system, processor-containing system, or other system that can fetch and execute the instructions from the instruction execution system. In the context of this disclosure, a “computer-readable medium” can be any means that can contain, store, communicate, propagate, or transport the program for use by, or in connection with, the instruction execution system. The computer readable medium can be, for example but not limited to, a system or propagation medium that is based on electronic, magnetic, optical, electromagnetic, infrared, or semiconductor technology.
Specific examples of a computer-readable medium using electronic technology would include (but are not limited to) the following: an electrical connection (electronic) having one or more wires; a random access memory (RAM); a read-only memory (ROM); an erasable programmable read-only memory (EPROM or Flash memory). A specific example using magnetic technology includes (but is not limited to) a portable computer diskette. Specific examples using optical technology includes (but are not limited to): an optical fiber; and a portable compact disk read-only memory (CD-ROM).
Note that the computer-readable medium could even be paper or another suitable medium on which the program is printed. Using such a medium, the program can be electronically captured (using, for instance, optical scanning of the paper or other medium), compiled, interpreted or otherwise processed in a suitable manner, and then stored in a computer memory. In addition, the scope of the certain embodiments of the present invention includes embodying the functionality of the preferred embodiments of the present invention in logic embodied in hardware or software-configured mediums.
This description has been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the disclosure to the precise forms disclosed. Obvious modifications or variations are possible in light of the above teachings. The embodiments discussed, however, were chosen to illustrate the principles of the disclosure, and its practical application. The disclosure is thus intended to enable one of ordinary skill in the art to use the disclosure, 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 this disclosure, as determined by the appended claims when interpreted in accordance with the breadth to which they are fairly and legally entitled.