Browse Prior Art Database

Single-Thread Design Use on an Interrupt Driven System for Initial Microcode Load

IP.com Disclosure Number: IPCOM000036087D
Original Publication Date: 1989-Sep-01
Included in the Prior Art Database: 2005-Jan-28
Document File: 5 page(s) / 135K

Publishing Venue

IBM

Related People

Thompson, RG: AUTHOR

Abstract

The following technique makes IML/ISL (Initial Microcode Load/Initial Software Load) as reliable and fast as possible to bring the attached system to a reliable usable state as soon as possible by using a dedicated single thread environment to focus all the attention of the processor to the task of completing the IML/ISL first. (Image Omitted)

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 53% of the total text.

Page 1 of 5

Single-Thread Design Use on an Interrupt Driven System for Initial Microcode Load

The following technique makes IML/ISL (Initial Microcode Load/Initial Software Load) as reliable and fast as possible to bring the attached system to a reliable usable state as soon as possible by using a dedicated single thread environment to focus all the attention of the processor to the task of completing the IML/ISL first.

(Image Omitted)

Waiting until the system requests an ISL from the card using a particular load source (or group of potential load sources) will ensure that the ISL request is immediately attended to when the system does the request. No action to the potential load sources will be done while the card is idle. Once the request has been initiated for a particular device all other devices are degated (shut off the bus) to ensure that the load source does not have to compete for the bus with the other devices and that the other devices (that may be broken) cannot influence the IML/ISL in any way. If the card is processing a request, no new requests will be processed without a physical level reset. This will ensure that the "single thread" treatment of the device cannot be interrupted, or started in an unknown state. The key difference with the single thread hardware monitor compared to a normal hardware monitor is that the single thread never releases control of the processor and monitors the hardware for good and bad status.

(Image Omitted)

The normal hardware monitor will initiate the request, then go into an idle state waiting for the hardware to give a stimulus for the operation completion. During the idle state of the normal hardware monitor, other work can be done, such as other requests to other devices, etc.

Fig. 1 shows details of the flow for a single-thread hardware monitor. Fig. 2 is a logical view of card requests requiring device interaction. Fig. 3 is a device view of the IML/ISL process.

A failure on any of the steps on the way to getting the IOP loaded that is not recoverable will cause the ISL/IML process to stop for that device and save pertinent failure information.

During Initial Microcode Load of a system, a highly reliable source must be used to bring the system to a usable state. If several devices are attached, the non load source devices should not slow down or prevent the IML from being successful.

If the load source is broken, it must be reported as broken in the most descriptive manner possible.

Cards attached to systems are built in a manner that will provide a reliable high-speed method of doing work. The method where the hardware interfaces to

1

Page 2 of 5

the microcode with an interrupt-driven processor is the most commonly used method. This will allow operations to overlap to gain maximum performance.

The problem with this is that control is lost if any interrupts are lost or misqueued. The failure symptom is a "hang" condition that will last forever.

The following considerations are important to...