The CTO of Xilinx came to MIT to check out the 6.111 projects and to give a talk on the future of FPGA. He mentioned most of the stuff I babble about in this blog. He discussed the need for better tools to increase the transparency of targetting FPGAs to open the market up to computer scientists (who outnumber us Electrical Engineers by 100 to 1). He also specifically mentioned dynamic partial reconfiguration and the need for an operating systems to support it.
I asked him a question about function multiplexing (setting up multiple configurations for a LUT and using a global switch to select a configuration). I wanted to know if Xilinx had any plans to deliver chips to support it. He said no. He expressed the opinion that the space used by the additional RAM would be better spent on additional LUTs in which one could implement the multiplexed function. Thus it's probably bettter to just implement the multiplexing in the configware. I'm not sure if this changes my opinion on using dynamic partial reconfiguration with function multiplexing to implement a paging mechanism to swap configurations. I suppose if reconfiguration can be done fast enough it would make sense to implement a set of multiplexed functions and alter them. There's a lot of stuff to consider here.
If the use of an operating system for an FPGA catches on, it is likely that morphware fabrics will be tuned specifically for the OS. Dynamic partial reconfiguration is a relatively new area of exploration so the hardware support for them is still limited. There's only one path for reconfiguration on an FPGA (as in you cannot reconfigure multiple blocks simultaneously). If multiple disjoint processes require reconfiguration it would be nice to do the operations in parallel. We shall see...
I turned on anonymous comments on this blog at the request of someone who emailed me. If there are people reading this who are interested in reconfigurable computing, feel free to get in touch with me! If you're in the valley this summer we could meet up and have some beers or something.
Subscribe to:
Post Comments (Atom)
1 comment:
Yes, recon is still too much in its infancy for Xilinx to generate recon-optimized silicon... DPR is really a by-product of the way that configuration logic is implemented, but one which is more and more being looked at as a saleable feature. IMHO, Xilinx is a bit slow in promoting DPR for space applications... for reconfigurable computing, they are prob. waiting on 3rd parties to generate some tools... they are a big player and can prob. afford to do this, and then perhaps buy them out (there's your opportunity!)
With the highest-speed configuration clock, you can access a Virtex-II frame within ~20 us, which I agree is far from from 'simultaneous' at hardware speeds. I guess the trick for the OS is to synchronize frame updates with user-logic operation, which is further constrained by the place-and-route algorithm.
Perhaps Virtex-4 provides better reconfigurability resources than Virtex-II.
Post a Comment