
Ask HN: FPGAs for a small trading group? - HockeyPlayer
We are a small prop group, historically very focused on speed but our system is still in software.  We are considering building an FPGA to provide fast orders in response to some events.<p>I&#x27;m interested in thoughts or war stories around these topics:<p>- 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?<p>- Have you been involved in the move from low latency software to FPGAs?  How did it go?<p>- Is it critical for the FPGA developer to have trading experience?  Being in Colorado, there aren&#x27;t many (any?) trading FPGA people around.
======
pinewurst
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.

~~~
HockeyPlayer
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.

~~~
pinewurst
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.

