[Oberon] NAstrobe for RISC5 on Pepino

[Skulski, Wojciech]

Andreas:
   > could you please remind me how I can handle the following situation.
   > On the RiskFive board I used the Ethernet chip type Wiznet W5300.
   > It is a memory-mapped peripheral, which works like ASRAM. In other words,
   > a piece of memory. I could handle it like this:
   >
   > WizMemArrayPtr := New (W5300_address, W5300_size)
   >
   > where W5300_address is hardwired in the FPGA decoder,
   > and W5300_size is a constant from the W5300 data sheet.

>I guess I could adapt EO’s NEW(ptr, size) to accomodate that,
>if it doesn’t already do what you describe.

Excellent. Is it supported under the other compilers?

>PS: When you say “W5300_address is hardwired”, do you mean
>that it has to be located at a fixed address in memory?

Yes. The way the memory-mapped hardware is built: 

Use case 1. 
You run a Chip Select wire from the FPGA to the chip. (Any chip, not just this one.) In the FPGA you instantiate an address decoder, which drives Chip Select LOW when the memory address is in the range to be mapped to the chip. (It is a convention, that chip select is active low.) You also connect the address and the data bits to the chip. Then, during the run time, the CS is driven LOW when the address is in range, and the chip responds to the address and the data. Furthermore, you can build bused hardware by reusing the same address and data wires for many chips. Any given chip will respond when its own CS is driven LOW. Otherwise it remains dormant.

This kind of memory mapping I would call "external". Note that such a memory buffer can also reside in the internal FPGA BRAM, where it can be used for mapping the variable to some action, like for example video, or data acquisition which is my own focus.

Use case 2.
A separate use case: it will help performance, if parts of BRAM can be designated for the CPU memory. BRAM can run faster then any external RAM. Imagine that a core set of modules is specified to be loaded to BRAM, both the code and the variables. These modules can run faster. The improvement may be substantial for Pepino, which is using a slow ASRAM memory. There will be (probably) little improvement in case of ZBT, which is faster than ASRAM.

This is also memory mapping, but I would call it "internal". The goal is optimizing the performance, which a nice to have feature for an embedded system. 

In the Use Case 2 I would advise to specify the memory range for a module code. It would permit to specify whether a module is loaded into BRAM (fast), external ASRAM or ZBT RAM (slower), or external DRAM (slowest). 

I know that a kind of rudimentary mechanism exists under Oberon System for compiling this special ROM code. The original intent was that the ROM code is discarded after boot. Here I am sayng that the ROM code can be used for running the core part of the system with the best performance. 

I also know that Astrobe is doing just that because its core can be fully embedded. So I am not trying to reinvent the wheel.

Use case 3.
Imagine using NOR flash with QSPI interface for execution-in-place (XIP). It is an interesting option, because modern QSPI flash is fast indeed. But it is read-only. So the code and the read-only variables can be mapped to NOR flash, while the read/write variables must be assigned to RAM. 

A feasible hardware can be built with QSPI flash for the code and RO variables, and without any external RAM, if the BRAM is sufficient for the RW variables. Such a board could be very small in size and very inexpensive.  

In order for this to work, there needs to be a facility to map variables, arrays, and also the executable code to predefined addresses. The facility must be fine grained, so the programmer can assign variables and code to addresses to be served by the internal BRAM, external RAM, memory mapped chips, or the QSPI controller. This kind of facility is the embedded 101. It would be nice if the facility was nice and clean.

Lots of work, I guess. This work can be performed with RiskFive where I provided the memory mapped Ethernet chip W5300, as well as a QSPI flash chip separate from the FPGA boot flash.

Thank you,
Wojtek