[Oberon] ALU 2015 and 2018

[Hellwig Geisse]

Wojtek,

On Mi, 2022-05-11 at 01:30 +0000, Skulski, Wojciech wrote:
> 
> I admit that I do not see how this follows from RISC5.v code. There are just four lines under the
> clocked "always" block, reproduced below. (The next line deals with DIV/MULT, and a few others
> with the interrupt.) I just cannot see how your statement can be inferred from the following lines
> of code. The comments in the code are mine.
> 
> I gather that the ALU and the Control Unit are two state machines which work in parallel. I cannot
> see how their mutual timing follows from the "always block" statements. I cannot see how the
> cascaded ALU statements get executed by the code below, which is the only clocked code in the
> entire RISC5.v. I cannot see how the timing relationship between the CU and the ALU is related to
> the code. Could you please elucidate?
> 

I'll try. In principle you are asking the "reverse-engineering" question:
Given the description, what is its behavior?

There are two steps when clarifying the behavior of a synchronous digital
circuit which is described in an HDL (Verilog in our case). I always ask
my students to draw a circuit diagram from the Verilog description first
(because they are so much trained in sequential programming that the very
nature of parallel execution is a big obstacle in understanding the HDL
description - they read it as if it were a program, which it is *not*).
The second step is to simulate the description and to observe all the
signals carefully, in this way verifying the diagram and simultaneously
understanding how it works.

When drawing the circuit diagram for a synchronous automaton, the state
elements (aka registers) are the place to begin with. Note that there
are architectural registers (these are known as "the CPU registers" for
programmers) and physical registers, which also include the state elements
that are not directly accessible from a program (with the "instruction
register" IR as a prominent example). And please keep in mind, that the
description of the various state elements can be condensed into a single
"always" statement (NW's style), or contained in many such statements,
scattered all around the Verilog source, the order of them being irrelevant.

Next you have to fill in the combinational circuits "between" the
registers. The description of the ALU is a good example. Its inner
working is of course responsible for correctly implementing the
arithmetic/logic instructions, but is less important for understanding
the state transitions of the machine. Be sure to clearly mark the
registers as "clocked", and the combinational circuits as "non-clocked".

The general outline of the circuit you will now have is this:
[register] --> <comb.circ.> --> [register] --> <comb.circ.>
with probably a feed-back path from the right-most combinational circuit
to a register (to be precise: to a multiplexer in front of a register).
This is the so-called "data path" of the machine. Generally, the registers
each have a "clock enable" signal, the multiplexers each have "select"
inputs. These signals are asserted/deasserted by the "control unit".
Machines vary wildly in realizations of the control unit: it may be
a centralized circuit, located directly after the IR, or it may be
scattered all around, usually within different pipeline stages. As
RISC5 is a small machine, its control unit is small too. It centers
around the circuits to decode instructions and to generate the stall
signal in order to coordinate memory access from two places, instruction
fetch and memory read/write.

If you made it thus far, the rest is easy. Draw timing diagrams for
the different classes of instructions, note the control signals going
from the control unit to the data path, and compare with the simulation
you should have set up.

I cannot reasonably present a circuit diagram of RISC5 here, I'm sorry.
But I did draw one the first time I tried to understand NW's description.
I can however help to set up a simulation of a circuit which is close
to the original HDL source. This design proved difficult to port to my
board (Terasic DE2-115), mainly for reasons of memory coupling. Therefore
I re-designed RISC5 completely. The results can be found in my repository.

Sorry for the long post. I suggest continuing the discussion off list
(unless there is general interest in this topic).

Best regards,
Hellwig