Asynchronous Design Tools?

KeggInKenny asks: "I have the opportunity to engage in a research project involving large-scale asynchronous logic circuits. After evaluating possible tools for hardware description, simulation and implementation, I'm finding there's very little targeted toward asynchronous logic. VHDL is little changed from the 1987 standard which is not nearly as suited for large designs as it's name would suggest, and Verilog is too synchronous (or at least it's too easy to fall into the 'synchronous assumption' trap because of Verilog's C-style structure). Specifically: we are designing a low-power microcontroller for portable (read battery-powered) devices, and hoping that through asynchronous logic, we can greatly reduce power consumption. I'd like to see what the hardware gurus from the Slashdot community have to suggest for VLSIC design focusing on asynchronous research. What tools did you use to design the chips, did you run into synthesization problems, and did you find yourselves focusing on many local clocks, as seems to be the current async trend, or true unclocked hardware?"

Comments

Asynchronous logic and Verilog

[eXtro]

Verilog isn't particularily synchronous, in fact, without going to special measures its combinational. You introduce the synchronous behaviour by making conditions happen based on global clocks:

always @ (posedge clock) begin
// do useful stuff
end

I don't know how your particular asynchronous scheme works, but if you were using handshaking (i.e. request/acknowledge) then you would update values and toggle your acknowledge signal based on the completion of your logic operation. These request and ackowledge signals would only propogate between elements.

I don't have a verilog book handy, and I usually design in spice, but something along the lines of
this, at least at the 30000 foot level:

always @ (posedge req0 && req1 && req2) begin
val0 = ip0 | ip1 & ip2;
val1 = ip0 & ip1 | ip2;
ack = 1'b1;
end

Again, I don't know exactly what you're doing, but I'm sure that you can model it with Verilog with increasing levels of detail.

..and that's the point

[kcm]

There are (at least) two ways to utilize asynchronous design architecturally:

The first being a large-scale asynchronous design that allows for high-speed disconnected operations to complete with lots of communication between them, and the second being a design which eliminates the extra latching required in a largely-synchronous design.

The first eats up power, and the second conserves it (theoretically). In the first case, you have tons of little "units" eating up as much power as they can because they're all operating independently as quickly as possible, and in the second case, you have a lot of little units which only "operate" when needed.

Think of it as polling vs. interrupts. One design, the faster one, says "are you done yet? are you done yet? are you done yet? are you done yet? here's your data..", and the other slower and power-conserving design says "hey, I have your data, let me know when you want it and I'll give it to you"..

Async tools

[brejc8]

The Async tools page has the list of most tools we use.
Ones we use most often are:

Balsa: make just about anything with it. Its personally quite VHDL like and very well mentained. Recently used to make a whole synthesized ARM compatable asynchronous chip. Comes with many flavours of back end (dual rail, single rail, safe and more).

Petrify: Make small components by describing each part transition by transition. (VSTGL) makes the process a little more graphical.

MINIMALIST: Simmilar to petrify but a little simpler to specify things.

The best way to learn these tools is to go to async 2003 where they have a tutorial of some of them.

There is also the book. It goes through a balsa tutorial.

The most important part of designing async stuff is to learn the different methods. Read the intoductions to some of these theses. They explain the basics. Before you start designing know what makes the system good or not.

Re:Well...

[Omegalomaniac]

...from my limited knowledge, "asynchronous" is really just "synchronous" on a much smaller scale. You just have smaller synchronous components that don't have to coordinate synchronously on the global scale. I mean, your adders and stuff are still going to be the same, they will just have their own clock (or no clock I suppose). So my naive assumption is that you have lots of little synchronous components glued logically together with a synchronous coordination bus/fabric. At *some* point it is always synchronous.

Adders don't have clocks, as I've had to point out to a few students. The inputs to the adders change with the clock, so it is easy to get confused. Asynchronous design is not multi-level synchronous design. It usually involves handshaking, that is one module asks "Are you done yet?" and the other module replies "yep" or "hold on". The purpose of a clock in a synchronous design is to be a taskmaster. The clock says to each module "You will be done at this time!" where "this time" is some integer multiple of the clock.
Contrary to what you said, I would say that at some point all synchronous design is asynchronous. Gates don't have clocks.