System bus interface controlling at least one slave device...

Electrical computers and digital data processing systems: input/ – Intrasystem connection

Reexamination Certificate

Rate now

  [ 0.00 ] – not rated yet Voters 0   Comments 0

Details

C712S208000, C712S209000, C710S107000, C710S120000

Reexamination Certificate

active

06195716

ABSTRACT:

TECHNICAL FIELD
The present invention relates to an interface bridge between system bus and local bus (and more generally to an interface device between system bus and a system unit), provided with a simplified auxiliary control interface for the direct connection to the system bus of one or more memory devices and more generally “slave” devices.
It also relates to the corresponding simplified control interface and the corresponding interface protocol.
BACKGROUND OF THE INVENTION
It is known that in modern data processing systems, to obtain high performance, use is made of an architecture with several symmetric processors interconnected via a high-performance system bus.
A conventional example of a system bus commonly adopted is that currently termed 6××which is particularly geared to the interconnection of RISC microprocessors, such as for example the POWER PC microprocessors from the IBM company or the like.
In this architecture, so as always to obtain high performance and to reduce the loads connected to the system bus, the operating frequency of which can thereby be increased beyond 100 MHz, the various I/O peripheral components are not connected directly to the system bus but rather to one or more local buses, for example of the type known as PCI standing for Peripheral Component Interconnect (bus) which communicate with the system bus through a PCI bridge.
The communication protocols and timings used by the local buses differ from those used by the system bus and the function of the bridge is to make it possible to transfer information between the buses, in full compliance with the corresponding protocols and corresponding timings.
The architecture and the protocol used by modern system buses are particularly elaborate, essentially in order to allow accesses to the bus of the “split” type, in which the addressing phase is separated from and entirely independent of the phase for transferring the data which are read, so as to ensure the consistency of the information, which may be replicated in several fast memories or caches, by means of bus watching or snooping operations, and so as to guarantee the correctness of the information transferred.
For example the 6××system bus is made up of two distinct buses for the addresses (64 wires, 48 of which are reserved for the transferring of addresses and the remainder for service information such as transaction attributes, parity check bits, transaction identifier (Tag), size and type of transfer) and for the data (158 wires, 128 of which are reserved for the transfer of {fraction (8/16)} bytes of data and the remainder for service information, such as parity bits, valid-data, error, bus-occupied and transaction identification (Tag) signals).
The transactions on the data bus take place at deferred time relative to those on the address bus, and in case of read cycles may also be out of order.
The logic link is ensured by a transaction identifier associated with the addresses and with the data.
The communication protocol on the address bus is divided into three phases:
in the first phase the address and the corresponding service information are latched and a parity check is performed, in the second phase, the type of transaction is verified, the availability or otherwise is verified of the resources for executing the transaction, and the various units connected to the system bus generate state signals which, gathered by a collector entity, generally an arbitration unit, are then broadcast to all the units connected to the system bus.
The state signals can indicate parity error, the need for a retry, if the resources needed for executing the transaction are occupied, acknowledgement of the transaction as executable, nullity of the transaction because of non-identification of a destination device or target.
The final phase is that of consistency verification or consistency snooping in which all the devices connected to the system bus report their own response to a collector entity via response signals RESP OUT. The collector entity then rebroadcasts to the various units a collective response code RESP IN which, depending on the consistency protocol adopted, generally the protocol known by the acronym MESI (Modified, Exclusive, Shared, Invalid), may have a different meaning, one of which is that of RETRY, for requesting the repetition of the current transaction, which is not executed.
Obviously the communication protocol is preceded by an arbitration phase (which may temporally overlap the execution of a previous transaction for access to the address bus) in the course of which the units which intend to obtain access to the address bus send an access request ABREQ to an arbitration unit which responds with a signal ABGRANT sent to just one in turn of the requesting units, depending on appropriate priority criteria.
The mechanism for transferring data to the data bus is much simpler.
In the case of write operations, the requesting or master unit presents simultaneously with the request for access to the address bus, also a request DBREQ for access to the data bus and, having obtained access and verified that the data bus is free, need do nothing other than assert a data bus occupied signal DBBSY and place thereon the data to be written.
In the case of read operations, the destination or target unit, addressed with a read request via the address bus, need do nothing other than request access to the data bus, with the assertion of a signal DBREQ and having obtained access from the arbitration unit (which responds with a signal DBGRANT asserted) and verified that the data bus is free, as indicated by a signal DBBSY deasserted, does nothing other than take possession thereof with the assertion of the signal DBBSY and transfer the requested data in one go (single beat) or in burst mode to the data bus (the mode is defined by the requesting or master unit).
It is thus evident that each unit, even the simplest, directly connected to the system bus, must be provided with interface logic able to operate in accordance with the communication protocol imposed by the system bus, even in the event that the unit is of the slave type, i.e. not able to activate transactions on the system bus (more properly on the address bus since, obviously, the unit has to respond if interrogated in read mode) and devoid of caches, thereby rendering such logic particularly complex and expensive.
The bridge devices which make it possible to set up a communication between the system bus and one or more local buses, the latter possibly providing for very simple communication protocols, only partly solve this drawback.
Thus, in this case, even if the cost and circuit complexity of the interface logic to the system bus is to some extent shared between the various units, in general more than one, connected to the local bus, it is however offset by the fact that the access transactions, for reading the units connected to the local buses, are appreciably slowed, while in some cases speed of response is essential.
A typical case consists for example of a ROM memory (possibly of the rewriteable EEPROM type) intended for storing part of the operating system which manages the working of the various processors connected to the system bus and which has to be speedily accessible by the various processors.
SUMMARY OF THE INVENTION
It is an object of the present invention to overcome these drawbacks of the prior art.
The present invention provides an interface bridge between system bus and one or more local buses, which is provided with a simplified auxiliary interface for controlling one or more “slave” devices such as for example ROM memories, for their direct connection to the system bus.
More generally the interface bridge may consist of any interface device between system bus and a unit of the system, to which device, which is intrinsically furnished with the logic required for the control of the protocol of the address bus, is delegated the function of interfacing with the address bus also for (on behalf of) a second “slave” device (or more than one), su

LandOfFree

Say what you really think

Search LandOfFree.com for the USA inventors and patents. Rate them and share your experience with other people.

Rating

System bus interface controlling at least one slave device... does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with System bus interface controlling at least one slave device..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and System bus interface controlling at least one slave device... will most certainly appreciate the feedback.

Rate now

     

Profile ID: LFUS-PAI-O-2615252

  Search
All data on this website is collected from public sources. Our data reflects the most accurate information available at the time of publication.