Ask HN's FPGA users: FPGA tool woes & wants?

(From two guys building a webapp for FPGA users)

Any fellow FPGA users on HN? If you don't mind taking a moment to share your thoughts; it'll be really helpful!

We'd love to hear about: - what you dislike about existing FPGA tools - what you'd want in FPGA tools; and - whether we're building would be useful

Here's our take: 1) Dislikes: - Being forced to choose a specific FPGA before compilation(synthesis, place-and-route etc.) when I don't even know which FPGA suits my application. - Installing, maintaining, upgrading bulky software tools on local PCs. - Taking weeks/months to learn a particular tool from just one FPGA vendor. 2) Wants: - Ways to automatically match an FPGA app to the right FPGAs. - in terms of speed, size, power, etc. - FPGA tools hosted and updated somewhere else. - A single user interface that translates user inputs for all vendors' FPGA tools.

Existing tools don't seem to do these things, so we started building a webapp with the above features.

Ran the idea by the folks at YC and they had questions about how useful our webapp would be after the FPGA programming files are generated and the user needs to test on real hardware. (Answer: Not very; our webapp will just ensure that the user ends up buying and using the most suitable hardware)

Beta site: http://www.plunify.com

Thanks for reading; looking forward to your comments!

I have only done a small amount of FPGA programming, so my comments may not be that useful.

I have only ever used a Xilinx FPGA or CPLD, so seeing how an app would compare on different FPGA's would be interesting, although for the apps that I have developed it probably wouldn't matter that much.

I do agree that the current suits are often bulky and take a long time to learn.

My comments may not be that useful, but I love seeing any thing that is related to embedded programming on HN. Great work!

Just having builds go way faster would be awesome. Shove some static analysis in there for warnings, and maybe collect user feedback to feed into a statistical model of the likelihood that the warning was indicative of an error. Take real advantage of being a webapp.

I think you should run far away from emphasizing the matching of a core to it's most cost-effective target -- it's not something you need to do until you actually have something nearing the need to buy a shitload of parts and ship. You generally develop on one of several overpowered dev boards that you already owned. Pitch the multi-hardware parallel build as testing, not chip selection: 'what targets is my build not totally broken on'.

When I was doing some rather oddball FPGA development (trying to do Alan Kay style pedagogical CPU dev) I would have killed for this. I was attempting to build stuff with as little HDL as possible for clarity purposes, and would frequently fuck myself over when the Xilinx tools couldn't synthesize or place-and-route it anymore for my Spartan-3 hardware. Some of it was just their incompetence, where a hand-laid design could fit easily, but a lot of it was just classic traveling salesman problem woes. It would have been a lot easier to see what the real constraints I was hitting if I knew which chips it didn't work on anymore.

The vendor compiler toolchains are fucking dogshit. Just having that hosted and guaranteed not to collapse in on itself would be golden. You should also develop simple desktop software for flashing the builds for at least Linux and Mac OS X. At one point I wrote my own flasher from scratch that sucked but Xilinx's Windows flasher had shat itself on me and I couldn't get it to work again (the Linux stuff never worked at all, ever). Make a simple drag-and-drop flasher. You could even sell a rebranded USB-JTAG that's guaranteed not to suck.

Simulators are ridiculously awful, but you're not going to come anywhere near fixing that.

"that the user ends up buying and using the most suitable hardware" is a side effect of some of your features, not the real use case you should be selling. It feels somewhat greasy, because at some level you're just marketing hardware to me. Even if you do try to monetize that through some kind of affiliate thing, don't put it up front. You'll spook the engineers.

If you're targeting professional engineers, I'd worry that A. They could figure out the answer to these questions on their own, or if not, B. one of the large distribution companies would only be too happy to send out a sales engineer to assist with the decision making process.

Are you targeting the hobbyist market? I'm not sure how much money they might have.

Thank you for your comments.

Some thoughts in response to your comments:

> professional engineers > A. They could figure out the answer to these questions on their own. [harnhua] True - what they would gain by using our webapp is convenience and automated testing/evaluation.

> B. one of the large distribution companies would only be too happy to send out a sales engineer to assist with the decision making process. [harnhua] Probably only if one is buying enough FPGAs/CPLDs to pay for that sales engineer? I reckon there should be many small-/medium-volume projects staffed by professional engineers who wouldn't attract such a level of customer service from the distributors. Sales engineers who're skilled in FPGAs are probably in short supply.

> hobbyist market [harnhua] Although there's little money there, we'd really like to make FPGAs easier to use for students and hobbyists as well.

Any thoughts?