Browse Prior Art Database

Using CRC to Increase Data Integrity

IP.com Disclosure Number: IPCOM000111651D
Original Publication Date: 1994-Mar-01
Included in the Prior Art Database: 2005-Mar-26
Document File: 4 page(s) / 161K

Publishing Venue

IBM

Related People

Kulakowski, JE: AUTHOR [+3]

Abstract

The use of a personal computer as a controller in high-end systems is becoming more prevalent. A block diagram of such a system is shown in Fig. 1. In this example, a PS/2* is used as a controller for optical disk drives attached to a S/370 system.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 41% of the total text.

Using CRC to Increase Data Integrity

      The use of a personal computer as a controller in high-end
systems is becoming more prevalent.  A block diagram of such a system
is shown in Fig. 1.  In this example, a PS/2* is used as a controller
for optical disk drives attached to a S/370 system.

      For a write operation, data is transferred from the host over
the S370/OEMI channel to the S/370 attach card in the PS/2 and is
then moved to PS/2 memory.  After processing control information, the
data is moved to the SCSI attach card which provides the SCSI
interface for the optical drives.  From here data is transferred to
the drive, where the data is stored on an optical disk.  For a read
operation, this process is reversed.

      Although the PS/2 is low cost, it does not have the same level
of data integrity compared to other controllers attached to high-end
systems.  Typically, other controllers have additional hardware, such
as parity, to guard against loss of data.  Such errors which may
occur are flagged to allow restoration of the data through
retransmission to or from the host or device.  Given a PS/2
controller is going to be used in a high-end system, a mechanism is
needed to lower the probability that customer data will not be lost
or altered without being detected.  One solution is to generate CRC
at the host and check the CRC in the drive, and vice versa.

      To accomplish this, several things are needed, including CRC
generation and checking at the host and in the drive, a Mode Select
command to put the drive in the CRC Generation/Check mode, a
controller that maintains an association of CRC bytes to records, and
a drive that can generate and check CRC bytes.

      It is assumed that CRC can be generated and checked at the host
with either hardware or software.  An optical drive also needs the
same capability.  A block diagram of a typical optical drive
controller which resides internal to the drive is shown in Fig. 2.

      The microprocessor is the drive manager.  It controls the Disk
Controller and the Drive Interface.  It interprets the SCSI commands
and monitors the ECC Logic through the Disk Controller.  The Optical
Disk Controller (ODC) controls the ECC encoding, decoding and data
buffering process.  CRC logic has been added to the block diagram.
This logic is used to generate and append CRC data to be sent to the
host and to check CRC appended to data transferred from the host.  On
a write operation, the CRC generation and checking logic generates
CRC for the data received from the host and compares it to the CRC
sent from the host.  For a read operation, a CRC is generated for the
data read from the disk and sent to the host so that the host can
perform a CRC comparison on receipt of the data.

      Low-end systems such as PS/2-based systems may not need the
data integrity required for high-end systems or want to provide the
over- head in the host to generate and check...