Arithmetic-Logic Unit

State of the part

The Arithmetic Unit was mainly developed by Adrian, Florian, Ivo, and Lorenz. It is in working condition and has been integrated into the final build.

Acronyms

In the following description, we will use several abbreviations which are listed here:

Acronym	Description
ALU	Arithmetic-Logic Unit
CF	Carry Flag
ZF	Zero Flag
SF	Sign Flag
OF	Overflow Flag
ACCU	Accumulator Register
BUS

Overview

The Arithmetic Logic Unit (ALU) allows the CPU to perform basic arithmetic and logic 8-bit operations.
All ALU operations take two 8-bit operands A and B. A is passed on the bus, while B is read from the Latch register. Those operands are passed through two dedicated 4-bit ALU chips and the resulting 8-bit value is passed through the shifter. The output of the shifter is then used to calculate flags and may be stored in the latch and/or accu registers. The shifter can be disabled, in this case, it just passes its input through.
Flags need not be saved and can be discarded. The same is true for the resulting value of a calculation. Also, flags can be set "raw" (SET_FLAGS_RAW control line). In this case, the calculated flags are discarded and the lower bits of the shifter output are used instead. This is useful for pushf, popf, and for microarchitectural operations (i.e. saving the flags during interrupts).

Features

On a high-level, the ALU provides the following operations:

• A + B
• A - B
• B - A
• A ⊻ B (bitwise A xor B)
• A | B (bitwise A or B)
• A & B (bitwise A and B)
• A >> 1 (right shift by one bit)

Structure

The ALU can logically be divided into multiple sub-categories, each of which has its own separate page:

• ALU chips: Implementation of the binary arithmetic and logic operations.
• Flags: A register to store the flags and logic to calculate them.
• Latch & accu: Two registers directly connected to the shifter output.
• Shifter: Implementation of the right-shift by one.

Tips for Reproduction

• Watch out for chips and their input voltage which led to a lot of problems during the assembly and testing.
• Cheap (?) breadboards can be quite unreliable. Watch out for loose connections!
• Since our ALU is very compact, we recommend creating a targeted plan for assembly from the beginning. It becomes very confusing and bugs are difficult to find.
• We learned the hard way to keep our schematics and hardware build in sync. They drifted apart after a number of quick fixes in the hardware and caused confusion both inside of our group and with other groups.

Testing

We applied randomized differential testing with Flo's Amaranth hardware model. The model is functionally equivalent and largely implements the schematic directly. To make sure that our build is working correctly, we cross-checked the flags and registers after operations with random control lines set. These tests cover all legal ALU operations.
This approach allowed us to finalize the ISA and microcode design for ALU operations independently of the actual hardware build (!).

Adrian and Ivo spent a long time on hardware problems, which were very hard to find. Therefore, it is also useful to test individual components or chips, such as the shifter, with the help of an Arduino.

Errata

During testing we noticed a few bugs that we've worked around instead of bothering with a proper fix:

• We've accidentally swapped ALU operands in the build and worked around it with updated microcode.
• The ALU breadboards use a different bit order (0, 1, ... 7) than the rest of the build. We work around this with a twisted bus connector cable, but a unified bit order would've been nice.

Schematic

Fritzing Visualization