Is Parallella really open?

Re: Is Parallella really open?

Postby Morgaine » Tue Aug 05, 2014 12:18 am

It's a pity that OpenCores' initial high profile project is the OpenRISC CPU prototyped on commercial FPGAs, the manufacturers of which all jealously guard their bitstream formats and require proprietary closed source tools to program them, as mentioned above.

If a h/w bootstrapping approach had instead been used, OpenCores could have started by designing as their Project #1 a simple FPGA architecture based on classic hardware designs on which patents have expired, and that FPGA could then have been used to prototype OpenRISC using completely open source tools. And then of course, Adapteva could have used that programmable logic capability for interfacing with Epiphany using completely open tools and hardware, FPGA included.

One can dream ... Maybe someday a fully OSHW FPGA and its complete FOSS toolchain will become a reality. :-)

Morgaine.
Morgaine
 
Posts: 42
Joined: Tue Jul 02, 2013 8:29 pm

Re: Is Parallella really open?

Postby 9600 » Tue Aug 05, 2014 7:45 am

Morgaine wrote:#1 a simple FPGA architecture based on classic hardware designs on which patents have expired.


Would it be possible to design and manufacture an FPGA, which is not patent encumbered and capable of supporting an OpenRISC or similar based SoC with reasonable performance? Even if it is, my guess is that the cost to do this would be way beyond the budget of an open source project that does not have significant commercial backing.

That said, I too would love to see an FPGA with comprehensive bitstream documentation available and support via an entirely F/OSS toolchain.

Cheers,

Andrew
Andrew Back (a.k.a. 9600 / carrierdetect)
User avatar
9600
 
Posts: 997
Joined: Mon Dec 17, 2012 3:25 am

Re: Is Parallella really open?

Postby Morgaine » Tue Aug 05, 2014 7:45 pm

9600 wrote:Would it be possible to
  1. design and manufacture an FPGA,
  2. which is not patent encumbered and
  3. capable of supporting an OpenRISC or similar based SoC
  4. with reasonable performance?

(Quote not verbatim --- I've taken the liberty of splitting up your question into 4 parts for easier reference.)

That would be an awesome question to address comprehensively in an ASIC design forum, but for our limited purposes here I think a much shorter answer might go something like this.

  1. OpenCore's highest profile product goal (beyond simply providing a very useful repository of open source VHDL and Verilog) is to produce an ASIC, and that ASIC happens to be for a SoC with an OpenRISC CPU. Such a SoC employs pretty much all the same digital ingredients as any other kind of plain digital SoC, namely synchronous logic implementing logic functions and memory cells, and it doesn't require elements which involve special technologies such as non-volatile memory, linear functions, radio frequency microstrips or mixers, nor high power drivers.

    Different ASIC technologies of this kind provide different tradeoffs of course, but in the end they're all just variations on a common theme, which put at its crudest is just defining and linking up gates to implement a variety of well-known functions. Some technologies are better for relatively long-distance routing as is commonly found in programmable logic, but even the least appropriate of them can do the job if pressed, especially if you have complete freedom to define your SoC architecture to suit your semiconductor process. In summary, if a team has what it takes to design and manufacture a CPU SoC, then they're fully equipped with what it takes to design and manufacture a programmable logic chip as well.
    .
    Answer: Yes.
    .
  2. We've been using and teaching logic design since the 70's or even earlier, and there is an enormous catalog of classic textbook digital circuits available for us to use within a fully OSHW programmable logic device. Most of these are so simple and obvious to an experienced practitioner in the field that patents could never have been granted on them (publication in a student textbook is an especially strong blocker), and patents have a limited lifetime anyway so anything patented prior to 1994 will now be in the public domain. Of course, in the US where frivolous litigation is an accepted business method, you can get sued for anything or for nothing and so this won't protect you, but OpenCores is based in Sweden, not the US.
    .
    Answer: Yes.
    .
  3. Your third question boils down to gate count and money. Could OpenCores (or anyone else in the OSHW camp) afford to manufacture an open FPGA device sufficiently large to host an OpenRISC CPU plus a few essential peripherals? I don't know, but I do know one thing: there is no shortage of people who would like to see an alternative to the totally closed ecosystems that are the only thing FPGA/CPLD companies see fit to give us, and who would be more than happy to buy such a device and write FOSS tools for it. I'm one of them, and I know many others.

    I strongly doubt that the required customer base would not materialize, especially if the support software were developed concurrently with the design of the device so that both become available simultaneously. Let's also remember that the customer base for an open FPGA includes the customers of all proprietary FPGA companies as well, but not vice versa (closed tools act as a disincentive for some, whereas open tools are not a disincentive for anyone). That's really good news for OSHW-friendly manufacturers entering the FPGA scene, as a broad customer base is ready and waiting.

    What's more, the incumbents in the FPGA industry don't really compete directly with each other because none of their products are pin-compatible nor bitstream-compatible nor SDK-compatible with anyone else's, so prices don't have much downward pressure. There is some competition because of the compatibility at VHDL and Verilog level, but the barrier to moving from one FPGA brand to another is so high that to some extent these ecosystems inhabit different spaces defined by investment in their proprietary toolsets. This makes it much easier for a new brand to emerge since there is no need for compatibility with an industry standard, as there would be if trying to enter the x86 or ARM spaces for example.

    And let's not forget the education sector, which tolerates closed tools and corporate capture only under the duress of nothing else being available. It's not a large sector in terms of direct commercial sales, but once in industry, engineering students will naturally tend towards systems they've already encountered before, so it clearly has commercial ramifications.

    Answer: Don't know, depends largely on pricing and promotion, but potential audience is large.
    .
  4. Performance of FPGAs is an interesting and important topic, but somewhat unexpectedly in the specific case of OpenCores it doesn't actually carry a huge amount of weight. The reason for this is that the FPGA is just a means to an end, a development platform for the design and testing of the OpenRISC design with a view to implementing it as an ASIC. When OpenRISC CPUs are run even on high-end FPGAs (eg. OR1200 on Xilinx ML501) they are typically clocked at no more than 50MHz, so the performance of the emulated CPU is less than stellar. In other words, nobody other than developers and a tiny number of enthusiasts will be running OpenRISC on the FPGA, so the performance of the programmable logic isn't really a primary concern for them.

    To some extent, that reasoning holds for other users of a hypothetical fully open FPGA as well, in the sense that a PL device has to be fast enough to implement one's desired functionality but no faster, since that would cost more and consume more power. Engineers are good at picking the right device to satisfy a given requirement, and aren't generally swayed by absolute speeds relative to the best in the industry, so there is always a market for lower speed devices if they provide other benefits.
    .
    Answer: Yes.

So as you see, I'm pretty upbeat about the prospects in this area, if only someone would dare tackle it --- that first step is the hardest.

While I'm at it, there are other benefits for manufacturers and users of fully open FPGAs which deserve to be highlighted. One such benefit of very great importance in industry is longevity of sourcing. Fully OSHW devices won't generally get End Of Life'd when a company moves to a new product, since someone else can easily step in to fill a void, or indeed multiple companies could do so and create an ecosystem. That's great if you value your investment in a technology, don't want that investment to be scuppered by supplier product cycles outside of your control, and like to keep your customers happy by offering product stability.

The savings for FPGA manufacturers stemming from not needing to run their own software division should be mentioned as well, because software teams are extremely expensive and a never-ending drain on profits from hardware sales.

Phew, sorry about the length, but I think it's a topic with enormous unfulfilled potential. :P

Morgaine.
Morgaine
 
Posts: 42
Joined: Tue Jul 02, 2013 8:29 pm

Previous

Return to Epiphany Operating System

Who is online

Users browsing this forum: No registered users and 1 guest