Mouse wrote about FPGA development tools:
...except that you have to (a) be willing to run
either Windows or
Linux, (b) run on their choice of hardware, and either (c1) set up a
very heavily firewalled sacrificial system or (c2) trust the security
of your system to code they aren't even willing to let you look at.
I'm not willing to do (c2) at all, and not willing to do either (a) or
(c1) unless I'm getting paid a fair bit to do so ((b) might join (a)
and (c1), if their required hardware is something I don't have, though
that's highly unlikely).
Better get used to not doing FPGA development, because the situation is
not likely to change any time soon. EDA tools for FPGAs is a very hard
problem, far more complex than e.g. schematic capture or PCB layout, and
after quite a few years of people working on those, the results are
somewhat usable but nowhere comparable to commercial tools.
Altera and Xilinx have invested literally thousands of many-years into
their tools, and it is unlikely that anyone is going to develop a
comparable open-source alternative in the foreseeable future.
Note that if you use any PCI/PCIe/PCI Express/Expresscard/PCCard Wifi
interface or RAID card in your computer (with very few exceptions), you
are already trusting the security of your system to closed-source code,
which is the firmware that runs on the processor(s) embedded in the
card. For >99% of those cards, the closed-source firmware has the
potential to access any memory in your computer and do anything with
it. USB Wifi cards, if they have an open-source driver, avoid that
potential security problem.
For that matter, the latest Intel and AMD processors have a fair bit of
closed-source microcode, and you have no way to verify that there isn't
any kind of back door embedded in those, perhaps at the behest of a
Three Letter Agency.
I'm much less concerned about tools than I am
about documentation on
the hardware's interface, on what the bits in the blob thrown at the
hardware mean
Xilinx tried selling a line of FPGAs for which the configuration
bitstream details were publicly documented, the XC6200 series, and no
one bought it. The reality is that 99.9999% of the customers are
perfectly happy to feed Verilog and/or VHDL into the FPGA vendor's
toolchain, and don't care what comes out as long as it works.
The closest you'll get with Xilinx is the "FPGA Editor", which lets you
view and modify an intermediate low-level logical view of the part that
doesn't exactly match the physical bits that go into the FPGA, but which
the tools can translate into the actual hardware configuration
bitstream. (The tools do NOT offer a reverse translation.)
I don't know whether Altera offers comparable (or better) tools for
dealing with their parts at a low level.
(and how to thrown them at it, though that part is
much
more likely to be documented).
Yes, Xilinx and Altera document the configuration interface(s) pretty well.
I'd love to get into FPGA hacking. But not nearly
enough so to
tolerate something as abusive towards their users as "you have to run
our closed-source code". :-?
Unfortunately there are so few customers or potential customers that
feel that way, so it isn't really even on their radar.
Eric