High Frequency Trading and EDA

Pop quiz – name an event at which an EDA vendor would be unlikely to exhibit. How about The Trading Show in Chicago, later this month? That’s trading as in markets, high-frequency trading, blockchain and all that other trading-centric financial technology. This is another market, like cloud, where performance is everything and returns easily justify investments in hardware design.

Of course, what these people are aiming to build is not smartphones or routers in the very latest semiconductor processes. They’re much more interested in personalized design – specialized applications (in this case high-frequency trading – HFT) built for proprietary advantage and never intended to be offered in the open market. And like their compatriots in the cloud, they’re very attracted to FPGA-based design for its flexibility, the rapidly increasing capability in those platforms and (comparatively) low development cost.

In automated trading, latency in trade information can have a huge impact on money made or lost. Simply aggregating ticker feeds from as many as 200 markets, each supporting its own format, was a task historically handled by software but with some latency in managing and massaging those inputs. Replacing that software with FPGA-based feed management can reduce latency in this stage by 5-10X. As in the cloud, there’s still a balance between the flexibility of software and the performance of hardware; some processing remains on CPUs, while more stable functions which need to be as fast as possible move to FPGAs. Solutions of this type are already in production use.

It’s not just about quickly consolidating ticker data. The trades themselves must be decided much faster than a human trader could respond. Deciding which trades to make requires intelligence, unsurprisingly using machine learning (ML) methods. That could be an opportunity for FPGAs, especially in ML algorithms with high-levels of parallelism benefitting more from FPGAs than multi-core CPUs, but lacking the neural net characteristics which fit so well to GPUs. However, I couldn’t find anything suggesting FPGAs are being used in this way today.

Risk management and order execution are other aspects of automated trading where FPGAs can help. While ML may suggest a trade, risk management monitors these suggestions in the background to ensure they do not fall outside trader-advised windows. Order execution, consolidating planned trades and fanning them out to the relevant markets to execute buys and sells, is yet another area where FPGAs naturally offer advantages in parallelism (sort of the inverse of the ticker aggregation task). In both these cases, FPGA-based solutions are in production today.

So now back to my opening question – why would an EDA vendor be exhibiting at a trading conference? FPGAs are playing a bigger role in automated trading, leveraging multi-billions of dollars in transactions. But these folks are traders. They have lots of mathematicians and lots of programmers, but they don’t have a lot of FPGA designers. Yet their differentiation hinges on how well their hardware performs – and that’s a moving target. Also, suppliers emerging around servicing these requirements, for smaller traders and retail companies serving day-traders, have the same needs. Which means that that it has become very important to be able to design and often re-design these systems to squeeze yet more advantage as competitors advance.

None of this has been lost on Aldec who, as an FPGA design verification and prototyping supplier, seem especially well positioned to take advantage of this opportunity (they apparently already have several customers in this space). They are exhibiting at the Trading Show in Chicago this year and Louie de Luna (Marketing Director at Aldec) was interviewed by the group that puts on the show. I’ll just touch on just a couple of points from that interview.

One that may trigger apoplexy in the ASIC verification community is momentum behind Python/cocotb for building testbenches (see here for background and a demo), rather than UVM. HFT engineers apparently don’t care about our sacred cows. They’re more than happy to switch to any solution that can get faster to completed verification. Louie cited one example where a UVM approach took 5k lines and 30 days to get to a result that missed some bugs, where the Python/cocotb approach completed with 500 lines of code in 1 day and caught those bugs. I’m sure this won’t always be true, and would probably not be generally true for large designs, but it is an interesting stat in its own right. No-one is suggesting UVM be replaced by this solution for mainstream ASIC design. At the same time, UVM may have already lost the battle in HFT and that may portend similar shifts in other personalized design flows.

Louie also talked about the importance of prototyping boards being available to test designs. He stressed that different algorithms often need different resources, perhaps more DSP primitives for floating-point-intensive calculations, or multiple small memories for highly-parallelized transaction processing. It is difficult to fit all these into one solution so Aldec offers a family of boards based on Xilinx Virtex-7 and UltraScale in multiple configurations, along with the software to manage them.

As an editorial sidebar, I should add that I am becoming quite impressed by this company. They’ve been around for over 30 years and most of us have probably dismissed them as a minor player in a space dominated by the EDA giants and others close to the core of “real” EDA (I’m guilty too). But something has changed at Aldec. I have no idea what triggered this but they seem to be getting a lot more aggressive, especially in FPGA-based design and even more in supporting applications where FPGAs themselves are growing rapidly. Relevance to high-frequency trading is just one recent example. Aldec are reinventing themselves and arguably, by complementing mainstream (and some not-so-mainstream) EDA solutions with a range of application-specific prototyping (perhaps even beyond prototyping) boards, they may be redefining the span of EDA.

You can read the interview with Louie de Luna in full HERE and the latest board announcement for HFT applications HERE.