US 5,428,753 AGrant
Method for Controlling a Bus to Progress Transfer Cycles Without Inserting a Cycle for Acknowledgment
Issue Date:1995-06-27
•12 Claims
•16 Drawing Sheets
Abstract
An information processing system wherein a module to operate as a master which executes a read access to a module to operate as a slave requests a bus arbiter to afford the mastership of a bus with a bus mastership request signal, and it simultaneously asserts a last cycle signal so as to notify the bus arbiter of the fact that the next cycle will be the last cycle to be used by the master. Subsequently, when the master has had the use of the bus granted by a bus use grant signal from the bus arbiter, it transfers an address to the slave by the use of the bus in the next cycle, thereby starting the read access. After the read access, the master releases the bus mastership. Only when the slave has failed to accept the transferred address, does it assert a retry request signal two cycles after the transfer cycle of the address not accepted. In this case, the module having executed the transfer two cycles before the cycle of the asserted signal executes again the transfer executed before. Thus, the address to be transferred can be transferred to the module ready to accept the address, in only one cycle.
Metadata
Assignee
- Hitachi, Ltd.
Inventors
- Nobukazu Kondo
- Seiji Kaneko
- Hideaki Gemma
- Tetsuhiko Okada
- Kazuhiko Komori
- Koichi Okazawa
Application Information
Application Number:US 0600555
Filing Date:1993-05-13
Priority Date:1992-05-15
Art Unit:235
Classifications
IPC:
G06F 1312G06F 1340G06F 1342
Field of Search:
395325
Patent Drawings (16 sheets)
Description
Background of the Invention
1. Field of the Invention
The present invention relates to information processing systems such as personal computers and workstations. More particularly, it relates to techniques for controlling the bus of an information 9 processing system.
2. Description of the Related Art
In an information processing system, a plurality of modules connected to a bus for the transfer of data in synchronism with a common clock. A technique for controlling the synchronous bus is known from, for example, the official gazette of Japanese Patent Application Laid-open No. 11872/1986.
Such a prior-art control of the synchronous bus will be explained.
FIG. 16 of the accompanying drawings illustrates the timings of data transfer on the bus according to the synchronous bus controlling technique in the prior art.
Referring to the figure, symbol CLK denotes a synchronous clock for data transfer, which is common to all modules connected to a bus. Symbol A/D denotes an address and data which are multiplexed together. An address valid signal ADRV indicates that the address of the signal A/D is valid. A signal WRITE serves to designate a write access, and it also indicates that the data of the signal A/D is valid. In addition, a wait signal WAIT serves to notify a master side of the fact that a buffer on a slave side is not in a status capable of accepting the data.
In a case where one of the modules is to access another for a write operation by the use of the bus configured of such signal lines, the bus master first asserts the address valid signal ADRV indicating the validity of the address on the line A/D, and it simultaneously delivers the address of the access destination to the line A/D.
On the other hand, the slave module senses that the write access is directed toward itself, on the basis of the decoded result of the address and the designation signal WRITE for the write access. In a case where the slave module is ready for accepting the data, it accepts the valid data on the line A/D at the timing of the synchronous clock CLK. In contrast, in a case where the slave module is not ready for accepting the data, it requests the prolongation of a data cycle by the use of the wait signal WAIT which notifies the master side that it is incapable of accepting the data.
In a case where the wait signal WAIT is asserted, the master module prolongs the data cycle during the assertion. When the slave module is ready to accept the data, it accepts the valid data on the line A/D at the timing of the synchronous clock CLK, and it negates the wait signal WAIT. Upon the negation of the wait signal WAIT, the master module finishes the data cycle and ends the access.
In this manner, according to the prior-art technique for controlling the synchronous bus, the master module transfers the data to the slave module, and during the report to each other whether or not the data transfer is possible, using the wait signal WAIT in a handshake fashion.
Summary of the Invention
With the prior-art technique as stated above, in transferring the data, a wait cycle is inserted in advance of the data transfer. Therefore, an overhead arises in correspondence with the wait cycle, to incur problems that the data transfer rate is lowered and that the utilization factor of the bus is lowered due to an increased bus occupation time period.
It is accordingly an object of the present invention to provide a bus control method in which the utilization factor of a bus can be enhanced by reducing the overhead of data transfer.
In order to accomplish the object, the present invention proposes by way of example, a bus control method in an information processing system having a bus, and a plurality of modules connected to the bus, wherein a master which is the module having acquired mastership of the bus controls the bus and transfers an address and data to a slave which is the module being a transfer destination, in synchronism with cycles of a clock which is common to all the modules; comprising the step of allowing a specified one of the modules to acquire the bus mastership and so become master module; the step of allowing the master, having acquired the bus mastership, to execute a transfer cycle for transferring either of the address or the data to the slave, and to thereafter release the bus mastership; the step of allowing the module having received either of the transferred address and data as slave, to send all the other modules an acknowledge report indicating receipt of either of the address or the data, a predetermined number of cycles after the transfer cycle in which either the address or the data is transferred; and the step of allowing the module which executed the transfer as the master the predetermined number of cycles before the cycle in which the acknowledge report is sent, to verify success of the transfer in accordance with the sent acknowledge report.
According to the bus control method of the present invention, when the master has acquired the mastership of the bus, it executes the transfer cycle for transferring the address and the data to the slave, without checking the status of the slave, and it releases the bus mastership without verifying the success or failure of the transfer.
On the other hand, the module having received the transferred address and data as the slave sends all the other modules the acknowledge report indicative of the receipt for each transfer cycle concerning the received address or data, the predetermined number of cycles after the corresponding transfer cycle. The module having executed the transfer as the master the predetermined number of cycles before the cycle in which the acknowledge report has been sent, verifies the success or failure of the transfer in the executed transfer cycle in accordance with the sent acknowledge report. Only when the transfer is not successful, is a countermeasure taken.
Accordingly, the transfer to the slave which is ready to accept this transfer from the master can be realized by only the cycle in which the address or data is actually transferred. Thus, the utilization factor of the bus can be enhanced.
Brief Description of the Drawings
FIG. 1 is a block diagram illustrative of the architecture of an information processing system according to an embodiment of the present invention;
FIG. 2 is a block diagram showing the construction of a system bus interface device;
FIG. 3 is a timing chart showing a sequence in the case where bus mastership requests for read accesses have contended;
FIG. 4 is a timing chart showing the start sequence of the read access;
FIG. 5 is a timing chart showing the response sequence of the read access;
FIG. 6 is a timing chart showing the response sequence of the read access based on burst transfer;
FIG. 7 is a timing chart showing the sequence of a write access;
FIG. 8 is a timing chart showing the sequence of the write access based on the burst transfer;
FIG. 9 is a timing chart showing the retry sequence of the read access;
FIG. 10 is a timing chart showing a sequence in the case where a transfer error has developed;
FIG. 11 is a timing chart showing a sequence in a broadcast access mode;
FIG. 12 is a timing chart showing a retry sequence in the broadcast access mode;
FIG. 13 is a flow chart showing steps which a master runs in the broadcast access mode;
FIG. 14 is a timing chart showing a retry sequence in the case of successive write accesses which are similar to the ordinary write accesses;
FIG. 15 is a timing chart showing the sequence of the successive write accesses; and
FIG. 16 is a timing chart showing the sequence of a write access based on a bus controlling technique in the prior art.
Detailed Description of the Preferred Embodiments
Now, an embodiment of an information processing system according to the present invention will be described.
FIG. 1 illustrates the architecture of the information processing system in this embodiment.
As shown in the figure, the information processing system in this embodiment comprises system buses 50.about.60, a plurality of modules #0.about.#7 (100.about.107) which are connected to the system buses 50.about.60, a bus arbiter 108 which arbitrates a bus mastership among the modules 100.about.107, an I/O (input/output) bus 110 which is connected to the modules 100.about.107, and I/O devices 111 and 112 which are connected to the I/O bus 110. In some cases, only one I/O device is connected to the I/O bus 110. Besides, a processor bus to which a CPU (central processing unit) and a memory are connected is connected to at least one of the modules 100.about.107. Each of the modules 100.about.107 includes therein a system bus interface device, which mediates the data transfer between the system buses 50.about.60 and the I/O bus 110 or the I/O device 111 or 112.
Numeral 61 in the figure denotes a bus mastership request signal (BREQ0) with which a request for the bus mastership is made to the bus arbiter 108 by the module #0 (100), numeral 62 a bus use grant signal (BGRANT0) with which the bus arbiter 108 grants the module #0 (100) the use of the system buses 50.about.60, and numeral 63 a last cycle signal (LC0) with which the module #0. (100) notifies the bus arbiter 108 of the fact that the next cycle is the last cycle in the use of the system buses 50.about.60. Likewise, numeral 64 denotes a bus mastership request signal (BREQ1) directed from the module #1 (101) to the bus arbiter 108, numeral 65 a bus use grant signal (BGRANT1) directed from the bus arbiter 108 to the module #1 (101), and numeral 66 a last cycle signal (LC1) for reporting the last cycle from the module #1 (101) to the bus arbiter 108. Also, numeral 67 denotes a bus mastership request signal (BREQ7) directed from the module #7 (107) to the bus arbiter 108, numeral 68 a bus use grant signal (BGRANT7) directed from the bus arbiter 108 to the module #7 (107), and numeral 69 a last cycle signal (LC7) for reporting the last cycle from the module #7 (107) to the bus arbiter 108.
Regarding the system buses, the system bus 50 bears an address and data (A/D), and the system bus 51 bears a command signal (CMD) for designating the type of access. The system bus 52 bears an address valid signal (ADRV) indicating that the address on the address and data bus A/D (50) is valid, while the system bus 53 bears a data valid signal (DATAV) indicating that the data on the bus A/D (50) is valid. The system bus 54 bears a transaction acknowledge signal (TACK) with which a slave side notifies a master side of the fact that the address or the data has been correctly received. The system bus 55 bears a retry request signal (RETRY) which is directed from the slave side to the master side. The system bus 56 bears a synchronous error signal (SERR) being an error report signal which is synchronous with a transaction from the slave side to the master side, while the system bus 57 bears an asynchronous error signal (AERR) being an error report signal which is not synchronous with the transaction. The system bus 58 bears a freeze signal (FRZ) which is output simultaneously with the synchronous error signal SERR (56) or the asynchronous error signal AERR (57) so as to freeze any transaction other than a diagnostic transaction, while the system bus 59 bears a bus reset signal (BRST) which cancels the freeze signal after the information processing system has recovered from an error on the basis of the diagnostic transaction in the freeze operation. The system bus 60 bears a synchronizing clock signal (CLK) which is supplied to all the modules 100.about.107 in common.
Next, FIG. 2 illustrates the internal construction of the module which is connected to the I/O bus 110.
Referring to the figure, numeral 1 denotes the aforementioned system bus interface device which takes charge of bus controls, and which is connected between the system buses 50.about.60 and the I/O bus 110 so as to mediate the data transfer between the module and the I/O device 111 or 112.
Numeral 2 represents a system bus control portion which is provided within the system bus interface device 1, while numeral 3 represents a control portion which controls the I/O bus 110 connected to the system bus interface device 1. Shown at numeral 4 is a conversion portion which matches the interfacing between the system bus control portion 2 and the I/O bus 110 or I/O control portion 3. The system bus control portion 2 includes a bus arbitration controller 5, an error controller 6, a system bus controller 7, a retry controller 8, and a buffer 9 for received data. Further, the control portion 2 includes a final stage buffer 16 for outputs, an initial stage buffer 17 for inputs, an address output buffer 18, data buffers 19 .about.22 for a burst write mode, an input address buffer 23, a buffer 24 for checking an input address and data, and an error checker 29 for detecting a transfer error in accordance with, e.g., the parity of the data. Numeral 25 denotes an arbitration control signal. The conversion portion 4 includes an address converter 10, a data converter 11 and a protocol converter 12. The I/O control portion 3 includes an address I/O unit 13, a data I/O unit 14 and an I/O (bus) controller 15. Numeral 26 denotes an address bus, numeral 27 a data bus, and numeral 28 a control signal.
Incidentally, the module which is connected to the processor bus has a construction similar to the above.
Now, data transfer operations in such an information processing system will be described.
First, a read access operation will be explained. In this embodiment, the read access operation is realized by a start sequence in which a read requesting side delivers an address to the system bus 50, and a response sequence in which a requested side delivers data to the system bus 50 in response to the received address. Besides, in this embodiment, the start sequence and the response sequence realize the read access operation in terms of split operations which are independent of each other.
In this embodiment, in a case where any of the modules 100.about.107 performs the read access operation, it initially requests the bus arbiter 108 to grant a bus mastership, by the use of the bus mastership request signal (BREQ). At this time, it simultaneously produces the last cycle signal (LC), thereby giving the bus arbiter 108 the previous notice that the bus mastership will be released in one cycle.
Subsequently, when the bus use grant signal (BGRANT) has been asserted, the address etc. are delivered to the system bus 50. Then, the use of the system buses is ended.
FIG. 3 illustrates a case where the modules #0 (100) thru #3 (103) have asserted the bus mastership request signals BREQ's for read accesses at the same time.
As shown in the figure, the bus mastership request signals BREQ.about.BREQ3 of the respective modules #0 (100).about.#3 (103) are simultaneously asserted. Herein, priority levels for the bus use are assumed to be higher in the order of the module #0 (100), module #1 (101), module #2 (102) and module #3 (103).
As seen from the figure, bus masters in the third cycle, fourth cycle, fifth cycle and sixth cycle change-over in the order of the module #0 (100), module #1 (101), module #2 (102) and module #3 (103). Although the bus masters change-over every cycle, no idle cycle is inserted.
FIG. 4 illustrates the sequence in which the read access is started.
As seen from the figure, in this sequence, when the start module having asserted the signals BREQ and LC for the purpose of the read access, receives the bus use grant signal (BGRANT) from the bus arbiter 108, it asserts the address valid signal (ADRV) 52 indicating that the address on the address/data bus A/D is valid, and it delivers the address of an access destination to the address/data bus (A/D) 50. Simultaneously, it delivers the command signal to the bus (CMD) 51 to indicate that the type of access is a read access. Then, the start sequence is ended. Incidentally, the start cycle of the read access is the fourth cycle in the figure.
Next, the response sequence is shown in FIG. 5.
The module having received the command and address of the read access acquires the bus mastership when it has prepared the response data. Thereafter, it asserts the data valid signal (DATAV) 53 indicating that the data on the address/data bus A/D is valid, and it delivers the response data to the address/data bus (A/D) 50. Simultaneously, it delivers the command signal to the bus (CMD) 51 to indicate that the type of access is a read response access. The response cycle of the read access is the seventh cycle in the figure.
By the way, the response sequence of a read access in a burst read mode is shown in FIG. 6. In the figure, the response cycles of the read access are the fifth.about.eighth cycles.
As described above, in this embodiment, a wait signal or the like as in the prior art is not employed, and the buffer for received data (9 in FIG. 2) in each module is assumed to be capable of accepting data at any time. After having acquired the bus mastership, the module performs the transfer in one cycle per data item or per address, infallibly. Thus, a time period for the occupation of the bus A/D (the bus 50 for transferring the address and the data) is shortened, and the utilization factor of the bus A/D is enhanced.
Also in the sequence of a write access, as shown in FIG. 7, each of address transfer and data transfer can be ended in one cycle. A start cycle in which an address etc. is transferred or delivered to start the write access is the fourth cycle in the figure, while a response cycle in which data, etc., are transferred or delivered is the fifth cycle.
Besides, in the sequence of a write access in a burst write mode, as shown in FIG. 8, the transfer can be performed in one cycle per data item or per address infallibly. In FIG. 8, a start cycle for transferring the address is the third cycle, and response cycles for transferring for data items in response to the start cycle are the fourth.about.seventh cycles.
As stated before, it is assumed that the received data buffer (9 in FIG. 2) of each module can accept data at any time, and the module having acquired the bus mastership executes the transfer in one cycle per data item or per address, infallibly. The storage capacity of the buffer, however, is actually limited. Accordingly, when write accesses have been performed in succession, the buffer might overflow and fail to accept the data.
In order to avoid such a situation, this embodiment is provided with the transaction acknowledge signal (TACK) 54 with which the slave side notifies the master side of the fact that the address or data has been correctly received, the retry request signal (RETRY) 55 with which the slave side requests the master side to send the address or data again, and the synchronous error signal (SERR) 56 with which the slave side reports the occurrence of an error to the master side in synchronism with a transaction. In addition, these signals are delivered by the slave side infallibly two cycles after the transfer cycle of the master side. Thus, the master side can recognize whether or not the transaction directed therefrom has succeeded.
Besides, each module can discriminate whether or not its buffer will overflow due to the transaction, when subjected to the start of this transaction. Therefore, the retry request signal (RETRY) 55 of the slave side module is asserted for only the head cycle of the transaction. By the way, in the burst write mode or the burst read mode, information on the quantity of burst transfer is contained in the command signal (CMD) 51 in the head cycle of the transaction. Also in this case, accordingly, each module can discriminate whether or not its buffer will overflow due to the transaction, when subjected to the start of this transaction.
FIG. 9 illustrates an example of the sequence of a retry operation for the read access.
In the illustrated example, the slave asserts the signal (RETRY) 55 in the sixth cycle with respect to the first start cycle (the fourth cycle), and the master responsively executes the second start cycle in the eleventh cycle, thereby succeeding in the retry operation.
Next, FIG. 10 illustrates an example of a sequence in the case where a transfer error has occurred.
The illustrated example corresponds to the case where a parity error being the transfer error has taken place in the second data transfer cycle (the sixth cycle) of a burst write access. Herein, the synchronous error signal (SERR) 56 which is the error report signal synchronous with the transaction directed from the slave side to the master side is delivered from the slave side (in the eighth cycle) two cycles after the cycle having undergone the parity error. Moreover, the slave side module freezes the bus (A/D) 50 with the freeze signal (FRZ) 58 at the same time as the delivery of the error report signal. On the other hand, when the synchronous error signal (SERR) 56 has been asserted, the master side seeks the cycle of the error occurrence, the address of the error, etc. on the basis of the timing of the assertion of the synchronous error signal (SERR) 56, and stored information on the respective cycles executed in the past. It holds the sought information as logging information.
Besides, when the synchronous error signal (SERR) 56 has been asserted, a predetermined device taking charge of an error recovery process, such as the processor connected to any of the modules, eliminates the error (at any time between the ninth cycle and the eighteenth cycle) on the basis of the logging information, such as the error occurrence cycle and the error address, held by the master side module. Thereafter, the freeze operation is canceled with the bus reset signal (BRST) 59, and the ordinary transaction is restarted (in or after the twenty-fourth cycle).
Thus, in this embodiment, the master side receives the error report which is perfectly synchronous with the transaction. Therefore, it can log even the information indicating the cycle in which the error has developed, so that the subsequent analysis of the error and recovery process for the error can be facilitated.
There will now be explained a transaction of broadcast type in which data is simultaneously written into two or more of the modules (100.about.107 in FIG. 1) by the use of the system buses (50.about.60) having the protocol as stated above.
In the broadcast type transaction, the data must be simultaneously written into the plurality of modules. It is accordingly apprehended that any of the plurality of modules will undergo the overflow of the buffer (9 in FIG. 2) and will fail to have the data written thereinto.
This embodiment is therefore contrived so that, in the broadcast mode, the master may always wait for two cycles after the transfer cycle while keeping the bus mastership, thereby checking if the retry request signal (RETRY) 55 or the synchronous error report (SERR) 56 is asserted.
Here, it is possible that the transaction acknowledge signal (TACK) 54, retry request signal (RETRY) 55 and synchronous error report (SERR) 56 will be simultaneously asserted by a plurality of modules. These signals are therefore prepared as "wired OR" signals beforehand. Under this condition, when a retry request has been made, the master executes the same access cycle once more while keeping the bus mastership. On the other hand, each of the slaves having received the transferred data is always caused to wait for two cycles after the data transfer cycle while holding the transferred data without initiating the process thereof, thereby checking if the retry request signal (RETRY) 55 or the synchronous error report (SERR) 56 is asserted by any other slave. On condition that the retry request signal (RETRY) 55 or the synchronous error report (SERR) 56 has been asserted, each slave discards the received data.
Examples of sequences in the broadcast access operation are illustrated in FIGS. 11 and 12.
The example in FIG. 11 corresponds to a case where the data transfer has succeeded with one broadcast access. On the other hand, the example in FIG. 12 corresponds to a case where the data transfer has succeeded with three broadcast accesses.
In the example shown in FIG. 11, the master issues the last cycle signal (LC) and releases the bus mastership on the grounds that, even when it has waited for two cycles after the transfer cycle while keeping the bus mastership, neither the retry request signal (RETRY) 55 nor the synchronous error report (SERR) 56 is asserted.
In contrast, in the example shown in FIG. 12, the retry request signals (RETRY) 55 are respectively asserted in the fifth and ninth cycles with respect to the broadcast accesses which the master has started in the third and seventh cycles. The master starts the retry operations in the seventh and eleventh cycles in response to the respective asserted signals (RETRY). Regarding the second retry operation, the master verifies that the retry request signal (RETRY) 55 is not asserted in the thirteenth cycle, and that the error report signal (SERR) 56 is not asserted in the fourteenth cycle being two cycles after the last transfer cycle, either. Then, the master issues the last cycle signal (LC) and releases the bus mastership, thereby ending the transaction.
Here, the steps which the master executes for the broadcast access will be explained with reference to FIG. 13. As indicated in the figure, the master starts the broadcast access process at the step 150 and thereafter executes the broadcast type write access toward all the modules except the master itself at the step 151. At the step 152, the master decides if the retry request is made for the step 151. Subject to the retry request, the routine returns to the step 151, at which the broadcast type write access toward all the slave modules is executed again. When it has been decided at the step 152 that the retry request is not made for the step 151, the master waits for two cycles at the step 153 so as to check if all the slaves have received data without any error. When the master has received the error report at the step 154, the routine branches to the step 155 for the error process, and when not, the routine is ended at the step 156.
By the way, in a case where the module which is submitted to successive write accesses is a bus converter for the protocol conversion between buses of different hierarchies, it verifies that the buffer thereof has accepted all data items up to the last cycle from one of the buses, whereupon it starts transfer to the other bus.
Meanwhile, as stated before, the cycle in which the retry request is responsively received is two cycles after the start cycle. Therefore, in a case as shown in FIG. 14 where the same module performs write accesses (started in the third and fifth cycles) to a specified one of the other modules successively, the second write access is performed consecutive to the first write access by the master side even when the first write access has not been accepted on account of the condition of the bus interface device (1 in FIG. 2) of the specified module, for example, the overflow of the buffer (9). On that occasion, only the second write access might be accepted. In other words, the sequence of the accesses is not always guaranteed.
In order to avoid the above drawback, this embodiment is contrived as follows: In such a case where the successive write accesses are performed from the same module to the specified module, the bus interface device to start the successive write accesses always waits for two cycles after the end of each write access so as to verify that a retry request is not received, and it thereafter starts the next write access.
FIG. 15 illustrates an example of a sequence in the case where the successive write accesses are performed from the same module to the specified module.
In the illustrated example, after the master has ended the first write access in the fourth cycle, it verifies that the retry request signal (RETRY) is not asserted in the fifth cycle. Thereafter, it starts the second access in the seventh cycle.
In this embodiment, each of the retry request, the transaction acknowledge and the error report is made two cycles after the transfer cycle. The reason therefor is that the error checker (29 in FIG. 2), etc. are not directly connected to the system buses (50.about.60 in FIG. 1) with the intention of lightening the loads of the system buses to the utmost, thereby making it possible to increase the frequency of the signal CLK which is the synchronizing clock of the transfer.
As thus far described, according to the information processing system in this embodiment, the master module does not perform handshaking such as a ready control for verifying the propriety of the receipt of data by the slave module, and the data transfer source ends the transfer cycle without checking the acknowledge signal of the slave which is the transfer destination. It is therefore possible to enhance the utilization factor of the bus (A/D), and to raise the rate of access.
Moreover, regarding the error process, the error report is sent in synchronism with the cycle of the corresponding transaction. Therefore, the master module having received the error report can log detailed information while tracing back to the cycle in which the error has occurred, and the recovery process after the error occurrence can be facilitated.
As set forth above, the present invention can provide a bus control method in which the utilization factor of a bus can be enhanced by reducing the overhead of data transfer.
Claims
What is claimed is:
1. In an information processing system having a bus, and a plurality of modules connected to the bus, a bus control method wherein a master which is the module having acquired a mastership of the bus controls the bus and transfers an address and data to a slave which is the module being a transfer destination, in synchronism with cycles of a clock which is common to all the modules; comprising: the step of providing an acknowledge bus line, separate from the bus, to be used exclusively for transmitting an acknowledge report, said acknowledge bus line being connected to said plurality of modules; the step of allowing a specified one of said modules to acquire the bus mastership and so become said master; the step of allowing said master having acquired said bus mastership, to execute a transfer cycle for transferring either of the address or the data to said slave, and to thereafter release said bus mastership; the step of allowing said module having received either of the transferred address or data as said slave, to send to all the other modules, via said acknowledge bus line, an acknowledge report for indicating receipt of either said address or said data, a predetermined number of cycles after said transfer cycle in which either said address or said data has been transferred; and the step of allowing said module having executed the transfer as said master the predetermined number of cycles before the cycle in which said acknowledge report has been sent, to verify success of said transfer in said transfer cycle having been executed said predetermined number of cycles before the acknowledge report cycle, in accordance with the sent acknowledge report.
2. A bus control method as defined in claim 1, wherein in the case of transferring at least two of the addresses and the data items to said slave in succession, said master keeps said bus mastership for said predetermined number of cycles after the execution of each of the transfer cycles until it verifies said acknowledge report sent for the corresponding transfer cycle by said slave; and it goes on to the next transfer cycle after it has verified said acknowledge report sent for said corresponding transfer cycle by said slave.
3. In an information processing system having a bus, and a plurality of modules connected to the bus, a bus control method wherein a master which is the module having acquired a mastership of the bus controls the bus and transfers an address and data to a slave which is the module being a transfer destination, in synchronism with cycles of a clock which is common to all the modules, comprising: the step of providing a retry request bus line to be used exclusively for transferring a retry request, said retry bus line being connected to said plurality of modules; the step of allowing a specified one of said modules to acquire the bus mastership and thus become said master; the step of allowing said master having acquired said bus mastership, to execute a transfer cycle for transferring either of the address or the data to said slave, and to thereafter release said bus mastership; the step of allowing said module having failed to accept either said address or said data transferred in said transfer cycle in spite of being said slave in said transfer cycle, to send to all the other modules, via said retry request bus line, a retry request for asking for re-execution of the transfer, a predetermined number of cycles after said transfer cycle in which the slave module has failed to accept either said address or said data; and the step of allowing said module having executed said transfer as said master said predetermined number of cycles before the cycle in which said retry request has been sent via said retry request bus line, to retry said transfer in said transfer cycle having been executed said predetermined number of cycles before the retry request cycle.
4. A bus control method as defined in claim 3, wherein: said step of allowing said module to send said retry request includes the step of allowing said module having been said slave in the specified transfer cycle, to send all said other modules said retry request in only the cycle which is a predetermined number of cycles after a reference starting cycle of successive transfer cycles, in a case where said slave module has failed to accept any of said address and the data transferred in said successive transfer cycles executed by said master; and said step of allowing said module to retry said transfer includes the step of allowing said module having successively executed said transfer cycles as said master during said predetermined number of cycles before said cycle in which said retry request has been sent, to retry said transfer cycles having been successively executed before.
5. A bus control method as defined in claim 3, wherein in the case of transferring at least two of the addresses and the data items to said slave in succession, said master keeps said bus mastership for said predetermined number of cycles after the execution of each of the transfer cycles until it checks for presence of said retry request sent for the corresponding transfer cycle by said slave; and in the presence of said retry request, said master re-executes said transfer executed in said corresponding transfer cycle, in preference to the execution of the next transfer cycle.
6. A bus control method as defined in claim 3, further comprising: the step of providing a retry request bus line, separate from the bus, to be used exclusively for transferring a retry request, said retry request bus line being connected to said plurality of modules; the step of allowing said module having received either of the address or data involving a transfer error as said slave, to send to all said other modules, via said retry request bus line, an error report for indicating occurrence of said transfer error, a predetermined number of cycles after the cycle in which said transfer error has occurred; the step of allowing said master to execute broadcast transfer for simultaneously writing data into at least two of said modules operating as a plurality of slaves; and the step of allowing said master having executed said broadcast transfer, to keep said bus mastership for said predetermined number of cycles until it checks for presence of at least either of an error report or said retry request sent by any of said slaves in the cycle being said predetermined number of cycles after the transfer cycle in which said broadcast transfer has been executed, to retry said broadcast transfer corresponding to said retry request in the presence of said retry request sent by any of said slaves in said cycle being said predetermined number of cycles after the broadcast transfer cycle, and to execute a predetermined error recovery process in the presence of said error report similarly sent by any of said slaves; wherein each of said slaves holds the transferred data for said predetermined number of cycles after having accepted said transfer of said data from said master, until it checks the presence of either of said retry request or said error report sent by any other slave as to said transfer cycle in which said transfer has been accepted; and it discards the held data in the presence of either of said retry request or said error report sent by any other slave said predetermined number of cycles after said transfer cycle in which said transfer has been accepted.
7. In an information processing system having a bus, and a plurality of modules connected to the bus a bus control method wherein a master which is the module having acquired a mastership of the bus controls the bus and transfers an address and data to a slave which is the module being a transfer destination, in synchronism with cycles of a clock which is common to all the modules; comprising: the step of providing an error report bus line, separate from the bus, to be exclusively used for transferring an error report, said error report bus line being connected to said plurality of modules; the step of allowing a specified one of said modules to acquire the bus mastership and thus become said master; the step of allowing said master having acquired said bus mastership, to execute a transfer cycle for transferring either of the address or the data to said slave, and to thereafter release said bus mastership; the step of allowing said module having received either of the transferred address or data as said slave, to send to all the other modules, via said error report bus line, an error report for indicating occurrence of a transfer error, a predetermined number of cycles after the cycle in which said transfer error has occurred, in a case where said transfer error is involved in either of the received address or data; and the step of allowing said module having executed the transfer as said master the predetermined number of cycles before the cycle in which said error report has been sent, to recognize said occurrence of said transfer error in said transfer cycle having been executed said predetermined number of cycles before the error report cycle, in accordance with the sent error report.
8. A bus control method as defined in claim 7, further comprising: the step of furnishing said information processing system with an error process means for executing an error recovery process which eliminates any error; the step of allowing said module having received either of said transferred address or data as said slave, to send all said other modules a freeze signal simultaneously with said error report, said freeze signal functioning to freeze any transaction on said bus other than a diagnostic transaction; the step of allowing said module having executed said transfer as said master said predetermined number of cycles before said cycle in which said error report has been sent, to obtain information on said transfer cycle having undergone said transfer error and on said transferred address in accordance with a send timing of said sent error report, to hold the obtained information as logging information, and to command said error processing means to execute said error recovery process; and the step of allowing said error processing means to send all said other modules a bus reset signal after having eliminated said error on the basis of said logging information, said bus reset signal functioning to restart the ordinary transaction on said bus.
9. A bus control method as defined in claim 7, wherein in the case of transferring at least two of the addresses and the data items to said slave in succession, said master keeps said bus mastership for said predetermined number of cycles after the execution of each of the transfer cycles until it checks for presence of said error report sent for the corresponding transfer cycle by said slave; and it goes on the next transfer cycle after it has verified absence of said error report.
10. An information processing system having a bus, a plurality of modules connected to the bus, and a bus arbiter for arbitrating a mastership of the bus among the modules comprising an acknowledge bus line, separate from the bus, to be used exclusively for transferring an acknowledge report, said acknowledge bus line being connected to said plurality of modules, wherein each of said modules comprising: a bus control means for controlling a sequence in which said module acquires the bus mastership; a sequence in which, when said module has acquired said bus mastership, it executes as a master a transfer cycle for transferring either of an address or data to a slave being the module of a transfer destination, and it thereafter releases said bus mastership; a sequence in which, when said module has received either of the transferred address or data as said slave, it sends to all the other modules, via said acknowledge bus line, an acknowledge report for indicating receipt of either said address or said data, a predetermined number of cycles after said transfer cycle having transferred either said address or said data therein; and a sequence in which said module having executed a transfer cycle as said master verifies success of the transfer in said transfer cycle having been executed, depending upon if said acknowledge report has been received said predetermined number of cycles after said transfer cycle.
11. An information processing system as defined in claim 10, further comprising a retry request bus line, separate from the bus, to be used exclusively for transferring a retry request, said retry request bus line being connected to said plurality of modules, wherein: each of said modules further comprises it retry control means for sending to all said other modules, via said retry request bus line, a retry request for asking for re-execution of the transfer, a predetermined number of cycles after the specified transfer cycle having failed to be accepted, in a case where said module has failed to accept said either of said address or said data transferred thereto in said specified transfer cycle; and said bus control means further controls a sequence in which said module having executed a transfer cycle as said master retries said transfer in the executed transfer cycle, in a case where said module has received said retry request said predetermined number of cycles after said executed transfer cycle.
12. An information processing system as defined in claim 10, wherein: said system comprises an error report bus line, separate from the bus, to be used exclusively for transferring an error report and an error processing means for executing an error recovery process which eliminates any error, said error report bus line being connected to said plurality of modules; each of said modules further comprises an error checker which checks for presence of a transfer error in either of the received address or data, when said module has received either of the transferred address or data as said slave; and an error control means for sending to all said other modules, via said error report bus line, an error report for indicating occurrence of said transfer error, a predetermined number of cycles after the cycle in which said transfer error has occurred, in the presence of said transfer error; said bus control means further controls a sequence in which, in a case where said module having executed a transfer cycle as said master has received said error report said predetermined number of cycles after the executed transfer cycle, it obtains information on said transfer cycle having undergone said transfer error and on said transferred address, it holds the obtained information as logging information, and it sends said error processing means a request for executing said error recovery process; and said error processing means having received said request for executing said error recovery process eliminates said error on the basis of said logging information, and thereafter sends all said other modules a bus reset signal for restarting an ordinary transaction on said bus.