What are people doing with FPGAs? I'd be really interested in understanding or seeing some cool projects!
FPGA's are an essential part of high speed trading these days.
Developing open-source FPGA tools
51–60 of 80 posts
Re: Developing open-source FPGA tools
#52What are people doing with FPGAs? I'd be really interested in understanding or seeing some cool projects!
Few applications I have worked on lately involving FPGAs:
- RF and microwave, direct digital synthesis.
- Data acquisition and analysis (fast, very fast)
- Time of Flight imaging/video
- Timing critical process control
Re: Developing open-source FPGA tools
#53For 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.
Verilator is gaining traction as the de-facto open-source simulator for industry and hobbyists. VCS is still the sign-off simulator, but at least there’s mounting pressure to support both.
Re: Developing open-source FPGA tools
#54Earlier quoted context omitted.
Psst…I think you mean "silicon".
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.
I removed those sticky e's from your fine comment above. I hope that's ok. It makes the discussion less distracting.
Re: Developing open-source FPGA tools
#55For 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)
The situation for Vivado (Xilinx) is more or less the same, Tcl for everything but terrible documentation.
Re: Developing open-source FPGA tools
#56For 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…
Xilinx's toolchain is the worst piece of software I've ever had to work with. There are two things that amaze me: 1. That the dumpster fire is actually capable at all to synthesize hardware without exploding 2. That their head of software still has a job.
I'm so happy to read ratings of Xilinx here. I'm a novice to the world of FPGA, and I've spent so much time fighting the tools.
My very favorite issue is with their IDE. The version I'm using has a broken search and replace... if the two strings have different lengths, the editor loses its place after the first replacement -- they compute the location of matches and then just smash the replacement strings in... failing to maintain an offset as character offsets change. Makes me scream.
Re: Developing open-source FPGA tools
#57Earlier quoted context omitted.
>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.
IIRC, the configurable logic took the place of the CAMs in the routing table mainly. There's cool niches where FPGAs make sense due to their on the fly reconfigurability even more than a purpose designed asic would.
Re: Developing open-source FPGA tools
#58Earlier quoted context omitted.
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.
IIRC, the configurable logic took the place of the CAMs in the routing table mainly. There's cool niches where FPGAs make sense due to their on the fly reconfigurability even more than a purpose designed asic would.
Do they really alter the images "on the fly" when traffic is flowing? Or do they have some situation where it's OK to stop traffic on their network interface for a short while?
Re: Developing open-source FPGA tools
#59What are people doing with FPGAs? I'd be really interested in understanding or seeing some cool projects!
Analogue Nt's consoles all rely on FGPAs to emulate the original systems on a hardware level.
Re: Developing open-source FPGA tools
#60Earlier quoted context omitted.
IIRC, the configurable logic took the place of the CAMs in the routing table mainly. There's cool niches where FPGAs make sense due to their on the fly reconfigurability even more than a purpose designed asic would.
Do they really alter the images "on the fly" when traffic is flowing? Or do they have some situation where it's OK to stop traffic on their network interface for a short while?
Yeah, they do. They might drop a few packets during a partial reconfiguration if a stream is still in progress, but that's bound to happen anyway on routing changes.