JPH04349554A - Bus verifying system - Google Patents

Abstract

PURPOSE:To verify the normalcy of an input/output bus between a CPU and a channel by setting one of two channels and the other as an initiator and a target, respectively, and forming a data loop by the CPU, under the condition that an input/output device cannot be used. CONSTITUTION:An initiator channel 14 and a target channel 15 are connected in common to a channel interface, for instance, an SCSI 16. A CPU 1 issues a store instruction for storing data A in a data buffer 17 of the channel 15, to the channel 14. The channel 14 issues a command for storing the data A to the channel 15, and stores the data A in the data buffer 17. The CPU 1 reads out the contents of the data buffer 17 of the channel 15, and stores them as data A' in a register 13. The CPU 1 compares the contents (data A) of a register 12 and the contents (data A') of the register 13. Unless they are the same, it is decided to be abnormal.

Description

[Detailed description of the invention]

0001

[Industrial Application Field] The present invention relates to a bus verification method, in particular,
The present invention relates to a bus verification method for confirming the normality of an input/output bus between a CPU and a channel in a situation where no input/output device is connected.

0002

[Prior Art] In the operation test of information processing equipment, CP
One of the most important items is to check whether data transfer between the U and the input/output device is performed normally. FIG. 4 shows the configuration of a conventional bus verification method. In Figure 4, C
Two input/output (I/O) buses 2 and 3 are connected to PU1. I/O buses 2 and 3 are connected to channel devices (hereinafter referred to as channels) 4 and 5, respectively.

[0003] Channels 4 and 5 are commonly connected to an input/output interface (hereinafter referred to as interface) 6. The interface 6 has a magnetic drum (DAS)
Input/output devices (units) such as a magnetic tape (referred to as D) 7 and a magnetic tape (referred to as MT) 8 are connected. Channels 4 and 5 have the function of receiving input/output commands from the CPU 1 and controlling input/output operations independently of the CPU 1. Interface 6 connects channels 4 and 5 and DASD 7
and MT8 are connected according to predetermined rules. By interface 6 channels 4 and 5 are
Various input/output units can be controlled by standard input/output commands.

The operation of the conventional bus verification method shown in FIG. 4 is as follows. Data storage and fetch operations for each of I/O buses 2 and 3 are performed as follows. (1) The CPU 1 issues a store command to the channel 4 via the I/O bus 2 to store data in the input/output unit, for example, the DASD 7. (2) The CPU 1 stores this data. (3) Channel 4 decodes the store command and sends the data from CPU 1 to DASD through interface 6.
7 and store it at a predetermined address.

(4) Next, the CPU 1 issues a fetch command to the channel 4 to read the above data from the DASD 7. (5) Channel 4 decodes the fetch instruction and
Read data from the above address of ASD7 and use I/O
It is transferred to CPU 1 via bus 2. (6) The CPU 1 compares the stored data and the received data, and if they are the same, the I/O
Bus 2 is determined to be normal, and if different, it is determined to be not normal. (7) Perform the same steps as (1) to (5) above for I/O bus 3 and channel 5, and
/Verify the normality of O bus 3. As mentioned above, conventionally, DASD7 or MT8
was used to verify each I/O bus 2 and 3.

[0006]

As described above, according to the conventional bus verification method, input/output devices such as DASD and MT are essential. However, there are cases where it is necessary to verify the normality of the bus in a test environment without input/output devices such as DASD and MT. For example, thermal environmental conditions
This is difficult for DASD, MT, etc., so there are cases where they cannot be used. In such a case, the above conventional method cannot be applied. Furthermore, in the conventional method described above, when an error occurs, it is difficult to distinguish whether the error occurs during a store or a fetch. The present invention is based on DAS
In test environments where it is impossible to use input/output devices such as D, MT, etc. connected to a channel, the normality of the bus can be confirmed without them, and the causes of errors can be easily identified. The purpose is to provide a bus verification method that can identify

[0007]

[Means for Solving the Problems] A bus verification method according to the present invention includes two input/output buses, which are connected to one end of each of the two input/output buses, and send data to one of the input/output buses.
A CPU that receives the data from the other input/output bus and determines the normality of the input/output bus by comparing the sent data and the received data, and a CPU that is connected to the other end of the one input/output bus and acts as an initiator. a functional first channel device; a second channel device connected to the other end of the other input/output bus and having firmware serving as a target for an initiator; and a second channel device commonly connected to the first and second channels; It is configured with an interface.

[0008]

[Operation] With the above configuration, a loop is formed starting from the CPU, passing through the first channel device, the interface, and the second channel device, and returning to the CPU. When verifying a store operation, the CPU issues a store command to the first channel device to store certain data in the target. Data is stored through one input/output channel, the first channel device and the interface into a data buffer provided in the firmware of the second channel device. Next, the CPU is
A read command is issued to the second channel device to read the contents of the data buffer. Data is retrieved to the CPU through the other I/O bus.

[0009] The CPU compares the data sent to one input/output bus with the data received from the other input/output bus, and if they are the same, determines that the input/output bus is normal; If they are not the same, it is determined that there is an abnormality in the input/output bus. When verifying the fetch operation, the CPU issues a store command to the second channel device to store data in the data buffer. Data is stored in a data buffer. Next, the CPU issues a fetch command to the first channel device to read data from the data buffer.

Data is retrieved from the data buffer, through the interface, the first channel device, and one input/output bus to the CPU. The CPU determines the normality of the bus by comparing the stored data and the retrieved data. As described above, even if an input/output device such as a magnetic drum or magnetic tape is not connected to the channel device, it is possible to check the normality of the bus during store and fetch operations. Furthermore, if there is an abnormality, it can be easily determined whether the abnormality occurred during a store or a fetch.

[0011]

Embodiments Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings. FIG. 1 shows the configuration of a bus verification method according to the present invention. The CPU 1 includes registers 12 and 13 that temporarily store test data, and register 12.
It has a comparator 11 that compares the contents of and 13. Registers 12 and 13 are connected to I/O buses 2 and 3, respectively. I/O bus 2 is connected to initiator channel 14 and I/O bus 3 is connected to target channel 15.

[0012] The initiator channel 14 and the target channel 15 are channel interfaces, for example, SCSI (Small Computer S
system interface) 16. Here, the target channel 15 will be explained. Generally, when a channel receives an input/output command from a CPU, it decodes it and outputs an input/output command to the corresponding input/output unit, such as a DASD, to control the operation of the input/output unit. That is, traditionally, the channel was always the initiator of a command, and the input/output unit was its target. In order to verify the normality of the bus in a situation where there is no conventional target input/output unit such as DASD, the present invention sets one of two channels as a normal initiator channel, and sets the other as a normal initiator channel. It is used as a target.

In order to change the channel as a normal initiator to a target functionally equivalent to DASD, MT, etc., firmware having functions equivalent to DASD, MT, etc. is installed in the channel 15 in advance, or, Such firmware is loaded onto channel 15 through I/O bus 3. The data buffer 17 forms part of the firmware and temporarily stores test data. As described above, CP
A closed loop is formed: register 12 of U1 - I/O bus 2 - initiator channel 14 - interface 16 - target channel 15 (data buffer 17) - I/O bus 3 - register 13.

The operation of the system shown in FIG. 1 will be explained below. FIG. 2 shows the operation of bus verification (store verification) when storing data. In FIG. 2, thick white arrows indicate the flow of data. Store validation is performed as follows. (1) The CPU 1 uses the data buffer 17 of the target channel 15 for the initiator channel 14.
Then, a store instruction for storing data A is issued. (2) The initiator channel 14 decodes the store command, sends a command to store the data A in the data buffer 17 to the target channel 15 via the interface 16, and stores the data A in the data buffer 17.

(3) The CPU 1 issues a read command to read the contents of the data buffer 17 to the target channel 15. Data buffer 17
The contents are taken out to the register 13 of the CPU 1 as data A'. (4) The CPU 1 uses the comparator 11 to compare the contents of the register 12 (data A) and the contents of the register 13 (data A') to check whether these data are identical. If the data A and A' are the same, it is determined that the store operation is normal; if they are not the same, it is determined that there is an abnormality.

FIG. 3 shows bus verification (
(fetch validation) operation. Fetch validation is performed as follows. (1) The CPU 1 transfers data A in the register 13 to the data buffer 17 for the target channel 15.
Issue a write instruction to store in the . Data A is stored in data buffer 17. (2) and (3) The CPU 1 issues a fetch command to the initiator channel 15 to retrieve the contents of the data buffer 17. This allows data buffer 1
The contents of 7 are interface 16 and channel 14.
The data is transferred to the register 12 of the CPU 1 via the . (4) CPU1 uses register 1 by comparator 11.
The data of 2 and 13 are compared and the normality of the bus is determined based on the data identity. In the above embodiment, the firmware is installed only in the channel 15, but it is of course possible to install the firmware in both channels and set either one as the target.

[0017]

As described above, according to the present invention, by using one of the two channels as a pseudo input/output unit, the normal operation of the bus can be maintained even in an environment where no actual input/output unit exists. It is possible to verify the gender. Therefore, it becomes possible to verify the normality of the bus in a wider environment than before.

[Brief explanation of drawings]

FIG. 1 is a diagram showing the configuration of the present invention.

FIG. 2 is a diagram (part 1) showing the operation of the present invention.

FIG. 3 is a diagram (Part 2) showing the operation of the present invention.

FIG. 4 is a diagram for explaining a conventional technique.

[Explanation of symbols]

1 CPU 2, 3 I/O bus 4, 5 channels 6 Input/output interface 7 Magnetic drum (DASD) 8 Magnetic tape (MT) 11 Comparator 12, 13 Register 14, 15 Channel 16 Input/output interface 17 Data buffer

Claims (1)

[Claims] Claim 1: Two input/output buses, connected to one end of each of the two input/output buses, transmitting data to one input/output bus, receiving the data from the other input/output bus, and transmitting data. a first channel device connected to the other end of the one input/output bus and functioning as an initiator; A bus verification comprising: a second channel device connected to the other end of the bus and having firmware serving as a target for the initiator; and an interface commonly connected to the first and second channels. method.