Browse Prior Art Database

Hardware Timer Usage Assignment

IP.com Disclosure Number: IPCOM000114676D
Original Publication Date: 1995-Jan-01
Included in the Prior Art Database: 2005-Mar-29
Document File: 2 page(s) / 77K

Publishing Venue

IBM

Related People

Chen, CC: AUTHOR [+3]

Abstract

The hardware on our project provides microcode with four timers. A description of the areas where these timers have been useful in our object oriented project is disclosed.

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

Hardware Timer Usage Assignment

      The hardware on our project provides microcode with four
timers.  A description of the areas where these timers have been
useful in our object oriented project is disclosed.

      Our Object-Oriented Analysis (OOA) approach has three general
areas of code.  Process Input/Output (PIO) is the only area of code
that accesses hardware (including the timers).  This is for the
abstraction of hardware.  Applications are the actual objects that
are represented in the OOA.  The Software Architecture handles the
communication between the objects in the application, by managing the
sending of events.

Managing Multiple Timer Requests

      PIO will manage the timer requests.  At any given time, there
will be several timer requests contending for the same timer.  PIO
needs to keep track of several variables to manage the timers.  PIO
needs to store all of the pending requests in ascending order, so
that the next lowest timer value is easily accessible.  PIO must also
manage, for each request, how much time has elapsed since the request
was made.  This is due to the fact that, for a given timer request,
the actual hardware timer may elapse several times.

      Individual Timer Usage - The Support Module has four timers
available to microcode.  They will be used as follows:
  1.  Watch Dog Timer: This timer will be used by the software
       architecture.  The software architecture handles the
       communication between the various objects on the machine.  The
       architecture has a queue of events that are sent to the
objects,
       and needs to know (by using a timer) if events are no longer
       being sent properly.
      o  State Action Timer - The watch dog timer will be set to trip
          at a value selected to detect state action failures.  The
          timer is started just before the call to the application
          state action function and reset immediately upon return.
      o  Dispatcher Timer - The watch dog timer will be set to trip
at
          a value selected to detect a dispatcher failure or
deadlocked
          event queue.  The timer will be active in this mode
whenever
          it is not being used as a state act...