Some of the old school analog computation people were really into this idea. They visualized computations as wires and nodes. I remember one mechanical engineering professor, who was a big fan of nomograms. He wanted a set of networkable blocks so he could build a computer program on his desk top and have it run digitally. We could probably do this today, but few people are used to thinking about algorithms that way anymore, despite the inherent parallellism that such thinking requires. This was back in the early 1970s, so this idea has old roots.

Rather, a good idea frequently exposes yet another bottleneck that was hidden before.

Yes, but that isn’t a matter of complaint as such.

When you say that DRAMs are substantially slower, don’t you mean that large memory space and subsequent deep data channels are the problems? I’m not sure how to tackle that one though – it seems as least as hard a problem to break down as the serial-to-parallel challenge is.

Given that before the FPGA gets programmed, enough statistics have to be collected by the profiling unit to determine if it’s worthwhile, it’ll only be reprogrammed if it’s worth it. This is (roughly) the scheme used for Just-In-Time compilation for CPU emulation, and it works there.

–jt

But such automatic compilation of designs has been the “holy grail” of not just the FPGA world, but the entire parallel/scientific computing field for 40 years. It’s just really hard to extract more than a few way parallelism from non-trivial problems that are stated serially, even without the memory bottleneck. And it’s hard as hades for most humans to express parallel algorithms as such.

There has been a LOT of work done here, and every high-level or automatic design compiler I’ve seen makes a major tradeoff in either flexibility, performance, ease of use.

Usually, you can only pick one (or at most 2).
(e.g. Mitrionics, which focuses on ease-of-use,Handel-C which goes for flexibility, Viva, which is pretty good trades flexibility for a decent enough performance and )

The trouble I see here is in the target audience– if you have a major scientific computation to perform that can be accelerated with FPGAs, why would you use this custom processor, when for a little more effort you can get an FPGA designer who can make a custom design which will probably outperform this guy. If you have a webserver with many trivially parallel tasks, unless they map to what the desing compiler wants to see, you’ve wasted your silicon– it probably makes sense to buy another COTS box ‘o processors.

You’re spending a lot of silicon on a design tool that you’ll need once in a while– don’t get me wrong, it’s very cool to have it on a chip, and it’s a step towards “evolvable, self-programming hardware”, but I’m not sure of the practicality.

Bioinformatics & network security is one place where this might do very well. You have lots of string and pattern matching which avoids floating point (which currently kills FPGAs), very regular memory accesses and very simple operations (counters, comparators and address generators). But agian, the simplicity of the app makes me question whether it isn’t worth the designer time vs. this automatic solution.

–jt