Bit-Slice Design: Controllers and ALUs

by Donnamaie E. White

Copyright © 1996, 2001, 2002 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 Ocober 10, 1996; July 9, 2001


Language Interrelationships

Programming classes relate source code - written by the user in some programming language - to object code - the machine level - machine executable instructions - via an assembler or compiler. A compiler is a software program that translates a high-level (compiler level) language program into object code. An assembler is a software program that translates an assembly-level source program into object code. There are usually several compilers and one assembler per computer system.

Compilers translate at an average ratio of four to one (four machine instructions per source instruction [as in FORTRAN IV]) or higher (six to one for FORTRAN VI). Assemblers can be very nearly one to one, with assembly statements being a mnemonic form of the bit pattern machine instruction. In both cases, software is processed by software to produce software, as shown in Figure 1-3.

Figure 1-3 Language relationships

Input Program Produces
Basic source code
software
Basic Compiler Program
software
Machine-Level Instructions
software
Assembly source code
software
Assembler Program
software
Machine-Level Instructions
software
Machine-Level Instructions
software
Microprogram
firmware
Physical Control signals to system
hardware

High-Level Language

High-level languages are fairly free format, i.e., they have few columnar placement restrictions on the coding form (free-form), use pseudo-English mnemonics (LET, GOTO, IF), and have prewritten functions. Their capabilities include arrays, loops, branches and subroutines, with the emphasis on structured programming support with IF-THEN-ELSE, CASE and PROCEDURE statements.

Assembly Level Language

Assembly-level languages have a more restricted format, require a precise data definition, may involve the programmer in program placement in memory, and use mnemonics for instructions but have more of them. Most instructions or statements are restricted to one operation - hence the approximate one to one translation ratio. The assembly level programmer in general must know more about the machine being used than the programmer who writes in FORTRAN or BASIC.

Machine Level Language

Machine-level languages are the closest to the system of the software level languages. They are usually written using an encoding of instructions, data and addresses in either octal or hexadecimal notation, are more tedious to construct and debug and are more restrictive in the format required than the assembly level languages. They can require more specific detail from the programmer, depending on the complexity of the system being programmed.

Microprogramming

The machine level instructions are what the computer control unit (the CCU) receives. In a microprogrammed machine, each machine level instruction (referred to as a macroinstruction) is decoded and a microroutine is addressed which, as it executes, sends the required physical control signals in their proper sequence to the rest of the system. This is where the software instruction via a firmware microprogram is converted into hardware activity.

Microprogram Storage

The various software programs will vary from hour to hour, or more often, and their data will vary; therefore read-write or RAM memory is required as their storage area. The microprogram, however, will usually remain the same. There are a few machines - the Burroughs 1700, for example - that loaded a different microprogram for each of several specific application languages.

Where one microprogram is to be used by the system, ROMs (high-production) or PROMs (lower production, prototype) are used for the microprogram memory. Such systems are called microprogrammed systems.

When a microprogram may be replaced by another, for example, to emulate another machine or to do a diagnostic run, then either a separate read-write memory, called a writable control store (WCS), or part of the system main memory is used as the microprogram memory with minifloppies, tape cartridges, or an area of main memory as the auxiliary storage for the microprograms.

The alterability is attractive for special application systems such as experimentation control. Writable control storage is also useful for prototype systems and is present on development systems for flexibility. Systems with alterable microprograms are called microprogrammable systems.

Throughout the remainder of this text, the microprogram control memory will be assumed to be a PROM memory for the sake of simplicity.

Format

Each machine-level instruction is in the form of an opcode and operands. There may be several different formats for the instructions in any one machine. These instructions are decoded by the control unit, and the decoding produces an address which is used to access the microprogram memory.

The microroutine for the individual machine or macroinstruction is called into execution and may be one or more microinstructions in length. (A microinstruction will be assumed to execute in one microcycle, also for simplicity.)

Each microinstruction field directs or controls one or more specific hardware elements in the system. Every time that a particular machine instruction occurs, the same microroutine is executed. The particular sequencing of the available microroutines constitutes the execution of a specific program.

Machine level language is very close to the hardware and has a very constrained format. It uses no mnemonics and requires that everything be specified by the programmer, including program address and data addresses. A sample machine instruction is shown in Figure 1-4A. More than one machine instruction format usually exists for a given system. The machine decodes which format it is using for part of the microinstruction via the content of other certain specific fields.


Figure 1-4 sample formats (A) sample machine level instruction (register addressing) (B)sample microprogram instruction (Am2900 family). Address (adr), condition code (CC), destination address (Dest), instruction (Instr), R1 and R2 are operands.

Figure 1-4A Machine Level Instruction

Op Code Destination
Register
R1
Source
Register
R2
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

Figure 1-4B Microprogram Instruction

Branch
Address
Am2910
INST
CC
MUX
IR
LD
Am2903
A and B
Am2903
Source
Am2903
ALU
Am2903
Dest
Status
Load
Shift
MUX
etc.


Microprogramming is done in the format or formats designed by the programmer. Once chosen, the format becomes fixed. Each field controls a specific hardware unit or units and the possible bit patterns for each field are determined by the signals required by the hardware units being controlled. Simple, short microprograms can be recorded in bit string fashion and prototype PROMs created using manually operated PROM burners. A sample microinstruction format is shown in Figure 1-4B. More than one microinstruction format can exist for a given microprogram. When two or more exist, extra bits must be added to the microword and these are assigned the task of signaling the controller as to which format is being decoded.

Development systems

Longer microprograms (more than 32 microwords in length or with microwords more than 16 bits wide) are better handled with a development system. These systems allow each field to be defined in mnemonics, which is a documentation aid. Once the fields are thus defined, the microcode (microprogram, microroutines, microinstructions) can be written in mnemonics, more or less in a pseudo-assembly language (called a meta language) providing human-readable self-documenting code in the process. The development system then may be used to assemble the microprogram and create the input to an automated PROM burner.

The development systems allow prototype hardware to be connected to them, and with the prototype microprogram load in the writable control store of the development system, the development system can be used to debug hardware and firmware in parallel. The WCS is used to replace the microprogram control store of the prototype system. FOr the 2900 Family, the development system is Advanced Micro Computer's AmSYS 29TM. (Neither Advanced Micro Systems - a Seimens-AMD venture - nor the AmSYS29 survives.)

Microprogramming is the programming level closest to the hardware, and the microprogrammer must know everything about each of the pieces of hardware which are to be controlled.

The trade-off here is between the detail level of the programming and the power and the control of the hardware that is possible. The actual number of microroutines required is a function of the number of machine-level instructions that the system is to recognize.

For an average computer (circa 1985), there would be about four microinstructions per machine instruction, with the minimum being 1 and the maximum at 16. The average varies with the application.

Figure 1-5 gives the relative relationships between the ease of programming and the level of control provided by each of the language levels. C+ and its derivatives evolved because of the need to have access to machine-level control of the hardware while still being able to describe algorithms in a higher-level programming code, a hybrid of both worlds.

Figure 1-5 Language interrelationships. Requires a detailed knowledge of the hardware, time to write the program and power and control of the hardware.

High-Level
Language
Assembly-Level
Language
Pseudo-assembly
Language
Machine
Language
Microcode
Decr <---------------------------------- --------------------------------------- -------------------> Incr

For information about this file or to report problems in its use email dew@Donnamaie.com

Copyright © September 1996, 1999, 2001, 2002 Donnamaie E. White White Enterprises

CST Webinar Series



Internet Business Systems © 2016 Internet Business Systems, Inc.
595 Millich Dr., Suite 216, Campbell, CA 95008
+1 (408)-337-6870 — Contact Us, or visit our other sites:
AECCafe - Architectural Design and Engineering TechJobsCafe - Technical Jobs and Resumes GISCafe - Geographical Information Services  MCADCafe - Mechanical Design and Engineering ShareCG - Share Computer Graphic (CG) Animation, 3D Art and 3D Models
  Privacy Policy