Top-Level Sim Design

Read time: 17 minutes (4376 words)

Now that we have Von Neumann’s basic scheme for a processer down, and we know the basic “dance” that the processor has to do to execute one instruciton, It is time to put together the besic design for our simulator.

Basic Data Flow

The machine processes exactly one instruction in one pass through those four “dance: steps.

Here is the basic idea:

Our real Challenge in extending this idea involves determining what signals need to move from one stage to the next.

Fetch Stage

This unit’s basic job is to “fetch” the next instruction to be processed by the machine and pass that instruction along to the decode unit. The unit needs to keep track of the address of that instruction in instruction memory, which we will assume is inside of this unit.

Program Counter Management

The fetch unit maintains an internal storage unit we will call a “register”. The register we are concerned with is called the program counter, or PC, which holds the address of the next instruction to be processed in the instruction memory.

Power-on or Reset

Obviously, when the machine is first powered up, there needs to be a way for this register to be initialized. We might also like to provide a way to “reset” the machine, so it starts processing over again.

Causing this to happen will be the responsibility of the `control unit we will discuss later.

In the case of the ATtiny85 processor, the power-up address is zero, so we can handle this by providing a special component called a multiplexor, which selects one of two possible data sources to route along to its output. The selector signal for this part will come from the control unit, and we simply set a constant signal value of zero on one input to the MUX.

To handle normla processing, we configure the othe rinput on the MUX so it delivers the generated next address calculated when the current instruction is completed. This will set things up properly for processing the next instruction later.

Since we have set up our first part needing help from the control unit, we might as well set that component up, and let is have a way to control all stages in processing. Here is that addition:

Basic Signal Flow

Just to save some time, here is a first cut at the signal flow through the stages. We will review these signals after looking at the design:

Fetch Stage Outputs

When we trigger the fetch nit unit, the PC address is used to “fetch” that instruction from instruction memory, and then send it on its way to the decode unit.

There is a problem with this basic ides, though. Some instructions in the processor need more than that one basic piece of data. There might be an additional chunk of data holding an address or a constant. We will simplify things a bit by asking the fetch unit to go ahead an fetch another piece of data, even if it is not needed.

The current value of the program counter needs to be passed along to the decode unit, so calculating the proper next address for the instruction following the current one can be done.

Decode Stage Outputs

The decode stage is responsible for taking an instruction, and the additional piece os data (if needed) and breaking all of that up into fields needed for processing. The output from this process will be the instruction for the ALU (if it is involved) and the operands needed by the ALU. All ALU instructions in the ATtiny85 use operands stored in the internal registers, which we will assume live in this stage of the design. The decoder will fetch the data stored in those registers, and deliver all of that to the execute stage.

The execute stage might need to perform some calculations to determine the correct next address, so that will happen in this stage as well.

Execute stage Outputs

The execute stage is where the ALU is located. This component performs the arithmetic and logic functions provided by instructions, and the result of those calculations is passed along to the store stage``.

Store Stage Outputs

The store unit is where we will locate data memory. In our processor, data may be transferred from data memory into an internal register, so we need a path running from the store unit back to the decode unit where the registers are located. Finally, the next address is routed back to the multiplexor to complete this cycle.

Design Review

There are a few details missing here, and those details may result in design further design changes.

We have enough of a design to begin discussing how we will manage this machine in our project. One thing is certain, our simple “tick-tock” scheme is not really going to work for this setup.

We need more control!