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

Chat to...

[awx]

Talk to this guy, he's very up-and-coming (and a slash user too :)

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.

Re:Asynchronous logic and Verilog

[addaon]

"This signature is a secret message encrypted with a one-time-pad"

And they say those things are unbreakable? Got it! Standard xor, byte at a time... you thought we wouldn't catch you?

1d48 081e 0012 4913 0b13 061a 000c 531d 5357 0e52 180c 0d15 4503 4919 0d53 320d 4a34 4100 0a02 520d 1f54 060b 4c1b 0804 1b45 4154 7b45 785a 3a43 454a 1f17 1000

Well...

[Hard_Code]

...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.

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.

Re:Well...

[AlecC]

I don't think this is necessarily true, but it is the way a lot of asynch designs are going. GALS - Globally Asynchronous, Locally Synchronous. Several reasons for this that I can think of. Firstly, asynch is much less well understood, so that by having a design that is 90% synchronous you can limit the unknown risk to the last 10%. Secondly, I think the technology of asynch interconnect is better understood that the sort of deep computation which in a syncronous design would be pipelined. Thirdly, some of the synchronous sub-units are probably availabl off the shelf (even if only from the designers memory). Fourthly, GALS diliver well on some of the advantages of full asynch e.g. spreading the clock noise, allowing different parts to run on clocks of their own speed, avoiding global clock distribution.

However, it is possible to have truly globally asynchronous designs. I could imagin that simulating and testing such a thing could be difficult.

..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"..

VHDL'93

[e8johan]

There is a VHDL version from 1993 supported by most major tools and VHDL supports asyncronous designs. I think that you may run into a number of synthetisations issues though as most of todays tools are intended for syncronous designs.

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.

Async means a lot of things...

[BDW]

What does it mean to you?

First off, I highly recommend you read some of the ASYNC proceedings. (ASYNC = Nth International Symposium on Asynchronous Circuits and Systems, for N=[1,8]) The best stuff in async tends to get published there. I think they've always published through IEEE, so you can go there, or just do some google searching.

There are no async design flows which you can just drop in to replace Cadence or whatever your current synchronous flow is. There is also a lot of literature (see ASYNC proceedings) on what async people have to do to get commercial synthesis tools to play nice at all. Cadence-style synthesis just isn't there. (Which could be seen as a good thing, depending on your view of the current ack-bassward synchronous flows...)

Your goal sounds close enough to the Manchester ARM work that their tools might work for you. First, read their papers on their ARM work; the devil is always in the details. (Publishing is like sales, you bury the ugly details in the fine print. :) If the experts at Manchester ran into a problem somewhere, odds are good you will too. Second, make sure you completely buy into their sect's interpretation of async before you jump in. They aren't the only sect in town.

I'm academically descended from the QDI culture in SoCal (Caltech, USC, whatever their startup is called these days, ...), so personallly I would go a different route. You should read up on what the QDI folks are doing. They've built their own (in many areas proprietary) flow, but the tools they use are readily available so depending on the complexity of your project you might be able to cook up your own, similar flow with the same tools.

My last point is a word of warning. As much as I like async and would like to see it more widely adopted, you are taking a big plunge, and if this is anything more than a course project, a big risk. Paraphrasing what a man who is much smarter than I said at the last ASYNC: If you read between the lines in the ASYNC proceedings you will see that the async community is basically a small (order hundreds) group of generally very smart people who are highly motivated. As often as not, they get things done by being highly motivated smart people. As a community, we haven't really demonstrated that our techniques to date will work for anyone but highly motivated smart people in the async community.

Look before you leap.

Brian