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?

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.

Frippy Frippy wrote:

 

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'll speak to Verilog and Xilinx since that is what I use most.  I don't like to type more than necessary and I have limited space for source code listings.

I'm able to get excellent results from Verilog and Xilinx tools, but it's not easy.  If you want to get the right results from Verilog (and I assume VHDL) you have to write your source code so that XST matches the templates to use the correct FPGA resources.  Since I did my Ph.D. and later industrial and academic research on CAD tools, it's easy for me to visualize how XST works and help it get the right results.  I think I'll call this Human-Aided Computer-Aided Design.  It's like a primitive C compiler with poor optimization where the programmer needs to know how to write source code that helps the compiler generate decent machine language.

My point upstream is that this is a lot to dump onto a new FPGA designer.  Sure, an experienced Verilog or VHDL designer has learned how to write code to conform to the eccentricities of the tools, but newbies are going to have a lot of trouble -- something that gets worse as new tool releases add more complexity and steepen the learning curve.  Duane Benson gave an excellent talk called "FPGAs: I know nothing... yet" at the 2013 DesignWest conference.  Duane is an accomplished microcontroller designer and wanted to give his perspective on the challenges of coming up the FPGA learning curve.  The reality from Duane's point of view is that it's really hard to get started.  As I said upstream, the FPGA vendors seem to think that everything is fine and dandy in Toolsville, an opinion you seem to share.

Regarding the complexity of the VHDL tools: yes, I suppose if I were using VHDL as the starting point the problem would be intractable for an individual or a small group.  I also wonder what the late John McCarthy would say if he saw Xilinx's code?

John, one of the differences between VHDL and Verilog is that VHDL is more verbose. Thinking it was more or less an arbitrary choice I went for VHDL first time. The verbosity gets annoying after a while. I had to integrate some Verilog one day and decided to switch.

In C I stick to the rule that I prototype my functions. VHDL requires the prototypes. But whereas a C-prototype will usually be about a line, a VHDL prototype will be about a page.... So that's one of the VHDL things people are complaining about.

Anyway, getting open source FPGA "bootstrapped" means one language -> hardware trajectory implemented. Then adding input modules and output modules should be easy to help things along.

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

Derek Campbell wrote:

 

> The two devices aren't even remotely the same in capability nor price.

 

Totally agree. However, the Guzunty is my baby and I am very sensitive to devices that might be perceived by some to be better. :-)

I just saw in a comment at Geek Times that Guzunty Pi is now available in the USA and Canada at cost from Amazon (US$16.51 plus ship) and Ebay ($21.50 incl ship).  In fun, easy-to-assemble kit form with socketed CPLD.

Yes indeed. :-)

Thank you to Mark MacMillan for acting as a distributor in North America.

Yes indeed. :-)

Thank you to Mark MacMillan for acting as a distributor in North America.