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

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