Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Diverse Read Error Recovery Options Encapsulated as Data

IP.com Disclosure Number: IPCOM000116680D
Original Publication Date: 1995-Oct-01
Included in the Prior Art Database: 2005-Mar-31
Document File: 6 page(s) / 226K

Publishing Venue

IBM

Related People

Nylander-Hill, PR: AUTHOR

Abstract

With the advancement of tape technology, there are ever increasing complexities involved in microcode management of errors related to new tape formats and media characteristics, parametized dataflow digital and analog design, and varying mechanical constraints. As a consequence of concerns in all of these areas, there has been a proliferation of "programmable" hardware design allowing for maximum flexibility in machine bringup, functionality, diagnostic aids, and inline read error recovery.

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

Diverse Read Error Recovery Options Encapsulated as Data

      With the advancement of tape technology, there are ever
increasing complexities involved in microcode management of errors
related to new tape formats and media characteristics, parametized
dataflow digital and analog design, and varying mechanical
constraints.  As a consequence of concerns in all of these areas,
there has been a proliferation of "programmable" hardware design
allowing for maximum flexibility in machine bringup, functionality,
diagnostic aids, and inline read error recovery.

      This flexibility is powerful in the overall view of the tape
product, but introduces an almost unmanageable number of options
available for use in read error recovery.  Given all the options,
combinations and permutations of the hardware base operating points
across the subsystem, the microcode involved in defining and
selecting from this set can easily get unmanageable.  It also becomes
difficult to define rational limits to error recovery.

      In approaching this dilema, several logical abstractions were
applied to the general problem of read error recovery utilizing a
seemingly endless variation of hardware operating parameters to a
reasonable extent.  First, hardware variations were grouped into two
classes:
  1.  Variations which would be useful in solving block acquisition
       errors (problems in detection of a block or with the track
       following servo)
  2.  Variations which would be useful in solving data correction
       errors (the block can be found, but exceeds the internal error
       correction power of the dataflow)

      Secondly, it was decided to isolate what was being done
procedurally from any hardware variations.  This was achieved by
encapsulating all the possible hardware options and variations into
data structures accessable by microcode.  Microcode functions are
invoked to change the operating parameters and to leave "tracks" of
what has been done so that subsequent invocations of these functions
don't repeat any settings.  The microcode state machine controlling
read error recovery is not aware of changing hardware parameters.  It
is merely concerned with the task of re-reading the block in error
and in determining the direction to re-read it in (forward or
backward).  In this manner, any variations in desired hardware
parameter settings during read error recovery are isolated to data
table modifications, leaving microcode logic unimpacted.

      The data structure was developed using the analogy of a
deck of cards.  Four decks of cards were defined to deal with 3
general
scenarios:
  SCENARIO 1 - ACQ_PES

      Track Following Servo is functional, and the block in question
cannot be found or can only be partially found.  The Servo System
Position Error feedback Signal (PES) may have its control offsets
adjusted to assist in finding the block.
  Applicable Decks: ACQ_DECK, IPS_DECK...