Ask HN: FPGAs for a small trading group?
3 comments
There's no guarantee that an arbitrary C/C++ task will map well onto/into FPGA. Ideally there should be a large number of subtasks that work in parallel with the end result that the overall pipeline (for lack of a better word) is shallow. FPGA clocks aren't fast - order of magnitude slower than CPU - but you can have a lot of simultaneous balls in the air.
Definitely there should be a purely software model, long before you start thinking about Verilog/VHDL and the actual hardware devices to fit them into.
I don't think the developer needs trading experience, especially if a high level model already exists. It should be a well-defined and testable black box.
Definitely there should be a purely software model, long before you start thinking about Verilog/VHDL and the actual hardware devices to fit them into.
I don't think the developer needs trading experience, especially if a high level model already exists. It should be a well-defined and testable black box.
As far I understand it, FPGAs are used in trading for their low-latency response. It is hard to respond in software much faster than 5 us, even using kernel bypass, etc.
They're not implicitly low latency though. FPGAs are about having the control and resources to structure workloads to complete in a minimum number of clock cycles. It's not an automatic thing you get by cross-compiling a C program onto a different platform.
I'm interested in thoughts or war stories around these topics:
- Should we build a C or C++ version of the FPGA first to clarify the exact behavior and define the interfaces to the master trading system?
- Have you been involved in the move from low latency software to FPGAs? How did it go?
- Is it critical for the FPGA developer to have trading experience? Being in Colorado, there aren't many (any?) trading FPGA people around.