4 ms·

I worked at Achronix Semiconductor (San Jose startup) for over a year and a half designing Asynchronous Circuits. I can answer any questions about the specifics

by boots 17y ago

I worked at Achronix Semiconductor (San Jose startup) for over a year and a half designing Asynchronous Circuits. I can answer any questions about the specifics of designing these circuits. Anyone interested in this topic should definitely look into the Cornell University research ( http://vlsi.cornell.edu/ http://vlsi.cornell.edu/ ). Unlike most researchers in asynchronous research, they still tape out chips.

jacquesm 17y ago
This is a very interesting area. You're really lucky to have worked for a company busy in this field, that's golden knowledge and experience. I think that there are a few factors that will eventually drive asynchronous designs to become the way forward.
sketerpot 17y ago
Cool, there are a few things I've been wondering about for a while now. 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?
- blasdel 17y ago
  Years ago I tried to implement a simple CPU architecture in Xilinx Verilog on a Spartan3 where the aim was for it to be pedagogically simple inside and out, with extremely concise and expository HDL source. 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.
- boots 17y ago
  If you wanted to map asynchronous designs to an ordinary FPGA, I think there would be two major hurdles: 1) Choosing an asynchronous methodology (There are more then one), and mapping that to the LUT. This shouldn't be too difficult, but you are likely to have a high area overhead for this. 2) Getting the place and router to behave as you would expect it to. It depends if the router uses the clock to propagate it's information, although I expect it would NOT. 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.
briansmith 17y ago
Is there difficulty implementing constant-time algorithms for async processors? For example, it is very desirable that every crypto operation takes exactly the same amount of time, to avoid timing attacks.
- sketerpot 17y ago
  You can always use a clock and a counter to delay for a period of time that you know is greater than the worst-case time that the operation could take. Or randomize it up a bit. Or design the logic to take similar times for all crypto operations. 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 http://www.gemplus.com/smart/rd/publications/pdf/MAM03as.pdf
- boots 17y ago
  There is definitely a very bound on the time that it could take, but one of the advantages of asynchronous is that you can design for the average case, not the worst case. Each circuit forms part of a data pipeline, and with enough data in this pipeline you can guarantee a maximum time limit. 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.
achronixinsider 17y ago
Do you think that your former employer (Achronix) would be pleased to hear that you are looking to disclose "specifics of designing these circuits" on a public message board?

by boots 17y ago

jacquesm 17y ago

This is a very interesting area. You're really lucky to have worked for a company busy in this field, that's golden knowledge and experience. I think that there are a few factors that will eventually drive asynchronous designs to become the way forward.

sketerpot 17y ago

Cool, there are a few things I've been wondering about for a while now. 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?

blasdel 17y ago
Years ago I tried to implement a simple CPU architecture in Xilinx Verilog on a Spartan3 where the aim was for it to be pedagogically simple inside and out, with extremely concise and expository HDL source. 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.
boots 17y ago
If you wanted to map asynchronous designs to an ordinary FPGA, I think there would be two major hurdles: 1) Choosing an asynchronous methodology (There are more then one), and mapping that to the LUT. This shouldn't be too difficult, but you are likely to have a high area overhead for this. 2) Getting the place and router to behave as you would expect it to. It depends if the router uses the clock to propagate it's information, although I expect it would NOT. 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.

briansmith 17y ago

Is there difficulty implementing constant-time algorithms for async processors? For example, it is very desirable that every crypto operation takes exactly the same amount of time, to avoid timing attacks.

sketerpot 17y ago
You can always use a clock and a counter to delay for a period of time that you know is greater than the worst-case time that the operation could take. Or randomize it up a bit. Or design the logic to take similar times for all crypto operations. 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 http://www.gemplus.com/smart/rd/publications/pdf/MAM03as.pdf
boots 17y ago
There is definitely a very bound on the time that it could take, but one of the advantages of asynchronous is that you can design for the average case, not the worst case. Each circuit forms part of a data pipeline, and with enough data in this pipeline you can guarantee a maximum time limit. 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.

achronixinsider 17y ago

Do you think that your former employer (Achronix) would be pleased to hear that you are looking to disclose "specifics of designing these circuits" on a public message board?