Prior to reducing an integrated circuit design to a form suitable for fabrication, the integrated circuit design is often emulated to allow the design to be optimized and debugged. A hardware emulator (“emulator”) suitable for such use typically includes field programmable gate arrays (FPGAS) that serve as a breadboard for implementing the integrated circuit design. Such an emulator typically runs at a slower speed than a computer peripheral (“peripheral”) to which it is attached (e.g., a graphics card or a hard drive).
When an integrated circuit that has a peripheral interface is emulated, peripheral activities are usually emulated at the speed of the circuit emulator. A specially designed, slowed-down peripheral device is typically connected to a port of the circuit emulator. The emulator receives data from the slowed-down peripheral and transmits data to the slowed-down peripheral at the speed of the emulator. On balance, such a slowed-down peripheral requires a custom design and does not completely predict the behavior of a normal peripheral, operating at full speed, accurately and correctly. Because the peripheral is normally designed to operate at a faster speed, timing issues may arise such that it cannot be slowed down at all.
The present invention allows a circuit emulator to connect to a computer peripheral at full operational speed using a standard interface, such as a serial port, a high-speed parallel port, a small computer system interface (SCSI) or a universal serial bus (USB).
The invention provides a method and an apparatus for transferring data between an emulated device in a circuit emulator and the computer peripheral. In one embodiment, an interface software program installed on a host computer (e.g., a personal computer) is provided to handle communication between the peripheral and the circuit emulator. The peripheral can be, for example, a graphics card or a hard drive.
According to the present invention, data from a computer peripheral on the host computer that is intended for an emulated device in the emulator is received and stored in buffers on the host computer. The interface software in the host computer repackages the data packet into a second format for transmission to the emulated device at the speed of the emulated device. Similarly, the interface software in the host computer repackages the data received from the emulator into proper format for transmission to the peripheral at full speed. Under this arrangement, the existing memory in the host computer is used to buffer data communicated between the emulator and the peripheral, so that data received from the peripheral at full speed are transmitted to the emulator at a slower speed, and data received from the emulator at the slower speed is provided to the peripheral at full peripheral speed. Thus, the costs of providing additional memory and management of such additional memory in an emulator are avoided.
In one embodiment, the interface software of the host computer is implemented as a multithreaded program having, in one instance, two executing threads. One thread is a task that receives data from the peripheral, stores the received data in a buffer, retrieves the stored data for repackaging, and sends the repackaged data over the emulator interface to the emulator. Another thread is a task that receives data from the emulator interface, repackages the data into a format for the computer peripheral, and sends the data to the computer peripheral.
In another embodiment, the interface software of the host computer is implemented as a multithread program including four executing threads. One thread is a task that receives data from the peripheral and stores the received data in a buffer. A second thread is a task that polls the buffer for the received data. This second thread repackages the data and sends the repackaged over the emulator interface to the emulator. A third thread is a task that receives data from the emulator over the emulator interface and stores the received in a second buffer. A fourth thread is a task that polls the second buffer for the data received from the emulator. This fourth thread repackages this data and sends the repackaged data to the peripheral.
In yet another embodiment, the interface software of the host computer is also implemented as a multithread program, as in the previous embodiment, except that the second buffer is eliminated and the third and fourth tasks are combined into a single task executing as a single thread. In this embodiment, the single task receives data from the emulator, repackages the data received, and sends the repackaged data to the computer peripheral. This approach is possible when the emulator runs at a much slower speed than the peripheral, such that data received from the emulator can be repackaged and sent to the peripheral before the arrival of more data from the emulator.
Further features and advantages of various embodiments of the invention are described in the detailed description below, which is given by way of example only.
The present invention will be understood more fully from the detailed description given below and from the accompanying drawings of the preferred embodiment of the invention, which, however, should not be taken to limit the invention to the specific embodiment but are for explanation and understanding only.
In the following detailed description, to simplify the description, like elements are provided like reference numerals.
Software that allows a hardware emulator, emulating a circuit (“emulated device”) to connect to a computer peripheral hardware device is described. In the following description, numerous specific details are set forth, such as the peripheral interface, the operating system, the type of computer, etc., in order to provide a thorough understanding of the present invention. It will be obvious, however, to one skilled in the art that these specific details need not be used to practice the present invention. In other instances, well known structures, functions, and software programs have not been shown in detail in order not to unnecessarily obscure the present invention.
An embodiment of the present invention is illustrated in
At the lowest level is also the driver software for the bidirectional port 406. This software, usually supplied by the manufacturer of said bidirectional port allows computer operating system software 404 to access said bidirectional port without detailed knowledge of the hardware design or the operation of said bidirectional port. Said operating system also includes routines called bidirectional port application program interfaces (APIs) 403 that allow application programs to indirectly access the computer peripherals via said operating system. In this way, application programs can control the peripherals but the operating system can override said control or can allocate these peripherals to application programs according to particular priorities.
According to the invention, the EmBridge program 400 is an application program that runs on top of the operating system, which controls the computer resources allocated to it. The EmBridge program 400 can communicate to the emulator 203 via said parallel port API.
Note that the EmBridge program 400 can use the computer peripheral API 402 to access the computer peripherals indirectly. In some cases, to increase performance for example, it may be necessary for the EmBridge program 400 to access the peripheral driver software 405 directly, bypassing the operating system 404 and the APIs provided by the operating system. Similarly, the EmBridge program 400 can use the bidirectional port API 403 to access the bidirectional port indirectly. In some cases, to increase performance for example, it may be necessary for the EmBridge program 400 to access the bidirectional port driver software 406 directly, bypassing the operating system 404 and the APIs provided by the operating system.
The user interface 401 is the part of the EmBridge program 400 that allows the human user to enter information and control operation of the program 400. Said user interface 401 also gives results back to the human user.
In prior art, a custom built, slowed-down computer peripheral device would be connected to the emulator. The emulator would receive data from the slowed-down peripheral and would transmit data to the slowed-down peripheral at the speed of the emulator. Such a slowed-down peripheral is expensive because it requires a custom design. Also, it does not completely predict the behavior of a normal peripheral, operating at full speed, accurately and correctly. Because the peripheral is normally designed to operate at a faster speed, timing issues may arise such that it cannot be slowed down at all.
The present invention overcomes the limitations of the prior art by interfacing a real computer peripheral to the emulated device, taking advantage of standard software that is easily available and has already been fully tested. This standard software includes driver software and APIs that are written by the computer peripheral manufacturer and are included in many standard operating systems. As shown in
Thread 4 consists of a data reception routine 507 that retrieves data from the emulator via the bidirectional port using either the bidirectional port API 403 of the operating system or the bidirectional port driver software. Thread 4 may obtain said data by polling said emulator or alternatively via an interrupt mechanism that signals the thread whenever data is available from said emulator. Said data reception routine 507 stores said received data in shared memory buffer 506. Thread 3 consists of data transmission routine 505 that polls said shared buffer 506. When data is available in said shared buffer 306, said data reception routine 505 retrieves said data. If necessary, said data reception routine 505 modifies said data to be acceptable to said peripheral. Said data reception routine 505 then transmits said data to said computer peripheral either via the operating system API 402 or directly to the hardware drivers.
In this embodiment, the EmBridge program 400 has a stop routine 508 that takes input from the user in order to stop all executing threads of the program.
Thread 4 consists of a data reception routine 507 that retrieves data from the emulator via the bidirectional port using either the bidirectional port API 403 of the operating system or the bidirectional port driver software and a data transmission routine 505 that transmits said data to the peripheral either via the operating system API 402 or directly to the peripheral driver. Thread 3 may obtain said data by polling said emulator or alternatively via an interrupt mechanism that signals the thread whenever data is available from said emulator. Said data reception routine 507 sends said received data to said data reception routine 505 that modifies said data to be acceptable to the peripheral, if necessary, then transmits said data to said computer peripheral either via the operating system API 402 or directly to the peripheral driver. This embodiment takes advantage of the fact that said emulator is running much slower than the EmBridge program 400 and that said peripheral can receive data at a faster rate than said software can send it. Therefore there is only a single thread to retrieve data from said emulator and send it to said peripheral. In this embodiment, the EmBridge program 400 can perform the entire operation of thread 3 without slowing down said emulator or said peripheral. Unlike the embodiment shown in
In this embodiment, the EmBridge program 400 has a stop routine 508 that takes input from the user in order to stop all executing threads of the program.
Thread 2 consists of a data reception routine 507 that retrieves data from the emulator via the bidirectional port using either the bidirectional port API 403 of the operating system or the bidirectional port driver software and a data transmission routine 505 that transmits said data to the peripheral either via the operating system API 402 or directly to the peripheral driver. Thread 2 may obtain said data by polling said emulator or alternatively via an interrupt mechanism that signals the thread whenever data is available from said emulator. Said data reception routine 507 sends said received data to said data reception routine 505 that modifies said data in order to be acceptable to the peripheral, if necessary, then transmits said data to said computer peripheral either via the operating system API 402 or directly to the hardware drivers.
In this embodiment, the EmBridge program 400 has a stop routine 508 that takes input from the user in order to stop all executing threads of the program.
Various modifications and adaptations of the operations described here would be apparent to those skilled in the art based on the above disclosure. Many variations and modifications within the scope of the present invention are therefore possible. The present invention is set forth by the following claims.
Number | Date | Country | |
---|---|---|---|
20030225564 A1 | Dec 2003 | US |
Number | Date | Country | |
---|---|---|---|
Parent | 09751573 | Dec 2000 | US |
Child | 10158772 | May 2002 | US |