Remember me

Register  |   Lost password?

The Trading Mesh

Leveraging FPGA-Enabled Acceleration Platforms For Financial Trading

Wed, 31 Oct 2012 06:35:33 GMT           

An Interview with Stephane Hauradou, ACCELIZE

31st October 2102

 

Sponsored by ACCELIZE (http://www.accelize.com)

 

In this interview for HFT Review, Mike O’Hara talks to Stephane Hauradou, Vice President of ACCELIZE, a leading provider of FPGA-based technology for the Financial Services Industry.

 

HFT Review: Stephane, welcome to HFT Review. Can we start with an introduction to who you are and what you do at PLDA/ ACCELIZE?

 

Stephane Hauradou: Yes, thank you. I’m one of the founders of PLDA Group, which was created in 1996 and has evolved to where we are today with its three entities: PLDA, ACCELIZE and ReFLEX CES. My involvement is mostly with ACCELIZE, where I handle operations, and PLDA, where I’m the CTO.

 

PLDA is a provider of semiconductor intellectual property (IP) and FPGA-based prototyping platforms, focusing on high speed interfaces such as PCIe and Ethernet. PLDA IP is used by over 2,000 customers worldwide, in a broad range of markets such as industrial, medical, military/defence, HPC, networking, etc… You could say that PLDA provides interface IP for the masses, and it’s been doing it for 16 years – it’s kind of the horizontal arm of our group, PLDA Group.

 

ACCELIZE on the other hand is the vertical arm of our group, providing FPGA-based technology to specific vertical markets, and focused right now on the financial industry and in particular the financial trading community. ACCELIZE leverages PLDA expertise and products to offer FPGA-enabled acceleration platforms for financial trading.

 

HFTR: Those products mainly being FPGA-enabled network interface cards (NICs), correct?

 

SH: Yes, the baseline products that ACCELIZE offers are FPGA-based programmable network cards.

 

HFTR: Why are you focusing on the financial trading vertical right now?

 

SH: Well, we’ve always been experts in FPGA technology but back in 2009 when we were looking at various options, we became increasingly aware of the need within the financial markets for FPGA-accelerated solutions. So we started to do some research and we learned about the various banks, exchanges and hedge funds that were trying to leverage FPGA technology to accelerate trading. We saw an opportunity, so we created ACCELIZE to leverage the expertise we already had at PLDA, bringing together the products we had in terms of cards, IP and so on, and packaging it together for this audience in the financial trading community.

 

HFTR: When you originally set up the ACCELIZE business in 2009, what kind of firms were you mainly dealing with?

 

SH: We originally saw two types of potential customers, the FPGA expert type; early adopters of the technology, with one or more teams of in-house FPGA designers, a past experience of using both off-the-shelf FPGA enabled appliances and designing their own FPGA adapters. These would typically be large trading firms, banks and exchanges. And the second type (which by the way represented the bulk of potentials) were software-only houses that may have used FPGA-enabled appliances but had very little to no FPGA design expertise. These would typically be smaller firms, like proprietary trading shops, but also large scale banks and hedge funds who were not yet investing in FPGA based trading.

 

HFTR: How has that changed since 2009?

 

SH: We’re still seeing those two populations but we’re starting to see a third group. A significant portion of the software-only firms that we saw back in 2009 are trying to bridge the gap, because they understand that by staying software only, they won’t be able to compete with the guys that already invest in hardware. So we’re seeing an emergence in off-the-shelf - or slightly customisable – FPGA trading adapter cards used for market data, feed handlers, etc, which provide these software-only companies with a low-risk, low-investment path to FPGA-based accelerated trading. The whole thing has become more accessible, basically.

 

HFTR:  Where has that growth been most evident?

 

SH: The growth that we’re seeing is definitely in the hundreds of trading firms who are now able to benefit from FPGA technology, initially with very limited, if any, FPGA expertise. In the past these firms had to rely on FPGA-enabled appliances with limited to no configurability, so basically no way for them to tweak the appliance at the hardware level to leverage the full potential of the FPGA.

 

HFTR: How much work are firms actually doing down at the chip level versus working with FPGA-enabled appliances?

 

SH: The trend is clearly to do more at the chip/adapter level. These firms are looking to own every aspect of the design and support themselves in the long run. And obviously working at the chip level enables levels of performance and latency tuning that just can’t be achieved with FPGA-enabled appliances in which the FPGAs are buried deep and far away from where the user interacts with the appliance.

 

HFTR: What kind of trade-offs (e.g. around latency) are firms having to make by abstracting themselves from the hardware level when using appliances?

 

SH: When you abstract the hardware by providing layers of firmware and middleware, you introduce latency and performance bottlenecks which ultimately mask the benefits and full potential of the FPGA. On the other hand working at the FPGA level and squeezing as much processing as possible into the FPGA and as close as possible to the wire ensures minimal latencies and optimal performances. The trade-off is then, do you want a system that is easy to program, use, and maintain but may not provide optimal latency and performance - in which case you would use FPGA enabled appliances, or do you want a system that is as close as possible to the wire for minimal latency and optimal performance – in which case you would use FPGA adapters, FPGA programmable feed handlers, and other types of FPGA network cards, knowing that these are, today at least, more difficult to program and maintain.

 

HFTR: In terms of business processes, where are you mostly seeing FPGAs being used? Does it mostly revolve around market data? Or are you seeing an increase in the use of FPGAs for handling order and trade flow?

 

SH: All of the above. Right now, the bulk of FPGA usage is around market data. But ultimately firms will want to go all the way and do it all on the FPGA. Because this is still relatively new technology for financial trading, FPGAs are seen as difficult to program and maintain, so the easiest place to start is on the market data front. When firms become more knowledgeable on the technology, when they invest and hire FPGA experts, then they are able to have more intelligence inside the FPGA and do things like order management, book building, pre-trade risk checking and so on. But that tends to be a second step after the market data and feed handling.

 

HFTR: For firms who are more used to working in the software environment, how challenging is it for them to move to an FPGA & hardware-accelerated environment?

 

SH: Sometimes we’re surprised to see that traditional software-only companies really are starting to take advantage of the FPGA technology, even though they have very little expertise in this field. They are eager to learn, they invest, and when that happens, they are certainly able to take the most out of the FPGA. But also keep in mind that over the past few years, you’ve seen a lot of vendors come out with “out of the box” FPGA-enabled adapters and NICs. Not appliances with tons of middleware and software, just simple programmable NIC cards that will do something like market data decoding or feed handling or risk checking for example. So there are a lot of different options for firms out there to start using FPGAs with minimal FPGA knowledge.

 

HFTR: All those different options mean that this is becoming an increasing crowded marketplace. How does your company set itself apart?

 

SH: What makes us different is principally one thing. We own and design all the pieces of the puzzle. If you look at other vendors in this space, some will have just the hardware, some just the IP, some just the software, whereas we have the FPGA hardware, the IP and the software, all of which we design.

 

Keep in mind that we don’t sell solutions, so we wouldn’t sell an FPGA feed handler or FPGA data acquisition card. We sell the technology, which is the hardware platform plus the important building blocks inside the FPGA to handle the I/Os and the infrastructure and so on, and we provide the software layers in terms of the drivers and APIs. So it’s a complete technology platform for customers or third parties to implement their financial solutions.

 

HFTR: Where is your geographical focus?

 

SH: New York and Chicago in the US, and we have an increasing number of customers in Western Europe, i.e. UK, France, Germany.

 

HFTR: What about Asia?

 

SH: In Asia, on the technology side, the markets are still growing. We’re working with a customer in India for example who connects our platform to the Indian market, but they’re still using 1 GigE, whereas most of Western European and US markets have already transitioned to 10 GigE.

 

Those regions may still be a little bit behind in terms of technology but they’re certainly catching up. And they will create a huge opportunity for vendors like ourselves.

 

HFTR: Where do you see the future of FPGA & hardware accelerated trading?

 

SH: I think we’ll see the emergence of what I’d call “smart FPGA processing nodes”, which are FPGA-centric network-attached cards or enclosures that would be able to receive market data direct from the network input port and then generate orders to their network output ports without requiring any connection to a CPU or server.

 

HFTR: With trading logic programmed onto the FPGA itself?

 

SH: Yes, everything inside the FPGA, starting with market data acquisition, decoding with built-in UDP offload, parsing, filtering, order book building, strategy & risk management processes and order generation with TCP offload out. And because it’s all FPGA-based, the strategies, logic and risk algorithms could be dynamically updated on the fly. So I see the trend is really to go towards a “bump in the wire” type architecture for the lowest possible and most deterministic latency. And with lower costs, because you won’t need servers any more.

 

HFTR: Getting to that point would involve some significant programming challenges in a pure FPGA hardware-based environment. So in conclusion, I’d like to ask your thoughts on the pros and cons of programming directly onto the FPGA (using Verilog or VHDL) versus putting this logic together in a higher-level language and then using something like a C-to-gate compiler to get it onto the FPGA?

 

SH: When we talk to customers who have a software-only background and are relatively new to FPGA, we ask if they tried using a C-to-gate compiler and how it worked for them. The answer is often that they tried it but without much success. On the plus side, you can certainly take a piece of algorithmic C and convert it to RTL and get some decent results in much less time than it would take you to encode something similar from scratch in VHDL or Verilog, but there are some serious drawbacks. First, it won’t give you the performance of directly encoded RTL. Second, it doesn’t take into account the bigger picture, in that once you have your block that you’ve created from C, how do you connect it to the rest of the FPGA? Because it’s not only about the algorithm itself, it’s about connecting it to the Ethernet port, the PCIe, the memory on the board and so on. Those things aren’t handled by these tools, so basically the customer ends up having to do it all himself. And they need FPGA expertise to do that.

 

I expect that in the future we will see the emergence of tools and methodologies that will allow customers to not only create those modules but also create a complete FPGA from a familiar C-type software environment.

 

HFTR: Stephane, thank you very much.

 

Click here to download this article as a pdf

 

, , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,