Abstract:
An apparatus for and method of automatically generating, transmitting, receiving, and verifying test request messages within a large scale resource sharing computer system. In the preferred mode, the testing technique is applied to a memory resource having up to four requester ports. The test messages are simultaneously but randomly generated within each of the requester ports. These test messages are transferred to the memory resource. The responses from the memory resource are automatically verified within each of the receiving requester ports.

Description:
CROSS REFERENCE TO CO-PENDING APPLICATIONS 
     None. 
     BACKGROUND OF THE INVENTION 
     1. Field of the Invention 
     The present invention generally relates to digital data processing systems and more particularly to techniques for testing access to a shared resource having a plurality of resource requesters. 
     2. Description of the Prior Art 
     The earliest computer systems generally employed a single processor, single memory, and single peripheral equipments of various rudimentary types. As systems became more complex, additional peripherals were added, prompting some switching functions provided by an input/output controller. Further complexities produced systems having multiple memory modules. Oftentimes, multiple computers were coupled together to perform larger tasks which could be parsed into two or more parallel functions. By providing for peripheral sharing and intercomputer input/output, such multiple computer systems became primitive multiple processor systems. 
     Today, even the simplest forms of general purpose computers have some modularity permitting customization through the addition of memories, input/output channels, etc. The most complex of current day computers employ multiple processors which share multiple memories, input/output controllers, and other resources. 
     Testing of early computers involves determining whether the various components function as intended. Does the processor properly execute each defined instruction? Does the memory properly store data? Do each of he input/output devices function as specified? 
     Similarly, testing of large modem multiprocessor systems requires exercising each of the components to ascertain that each module functions as intended. However, even though this type of testing is necessary, it is not sufficient. Because of the multiple user/multiple shared resource environment, substantial testing of intercomponent communication is also required. Not only is it important to verify that each user can properly communicate with each resource, it is absolutely necessary to show that all users can communicate with all resources, as simultaneously as permitted by the priority scheme. 
     This type of testing becomes very complex, because it needs to randomly (or pseudo-randomly) perform functional testing and assessment from the perspective of multiple users and multiple resources. In the past, this has necessitated specialized test equipment driven by laboriously defined test patterns followed by time consuming manual analysis of the results. 
     SUMMARY OF THE INVENTION 
     The present invention overcomes many of the disadvantages found within the prior art by providing apparatus for and a method of testing intercomponent communication within a multiple user/multiple shared resource environment. In accordance with the technique of the present invention, intercomponent test messages are automatically generated consistent with a predefined format. The test messages are randomly transferred by the various different requesters to a shared resource. The present invention automatically verifies the responses received by the requesters from the shared resource. 
     Though the present invention is applicable to a general class of situations, the preferred mode is practiced within a Horizon mainframe computer system available from Unisys Corporation. In this system, the main memory storage unit is accessible by up to four asynchronous and independent ports. These ports serve as requesters on behalf of instruction processors, input/output processors, and other users. In ordinary operation, a port transmits a message to the main memory storage unit which specifies the requested service. The main memory storage unit decodes the message and honors the enclosed request in accordance with a predefined priority scheme. After honoring the request, the results are formatted as a message which is transferred to the port specified in the request. 
     The apparatus of the preferred mode of the present invention, generates test messages to be randomly transferred to the main memory storage unit by each of the available ports. As messages are received by the various ports from the main memory storage unit in response to the test messages, these responses are verified for proper operation and routing. Each of the requesters has counters which are incremented in a predefined fashion to provide uniqueness of the test messages within the sequence. Corresponding counters within the requesters permit the receiving requesters to create the anticipated response messages to enable verification. The present invention is structured to continuously generate test messages and verify responses until testing is terminated by the operator. A special error signal is produced whenever an unexpected response message is received. 
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS 
     Other objects of the present invention and many of the attendant advantages of the present invention will be readily appreciated as the same becomes better understood by reference to the following detailed description when considered in connection with the accompanying drawings, in which like reference numerals designate like parts throughout the figures thereof and wherein: 
     FIG. 1 is a block diagram showing the structure of the Horizon main memory storage unit configuration for practicing the preferred mode of the present invention; 
     FIG. 2 is a table showing the format of the test messages to be generated; 
     FIG. 3 is a detailed block diagram of the structure of the present invention involved in test message generation and transmission; and 
     FIG. 4 is a detailed block diagram of the structure of the present invention involved in test message response verification. 
    
    
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 
     FIG. 1 is a basic block diagram of the main memory request structure of the Horizon mainframe computer system, commercially available from Unisys Corporation. The architecture of this state of the art mainframe computer system includes memory storage unit (MSU)  10  which is basically word, cached, semiconductor storage bank. Each word is 36 bits in width. The instruction processors and many of the input/output devices of the Horizon system are based upon this 36-bit word format. Every access to the memory storage provides reading and/or writing of eight double word blocks. The read/write access to this storage is address interleaved to decrease average access time. MSU  10  has priority analysis and buffering facilities for up to four requesters. A more detailed explanation may be found in the above referenced, commonly assigned, co-pending, and incorporated U.S. Patent Application. 
     The four requester ports are PPDA 0   20 , PPDA 1   22 , PPDA 2   24 , and PPDA 3   26  which are coupled to MSU  10  via bi-directional interfaces  12 ,  14 ,  16 , and  18 , respectively. Each of these ports services at least one user (not shown) which may be an instruction processor, input/output controller, or other user requiring main storage access. A request is formulated in a requester port in response to the need of a corresponding user. The formulated request is actually a message to MSU  10  having a predefined format. This message is received by MSU  10 , decoded, queued for servicing, and eventually honored. A response message is formulated by MSU  10  and returned to the port specified in the service request message. Further details concerning the operation of a requester port may be found in the above referenced and incorporated U.S. Patent Application. 
     It can be readily appreciated that the basic operation of MSU  10  can be verified using standard memory testing techniques from a single requester port. Furthermore, these tests may be repeated for each requester port to fully test the interfaces. However, such testing does not completely exercise the priority logic, the queuing circuitry, and all of the message routing facilities. 
     Simultaneous, asynchronous, and random (or pseudo-random) testing must be performed from all requester ports to properly verify all functions under normal operating conditions. Unlike prior art techniques which manually generate requester messages and verify response messages, the present invention provides a technique for automatically generating random (or pseudo-random) requester messages and automatically verifying the corresponding response messages (see below). 
     FIG. 2 is a table defining the contents of the test requester messages to be automatically generated in accordance with the present invention. A requester message within the Horizon system consists of a 14-bit response field and eight 64-bit containers of data. The response field contains the information needed to determine where the message came from. With this invention, the eight 64-bit data containers are used to transfer the contents of message counters that a given PPDA uses to keep track of the number of messages it has sent to each of the other ports. Each PPDA has a “sent_to” counter, for each of the four destinations, and as a message is sent, one or more of these counters are incremented depending on which PPDA(a) are to receive the message. Then as the message is sent, the four “sent_to” counters are placed in four of the data containers as shown in FIG.  2 . 
     FIG. 3 is a detailed block diagram  28  showing the automatic generation and transmission of test messages within a PPDA. The test (and also normal) request messages are transferred via pathway  30  to the interface to MSU  10  (see also FIG.  1 ). Write data selector  32  (a two input/one output parallel multiplexer device) selects whether normal write data from path  34  or test message data from path  36  is to be transferred via pathway  30 . Selection is based upon message data indicator  38  which permits changing from normal operation to test operation. The normal write data input is as described in the above identified U.S. Patent Application. 
     MSG data selector  42  provides for selection of the contents of the eight data containers for a given automatically generated test message. Sequencing of the data selection is made under the direction of container number  40 , which is a two-bit selection value. Thus container number  40  defines selection of each of the eight inputs of MSG data selector  42 . 
     A convenient fixed pattern is predefined. It is to be loaded into the first two and last two data containers (see also FIG.  2 ). It is suggested that these fixed patterns correspond to “worst data patterns” such as alternating ones and zeroes. The remaining four data container inputs (i.e., data container numbers  2 ,  3 ,  4 , and  5 ) are received via paths  44 ,  46 ,  48 , and  50 , respectively. These correspond to the outputs of Sent_to_ 0  counter  52 , Sent_to_ 1  counter  54 , Sent_to_ 2  counter  56 , and Sent_to_ 3  counter  58 . The use of these counters provide unique identification for the messages sent to each of the PPDAs. These counters are incremented by the Master bit message destination vector signal as shown. 
     FIG. 4 is a detailed block diagram showing the PPDA circuitry for automatically receiving the test messages and automatically verifying that the test messages were correct and correctly delivered. The response message is received by the PPDA from MSU  10  via the corresponding pathway (see also FIG.  1 ). The response message is divided into its two major component parts, the 14-bit response field and the eight 64-bit data containers. The first component part (i.e., the 14-bit response field) identifies the transmitter of the test message. This information is provided to line  118  as the POD ID and line  66  as the POD ID of MSG Source. The second component part (i.e., eight 64-bit data containers is provided on line  106  as MSU read data. 
     The POD ID of MSG Source is provided to decoder  68  to decode the source of the current message. The output of decoder  68  increments one of the Rec_from_counters (i.e., counters  80 ,  82 ,  84 , and  86 ) via lines  78 ,  76 ,  74  or  72 , respectively. This incrementation permits the receiving PPDA to determine which message is being received and the contents of that message for comparison purposes. 
     The Rec_from_counter outputs are transferred to selector  96  via lines  88 ,  90 ,  92 , and  94 , respectively. Selector  96  multiplexes the inputs to choose the counter output corresponding to the POD ID (i.e., transferring PPDA) on line  66  for presentation as a first input to selector  102  via line  98 . The other input to selector  102  is the predetermined fixed pattern (see above) received via line  100 . Using these inputs to selector  102 , the correct contents of the second portion (i.e., data containers) received message can be created to compare with the actual received message. 
     Compare enable logic  116  controls the assembly of the created correct message by switching selector  102  to its first input (i.e., counter outputs) for container numbers  2 - 5  and to its second input (i.e., fixed pattern) for container numbers  0 ,  1 ,  6 , and  7 . The container number is determined by the position within the received message and is presented to compare enable logic  116  on line  70 . The output of selector  102 , applied to line  108 , is thus the complete created data container portion of the message expected to be received. 
     Data compare  112  compares the second portion of the received message from line  106  with the created second portion of the expected received message from line  108 . A compare error signal is generated and placed on line  114  if the second portions of the received message and created message are not identical. Timing control of data compare  112  is received via line  110  from compare enable logic, which enables a comparison only during the second portion of the message. 
     Having thus described the preferred embodiments of the present invention, those of skill in the art will readily appreciate that the teachings found herein may be applied to yet other embodiments within the scope of the claims hereto attached.