[Oberon] ProjectOberon on FPGA

[Jan de Kruyf]

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

Skulski,

I am offering a course in psycho-ceramics shortly.
Perhaps you might want to make it known in the wider community.
Recommended for all those who have difficulty dealing with crackpots . . . .

Seriously though, just to push the boundary a bit more:
you think you can set up 2 parallel oberon cores for us in an FPGA?

We can build a mini Beowulf, software wise it should be doable as long as
we dont get too fancy,
Unless of course someone would be so kind to release the Xoberon system
sources, but I have little hope.
Just as way of processing 2 streams of data at once.
Depending of course how much Bram is available.
( you note, I did do some more reading about what you are up to)

j.



On Sat, Aug 29, 2015 at 6:44 AM, <skulski at pas.rochester.edu> wrote:

> 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
>
>
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.inf.ethz.ch/pipermail/oberon/attachments/20150829/d1114478/attachment.html