TREA

Method, system, and program product for pre-compile processing of HDL source files

Follow

Information

  • Patent Application
  • 20080072187
  • Publication Number
    20080072187
  • Date Filed
    September 16, 2006
    18 years ago
  • Date Published
    March 20, 2008
    16 years ago
Information
Abstract
Pre-compilation processing including pre-compilation operations on HDL source code files, including creating a “make it” file, on demand processing of the HDL source code in an HDL source browser, and resolving overloaded function and operator calls in an HDL source code browser debugger
Description

BRIEF DESCRIPTION OF THE DRAWINGS

The subject matter which is regarded as the invention is particularly pointed out and distinctly claimed in the claims at the conclusion of the specification. The foregoing and other objects, features, and advantages of the invention are apparent from the following detailed description taken in conjunction with the accompanying drawings in which:



FIG. 1 illustrates a high level flow chart for the method, system, and program product of the invention.



FIG. 2 illustrates a simplified diagram of the components of a design system including a user terminal and a server.





DETAILED DESCRIPTION OF THE INVENTION

The pre-compilation steps in creating a compiled HDL file include one of more of creating a make file, selective examination of HDL source code through on demand processing with a source browser and analysis of operator calls for over loaded operators in a source browser and debugger. For purposes of illustration we consider a make file, where the process starts with a “to do” file.


A to-do file contains all HDL source files that are needed for a design without any particular order, and a target “makefile” that is initially empty. A shell script can run this process as follows: it submits one file name from the to-do file to the HDL analyzer and waits for it to finish. If the run is successful, the file name is appended to the target Makefile and removed from the to-do list. If the run is unsuccessful, this implies that the file contains lower design parts that have not been analyzed yet; hence, it will remain in the to-do file. When the running script reaches the end of the to-do file, it re-visits it and checks for any left-over file names. This repeats until the to-do file is empty.


This is shown in FIG. 1. FIG. 1 illustrates a high level flow chart of the method of the invention. The method starts by constructing a list of all HDL (hardware design language) files, a “to do” list 101. The next step is getting the first file in the “to do” list 103 and compiling the file 105. If compilation is successful 107 the file is added to the end of the target file and removed from the “to do” list.


The “to do” list is tested for remaining files 109. The next remaining file in the “to do” list is sent for compilation 105. The processed files are checked for failures to compile 111, and if there any failures to compile the next file is called from the “to do” list for compilation 103.


If there are no remaining files that failed to compile, and there are no more files in the “to do” list, the target file contains files in lower to upper correct dependency order 113.


On demand processing and hierarchal navigation of the source code in an HDL source browser is a step in pre-compilation processing. Consider the following VHDL code where an entity e1 is instantiated from an entity gen1.














library ieee;


use ieee.std_logic_1164.all;


entity gen1 is


 generic(g1: integer := 2);


 port (i1, i2: in std_logic;


  o: out std_logic);


end;


architecture gen1 of gen1 is


 signal x,y,z: std_logic;


begin


  x <= i1;


  y <= i2;


 l1: entity work.e1 port map(in1 => x, in2=> y, out1 => z);  o <= z;


end;









The instantiated e1 entity is located in a VHDL file that is either accessible to the user or not. The e1 declaration is as shown:

















library ieee;



use ieee.std_logic_1164.all;



entity e1 is



 port (in1,in2: in std_ulogic;



  out1: out std_ulogic);



end;



architecture e1 of e1 is



begin



 o1 <= i1 or i2;



end;










According to one embodiment of the invention, it is not necessary to process the instantiation of e1 when it is encountered, but to store information that e1 is instantiated along with the context of the instantiation (at which place, inside an architecture or a block, etc). Also in the port map, in1, in2 and out1 are ports that are supposed to be declared in the entity e1, but since at this point we are not processing the instantiation, we need to store these ports and resolve them later when processing the instantiation.


There are two semantic navigation functions that a user can do with an instantiation:


1. Point to the labe1 of the instantiation (l1 in this case) and ask to jump to its entity or architecture.


2. Point to a formal port (in1, in2 or out1 in this case) and ask to jump to its declaration in the instantiated entity.


In either case, the compiler needs to locate the entity e1 and display it in the source window browser. The compiler will retrieve the stored information for the e1 instantiation and try to locate and compile the entity e1s. If successful, the HDL file containing the entity e1 will be displayed. If not, an error message will be issued and the user will be able to continue either by moving on to other commands or fixing the problem on-the-fly. For example if the user forgot to set the env variable for locating the HDL source to point where the entity e1 is located, he can either


1. Open a dialogue window in the source browser and append the path where the file containing e1 is located to the appropriate env variable.


2. Go back and perform the previously failed operation.


One of the side effects of the on-demand processing is in displaying the sources and sinks of signals. In the example above, if the user, before processing the instantiation, asked to display the sources and sinks of the signal x, it is obvious that the reference of x in “x<=i1;” is a source. On the other hand, the reference of x in the instantiation statement (in1=>x) is not known before processing the instantiation. It is unknown at this point if in1 is an input, output or inout. A new category “connected to unresolved port” is added for this purpose. Whenever an instantiation is processed the sink-source list of the signals connected to the ports of the instantiated entity is updated.


A further aspect of pre-compilation processing includes analysis of overloaded operators. This is done by resolving overloaded function and operator calls in an HDL source code browser debugger. This is illustrated by the following VHDL code:

















-- file p1.vhdl



library ieee;



use ieee.std_logic_1164.all;



package p1 is



 function f1(a: bit) return std_ulogic;



 function “+”(a:std_ulogic; b: bit) return std_ulogic;



end;



package body p1 is



 function f1(a: bit) return std_ulogic is



begin  .................  ................ end;



function “+”(a: std_ulogic; b: bit) return std_ulogic is



  begin



.................  ................ end;



end;



-- file p2.vhdl



package p2 is



 function f1(a: std_ulogic) return bit;



 function “+”(a:bit; b: bit) return std_ulogic;



end;



package body p2 is



 function f1(a: std_ulogic) return bit is



begin  .................  ................ end;



function “+”(a: bit; b: bit) return sd_ulogic is



  begin



.................  ................ end;



end;



-- file gen1.vhdl



library ieee;



use ieee.std_logic_1164.all;



use work.p1.all;



use work.p2.all;



entity gen1 is port (i1, i2: in bit;



   i3  : in



std_ulogic;



   o   : out std_ulogic);



end;



architecture gen1 of gen1 is



 signal x,y,z: std_logic;



begin



 o <= f1(f1(i1) + i2) + f1(i3);



end;










If the user has only the list of functions and operators that are visible at the assignment to the output o, he has to switch between the three files (p1.vhd1, p2.vhd1 and gen1.vhd1) and manually match the function and operator calls to their corresponding declarations, and if he did not make a mistake he will reach the conclusion that the first f1 and second f1 calls (parsing left to right) correspond to the function in the package p2 and the third corresponds to the function in the package p1. On the other hand, the first “+” corresponds to the declaration in the package p1 and the second in the package p2.


The method of this invention:


1. Tokenizes the HDL expressions. All f1's and +'s in the example above will become different tokens.


2. Associates actions with the function and operator calls that include at least two actions:

    • 1. Jumping to the function declaration
    • 2. Jumping to the function body


All the user needs to do to figure out the corresponding function declaration or body of a function call or an operator is to point to it and select the required action, which will result in jumping to the place where the declaration or body is located, even if it is in different file. For example picking the first f1 call in the example above and selecting the action “Go To Body”, will result in the browser opening the file p2.vhd1 and pointing to the line:


function f1(a: std_ulogic) return bit is


As can be seen, this can save the user time especially for nested expressions and alleviate the possibility of making errors; thus making debugging much easier.



FIG. 2 illustrates one example of a system for practicing the method of the invention using the program product of the invention. The system 201 includes a user terminal 211, e.g., a work station, and an associated server 221, which may be connected directly or over a network. The associated server includes tools and applications such as (by way of exemplification and not limitation) a Hardware Design Language Tool, a Circuit Simulation Tool, a Computer Integrated Mfg Tool, and a Mask Works CAD-CAM Tool. Not shown are an operating system and system utilities, and links to associated equipment and fabrication tools may be included,


The invention may be implemented, for example, by having the system for pre-compilation processing including pre-compilation operations on HDL source code files, including creating a “make it” file, on demand processing of the HDL source code in an HDL source browser, and resolving overloaded function and operator calls in an HDL source code browser debugger executing the method as a software application, in a dedicated processor or set of processors, or in a dedicated processor or dedicated processors with dedicated code. The code executes a sequence of machine-readable instructions, which can also be referred to as code. These instructions may reside in various types of signal-bearing media. In this respect, one aspect of the present invention concerns a program product, comprising a signal-bearing medium or signal-bearing media tangibly embodying a program of machine-readable instructions executable by a digital processing apparatus to perform a method for by having the system for pre-compilation processing including pre-compilation operations on HDL source code files, including creating a “make it” file, on demand processing of the HDL source code in an HDL source browser, and resolving overloaded function and operator calls in an HDL source code browser debugger a software application.


This signal-bearing medium may comprise, for example, memory in a server. The memory in the server may be non-volatile storage, a data disc, or even memory on a vendor server for downloading to a processor for installation. Alternatively, the instructions may be embodied in a signal-bearing medium such as the optical data storage disc. Alternatively, the instructions may be stored on any of a variety of machine-readable data storage mediums or media, which may include, for example, a “hard drive”, a RAID array, a RAMAC, a magnetic data storage diskette (such as a floppy disk), magnetic tape, digital optical tape, RAM, ROM, EPROM, EEPROM, flash memory, magneto-optical storage, paper punch cards, or any other suitable signal-bearing media including transmission media such as digital and/or analog communications links, which may be electrical, optical, and/or wireless. As an example, the machine-readable instructions may comprise software object code, compiled from a language such as “C++”, Java, Pascal, ADA, assembler, and the like.


Additionally, the program code may, for example, be compressed, encrypted, or both, and may include executable code, script code and wizards for installation, as in Zip code and cab code. As used herein the term machine-readable instructions or code residing in or on signal-bearing media include all of the above means of delivery.


While the foregoing disclosure shows a number of illustrative embodiments of the invention, it will be apparent to those skilled in the art that various changes and modifications can be made herein without departing from the scope of the invention as defined by the appended claims. Furthermore, although elements of the invention may be described or claimed in the singular, the plural is contemplated unless limitation to the singular is explicitly stated.

Claims
  • 1. A method of pre-compilation processing an HDL source code file including at least one of creating a “make it” file, on demand processing of the HDL source code in an HDL source browser debugger, and resolving overloaded function and operator calls in an HDL source code browser debugger comprising: a) running an HDL source code file, wherein if the run is unsuccessful due to a missing module name, the file is manually processed, otherwise, a small file is saved on disk by the name of the defined module so that the analyzer recognizes it if needed later; andb) after all files are attempted, those that failed are run again until all runs are successful.
  • 2. The method of claim 1 further comprising: a) compiling a selected file wherein for every module that is instantiated, not resolving binding of the instantiation to other HDL modules, and storing instantiation information;subsequently processing the stored instantiation information and resolving the instantiation.
  • 3. The method of claim 2 wherein the stored instantiation information includes port connections and instantiation context.
  • 4. The method of claim 2 comprising compiling only those modules that are navigated by a user, and the user will be able to view the files that the user is interested in irrespective of whether the user has access to the rest of the files in the design hierarchy.
  • 5. The method of claim 1 comprising: a) selecting an operator or function call including function declaration or function body corresponding to the operator or function call; andb) thereby jumping directly to the function declaration or body.
  • 6. The method of claim 5 wherein the function is chosen from the group consisting of architectures, entities, module, and packages.
  • 7. A program product comprising a computer readable media having computer readable code thereon, said code carrying out a method of pre-compilation processing an HDL source code file including at least one of creating a “make it” file, on demand processing of the HDL source code in an HDL source browser debugger, and resolving overloaded function and operator calls in an HDL source code browser debugger comprising: a) running an HDL source code file, wherein if the run is unsuccessful due to a missing module name, the file is manually processed, otherwise, a small file is saved on disk by the name of the defined module so that the analyzer recognizes it if needed later; andb) after all files are attempted, those that failed will be run again until all runs are successful.
  • 8. The program product of claim 7 further comprising: a) compiling a selected file wherein for every module that is instantiated, not resolving binding of the instantiation to other HDL modules, and storing instantiation information;b) subsequently processing the stored instantiation information and resolving the instantiation.
  • 9. The program product of claim 8 wherein the stored instantiation information includes port connections and instantiation context.
  • 10. The program product of claim 8 comprising compiling only those modules that are navigated by a user, and the user will be able to view the files that the user is interested in irrespective of whether the user has access to the rest of the files in the design hierarchy.
  • 11. The program product of claim 7 comprising: a) selecting an operator or function call including function declaration or function body corresponding to the operator or function call; andb) thereby jumping directly to the function declaration or body.
  • 12. The program product of claim 11 wherein the function is chosen from the group consisting of architectures, entities, module, and packages.
  • 13. A method of providing a debugging service for an HDL source code file in an HDL source code browser debugger comprising performing at least one of creating a “make it” file, on demand processing of the HDL source code in an HDL source browser debugger, and resolving overloaded function and operator calls and further comprising: a) running an HDL source code file, wherein if the run is unsuccessful due to a missing module name, the file is manually processed, otherwise, a small file is saved on disk by the name of the defined module so that the analyzer recognizes it if needed later; andb) after all files are attempted, those that failed are run again until all runs are successful.
  • 14. The method of claim 13 further comprising: a) compiling a selected file wherein for every module that is instantiated, not resolving binding of the instantiation to other HDL modules, and storing instantiation information; subsequently processing the stored instantiation information and resolving the instantiation.
  • 15. The method of claim 14 wherein the stored instantiation information includes port connections and instantiation context.
  • 16. The method of claim 14 comprising compiling only those modules that are navigated by a user, and the user will be able to view the files that the user is interested in irrespective of whether the user has access to the rest of the files in the design hierarchy.
  • 17. The method of claim 13 comprising: a) selecting an operator or function call including function declaration or function body corresponding to the operator or function call; andb) thereby jumping directly to the function declaration or body.
  • 18. The method of claim 17 wherein the function is chosen from the group consisting of architectures, entities, module, and packages.
  • 19. A program product comprising a computer readable media having computer readable code thereon, said code comprising compressed code and including executable code for effecting installation thereof on a target computer, after installation said code carrying out a method of pre-compilation processing an HDL source code file including at least one of creating a “make it” file, on demand processing of the HDL source code in an HDL source browser debugger, and resolving overloaded function and operator calls in an HDL source code browser debugger comprising: a) running an HDL source code file, wherein if the run is unsuccessful due to a missing module name, the file is manually processed, otherwise, a small file is saved on disk by the name of the defined module so that the analyzer recognizes it if needed later; andb) after all files are attempted, those that failed will be run again until all runs are successful.
  • 20. The program product of claim 19 further comprising code for decompressing the code and effecting installation thereof on a target computer, and after installation for instructing the target computer to: a) compile a selected file wherein for every module that is instantiated, not resolving binding of the instantiation to other HDL modules, and storing instantiation information;b) subsequently process the stored instantiation information and resolving the instantiation.