It's not that bananas, as a TCP connection is just a state machine, but you do need to plan how many simultaneous connections you want upfront and whether to copy all the logic for each one or find some way of sharing the logic and having a state table in memory somewhere.
Do you know if Argon Design hires graduates? I would love to break into the HFT / FPGA design space, however it seems like the barrier to entry is rather high.
I don't work there any more due to moving to Scotland, but entertainingly I'm still in the carousel of employees at the top of that page. They absolutely do take graduates but only good graduates; you'd need a 1st or 2:1 from one of the top universities. Note that they're a consulting firm that do all sorts of things and may not currently be doing any HFT or FPGA projects!
This company http://exablaze.com/ (which I do some work for) builds FPGA based NICs and switches nearly exclusively for the HFT industry.
Arista discontinued the 7125FX switch (with an FPGA in it) because of limited uptake. In the end, I think this was for 2 reasons, 1) by the time the switch got to market, the FGPA was slow and out of date 2) only 8 ports of the switch were FPGA enabled and because of 1) were slower than regular ports. The switches made by Exablaze use very modern FPGA's (Xilinx Ultrascale) and the entire switch is implemented in the FPGA, yet is one of the fastest (if not the fastest) switch you can get.
ASICs aren't necessarily faster these days.
Some of that clock speed comes down to floor planning, which takes a lot of design hours, which ASIC project generally takes more design hours than FPGA anyway.
I am not in HFT so maybe not the best to answer, but ASICs just wouldn't work for HFT.
Basically FPGAs favour low volume, highly configurable projects. Whereas ASICs favour high volume, very defined projects.
Seeing as HFT algos must change often there would be great benefit in being able to reconfigure FPGA.
ASIC you would be stuck with your old HFT algos.
ASIC also are $$$ to produce an initial run, the initial run can also have bad HW bug in it which cannot be fixed and ASIC needs to be respun again, costing more $$$.
It works for Bitcoin, because people lots of small consumers would buy Bitcoin ASIC with simple and non changeable algo and because of the bottom line power usage mattered.
HFT firms I imagine don't care about performance per watt.
It's not that bananas, as a TCP connection is just a state machine, but you do need to plan how many simultaneous connections you want upfront and whether to copy all the logic for each one or find some way of sharing the logic and having a state table in memory somewhere.