[Oberon] FPGAs are no longer FPGAs

[Jörg]

Wojtek

I fully understand your reasoning for productive environments.
ProjectOberon was born as a lecture to show how HW and SW go hand in hand for a language design.
Especially, how a CPU influences the compiler and vice versa. eg make the CPU instruction set as regular as possible because it simplifies the compiler a lot.
And for educational reasons, NW didn’t want to depend on a huge amount of external „cores" he would have to teach/explain first. Not only the SW should be as simple as possible, but also the HW should be as simple as possible.

And you saw in this thread where his „simplicity“ rule ends up:
* The SW guys debate why this and that feature is not included in the language, because it's so useful and other languages have it…
* And the HW guys point out that the FPGA design is not as it should be…

The limit is the sky, on HW side as well as on SW side. But it often happens that the „complexity“ it adds is purely optimization and hides the principles.

br
Jörg

> Am 17.10.2017 um 02:13 schrieb Skulski, Wojciech <skulski at pas.rochester.edu>:
> 
> 
>> So, a proper design would look something like this.
> 
>> [cid:image001.png at 01D33FBA.8D9CD950]
> 
>> According to the Xilinx text, the main problem seems to be the skew. 
>> As RISC-5 only runs at 25 MHz, it might be that there is a lot of time reserve 
>> and the different arrival times of the clk signal do not matter so much…
> 
> Joerg:
> 
> actually, this practice is discouraged. Strongly discouraged, I would say. Maybe one day it was OK, but today one is supposed to use the Digital Clock Manager (DCM) provided for the purpose of dealing with clocks.
> 
> On a more general note. DCM is just one of many "cores" provided by a modern FPGA. As the article (below) says: "FPGAs are no longer FPGAs". They are no longer composed of just gates and flip flops, but rather they delivers lots of hard silicon cores that are supposed to be used. The trick of generating the clock without using the DCM is not taking advantage these highly optimized cores, and thus it is impacting the performance. 
> 
> The article did not discuss another facet of modern FPGA programming, which is "soft cores". Not everything is being delivered as a hard core embedded in the FPGA silicon. An increasing number of solutions is delivered as "soft cores", which are prepackaged pieces of HDL, well tested and documented. Vendors like Xilinx often deliver the soft cores precompiled without source. Fortunately, good quality open source soft cores are quite abundant. (Look at OpenCores or Hamster Works.) My own personal choice is to always look at the available cores before embarking on my own development. The original Oberon System did not use this approach. That's fine, but my own preference would be to replace at least some of the present design with either soft or hard cores. In particular, implementing fast memory interfaces is plain impossible without using hard memory controllers provided by FPGA vendors.
> 
> So to summarize, your proposed clock solution is good for a tutorial, but it should not be used in practice, unless performance is truly not important.
> 
> The article is available here: 
> 
> www .fpgarelated .com/ showarticle/357/how-fpgas-work-and-why-you-ll-buy-one
> 
> Note that I broke the line with spaces to prevent our University mailer to mess it up in a ridiculous way. 
> 
> Wojtek
> 
> <image001.png>--
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon