Abstract:
A system and method for developing a circuit design for a programmable logic device. A tool is provided for interactively modifying a configuration bitstream, downloading the bitstream to a programmable logic device (PLD), and reading back and displaying state information from the PLD. In one embodiment, the tool is command driven. Responsive to a first command, the tool implements a selected logic core from a library of run-time parameterizable logic cores in a configuration bitstream. The bitstream can be automatically downloaded to the PLD as part of the first command, or alternatively, using a separate command. A second command is available for applying a clock signal to the PLD. After application of the clock signal, the states of selected elements implemented by the logic core are reported.

Description:
RELATED PATENT APPLICATION 
     The present application is related to the following patent applications: 
     U.S. patent application Ser. No. 09/168,300, entitled “CONFIGURATION OF PROGRAMMABLE LOGIC DEVICES WITH ROUTING CORES” by Guccione and Levi, which was filed on Oct. 7, 1998 and issued as U.S. Pat. No. 6,216,259 on Apr. 10, 2001; 
     U.S. patent application Ser. No. 09/501,356, entitled “RUN-TIME ROUTING FOR PROGRAMMABLE LOGIC DEVICES” by Keller, Guccione, and Levi, which was filed on Feb. 9, 2000; and 
     U.S. patent application Ser. No. 09/533,092, entitled, “METHOD AND APPARATUS FOR DEFINING AND MODIFYING CONNECTIONS BETWEEN LOGIC CORES IMPLEMENTED ON PROGRAMMABLE LOGIC DEVICES” by Keller and Patterson, which was filed concurrently with the present application. 
    
    
     GOVERNMENT CONTRACT 
     The U.S. Government has a paid-up license in this invention and the right in limited circumstances to require the patent owner to license others on reasonable terms as provided for by the terms of DABT63-99-3-0004 awarded by DARPA. 
    
    
     FIELD OF THE INVENTION 
     The present invention generally relates to configuring programmable logic devices and testing designs implemented thereon, and more particularly to interactively implementing and testing logic cores on a programmable logic device. 
     BACKGROUND 
     Logic cores are generally used as building blocks in creating electronic circuit designs. A logic core typically is a design that when implemented in hardware performs a predetermined function and that has input and output signal lines that can be connected to other logic. For example, one particular logic core may implement a digital filter, and another logic core may implement a constant multiplier. 
     The traditional tools for creating logic cores generally support design entry via schematics or a hardware description language such as HDL or VHDL. In addition, there are a multitude of proprietary languages for creating logic cores that are specifically suitable for a particular family of devices. Some environments, for example VHDL, support creation of test environments along with the designs themselves. 
     In the context of programmable logic devices, for example, field programmable gate arrays (FPGAs) from Xilinx, there are numerous tools available for testing the functionality of circuits created from logic cores. The tools include functional and physical simulators, BoardScope™ graphical debugger software, and XHWIF hardware interface software. 
     New developments in the area of creating designs for PLDs are rendering the known test methodologies and tools inadequate. For example, circuit designs, including run-time parameterizable logic cores, can be created in the JBits environment from Xilinx. The JBits environment is a Java-based tool that includes an application programming interface (API) that allows designers to develop logic and write a configuration bitstream directly to a Xilinx FPGA. The JBits API permits the FPGA bitstream to be modified quickly, allowing for fast reconfiguration of the FPGA. With Virtex™ FPGAs, the JBits API can be used to partially or fully reconfigure the internal logic of the hardware device. The JBits environment also supports run-time reconfiguration of FPGAs and also configuration of FPGAs over a communications network, for example, an intranet or the Internet. 
     The JBits environment can also be used to create a suitable test bench for a circuit design. The drawback, however, is that if during testing it becomes desirable to change the parameterization of a logic core to something other than that which was initially programmed in JBits, the JBits program that implements the logic core must be changed to accommodate the new parameter(s). Changing the JBits program requires both knowledge of the JBits environment and knowledge of how the logic core has been programmed with JBits. This added level of complexity and additional consumption of time may be undesirable from the viewpoint of one testing and debugging the circuit implementation on the FPGA. 
     A system and method that addresses the aforementioned problems, as well as other related problems, is therefore desirable. 
     SUMMARY OF THE INVENTION 
     A system and method for developing a circuit design for a programmable logic device are provided in various embodiments. In one embodiment, a tool is provided for interactively modifying a configuration bitstream, downloading the bitstream to a programmable logic device (PLD), and reading back and displaying state information from the PLD. The tool allows a designer to interactively generate a test configuration bitstream, advance the PLD clock, and observe the states of elements in the PLD. The test configuration bitstream can then be interactively modified using the tool and a test sequence repeated. 
     In one embodiment, the tool is command driven. Responsive to a first command, the tool implements a selected logic core from a library of run-time parameterizable logic cores in a configuration bitstream. The bitstream is downloaded to the PLD. In one embodiment, the bitstream is downloaded in response to the first command, and in another embodiment, the bitstream is downloaded responsive to another command. A second command is available for applying a clock signal to the PLD. After application of the clock signal, states of selected elements implemented by the logic core are reported. 
     It will be appreciated that various other embodiments are set forth in the Detailed Description and Claims that follow. 
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS 
     Various aspects and advantages of the invention will become apparent upon review of the following detailed description and upon reference to the drawings, in which: 
     FIG. 1 is a flow diagram that illustrates an example design and test flow; 
     FIG. 2 is a design and test flow diagram in which a user can interactively observe the behavior of the circuit implemented on a PLD and interactively change the configuration bitstream; 
     FIG. 3 is a flow chart that illustrates a method for implementing the ADD core command; 
     FIG. 4 is a flowchart of a method for implementing the REMOVE core command; 
     FIG. 5 is a flowchart of a method for advancing a clock signal supplied to a PLD under test in response to a STEP command; 
     FIG. 6 is a flowchart of a method for implementing the STATUS command; 
     FIG. 7 illustrates a display screen having an example input script of commands; and 
     FIG. 8 illustrates a display screen having PLD state data reported to a user in response to executing the example script of FIG.  7 . 
    
    
     DETAILED DESCRIPTION 
     Various embodiments of the present invention are described in terms of extensions to the JBits software, which is available from Xilinx. While the invention is not limited in scope to JBits, the various embodiments are presented in terms of specific examples involving the JBits programming environment. Those skilled in the art will appreciate that the invention could be implemented in other programming languages, applied to programmable logic devices (PLDs) other than FPGAS, and/or adapted to applications that are not run-time reconfigurable. 
     FIG. 1 is a flow diagram that illustrates an example design and test flow in an environment such as that supported by the JBits software. An initial bitstream  142  is provided as input to design application  144 . The initial bitstream is one created using conventional tools, for example, and the design application is a Java program that uses the JBits programming interface  146 . The initial bitstream may also be empty, with modified bitstream  150  created entirely by design application  144 . Design application  144  uses logic cores  148  in creating modified configuration bitstream  150 . Programming interface  146  and hardware interface  154  are then used to configure PLD  156  with bitstream  150 . 
     Once PLD  156  is configured with bitstream  150 , debugger  152 , such as BoardScope from Xilinx, can be used in conjunction with a hardware interface  154  to test the operation of the implemented circuit. It will be appreciated, however, that while BoardScope allows a user to observe the states of elements within PLD  156  (e.g., flip-flop states within configurable logic blocks (CLBs)), the user cannot manipulate the configuration bitstream via BoardScope. If during testing a change to bitstream  150  is desired that is beyond that for which application  144  is programmed, application  144  must be reprogrammed to effect the change. 
     Hardware interface  154  can be implemented with the XHWIF hardware interface from Xilinx, for example. XHWIF provides a Java interface for communicating with FPGA-based boards and includes methods for reading and writing bitstreams from and to FPGAs and methods for describing the kinds and number of FPGAs on a board. In addition, XHWIF includes methods for advancing the on-board clock and reading and writing board memories. 
     FIG. 2 is a design and test flow diagram in which a user can interactively observe the behavior of the circuit implemented on a PLD and interactively change the configuration bitstream. For example, based on the observed states of PLD  156 , it may be desirable to change the parameterization of selected cores and create a new configuration bitstream, download the new bitstream, and observe the states of PLD  156  with the new bitstream. 
     In one embodiment, implementation and testing tool  182  is an interactive program implemented in Java using the JBits application program interface. In response to user-entered commands, tool  182  begins with initial bitstream  142  and creates modified bitstream  186 . The initial bitstream may be null or implement logic necessary to test selected ones of cores  148 , depending on the functionality of the cores to be tested. A library of run-time parameterizable (RTP) cores  148  is used by tool  182  in creating the modified bitstream. 
     Implementation and testing tool  182  provides a command-driven interface in which commands can be entered via a computer keyboard by a user or by a script file containing a sequence of commands. Those skilled in the art will appreciate that the commands could also be generated in response to user interaction with a graphical or voice-driven user interface, or using other methods. 
     The available commands provide the capability to instantiate RTP cores in a bitstream, remove RTP cores from a bitstream, report the states of flip-flops of RTP cores when implemented on the PLD, advance the clock signal on the board having the PLD, save the current bitstream for later use (bitstream  184 ), and reset the PLD to a known initial state. Selected ones of the commands are described in conjunction with the following flowcharts. 
     FIG. 3 is a flow chart that illustrates a method for implementing the ADD command. The ADD command instantiates a specified core in the configuration bitstream  186  and downloads the modified bitstream to the PLD. 
     The Java Reflection API is used in the dynamic location of cores. Any Java class file that extends the core class is identified in a master list (not shown) of cores. The master list is generated when tool  182  is first started. Once the master list is generated, APIs of the different Java classes (RTP cores) are used to obtain information pertaining to the class constructors, which provide the numbers and types of the parameters for the various classes. 
     The ADD command has the following syntax: 
     ADD&lt;core name&gt; &lt;row&gt; &lt;column&gt; &lt;other parameters&gt; 
     In processing an ADD command, at step  222 , the parameter &lt;core name&gt; is located in the master list. (In the embodiment of FIG. 3, the input parameters are specified with the ADD command instruction. In other embodiments, the input parameters are queried from the user, read from a file, or otherwise obtained prior to step  222 .) The parameters &lt;row&gt; and &lt;column&gt; reference coordinates of configurable logic blocks (CLBs) in an FPGA at which the logic core is to be placed. At step  224 , the parameters are converted from the character representations to the appropriate data types. Note that error checking includes verifying that the row and column parameters are valid for the particular FPGA. 
     The core is instantiated at step  226 , with the parameters supplied on the command line being used as input parameters to the class constructor. In addition, the identification of the constructor and the associated parameters are saved in a core list (not shown). The core list is used to track which cores are instantiated at run-time with tool  182 . 
     At step  228 , the configuration bitstream is updated to implement the referenced core. In the JBits environment, a set method is programmed for each core to generate the proper configuration bits. Tool  182  invokes the set method for the specified core. 
     At step  230 , tool  182  uses hardware interface  154  via programming interface  146  to download the configuration bitstream to PLD  156 . The configuration bitstream is then read back from the PLD at step  232  by invoking the STATUS method. Briefly, the STATUS method implements the STATUS command, which is used to read back the configuration bitstream and extract state information of flip-flops of the RTP cores that have been implemented using the ADD command. After reporting the states of the flip-flops, the ADD method is complete. 
     It will be appreciated that in other embodiments, the download of the configuration bitstream to the PLD is not performed as a part of the ADD command. Rather, a separate command (for example, “CONFIGURE”) downloads the configuration bitstream to the PLD. In another embodiment, the ADD method is adapted to process multiple RTP cores as specified in a command. 
     In another embodiment, a logic core can be placed relative to another core with a PLACE command. The PLACE command can be implemented with the following parameters: &lt;new core&gt;, &lt;anchor core&gt;, &lt;direction&gt;, &lt;alignment&gt;, and other desired parameters. The &lt;new core&gt; is the core to be added at a location relative to the &lt;anchor core&gt;. The &lt;direction&gt; indicates the side on which the &lt;new core&gt; will be placed relative to the &lt;anchor core&gt;, with the direction being one of north, south, east, or west. The &lt;alignment&gt; indicates how the &lt;new core&gt; will be aligned relative to the &lt;anchor core&gt;. For example, if the &lt;direction&gt; is north, then the &lt;alignment&gt; can be left or right, where left means that the left column of CLBs of &lt;new core&gt; will be aligned with the left column of CLBs of &lt;anchor core&gt;. For a &lt;direction&gt; east or west, the &lt;alignment&gt; can be either top or bottom. 
     Once logic cores have been configured into the configuration bitstream via the ADD command, the cores can be interconnected using stitcher cores, which are described by Guccioni et al in co-pending U.S. patent application Ser. No. 09/168,300. Briefly, stitcher cores are logic cores that specify routing configuration bits. By using the ADD command referencing a stitcher core, the desired connections can be made. In another embodiment, the route methods of the application entitled, “RUN-TIME ROUTING FOR PROGRAMMABLE LOGIC DEVICES”, by Keller et al are used to accomplish the desired routing. Such route methods are invoked with a ROUTE command as implemented by tool  182 . In still another embodiment, a CONNECT command routes ports of one logic core to ports of another logic core. Usage of logical ports in combination with logic cores is described in the co-pending application entitled, “METHOD AND APPARATUS FOR DEFINING CONNECTIONS BETWEEN LOGIC CORES IMPLEMENTED ON PROGRAMMABLE LOGIC DEVICES”, by Keller et al. 
     FIG. 4 is a flowchart of a method for implementing the REMOVE command. The REMOVE command is used to remove a specified RTP core from a configuration bitstream. The syntax of the REMOVE command is as follows: 
     REMOVE &lt;core name&gt; &lt;row&gt; &lt;column&gt; 
     In the embodiment of FIG. 4, the input parameters are specified with the REMOVE command instruction. In other embodiments, the input parameters are queried from the user, read from a file, or otherwise obtained prior to step  262 . At step  262 , the core list (as described with the ADD command) is obtained, and at step  264 , the constructor of the core referenced by &lt;core name&gt; and having the specified &lt;row&gt; and &lt;column&gt; parameters is removed from the core list. 
     The initial bitstream is obtained at step  266 , in order to rebuild the configuration bitstream using the cores remaining on the core list. At step  268 , for each core remaining in the core list, the saved constructor is used to instantiate the core and the associated set method is called to set the appropriate bits in the configuration bitstream. The configuration bitstream is downloaded to the PLD at step  270 , and the STATUS method is invoked at step  272  to read back the configuration bitstream and obtain the states of the flip-flops of the RTP cores. 
     In another embodiment, a core can be removed by resetting the PLD resources used by that core, such as with an UNSET method. A “null” core is used to replace the core to be removed from the configuration bitstream. The null core has no state and is not visible to the STATUS command. In comparison to the REMOVE method, the UNSET method does not destroy the state of the other cores. 
     FIG. 5 is a flowchart of a method for advancing a clock signal supplied to a PLD under test. The method implements the STEP command, which has the following syntax: 
     STEP &lt;number of cycles&gt; 
     In the embodiment of FIG. 5, the number of cycles is specified with the STEP command instruction. In other embodiments, the number of cycles is queried from the user, read from a file, or otherwise obtained prior to step  300 . The number of cycles is then used, for example in a FOR loop, to repeat a sequence of steps ( 300 ,  302 ,  304 ) the specified number of times. 
     At step  300 , hardware interface  154  is called to oscillate the board clock signal one cycle. The STATUS method is invoked at step  302  to read back the configuration bitstream and display the states of flip-flops after having advanced the clock signal. Decision step  304  tests whether the clock should be stepped again as determined by the &lt;number of cycles&gt; parameter. If so, control is returned to step  300  to oscillate the clock again. Otherwise, the STEP method is complete. 
     FIG. 6 is a flowchart of a method for implementing the STATUS command. The STATUS command can be entered by a user to display the states of flip-flops of the implemented RTP cores, and the method is called by the ADD, REMOVE, and STEP methods. 
     Decision step  312  tests whether the current configuration bitstream has up-to-date state information. The test is accomplished by maintaining a flag that is updated when the STEP method is performed. If the STEP method was invoked since the last time the configuration bitstream was read back from the PLD, then the configuration bitstream is again read back from the PLD at step  314 . At step  316 , the states of flip-flops in each core that is identified in the core list are extracted from the configuration bitstream and reported to the user. The state information can be extracted by invoking the methods that are provided with each of the Java-implemented RTP cores. Specifically, various “get” methods are invoked to return the height, width, origin row and column, and state. The state information can be inspected by the user to determine whether the core is behaving as expected. 
     In another embodiment, a separate command named READBACK is implemented to read a configuration bitstream back from a PLD into a bitstream object. In this embodiment, the STATUS command does not initiate reading back the configuration bitstream. Instead, the STATUS command extracts state and other information from a configuration bitstream after the READBACK command has been performed. In this embodiment, the ADD, REMOVE, and STEP commands are adapted accordingly. 
     In addition to the methods described above, additional methods are implemented to support LIST, SELECT, WRITE, RESET, and EXIT commands. 
     The LIST command displays a list of the RTP cores and the associated constructors. The list is generated from the information in the master list of RTP cores. 
     The SELECT command sets a parameter that dictates to which PLD on a board reference is made by the ADD, REMOVE, WRITE, CONFIGURE, and PLACE commands. The STEP and RESET commands are applied to all PLDs on a board. 
     The WRITE command can be used to write the current configuration bitstream to a file. The bitstream can be used at a later time to initialize a PLD with a configuration bitstream other than the initial bitstream. 
     The RESET command can be used to place the PLD in a known state. Specifically, the RESET command causes the initial bitstream to be loaded into the PLD and read back. 
     The EXIT command disconnects the processor hosting tool  182  from the board and causes the tool to terminate. 
     FIGS. 7 and 8 illustrate a specific example involving an input script of commands (FIG. 7) and the state information (FIG. 8) displayed in response to processing the script of FIG. 7 by tool  182 . 
     The present invention is believed to be applicable to a variety of systems for configuring PLDs and has been found to be particularly applicable and beneficial in configuring FPGAs in a Java-based run-time reconfiguration environment. Other aspects and embodiments of the present invention will be apparent to those skilled in the art from consideration of the specification and practice of the invention disclosed herein. It is intended that the specification and illustrated embodiments be considered as examples only, with a true scope and spirit of the invention being indicated by the following claims.