[Oberon] Unlimited Oberon System for any board

[Skulski, Wojciech]

Joerg:

  thank you for a succinct description. 

> The Oberon OS as it exists for RISC5 today is in my point 
> too limited to build a good starting point for a native OS 
> on any commercial HW board.

Agreed. This is due to the history of the the 2013 FPGA Oberon System.
Let me summarize the history before drawing some recommendations. 

The OS was developed using a popular education platform board. 
It was popular enough that Pong P. Chu wrote two books using this 
board for the exercises. The FPGA on this board provided 200k 
"system gates" (whatever it means...). It was large enough 
for the frugal System-on-Chip firmware, but too small for 
more ambitious designs. The board PCB design permitted 
larger FPGAs with 400k and 1M system gates. In practice 
these boards with the larger chips were hard to get. Consequently,
the firmware had to fit into the 200k FPGA, which was filled 95%.
Since the FPGA was full, any FW extensions were hardly possible 
with the most popular variant of the board, and other variants were 
hardly available. Software wise, the available SRAM was just enough 
for the proof of principle after chopping off everything that could be 
chopped off, which was favored by NW. The frugal software 
was cherished and declared success, which is really was. However, 
the valuable Oberon variants, V4 and S3, could not fit into the SRAM. 
In summary, using this board lead to a short term success, but it also 
cornered the community into the hardware platform which was 
inadequate for either the existing V4/S3, or for any new developments.

The Digilent board was discontinued (contrary to Chris saying that Digilent 
keeps their products alive for a long time). The 200k variant can be 
still purchased on eBay. The 400k or 1M variants are virtually unavailable. 
Three other boards were either developed or adopted with the OS in mind: 
Pipistrello, Pepino, and Oberon Workstation. All three were basically clones 
of the original board, featuring larger FPGAs and thus permitting some 
firmware experimentation. All three boards kept the same 1 MB SRAM 
as the original. Pepino could be assembled with 2 MB, but I am not sure
if it was. The most popular Pepino still has 1 MB. Even though 
a more powerful SoC firmware could be tried with these 
boards, but a significantly more powerful Oberon software would still 
not fit into 1 MB. Joerg tried some color enhancements (4 bit color 
rather than B/W), but this led to chopping down the program memory.

In summary: All the Oberon Software is still limited by the accident 
which happened in the past, which was a particular board with a particular
amount of SRAM. The progress is still limited this design decision taken long 
time ago. 

Recommendations:

1. Lifting the limitation is possible with RISC5 emulators. It should be possible to 
develop the V4 or S3 for RISC5 inside the emulator. It would help determine 
how much RAM is recommended for these versions of the RISC5 Oberon System.
Knowing the requirements could direct the FPGA board design.

2. Boards with more powerful FPGAs and more memory are needed to break 
the 1 MB barrier. I designed and built a board with 4 MB, which was motivated 
by my particular needs. This is the practical limit of how much fast SRAM memory 
can be put on the board. (I used ZBT chips.) If more memory is needed 
then it must be some sort of DRAM.

3. If DRAM is used then the CPU needs to use caches. It was discussed by NW 
in "Experiments in Computer System Design", August 2010, pages 32-41.

4. The present RISC5top.v has a very frugal peripheral interface, limited to 
256 addresses. It is simply not enough. A more powerful SoC design is needed.
It can be the FPRO developed by Pong P. Chu. It can be WishBone. 

5. We should not adopt the vendor-specific system bus because this immediately 
puts us at mercy of the vendor wizards and black boxes, which are evolving 
faster than anyone can download the vendor tools. (My opinion based on 
experience.)

6. I recommend abstracting just the RISC5 core from the NW/PR SoC. This core 
is the essence of the FPGA Oberon System. Other pieces of the SoC are not.
The RISC5 core can be wrapped up to become an "IP core" which it really is.

7. I recommend development of two versions of the RISC5 core, one with the caches 
(RISC5c) and one without (RISC5nc). More variants are possible. They should use 
the same firmware interface, so they become interchangeable. Variations of the 
interface, if necessary, should be kept small. 

8. The RISC5c can be then used with commercial FPGA boards which tend to use 
the DDR chips these days. 

9. The RISC5nc can be used for the legacy boards (Pepino, Pipistrello, etc), 
for the RiskFive where the cache is not needed, and for the low cost 
RAM-less boards. In the latter case one would use Astrobe, which can run 
without any extra RAM.

10. Both versions of the core should exist in two variants. The plain vanilla 
RISC5 Controller System similar to the MicroBlaze Controller described 
in Chu's books. It is the same as we have now. No changes needed 
except for documentation. The WishBone versions will help to put together 
a Soc using the WishBone and WishBone cores, which are many. I want to 
stress that WishBone is commonly used in EE courses which I have seen.

11. There is really no need to keep using the present Oberon peripherals 
(SPI, PS/2, etc) which are not unique. There are plenty of other implementations 
of these on Open Cores, in the books by Chu or Pedroni, and all over the place. 
The really unique part of the firmware is RISC5 itself. It is worth the effort. 
Other parts of the NW/PR firmware are easy to replace in case of trouble.
 
Joerg wrote:
>Just one example: the SW architecture for HW drivers  
(if you can speak of an architecture at all) is too slim 
and too static. There is Kernel (driving timer, clock and disk), 
Input (driving mouse and keyboard) and Display (driving the screen)
The existing APIs do not allow to change the keyboard layout, 
nor to change the resolution.

My recommendation: Once it becomes easy to add new firmware modules 
after adoption of the modular firmware design (either FPRO or WishBone) 
the ned for driver development will become pressing. So it is good that 
Joerg is rising this issue.

Joerg wrote;
>At least a FAT16/LFN filesystem implementation, 
a TCP/IP API and an USB API should be part of 
a „modern“ OS. As these protocols are complex beasts, 
I could imagine that coding those will need quite 
some memory. Perhaps too big for the 1MB my FPGA 
board currently has.

At this point I can loan you the RiskFive with 4 MB, W5500, W5300, 
and full color video output via Analog Devices video DAC. (Not the 
crippled output which Digilent was providing!) This can be useful 
to break away from the 1 MB and limited video you have now.

More powerful boards can be either developed in this community
or adopted from the vendors, like Arty-7 for example. It has 
256MB DDR3L with a 16-bit bus @ 667MHz. This can be utilized 
if we had the RISC5c core with the cache. 

> But indeed running ProjectOberon natively on a RasPi would be nice😊.

Arty-7 will be much nicer. There is a great advantage if one can use 
the FPGA to try lots of new ideas and designs, like multicore RISC5, etc. 

Thanks,
Wojtek

============================================
Am 02.05.2020 um 00:17 schrieb Guy T. <turgu666 at gmail.com>:

Wojtek,

From your answer, I understand that you would prefer a simple solution in the same realm as the FPGA based NW Risc5 design. This is certainly an aspect that need to be considered.

The reality today is that I don’t see any ready-made processor chip available that would be simple enough to be a contender to a simpler FPGA design, unless you look at old technologies no longer available elsewhere than on eBay. The ESP32 I’m working on cost me around $4 CDN each and it comes with around 1450 pages of describing both the CPU  architecture (around 660 pages) and the 20+ interfaces in a technical reference manual (around 680 pages), and this doesn’t take into account the ESP-IDF framework.

The NW design is very interesting and very useful for computer science education. But the reality right now is the difficulty to get access to a ready made board that would survive for a reasonable amount of time in term of availability, unless an open design is made available and simple enough for a guy like me (I’m a hobbyist in electronics) or a student that would be able to build one in his basement. The last board have seen is the ulx32 (https://www.crowdsupply.com/radiona/ulx3s). Very interesting, but will it survive? (it is too complex to be built at home) I hope so, unless other alternatives appear.

Maybe the solution is to follow two tracks: An FPGA based solution and a commercial board based solution (read: Raspberry Pi and/or BlackBerry like boards). Nothing is perfect here.

Again, it's all depend on the orientations that the community wants to take.

Me, I don’t really care to what orientation will be taken. For now, I’m using the risc5 emulator on my laptop and have fun in building the compiler for the ESP32. IOT development is my current spin. I would be more serious in developing stuff with the Oberon OS if I can get an interesting platform to run it.

Cheers!
Guy