Browse Prior Art Database

Functional Isolation Strategy for Hardware-Specific, Multi-Processor Tasking

IP.com Disclosure Number: IPCOM000118861D
Original Publication Date: 1997-Aug-01
Included in the Prior Art Database: 2005-Apr-01
Document File: 4 page(s) / 167K

Publishing Venue

IBM

Related People

Hamilton, RA: AUTHOR [+4]

Abstract

Disclosed is a method for extending the flexibility of hardware interface systems. This method allows interface firmware or software to communicate with attached hardware, even if it has no detailed knowledge of the hardware specifics or purposes.

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

Functional Isolation Strategy for Hardware-Specific, Multi-Processor
Tasking

      Disclosed is a method for extending the flexibility of hardware
interface systems.  This method allows interface firmware or software
to communicate with attached hardware, even if it has no detailed
knowledge of the hardware specifics or purposes.

Note: In this discussion, the term "application processor" refers to
a processor on which an application resides.  This application will
have the need to interact with peripheral hardware.  The term
"interface processor" refers to the processor which has low-level
hardware interface  capabilities, and which is charged with some
portion of enacting the application processor's task.  "Hardware
peripheral" refers to any hardware, connected to the interface
processor, which is necessary for  the accomplishment of the
application processor's task (Fig. 1). Further  note that any
connection of two or more computers could permit the exchange of
roles:  any interconnected processor could serve as the application
processor and any as the interface processor, either at different
times or simultaneously.

      As computer systems become increasingly complex, the need to
partition peripheral tasks to distinct and often disparate processors
abounds.  The processor configuration may vary, as they take the form
of separate CPUs within the same enclosure, systems spread across
vast networks, or other models.  In any case, the processors often
have different physical peripherals around them, which are sometimes
needed by other applications not residing explicitly on the adjacent
processor.  Note that the tasks under investigation here are NOT the
distributed sharing of computational resources; rather, this deals
with the cases where one processor needs to pass information to, or
receive information from, a remote hardware peripheral best accessed
via the interface processor.

      One of the fundamental problems encountered as such access
requests are distributed is that of how to best utilize both the
interface and application processors in the passing of such data to
and from the peripheral hardware.  Of particular interest are the
cases where  the application processor has overall knowledge of the
task to be accomplished AND knowledge of high-level hardware
specifics.  The interface processor may have the resources to
interface with the queried  hardware but may have no knowledge of the
high-level task or the overall  purpose of the peripheral hardware.
An embodiment of this problem involves the RS/6000* system processor
(the application processor), which  has a need to communicate with
physical devices such as thermal sensors,  microcontrollers, and hard
disk monitors in an external cabinet.  The need is driven by a daemon
running on the primary processor, tasked with  monitoring these
devices.  As the primary processor has no direct path to  reach the
external cabinet, it must rely on an inte...