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

Cannot sign up. It says "Please tick on the checkbox below to agree to the terms and conditions. Thank you." even if I click it.

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.

First thing I wanted to click: the pretty color bar picture (http://www.plunify.com/images/plunify_graph.gif ); needs to link to a bigger version.

Also, if you're using Flash for static charts, I'd suggest replacing with pictures (no Flash player, nothing to see in http://www.plunify.com/reports.php )

[clicky for the site: http://www.plunify.com/]

I'd like tools for OSX.

With a web-app like this, I would be concerned about IP issues. Half the industry is banking on IP unless they are open-source like the OR1K. Otherwise, a proprietary house might be hesitant to upload HDL code even if it is over a secure SSL connection.

For simulation with Icarus Verilog, it might be possible to upload the compiled VVP binary. You can sell your computing power as a utility (ala cloud computing) and help people save cost from buying an expensive server and save time from having to wait days for results.

For FPGA selection, I personally doubt that your tool would be that useful because this decision is primarily dictated by the cost of parts - rather than the specific features. The hardware business is very cost-driven. What you can do is to provide customers with the ability to perform synthesis over multiple architectures for the purpose of 'testing' that their code works on them all.

I don't think being locked down to a specific FPGA is as big a deal as you think. In professional circles, FPGA choice is mostly a matter of your company being an Altera shop or a Xilinx shop, and which FPGA they've used in the past. For large customers, FPGA companies work quite closely with their customers so things like support and availability of parts at the quantity required means far more than exactly what features are in where. For many hobbyists, typically what matters is what peripherals ship with the cheapest dev kit as much as how many LUTs and memory blocks are on the chip.

But, on the flip side, some of the most annoying and agonizing decisions that you end up making over a lifecycle of a project is whether to upgrade to the newer / newest releases of various software. As you guys undoubtedly know, setting up these software is not trivial, and getting it to a point where a reasonable workflow exists can be pretty damn painful. And with every upgrade, you might get a nice compilation and synthesis speed upgrade coupled with a memory bug here and configuration but there. Something that some people might have a use for, is ability to target not just across different chips, but different versions of the software, not as a chip selection utility, but more as a tool selection utility might make a little more sense, where you provide fine control over exactly which version of tools are being used, as well as commonly used knobs for configuring the various parameters of place and route & synthesis options (of which there are plenty)

Even with that, though, I don't know if this is a service that a lot of people will find useful. As sybreon points out, IP cores are a huge part of FPGA development flow and I don't really see a way to easily handle that aspect of things. Many of the IP cores spit out encrypted HDL and I think pretty much every tool vendor has a different format that they can handle. Also, a lot of people are pretty tied to their simulator of choice, with libraries and custom TCL scripts to massage things just right, and I'd imagine it'd be difficult to move things like that over (though I did not go through the signup process to try things out myself).

I've been out of FPGA arena for couple of years now, but I think places to focus within the FPGA marketplace, especially in areas where people will pay real $$, is in testing and verification. Back in the days, many people used FPGA like they would a software compiler - try few lines of code, hit compile, check it out, rinse and repeat. With the increasing complexity of the designs due to ever increasing gate count, trying to develop like that doesn't work so well. If you could, for instance, take in a verilog or vhdl module, do some simple analysis to figure out input / output ports and the sensitivity list, and beat the crap out of it (using both user-defined data set and random / smart / fuzz sets), you might have something there...

The HORRIBLE point facing FPGA creation is the tools just don't tell you when you've accidentally made silly circuits.

There should be much better errors/warnings letting you know when you've written VHDL/Verilog that doesn't turn into standard logic gates and systems, when you've done things that have easy to identify race conditions, and when you've written things that just don't make sense.

After working with computer code compilers, and analyzers like lint and clang, it is still sad to look at the errors (and lack of errors) coming out of VHDL/Verilog tool chains and not see something even 2 orders of magnitude of useful as far as toolchain output. WAY too much Field application engineer time is spent on junior engineering problems that can't be effectively delegated due to this insufficient machine error checking.

I mean, half the time you generate something that will simulate differently than run in real life, that's OBVIOUS from the code structure. But no, the toolchain doesn't identify that, bench checking the specification to the VHDL is the only way to find that (or a code review by another engineer).

So TLDR: Make VHDL or Verilog spit out REAL errors and warnings when used somewhat incorrectly, or likely incorrectly. Bring the tools up to the standard of sequential coding tools, or even more in that direction instead of the morass it still is today for hardware specification languages.

I know many companies wouldn't allow your tool to be used for IP related concerns. Perhaps you should make your tool into a downloadable service?

Is there a way to tackle the problem of IP vendors not wanting to upload their IP? The reason why we are online is that we can leverage on the cloud and make things run 5X, 10x or 20x faster and cheaper.

But will we ever get the IP vendors to trust us? We once thought about doing an 256bit AES client for them to encrypt their data before sending over. But after chewing on it, we felt that the problem is a perception issue. It is a matter of trust. It is like we use our credit cards online because we trust the payment merchants with our details. Will this problem eventually be eroded by time?

Oh btw, I am harnhua's cofounder. Thanks for all the wonderful views and insights.