Ian Piumarta wrote: > Several of us here (at VPRI) are interested in the potential of > better synergy between hardware and software. Something we'd love to > see is the *OLA back-end generating netlists for FPGAs, or better > still reprogramming them on the fly (which I'm told is possible, but > I've yet to see an example). Just-in-time software deserves just-in- > time hardware, no? ;-)
I was able to convince my advisor that my master's thesis (due next March) would be much more interesting if I did something like this rather than simply implementing a collision avoidance algorithm (robotic vision) in hardware. The idea is to extend the Self/Hotspot/Strongtalk compilation technology an extra step. Code is initially interpreted or compiled with a very simple (but fast) compiler. When a method is determined to be a hot spot in the system, a second compiler generates much better code for it. If it proves to be really critical to system performance then a third compiler would generate hardware for it. Unfortunately there are complications. The most critical one is the black box nature of modern FPGAs described in detail by Toby Watson in another message in this thread. Xilinx bought the 62xx technology (also mentioned by Antoine van Gelder) and killed it, while the Atmel AT40K series hasn't been seriously updated since the late 1990s. So given that some vendor's proprietary tools will have to be used as the back end of the third compiler and these tools won't run on the FPGA machine itself, I will have to content myself with loading previously compiled modules instead. Another complication is that partial reconfiguration is currently very complicated to do, when it is available at all. The Virtex-4 that the development kit I bought for this project uses is the state of the art in this regard. A design in the FPGA itself can include a special component (called ICAP, if I remember correctly) that allows it to examine and change the programming of other regions of the FPGA even as it continues to run. The lower end Spartan 3 chips that I plan to use for the children's computer don't have this ability, but they can be programmed from an external source such that part of the FPGA's configuration is changed while another part is still running. In either case, actually generating the correct bits to do this requires a lot of work due to poor support from the current tools. The idea in my project is that the inital configuration will have a number of processors (nine, for example) all alike and connected via an onboard network. When code generated by the second compiler for some method takes up more than 100% of one of these processors and it happens to have a corresponding pre-compiled hardware alternative, then one of the processors (it doesn't have to be the same one) is replaced by the hardware block. Figuring out when a given hardware block isn't being used enough and could be replaced by a generic processor is a little more complicated. Since the hardware block presents exactly the same interface to the rest of the system (messages over the network) that the software it replaced did, this switching back and forth is completely transparent to the rest of the application. Steven H. Rogers mentioned the slowness of reconfiguring the FPGA which would make a software based multiprocessor like Chuck Moore's Intellasys chip more desirable. Partial reconfiguration would help with that since the reconfiguration time would then be proportional to the area being changed rather than the size of the FPGA being used. In my project it is unlikely that I will have time to implement partial reconfiguration and so will probably reprogram the whole FPGA every time, even though it might take nearly a second to do so. But my base configuration is very similar to the SEAForth design (but with fewer and slower processors) and the reconfiguration time will be taken into account by the scheduler, so hardware generation won't be used unless it will make a significant difference. There are some guys doing interesting things with reconfigurable processors that can have their instructions changed in just a few microseconds: http://www.stretchinc.com/technology/ -- Jecel _______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
