[Oberon] Emulating Project Oberon's RISC5 Architecture using Icarus Verilog

[Hellwig Geisse]

Hi Elen,

On Sat, 2024-03-16 at 10:15 +0000, Elen Edain wrote:
> 
> 
> I am currently undertaking a project to simulate the Project Oberon RISC5 system architecture
> using Icarus Verilog, aiming to replicate the system’s environment in a manner similar to QEMU for
> educational exploration. This endeavor is inspired by Niklaus Wirth's educational vision, focusing
> on understanding system design comprehensively.
> 
> Despite progress, I've encountered a challenge with emulating specific FPGA modules (originally on
> a Digilent Spartan 3 board), notably the DCM, RAM16X1D, and IOBUF modules, as a software
> simulation. This aspect falls beyond my expertise as a software engineer, primarily dealing with
> hardware emulation nuances. Thus I am on a learning journey as well and it is early days.
> 

the simple answer is: don't emulate the structure of these modules, but emulate their
behavior instead, and only to a depth that has enough details to reach whatever the
goal of the simulation is. Let me discuss this topic with the DCM as an example.

A DCM (digital clock manager) is a circuit that produces clocks with various frequencies
and/or phase shifts relative to the input clock. Although this is a strictly digital
circuit, the manufacturer usually doesn't supply any detailed circuit diagram for it.
So you would have a difficult time if you would try to reverse-engineer a DCM in order
to design a circuit that in the end shows the behavior of the chip exactly (i.e., with
all the timing details of all output clocks, phase jitter, and other peculiarities).

But this is seldom necessary. You have to choose a boundary of simulation in any case.
For example, you don't simulate your digital circuit by moving virtual electrons in
a 3D silicon crystal lattice. Typically you skip the levels of transistors and single
gates, and ground the simulation at the level of groups of gates, such as adders,
latches, and registers, in other words, the primitive behavioral elements that your
simulation language offers.

So the question you must answer is: how much detail is needed for my application
of the simulation? In the case of the DCM, this could be "two clocks (50 and 75 MHz),
phase-aligned on the leading edge", or similar requirements with more clocks, other
frequencies, or different phase angles. This however can be simulated in Verilog
very easily: use different generators for different frequencies, use one statement
for the low phase and another for the high phase of the clock, and specify the
duration of each in the delay parts of these stements (e.g., #5 clk = ~clk). It
is correct that these clock generators cannot be synthesized, but that was never
the intent. They are only used for simulation.

RAM is even easier to simulate, as long as you don't want to reproduce the real
timing behavior. I once worked with the Verilog simulation of an SDRAM, supplied
by the manufacturer of the device, which *did* reproduce it; the Verilog was well
over 1000 lines. I think that this is way too much detail, especially if the
simulation is meant to be used for study.

I/O buffers are the easiest of all: drop them. The only effect these buffers have
(apart from amplifying the output current) is on timing, but the delay they introduce
may be ignored in your application. This changes if you want to simulate more modern
SDRAM or even DDR memories, which require special IOBUFs with different clock inputs.
In this case the timing behavior must indeed be simulated.

Best regards,
Hellwig