Introducing a novel technique for Intellectual Property and FPGA/ASIC clock domain crossing analysis using Blue Pearl's User Grey Cell methodology, rather than the traditional Black Box methodology.
In this column, I'd like to introduce a novel technique for Intellectual Property (IP) and FPGA/ASIC clock domain crossing (CDC) analysis using a Grey Cell methodology rather than the traditional Black Box methodology.
The growth of IP-based design
As design complexity escalates, 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, which was discussed at DAC 2012 and elaborated on in EETimes.
With the recently introduced User Grey Cell methodology, Blue Pearl enables IP providers and FPGA designers to reduce the risk of missing 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 optimize 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 synthesizable RTL format, protected IP format, simulation models, or non-synthesizable formats. If the IP is in the form of a synthesizable 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.
To Page 2 >