Browse Prior Art Database

Method for Handling Microcode Dependencies On Hardware Levels

IP.com Disclosure Number: IPCOM000099731D
Original Publication Date: 1990-Feb-01
Included in the Prior Art Database: 2005-Mar-15
Document File: 3 page(s) / 99K

Publishing Venue

IBM

Related People

Fawcett, BW: AUTHOR [+4]

Abstract

Described is a structure that allows controlling microcode to remain at an average complexity level regardless of how many independent hardware cards are involved. Service processor (SP) microcode is dependent upon a variety of hardware card levels because of the nature of the functions it provides. This results in a combinatorial explosion of the number of hardware sets that must be supported by the microcode, since the multiple hardware card levels are independent of each other. This problem is addressed by a method illustrated in the figures.

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

Method for Handling Microcode Dependencies On Hardware Levels

       Described is a structure that allows controlling
microcode to remain at an average complexity level regardless of how
many independent hardware cards are involved.  Service processor (SP)
microcode is dependent upon a variety of hardware card levels because
of the nature of the functions it provides.  This results in a
combinatorial explosion of the number of hardware sets that must be
supported by the microcode, since the multiple hardware card levels
are independent of each other.  This problem is addressed by a method
illustrated in the figures.

      Fig. 1 illustrates hardware structure.  To avoid the
combinatorial explosion impact on the microcode which runs in the SP
card 1, the related microcode is divided into multiple loads. There
is one overall driver load (SP load 5) and separate operation loads
(op loads 6) for each hardware card that is operated on a processor
2, system bus adapter (SBA) 3, and memory cards 4.

      Fig. 2 illustrates software structure.  SP load 5 performs all
of the high-level functions and system interfacing, while individual
op loads 6 perform the detailed hardware interfacing.  This keeps the
SP load independent of the hardware level specifics.

      For the hardware cards that exist multiple times on one system,
there must be the capability of having the individual cards at
different levels.  For example, the first processor may be at level
1.0, while the second processor may be at level 3.0.  A
pointer-access scheme is used to keep the algorithm simple in the SP
load. Each of the hardware cards has a pointer in a pointer table 7
to op load 6 for that card.  Any code that requires an operation on a
particular hardware card must utilize the procedures that exist in
that card's op load 6.  This is true whether the code that requires
the operation is in SP...