As a new year present to the industry and our loyal customers, Real Intent announced the release of Meridian CDC version 4.0 on January 11. This release incorporates numerous enhancements and speedups. We will be covering many of the features in more detail in later blogs, but here are a couple of highlights:

1. Real Intent’s Meridian CDC product has been the performance and capacity leader for some time now and the 4.0 release builds on the leadership with significant additional performance and capacity improvements (up to 5X) in structural analysis, design upload and GUI debug.  Meridian CDC 4.0 makes full chip CDC verification on 100+M gate SoC designs a reality and enables design managers to enforce full-chip CDC verification as a first-order sign-off requirement.
2. Meridian CDC 4.0 makes it much easier and faster to setup the design environment (clock, reset, mode select, stable value, input and output domains through SDC translation and automatic design analysis) so that the time to the first useful CDC analysis is minimized. Our continuous efforts in this regard are testament to our customer-centric perspective. We truly believe that in addition basing our products on strong technology foundations, we must also ensure that we do our utmost to make our products the most usable.

Our existing customers are already benefiting from the speedup and added functionality in 4.0. Meridian CDC is the flagship product at Real Intent, and we have a clear focus and devote significant resources to keep it so. The team is already onto the next release target with even more exciting features and improvements to come.

As noted by Prakash Narain, CEO of Real Intent, “Meridian CDC 4.0 release represents a milestone in the industry for delivering a CDC verification solution that can be used to achieve complete CDC sign-off for large and complex SoC designs from RTL to gate.”

Electronic Design Automation (EDA) is a key enabler for the advance of IC/SoC designs. The advances in EDA tools parallel, as much as possible, the advances in IC design and verification. The development of Clock Domain Crossing (CDC) verification is a good example of this advancement.

In 2001, Cliff Cummings published a paper at SNUG called “Synthesis and Scripting Techniques for Designing Multi-asynchronous Clock Domains” ¹. In the paper, he talked about various asynchronous design techniques such as passing signals from fast to slow clock domains, passing multiple control signals, synchronizing datapaths by using handshakes and FIFOs. Cliff also proposed a CDC design methodology by adopting naming conventions and adhering to certain design partitioning principles.  In the paper, Cliff also discussed the impact of implementing asynchronous designs using synthesis and static timing analysis. Back then, Cliff was unaware of any CDC tools in the market. It was the era of simple CDC designs with less than 5 clock domains and manual review for CDC verification.

Things changed pretty quickly. In 2002, the first-generation CDC tools came to the market. Real Intent’s Verix CIV (Clock Intent Verification) was one of the pioneers in this field. The characteristic of the first generation tools was that they used structural analysis techniques to see if proper synchronization is in place and if there are unsafe CDC structures. While structural analysis alone was not sufficient to prove that all the asynchronous transfer protocols are safe, it was a step in the right direction and provided high value over manual review.

The second-generation CDC tools came around 2007, including Real Intent’s Meridian™ CDC.  These tools represented an advance in CDC verification technology by incorporating multiple verification techniques in addition to structural analysis. Formal analysis became an integral part of the solution in order to check for things such as data stability, pulse width, gray encoding and glitch potential. The tools also provided a simulation library and monitors so that users can perform CDC verification by injecting metastability effects during simulation and catching CDC violations using monitors. This advancement was necessitated by the number of bugs that slipped through to silicon due to clocking issues. According to Collett International and Farwest Research Group’s surveys conducted in 2002, 2004 and 2007, about 20% of chip re-spins were caused by clocking issues. As a result, functional CDC verification using formal analysis and simulation have become must-have techniques in the CDC verification flow.

Recognizing the change in CDC landscape, Cliff Cummings wrote a follow-up paper entitled “Clock Domain Crossing (CDC) Design & Verification Techniques Using SystemVerilog” ², which won the 1^st place award at SNUG 2008.  In this paper, Cliff provided a detailed discussion on problems and solutions in CDC design and verification, and in particular, he mentioned that the industry by then has identified these types of design techniques as clock domain crossing techniques. By 2008, CDC had become a known acronym in the industry and the problem space is also more or less well understood.

However well understood the problem may be, doesn’t mean it is completely solved. Advancement in design size and complexity has created additional requirements in CDC verification in recent years in the areas of performance and capacity. The second-generation tools, though functionally comprehensive, do not meet the needs of technology leaders who are designing multi-million-gate SoC designs with complex clocking architectures. To serve these companies, Real Intent released Meridian CDC 3.0 in 2010, with a focus on capacity and speed so as to enable CDC sign-off. With Meridian CDC 3.0, it is possible to verify over 100 Million gate flat full-chip designs with over 100 clock domains without having to break the design into smaller pieces for CDC verification. This translates into major productivity gains for the design team, and also eliminates the chance of bugs slipping through when stitching results together from sub-blocks. The ability to process a whole 100 Million gate design flat represents a significant improvement over earlier and other solutions.

The past 10 years have seen many changes in CDC design and verification. From a couple of asynchronous clock domains to well over 100 asynchronous clocks, from manual review to the 3^rd generation CDC tools, and the trend is set to continue. Real Intent is a veteran and leader in the field of CDC verification, and will continue to serve the needs of design teams who are pushing the limit of today’s SoC designs as they approach one billion gates.

###

¹ Cliff Cummings, “Synthesis and Scripting Techniques for Designing Multi-asynchronous Clock Domains”, http://www.sunburst-design.com/papers/CummingsSNUG2001SJ_AsyncClk.pdf, SNUG-2001.

² Cliff Cummings, “Clock Domain Crossing (CDC) Design & Verification Techniques Using SystemVerilog”, http://www.sunburst-design.com/papers/CummingsSNUG2008Boston_CDC.pdf, SNUG-2008.

While we’ve chuckled over this comment for years, we think a better analogy comes from another part of the animal kingdom and it goes something like this:  Traditional hardware emulators are a lot like the dinosaurs that roamed the earth for 160 million years.  Both are now extinct, the latter wiped out at the end of the Mesozoic Era.  The former, wiped out by hardware-assisted verification platforms designed and implemented with the largest commercial FPGAs that are as fast and sleek as a Gazelle.

Dinosaurs were dominant terrestrial vertebrates, a term that sounds slow, plodding and ponderous, not at all unlike the description of early hardware emulators.

At their introduction in the 1980s, emulators were considered revolutionary and a bold feat of engineering marvel.  The high cost of ownership, however, limited adoption to big companies with large budgets and complex design problems.  Further, a traditional emulator’s maximum speed was about one megahertz (MHz), slow even then.  They were also criticized for being difficult to set up, wasting time and resources.  A common refrain in those early days was the excessive time to emulation.

Dinosaurs are known to have laid eggs.  Hmmm.

As we compare the latest generation of hardware emulation systems to the impressive gazelle, it’s easy to understand why they are changing designers’ perception of this market segment.  They perform at significantly faster speeds, are notably dexterous in their design verification deployment, and drastically more cost effective.

Gazelles are reputed to be swift animals.  In fact, some are able to maintain speeds as high as 50 miles per hour for extended periods of time.  Today’s emulation systems are equally swift –– some clock in at 10 megahertz (MHz) on a 40-million gate design.

These new functional verification engines have a small footprint and are light weight, saving space, power and infrastructure costs, and execute at speeds of several megahertz even in transaction-based co-emulation.  Their debugging capabilities are similar to those of the beloved HDL simulator.  Even more attractive is their pricing –– they sell for a fraction of the cost of older generations of emulators.  They can be used by the embedded software team and hardware designers for hardware/software co-verification, and increasingly are used as a solution to an event-based simulator’s runtime problems.

The gazelle is appreciated for being both nimble and graceful, and does not lay eggs.

Experts tell us we can learn much from the Animal Kingdom.  We’ve learned enough to be able to compare and contrast the characteristics of chip verification tools to two venerated animals.  As we’ve shown, traditional emulators have gone the way of the Dinosaur while today’s fast emulation systems are emulating the characteristics of a Gazelle.

With double-digit increases in attendance in all categories, DAC 2011 in San Diego was a success. Floor traffic was high, our suites were booked, conversations with designers were productive, and the iPad drawing prizes were flying off the shelves in every booth!

DAC doesn’t just represent an opportunity to tell attendees what solutions we have to offer. More importantly, it is a great opportunity to learn from designers and verification engineers what they think is important, what trends they are noticing, and what they are looking toward in the future.

While much of this discussion in anecdotal, one useful way we gather trend data at Real Intent is through our attendee survey form. Hundreds of visitors to the Real Intent booth completed a survey to report their challenges, attitudes toward different topics, and what keeps them up at night. By aggregating this data we can see some important trends.

One new question we collected data for was the attendees’ plans to adopt RTL Sign-off Technologies. (Note that in this graph, the numbers are absolute, not percentages).

As you can see, many people are already using Lint and CDC tools, although these areas are still growing as they are being driven by design complexity. The newer applications of Constraint Verification and X-Propagation Analysis showed less current usage, and relative to that, significant interest in adoption. In fact, X-Verification in general was one of the hottest topics at DAC this year, with many visitors to our booth inquiring about our new solution, Ascent™ XV.

Another important question we ask attendees is about the number of clock domains they expect in their next design. I’ll show this as a pie graph, and number of responses to this question was 163.

Compared to previous surveys we have done, the number of clock domains keeps going up, with two-thirds of respondents expecting more than 25, and a significant number expecting more than 100. This trend is obviously driving the strong demand we are seeing for our flagship product, Meridian™ CDC.

While on the subject of CDC, we asked DAC attendees if they have ever had a CDC bug slip through, causing a late-stage ECO or silicon re-spin.

There were 94 responses to this question, with nearly two-thirds reporting that they have had a CDC bug slip through. With the complexity of SoCs increasing, as evidenced by number of clock domains, this is clearly fueling more need for CDC Verification tools like Meridian CDC.

It’s not surprising then, to see the answer to the next question: Do you Consider CDC Verification to be a Sign-off Criterion?

With 103 responses, an overwhelming majority, 83% of attendees, see CDC Verification as a necessary addition to their sign-off regimen, since CDC bugs cannot be detected by functional simulation or static-timing analysis.

We also surveyed attendees on the issues that they encounter with their current CDC or Lint tool. As we expected, the problem of noisy reports ranks high. This is primarily because the industry-leading Lint tool, and its add-on CDC option, relies on templates and does not ensure a correct design environment set-up. Without a correct set-up, many non-issues are erroneously flagged, resulting in a noisy report with actual CDC bugs being lost in a sea of tens of thousands of warning messages.

Ranking even higher, interestingly, was performance. As SoC designs grow larger, full-chip CDC analysis becomes intractable for all but the fastest and highest-capacity tools. This is an area where Meridian CDC shines, routinely handling designs in excess of 100 Million gates.

Shifting gears to one of the newest and hottest topics at DAC, we asked attendees about their level of concern about functional bugs that are caused by differences in X-Interpretation, and found that it is quite high.

While X-Propagation hazards are not a new problem, they are growing in significance thanks to increasing design complexity. Not only can X-Propagation problems mask functional bugs in RTL simulation, but they also require painful debugging of mismatches between RTL and gate-level simulation. Out of the 118 responses to this question, only 13% of attendees registered no concern, and a full quarter were “very concerned”. Indeed, the interest level in Ascent XV, Real Intent’s new solution for X-Verification, was extremely high at DAC.

Finally, we asked about the area of Exceptions and Constraints Management, to learn what “pain points” attendees were dealing with.

Constraints Checking was easily the highest reported “pain point”, with other areas related to constraints and exceptions also being ranked highly. This is clearly an important and growing problem that requires modern tools, such as Real Intent’s PureTime™, to address constraints and exceptions management across full-chip SoC designs.

In summary, DAC offered Real Intent an opportunity to not only tell attendees about our solutions, but to measure the important trends and concerns that designers face today, as well as report them back to you.

I would like to thank every DAC attendee that completed our survey form. To give them even more reason to participate, each attendee who completed the survey was entered into a drawing for an iPad 2. I am happy to announce that the winner of the iPad 2 drawing was Jim Kelly of NVIDIA. Congratulations, Jim!

We look forward to seeing you next year at DAC 2012 in San Francisco!

Real Intent will feature its Ascent™ XV solution, the industry’s first and only solution for comprehensive X-verification and sign-off. Ascent XV isolates and eliminates functional bugs that are masked by X (unknown value) propagation in RTL simulation, and reduces gate-level simulation debugging due to mismatches between RTL and gate-level simulation results caused by differing X interpretation.

Also to be featured are the latest advances in Meridian™ CDC, the industry’s flagship Clock Domain Crossing sign-off verification solution, and new capabilities within Ascent Lint, the industry’s fastest and most accurate lint solution, which is complemented by automatic formal checks in Ascent IIV (Implied Intent Verification).

Real Intent will also show Meridian DFT, its Design-for-Test verification solution, and PureTime™, its constraints management solution with glitch-aware exception verification.

And, to learn what solutions will be crucial to verifying the billion-gate designs that are right around the corner, be sure to hear Real Intent CEO Prakash Narain along with other experts from Intel, Broadcom, NVIDIA, Qualcomm and Mindspeed on the DAC technical panel entitled:

“The Billion Dollar Question: How to Verify Billion-Gate Designs”

Wednesday, June 8, 2011 – 4:00 PM to 6:00 PM – Room 33ABC – For details, Click here

Next-generation chips will contain literally billions of gates that need to be verified before committing to silicon. With billions of dollars at stake, the right solution is crucial for verifying designs susceptible to complex failures arising from corner-case confluences of timing and functionality. This panel will debate the merits of emerging solutions for such self-contained verification problems that threaten to subvert the nominal “simulation plus STA” verification flow.

TO BOOK A PRIVATE DEMO SUITE APPOINTMENT:

If you’d like to learn how to comprehensively sign-off on your RTL code for X-accuracy, CDC integrity, syntax, semantics, DFT and constraints integrity, then please be sure to book your private meeting with Real Intent’s experts by visiting www.realintent.com/events/dac.php.  Appointments are available Monday through Wednesday, 9 AM to 6 PM, but slots are limited, so register TODAY!

TO VIEW A BOOTH DEMO:

• Please visit booth #2131 at DAC 2011
• Complete a short survey at the booth to enter our drawing!

We look forward to seeing you at the show!

One great thing about such events is that they give us an opportunity to survey designers on SoC design trends and discover what they think is important in the area of Sign-off. Since they have taken the time to attend the seminar, clearly these designers have more interest in the subject matter than would be indicated in a purely random poll, but it is still very interesting to see what trends we can learn from the survey. Here are results from some of the questions.

As you might imagine, we asked a lot of questions about Clock Domain Crossing. The first was “How Many Clock Domains Will Your Next Design Have?”

As you can see, the results showed that over half of the designers expect to have 25 or more clock domains on their next chip. We continue to see an upward trend with more SoCs having greater than 50 clock domains and some SoCs already in the hundreds. This greatly increasing complexity is fueling the growth of CDC Verification and driving the capacity, performance and comprehensiveness requirements that have compelled more companies to choose Meridian CDC.

We then asked if designers had ever had a CDC-related bug slip through and cause late-stage ECO or a silicon respin.

Over three-fourths of these designers reported that they have had a CDC Bug slip through. Clearly, CDC Verification has become an imperative, and one of the most important requirements of a CDC Verification solution is comprehensiveness.

Based on this result, the result of the next question was not a surprise. We asked whether designers considered Clock Domain Crossing Verification to be a Sign-off Criterion. No graph is needed for this one, because 100% of the attendees answered Yes.

Since Sign-off requires a solution with the capacity and performance to handle full-chip designs, without producing noisy reports, we surveyed designers on these issues. For this question, we also broadened the poll to include Lint.

Clearly, noise is a major issue with many designers’ current tool.  One user at the seminar reported that a CDC bug had caused a respin of a large SoC. He said that the tool he was using on this design (which was not Meridian CDC) did spot the CDC bug, but it was buried in a report containing 30,000 warnings. This elicited a collective groan from the audience, as many had obviously dealt with this issue. The user reported that he got rid of that tool and replaced it with Meridian CDC from Real Intent.

This graph also shows that performance and capacity are major issues. Designers seem more worried about performance today, since some tools are not able to give quick feedback to designers, but we are hearing more and more concern about Capacity as SoC design sizes grow into the 100s of Millions of gates.

Finally, as I mentioned earlier, one of the technical sessions in this seminar was on X Verification. We also surveyed designers about their level of concern for this hazard.

The result shows that most designers were very concerned about bugs slipping through to silicon due to X-Propagation, which can mask functional bugs due to a phenomenon known as X-Optimism. X-Optimism is a coding hazard that occurs when a simulator assigns a known value when the value really should be unknown. Such bugs are highly elusive, and require a comprehensive solution to flag potential hazards and identify X-Optimism bugs when they occur in RTL simulation. Indeed, the session on Ascent XV for X Verification generated a lot interest and excellent questions about how to detect and eliminate X Bugs.

This seminar gave us the opportunity to preview some of our latest technology for designers in Silicon Valley, as well as to sense what concerns they have and what trends we should be aware of. And it also gave us an opportunity to get a jump on DAC, where we will be showing the latest developments in our solutions for Advanced Sign-off Verification.

Don’t Miss Us At DAC 2011 in San Diego! To sign up for a suite presentation and demo, email us today at dac@realintent.com.

Then, he said complexity is rising due to the increased use of embedded software.  According to his team’s calculations, the software portion of a system on chip (SoC) is growing at a rate of 140 percent per year, while hardware is expanding about 40 percent year to year.

With all the rolling around in my mind, I barely registered the radio announcer’s voice, but snapped to attention as Bon Jovi began singing:

Whoa, we’re half way there

Whoa oh, livin’ on a prayer

… we’ll make it I swear

Whoa oh, livin’ on a prayer

Whoa, is right!  In an earlier career, Jon Bon Jovi must have been a hardware designer or a verification engineer.  Otherwise, it’s hard to imagine him composing a song about livin’ on a prayer for anything but SoC design.

Verifying hardware design?  An impossible task that, at times, seems to need some celestial intervention or as Bon Jovi intones, prayer.  That’s what it may seem like for the hardware designer I met last week or verification engineer whose job it is to debug the design.

Functional verification is a way to thoroughly debug a design before silicon availability, though exhaustive functional verification using a software simulator is not a viable solution any longer because of its unsatisfactory performance.  Moreover, simulation farms do not address large designs since they require long sequences of tests that consume billions of cycles and cannot be parallelized.

Fortunately, prayers do get answered.  For example, EVE pioneered an approach to hardware-assisted verification that combines traditional emulation and rapid prototyping systems into a single-unified environment for ASIC and SoC debugging and embedded software validation.  And, Real Intent produces automatic verification solutions using innovative formal techniques in an easy to use methodology.

Hardware-based verification platforms are more than just another emulation product because they can be used by hardware designers to verify and debug SoC hardware designs, and embedded software developers to validate SoC embedded software.  The hardware and the embedded software can be debugged concurrently, giving engineering teams two concurrent views of a design, the inner workings of the SoC hardware and the whole embedded software code.  An engineering team can trace and change any of them and monitor the effects.  A hardware bug that effects the embedded software code execution can be traced starting from the embedded software and vice versa.

While Bon Jovi’s lyrics may seem apropos, don’t keep livin’ only on a prayer!  EVE and Real Intent can help.  They will be at the 48th Design Automation Conference next month in San Diego demonstrating their solutions.  Stop by EVE in Booth #2836 and Real Intent in Booth #2131 to learn more.

###

Special thanks to Bon Jovi.  Livin’ on a Prayer is from the album Slippery when Wet and was released as a single in 1986.

Real Intent, as a leader in the space of CDC verification and sign-off, has made great contributions to the field by advancing the technology, as well as in educating the industry on key CDC issues. The Real Talk Blog, over the past year, has featured many articles discussing aspects of CDC verification and sign-off. A few highlights are included here:

CDC (Clock Domain Crossing) Analysis – Is this a misnomer?

Al Joseph, Sr. Application Engineer, wrote about the fact that while the industry was quick to adopt the acronym “CDC”, and many EDA vendors were quick to claim to have a CDC solution, users need to understand what CDC analysis really entails. A Real CDC solution must go far beyond just checking for single-bit and data-bus metastability management. It should also recognize and verify all asynchronous interfaces, support RTL and gate-level netlists, and incorporate structural, formal, and metastability simulation techniques.

Clock Domain Verification Challenges: How Real Intent Is Solving Them

Real Intent CTO, Dr. Pranav Ashar, discussed the mounting challenges facing clock domain crossing verification today, such as the number of signal crossings between asynchronous clock domains, the proliferation of gated clocks, widely disparate and dynamic clock frequencies, reset distribution, timing optimization, etc.  Dr. Ashar also touched upon how Real Intent’s solution addresses these challenges.

Verifying CDC Issues in the Presence of Clocks with Dynamically Changing Frequencies

Vishnu Vimjam, R&D Manager, discussed a unique capability Meridian CDC has in verifying designs with dynamically changing frequencies.  With other solutions, users would have to perform multiple runs to verify the correctness of the design under different frequencies combinations. Using Meridian CDC, however, users can obtain confidence in one run on whether there will be CDC design errors under all possible frequencies. This is the most advanced technique in formal CDC analysis, not a small achievement for Meridian CDC R&D.

What Do You Need to Know for Effective CDC Analysis?

People often underestimate the knowledge required to make the best use of a CDC tool. Sr. Application Engineer Al Joseph outlined all the things a design or verification engineer needs to understand, such as power, testability, quasi-static domains, and mode selection, etc., in order to be the most productive and effective in using a CDC solution.

Is Your CDC Tool of Sign-Off Quality?

With the increase of design size and number of asynchronous clock domains (we have worked with companies with well over 100M gates with 200 asynchronous clock domains), CDC sign-off has become a must-have in the verification sign-off flow. However, not every CDC solution is up to the task of CDC sign-off. Al Joseph, Sr. Application Engineer, wrote about the criteria a CDC tool needs to have in order to enable CDC sign-off.

Top 3 Reasons Why Designers Switch to Meridian CDC from Real Intent

Rick Eram, Director of Sales at Real Intent, has first-hand knowledge of why designers are switching to Meridian CDC after trying out competitors’ products. In short, the main reasons are ease-of-setup, accuracy, performance and coverage. To sum it up, “Doing CDC verification takes a Real CDC tool architected to do the job, not a linter adapted to do CDC work”.

Real Intent has a wealth of knowledge and experience in CDC verification and sign-off. It is our mission to help every design and verification team succeed in achieving CDC sign-off. Come and join us for an informative and fun seminar on May 5^th at noon! You can sign up at http://www.springsoft.com/ri-ss-seminar.

I look forward to seeing you there!

Certitude is the only solution to provide an objective measure of the quality of your verification environment and guidance on how to improve it. Certitude injects potential bugs into your design and evaluates the ability of your verification environment to catch them. It completely analyzes whether the potential bugs are activated, propagated to observable outputs, and detected by your environment, thus identifying whether you need to improve your tests, assertions or checkers.  The result is higher confidence in your verification results and improved design quality.  Certitude provides both guidance and a means of measuring progress throughout the functional verification closure process, and critical data points to support your signoff decisions.

Learn More!

On May 5^th, SpringSoft and Real Intent will be co-hosting a seminar on The Latest Advances in System-on-Chip Functional Verification Sign-off.  Join us there, where we will demonstrate how the Certitude system integrates easily with your existing simulation environment and applies these patented techniques to provide comprehensive, objective feedback on the quality of your verification environment and how to improve it.  We will show how recent technical advances, such as an improved fault prioritization algorithm and enhanced fault-dropping techniques, enable Certitude to quickly find the most serious deficiencies in your environment with a minimum of simulation resources.  We will also demonstrate how the tight integration with Verdi™ and the new Fault Impact Ranking engine minimize the analysis and debug effort required to understand and fix these problems.

The “unknown” as it is called in digital design, is represented as an “X” logic level.  This means that the signal might actually take on a value of “1”, “0”, or “Z” in 4-state logic.  X values have existed in logic design forever, and are commonly used to represent the state of uninitialized signals, such as nets that are not driven, or storage elements that have no reset. “X-propagation” occurs when one of these X values feeds downstream logic, causing additional unknowns.  For example, as shown below, when signal ‘a’ is an unknown value, that unknown value is sometimes, but not always, propagated to the output.

assign y = a && b;

a       b      output

0       0         0

0       1         0

1       0         0

1       1         0

x       0         0

x       1         x

X’s also take on a beneficial role in both synthesis and verification. Explicit assignments to an X value can signify a “don’t care” condition that grants synthesis tools greater flexibility to optimize the generated logic. The X value is also used in verification to flag illegal states, created by problems such as bus contention. Automatic formal checking tools like Ascent IIV can use these assignments to check that the illegal state cannot be reached.

Unfortunately, X’s can also mask functional bugs in the RTL due to an X-propagation interpretation hazard known as “X-optimism”.  X-optimism is a trait of incomplete coding that incorrectly transforms an unknown value to a known value.  “If-else” statements and “case” statements can be X-optimistic when the condition is evaluated as an X value. Simulation semantics do not propagate the X value but rather translate the unknown X value to a known value.  The fact that the condition was an unknown is no longer visible – it is hidden, in a way that makes the X-propagation elusive. Here is an example:

// if-else conditionals

reg out1;

always @(*)

begin

if (condition)

out_1 = 1′b1;

else

out_1 = 1′b0;

end

condition |  out_1
============
1                   1
0                   0
x                   0

When condition is a 1’b1, then the output is 1’b1 and when condition is 1’b0 the output is 1’b0.  But notice what happens when condition is an X value.  Here the X value is an “unknown”.  But the output is translated to a 1’b0, and the unknown X is now masquerading as though it were definitively a 1’b0, when in fact it could have been a 1’b1 or a 1’b0, depending on how it is synthesized into gates.

While X-optimism bugs can be detected in gate-level simulation, it is slow and painful to debug there. X-optimism may also be innocuous, but still lead to differences between RTL and gate-level simulation that must be painstakingly resolved in order to achieve sign-off.

There are capabilities of existing tools that can help with X-verification. For example, RTL analysis tools like Ascent Lint will identify X assignments. Automatic formal tools such as Ascent IIV take it a step further and can verify that designated “illegal” states cannot be reached, thereby verifying that the X value will not propagate. While highly useful, this covers a relatively small percentage of X’s that might exist. In addition, four-state formal verification tools allow you to write explicit assertions to confirm that an X value cannot propagate to a specified point.  However, this requires knowledge of assertion languages and the ability to completely specify the applicable behavior of the inputs, as well as the need to know every point in the design that needs to be verified by an assertion, which is highly impractical.

X-verification sign-off is not an easy problem to solve, because the mere existence of X values is not an issue. The issue is that hazardous X propagation is often elusive because it is transformed by X-optimism into supposedly known values. Moreover, X-optimism is an insidious and intermittent problem because it only becomes an issue if the X-optimized signal is being used in the design when the optimism occurs.  The functional issue that results may not be detectable for many clocks after the X-optimism occurrence, and there may be multiple sources of X in its fan-in, making root cause analysis very difficult.  Adding to that, if debug occurs at the gate level, simulations are very slow and the logic is not as readable as the original RTL.

What is needed is a comprehensive solution built on the existing RTL verification infrastructure that detects when the propagation of X values masks functional bugs.  Real Intent is developing just such a solution, called Ascent XV. Join us at our joint seminar with SpringSoft entitled “Latest Advances in Verification Sign-off” (sign-up at http://www.springsoft.com/ri-ss-seminar) for details on Real Intent’s comprehensive solution to the X-Verification problem.  Ascent XV is conquering the “unknown” so designers can sign-off with confidence.