Error detection/correction and fault detection/recovery – Data processing system error or fault handling – Reliability and availability
Reexamination Certificate
1999-10-14
2003-01-21
Beausoleil, Robert (Department: 2184)
Error detection/correction and fault detection/recovery
Data processing system error or fault handling
Reliability and availability
C714S044000, C710S015000, C710S018000
Reexamination Certificate
active
06510532
ABSTRACT:
BACKGROUND OF THE INVENTION
For coherent and consistent operation, a data and command bus between otherwise disparate or independent remote elements—required to interact through exchange of data, interrogation and command or instructions—generally follows a prescribed behaviour pattern or protocol.
Protocol
The term ‘protocol’ is used herein to embrace a regime, or rule set, for regulating—in relation to communications traffic over a data highway or pathway—the nature of inter-connection or interface, the manner of interaction, and the content of information, interrogation or command, in data exchange or transfer elements or modules.
A protocol can adopt and prescribe various operational rules and standards—to which all physical connections with, and modes of communications over, the highway must defer, conform and adhere.
Thus, so-called SCSI and PCI, represent examples of common contemporary protocols for (parallel) bus configuration.
Bus
The term ‘bus’ is used herein to embrace any form of communications channel, data highway or pathway, particularly, but not exclusively, of a parallel, or multiple simultaneous, channel or line character or configuration.
That said, aspects of the invention may be applicable to other, for example serial, bus configurations.
Generally, a bus is a transmission line, commonly expressed or embodied as a hardware signal path, of physical conductors, whether (umbilical) cables or printed circuit board (PCB) conductor strips.
As such, a bus could find diverse application from, say, vehicle electrical supply engine, transmission and brake monitoring and command multiplex wiring harness, through to personal computers.
Hardware aside, a bus could be interrupted—or even part—constituted by—intermediate radio, optical fibre or infra-red links, provided an electrical signal can physically be picked up at some point (eg of bus termination).
Interface
Interaction between a bus, a primary command and control processor or central processing unit (CPU) and a (peripheral) device is through an interface—which itself must adhere to the bus protocol, but which enables physical (impedance or load) matching of otherwise incompatible elements, to allow converse therebetween.
The term ‘interface’ is used herein to embrace an interconnection, principally by physical interaction, with a bus.
(Interface) ASIC
It is common to use a dedicated or bespoke (semiconductor) device configuration, such as an ASIC (Application Specific Integrated Circuit), in an interface between a bus and a peripheral device.
Such a ‘dedicated’ ASIC is then instrumental in controlling interactions between a peripheral and the bus—and, in particular, (when the protocol so allows) in a peripheral ‘asserting’ and ‘de-asserting’ temporary control over the bus, as discussed later.
Some aspects of the present invention are concerned with supplementing, enhancing or reinforcing the use of such an interface ASIC, with additional functionality and memory, intimately to address local conditions:
at the driver output of the ASIC; and
input of the ASIC.
Bus or Interface Protocol
A bus or interface protocol commonly embraces various features of hardware and software. As such, a protocol may dictate or prescribe signal levels, or ranges, and allocate particular significance to certain signal sequences, or combinations.
According to bus or interface configuration, the protocol may also allocate particular (control) functions to certain individual signal lines or channels, or select multi-channel combinations.
Generally, a given bus protocol prescribes intended or envisaged ‘allowable’, or correct, bus instantaneous signal level conditions, on individual bus lines.
However, the protocol may not be overly specific upon allowable departures from recommended or set levels—and so upon what would constitute an ‘error’ or fault condition, (and as such one in need of correction or resolution), as discussed later.
A protocol may also define signal level transitions, or changes, and sequences. Regard might also be paid to the cumulative or combinatorial effect of signal levels.
Some, but not all, protocols may allow different peripheral devices temporarily to take command and control over, or to ‘assert’ the bus.
Should an error or fault condition arise, as described later, it is important to know (in a bus which so allows) which (peripheral) device is asserting the bus at the time, in order to pin-point the source of ‘deviant’ behaviour.
Some form of local error monitoring capability—as provided by aspects of the present invention, discussed later—is particularly advantageous when the protocol allows such peripheral device assertion.
Interrupt signals on the bus could preface hand-over and hand-back signal sequences, passing the bus over to other peripheral devices, or back to a centralised command CPU. Indeed in practice, in a computer system, the peripheral device(s) might well occupy more time cumulatively in charge of the bus than the CPU itself.
Hence the value of knowing which device is actively ‘asserting’ and which device(s) are ‘passive’ at any sampling instant. When not asserting the bus, a peripheral device is free to receive signals from, or to interrogate, signals upon the bus.
Generally, a device state will reflect signals detected on the bus, through an associated device interface.
In considering the interaction between a peripheral and the bus, separate or individual consideration must be given to:
the outflow of signal directives—in a bus ‘assertion’ or driving mode; and
the inflow of signals from the bus—in a passive reception or driven mode.
The passive mode is significant, since the peripheral can be commanded to change operational state or condition, in response to perceived bus signal changes.
Missed, or wrongly interpreted, bus signals can lead to a missed or skipped device state change and consequent disruption of device operational sequence in synchronism with the bus—and attendant degradation in peripheral performance.
Physically, there is a unique common point or node location, from or at which both outgoing and incoming signals may be encountered—for analysis of bus interactions and bus read-write errors associated with that peripheral.
A conventional self-contained bus analyser connected at a remote location (from the peripheral and its associated interface), simply cannot address or map that critical interface input-output node, which will enjoy an unique signal level profile.
Nor can a conventional bus analyser determine directly the operational state or phase of individual peripheral devices.
Thus bus signal condition—upon which a conventional bus analyser is critically dependent—is not uniform throughout the bus. Nor is bus signal condition necessarily indicative, either of local interface signal condition (for any given peripheral), or of the operational state of that peripheral.
The diagnostic ability of a conventional bus analyser is thus constrained—and inadequate for a complete diagnostic role.
Moreover, since a bus is effectively a transmission line, with inherent (characteristic) impedance losses throughout, it follows that relative ‘downstream’ or ‘upstream’ bus tappings cannot replicate a localised approach—as envisaged with aspects of the present invention. Nor can a remote bus analyser recognise state changes of individual peripherals.
Thus part of the performance—and thus error—mapping is incomplete, and so potentially inadequate, in the conventional remote error signal capture and diagnostic approach.
As a transmission line, the bus access interfaces and terminations can prove critical. Thus bus loads must be matched to the bus transmission line characteristics, for effective signal energy transfer. Mis-matching can lead to spurious signal reflections or echoes and attendant interpretation errors and disruption. Matching an external bus analyser to a bus can be problematic.
The character or nature and extremity or degree of errors that can be tolerated by a bus protocol is not generally well-specified. Not all protocol interpretations by peripherals, or indeed the bus con
Haper Lynne
Pelly Simon James
Beausoleil Robert
Hewlett--Packard Company
Wilson Yolanda L.
LandOfFree
Bus and/or interface local capture module for diagnostic... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Bus and/or interface local capture module for diagnostic..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Bus and/or interface local capture module for diagnostic... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3021809