March 2016 - Oberon - mailman3.inf.ethz.ch

Blackbox for linux?
by Srinivas Nayak 07 Mar '16

07 Mar '16

Dear All, Do we have Blackbox for Linux? With thanks and best regards, Yours sincerely, Srinivas Nayak Home: http://www.mathmeth.com/sn/ Blog: http://srinivas-nayak.blogspot.in/

5 5

Oberon Runtime Environment running Oberon byte-code
by Srinivas Nayak 06 Mar '16

06 Mar '16

Dear All, To my knowledge, Oberon programs needs a runtime environment with 1. command activation 2. garbage collection 3. dynamic loading of modules 4. certain run-time data structures Although not part of the language, this environment is implied by the language definition. And this empowers Oberon. If this is the case, like Java, would a Oberon Runtime Environment running Oberon byte-code have been better? Is there a limitation in this scheme? Looks like, Michael Spivey with Oxford Oberon-2 compiler proceeded with similar scheme... I would like to know if there is any reason, we didn't make it like java... I hope that would have solved taking Oberon to different platform easy. With thanks and best regards, Yours sincerely, Srinivas Nayak Home: http://www.mathmeth.com/sn/ Blog: http://srinivas-nayak.blogspot.in/

6 5

ETH Oberon links not working.
by Srinivas Nayak 04 Mar '16

04 Mar '16

Dear All, Links present on page http://www.oberon.ethz.ch/downloads/index is not working. Any help? -- With thanks and best regards, Yours sincerely, Srinivas Nayak Home: http://www.mathmeth.com/sn/ Blog: http://srinivas-nayak.blogspot.in/

3 2

Re: [Oberon] Accessing Oberon RISC5 files on other computers
by skulski＠pas.rochester.edu 03 Mar '16

03 Mar '16

John R. Strohm [strohm(a)airmail.net]wrote: >At that point, you are talking about a FATnn (FAT12, FAT16, FAT32, > if memory serves me) filesystem on the SD card, and adding > a FATnn filesystem to your Oberon system, plus code to recognize > that a random SD card plugged into an > Oberon system has a FATnn filesystem already on it. Obviously. I am talking of whatever needs to be done to transfer the data in a reasonable way. If it is FAT, let it be FAT. > Which is kind of a mess, not to mention proprietary. Every real product is a mess. How else? Are we insisting on worshiping a gold plated ivory tower? Beautiful, clean, and useless? Wojtek

3 2

Re: [Oberon] Fast version of Oberon RISC5 for Pepino
by skulski＠pas.rochester.edu 01 Mar '16

01 Mar '16

________________________________________ From: Chris Burrows [chris(a)cfbsoftware.com] There are two versions of Multiplier still available on Prof Wirth's site. One which is portable (Multiplier.v) and one which uses the fast 18 x 18 bit multiplier units (Multiplier1.v): Chris: Spartan-3 was the first generation that provided the silicon implementing 18x18 multipliers. Since NW code was written for Spartan-3, it is not surprising that he provided the targeted version of the code. Subsequent generations added more silicon features inside these blocks, such as multiply-accumulate registers. The blocks were renamed "DSP slices". More features are being added to these in every new generation. Writing Verilog/VHDL code that is portable among these generations may be tricky. One can adopt Magnus' approach by writing high level code expressing the intent, and then let the compiler "infer" the proper circuit. (FPGA compilers do not compile, they "infer" according to the official slang.) The word "infer" means that the designer should check in the compilation report whether or not the compiler guessed right, and change the syntax if not. My general conclusion is that the FPGA code only pretends to be portable. Yes, you can write code which looks obvious. No, you cannot assume that the obvious code is translated according to the intent. You need to check whether this particular compiler "inferred" the proper circuit for this particular FPGA. I am also skeptical about writing code in LOLA, translating to Verilog, and claiming it is the end of the problem. In my mind LOLA is a sketch of the final solution rather than the final solution which needs to be written in the way the vendor recommends. It means VHDL/Verilog. I also think that having slightly different variants of the code for various FPGA families cannot be avoided. Just my experience. Yours may differ. Wojtek

3 2

Re: [Oberon] Fast version of Oberon RISC5 for Pepino
by Chris Burrows 01 Mar '16

01 Mar '16

> > From: Oberon [mailto:oberon-bounces@lists.inf.ethz.ch] On Behalf Of > Magnus Karlsson > Sent: Tuesday, 1 March 2016 10:31 AM > To: oberon(a)lists.inf.ethz.ch > Subject: Re: [Oberon] Fast version of Oberon RISC5 for Pepino > > The current RISC5 verilog code does not take advantage of the fact > the both > Spartan3 and Spartan6 have hardware multipliers There are two versions of Multiplier still available on Prof Wirth's site. One which is portable (Multiplier.v) and one which uses the fast 18 x 18 bit multiplier units (Multiplier1.v): https://www.inf.ethz.ch/personal/wirth/ProjectOberon Regards, Chris Burrows CFB Software

2 1

Fast version of Oberon RISC5 for Pepino
by Magnus Karlsson 01 Mar '16

01 Mar '16

One outcome of the discussion about the Oberon RISC5 verilog code is that I did a deeper study about the clock limits for the project and found that the RISC5 CPU in itself can be clocked at up to about 66 MHz but the external SRAM path is too slow for that speed (read is the problem). The asynchronous nature of the SRAM interface makes it hard to constrain the ISE compiler to work hard on this path. I did trace the SRAM read data path and found that it takes about 10 ns from the SRAM data input pins to the Z register bit (this is the longest path). The address output path is about 5 nS and with a 10 nS SRAM access time the fastest system clock cycle should be around 25 nS. To test this out I created a version of the code that runs the CPU at 37.5 MHz (26.666 nS) instead of 25 MHz, i.e. the CPU is running 1/2 the video clock rate instead of 1/3, and it seems to run fine of both the LX9 and the LX25 version of Pepino. All timing constants (UART Rx, UART Tx, SPI and millisecond timer) have been changed to reflect the 50% faster clock rate. If anyone want to try it, the project (including bit files) is available here: https://github.com/Saanlima/Pepino/tree/master/Projects/RISC5Verilog_Pepino… Cheers, Magnus

3 5