Anyone interested in this topic should definitely look into the Cornell University research ( http://vlsi.cornell.edu/ ). Unlike most researchers in asynchronous research, they still tape out chips.
Is it possible to make practical async logic on ordinary FPGAs? I've seen some very conservatively-designed async stuff that ran on an Altera FPGA, but I remember hearing that it was kind of flaky. (It was a Java-to-hardware synthesis program -- there's a remarkably direct mapping between the usual program structures like loops, if statements, etc., and hardware if you're willing to use a naive design.)
What are the prospects for putting asynchronous IP cores into a system-on-chip with mostly clocked parts?
What kind of async logic style do you usually use in practice? Dual-rail quasi-delay-insensitive, or bundled data with matched delays, or something so exotic that I've yet to hear of it?
I've heard some people speculating about how async circuits can be used to make fault-tolerant logic. For example, if you're using dual-rail coding, then a single bit flip is going to be detectable as a fault, and you can trigger some self-checking-and-repair logic without breaking your timing assumptions. How important/plausible would you say this is?
I failed pretty miserably: It took me several rewrites before I got one to even synthesize, and dozens before I got it to place+route onto the physical chip (fucking traveling salesman problem!). I never got my CPU's JMP instruction to work correctly within my self-imposed ideological constraints, making it rather useless.
It took me a while to realize that the fundamental problem with my design was hidden asynchrony, despite having a clock.
Getting the asynchronous IP core into a SoC system is not that difficult. You'll have to convert synchronous signals to asynchronous signals and vise versa, but once you figure that out (it's actually very simple) you can plug in the asynchronous core anywhere.
I used dual rail QDI in my circuit design, with a mix of four phase handshakes and two phase handshakes, depending on the application.
Fault-tolerant logic is definitely feasible - I worked on this for one project! The technique is patented by Achronix, but it definitely is almost bullet proof and only requires an area overhead similar to a voting schema.
I think that there are a few factors that will eventually drive asynchronous designs to become the way forward.
Here's another cool thing: by using a dual-rail encoding (one wire being high means a bit is 0, the other wire being high means the bit is 1) you can design logic that consumes roughly constant power no matter what the operands are. This makes power-analysis attacks a lot more difficult.
Here's a paper on all this that you may enjoy:
http://www.gemplus.com/smart/rd/publications/pdf/MAM03as.pdf
Unfortunately, to match the minimum to the maximum, you would likely have to design your implementation to be very slow. In the constant time case you remove all the pipelining advantages, as you would be required to 'fill' the pipeline.