[Oberon] Oberon Digest, Vol 238, Issue 6

[Daniel Schmid]

Dear Elen

Honestly speaking i don't understand what exactly you'r going to
emulate and so if this information will help, but anyway let me
say; i got an Evaluation Board from Digilent with an Artix-7 FPGA
on it and then could - with the support of astrobe - program the
NW RISC5 processor from the Verilog source. Oberon is running well
on it. So this is no original but current hardware. 
Best regards from Switzerland
Daniel

On Sun, 2024-03-17 at 12:00 +0100, oberon-request at lists.inf.ethz.ch
wrote:
> Send Oberon mailing list submissions to
>         oberon at lists.inf.ethz.ch
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://lists.inf.ethz.ch/mailman/listinfo/oberon
> or, via email, send a message with subject or body 'help' to
>         oberon-request at lists.inf.ethz.ch
> 
> You can reach the person managing the list at
>         oberon-owner at lists.inf.ethz.ch
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Oberon digest..."
> 
> 
> Today's Topics:
> 
>    1. Emulating Project Oberon's RISC5 Architecture using Icarus
>       Verilog (Elen Edain)
>    2. Re: Emulating Project Oberon's RISC5 Architecture using
>       Icarus Verilog (Hellwig Geisse)
> 
> 
> ---------------------------------------------------------------------
> -
> 
> Message: 1
> Date: Sat, 16 Mar 2024 10:15:05 +0000
> From: Elen Edain <elen.edain at protonmail.com>
> To: oberon at lists.inf.ethz.ch
> Subject: [Oberon] Emulating Project Oberon's RISC5 Architecture using
>         Icarus Verilog
> Message-ID:
>         <jQ3PCiO9X0FdAiKZeNURSPbsnrvCMK4suFF9FnBwOsH5JKsA4_UGIumFYdAD
> tMQ_AoBMO0PNVjKpb41k1n1v0yO8S1uOyBUQX62krC5ve5Q=@protonmail.com>
>         
> Content-Type: text/plain; charset="utf-8"
> 
> Hello and Greetings from Iceland,
> 
> 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.
> 
> I am seeking the community's expertise and advice on simulating these
> FPGA modules in Verilog, to further develop a detailed tutorial
> aligned with Wirth's original documentation, thereby eliminating the
> dependency on the original FPGA board.
> 
> The ultimate aim is to produce a contemporary, step-by-step guide for
> working through the Project Oberon ecosystem without the need for the
> original FPGA board. Any advice, resources, or guidance on where to
> start with these hardware component emulations would be greatly
> appreciated.
> 
> Best regards,
> 
> Elen
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 249 bytes
> Desc: OpenPGP digital signature
> URL:
> <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20240316/bb21a
> b18/attachment-0001.sig>
> 
> ------------------------------
> 
> Message: 2
> Date: Sat, 16 Mar 2024 22:44:48 +0100
> From: Hellwig Geisse <hellwig.geisse at mni.thm.de>
> To: ETH Oberon and related systems <oberon at lists.inf.ethz.ch>
> Subject: Re: [Oberon] Emulating Project Oberon's RISC5 Architecture
>         using Icarus Verilog
> Message-ID:
>         <00dc691c69434030d7d3a7372c0aec9317150d90.camel at mni.thm.de>
> Content-Type: text/plain; charset="UTF-8"
> 
> 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
> 
> 
> 
> 
> ------------------------------
> 
> Subject: Digest Footer
> 
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related
> systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon
> 
> 
> ------------------------------
> 
> End of Oberon Digest, Vol 238, Issue 6
> **************************************

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20240414/53c22108/attachment.sig>