<div dir="ltr"><div>> I am not even thinking of DR in the Oberon context. A simple BRAM concept</div><div>> seems to be causing some reception difficulties. Now imagine the criticism</div><div>> if I mentioned the DR. It is wise to stay away from this topic.</div><div><br></div><div>Skulski,</div><div><br></div><div>I am offering a course in psycho-ceramics shortly. </div><div>Perhaps you might want to make it known in the wider community.</div><div>Recommended for all those who have difficulty dealing with crackpots . . . .</div><div><br></div><div>Seriously though, just to push the boundary a bit more: </div><div>you think you can set up 2 parallel oberon cores for us in an FPGA?</div><div><br></div><div>We can build a mini Beowulf, software wise it should be doable as long as we dont get too fancy,</div><div>Unless of course someone would be so kind to release the Xoberon system sources, but I have little hope.</div><div>Just as way of processing 2 streams of data at once. </div><div>Depending of course how much Bram is available.</div><div>( you note, I did do some more reading about what you are up to)</div><div><br></div><div>j.</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Aug 29, 2015 at 6:44 AM, <span dir="ltr"><<a href="mailto:skulski@pas.rochester.edu" target="_blank">skulski@pas.rochester.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Enso:<br>
> ... It is wise to stick to one working hardware system<br>
<span class="">> and leave as much as possible to software, whenever possible.<br>
<br>
</span>The advice is wise, if it is possible. Most often it is impossible in the<br>
FPGA world. FPGAs were invented because software approach has its serious<br>
limitations.<br>
<br>
To substantiate the point. Our DDC-10 instrument is constantly processing<br>
ten streams of 14-bit samples @100 MHz each. That is 10*14*100/8= 1,750<br>
megabytes per second. The next instrument version, soon to be released,<br>
will process three times more. Let's optimistically assume that one RISC5<br>
core can process one megabyte per second. We would need 1,750 cores with<br>
our current instrument, and over 5k cores with the new one. This example<br>
should tell you that the software solution is impossible in this kind of<br>
application.<br>
<span class=""><br>
> Developing code for a fixed platform is a joy; developing<br>
> code for a platform that is changed every time someone needs some new<br>
> hardware feature is a nightmare.<br>
<br>
</span>Not a nightmare but rather a skill. There are specialists for whom it is a<br>
profession.<br>
<span class=""><br>
> Given that anyone can change hardware<br>
> any time they feel like it, resisting the urge to do so is very wise.<br>
<br>
</span>This statement is not applicable to our field. We develop FPGA firmware<br>
not because of lack of wisdom, but because of necessity. A quick look at<br>
the required data rates will prove the point. I refer you to the example<br>
above.<br>
<span class=""><br>
> It may be worth seriously thinking how to create hardware modules that<br>
> integrate in a sensible way, much like the rest of Oberon. Hardware that<br>
> is 'loaded' as needed, perhaps. But that's a whole other project, isn't<br>
> it...<br>
<br>
</span>The whole industry exists around the "IP cores". Check the Xilinx website<br>
as well as OpenCores.org. All these IP blocks are precisely what you<br>
mentioned, except that they are usually statically linked rather than<br>
loaded on demand.<br>
<br>
The on-demand loading is named "dynamic reconfiguration" (DR). Check<br>
Xilinx website. It is supported by the FPGA tools, but it is way more<br>
complicated than statically linking the cores. There are special IP cores<br>
that help with dynamic reconfiguration. So this solution is both well<br>
developed and quite complicated.<br>
<br>
I am not even thinking of DR in the Oberon context. A simple BRAM concept<br>
seems to be causing some reception difficulties. Now imagine the criticism<br>
if I mentioned the DR. It is wise to stay away from this topic.<br>
<br>
Wojtek<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
--<br>
<a href="mailto:Oberon@lists.inf.ethz.ch">Oberon@lists.inf.ethz.ch</a> mailing list for ETH Oberon and related systems<br>
<a href="https://lists.inf.ethz.ch/mailman/listinfo/oberon" rel="noreferrer" target="_blank">https://lists.inf.ethz.ch/mailman/listinfo/oberon</a><br>
</div></div></blockquote></div><br></div>