Global Sources
EE Times-India
Stay in touch with EE Times India
EE Times-India > T&M

Minimise metastability with User Grey Cell approach

Posted: 17 Mar 2014     Print Version  Bookmark and Share

Keywords:IPs  EDA  User Grey Cell  clock domain crossing  CDC 

As design complexity increases, designers increasingly rely on commercial or existing IPs to meet project deadlines rather than designing everything from scratch. According to Semico Research, over the next couple of years, the number of IPs per design will increase from an average of 50 to a staggering 180.

The difficulty of IP integration and design verification will undoubtedly grow exponentially. Even today, many design teams complain that it takes too long for integration and verification using existing methodologies. Just imagine the resulting dreadful situations as the number of IPs per design goes up. To alleviate these types of issues, EDA vendors need to provide breakthrough methodologies. Previously, Blue Pearl Software introduced the Grey Cell methodology.

With the recently introduced User Grey Cell methodology, Blue Pearl enables IP providers and FPGA designers to reduce the risk of missing clock domain crossing (CDC) issues. In this paper, we illustrate how the recently introduced patent-pending User Grey Cell methodology reduces metastability.

Leading cause of metastability
Designs today integrate components/IPs from many sources that operate with independent clocks with different frequency and phase relationship. This is done to bring data into the design from different sources or to change frequency in order to optimise power. The added complexity of disabling many logic cones means verification engineers need to be more vigilant.

Whenever there are setup or hold-time violations in any flip-flop, it can enter a state where its output is unpredictable. This state is known as metastable state. It could well be that the flip-flop will settle in a known state. But due to dependencies on thermal and induced noise, one cannot be certain on the time it takes to settle. The likelihood of a functional failure due to metastability increases with clock frequency.

When components or IPs with different clock phase/frequency interface, the receiving logic flip-flop may violate setup or hold time causing the output to not settle to a stable 1 or 0 state. This metastable state can get propagated through the design as erroneous states causing functional failures. Hence it is important for designers to find portions of their designs where CDC can occur. Designers then insert logic to greatly reduce the likelihood of propagating erroneous data due to metastable signals.

Failure of the Black Box methodology
As discussed earlier, the required components/IPs come from varied sources. They could be acquired in synthesisable RTL format, protected IP format, simulation models, or non-synthesisable formats. If the IP is in the form of a synthesisable RTL, then it is relatively straightforward to do CDC analysis through it. However, for the other formats, the IPs have traditionally been treated as Black Boxes, i.e. the analysis will not use any knowledge of the internals of the IP. In a Black Box methodology, the CDC analysis will stop at each IP boundary and treat it as an end point with no relationship whatsoever with what's inside the IP.

As designers rely more and more on IPs, the number of Black Boxes included in the analysis is increasing. Thus, the risk of missing critical CDC issues grows. Moreover, since the IPs are instantiated in hierarchical designs, it quickly becomes impossible to manually trace and decide whether a particular Black Box can cause a CDC issue.

Won't IEEE P1735 solve the Black Box issue?
The IEEE project P1735 intends to describe IP encryption markup for design information formats, and thus enable design flows that provide interoperability between IP sources, tools, integrators, and users of the IP. This is driven primarily by IP providers who want to protect their know-how and thus encrypt their IP. P1735 provides guidelines for key management, together with encryption and decryption algorithms. These enable inter-operable IP encryption and thus allow specific EDA tools to see the inside of the IP.

Once P1735 is finalized, it will solve the CDC analysis for a synthesisable RTL IP, assuming that, once decrypted, the tool has enough information to perform the analysis through the IP. However, this does not completely address all the reasons why designers settle for a Black Box methodology. Designers still need to handle the non-synthesisable models, simulation models, behavioural models, and/or still incomplete models. For these components, encryption/decryption still does not help in enabling a complete CDC analysis. Thus, P1735 still does not solve all the issues of using a Black Box methodology.

1 • 2 • 3 Next Page Last Page

Comment on "Minimise metastability with User Gre..."
*  You can enter [0] more charecters.
*Verify code:


Visit Asia Webinars to learn about the latest in technology and get practical design tips.


Go to top             Connect on Facebook      Follow us on Twitter      Follow us on Orkut

Back to Top