# Introduction

## State, evolving the state

After Round 3 we now have a fair bit of insight into combinational logic and what it can do. Yet, combinational logic appears fairly restrictive. We can design our circuits to be configurable, but this appears to be nowhere near the level of versatility that one would expect from a programmable computer. Something must be missing from the big picture.

Say, think about a simple pocket calculator (or the calculator app in your handheld device). Suppose you have a list of 100 numbers whose sum you need to compute. Using the calculator, you can add up the numbers by keying them into the calculator, one number at a time. The machine maintains the sum and evolves it as you key in the numbers.

What we appear to be missing is the ability to maintain a state, and the ability to evolve that state.

Let us consider another, even more elementary example.

Let us think about a (binary) counter device that adds one to a count every time you push a button:

Circuit-wise we of course know how to design an incrementer circuit in combinational logic (recall Round 3), so it would appear like we should be in good shape to arrive at a counter device. So how do we do it?

## Feedback

If you think about it a little, to turn an incrementer into a counter it suffices to feed the output back to the input. That is, whenever the button is pushed, we set the values of the input elements to equal the the values of the outputs. The gates of the circuit will then stabilize to reflect the new values of the inputs, and we get new values of the outputs. Until we press the button again, and feedback occurs again, and so forth. The same combinational logic is used over and over again to evolve the state.

This is the gist of sequential logic. We take a combinational circuit and feed the values of some of its output gates back to some of its input elements, whenever the clock signal triggers the feedback.

Let us review this idea with a little more detail before turning to Scala programming again. Here is a more detailed view to a counter circuit with feedbacks from the outputs of the incrementer to the inputs:

Let us now think how this circuit operates over time.

In the context of sequential logic, time is measured in clocks. That is, the time $$t=0,1,2,\ldots$$ is equal to how many times the clock signal has triggered since system start. At start, $$t=0$$.

Here is an illustration how the circuit operates over time:

Observe that sequential logic is very simple indeed (compared with all the trouble we had to go to learn combinational logic!):

When the clock triggers, the specified feedbacks happen.

Nothing more, nothing less.

Now let us turn to Scala programming to start witnessing the power of sequential logic.

## Upgrade from tinylog to minilog

Recall the tinylog package from Round 3?

A wonderful feature of encapsulation is that client code remains essentially oblivious to changes-in-implementation, assuming the interfaces to that implementation (that is, the classes and their methods visible to clients) remain mostly unchanged.

Our intent in this round is to witness such a change in implementation. Namely, we will upgrade package tinylog from Round 3 to package minilog in Round 4. This is to (a) get a more efficient circuit simulation, and (b) extend the package with a feedback mechanism to enable us to build sequential logic.

From a pedagogical perspective it is of course also important to show that such changes in the underlying implementation are possible, and enabled by careful design of the original interfaces. A further pedagogical motivation is that we get to introduce the principle of designing with patterns by reviewing the designs of both tinylog and minilog.

Before we proceed with the details of the upgrade to minilog, however, let us play with sequential logic.

## Our first design with sequential logic – the counter

Ambitious goals again have humble beginnings. Let us implement the counter circuit.

We start by recalling from Round 3 how to build an incrementer, in combinational logic.

import minilog._ // Note: in this round we use the package minilog

// Here is a builder for an incrementer

def buildHalfAdder(ai: Gate, c: Gate) = (ai && c, (!ai && c)||(ai && !c))

def buildIncrementer(aa: Bus) = {
var c = aa.host.True   // initial carry is true
val r = new Array[Gate](aa.length)
for(i <- 0 until aa.length) {
r(i) = s
c = c_out
}
new Bus(r.toSeq)
}


Now we are ready to implement the counter circuit.

val n    = 4
val c    = new Circuit()                   // a host object for our gates (new in minilog)
val ins  = c.inputs(n)                     // have the host create a new bus of n input elements
val outs = buildIncrementer(ins)           // build an incrementer
ins.buildFeedback(outs)                    // feed the outputs back to the inputs (new in minilog)


Observe the feedback statement ins.buildFeedback(outs). This statement simply indicates that each input element in the bus ins is to receive its value from the corresponding output in the bus outs when the feedback (clock) is triggered.

Recall the Toggler tool in tinylog ? The Toggler tool has been upgraded in minilog into a tool called Trigger, which we will put to use right now:

val t = new Trigger(c)                   // trigger requires a host object
t.watch("ins",  ins.reverse)             // we can watch gates or buses in the host object
t.watch("outs", outs.reverse)            // ... reversion shows least significant bit on the right
t.go()                                   // opens up the graphical interface


Observe the central new feature of Trigger, namely the trigger button that triggers the clock (and feedback):

Now give a few clicks to the button, and watch the binary counter run!

## Our second design – the accumulator-adder

Let us now return to the example of taking the sum of a list of integers. Say, suppose we want to evaluate (in binary) the sum of

00001011,
00101010,
00010101, and
01010111.

How would we design a machine to help us with this task?

We know how to build an adder circuit, so building sequential logic that accumulates a sum should be within the scope of our tools. Say, we feed the output of the adder back to its first input bus. This enables us to accumulate a sum, one summand at a time, by keying each summand in via the second input bus, and triggering the clock (feedback) to accumulate the sum.

Here is a builder for an adder (written in functional style):

def buildAdder(aa: Bus, bb: Bus) = {
new Bus(
((aa zip bb).scanLeft((aa.host.False, aa.host.False))) {
case ((s,c),(a,b)) => (a+b+c,(a && b)||(a && c)||(b && c))
}.drop(1).map(_._1))
}


val n         = 8
val c         = new Circuit()
val accum_in  = c.inputs(n)
val user_in   = c.inputs(n)

accum_in.buildFeedback(accum_out)


Let us witness this in Trigger:

val t = new Trigger(c)
t.watch("accum_in",  accum_in.reverse)
t.watch("user_in",   user_in.reverse)
t.watch("accum_out", accum_out.reverse)
t.go()


Now, toggle “user_in” to whatever value you want, and trigger feedback to have it added to the accumulator!

The feedback from accum_out to accum_in now in effect acts as $$n = 8$$ bits of memory, which is used to store and accumulate the sum.

The accumulator-adder can in fact be viewed as an extremely simple special-purpose processor design.

The processor has only one operation it can perform, namely add the contents of an 8-bit user input into an 8-bit register (or, the accumulator).

## Our third design – the accumulator-adder-subtracter

Our third design already includes configurable functionality. Namely, the machine can either add or subtract the user input from the accumulator, depending on what the user selects.

Here is a builder for a subtracter:

def buildSubtracter(aa: Bus, bb: Bus) = {
new Bus(
((aa zip bb).scanLeft((aa.host.False, aa.host.True))) {
case ((s,c),(a,b)) => (!(a+b+c),(a && !b)||(a && c)||(!b && c))
}.drop(1).map(_._1))
}


So now we can build the accumulator-adder-subtracter:

val n         = 8
val c         = new Circuit()
val accum_in  = c.inputs(n)
val user_in   = c.inputs(n)
val sel       = c.input()
val res_sub   = buildSubtracter(accum_in, user_in)
val accum_out = (res_add && !sel) | (res_sub && sel)

accum_in.buildFeedback(accum_out)


Let us witness this in Trigger:

val t = new Trigger(c)
t.watch("accum_in",  accum_in.reverse)
t.watch("sel",       sel)
t.watch("user_in",   user_in.reverse)
t.watch("accum_out", accum_out.reverse)
t.go()


After a little bit of play, let us now pause and reflect. Sequential logic has suddenly made our tools more powerful. We can now maintain a state inside a circuit, and evolve it according to combinational logic that can be configured (for example, either to add or to subtract) by toggling input.

## Towards understanding the computer

Let us think about our quest to understand the computer. It appears we have come a fair way now, but yet the notion of programmability (e.g. a console that executes our commands) appears more powerful than configurability. For example, we can now add integers by keying them into input elements of sequential logic and then triggering the clock.

But how do we instruct the machine to, say, take the sum of the first 100 million positive integers and then report back to us? It still appears that we do not have the full picture. Yet we are not far from our goal.

## Building an instructable data path – a roadmap for this round

Our objective in this round is to familiarize ourselves with sequential logic and continue towards our objective of understanding the computer. In fact, during this round we will cover most of the way to a fully functional, programmable processor architecture.

Yet again our strategy is to proceed from the bottom up. We start by upgrading our circuit-building and -simulation tools to sequential logic. In the process we will introduce the principle of designing with patterns to structure our programs in Sequential logic in Scala (*)

Once we have package minilog ready, we have all the tools required to fully and finally resolve the mystery of the programmable computer. In essence, it is all just sequential logic.

To back this claim, our goal in the next two rounds is to deploy sequential logic to build the armlet, in many respects a substantially simplified but yet fully programmable processor architecture loosely inspired by the ARM architecture.

Note

Most modern mobile devices and embedded systems have long used processors based on the ARM architecture. In fact, it is likely that you currently have an ARM processor running in your pocket or purse.

In recent years even personal computers based on the ARM architecture have become more common. For example, in 2020 Apple introduced products in their Air Pro, and Mini lines built around their M1 system.

Our objective in this round to build the data path of the armlet. That is, the part of the processor that maintains and manipulates the data in our computations, one step (clock tick) at a time. The two key components of the data path are the arithmetic logic unit (that implements the arithmetic and logic operations in our computations) and the memory interface unit (that loads and stores words of data from a memory unit outside the processor). The armlet data path

Furthermore, our goal is to be able to instruct the data path. That is, we want our design to be such that we can configure what the data path does at any given step by means of an instruction, that is, one word of control input to combinational logic. The armlet instruction set

Yet again what is above may sound like a formidable objective, but in fact we have essentially all the tools ready. The armlet data path is in essence nothing but a somewhat more intricate accumulator-adder (recall our design above): a combinational logic circuit with simple feedbacks from selected outputs to inputs.

In the exercises we will practice sequential logic design ranging from simple oscillators to the design of a pipelined multiplier unit.

In the next round, we extend the single-step functionality of the data path with an execution-and-control unit to obtain a fully programmable Von Neumann architecture, which we then proceed to program. Finally, we take a look at Scala itself and the progression from a Scala program to execution on actual physical hardware.