re: open_hitter

I'm somewhat happy; this project passed proof-of-concept stage last week! The core of the core code passed unit tests on fpga hardware. After some to and fro in the code, removing the start button and starting the test automatically every second fixed it, but as a result there's some remaining untidiness to clean up.


What does it do?

In equities trading it's common to split out the engine that calculates prices (which needs to be smart) from the exchange-facing engine (which needs to be super-fast). For example there are still successful pricing engines written in Java, but for the exchange engine/adapter we needed to write engines in optimised C and use special NIC's from Chelsio/Solarflare. Nowadays I didn't think you would start a system without fpga, but there are still firms starting new exchange adapters in C++.

This open_hitter is an instance of a particular kind of exchange adapter that engages in a race to send priced orders in response to a great deal, just appeared on the market. The race is against other trading firms who also want that great deal (and this particular trading engine only applies outside of the USA, for example in Korea, where the first arriving order gets priority and can win).

So imagine there's a pricing engine, calculating and recalculating the prices (and quantities) that are worth sending as orders. This engine would send these to the hitter engine as a stream of udp packets. The fpga can listen on a NIC and file these potential orders into its internal store. The fpga also listens to the latest prices arriving from the exchange, and for each arriving price it consults the internal store to see if there's a matching order already there. Any matching order also has a price indication, and from this the fpga can calculate the order to be sent to the exchange (and decrement the internal store). This search of the internal store can be really quick in parallel on fpga, and this was the concept step working on fpga as of last weekend.


Some challenges and issues

I was much impressed by the multi-valued std logic feature in vhdl, in particular supporting 'Z' (high impedance) which would be a great feature if it was actually physically implemented on modern fpga hardware. Currently my internal store is limited to about 200 cells (sharing geography with microblaze) which is way short of the 20,000 cells I'm aiming for.

Similarly the order/price structure is clunky and repeated. It would be great to have this more parameterised/overridable for different exchanges. Similarly the tcp/udp message parse needs to be parameterised/overridable .. hoping to use code from another project here but haven't researched or really thought it through, let alone approached other project owners.

Wondering how Open I can finally make this. Currently stuck in endless recursive research through Soc possibilities. Fusesoc looks nice, but doesn't do Xilinx. Do I divert to it and help (maybe there's a reason and adding Xilinx would be too hard) or buy a supported board with a couple of NICs. Currently the final synthesis still has to be proprietary .. but it would be great if I could lock up the install/build in a vagrant script.

Open or not, the design needs to be realisable by enthusiastic newbies. What's that going to look like .. hopefully a linear wiki page and wireshark timings.


Nice surprise

Epiphany moment: I had one LED on a 125,000,000 count (ie flashing once a second) and some other LEDs indicating success of an intricate algorithm where any dropped bit would trigger a fail. Awesome rock solid performance. That's physical hardware ticks, real hardware subject to temperature, voltage transients etc. Got to me it did.


Anyway, I hope that some of the above will be of interest. The bar is so high in terms of the expertise out there, that it had got to the end of the weekend and I still couldn't write - so I decided to write anyway!

Best regards,
Stephen

Granted, my only personal experience is with Xilinx and Altera FPGA architectures, but I'd venture a guess that most "modern fpga" hardware supports tri-state-able I/O pins... What leads you to believe that it doesn't? It'd be difficult, without external hardware, to selectively electrically isolate an FPGA from, say, a bus, without some kind of tri-state implementation.

Sure. You are right about I/O pins, but I was hoping to use the same kind of logic inside my search unit (and I don't have any evidence that the synthesis via alternate structures ?mux is actually linked to my problem).

I get hits searching on 'virtex internal tri-state support', and I think that this is the article I was remembering when I posted news;

http://www.quora.com/Can-Z-in-VHDL-be-synthesized-for-FPGAs
... has three answers and seems authoritative eg;
Current FPGAs don't have internal tri-state buffers- floating signals are bad because of power and SI reasons. Intstead, modern synthesis tools will try to discern what the designer wants, and implement it in gates that only use logic 1s and 0s. As Malcolm said, external tri-states are still available.