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

[Skulski, Wojciech]

Paul:
I wrote:
>> The downside is that the DDR3 controller is taking lots of FPGA
>> resources
Your response:
>Not so much, where the hardware resources are there and 
>dedicated on the chip, such as with an Artix or Spartan DDR I/O.

The table below is from DS176 June 8, 2016, page 10, Zynq-7000 AP SoC and 7 Series Devices Memory Interface Solutions (v4.0). The first number is the number of required look-up tables (LUTs), 2nd is percentage of the chip taken by the interface. The total number of LUTs in Artix-7 35T  is 20,800 = 5,200 * 4, where "5200" is the number of "slices", and each slice provides four LUTs. From this table it follows that the DDR3 interface is taking a big cut of the FPGA. I doubt whether the remaining part is sufficient for RISC-V and substantial peripherals.

DDR3 SDRAM(2) 14,016 67%
DDR2 SDRAM(2)  9,267 45%
LPDDR2 SDRAM  3,952 19%

>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.

The answer is above. Going this route will require a much larger FPGA. The 35T is loaded to the edge with just the DDR3 controller. I mentioned 100T. Concerning complexity, I am not advocating either DDR3 or RISC-V. I mentioned these because Andreas asked on the forum. There were also complaints concerning lack of appropriate boards. I wanted to say that boards do exist, and then please start looking at the overheads. 

The bottom line: either let's make our own boards (RiskFive is one), or adopt 3rd party boards with all their goodies. Digilent Arty comes with two variants, 35T and 100T, and with DDR3. Want the board, get the board. They are there. Before you get the board, look at the firmware which will be needed to use that memory. All the info is available. 

>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.

If "synchronous" means "ZBT", then I posted the preliminary firmware. It is about the same as the original ProjectOberon. If "synchronous" means DRAM, then the answer is above.

> 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.

I believe that ZBT is the best solution up to 4 MB. HyperRAM is the best between 4 MB and 32 MB, because the DRAM controller is sealed on chip and you do not have to even know it exists. Above 32 MB it is probably DDR2, or DDR3 if you are prepared for the ugliness and the size of the firmware. I will avoid going there.

>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?

Thank you, not now. We developed the BeagleBone derivative with AM5338 running Linux. We have had enough fun with ARM and Linux. My curiosity is more than satisfied. You can see my slides if you search the web for Skulski_SkuTek_SBIR_Xchange_Aug_14_2020_SC0009543.pdf. 

Thank you,
Wojtek