[Oberon] RISC5 implementation issues.

[skulski at pas.rochester.edu]

Paul wrote:

>FPGAs are a little off-topic for many Oberoners

Should not be if we want to advance the FPGA Oberon. We may consider a
separate mailing list if the community does not want to see FPGA
discussions. Otherwise they have to bear with the HW engineers.

> I agree with Magnus, the tools add the relevant clock buffer
> as part of their job, and the source code is kept simple and clear.

The RISC5 code only looks simple and clear, but in fact it is not. The
very fact that you need to refer to the FPGA editor proves that lots of
details are hidden under the rug.

We analyzed the RISC5 code at SkuTek and our conclusions were much the
same as Walter's. Speaking on behalf of our electrical engineer Dave, some
parts of the code seem to rely on unspecified timing relations between the
signals. The core works due to particulars of a given FPGA and the current
FPGA compiler. If this is true then the core is not portable.

> Hopefully the below simple hardware LED counter for the Spartan 3
> board (easily adapted to almost any other board!) might be indulged,
> and interesting for enough people :)

Simple circuits like this are interesting, but if one wants to learn FPGA
programming then I would rather treat this topic more seriously. I either
recommend a systematic approach by reading a few books, or perhaps open a
serious discussion on the RISC5 architecture and implementation.

RISC5 deserves a similar level of detail as PicoBlaze, which is of a
similar level of complexity. In both cases the printed documentation is
similarly good. But if you look at the Picoblaze code, you will see a
great example of well structured and well documented code. If you look at
RISC5,  to me the code seems to be terse and obfuscated. I would welcome a
well structured, well commented code of the fundamental part of the Oberon
System.

Also, RISC5 deserves having both the Verilog and VHDL implementations. We
can start with an automated translation and go from there.

Finally, I would welcome the participation of The Chief Justice in our
discussions. A glaring difference between PicoBlaze and RISC5 is that
their Chief Justice is participating in the community. Our Chief Justice
is only showing his back to us. He is not helping the case.

A simple counter example:

Concerning the counter code below, I am puzzled by the statement "always
@(posedge CLK50M) clk <= ~clk;". If I understand the intent, it creates a
signal that is controlled by CLK50M. Why not use the CLK50M directly? You
can run the counter at the CLK50M frequency and use higher order bits.

On the other hand, if you are saying "no, I cannot do this, so I have to
divide clock because of timing" -- well, you have just proven the point
that this seemingly simple code has issues that extend well beyond the
apparent simplicity. Welcome to the real world of FPGA programming! But
then, do not say it is simple. It requires a systematic approach,
explaining the implementation issues, timing issues, perhaps routing and
implementation implications, etc. It is exactly what Walter is saying and
we fully support. Do not say that not simple is simple, because it only
creates confusion.

Wojtek
--------------------------------

(test.v)

`timescale 1ns / 1ps

module TestTop(
    input CLK50M,   //50MHz
    output [7:0] leds);

reg clk;
reg [31:0] cnt;

assign leds = cnt[31:24];

always @(posedge clk) //25MHz
  cnt <= cnt + 1;

always @(posedge CLK50M) clk <= ~clk;

endmodule

(test.ucf)

NET "CLK50M" LOC = "T9" ;
NET "leds[0]" LOC = "K12";
NET "leds[1]" LOC = "P14";
NET "leds[2]" LOC = "L12";
NET "leds[3]" LOC = "N14";
NET "leds[4]" LOC = "P13";
NET "leds[5]" LOC = "N12";
NET "leds[6]" LOC = "P12";
NET "leds[7]" LOC = "P11";


--
Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.inf.ethz.ch_mailman_listinfo_oberon&d=BQICAg&c=kbmfwr1Yojg42sGEpaQh5ofMHBeTl9EI2eaqQZhHbOU&r=uUiA_zLpwaGJIlq-_BM9w1wVOuyqPwHi3XzJRa-ybV0&m=axz6Q0wJHXAJpiWM47p-dh9pJ_84HrSvnfp_KM_Bz9w&s=luMUZvoVzcE_dKdkaPgdDwgDOkCpB32rbg5lyrp5_Fg&e=