Browse Prior Art Database

High Availability, Self Checking Refresh Controller

IP.com Disclosure Number: IPCOM000108785D
Original Publication Date: 1992-Jun-01
Included in the Prior Art Database: 2005-Mar-22
Document File: 2 page(s) / 86K

Publishing Venue

IBM

Related People

Drehmel, RA: AUTHOR [+4]

Abstract

A main storage refresh controller completely implemented in hardware which can recover from and track intermittent errors is disclosed. The controller also contains self-checking logic to verify that it is working within the specifications of the memory technology.

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

High Availability, Self Checking Refresh Controller

       A main storage refresh controller completely implemented
in hardware which can recover from and track intermittent errors is
disclosed.  The controller also contains self-checking logic to
verify that it is working within the specifications of the memory
technology.

      The controller was implemented completely in hardware and does
not require microcode intervention or programming. The error
recovery, tracking, and refresh verification run at all times the
memory control chip is powered on.  The intermittent error (IE)
handling and tracking parts of the controller are closely tied
together, while refresh verification exists completely separate.  The
CAS-before-RAS method of refresh was used in this design.

      The key concept is that the controller permits one retry of a
refresh when an error occurs while performing a refresh.  The figure
describes the process followed if an error occurs while a refresh is
in progress.  When an error occurs, the controller immediately
branches to an error psuedo-state (EPS).  The EPS controls the
loading of 2 error latches which keep track of the number of errors.
Each time the sequencer enters EPS, a first error latch, FIRERR, is
loaded.  If the sequencer enters EPS and FIRERR is already set, a
second error latch, SECERR, is loaded.  EPS then causes a transition
to states that maintain the RAS/CAS active/inactive requirements
specified by the DRAM technology.  These states are needed because an
error could occur at any time and the error handler does not know
what value RAS/CAS has.  The FIRERR and SECERR latches are then used
to decide which states to execute next.  If only the F...