3 ms·

A welcome solution to a problem space in need of some serious simplification and standardization. To all the FPGA vendors out there, I want/need/have to use yo

A welcome solution to a problem space in need of some serious simplification and standardization. To all the FPGA vendors out there, I want/need/have to use your chips, I genuinely do not care about all the 20 thousand GUI-based idiosyncrasies you decide to add to your tooling every 3 months, in order to 'make my life easier'. Expose it through an API and document it fully (not partially). VHDL-2008 standard was published in Jan 2009, more than _eleven_ years ago, still to this day, it is not fully supported on most tools. How can you look at customers with a straight face and reasonably think that you should continue to add more GUI-based abstraction layers (looking at Xilinx Vitis), instead of focusing on the basics first. I sincerely hope that projects like Yosys, Symbiflow, GHDL, etc. continue to mature and grow. Equally important, I hope that vendors that support these projects (like Lattice) actually see a rise in market share because of opening up their hardware to open-source community toolchain. edit: corrected publication date of VHDL-2008

amelius 6y ago
> To all the FPGA vendors out there I wonder how many of them read HN. Perhaps it would be better to send them a letter? And perhaps these companies are making the "wrong" product simply because nobody ever tells them what they want.
- alxlaz 6y ago
  Technical reasons aside (some of these vendors are on 20+, even 30+ year-old codebases by now), the other big reason why they are making the "wrong" product is that the "right" product avoids some vendor lock-in and makes some of the consulting market redundant. As far as the product managers are concerned (or, more accurately, as far as the metrics based on which they're evaluated are concerned), the "wrong" product isn't wrong at all. End users have been complaining about all these "20 thousand GUI-based idiosyncrasies " forever, but they've nonetheless put up with them because at the end of the day you have to ship the damn thing. There's been no shortage of outside players attempting to "disrupt" this market. However, most of these attempts have been comical failures. Instead of addressing problems that FPGA/hardware engineers have, lots of these attempts were focused on addressing the sort of problems that software engineers have when they try to do FPGA development. Not necessarily (but, in some cases, also) due to sheer superficiality, but also because they are problems that are a lot more accessible when coming from outside the field, without a foothold in the FPGA manufacturing/development space (i.e. when you're not building tools for FPGAs that you design, manufacture and sell). So lots of these problems are very much WONTFIX: users have no meaningful alternatives, and fixing some of these things might actually even make it easier for alternatives to spring up (or at least for users to build various in-house tools that aren't so vendor-specific). Why would any FPGA vendor waste money on that?
  - gsmecher 6y ago
    Neither Xilinx nor Intel are in the business of making simulators (and in both cases, it shows). If there is an opportunity to graft the LLVM model into the FPGA world, IMO it's the simulators. Unfortunately it requires some creativity to support encrypted RTL in an open-source simulator, and both vendors require a way to supply simulation models without exposing source code. Doubly unfortunately, the open-source simulators are all language-specific and any attempts to bridge the gap have been only limited experiments. A brand-new simulator architecture seems necessary but has its oxygen starved by the rest of the ecosystem, open-source and commercial. I am watching https://github.com/llvm/circt https://github.com/llvm/circt with interest but I don't think this is quite focused on simulators the way I think is necessary.
- anitil 6y ago
  > Perhaps it would be better to send them a letter? They only take fax

amelius 6y ago

> To all the FPGA vendors out there I wonder how many of them read HN. Perhaps it would be better to send them a letter? And perhaps these companies are making the "wrong" product simply because nobody ever tells them what they want.

alxlaz 6y ago
Technical reasons aside (some of these vendors are on 20+, even 30+ year-old codebases by now), the other big reason why they are making the "wrong" product is that the "right" product avoids some vendor lock-in and makes some of the consulting market redundant. As far as the product managers are concerned (or, more accurately, as far as the metrics based on which they're evaluated are concerned), the "wrong" product isn't wrong at all. End users have been complaining about all these "20 thousand GUI-based idiosyncrasies " forever, but they've nonetheless put up with them because at the end of the day you have to ship the damn thing. There's been no shortage of outside players attempting to "disrupt" this market. However, most of these attempts have been comical failures. Instead of addressing problems that FPGA/hardware engineers have, lots of these attempts were focused on addressing the sort of problems that software engineers have when they try to do FPGA development. Not necessarily (but, in some cases, also) due to sheer superficiality, but also because they are problems that are a lot more accessible when coming from outside the field, without a foothold in the FPGA manufacturing/development space (i.e. when you're not building tools for FPGAs that you design, manufacture and sell). So lots of these problems are very much WONTFIX: users have no meaningful alternatives, and fixing some of these things might actually even make it easier for alternatives to spring up (or at least for users to build various in-house tools that aren't so vendor-specific). Why would any FPGA vendor waste money on that?
- gsmecher 6y ago
  Neither Xilinx nor Intel are in the business of making simulators (and in both cases, it shows). If there is an opportunity to graft the LLVM model into the FPGA world, IMO it's the simulators. Unfortunately it requires some creativity to support encrypted RTL in an open-source simulator, and both vendors require a way to supply simulation models without exposing source code. Doubly unfortunately, the open-source simulators are all language-specific and any attempts to bridge the gap have been only limited experiments. A brand-new simulator architecture seems necessary but has its oxygen starved by the rest of the ecosystem, open-source and commercial. I am watching https://github.com/llvm/circt https://github.com/llvm/circt with interest but I don't think this is quite focused on simulators the way I think is necessary.
anitil 6y ago
> Perhaps it would be better to send them a letter? They only take fax