[Oberon] ProjectOberon on FPGA

[skulski at pas.rochester.edu]

Enso:
> ... It is wise to stick to one working hardware system
> and leave as much as possible to software, whenever possible.

The advice is wise, if it is possible. Most often it is impossible in the
FPGA world. FPGAs were invented because software approach has its serious
limitations.

To substantiate the point. Our DDC-10 instrument is constantly processing
ten streams of 14-bit samples @100 MHz each. That is 10*14*100/8= 1,750
megabytes per second. The next instrument version, soon to be released,
will process three times more. Let's optimistically assume that one RISC5
core can process one megabyte per second. We would need 1,750 cores with
our current instrument, and over 5k cores with the new one. This example
should tell you that the software solution is impossible in this kind of
application.

> Developing code for a fixed platform is a joy; developing
> code for a platform that is changed every time someone needs some new
> hardware feature is a nightmare.

Not a nightmare but rather a skill. There are specialists for whom it is a
profession.

> Given that anyone can change hardware
> any time they feel like it, resisting the urge to do so is very wise.

This statement is not applicable to our field. We develop FPGA firmware
not because of lack of wisdom, but because of necessity. A quick look at
the required data rates will prove the point. I refer you to the example
above.

> It may be worth seriously thinking how to create hardware modules that
> integrate in a sensible way, much like the rest of Oberon. Hardware that
> is 'loaded' as needed, perhaps.  But that's a whole other project, isn't
> it...

The whole industry exists around the "IP cores". Check the Xilinx website
as well as OpenCores.org. All these IP blocks are precisely what you
mentioned, except that they are usually statically linked rather than
loaded on demand.

The on-demand loading is named "dynamic reconfiguration" (DR). Check
Xilinx website. It is supported by the FPGA tools, but it is way more
complicated than statically linking the cores. There are special IP cores
that help with dynamic reconfiguration. So this solution is both well
developed and quite complicated.

I am not even thinking of DR in the Oberon context. A simple BRAM concept
seems to be causing some reception difficulties. Now imagine the criticism
if I mentioned the DR. It is wise to stay away from this topic.

Wojtek