Bit-Slice Design: Controllers and ALUs

by Donnamaie E. White

Copyright © 1996, 2001, 2002, 2008 Donnamaie E. White

 
 

Preface

Table of Contents

1. Introduction

2. Simple Controllers

3. Adding Programming Support to the Controller

4. Refining the CCU

5. Evolution of the ALU

6. The ALU and Basic Arithmetic

7. Tying the System Together

Glossary

 

 

Introduction

Last Edit October 10, 1996; July 9, 2001


Selection of the Implementation

At the time that the original version of Bit-Slice Design Controllers and ALUs was written, the designer was faced with three basic choices in implementation:

  1. SSI/MSI hardwired logic --- called a discrete design
  2. 9080A/8080a (8-bit) or AmZ8000-In8086-M68000 (16-bit) MOS Fixed-instruction set (FIS) microprocessors. [When this book was first written, the 9080A/8080A 8-bit processor was the original example. Along with the In8086 and M68000 16-bit microprocessors. Really. Can we say Pentium? PowerPC 604? G3 Pentium III? 500MHz systems on a desktop? We've traveled a bit.]
  3. Microprogrammable or bit-slice architecture with the AMD 2900 Family or other similar family of devices. [The Am2900 bit-slice series was the one of choice on the early 1980s. ]
  4. Application-Specific solutions in ASIC or standard products where the devices are pre-designed or only slightly modifiable
There are a number of factors which could influence the decision as to which implementation is best for the application.

Note that this was written when designers made the component selections. Today's designers choose a process technology, specify the desired functionality in Verilog or VHDL, including IP (intellectual property) pre-designed blocks (design re-use) and use a design synthesis program (such as the Synopsis Design Compiler) makes the actual choices for implementation. Design Compiler works with pre-developed libraries such as DesignWare Foundation, which contains ALUs, adders, MUXs, controllers, and other devices in a selection of configurations based on several design optimization criteria.

There are a number of factors which influence the decision as to which implementation is best for the application.

Architecture

In terms of the design architecture, any FIS MOS microprocessor by definition has its own predefined internal architecture and this constrains the design options available. (Today's devices are not quite so limiting.)

An SSI/MSI implementation allows the designer to specify in complete, exact detail the architecture desired. (We cannot afford this luxury for the bulk of today's designs. It takes too much time, the circuits are too large and there are not enough designers.)

Custom-tailored designs are standard-cell designs today. The SSI-MSI components are macros in a library that can be combined to form any design required. Standard-cell designs (as of 1999) were one half of the ASIC market, having become as fast to design (thanks to design tools) and resulting in chips that might actually be smaller than a conventions metal-only ASIC. ASICs now use up to 6 layers of metalization for customization layers.

With bit-slice devices, some constraints are placed on the designer, but most of the system architecture is left to user definition via the selected interconnects and the microprogram. Bit-slice devices were, in fact, the first use of the design re-use concept. The individual block designs exist and are not re-designed. The interconnections, and how the blocks are used, are custom-tailored for the application.

This concept was followed by ASICs (1980-early 1990s), which allowed custom-tailored IC blocks to be developed specific to an application. Some designers have actually implemented some of the 2900 bit-slice devices in ASIC architecture.

Size

The real estate or board space (which translates into rack space, etc.) is often of concern in a design because of predefined space limitations. An FIS MOS microprocessor might have used 3-6 chips for a typical average-complexity control system, versus 100-500 chips for the same system implemented in SSI/MSI, and 30-60 chips for a compromise bit-slice design.

Word Length

The word length necessary for the system, whether s computer, controller, signal processor, or other, is usually known in advance of the design. FIS MOS microprocessors can be used where their word length is compatible with the design objective. MOS devices exist for 4-, 80 and 16-bit data [1981] word systems. Using SSI/MSI, any word length may be accommodated. Using bit-slice (the 2900 family was expandable in units of 4 bits), a wide variety of useful word size systems are possible. When bit-slice does not conveniently match, SSI/MSI can be used to "patch" the basic bit-slice design.

Instruction Set

The instruction set that the system under design must support has a major impact on the choice of implementation. The new design must support the existing instruction set.

Speed

Another design criteria or specification is the required speed of the design. SSI/MSI using Schottky TTL and the bit-slice (Am2900 family) can support systems with 125ns cycle times MOS microprocessors are slower, with approximate cycle times of 1-2 micro seconds. The newer MOS devices support 4-5 MHz clock speeds. The newer bit-slice devices are targeted for 100ns microcycle systems. [This was written in 1981 - we do build things a tad faster these days. CPUs run at 225-500MHz and ASIC (bipolar) runs at 200-400Mhz and up; communications chips passed 1 GHz some time back.]

Tradeoffs

Design tradeoffs are summarized in Table 1-1. Basically, where high speed, long word lengths, or critical instruction sets occur, MOS FIS cannot be used. If design-time - part count - board space restrictions also exist, or if production volume does not support the effort required to do an SSI/MSI design (considered the most difficult to do correctly in a given time frame), the bit-slice devices are the best choice. It should also be noted that a microprogrammed bit-slice design is upgradeable or changeable through a change of PROM or a reload of or patch to writeable control store, making it more flexible than a hardwired design.

Bit-slice devices are applied to three basic areas: machines with long control words, machines with special instruction sets, and high-speed machines. The best examples (1981) are signal processors, with a low volume per particular specification and which require high speed and a long data word, and emulators such as the one for the SIGMA 9 (32-bit word) and the one for the GE 400 (24-bit word), where software compatibility to the existing system at increased through-put is mandatory. Variable instruction-set minicomputers have also been developed using bit-slice which allows custom-tailored instruction sets to be microprogrammed around one fixed hardware implementation.

Table 1-1 Design Tradeoffs

TOPIC SSI/MSI Bit-SLice Devices FIS MOS Microprocessor
Architecture Any desired Pseudo-flexible Predesigned
Physical size
(typical)
500 chips 50 3-6
Word length Any desired Multiples of 2, 4 4, 8, 16 [32, 64]
Instruction set Any desired,
may be hardwired
Any desired,
may be microprogrammed
Constrained if speed
is a problem
Operating speed 100-200ns 100-200ns 1-2microsec.
Design time Long, slow
if done correctly
Fast Fast
Debug Difficult Development systems
aid process
Development systems
aid process
Documentation Tedious, often difficult Forced via microprogram Software is a major portion
Upgrades Up to a full redesign
may be required
Easily done,
can be pre-planned upgrade
Easily done (software)
Cost Highest Medium Lowest

Microprogramming

Microprogramming is to hardware design what structured programming is to software design. If a bipolar Schottky TTL machine is to be built, in bit-slice or in SSI/MSI or ASIC, its control should be done in structured microprogramming. First suggested by Wilkes as a methodical way of handling the unit of a system, it is recognized as the best approach. Why?

First, random sequential logic circuits are replaced by memory (writeable control store or ROM [read-only memory] or PROM [programmable ROM] or related devices). This results in or forces a more structured organization onto the design.

Second, when a unit is to be upgraded, a filed engineer can replace the appropriate PROM considerably easier than hardwiring and patching new components onto a crowded printed circuit board (PCB) with all of the associated pitfalls of such activity.

Third, an initial design can be done such that several variations exist simply by substituting one or more PROMs (changing the microprogram), and enhanced versions can be preplanned such that version B is constructed simply by adding a PROM or two to version A, simplifying production.

    Version B = Version A + more ROM

The basic units would contain sparsely populated PCBs with upgrades provided for in the existing etch and the connections ("hooks"). By adding PROMs or changing others, the system is expanded. This technique is also commonly used for RAM memory (read-write memory) expansion

The microprogram, documented in the definition file and in the assembly source file, serves as the principle documentation of the firmware. This, coupled with the modularity of the design as enforced by the use of microprogram control, provided a better opportunity for clearer documentation than multi-paged schematics can provide.

Structured microprogramming, including self-documenting definition files, were used on a major multi-engine microprogrammable mainframe design managed by this author. The code was so clear to follow that it passed over to test without problems and was found to save time and money during hardware design debug. The Air Force, which was reviewing this particular project, reviewed the coding procedures once, and decided that we knew what we were doing. The project set the standards by which other microprogramming projects would be reviewed.

Structured Microprogramming Works!

Last, diagnostic routines can be included in the PROMs supplied with the final system and can be called in by a field engineer through a test panel to be executed to aid debug. Some diagnostic routines could be microprogrammed into the system such that they are routinely executed in the normal running environment. For more severe testing, the normal PROM memory could be swapped with a special test memory simply by substituting PROMs.

For information about this file or to report problems in its use email donnamaie@sbcglobal.net
Copyright © September 1996, 1999, 2001, 2008 Donnamaie E. White WhitePubs Enterprises, Inc.