Browse Prior Art Database

Pipeline Control in a Microcoded Processor

IP.com Disclosure Number: IPCOM000102326D
Original Publication Date: 1990-Nov-01
Included in the Prior Art Database: 2005-Mar-17
Document File: 8 page(s) / 373K

Publishing Venue

IBM

Related People

Funk, MR: AUTHOR [+6]

Abstract

This article describes a technique for improving the performance of a processor in a computer system utilizing a pipelined architecture. Many processors implement a pipeline by hardwiring a large portion of the instruction set. This has the effect of severely limiting the flexibility of the processor's instruction set interface. Further, due to the complexity of the hardware design required to create such a processor, the time from initial design to final product increases.

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

Pipeline Control in a Microcoded Processor

       This article describes a technique for improving the
performance of a processor in a computer system utilizing a pipelined
architecture.  Many processors implement a pipeline by hardwiring a
large portion of the instruction set.  This has the effect of
severely limiting the flexibility of the processor's instruction set
interface. Further, due to the complexity of the hardware design
required to create such a processor, the time from initial design to
final product increases.

      This article describes a means by which microcode can support
the early stages of a pipeline design
      -  to allow a flexible instruction interface,
      -  to allow early versions of the processor hardware for
software debug,
      -  to not require extensive hardwiring of instructions,
      -  to allow significant sharing of processor resources, and
      -  to still support the state-of-the-art instruction
pipelining.

      The assumed processor is a microcoded processor which
implements a complex and flexible instruction set.  This instruction
set is supported by microcode referred to as Horizontal MicroCode
(HMC).  The HMC interprets the instruction set of the processor.  The
HMC control words are executed by the hardware.

      A significant portion of the time required to develop a new
processor is the time required to assure that that processor is
error- free.  In addition, a significant period of the product
development time includes assuring that the software which runs on
this processor is also error-free. Therefore, it is advantageous to
deliver an error- free processor for internal use for software
development and test.  Fixing a processor hardware problem often
requires multiple months before fixed hardware is available.  On a
hardwired processor, all problems are hardware problems. This can
imply that software development and test can be delayed until the
processor problem has been corrected.  On a microcoded processor,
many of the hardware problems can be avoided by implementing the
processors instruction set in a way that does not use the failure
mode.  The effect is that the performance is less, but the internal
development and test of the supported software can continue.  The
failing hardware can be corrected in parallel with this effort to
gain back the lost performance.

      Many of the instructions supported by a processor follow a
similar set of steps as part of the instruction execution.  On a
processor supporting a Von Neumann architecture, the instructions
must appear to execute as sequential units of operation. Phrased
differently, each instruction must produce results which are
available for use by following instructions. However, in actual
implementation, the stages of the execution of sequential
instructions can overlap in time. This overlapped execution of the
execution stages of sequential instructions is called...