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?

John Beetem wrote:

 

Speaking of "cuddly CPLDs", I guess Morgaine never saw (or has forgotten) the old MMI PAL data books, which were filled with cartoon drawings of friendly, smiling "PALs" in standing-up DIP packages.

I have in front of me Monolithic Memories' Programmable Logic Handbook of 1985 featuring a cuddly and smiling PAL sitting on a die on page 1-5, and on page 1-6 waving a rod at a very non-smiling PROM teaching it new tricks.

Some things just can't be thrown away.

Jean-Paul Louis wrote:

 

I have been using the Lattice family since the GAL families in the 80's.

I have Lattice's GAL Data Book from 1989 on the shelf here too, but it has no cuddly smiling chips.

Morgaine Dinova wrote:

 

Jean-Paul Louis wrote:

 

I have been using the Lattice family since the GAL families in the 80's.

I have Lattice's GAL Data Book from 1989 on the shelf here too, but it has no cuddly smiling chips.

The only advantage to companies' not giving away or selling data books any more is that you never have to throw away old data books to make room for new ones.

Pack rat?  Moi?

Edit: Woo hoo!  This is my post number 1000 (decimal)!

Well I did throw away most of my PDP and VAX handbooks.  I hope Drew isn't listening.

Addendum:

John Beetem wrote:

 

Edit: Woo hoo!  This is my post number 1000 (decimal)!

Congratulations!

Packrat? moi? naw. I just can't part with my 1975 RCA COSMOS Digital catalog.

Who remembers Silicon on Saphire?

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.

@FF

The economics may be different but in principle the idea of FOSS support for FPGA design is not that different from the GCC concept. At the higher levels of abstraction the tools are (in both cases) hardware agnostic. Actual fitting and routing into an FPGA is very hardware specific (although I'm not sure that FPGA architectures are any more diverse than processors'). The usual way this is dealt with is by a vendor supported software component but completely independent designs are possible.

The question as to why is perhaps less obvious - quite good FPGA tools are available free or very cheap but when you need serious tools it starts to cost a bit more.

The VHDL/Verilog simulator that I use on a day to day basis costs more than £10k - you can get the same thing for free in a crippled  version (artificially slowed down). If there were an open source version it would run at full speed for everyone so that would fit nicely with the silicon vendors free router/fitter.

The open source community has every right to crow/bleat/be-proud-of Linux - it is hugely successful and has done a lot to stimulate the efforts of others to make better stuff at better prices.

MK

If you have so little to do in your day job that you think rewritting huge amounts of code to no good effect is a good use of your time then maybe you should come and work for me and we'll get you doing real world designs which we have to sell to real customers using the code supplied by the likes of Xilinx and Altera.In my company we spend our time making money by selling designs which people use, rather than dicking about with open source crap.

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

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.

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.