What are people doing with FPGAs? I'd be really interested in understanding or seeing some cool projects!
Building an improved Amiga accelerator and a new standalone byte-compatible Motorola 68K Amiga
Developing open-source FPGA tools
41–50 of 80 posts
Re: Developing open-source FPGA tools
#42What are people doing with FPGAs? I'd be really interested in understanding or seeing some cool projects!
Preserving old CPU architectures and building fun retro arcade machines of them:
http://www.racketboy.com/retro/mister-fpga-the-future-of-ret...
Re: Developing open-source FPGA tools
#43Earlier quoted context omitted.
OpenSCAD is a nice example of how this kinda stuff can work. It's nowhere near viable as a general purpose CAD program, but the concept could easily scaled up to the level of SolidWorks. Its file format works very well with version control systems, is human readable to an extent and can be opened with any text editor (so your data isn't 100% gone if one bit gets accidentally flipped).
It's worth pointing out that OpenSCAD was started by Clifford Wolf, who went on to develop Yosys, the synthesis tool used in these open FPGA workflows.
TIL!
Re: Developing open-source FPGA tools
#44What are people doing with FPGAs? I'd be really interested in understanding or seeing some cool projects!
Making hardware that can be patched when speculative execution goes specularly wrong.
Re: Developing open-source FPGA tools
#45Earlier quoted context omitted.
Haha indeed! I will leave it for traceability. I had to apply some bathroom silicone sealant over the weekend so I just go ahead and blame it on that.
And we use silicone thermal paste on top of a piece of silicon ;-)
Nothing but the finest pulverized silver for me, thanks ;)
Re: Developing open-source FPGA tools
#46I think the best way to support this kind of effort is to have more people know what FPGA is and what they can do with it ... So they can use the tools and tinker with this stuff. So if you're into this space just write more content : articles, how-to's, videos, tutorials etc.
Also, more SW programmers should be getting into this field, as by working in SW first you realize all the things that need improvement in the FPGA world (which the FPGA people didn't recognize, not knowing how SW is done in the modern world, or got used to).
Re: Developing open-source FPGA tools
#47Earlier quoted context omitted.
Motor control for a pretty high number of motors. There's rumors that a couple of the big cloud vendors use them on network cards for SDN. Integration with non standard peripherals like ku band radios on a satellite.
>There's rumors that a couple of the big cloud vendors use them on network cards for SDN. No rumours needed, the papers are out there in the open.
For network cards specifically it seem surprising that it wouldn't be more economical for the big three to roll out custom silicon instead of FPGA.
Re: Developing open-source FPGA tools
#48For those who are not familiar with silicon vendors' toolchain, it really is very poor quality especially when they started pushing for GUI based Graphical/System development. Vendors make money selling silicon, they see the toolchain as a necessary evil. There are 2018 tools that are still unable to fully support VHDL-2008 standard. Many bugs reported years again remain open. And often the GUI centric approach means…
The toolchain for ASIC/EDA in general is very poor. In 2019 I'm amazed that an open-source HDL simulator is not the de-facto industry standard. The big 3 EDA vendors charge astronomically high prices for simulator licenses, yet Verilog/VHDL along with simulator APIs (DPI/PLI) have been standardized for decades.
Re: Developing open-source FPGA tools
#49For those who are not familiar with silicon vendors' toolchain, it really is very poor quality especially when they started pushing for GUI based Graphical/System development. Vendors make money selling silicon, they see the toolchain as a necessary evil. There are 2018 tools that are still unable to fully support VHDL-2008 standard. Many bugs reported years again remain open. And often the GUI centric approach means…
> Also specifically with Xilinx they seem to have zero consideration for basic version control and create/duplicate/modify an explosion of files and cached versions of files. There is an ugly feedback loop here. HDL tools interact poorly with version control -> it is difficult to collaborate using those tools -> HDL engineers would rather silo up than fight the tools -> no pressure to improve tools' support for versi…
Perhaps there is some truth in your assessment but I think the lack of pressure on tool support is more related to the lack of industry-grade alternatives, more so than HDL teams clinging on to a desire of developing like it's 1989. The reality is that nowadays HDL teams are composed of a lot of people with CS and CE background, who are obviously aware of sane development processes and practices. You will find that a lot of people simply use their text editor of choice and then just use the vendor's tool whenever absolutely necessary with a 7 foot pole (from a script or CLI if possible).
The problem again (in my very speculative opinion) is that you have a very limited set of vendors who have a complete lock down on their hardware.
Imagine a world without gcc or llvm and only Intel or AMD could provide you with a compiler. Imagine also that they would provide you with this compiler for free, such that their business model was entirely based on them selling their CPU's. How much pressure would they have in providing a high quality toolchain?
It's not like their customers are gonna run away to a non existent competition they still need to buy CPU's and they would be stuck with their 'barely works' toolchain.
You can see the difference if you compare FPGA vendor software with HDL simulation software. Simulators are in the business of selling you software so they have pressure to actually deliver quality software. FPGA vendors are in the business of selling _silicon_ (@saagarjha) so they pretty much see the toolchain as an operational cost.
Re: Developing open-source FPGA tools
#50For those who are not familiar with silicon vendors' toolchain, it really is very poor quality especially when they started pushing for GUI based Graphical/System development. Vendors make money selling silicon, they see the toolchain as a necessary evil. There are 2018 tools that are still unable to fully support VHDL-2008 standard. Many bugs reported years again remain open. And often the GUI centric approach means…
If you're using Intel's Quartus tool (Altera), pretty much every option is exposed through a Tcl API. You can accomplish everything without ever opening the GUI. The biggest problem is that those Tcl APIs are usually not documented very well...even for us internal developers (I used to develop Quartus)