Browse Prior Art Database

Bus Hardware Diagnostic Interface

IP.com Disclosure Number: IPCOM000035826D
Original Publication Date: 1989-Aug-01
Included in the Prior Art Database: 2005-Jan-28
Document File: 3 page(s) / 73K

Publishing Venue

IBM

Related People

Clift, JR: AUTHOR [+2]

Abstract

For diagnostic purposes this article describes a technique for stimulating and extracting data from any computer system bus architecture which allows a direct memory access (DMA) type of function. The data connection is achieved through the use of an interface which connects two units in a master-slave arrangement.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 46% of the total text.

Page 1 of 3

Bus Hardware Diagnostic Interface

For diagnostic purposes this article describes a technique for stimulating and extracting data from any computer system bus architecture which allows a direct memory access (DMA) type of function. The data connection is achieved through the use of an interface which connects two units in a master-slave arrangement.

The ability to stimulate and monitor bus activity gives the user a window into the internal workings of the system under interrogation. Many micro/personal computers have some sort of power-on-self-test (POST) or diskette-based diagnostic. However, the ability of the machine to execute these diagnostics means that the machine is capable of initializing much of its internal structure. It is not at all uncommon to find that a machine has some sort of hardware failure which prevents it from running its diagnostics. Currently available logic analyzers on the market lack the ability to stimulate and interact with a bus under test, are costly and lack the ability to do any type of data processing on the collected data. A new diagnostic interface shown overcomes the deficiencies cited and adds features and flexibility to enhance the investigation of bus related data.

Referring to the figure, a block diagram is shown of an interface between a master and slave computer system. The master can be any processing machine running in its native mode of operation. The master supplies and receives data from the interface via an interconnect channel which can be either serial or parallel. The interface strobes data on and off the slave units bus at the proper time intervals. The slave represents a unit containing the bus structure under test. The size and number of buses requiring stimulation within the slave are accommodated through the interface design.

If a diagnostic flow chart requires random-access memory (RAM) and read- only memory (ROM) chips to be checked through substitution or software, it soon becomes evident that physical substitution offers a very limited approach since most components are soldered into boards. As for the self-contained/initiated software-testing approach, it is dependent upon the type of hardware failure being experienced, i.e., the POST dilemma mentioned. By merging the merits of both, the flexibility of a software-testing approach with the confidence of a hardware substitution approach, a method is provided for direct software to electrical/hardware connection through a master-slave arrangement. The interface can achieve this by isolating the code/test generation from the device under test. The following test sequence example explains one typical use of the hardware diagnostic interface.

Interface Diagnostic Technique: 1. The master instructs the interface to prepare for a machine cycle transfer. Information instructing the interface to do a read or write to the slave's bus is also transmitted. 2. The interface assembles all instruction data in a broadside bus image. 3....