Method for Simulating Bus Traffic

The present invention relates generally to the field of computer hardware logic design, and more particularly to an improved simulation environment for developing and testing such hardware logic.

In designing and testing hardware interface logic for devices to be used with conventional bus computers, a primary task is to design hardware logic which will accomplish assigned tasks with optimal efficiency and as many desirable features as possible. For example, a video interface card intended for insertion into an industry standard Peripheral Component Interconnect ("PCI") bus computer would, ideally, quickly draw and refresh images on a video screen, with a maximum number of colors and other desirable features available. However, no matter how well designed such an interface is, it is of no value unless it communicates well with the computer's processor and other devices, as necessary, by means of the computer bus. Therefore, the makers of such hardware interfaces must give close attention to the design and testing of the interfaces for proper communication with the computer bus.

Several companies currently provide logic simulators, which are software tools which provide a means by which logic designers can emulate a working environment for hardware devices, such as the video interface card discussed above, so that the new hardware devices can be tested for proper operation in relation to the bus interface. Some of these vendors, as well as some other independent developers, provide "models" which plug into the software simulators. The models provide the necessary traffic on the bus to test new hardware interface devices. Such models are commonly written in one or both of two languages which are readily available and well known in the field: "VHDLtm" (VERY HIGH SPEED INTEGRATED CIRCUIT HARDWARE DESCRIPTION LANGUAGE) or "Verilogtm". Such models generally include a set of instructions for sending and receiving data to and from the device under test such as could be expected in a "real" application of the device, and further for storing the results of the data interchanges so that the results can be retrieved and studied at the end of the test.

Existing prior art models have performed quite effectively where there are few, or relatively few problems encountered during a test. However, as devices get even more complex, it becomes more important that models might, somehow, be able to become more interactive such that they are more of an aid in troubleshooting a complex interface problem rather than just a reporter of such problem. To the inventor's knowledge, prior to the present invention, no means has existed in the art for providing such dynamic interaction between the model, the simulator, and the device under test. All prior methods and means have generally just run preprogrammed tests and accumulated data to be studied at the end of the test.

Accordingly, it is an object of the present invention to provide a model which can react to eventualities occurring during a test.

It is still another object of the present invention to provide a model which can allow operator intervention during a test.

It is yet another object of the present invention to provide a model which can provide information about test results prior to the conclusion of the test.

It is still another object of the present invention to provide a model which can work in conjunction with commercially available simulators.

It is yet another object of the present invention to provide a model which is adaptable to be used with various bus types for testing various device types.

It is still another object of the present invention to provide a model which can be adapted for operator intervention or for programmed automatic test intervention upon the observance of predetermined test result criteria.

It is yet another object of the present invention to provide an improved means for troubleshooting new computer interface devices.

It is still another object of the present invention to provide a model that is appropriate for use by logic designers, system engineers, and VLSI chip designers.

Briefly, the preferred embodiment of the present invention is an improved model adapted for use with a PCI bus and having a programming interface (PI) controlling and directing a (primary) memory pool, a slave memory pool, a command processor/bus master (CP/BM) and an arbiter, each of which is a device affecting data traveling to and from a computer bus. For example, in the Appendices portion of the present disclosure, a PCI Bussim Model Architecture is described which includes slave pool memory, master pool memory, CP/BM, and PI elements. Specifically, page 2 of the PCI Bussim Model Architecture provides an example as follows: (There are two blocks of pool memories used by the Master (Command Processor/Bus Master--CP/BM) and Slave blocks. The pools are named Master Pool (MP) and Slave Pool (SP) depending on the block using the pool. The Pool Memory is used during a burst cycle, where individual data, wait states and byte enables are stored for each transfer of the burst. The interface to each of the Pool Memories is provided through individual set of signals connected to them, and through VHDL procedures provided by the PI).

A user device is connected to the computer bus such that, according to instructions issued from the programming interface, data is caused to travel between the bus and the user device, with verification occurring such that the nature of any failure can be readily determined and appropriate action taken (either by machine or user intervention). The unique structure of the dynamic hardware emulation model is dynamic, rather than operating in a batch mode as in the prior art, each portion of a test is individually informative and the test can be aborted, continued without interruption or automatically changed, as is appropriate to the nature of the user device and the specific test procedure being performed.

An advantage of the present invention is that users need not learn different modeling environments in order to test at different levels of design abstraction.

A further advantage of the present invention is that individual operations are separately verified such that a record is kept regarding errors and causes thereof, and further such that branching of a test can occur upon given error conditions.

Yet another advantage of the present invention is that test speed is optimized.

Still another advantage of the present invention is that development time is minimized because additional information is provided from testing, and further because futile testing is avoided.

These and other objects and advantages of the present invention will become clear to those skilled in the art in view of the description of the best presently known mode of carrying out the invention and the industrial applicability of the preferred embodiment as described herein and as illustrated in the several figures of the drawing.

FIG. 1 is a block diagram of the inventive dynamic hardware emulation model; and

FIG. 2 is a flow diagram of a cycle of operation of the dynamic hardware emulation model of FIG. 1.

The best presently known mode for carrying out the invention is a dynamic hardware emulation model for use in conjunction with a computer hardware environment simulator for testing at least one user device. The predominant expected usage of the inventive dynamic hardware emulation model is in the design and testing of hardware component devices intended to be connected to the data bus of a computer.

The inventive dynamic hardware emulation model is depicted in a block conceptual diagram in the view of FIG. 1, and is depicted therein by the general reference character 10. One skilled in the art will recognize that a model such as the inventive dynamic hardware emulation model 10 is intended to be used in conjunction with a software test environment simulator 11, several versions of which are commercially available from Synposistm, Cadencetm, and other sources. As can be seen in the view of FIG. 1, the dynamic hardware emulation model 10 has a programming interface ("PI") 12, a pool memory 14, a command processor/bus master ("CP/BM") 16, a slave memory 18, and an arbiter 20. For example, the PCI Bussim Model Architecture in the Appendices portion of the present disclosure notes on page 9 that the slave pool memory, master pool memory, CP/BM, and arbiter are components to the system. Specifically, page 9 of the PCI Bussim Model Architecture discloses as follows: (The signal fields are used to interconnect the ports of the underlying components which is the CP/BM, the Slave Pool Memory, the Master Pool Memory, and Slave PCI Model, and the Arbiter).

The best presently known embodiment 10 of the present invention can work in conjunction with commercially available simulators. A PCI bus 24 has attached thereto (in addition to several component models (for example an arbiter, clock generator, or the like) necessary and usual for the emulation of the bus environment which are not shown for the sake of clarity) at least one user device 26 (two user devices 26 are shown by way of example in the view of FIG. 1) which is under examination. The memory pool 14 and slave memory pool 18 resides in a conventional main memory 30 of the computer system 22, and will be discussed in more detail hereinafter.

FIG. 2 is a flow diagram of a test process 32 according to the best presently known embodiment 10 of the present invention. In the example of FIG. 2 it is understood that the PI 12 has therein a series of instructions for performing a particular test or test sequence. Such instructions can optionally be placed in the PI 12 itself or retrieved from files stored in the data storage device 23 or through user intervention from the data storage device 23 and, optionally, also by individual user input (as from a keyboard or other input device, not shown). In a load procedure into pool memory operation 32 (FIG. 2) a series data for distinct operations are loaded into the pool memory 14 (FIG. 1) by means of a pool memory PI access port 35 (FIG. 1). The data stored by the load procedure into memory operation 34 will have actual data 36, byte enable 38 instructions and wait state data 40, such that a wait state and byte enable can be specified for each step of the operation. For example, the PCI Bussim Model Architecture in the Appendices portion of the present disclosure describes example operations for setting the data value, wait state value, and byte enable value to the master pool memory on page 10 as follows: (Valid operations are:

SET.sub.-- DATA Sets the input data value to the Master Pool Memory.

SET.sub.-- WS Sets the input wait state value to the Master Pool Memory.

SET.sub.-- BE Sets the input byte enable value to the Master Pool Memory.)

In an instruct CP/BM operation 42 (shown, by way of example as following the load procedure into pool memory operation 34 in the view of FIG. 2, although the load procedure into pool memory operation 34 and the instruct CP/BM operation generally occur relatively simultaneously and may, in fact, be interspersed), instructions appropriate to the current operation are provided from the PI 12 to the CP/BM 16 via a CP/BM command link 44. As an example, where the user device 26 under test is a video graphics array ("VA") video interface card, an operation might be to write data beginning at a particular memory address, and a series of operations might be to continue to write data into the VA card, beginning at a particular address. The data to be written (the actual data 36) would be supplied to the pool memory 14, and a burst count 46, address 48 and command 50 are provided from the PI 12 to the CP/BM 16. (The burst count 46, address 48 and command 50 are illustrated graphically in the view of FIG. 1 as blocks of data on the CP/BM command link 44.) For example, the PCI Bussim Model Architecture in the Appendices portion of the present disclosure describes example operations for setting commands, burst length, and address on pages 12-13 as follows:

(SET.sub.-- CMD Sets the command for the CP/BM.

SET.sub.-- BURST.sub.-- LEN This operation allows the burst length for the PCI cycle that is being initiated.

SET.sub.-- PCI.sub.-- ADDR This address for the PCI cycle is given using this operation.) In addition to the pool memory PI access port 35, the pool memory also has a CP/BM write port 52 and a CP/BM read port 54, both to enable direct communication between the CP/BM 16 and the pool memory 14.

It is known in the industry that certain commands are associated with certain bus types. For example standard commands for the PCI bus 24 are memory read, memory write, configuration read, configuration write, input/output ("I/O") read and I/O write. The inventive dynamic hardware emulation model provides a modified set of commands such that each of the commands can add an optional verify. That is, instead of just "memory read" a command can be "memory read and verify" and a "memory write" can be "memory write and verify". A "read modify write" command is also enabled in the best presently known embodiment 10 of the present invention. For example, the PCI Bussim Model Architecture in the Appendices portion of the present disclosure describes an example operation for a write verify on page 13 as follows: (C.sub.-- WRITE.sub.-- VERIFY Start a Write cycle and read back the same location to verify the success, of Write cycle). It is known in the industry, for example where it is desired to superimpose one image over another on a video screen, to read data (as from the user device 26 where the user device 26 is a video interface card), and to modify such data according to a complex parameter such that a composite of the "old" image (the one already showing on the screen) and a new image is written to the device 26.

The user device 26 can operate in a master or slave mode. That is, the user device 26 can be commanded, as by the PI 12, to send or receive data, or the user device 26 can itself, acting as the master, issue commands.

The slave memory 18 contains data which is read from a user device 26 when the user device 26 is in the slave mode. The arbiter 20 determines which of the user devices 26 (or other devices) has access to the bus 24, should more than one such device request access to the bus simultaneously.

Returning to the flow diagram of FIG. 2, in a perform instructions operation 56, the CP/BM 16 performs an operation as previously instructed by the PI 12, using data put into the pool memory 14 by the PI 12, and advances a burst counter. A perform data transaction phase 64 shown in FIG. 2 indicates the accomplishment of any data input or output required according to the instructions performed in the perform instructions 56 operation. In a burst count check decision operation 58, if the burst counter matches the burst count 46 (FIG. 1) previously loaded into the CP/BM then the burst counter is reset and control is returned to the PI 12 to begin the next test process 32. If the burst counter does not match the burst count 46, then the burst counter is advanced and the next perform instructions 56 operation is initiated as is shown in the view of FIG. 2 by a cycle return loop 60 indication. Each repetition of the perform instructions operation is referred to as a cycle. It should be noted that instructions issued from the PI 12 can also be "non-burst" instructions wherein a single operation rather than a series of operations is performed.

Various modifications may be made to the invention without altering its value or scope. For example, while the example of the best presently known embodiment 10 of the present invention relates to a PCI bus, the invention is adaptable for use with any such bus or similar computer hardware interconnection means. Similarly, while the best presently known 10 embodiment is written in and intended for operation with the VHDLtm language, as discussed previously herein, it is intended by the inventors that Verilogtm or other language versions of the invention be produced. Furthermore, while the user device 26 is generally illustrated herein as being a video interface card, application of the present inventive dynamic hardware emulation model 10 is by no means restricted to the development and testing of video interface cards.

All of the above are only some of the examples of available embodiments of the present invention. Those skilled in the art will readily observe that numerous other modifications and alterations may be made without departing from the spirit and scope of the invention. Accordingly, the above disclosure is not intended as limiting and the appended claims are to be interpreted as encompassing the entire scope of the invention.

The inventive dynamic hardware emulation model 10 is intended to be widely used, in conjunction with commercially available simulators, in the design and testing of computer interface device, such as video interface cards, that are to be inserted into the bus slots of computers.

As contrasted to existing prior art models, wherein a test had to be loaded and run in its entirety (excepting, perhaps, where a catastrophic failure might `hang up` a system and thereby self abort a test), the inventive dynamic hardware emulation model 10 can be programmed to carry out actions based on responses from the user device 26 under test, thereby both avoiding the continuation of a fruitless test and allowing the branching of a test to a useful line of inquiry, should there be a failure. Such branching can occur simply by stopping the test and allowing the human user to decide how to then proceed, or else a more sophisticated routine might allow for the automatic branching of tests upon certain potential failure modes.

Further as contrasted to existing prior art models, wherein accumulated data had to be processed and investigated at the end of a test, the present inventive configuration allows for an operation by operation verification of test results, thus not only preventing fruitless testing, as discussed above, but also providing additional valuable information to the hardware designers. That is, as contrasted to prior art modules wherein a user would only know that an error had occurred--that data had not been transmitted or received as expected--(and then only after time consuming evaluation of accumulated data), users of the inventive dynamic hardware emulation model 10 will know the nature of the error.

The inventive dynamic hardware emulation model 10 will be readily recognized and accepted by those who use such models. The additional features, as compared to prior art models, will be easily understood. The user may not even understand or need to know that such additional features are not simply additions to prior art models, but rather required a complete rethinking of how such models are arranged, as discussed herein, in order to implement the new and useful features.

It is anticipated that, as the present invention is further developed, more sophisticated test routines and parameters will be developed both by the inventors and by other users of the dynamic hardware emulation model 10. Indeed, it is an important aspect of the present invention that the pool memory 14, the command processor/bus master 16 and the slave memory 18 are implemented and interconnected generally as presented in relation to the best presently known embodiment 10 of the present invention, thereby allowing ready access between the various component parts of the invention and providing a platform upon which further ingenuity can be built. As discussed previously herein, the inventors have provided such a flexible platform as an alternative to the prior art paradigm for a model, wherein there was no built opportunity to conform the sequence of a test according to individual need.

Each user may elect to interact with the dynamic hardware emulation model 10 in varying degrees of detail. The user may specify PCI bus commands directly, or call upon a macro command which provides the composite commands such as "read modify write" and "read verify". The `on the fly` read verify described herein, which verifies each read transaction, eliminates the need for time consuming comparison of accumulated data to a file of expected data. This leads to higher productivity and design accuracy, when developing computer interface devices, by preventing spurious testing. Since the user interface of the dynamic hardware emulation model 10 remains constant no matter what level of detail is required in the testing, user learning time is minimized.

The VHDL implementation of the best presently known embodiment 10 of the present invention will run on any commercially available IEEE-1076 compliant VHDL simulator, although versions which will run on other simulators and hardware accelerator versions are anticipated by the inventors. The present inventive dynamic hardware emulation model 10 is intended to be used as a substitute for existing models and can be substituted therefor without substantial modification of associated hardware and software, and without substantial effort or learning on the part of users. Since the dynamic hardware emulation model 10 of the present invention may be readily produced and integrated into existing development and testing environments, it is expected that it will be readily accepted in the industry. For these and other reasons, it is expected that the utility and industrial applicability of the invention will be both significant in scope and long-lasting in duration.

The attached appendices labeled "APPENDICES TO U.S. APPLICATION ENTITLED: DYNAMIC HARDWARE EMULATION MODEL DOCKET NO. 73497-0001 RAGHAVAN ET AL. FILED APR. 20, 1995" are incorporated by reference in the entirety.