Has anybody actually used Fixnetix's FPGA solution for pre-trade risk management? I had heard scuttlebutt that one of the Really Big Banks had given it a try, but has come away less than completely impressed due to capability (incomplete solution) and lack of flexibility (bloody hard to reprogram outside a few basic parameters).
Fixnetix "FPGA"
- Thread starter Random.Capital
- Start date
I've used a few different approaches in the past, but they didn't really create much of an impact for me. I think their benefit over well-tuned software is miniscule, at least for the sort of things I try. Also, the boxed vendors always tend to make assumptions about working environments, so integrating their products tends to be irritating.
Hey Randon.Capital,
I read your comment. I have just joined the site today. The place I work is about to start a POC with them on this "new" product, is it worth doing...? Did you get any other members points of view?
Are "we" (teh royal we) wasting our time... it sounds like a great system on paper!?!
I read your comment. I have just joined the site today. The place I work is about to start a POC with them on this "new" product, is it worth doing...? Did you get any other members points of view?
Are "we" (teh royal we) wasting our time... it sounds like a great system on paper!?!
Hey @city...
Not sure I have a generic answer for you. If it's a fixed-function kind of deal, where the board has to perform X,Y and Z and those are well-understand (ie, a feed handler or aggregator), that "should" be a straightforward pay for services/product kind of development. It's not really all that complicated, so I'm genuinely curious why there have been so many problems in the past.
Is it a matter of the FPGA guys just not getting The Street's requirements?
Anyway, if you're doing a POC, I assume it's for something spiffier than the above. I don't know the details of what you need or what your partner thinks they can offer, but IMO, if it's a path towards what would be Verilog work back onto the software side of things, it may well be worth the time/money of a joint development.
*Somebody* is going to get that right. Whoever is first will have a decided advantage.
Not sure I have a generic answer for you. If it's a fixed-function kind of deal, where the board has to perform X,Y and Z and those are well-understand (ie, a feed handler or aggregator), that "should" be a straightforward pay for services/product kind of development. It's not really all that complicated, so I'm genuinely curious why there have been so many problems in the past.
Is it a matter of the FPGA guys just not getting The Street's requirements?
Anyway, if you're doing a POC, I assume it's for something spiffier than the above. I don't know the details of what you need or what your partner thinks they can offer, but IMO, if it's a path towards what would be Verilog work back onto the software side of things, it may well be worth the time/money of a joint development.
*Somebody* is going to get that right. Whoever is first will have a decided advantage.
I designed FPGA's for many years, I still do some FPGA projects on a consulting basis.
Here's the deal; FPGA's are "blank slates". You can put in a generic microprocessor, or, you can design logic with very specific requirements that will put to shame any commercially available processor.
Most microprocessors have a set amount of cache, a fixed register file, an arithmetic unit etc. These resources are fixed and aimed to accomodate all software programs relatively well, but no single program exceptionally well; micro's are designed to "fit all" in that sense.
FPGA's can be designed specifically for a given function, for example; say you want to multiply thousands of pixels at the same time *in real time*. One can easily create a massive bank of multipliers in an FPGA and do the math in nanoseconds (or on one CPU clock cycle).
To do the above with a regular processor, you'll have one arithmetic unit at your disposal and you'll be doing everything serially, one pixel per clock cycle... i.e. butt slow.
I suspect most people have difficulty with FPGA's is in realizing that is not a software program one is writing. The worst thing a group can do is hire a software engineer with no background in logic design/hardware architecture to do FPGA design. FPGA design is a different skill set and requires a specialized approach that is not at all like software engineering.
In fact, from my experiences software people should simple stay away from FPGA design unless they understand HDL coding and synthesis techiniques. Improper coding of an FPGA will make it lose all the intended benefit.
PM if you guys are looking for some guidance in designing FPGA's.
Mike
Here's the deal; FPGA's are "blank slates". You can put in a generic microprocessor, or, you can design logic with very specific requirements that will put to shame any commercially available processor.
Most microprocessors have a set amount of cache, a fixed register file, an arithmetic unit etc. These resources are fixed and aimed to accomodate all software programs relatively well, but no single program exceptionally well; micro's are designed to "fit all" in that sense.
FPGA's can be designed specifically for a given function, for example; say you want to multiply thousands of pixels at the same time *in real time*. One can easily create a massive bank of multipliers in an FPGA and do the math in nanoseconds (or on one CPU clock cycle).
To do the above with a regular processor, you'll have one arithmetic unit at your disposal and you'll be doing everything serially, one pixel per clock cycle... i.e. butt slow.
I suspect most people have difficulty with FPGA's is in realizing that is not a software program one is writing. The worst thing a group can do is hire a software engineer with no background in logic design/hardware architecture to do FPGA design. FPGA design is a different skill set and requires a specialized approach that is not at all like software engineering.
In fact, from my experiences software people should simple stay away from FPGA design unless they understand HDL coding and synthesis techiniques. Improper coding of an FPGA will make it lose all the intended benefit.
PM if you guys are looking for some guidance in designing FPGA's.
Mike
Every project I've ever seen that tried to "repurpose" SW folks by sending them on a 2 week Verilog course ended in complete and utter disaster. It's like asking a chef to do a 2" lift on my Jeep - they're just totally different worlds.
There is a middle path, where you restrict the subset of C/C++ allowable, provide some clever libraries and pragmas, have an extremely clever design on the FPGA, and hey, it's possible to write "software" that executes on the FPGA.
But that's a hard problem. From what I've seen Fixnetix doesn't appear to be very close to that. A couple of other FPGA board outfits, for all the (unfulfilled) promise of ESL, are essentially selling hardware as a loss leader on future services contracts.
IMO, etc.
There is a middle path, where you restrict the subset of C/C++ allowable, provide some clever libraries and pragmas, have an extremely clever design on the FPGA, and hey, it's possible to write "software" that executes on the FPGA.
But that's a hard problem. From what I've seen Fixnetix doesn't appear to be very close to that. A couple of other FPGA board outfits, for all the (unfulfilled) promise of ESL, are essentially selling hardware as a loss leader on future services contracts.
IMO, etc.
That sounds about right, ha.
Can you identify a specific market opportunity here that can benefit from our skill sets?
I've thought about ways to implement a blazing-fast modeling environment, but, the "meat" would be in ultra-low latency solutions; which, admitedly I have little experience with. I do some medium frequency trading (I've been a algo trader for > 10 years now) and most of the trading related techy stuff I do is in C++ and Excel.
My FPGA experience is mostly related to high-end image processing algo's, which, believe or not, transfer over to trading applications quite nicely.
It would be neat to apply some of my FPGA skills to financial applications, but, I haven't come across anything that is crying out for it. This is likely a result of my ignorance and lack of exposure to high end financial firms
I live in a really nice coastal town in CA and will never move to the financial centers, the urban lifestyle is just too much.mmmh interesting, I canât really say too much at the moment but will know more by the end of the week, the testing will start tomorrow on NASDAQ... full Dodd frank compliance as well as front-end demo!?! Apparently we will then be given the front-end to change settings in the product in near real-time... letâs see eh! I hope it works but not a 100% sure... will post later in the week... if you hear anything can you post? (in fact if anyone else is using this then please post...).