CDNLive India: Asynchronous Design

Every few years the idea of doing completely clockless design gets proposed again. This is also known as locally asynchronous design (no clocks at all), as opposed to simply having lots of clock domains and having asynchronous communication from one domain to the next.

There are all sorts of issues with this:

• Engineers learn synchronous design in school and never work on anything else, so they are unfamiliar with the basis ideas.
• Even in modern designs when asynchronous events happen, at the edge of clock-domain boundaries, it tends to be a major area of error, especially before clock-domain-crossing (CDC) tools existed.
• The modern digital design flow is based around clocks, such as static timing analysis.
• Even if you can get the system designed using whatever tool flow works, how is verification done?

Despite these difficulties, there are a lot of attractive aspects to locally asynchronous design. First, about 30% of the power and a large amount of the interconnect is "spent' on clock distribution. Synchronous designs have their frequency set to the worst case silicon. But most silicon is "typical" by definition. So a lot of performance is being left on the table. Locally asynchronous design runs at the fastest speed possible given the actual silicon corner. Furthermore, when performance is data-dependent, synchronous design still runs worst case, whereas locally asynchronous design will run at the appropriate speed for the data values.

A Trip to Greece

Several years ago I did some consulting for a company called Nanochronous, who supported locally asynchronous design. They provided silicon structures to handle the scheduling of operations, along with software which read a "normal" netlist and produced an equivalent design that realized the same RTL operation sequence but without requiring an explicit clock. Their engineering organization was on the Greek island of Crete. The company was running low on its seed funding, so they didn't have a lot of money. But I got offered the deal of having my expenses paid for a trip to Crete, and I would do 3 days consulting, doing what was effectively an operations review. If the company got funded, they would pay my consulting fee. Otherwise, I would just get an all-expenses vacation in Crete. Since I'd not been to Crete since I was 19 on Inter-rail, this was quite attractive. Plus Greek food is wonderful.

It was a great trip, and certainly more pleasant to fly to Heraklion from Athens rather than sleeping outside on the deck of a ferry, which had been my previous mode of arrival. I arrived on a Sunday and got taken up to a little village up in the mountains where they roasted a couple of whole lambs each morning, and after church (Greek Orthodox, of course) everyone went to the local taverna for lamb, pita, greek salad, ouzo and wine. I reminded me of some of the places up in the foothills of the Alps near where I lived in the south of France.

One issue with the Nanocrhonous technology was, as always, verification. Their technology seemed to work well but it was hard to verify except using SPICE, which didn't scale. Despite significant interest from some large fabless semiconductor companies, eventually the company were unable to break through the verification wall. In the era when I went to Crete, Formal Verification was in its infancy, but it is not a promising technology since clocks are fundamental to (most of) the algorithms used.

Texas Instruments

At CDNLive in India recently, Texas Instrument's Sudhakar Surendran, presented on Locally Asynchronous Design Verification. I don't think TI does any designs where the whole chip is locally asynchronous, but these techniques are widely used in delay-based speed optimization, power management circuits, and other applications. But these still require verification.

In addition to problems that asynchronous FSM might have, an asynchronous one has some new things that might occur such as glitches. They can also have unstable states (for example, if, for a certain combination of inputs, state A goes to next state B, but next state for B is state A, then this will oscillate). TI used a trick with Xs as a ternary logic to model unstable states (which formal has no concept of an unstable state).

The biggest challenge in using Jasper Gold for verifying a design like this is that the formal tools have no concept of delay (they don't do timing, they just do functionality). The design won't even compile. So TI created a delay element that emulated the delays for the formal tool. Then they modified the source file to instantiate these elements at all delay points.

The next issue was that combinational loops are not acceptable to formal tools. So any combinational loop was broken by adding a one-clock delay element (and adjusting all the other delay values appropriately). They could then use both formal verification and standard constrained random verification.

In a bit more detail, TI would:

1. Discretize the timing delays
2. Model the discretized delays using FV tool crank or internal clock
3. Create TIMING_FV Model for each delay formats (SDF,…)
4. TIMING_FV model uses basic template for each construct
5. Create FV timing delay wrapper for each cell in the library
6. Create FV friendly design netlist for the design with timing delay
7. Uses original netlist, cell FV delay wrapper, timing/SDF and the TIMING_FV model

Sudhakar went into detail in each of these steps, but that is beyond the scope of this post. I think the important takeaway is that they have developed an approach that allows a formal verification tool like Jasper Gold to be faked out by using delay elements to generate a clock that doesn't really exist in reality. This approach allows formal verification to be used on asynchronous designs.

Summary

TI showed methods to use formal verification for asynchronous designs. A big advantage was to "shift left" by doing this very early in verification, once RTL was first available.

• Model timing in Formal tools that enabled reading in asynchronous designs
• Detect hazards in asynchronous designs
• Enable ‘unstable’ states detection

The presentations are not yet available, but eventually all presentations will appear on the CDNLive India page.

Sign up for Sunday Brunch, the weekly Breakfast Bytes email