Clock domain crossing is now a fact of life in many systems-on-chip (SoC) – a natural consequence of the need to integrate intellectual property (IP) cores from many sources and the physics of trying to get high-speed clock signals from one side of a chip to another without having to come up with arcane skew-compensation techniques.
In this scenario, the idea of making clocked cores communicate with each other using asynchronous protocols is very attractive. It offers the possibility to reduce the timing-closure loop for full-chip designs by relaxing some of the clocking requirements. Is globally asynchronous, locally synchronous (GALS) design inevitable? I talked to Real Intent CTO Pranav Ashar to find out how the EDA company is seeing the use of GALS increase – but it’s not a slam-dunk yes.
“GALS as such is not a new thing. People have been talking about this in the research community for more than 20 years,” says Ashar. “But a lot of it has really come to the fore in recent years. One of the reasons is that you can’t route the same clock to all parts of the chip without a lot of overhead of managing skew.
“Another area where GALS is very relevant is in power management. If I have a very diverse set of requirements and energy requirements, such as DSP-like computation that I need to do very quickly, it makes sense to run that at high frequency at a high Vdd. You want to have a separate island for that.
“A lot depends on the motivations. There can be diffferent situations for going for GALS,” says Ashar.
The key question is whether the overall design allows functional partitioning that makes GALS more attractive than a conventional synchronous design approach that allows for different clock speeds within islands.
“GALS makes sense where there are islands of computation that can be local and the scope of dependence is limited. It is a little like writing a software program. If I can encapsulate data and call a procedure and I can divide up my computation in that manner, that makes it amenable to a GALS-like paradigm.”
Pranav notes: “You need to bear in mind that there is generally an overhead to asynchronous communication protocols. The protocol will probably waste some clock cycles. There is a latency to these protocols and you need to compensate for the latency, hide it or work with a protocol where the delay is small enough.
“If the design implements some sort of pipeline where I can hide the latency of the asynchronous protocol in the pipeline, then GALS makes sense. The principles are not different from what software engineers and hardware designers have been working with in traditional architectures,” Ashar explains.
Although GALS relaxes timing requirements by forcing logic to only accept data once the handshake phase is complete, it introduces verification requirements of its own.
“The fundamental problem is that asynchronous interfaces have the potential for metastability, which introduces functional unpredictability. The value will be random for a certain amount of time. If downstream logic can’t handle that, it will cause problems. There is also the issue that metastability for a period is effectively a short and that will cause electrical problems in the design,” Ashar explains.
“How to design or implement an async interface is fairly standard at a textbook level. You need a synchroniser, which is typically a pair of flops. The electrical properties are such that metastability is limited to the connection between the first and second flop. Designers will use different numbers of these flops. Some may have more than one [synchronizer]. The implementation styles and detail vary quite a bit. But the basic principle is to trap the metastability there but that does not get rid of the randomness in itself.
“So your protocol needs to be cognizant of the potential for randomness. Some of the asynchronous protocols are quite sophisticated these days. The protocol may not be a simple handshake: it may have a nesting of control or could be more like a FIFO,” says Ashar.
The variability in design styles creates complexity in verification. Ashar says: “Doing verification with acceptable automation is the hard part. You have to drill down to how it’s trying to deal with metastability and then come back to generate checks.
“We’ve been working on this for more than ten years and we’ve assimilated a lot of feedback from customers. In the process, we’ve developed a fairly robust set of technologies that are able to handle the diversity.
“One of the things about the verification of asynchronous crossings is that this is one of the areas where simulation is deficient in being able to handle potential problems. In verification in general, over time we’ve separated timing and logic simulation. As a result, logic simulation is not equipped to identify bugs in the context of these protocols.
“Over the last ten years GALS has become predominant enough to become a key sign-off parameter and it needs a specialised solution,” says Ashar, who points to the use of more formal, static-verification techniques.
“One of the benefits of static verification is that it allows you to get away from simulation. For GALS, once you have identified the nature of the protocol and you have signed off on it using static technqiues you can be confident that, for that protocol, the transfers will work correctly.”