|
|
|
|
|
by jjoonathan
2163 days ago
|
|
I don't mean to belittle your exploration, but are you sure it's an apples-to-apples comparison? This suggests to me that it isn't: > it seems like hardware engineers have a fetish for all-encompassing painful vendor specific IDEs Hardware engineers feel pain just like you do. The reason why they put up with those awful software suites is because they have features they need that aren't available elsewhere. In particular, they interface with IP blocks and hard blocks, including at a debug + simulation level. Those tend to evolve quickly and last time I looked -- which admittedly was a while ago -- the open source FPGA tooling pretty much completely ignored them, even though they're critical to commercial development. If you are content to live without gigabit transceivers, PCIe controllers, DRAM controllers, embedded ARM cores, and so on, I suspect it would be relatively easy to use the open source tooling, but you would only be able to address a small fraction of FPGA applications. |
|
I wasn't talking about open sourcing. I accept we won't have open source DRAM controllers and the like from them. I understand the licensing restrictions. I just don't like how they force all this stuff to be gatewayed through their baroque and over complicated GUI tools.
I prefer tools that are scriptable, that can work with the build system of my choice, that work properly with source control (imagine that!), where you have your choice of editor rather than having their garbage one rammed down your throat, where there's wizbang features like reformatting and auto-indentation... Hell, even refactoring.
Vivado and Quartus just get in the way. There's no reason to tie all the stuff you're talking about into an integrated tool. They could just ship libraries.
Fusesoc does in fact try to make them behave this way. But you can tell it's a bit of a war to make it happen.