I'm being offered the chance to do research on FPGAs next year or this summer instead of going off to my college of choice (DigiPen). I'm pretty sure this is an awesome opportunity and will no doubt effect my future, if what I've been told is true, that these will soon be put in computers standard and they'll run without need to alter code. I'm pretty sure I'm not being an idiot by signing up for this. But the thing that irks me is how the person I talked to was saying how his team (the one I'll hopefully join) is trying to make the FPGA run at machine level and to chose what functions should be on IT instead of RAM. They especially want to keep deciding what functions are where NOT in the programmer's hands. But, when I think about applying these to games, in the in-game engine, I want to execute a frame sixty times a second even in the worst case, so I'd want long and unwieldy functions on the FPGA so the AVERAGE time is lowest. During a loading screen or something like, it'd want the most often called functions to be in the FPGA so I get the lowest TOTAL time. So my theory is that the best way to prioritized functions for going to the FPGA would be to have default priority checks, but allow the programmer to change the priority settings so that time consuming functions are placed in the FPGA first, or often called, or maybe heavily recursive functions. These examples might be a little contrived, and I might just have amisunderstanding going on, but I just don't want to sound like an audacious noob by suggesting the experienced coders are doing this all wrong. So I've come here to do two things: Validate or dismantle my theory, and know exactly how this will/may affect my future and the future of gaming. Thanks in advance. PS: How hard will this stuff be? The person who recommended me is confident in me, but I have no experience with low level languages, and little experience with high level ones.

I'm not quite sure I follow. Are you suggesting that pre-programmed FGPAs will start appearing in mainstream PCs or game consoles, with no way to modify their programming. That doesn't make any sense. ASICs are much cheaper (per unit) and much faster.

If you're thinking about a specific application, that can make use of an FPGA, then you first have to identify functions that actually benefit from the FPGA. The CPU is going to be much faster in general purpose computing. The FPGAs really shine in highly parallel task, but even then GPUs are faster, if applicable to the task. Then there's the development cost. You won't be just writing a piece of code and then deciding if it's going to the FPGA or the CPU, the code has to be written separately for both. I suggest you do some coding first to get a feel for it and then start sorting the problem out.

As to how hard it's going to be. With your experience, I'd say pretty hard. If you're going to write the FPGA code in Verilog or VHDL, it's quite different from anything you've ever seen. Plus, optimization is everything, so you need to get an understanding of what the HDL compiler does.

Quote: Original post by SnotBob
I'm not quite sure I follow. Are you suggesting that pre-programmed FGPAs will start appearing in mainstream PCs or game consoles, with no way to modify their programming. That doesn't make any sense. ASICs are much cheaper (per unit) and much faster.

I think what they're planning was an FPGA with the only pre-programming being deciding what code is off the FPGA and what's off the RAM. I don't really know a lot yet.

I don't think what I'll be doing will be quite the same as what will be on mainstream PCs and consoles. I just know it's analogous technology to say the least.

Quote: Original post by SnotBob
As to how hard it's going to be. With your experience, I'd say pretty hard.

Thought so. Should have asked if there's anything I can do to prepare myself. Like, what subject to study. Kind of actually reminds me of calculator programming, except that was a weak, but high level language.


Also:
As you pointed out, FPGAs are slower than more specialized pieces of equipment, but they're flexible and field programmable. So, one of the first questions, and this is really just a clarification, was, what is their likely use in games? I have to imagine it'll be something a little more complex than just taking foo() and doing it there instead of on RAM. It seems to me like they'd be really good at keeping track of threads and runtime-data (like execution time, number of times code block was used, etc.). Yes? Or would this, or IS that, or will, be done by a specialized piece of instead?

I agree with 'SnotBob', the main benefit of FPGAs is their ability to be easily re-programmed, not in their performance..
I can't think of a good use of them in the game industry .. with lots of multi-core processors out there, and continuous improving of GPUs, you should have a very good reason to use FPGAs...

Quote: Original post by Splinter of Chaos
Should have asked if there's anything I can do to prepare myself. Like, what subject to study. Kind of actually reminds me of calculator programming, except that was a weak, but high level language.

Well, you can start programming in Verilog or VHDL right away. Personally I find Verilog to be somewhat easier. Read some Verilog/VHDL tutorials (Here's one), get a simulator (e.g. Icarus Verilog) and start coding. Keep in mind though, that the simulators are event based, while on a FPGA the programs actually are made up of a circuit consisting of a large number of elementary logic blocks working simultaneously. This means that there are slight semantic differences between programs run in a simulator and on an FPGA. Also it helps if you have an understanding of basic digital electronics.

Quote:
Also:
As you pointed out, FPGAs are slower than more specialized pieces of equipment, but they're flexible and field programmable. So, one of the first questions, and this is really just a clarification, was, what is their likely use in games? I have to imagine it'll be something a little more complex than just taking foo() and doing it there instead of on RAM. It seems to me like they'd be really good at keeping track of threads and runtime-data (like execution time, number of times code block was used, etc.). Yes? Or would this, or IS that, or will, be done by a specialized piece of instead?

To be quite honest, I cannot imagine any use for FPGAs in games programming as such. You could perhaps use one for physics simulation, but GPUs are getting more and more generalized and physics hardware might become mainstream, so they seem better suited for the task. Maybe some AI tasks might benefit from an FPGA. Or you could use it as an accelerator for some audio/video handling, like performing parts of MP3 decoding.

An FPGA really would not be good for handling system data, such as threads. In a PC, the FPGA would likely be connected to the PCI bus, where it has direct access to the system memory, acting much like a co-processor of sorts. The first obstacle in even accessing system data is to deal with the logical to physical memory mapping done in the CPU.

The way you would use the FPGA is that you prepare a piece of data in RAM for the FPGA to process using the CPU, then you pass the FPGA the physical address to that data (or you write the data into a specific address known by the FPGA), let the FPGA run with it and read the results from another part of the memory. Before any of that though, the FPGA has to be programmed by feeding it a stream of bits, the output of the HDL compiler. This takes time (might take as much as a whole second, not including the compilation), so reprogramming the FPGA frequently on the fly isn't really an option.

2 years ago at an APICS conference I attended there was a group doing research with FPGAs, and looking at their applications to mainstream computers. One of the biggest problems they had was the highly limited write count they offered. Like flash memory, FPGAs eventually stop being reprogrammable.

Now, one interesting suggestion I've seen elsewhere was to offer an easy method of hot swapping FPGAs, so you could have an array of reprogrammable co-processors, and applications could request what ones it needed, and suggest what kinds it could use but weren't mandatory. You then have flash drive/card like chips that you can pop in and out of your computer, and applications could be sold including their own preprogrammed coprocessor (not a reprogrammable chip).

Quote: Original post by Talroth
2 years ago at an APICS conference I attended there was a group doing research with FPGAs, and looking at their applications to mainstream computers. One of the biggest problems they had was the highly limited write count they offered. Like flash memory, FPGAs eventually stop being reprogrammable.

They must have been using flash based FPGAs. I don't see any reason not to use RAM based FPGAs in a PC setting and use the CPU to program them after power-up.