[Oberon] [EXT] Re: Project Oberon, RISC-V Edition

[Paul Reed]

Hi Wojtek,

> I also think that it would pay off to ask some good FPGA programmer
> (not me, I am not a good one) to interface the DDR3 memory to RISC5
> SoC.

Personally I'd prefer you don't use terms like "firmware" and 
"programmer" when you mean "FPGA configuration" and "hardware designer". 
Terms, especially such as "firmware", tend to have specific meanings in 
their fields and it's confusing to drag them into a different one. They 
are not the same!

> The downside is that the DDR3 controller is taking lots of FPGA
> resources

Not so much, where the hardware resources are there and dedicated on the 
chip, such as with an Artix or Spartan DDR I/O.

I think there are three main things to be addressed: first, try using 
the Xilinx memory interface generator to create a memory controller for 
the DDR on the Arty board and see if you can live with all the files it 
generates, the complexity of which is, of course, anathema to Oberon's 
philosophy.

Second, work out what needs to change about RISC5 to make it use a 
synchronous memory interface, rather than asynchronous static RAM. And 
see if, again, you can live with the increased complexity.

I've done both of the above and had them working. But not yet in a 
satisfactory or even remotely publishable way, because of the complexity 
and the nasty details.

And if you are happy with the extra complexity, why not just use RISC-V, 
or the ARM in a Zynq, for example, in order to leverage all the great 
resources available for those more complex platforms?

And if the hardware doesn't need to be too configurable, very cheap ARM 
or RISC-V boards exist, as discussed before. Or at least, the 
configurable hardware doesn't need to have a processor on it.

Which brings us to the third thing, which is what is the actual 
application? Software can be applied to a vast range of areas, many not 
even imagined when the code was first written. This doesn't happen 
nearly as much with hardware, as it's considerably less abstract, even 
when written in a portable hardware-description language.

In my experience it helps to have an actual application in mind, rather 
than be a solution in search of a problem, because with an actual 
"customer" waiting, a lot of the hard decisions about the hardware get 
settled much more quickly.

Cheers,
Paul