[Oberon] [EXT] Re: Project Oberon, RISC-V Edition
paulreed at paddedcell.com
Mon Dec 7 10:47:06 CET 2020
> 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
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
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
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.
More information about the Oberon