[Oberon] RiskFive and Use of IP Cores

[Skulski, Wojciech]

John:

 sorry for being slow in responding. Too many things to do at the same time.

Concerning RiskFive, at this point we are stuck with the DDR3 memory, which needs a cache for any performance. Joerg directed my attention to the problem, which I somehow thought was specific to the very high performance hard silicon processors. it turns out that it will affect the slower soft core as well. 

This is more of a problem than I expected. I am now looking at redoing the PCB using the ZBT memory to avoid caching.

The board with the DDR3 has been designed. Ordering a production run is delayed until we are sure what to do about the processor cache. 

Thank you,
Wojtek
________________________________________
From: Oberon [oberon-bounces at lists.inf.ethz.ch] on behalf of jwr at robrts.net [jwr at robrts.net]
Sent: Wednesday, March 7, 2018 1:22 AM
To: oberon at lists.inf.ethz.ch
Subject: [Oberon] RiskFive and Use of IP Cores

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
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.inf.ethz.ch_pipermail_oberon_2017_011051.html&d=DwICAg&c=kbmfwr1Yojg42sGEpaQh5ofMHBeTl9EI2eaqQZhHbOU&r=uUiA_zLpwaGJIlq-_BM9w1wVOuyqPwHi3XzJRa-ybV0&m=BQvU1oCMwzNQdPv2qiawurp1xRe-OmnGOMI0OtpYa_Y&s=7X2_R2j-J_-T2OlTtki6JcwjimJvRX5uVBzUU9ZA4HI&e=, 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