The idea for this project came about during a week of freezing winter arctic events here in Austin, Texas, with a failed power grid (as well as the Texas government), while keeping close to a gas fireplace, the only source of heat and light, for a couple of days. With a weak internet over a phone data line, I could only do some preliminary searches and mainly work out various details on a writing pad, growing feeling that the project may be personally exciting and practically doable.

It took a long time, but this FPGA Calculator is now finished and I am really happy with how well it turned out.

How do calculators work?

You press a few buttons, choose a function, and you get your result back. But what is the technology and the algorithms at work behind its computation? For sure we can read about that, but to fully internalize all the tradeoffs and corner cases, we need to embark on designing one. To create one from scratch, and by that, I mean it – not using emulators and pre-existing ROMs, or even a powerful microcontroller, will provide us with that innate knowledge. We should start with a blank drawing pad onto which we would sketch our design from the very first gate and build on top of it.

Let’s dive in.

Architectural Decisions

We will have to make certain implementation decisions, many of which are exclusive, each one with its own tradeoff.

Internal number representation

The number format internally used for computation:

1. BCD (binary-coded decimal), where each nibble stores one decimal digit of mantissa and exponent
   • More cumbersome operations on individual digits.
2. Floating point representation
   • Needs conversion to and from decimal values.
   • Suffers from conversion errors.

The drawbacks of BCD are more complex routines and slightly lower compactness; the advantage is the perfect representation of decimal magnitudes, as opposed to pure binary, which cannot represent exactly some of them; also that there are very refined algorithms for both ordinary arithmetic and transcendental functions.

Digits of precision

How many digits of precision do we want to carry? Here we need to be very careful not to show more numbers than we can compute exactly (with the exception of the last, rounding, digit). A calculator that displays incorrect values is much worse than one that displays only a few, but correct, digits.

1. BCD may need internally wider registers to compute trailing, rounding digit, so it uses more digits for computation that it shows in the result (ex. HP41:10 digits, 13 internally; HP71: 12 digits, 15 internally)
2. Binary (floating point) may be off when rounding certain values that can’t be represented exactly in a decimal system. This notation may follow a standard like IEEE 754 or implement its own partitioning of mantissa and exponent values.

A major decision to be made is whether to use one of many rounding modes or simply truncate the result. Each rounding mode has its share of advantages and drawbacks, or it’s suitable for a particular use (financial, scientific, etc.)

Calculation notation

1. RPN (Reverse Polish Notation)
   • It does not have parenthesis, it uses stack and computes intermediate values immediately.
   • It might not have “=” key but have a “push to stack” key (often called “ENTER”).
   • In general, this is quicker, and it needs fewer keystrokes.
2. Algebraic (or infix notation)
   • It uses parenthesis and knows about operator precedence.
   • In practice, it requires more cognitive effort.
   • Has “=” key that evaluates a complete equation

Programmable vs. fixed function

1. Programmable calculators have larger non-volatile storage where they store user input sequence (a program) and provide additional functions for execution control (value testing, looping, etc.)
2. More sophisticated machines are more akin to full-blown computers and have a high-level language interpreter (like BASIC)

Gates vs. Microcode

How much is done in hardware (in gates) vs. in microcode (ROM)? Here, by gates, I mean strictly specialized digital logic dedicated to computing arithmetic functions. Options are listed from one extreme to another:

1. Everything is done in gates (no ROM) (those would be some early, or very simple, calculators).
2. Very minimal basic operations in gates; most functions are in code (ex. HP’s Saturn CPU).
3. Most computations are done in gates, only the most complex functions in code.
4. Everything is done in code, there is only minimal necessary functionality in gates (ex. Z80-based calculators).

Algorithms

What algorithms are used to compute higher-level functions?

1. Taylor series
2. CORDIC
3. Chebyshev polynomials
4. Other series and algorithms

Series and polynomials are, in general, estimators. With more iterations, they converge to a theoretically exact result. There is a tradeoff between the number of iterations (that is, the speed), and the precision. For many higher-order functions, it is hard, or even impossible, to specify the precision across all possible input values.

Keypad

The keypad (or keyboard), is the primary interface with the user. Arguably, the best keypads are those made by HP for their line of calculators. They use double-molded plastic and a proprietary spring system.

On the other end of the keyboard technology are super-cheap membrane keypads, such are those used in budget home computers by Sinclair and many $1 calculators from China.

A small step up is the membrane sheets pushed by extruded rubber/molded keyboard overlays. They provide more tactile feedback. They are very common since they are inexpensive and provide a good balance of price vs how they feel. Your TV remote controls, thermostats, and most home appliances would have those.

There are two kinds of actuators that could be used under the rubber overlay.

The first one could be traditional PCB-mounted push buttons. Since those have a thickness, we would make another PCB sheet, acting as a spacer, with round holes where the buttons are, providing that clearance. If the clearance is not sufficient, we could raise that board up with some spacers.

Another option would be to use small, tactile dome switches. Their use is uncommon among hobbyists. Those switches are made of tiny pieces of domed conductive material (sometimes gold-plated) that bend as you press to make contact in the middle. They make a quite satisfying tactile “click.” The domes should not be soldered to the board since that would stiffen their elasticity and make them prone to failure, so they are either physically held by some template or they are glued on top (frequently they are sold with an adhesive sheet).

Surprisingly, although these cost only a fraction of a cent to manufacture, US electronics shops like Mouser sell them for 50 cents each! If you shop from Alibaba (China), you can get a bag of 500 for $10.

A variation of those dome switches have a hole in the middle, where you can PCB mount an LED behind it.

There is another kind of “switches”, or better, the lack of them. With the advent of microcontrollers and their special-purpose IO blocks, many now offer touch detection. That “switch” does not need anything else besides access to an open trace. The controller registers even the slightest capacitive touch of a finger.

Modes of Operation

Besides decimal, we could also support hex and binary numbering system, and we may as well throw in octal. We could, of course, architect it to support any arbitrary base, but there is little practical use for something like that.

If we do that, we need a few additional keys: besides the standard numerical “0”…”9”, we may also need “A”, “B”, “C”, “D”, “E”, and “F”. We also need to assign mode switching functions to keys.

Consequently, we should also add a couple of bitwise operations to go with these modes. At the very least, AND, OR, XOR, NOR, and SHIFT (left or right) operations come to mind.
 

The CPU

The heart of our calculator will be a small micro-sequencer implemented in FPGA. The access to external devices such are keypad and display, should be handled as a memory-mapped IO.

As a design decision, keypad scanning could be a separate and independent module that takes care of debouncing and simply queues key codes to an internal FIFO.

Similarly, the LCD driver could also be a separate module that initializes the display and implements some simple protocol to control writing the characters.

The exact details should be more obvious once we start writing a concrete architectural document.

Summary

In this first article, I tried to provide an overview of various options we can select from. Other major things are still being left out (like the power source) because we are still wrapping our heads around the complete project. As I was writing, some things did start to crystalize in terms of dependency and trade-offs (“if you decide to implement it this way, then you can’t do that”) and feasibility. Still, anything is on the table.

Next article: A Calculator (2): Basic Four Functions – Baltazar Studios

Interesting Reads

• HP Saturn processor:  HP Saturn – Wikipedia
• Multi-cycle sequencer:  Appendix D Mapping Control to Hardware (tufts.edu)
• The Spectrum ROM Disassembly (Uses Chebyshev polynomials for trig functions):www.primrosebank.net/computers/zxspectrum/docs/CompleteSpectrumROMDisassemblyThe.pdf

• How HP calculates CORDIC: www.jacques-laporte.org/TheSecretOfTheAlgorithms.htm
• How CORDIC works:  Cordic for Dummies (jacques-laporte.org)
• HP35 on Arduino (with source): www.jacques-laporte.org/TheSecretOfTheAlgorithms.htm
• Calculator forensic:  Calculator Forensics (rskey.org)

This set of articles explains how HP calculators calculate various functions:

• SQRT:  1977 , Volume , Issue May-1977 (hp.com)
• Trig:  1977 , Volume , Issue June-1977 (hp.com)
• Inv trig.:  1977 , Volume , Issue Nov-1977 (hp.com)
• Logs:  1978 , Volume , Issue April-1978 (hp.com)

The post A Calculator appeared first on Baltazar Studios.