Your FPGA tool wishlist?

[bagelfire]

Hi,

What would you like to see in a good FPGA tool?

My company is a software startup looking for ideas to implement in the FPGA space, and this is a survey to find out what FPGA users and developers would want.
So if there are features that you would like to have, please let me know and we will seriously think about implementing it!

Some things we are doing so far:
- putting open source simulators like GHDL, Icarus Verilog on the web as web applications for users to run simulations online
- letting users submit requests to implement Verilog / VHDL code on any Xilinx or Altera device(s), and we will run them in parallel and give users the results.

There are so much more we can do for example improving error-checking and parsing of warnings, graphical design entry, etc., but we'd like to focus on the features that most designers want.

Our aim is to simplify FPGA design and testing wherever we can.
So if you don't mind taking a moment to write down what you want, that will be very helpful! We'll give out our services free to users whose wishlists we end up implementing.

Thanks!
- mike

 

[cim123]

works natively on llinux for once.

Manish

 

[bagelfire]

Not sure which tools you're referring to, but Xilinx ISE and Altera Quartus both run fine on Linux.
Perhaps Lattice or Actel?

 

[supercat]

What would you like to see in a good FPGA tool?

I've not done FPGA's--just CPLD's, but one thing I'd like to have would be a simulator that could take in a couple fusemaps (JEDEC files) and use one as test-bench for the other. I'm sure many people would look down on ABEL as a language, and indeed it does have some feeble design quirks, but for situations where circuit behavior may be adequately described in terms of equations for various combinations of T, D, C, LE, ASET, and ACLR, writing something in ABEL seems far more natural than writing in Verilog or VHDL.

As for the simulation, I'd like to have the simulator expand each pin of the "chip" under test into three: Output_enable, Output_data, and Input, to allow the test-bench "chip" to adapt its behavior to the device under test in ways that would otherwise not be possible. For example, the test-bench could simulate a heavily-capacitively-loaded port pin by keeping the input to the device under test low for some time after its output has switched to high.

Simulators which try to model device behavior based on something other than a fusemap are prone to yield inaccurate results if the device fitter yields something other than what was specified. Simulating based on the fusemap would ensure that any fitter strangeness will show up in the simulation. At least for a CPLD, generating a model from a fusemap shouldn't be too hard; not sure about how easy or hard it would be with an FPGA.