Unidirectional verification of bus-based systems

Details Unidirectional verification of bus-based systems Unidirectional verification of bus-based systems

2000-07-25

2004-05-11

Decady, Albert (Department: 2133)

Error detection/correction and fault detection/recovery

Pulse or data error handling

Transmission facility testing

C714S712000, C714S738000, C714S819000, C714S821000

Reexamination Certificate

active

06735728

ABSTRACT:

BACKGROUND OF THE INVENTION
The present invention relates to a testing system for testing a bus-based system.
Modern data processing systems are often built up of a plurality of individual components interconnected by means of one or more internal or external busses. The individual components can be, for example, central processing units (CPUs), memories, RAID subsystems, cache system, NIC cards, mass storage devices, etc. Different internal or external busses (in the following only referred to as busses) are generally (inter-)connected using one or more bus interfaces. Each bus interface (also called bridge) is coupled between (at least) two busses or between one bus and e.g. a CPU subsystem, and only such information which is intended to pass to the ‘other side’ of the bus interface will be routed thereto. For that purpose, each bus interface “knows” the address(es) of component(s) connected to the respective bus and/or the types of transfers it has to route through (in case of a PCI bus, this information is configuration cycles, special cycles or interrupt acknowledge cycles).
FIG. 1
depicts an example of a typical structure of a bus-based system. The system comprises three busses
10
,
20
and
30
. A bus interface
40
is coupled between bus
10
and bus
20
, and a bus interface
50
is coupled between bus
20
and bus
30
. As examples for individual components within the bus-based system are components
52
,
54
and
56
, each coupled to bus
10
, components
60
and
62
, each coupled to bus
20
, and components
70
and
72
, each coupled to bus
30
.
In operation, when, for example, component
52
wants or is requested to write an information to component
72
, this information is first placed on bus
10
. Bus interface
40
, which “knows” that component
72
is coupled “somehow” to bus
20
, routes that information to bus
20
. Accordingly, bus interface
50
, which “knows” that the component
72
is coupled to bus
30
, routes that information to the bus
30
. The component
72
, connected to bus
30
, can eventually receive and accept that information. In another example, when, for example, component
60
wants or is requested to read from component
70
, component
60
initiates a read signal onto the bus
20
. The bus interface
40
knowing that the component
70
is not coupled to bus
10
will not route that read signal onto bus
10
. However, the bus interface
50
knowing that the component
70
is coupled to bus
30
will route the read signal to bus
30
, and component
70
will thus receive the read signal from the bus
30
.
In order to test (also referred to as verifying or validating) the structure of the bus-based system and also the functionality and accuracy thereof, in particular of the bus interfaces, tests are normally executed in the “naked” system generally without or only with a reduced number of components which could possibly be applied within the system. For this purpose the system will usually completely be ‘populated’ with test devices, e.g. inserted into each free slot for inserting components, so that every slot and every bus can participate in testing the system.
A test system known in the art is employed by the Hewlett-Packard HP E2920 PCI series and the HP E2976A System validation package and uses test cards coupled to individual busses for validating the bus-based system. In the. example of
FIG. 1
, a testing card
80
might be coupled to the bus
10
, a testing card
85
might be coupled to the bus
20
, and a testing card
90
might be coupled to the bus
30
. For validating the structure of the bus-based system, each testing card can write information to any other testing card and eventually read that information again from that other testing card. If the information read out from the other testing card equals the information written thereto, it can be assumed that the transmission of the information has been executed without faults and thus that the structure insofar is without faults.
FIG. 2
depicts the principle structure of the testing card
80
, as an example for all of the testing cards
80
,
85
or
90
. The
80
comprises a memory
100
, a sender (which might also be referred to as data source or initiator)
110
, a receiver (which might also be referred to as data target or completer)
120
, and a comparator
130
. For writing information onto the bus
10
, the sender
110
reads out that information from the memory
100
and puts it on the bus
10
. It is clear that the external address and the internal address do not need to have any relationship with each other.
For comparing the result of a writing action onto another testing card (direction of arrow I in
FIG. 2
) e.g. on the testing card
85
(as indicated in
FIG. 2
as a connection of the testing card
85
to the bus
10
), the sender
110
initiates a reading action (direction of arrow II in
FIG. 2
) onto the other testing card
85
. The read-out information from the testing card
85
will eventually be available on bus
10
and the receiver
120
will place that information to the comparator
130
which compares that information with the information corresponding to that address AD as stored in the memory
100
.
Although the testing cards as depicted in
FIG. 2
already lead to a sophisticated validation and verification of bus-based systems, some structural faults are only hardly detectable. Such a fault could be, for example, when data bits are exchanged during the data transfer, so that e.g. the data is changed first in the first direction and then back again in the second direction of the transfer. In that case, the receiver receives an information different from the initial information from the sender. However, the changed information will be changed again (and thus might be corrected) when it is read out, so that the information eventually received by sender again might ‘accidentally’ equal the initial information. In such a case, the fault will not be detected. Another error that cannot be found is an addressing fault. If e.g. the address on bus
20
is slightly off the address on bus
10
because of address miscalculations within the bridge
40
, the test device might still be able to receive the data and give it back again. In a real life system, wherein it is crucial that the data arrives correct and at the right place, this would cause an error.
SUMMARY OF THE INVENTION
It is an object of the present invention to further improve the validation of bus-based systems. The object is solved by the independent claims. Preferred embodiments are shown by the dependent claims.
In contrast to the conventional bi-directional data transmission scheme over the bus system for verifying purposes (as depicted by arrows I and II in FIG.
2
), the invention is based on a concept of a unidirectional test data transmission over the bus-based system to be validated.
An inventive testing system provides a sending unit and a receiving unit, both coupled to or by at least one bus within the bus-based system. For testing (verification or validation) purposes, a data generator of the sending unit sends a specified information to the receiving unit. The receiving unit (directly) compares the received information sent from the sending unit with an information generated by a data generator of the receiving unit, whereby the data generation of the receiving unit is in a defined relationship with the data generation of the sending unit. Thus, the (test) information only has to travel once through the bus-based system and can be assessed and validated directly at and by the receiving unit.
The defined relationship between the data (pattern) generation of the sending unit and the receiving unit can be provided in different (deterministic) ways. One way could be an algorithmic relationship in a way that the receiving unit generates a data pattern making use of common information or knowledge that is available to both units. Thus, both units can test the other unit's data pattern for correctness.
Preferably, the algorithmic relationship is based on the address of the rece

Affiliated with

Also associated with

Rating

Unidirectional verification of bus-based systems does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Unidirectional verification of bus-based systems, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Unidirectional verification of bus-based systems will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-3208793