Avoiding timing issues in a processor

Question

I'm writing a simulation of a (very slow and primitive) processor.

For example: let's say the clock speed is a constant 1 hz. I assume this means that 1 instruction can/will be processed every second. Some instructions take longer than others. Adding 1 + 0 takes less time than 1 + 7. (The latter causes a ripple of carry bits which takes a non-zero amount of time.)

I need to be able to carry out instructions only after all other instructions have finished.

Do I need to:

1. time how long the longest instruction takes and set the clock speed to greater than that?
2. create a stateful watcher that won't allow future a instruction to be executed until the previous is complete
3. Am I misunderstanding the problem completely?

In #1, it seems like I'm still risking a race condition of instruction being incomplete before the next begins. In #2, it seems like I'm risking an unpredictable/variable clock speed which could cause me issues later.

How can I resolve this? Are there any hints in how a real processor handles this issue?

Answer 1

Are you familiar with the instruction pipeline ?

Answer 2

Firstly, processors do a single set of micro instructions per clock cycle, these usually involve things like switching a bus into a register or the ALU (arithmetic logic unit), the next micro instruction might clock the register or ALU to do something with the data on a bus. Most assembly level instructions are built up with a series of micro instructions. An addition instruction only takes a few micro instructions, but dividing may take many more. Most micro controllers document how many cycles each assembly level instruction takes.

With more sophisticated microcontrollers there is also an instruction pipeline (as cat mentions), which means the processor can start doing part of the next instruction before the previous on has completed. This can become very complicated with concepts like predictive branching.

Typically when you simulate digital electronics you use an event based model as electronic systems are concurrent, but also have propagation delays that need to be modeled. I remember using tools like PSpice and MicroSim at Uni that did this very well.

Answer 3

(1) is what the clock is. You shouldn't have a race condition; it takes x ns to execute an add; the clock is y ns. x < y. Therefor, the add will always finish first (well, provided y is large enough that timing changes due to e.g., temperature changes don't make x<y false).

Sure, if you make y too small, bad stuff happens. But that's quite realistic; it happens when you overclock chips. They get unstable as the clock rate goes up.

Answer 4

There are many differences between how an actual processor handles timing and how a simulation of the processor can handle timing. And, there is no one way that actual processors deal with timing!

Since you say it is a simple and primitive processor, you need not worry about caches, pipelining, out of order execution, branch prediction, etc (though it would be good to learn about these).

You can simply set the clock interval equal to the interval of the longest instruction. Or, you could club all the shorter instructions in one group, find the longest in the that group, and set the clock interval to that value. Now, the remaining long instructions can be allocated an interval which is equal to a multiple of the clock interval.

To repeat, there is no one way to go about this.