To the extent that BlueArc is successful and PLA-based designs begin to dominate the I/O world it would seem that this would conflict with WIND's plans in this area. If it's all done in hardware there's no need for embedded software at the card/interface layer, no?
The answer is no, but the process of getting there is the fun part.
When we talk about it all being done in hardware, let’s agree we insist on retaining full functional equivalence to IxWorks running on an Intel IOP. The IOP itself does a lot of special, I/O things automatically with the PCI bus; the OS does lots of things like implement the VxWorks API and I2O message handling; and finally TCP/IP particulars are implemented probably as middleware. Since it was extremely difficult to develop all this in software in the first place; it would be mind-boggling to try to reduce it to hardware. A pure hardware solution have to be based on a dramatic simplification, with the only possible justification being that increased speed reduces the requirements for much of the flexibility (I know George Gilder would buy that logic).
That’s not how it will develop, because we seriously want all the functionality included in the iTHINGS. In particular, we want to be able to add and update software applications that implement security and all sorts of other data manipulation possibilities. Just as the ASIC solution I mentioned in the previous post lacks adequate functionality, so would any conceivable solution based solely on hardware whether programmable or not. Remember, the hardware-based solution must replace WIND’s IP and Intel’s microprocessor IP – a very tall order.
But that’s not the end of the story. At higher networking speeds, say 10GbE, Intel/WIND will find it even more daunting than in the past to maintain all the desirable flexibility and keep up with network traffic. The solution cannot be to depend on Moore’s Law to provide a super fast microprocessor; either Moore’s Law won’t keep up or the cost of the microprocessor would have to be prohibitively high. There is only so much tuning WIND can do to IxWorks, or optimization of TCP/IP protocol processing.
The solution will be hardware – and I am not contradicting myself.
But this is how it will be done. The future IOP will consist of the equivalent of the current IOP plus an FPGA (no doubt these and fast memory will reside on a single, multi-core chip, but they can be separate devices.) A monitoring program will keep track of the frequency with which each software program gets executed. This includes programs imported to implement security or any other feature. It can include middleware, protocol handling, or just about anything. On a frequency and available resources basis, the monitor would select a particular program and compile it to HARDWARE and cause invocations of the routine to access the hardware solution instead of the solution in software. This solution gives the best of all worlds, complete flexibility provided by software with the speed of hardware determined dynamically.
Compiling to hardware has always been done as a major undertaking, possibly taking days if not weeks, and would require testing to verify results. No more. A C-language program can be compiled in regular fashion nowadays, except the output is in a hardware description language, not machine language for a particular microprocessor. The compiler output is then put through a place and route algorithm to output a configuration file that drives the FPGA. The configuration file is put in fast memory (like SRAM) and voila; the program runs in hardware 100 times faster than in software. There will be a few delicate complications to add spice, like what about timing issues when a program all at once runs 100 times faster than before? Also, the program running on the FPGA has to have the same access to subroutines and system resources in the microprocessor as the original software program. This implies the FPGA program probably will need to be wrapped in a software shell that accesses all the needed resources accessed by the original program. WIND can figure it out. They love this stuff.
The Intellectual Property embedded in this adaptive hardware/software solution is greater than what is contained in WIND’s current TINA offering, by far. Indeed, if one day the entire solution could be converted to hardware thusly, WIND’s IP carries over just like it would with an ordinary binary file. Both are compiled from proprietary source code. Hardware will become an increasing part of the solution, but not at the expense of software or WIND’s IP.
I’m not playing make-believe. WIND is developing this capability as we speak, probably day and night. WIND calls it “reconfigurable computing” and they and I are really excited about its possibilities. I mentioned it the other day in one of the mega trend posts, but this provided an excellent opportunity to show how and why it might be deployed. WARNING: don’t try this with your Windows open.
Allen |
