On 10/15/06, William DUCK <[EMAIL PROTECTED]> wrote:
NSF Center for High-Performance Reconfigurable Computing (CHREC)
This is a long-term sort of project idea for us. The holy grail would be to convert arbitrary C or Fortran code into FPGA logic. (This would be especially good for Cray computers that arrange Opterons with Xilinx FPGAs.) A more realistic goal, however, would be to convert a restricted subset of C into gates. One idea I had was to define stylistic requirements on C functions where a function takes a single struct as input and returns a single struct as a result. The structs can contain any primitive data items. This would be relatively easy to parse and convert to Verilog, which we would synthesize for the FPGA. The next way in which we make this realistic is to not try to get optimal FPGA performance. We just try to get whatever performance we can. If the logic is used properly, we can always get a performance win. An idea to keep in mind here is that the C code needs to be valid C code. The idea is to use pragma directives or whatever to indicate that the code CAN be converted to gates, but it doesn't have to be. Here's the next restriction to make it realistic: The hardware is a pipeline, and to make good use of it, we need to treat it like one. Pipelines work by pushing data items into the put, and with some latency, we get results at the same rate out. The problem to deal with is the latency. We can add another stylistic element. Instead of having the function return a struct, it returns void. The way you code it is, when the function is finished, it calls a function (that our parser recognizes) to enqueue the results. Now, the program using the logic should be written to push inputs in bulk, then at a later time, pop results. The performance of the software version would be somewhat lower than a straight software version, but now, it's structured so that we can make efficient hardware out of it. The hardware would be prefixed and suffixed with queues, and those would be extended with software queues so that the controlling software can push an arbitrary number of input blocks before popping anything. This would make an awesome academic paper... _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
