Data processing: structural design – modeling – simulation – and em – Simulating electronic device or electrical system – Circuit simulation
Reexamination Certificate
1995-06-30
2001-09-18
Coulter, Kenneth R. (Department: 2154)
Data processing: structural design, modeling, simulation, and em
Simulating electronic device or electrical system
Circuit simulation
Reexamination Certificate
active
06292764
ABSTRACT:
A MICROFICHE APPENDIX is part of this patent. It includes six (6) fiche with four hundred and four (404) frames.
The invention concerns configurable device adapters for connecting dissimilar types of devices to a data processing system bus. The invention can optimally match the bus to each device, and for this reason the invention is called “tunable.”
BACKGROUND OF THE INVENTION
This discussion will first explain a highly simplified data bus, and then illustrate how the simplified bus has evolved into a vast array of different types of data busses.
Different types of devices can generally be connected to a bus by different types of device adapters. However, device adapters do not necessarily result in optimal matching to a particular device, as will be explained.
FIG. 1
illustrates a highly simplified example of data transfer over a bus. The transfer sequence is the following, beginning at the top left part of the Figure:
1. The Sender places data onto the Data Lines, as indicated.
2. The Sender pulls a Ready line HIGH, as indicated, thereby telling the Receiver that the Data is ready.
3. In response, the Receiver collects the Data.
4. The Receiver pulls the Acknowledge line HIGH, thereby telling the Sender that the Receiver has taken the data, and that another piece of Data can be placed on the Data Lines.
5. The Sender detects the signal on the Acknowledge line, and pulls the Ready line LOW.
6. The Receiver responds by removing the signal on the Acknowledge line.
At this time, all lines are in their original conditions. The Sender may repeat the process by placing a second piece of Data onto the Data Lines.
The exemplary transaction given above is a highly simplified example. It easy to envision ways to improve and complicate the bus. Several examples are the following:
1. The Receiver may detect an error in the data, and may wish to request that a given piece of data be transmitted again. To accommodate this wish, an additional Repeat line can be provided, by which the Receiver requests the repeated transmission.
Thus, when the Sender receives a signal on the Repeat line, the Sender repeats the transmission. Conversely, if the Sender receives no such signal, but receives an acknowledge signal instead, the Sender sends the next piece of data.
2. Assume that the Sender places a piece of data on the Data Lines, and pulls the Ready line HIGH. How long should it wait for the acknowledge signal? What does the Sender do if it receives no acknowledgment signal within the allotted time?
One common approach to the problem is the following. If the Sender receives no acknowledgment signal within a specified time, then the Sender abandons the attempt to send data.
However, another approach is based on the supposition that, if the Receiver is busy performing another task when the Sender wants to send data, nevertheless, the Receiver is willing to accept the data when the task terminates. Under this approach, a Wait line can be provided. When the Sender sees a Wait signal, it does not abandon the attempt to send data, but waits for the Wait signal to disappear.
3. Suppose that other devices besides the Receiver are connected to the data bus. However, the Sender wishes to send data to a specific device, and wishes others to ignore the data. Selection lines can be added which instruct a specific device to listen to the data.
4. As in case
3
, above, multiple devices are connected to the data bus. However, in contrast to the examples given above, now the devices wish to initiate communication: The devices now become Senders. Further, the devices simultaneously wish to send data. However, to allow them to do so would result in confusion.
A solution is to add Interrupt Lines. Each device asks permission, prior to sending data, by using the interrupt lines.
There are numerous additional examples of additional types of lines which can be added to a bus, to provide added features. Therefore, it is not surprising that numerous types of device interfaces exist, each with its own particular combination of lines and data transfer sequences.
Further, a device interface to a bus does not operate in isolation: if the device and bus attain the highest possible speed between themselves, it is possible that this speed was obtained at a cost to some other components or devices.
For example, assume that a bus couples together a processor and a printer. It is easy to see that very fast data transmission can occur if the processor devotes its full attention to the printer, and ignores all other devices on the bus, such as disc drives. However, under this scenario, the processor becomes unavailable for other tasks while tending the printer. Thus, while throughput of printed data is very high, other tasks have been brought to a standstill.
Viewed another way, in this example, the processor is capable of transmitting data at a far higher rate than the printer can print it. Thus, in fact, during the full-attention printing, the processor will be spending idle time while the printer prints. The processor could be performing other tasks during this idle time.
One solution to this type of problem is the use of buffering. A simple example will illustrate.
Assume that the Sender's data bus is 32 bits wide, as shown in FIG.
2
. Assume that the Receiver's data bus is smaller, at 8 bits. A very crude device adapter could operate as STEP 1 through STEP 4 indicate. The Adapter transfers data in eight-bit chunks. However, a problem with this approach is immediately apparent. While the Receiver may be receiving data as fast it can, the Sender is tied to the bus during the Receiver's activity. The Sender can do nothing else. This approach is inefficient from the Sender's view.
As shown in
FIG. 3
, the Adapter can grab the entire 32-bit word from the Sender, and place the data in a Buffer. Now, the Buffer holds the data while the Adapter transmits it to the Receiver in eight-bit chunks. Now the Sender has been freed from waiting for the Receiver to receive the data.
For sending data in the opposite direction, wherein the Receiver sends data to the Sender, the Adapter would perform the opposite sequence. The Adapter would collect data from the Receiver in eight-bit chunks. When 32 bits have accumulated in the Buffer, the Adapter sends the 32 bits to the Sender.
While the buffering approach represents an improvement over the non-buffering approach, the buffering approach itself can be improved, by choosing the proper size of the buffers under the circumstances, as well as other parameters.
It should now be apparent that there are numerous design constraints which exist and trade-offs which are made when attaching a device to a bus. When designing an adapter to allow such attachment, hereinafter a device adapter, these design constraints and trade-offs result in a time consuming design effort for a particular type or class of device(s). When a subsequent type or class of device(s) is to attach to this bus, a similar intensive design effort is required to create a device adapter for this new device. There is a need for a system which allows for parameters, such as buffering specifications for a particular type or class of device, to be identified to a general purpose design macro, wherein a device adapter design is automatically generated which conforms to such user specified requirements. This device adapter design would thus be optimized for a given device which is to attach to a bus.
OBJECTS OF THE INVENTION
It is an object of the invention to provide an improved device adapter.
It is a further object of the invention to provide a device adapter which can be optimized, or tuned, to a given environment.
It is yet another object of the present invention to provide general purpose device adapter macro which can be customized, via user specified parameters, for a particular attaching device.
SUMMARY OF THE INVENTION
In one form of the invention, configurable device adapters are provided. The invention provides circuitry, for a particular type or class of device, which adapts the device to a bus.
Avery James M.
Isenberg William D.
Coulter Kenneth R.
Hyundai Electronics America Inc.
Townsend and Townsend / and Crew LLP
LandOfFree
Tunable architecture for device adapter does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Tunable architecture for device adapter, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Tunable architecture for device adapter will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2535732