[Oberon] RiskFive and Use of IP Cores

[jwr at robrts.net]

In a series of 2017 messages "RISC-5 and Memory", there was an  
excellent discussion. I wish to add a some comments of my own.
In his 5 Oct message posted at  
http://lists.inf.ethz.ch/pipermail/oberon/2017/011051.html, Wojtek  
Skulski said (among other good things):
"Don't do it yourself. Use Xilinx Core Generator which will interface  
the hard silicon logic built into Xilinx FPGA banks." "The bottom  
line: if you want to use high speed DDRx memories at close to their  
ratings, you cannot achieve it with LOLA-generated Verilog. You need  
to follow the FPGA manufacturer hard silicon solution, which is  
provided with their design tools." "But if we want to see V4, S3, or  
CP running on the FPGA (which are worthy goals!), then we need to  
tackle the subject matter with full repository of available tools and  
IP cores."

The (original) Project Oberon demonstrated many things, including that  
it was possible to develop a fully capable system which was small and  
highly understandable. Project Oberon 2013 extended this demonstration  
by making even the "hardware" visible and understandable in HDL, as  
well as portable to new FPGA boards. However, several critical  
decisions were made to support and favor goals of simplicity, size,  
and visibility, which it may now be time to move beyond for newer  
(specialized) implementations. Recall that the PS/2 interface was  
selected for mouse and keyboard, because the code to support USB would  
exceed the size of the entire PO2013 Oberon+HDL code.  Recall that  
static ram was selected because implementation of a dynamic ram  
controller would be highly complex, and that decision also drove the  
limited total memory available (usually 1Mb) and the initial  
monochrome display. There were other key choices as well which served  
to facilitate the proof-of-concept and educational purposes of Project  
Oberon, which now limit overall system capability. We now HAVE an  
excellent educational system which is sufficiently small and fully  
understandable for study, usable for many applications. We now are  
well positioned to move beyond that point, to more capable,  
higher-performance systems.

Wojtek (and others) want to use Oberon as system software for  
highly-capable high-performance (hardware) applications. I concur that  
we now need to take advantage of built-in and available hardware  
cores, to enable the next set of advances. For several (or many) key  
aspects, instead of choosing simple hardware and building a compact  
driver in Oberon, we now need to step by step begin choosing and using  
high-performance hardware IP cores (USB, dynamic memory controller,  
high-speed ethernet and fiber controllers, etc.etc.), and using Oberon  
to INTERFACE WITH those cores, rather than implementing in software  
the capabilities which those hardware cores implement. With  
appropriate care, we need to selectively replace hardware-related  
items currently performed in (Project) Oberon 2013, with interfaces in  
Oberon to those items implemented in hardware IP cores.  Yes, that  
will make understanding the full details of those items more  
difficult, but that's OK! We already have PO2013 for  
understandability; we should now be trying to multiply system  
capability and performance by leveraging hardware IP and circuit-level  
hardware capabilities.

Wherever possible we should continue to strive for clarity and  
simplicity and understandability. However, we ALSO want to strive for  
performance and capability, and to that end, leverage hardware IP  
appropriately. We should build clear and understandable and robust  
interfaces to the hardware IP, And because not every application will  
require the same hardware or performance, we should be prepared to  
implement certain interfaces multiple times, using different IP cores.  
For instance, we may need an interface to a Xilinx-based USB core, an  
Altera-based USB core, and perhaps a USB core implemented in one or  
more highly-capable external USB-support chips. Likewise there may be  
several different memory controllers to support, depending on  
performance and other requirements. And so forth for other functions.

I think the RiskFive project is heading in an excellent direction.  
High-performance hardware appropriate for multiple sophisticated  
applications has been designed, in an open manner with much inherent  
flexibility, considering but not limited by current PO2013  
constraints. It will provide an excellent test case and demonstration  
platform for using Oberon to drive and interface with sophisticated  
hardware devices and hardware IP, and the nature of the hardware also  
allows for implementation and comparison of non-Oberon system software  
as well.

-- John Roberts