Role for FPGA or CPLD with Raspberry Pi

There's a nice new write-up of Valent F(X) FPGA boards for RasPi and BeagleBone at Linux Gizmos: BeagleBone and Raspberry Pi gain FPGA add-ons.  Boards not yet available commercially, but they're considering a Kickstarter.

Very interesting.  I had a good chuckle at "LOGI-BONE SLIM" and "LOGI-BONE PHAT". :-)

Care to hazard a guess at pricing?

I'll ignore the somewhat offensive tone and address the substance of your comment.

At no time did I suggest that I would be investing my time in writing FOSS code for FPGA development. The most likely source for such funding would be one of the smaller silicon vendors and the reason that they might do it is that rather than pay Mentor\Aldec etc for the subsidised use of their tools they could fund FOSS and leverage the open source effort that this might attract.

Your perspective of FPGA design is obviously limited by your Altera/Xilinx focus, I already sell designs which people use and I don't use Altera or Xilinx parts. As I explained before I use a paid-for simulation tool.

I'll leave it to others to correct your rather weird generalised open source antipathy - I don't happen to use Linux but I do use some open source tools - and I find the range of quality to be not much different than paid-for but the cost is lower.

MK

Frippy Frippy wrote:

 

An open source tool chain for FPGA design is frankly a ridiculous idea, all FPGA vendors release and support their own proprietry design software and trying to integrate all the features that they support into a single tool is, well the first question I would ask is why the hell would you even want to think about attempting it?

 

The whole idea is typical of the open source software community as a whole, nerds with nothing better to do than bleat about linux.

I've been advocating for open FPGA documentation for decades, so I'll be happy to address this topic.  Basically, the problem with proprietary tools in general is that if they don't suit your needs, you're stuck.  Here are some of the issues with FPGA tools:

1.  FPGA tools (I'm most familiar with Xilinx and Actel/Microsemi) have a very steep learning curve, which makes them hard for new users to learn.  Since most Xilinx / Altera / Actel / etc. customers are experienced, none of the vendors see that this is a problem.  Indeed, their marketing literature says that the tools are gloriously simple to use, and you can't expect solutions from people who don't recognize that they have problems.  The steep learning curve makes FPGAs hard to teach, so this wonderful technology is out of reach of many who could benefit from it.  It would be like Intel only allowing people to program their processors in PL/M, while refusing to expose the machine language so that others could write compliers.

2.  FPGA design languages -- VHDL and Verilog -- have a lot of problems.  While they aren't too bad for expressing behavior, it's very tricky to use them to create the hardware you actually want.  The choice usually boils down to which one hates the least.  But they're the only way in, so you're stuck with two ugly choices.

3.  FPGAs ought to be a wonderful technology for high-performance reconfigurable compute engines, but the tools aren't up to the task: see this Geek Times article.  I talked about this last April in this element14 discussion:

There was a lot of talk over the decades about FPGAs being used as reconfigurable compute engines.  This use has never really had any traction, and my hypothesis is that this hasn't occurred because FPGAs are too hard to design with using the current tools.  The tools are fine if you're designing a custom chip for a product and your other choice is ASIC.  But if your other choice is to wire up an array of high-performance microprocessors, the FPGA solution is too difficult.

 

If FPGAs were open like many microprocessors, people who could solve this would work on it.  But given that any results will be "purely academic", the kind of people who want to see something actually working (e.g., all engineers) have no incentive even to start.  It's IMO truly a missed opportunity, but could be rectified at any time by an FPGA vendor if it chose to do so.

4.  When I buy a chip, I'd like to be able to use it for whatever I want, rather than have "digital handcuffs" limiting what I can do with it.  Otherwise it's like buying a car and being told I can only buy gas from one particular vendor, I can only use the car to drive to certain approved destinations, and I can only get repairs from the dealer.  This a basic argument behind Free-as-in-Freedom (FaiF) or Free (Libre) Open Source Software (FLOSS).  If you think that what you're allowed to do with the products you buy should be left to the seller, that's your prerogative.  FaiF / FLOSS proponents think differently and advocate for this freedom.

As to the question "why would I want to do it?", that's easy: because I think I can write better FPGA tools to address some of my needs than what I can buy or download from the vendors, and solving these kinds of problems is something I find passionately interesting.  As a proponent of open documentation and FaiF/FLOSS software, I'd want to share the result.  Most people wouldn't find this fun, but then not that many people find 16x16 Sudoku puzzles fun either.  I'll let Mr. Knightly from Jane Austen's Emma speak for me: "Very well. If the Westons think it worth while to be at all this trouble for a few hours of noisy entertainment, I have nothing to say against it, but that they shall not choose pleasures for me."

Very well presented and argued, John.  I agree in every respect.

The day that you have a rudimentary open source tool that works with a specific programmable logic device, whichever that may be, I'll be very happy to buy the hardware and experiment with your code, and hopefully help you improve it.  It never hurts to have extra testers, and that's a very low barrier to entry for anyone wishing to support the development of open source EDA.

this is absolute rubbish,

VHDL is both a simulation and design language the fact that you find it hard to use is not down to the language but down to your lack of understanding over how to use it correctly, if you have difficulty learning a tool the best way to understand it better is to practice using it. there is no demand for an open source FPGA design tool because nobody else has the issues that you state that you have,

Ive been using Xilinx, altera and actel tool sets for donkeys years and Ive seen many attempts to rewrite VHDL into something simpler but they always fail due to the huge complexity of the task. The complexity of writting a VHDL synthesis tool capable of handling all devices from all vendors and covering all the VHDL functionality and verifying that it works correctly is stupendously large.I know for a fact that the latest synthesis tools from Xilinx for example took something in the region of 575 man years to write and verify,  and you get it for free..

I once had some idiot telling me that he wanted to rewrite XST because it couldnt handle the complexity of his code, puzzled I had a look at his code, the reason XST couldnt handle it was it written as if it was software and was full of aysncronous feedback loops so XST was spitting it out. He was a self proclaimed software genius.

I'm a long term VHDl user but I'm currently forcing myself to use Verilog on a project in order to widen my horizons. There are a great many Verilog users and I doubt that the only reason that they don't use VHDL is prejudice or stupidity. By the same token it is obviously possible that a better solution than either VHDL or Verilog might be devised.

It isn't necessary to leap right in and write a complete tool chain to make a contribution. One of the downsides of VHDL (and Verilog) is the number of mindless (but significant) lists of ports required to define and join up different components. There are several relatively simple tools you can use to manage or automate this process but I'm sure that better ones are possible.

Starting from the other end is possible too - VHDL -> FPGA sysnthesis is very complicated but gate level -> FPGA could be quite simple. It was essential to get any performance out of Xilinx's first FPGAs with an 8 x 8 array of logic cells.

The problem with the current situation, where the tools are almost all closed and locked to some degree to the silicon vendor, is that experimentation is usually directed towards gaining market advantage which is not always alligned that well with the long term. Having more competition and more lateral thinking in FPGA tool development would be a good thing.

MK

IMHO the "good thing" that would come from an open source FPGA compiler would be that the open source community, together with universities, can work on algorithms and methods to improve the whole process for everybody. i.e. improve the set  of known algorithms and methods for the world as a whole.

Such a compiler would need to be well-thought-out, so that it would be very modular. Then incremental improvements can be made. Someone improves a placer, someone makes a better router. Sometimes such a step takes the form of an improvement of an existing program from the "suite", sometimes it is a new algorithm in a new addition to the suite.

This allows universities to set tasks for students like: implement this improved algorithm in the free-fpga-suite. Or allow researchers to suggest improved algorithms and test them out.

Once things start rolling, it should become relatively easy to extend the suite with smaller projects. New output modules for specific architectures, or just a new chip.

For the users who don't want to mess with the code, the advantage is that they get better uniformity between vendors. Now if you write something for a xilinx, porting it to altera means you probably run into a few snags. Things that don't compile right away. That's called vendor lockin. They like that. It makes it harder for you to go to the competition, yet not hard enough that they can't win over the big professional players.

Software compilers are more "common" than the hardware ones. So if 1% of the users is able to contribute, you have a much larger pool of developers for say "GCC" than the "open source FPGA project". That in turn might mean we're missing a "critical mass" for things to start rolling.

So... Although I think it's likely that "it will never happen", I do see advantages to the open source FPGA project. Maybe if I was a professor at a university I'd be able to get such a project going. But as it is I'm not in a position to invest the required amount of time and effort in such a project.

rewriting the language or rewriting the tools because you dont know how to use them is not the way forward, the 'digital handcuffs' are there to ensure that designs are done to best practices.

You are writing that in response to what?
YOU are the one making that point with your XST post.

Roger Wolff wrote:

 

IMHO the "good thing" that would come from an open source FPGA compiler would be that the open source community, together with universities, can work on algorithms and methods to improve the whole process for everybody. i.e. improve the set  of known algorithms and methods for the world as a whole...

 

So... Although I think it's likely that "it will never happen", I do see advantages to the open source FPGA project. Maybe if I was a professor at a university I'd be able to get such a project going. But as it is I'm not in a position to invest the required amount of time and effort in such a project.

I don't think it needs an organized project.  Indeed, my experience at trying to get academics to work together on anything is far worse than "herding cats".

But what it does need is FPGA architectures with open documentation so that interested individual researchers can see something actually working instead of just writing papers.  Then people can work on the bits that interest them, and if they release the results under a FaiF license the community will be able to collect the results.

Roger Wolff wrote:

 

IMHO the "good thing" that would come from an open source FPGA compiler would be that the open source community, together with universities, can work on algorithms and methods to improve the whole process for everybody. i.e. improve the set  of known algorithms and methods for the world as a whole...

 

So... Although I think it's likely that "it will never happen", I do see advantages to the open source FPGA project. Maybe if I was a professor at a university I'd be able to get such a project going. But as it is I'm not in a position to invest the required amount of time and effort in such a project.

I don't think it needs an organized project.  Indeed, my experience at trying to get academics to work together on anything is far worse than "herding cats".

But what it does need is FPGA architectures with open documentation so that interested individual researchers can see something actually working instead of just writing papers.  Then people can work on the bits that interest them, and if they release the results under a FaiF license the community will be able to collect the results.

[I wrote most of this yesterday and then forgot to hit send. It "belongs" a few posts up.... Sorry about that.]

I do think that having the right "project setup" is important.

For example, the way cadence and quartus are setup means they are a set-of-programs that allow manipulations on the state of a "database" of your project. This is good. This is also the way the panorama stitcher "hugin" should work. Now a gui-and-does-some-operations is available that mixes operations on the state and the GUI. Thus it is sometimes necessary to delve into the gui to fix something algorithmic.

Having the right "design" will make things easier for people to contribute. But having the wrong design doesn't mean that nobody will. But I think the critical mass will be more, so that I'm afraid it will be even harder to achieve.

On the other hand, some of the (IMHO) badly designed open source projects are still succesful. But in this case I'm afraid this design-issue might be more important for the project to gain enough traction.

Roger Wolff wrote:

 

Now a gui-and-does-some-operations is available that mixes operations on the state and the GUI. Thus it is sometimes necessary to delve into the gui to fix something algorithmic.

That's a very good point.  It's one of the biggest downsides of software projects today (both open source and proprietary ones) that the concept of separation of GUI and business logic just hasn't emerged.  You'd have thought that through the development principle of "separation of concerns" there would be a standalone user-configurable graphic UI application available, uncommitted to any particular application, to which application designers could interface their application logic without needing to hack any graphics code.  Alas, that's unheard of, AFAIAA.

It's a big pity.  I've been involved in projects requiring a complex GUI (for example virtual world clients), and the complexities of protocol and 3D object management are dwarfed by the complexities of developing the GUI, which is an unnecessary overhead and a distraction.  Even worse, GUI appreciation is extremely subjective and as a result the developer's choices are never appreciated by more than a handful of its users, so the end result is always somewhat unsatisfactory.  If GUIs were entirely separate from application logic then users could employ their favourite GUI configured to look however they desire as a graphic interface to many different applications.

It's been on my mind as a worthwhile project for a long time.  There is no shortage of very well respected and portable graphics programming and GUI libraries, so it's always amazed me that nobody's bothered to program an uncommitted and fully user-configurable standalone GUI program yet.  Application developers are forever chained to the pit face of dedicated GUI development as well, and it's a waste of time for everyone concerned.

Yes, I've been thinking about a "uncommitted GUI" program as well. The thing is, to make it a "gui", the user needs to be shown the "state of the project" and there are likely going to be interactions with that "state" by the user clicking and so forth. That's the hard part.

Not too hard.  What we traditionally consider objects within a view (for example a SOIC package or a D-latch or a falling edge on an LA trace) are really no different to GUI objects like buttons or menus or selectable letters in a panel.  We've just been mentally programmed to think of them as different.

A user-configurable GUI program would provide an API to every element it contains without exception.  As long as an external application has a flexible (network) API through which to reach those elements, the application developers can stick to their business while the GUI developers can stick to theirs, and neither of them has any business telling the end user how the application should look graphically because that's each user's business.  (Although the application developers would naturally provide the initial example through which they've been driving their application code.)

On a small scale, web browsers offer a tiny amount of configurability of their GUI.  In Firefox for example you can select from a smorgasboard of a couple of dozen different elements and place them where you like on any of the toolbars.  However, there is no ability to associate commands or protocols or APIs with any of them, it's all entirely fixed by the browser having the single and preprogrammed purpose of interfacing to the web.  And even worse, the application view in the main browser window is not determinable by the end-user at all, but wholly by the remote end.  That's the opposite of the goal of separation of concerns that I'd like to see happen.

Themable widget sets are also a small step in the right direction, but they tend to focus more on eye candy  than on functionality.  Most importantly though, nobody has used such a widget set to create a standalone GUI program which application developers can then deploy without having to hack graphics code.

Among the many awesome features of such separation would be that application developers could develop their code in whatever language they wish, totally unconcerned by the language in which the GUI application happens to be written.  Not only are network interfaces totally language-agnostic, but they are also license barriers, so that an application developer wouldn't need to be concerned with the licensing of the GUI, nor vice versa.  In today's lawyer-infested technical environment, that would be a major win for everybody (except lawyers).

For completeness, I'll just mention that there is one type of graphics program that is entirely standalone and uncommitted to any given application.  It's the window manager, and there are hundreds of them.  Unfortunately nobody has yet used that awesome concept as an archtectural model for separation of concerns in applications development.