Browse Prior Art Database

Read Only Storage Failure Checking Technique

IP.com Disclosure Number: IPCOM000084750D
Original Publication Date: 1976-Jan-01
Included in the Prior Art Database: 2005-Mar-02
Document File: 2 page(s) / 14K

Publishing Venue

IBM

Related People

Blevins, PR: AUTHOR

Abstract

Many read-only storage (ROS) modules do not implement the hardware odd/even parity function for the bytes within the ROS memory. The prime otivating constraint has been the judged trade off between hardware cost nd the required product reliability. However, recent studies have shown that during a typical seven-year machine life that many of the ROS subsystems are expected to fail.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 58% of the total text.

Page 1 of 2

Read Only Storage Failure Checking Technique

Many read-only storage (ROS) modules do not implement the hardware odd/even parity function for the bytes within the ROS memory. The prime otivating constraint has been the judged trade off between hardware cost nd the required product reliability. However, recent studies have shown that during a typical seven-year machine life that many of the ROS subsystems are expected to fail.

To alleviate both the generated product reliability exposure and the cost/performance disadvantages of a hardware parity function, a software parity function using a cyclic redundancy check character (CRC) can be used.

During ROS module development each module is formatted as follows:
Information Field - Consists of all module bytes except those required for the

Block Check Field.

Block Check Field - Consists of bytes required to store the CRC of the selected

generator polynominal.

Code Field - Concatenation of the Information Field and the Block Check Field.

For a 4K-byte module and using a generator polynominal g(x) = X/16/ + X/12/ + X/5/ + 1, the Information Field consists of 4094 bytes while the Block Check Field consists of only 2 bytes.

During the ROS module release, the CRC required for a given ROS module Block Check Field is generated as a function of the assigned contents of the corresponding Information Field by an encoder routine.

Note that since the ROS module can conveniently be accessed in orders other than sequential, the order of the fields may be arbitrarily assigned. For example, the Block Check Field might be embedded between a partitioned Infornation Field. Obviously, appropriate corrections must be made in the algorithms which compute or encode the CRC. However, generation of the CRC by the decoder is independent of the location of the Block Check Field. Such nonsequential field ordering allows ROS modules containing tables, etc., to be easily supported. Additionally, the independence of the decoder with respect to the Block Check Field location allows mixed field orderings to be supported by a single decoder.

During system operation, parity checking can be performed by a software ROS check routine. This software routine will dynamically and continuously compute the CRC for each individual module with...