Posts Tagged ‘clock domain crossing’
Thursday, May 14th, 2015
In the stories of the Wild West from the 1800s, the image of a cattle drive often is depicted. A small team of cowboys delivers thousands of heads of cattle to market. The cowboys spend many days crossing open land until they reach their destination – one with stock yards to accept their precious herd, and a rail station to deliver it quickly to market. Along the way there are dangers, including losses by predators and mad stampedes by cattle rushing blindly when frightened or disturbed. The primary job of the cowboys is to keep the herd on track and settled as they move to ship-out.
I see immediate parallels between the cowboys of the Wild West and today’s system-on-chip (SoC) design and verification engineers. Cowhands struggle to control and move a big herd. Similarly, today’s design teams grapple with how to keep a project on target and converging to tape-out and success when the gate count of SoCs has become so large it can stretch and even overwhelm their ability to stay on track. How big are these new SoCs? (more…)
Friday, April 17th, 2015
Thanks to the widespread reuse of intellectual property (IP) blocks and the difficulty of distributing a system-wide clock across an entire device, today’s system-on-chip (SoC) designs use a large number of clock domains that run asynchronously to each other. A design involving hundreds of millions of transistors can easily incorporate 50 or more clock domains and hundreds of thousands of signals that cross between them.
Although the use of smaller individual clock domains helps improve verification of subsystems apart from the context of the full SoC, the checks required to ensure that the full SoC meets its timing constraints have become increasingly time consuming.
Signals involved in clock domain crossing (CDC), for example where a flip-flip driven by one clock signal feeds data to a flop driven by a different clock signal raise the potential issue of metastability and data loss. Tools based on static verification technology exist to perform CDC checks and recommend the inclusion of more robust synchronizers or other changes to remove the risk of metastability and data loss.
Thursday, March 5th, 2015
The Design and Verification Conference Silicon Valley was held this week. During Aart de Geus’ keynote, he shared how SoC verification is “shifting left”, so that debug starts earlier and results are delivered more quickly. He identified a number of key technologies that have made this possible:
- Static verification that uses a mix of specialized code analysis and formal technology which are must faster and more focused than traditional simulation
- New third generation of analysis engines
- Advancements in debug
Real Intent has also been talking about this new suite of technologies that improve the whole process of SoC verification. Pranav Ashar, CTO at Real Intent wrote about these in a blog posted on the EETimes web-site. Titled “Shifting Mindsets: Static Verification Transforms SoC Design at RT Level“, it introduces the idea of objective-driven verification:
We are at the dawn of a new age of digital verification for SoCs. A fundamental change is underway. We are moving away from a tool and technology approach — “I have a hammer, where are some nails?” — and toward a verification-objective mindset for design sign-off, such as “Does my design achieve reset in two cycles?”
Objective-driven verification at the RT level now is being accomplished using static-verification technologies. Static verification comprises deep semantic analysis (DSA) and formal methods. DSA is about understanding the purpose and intent of logic, flip-flops, state machines, etc. in a design, in the context of the verification objective being addressed. When this understanding is at the core of an EDA tool set, a major part of the sign-off process happens before the use or need of formal analysis. (more…)
Thursday, February 12th, 2015
In the YouTube video interview below, Oren Katzir, vice-president of application engineering, introduces the topic of clock-domain crossing (CDC) verification. He identifies what are the four key issues that need to be met to achieve SoC sign-off, and what are the features that Real Intent’s Meridian CDC tool offers to handle the deluge of data that can arise in CDC analysis, and as well, work effectively with different design methodologies. I am sure you will learn something from Oren’s experience with many customers’ designs.
Thursday, December 11th, 2014
Real Intent has had an exciting 2014! In the last few months we have announced a new release of Meridian CDC , new distribution partners in Taiwan and India, and seen many of you at trade shows in Silicon Valley, China, Israel, Japan, Germany and the United Kingdom. Our YouTube video channel keeps you up to date on all the latest developments at Real Intent, with our most recent on the New 2014 Release of Meridian CDC Meets Challenge of Billion-gate SoCs. I also discussed “Beer, New Meridian CDC, and Arnold Schwarzenegger?! ” with Sean O’kane of ChipEstimate in an ARM TechCon video interview.
There have been over 50 postings on the Real Talk blog this year, and I have selected the most popular ones read by the EDACafe audience. Here are the top five:
As you can see clock-domain crossing (CDC) remains a very hot topic. Look for more postings on this sign-off requirement in the coming year.
Thursday, October 16th, 2014
At ARM Tech Con 2014, I discussed beer, the new release of our Real Intent clock-domain crossing software Meridian CDC, and a new spokesperson for our company, with Sean O’Kane of ChipEstimate.TV. Enjoy!
Thursday, October 9th, 2014
Real Intent will release our greatly extended Meridian CDC clock domain crossing software in November with new capabilities headlined by more hierarchical firepower and the launch of a user-configurable debugger.
The 2014.A edition announced last week (on my wife’s birthday), will have 30% higher performance against the existing tool and a 40% smaller memory footprint. The formal analysis engine within Meridian has also been given a 10X boost in throughput.
In the YouTube video interview below, Ramesh Dewangan, vice-president of application engineering, points out that the bottom-up hierarchical flow is key to Meridian CDC’s giga-scale capacity (though the tool is equally capable of handling designs ‘flat’).
The hierarchical approach means that the complete design view of the SoC is available for CDC analysis at any time. There is no abstraction or any approximation that is used that has a potential to miss bugs. Being more specific, there is neither abstract modeling nor waivers.
Thursday, October 2nd, 2014
ARM TechCon was in Santa Clara this week and Real Intent was exhibiting at the event. TechCon was enjoying its 10th anniversary and ARM was celebrating the fact that it is at the center of the System-on-Chip (SoC) revolution.
The SoC ecosystem spans the gamut of designs from high-end servers to low-power mobile consumer segments. A large and heterogeneous set of players (foundries, IP vendors, SoC integrators, etc.) has a stake in fostering the success of the ecosystem model. While the integrated device manufacturer (IDM) model has undeniable value in terms of bringing to bear large resources in tackling technology barriers, one could argue that the rapid-fire smartphone revolution we have experienced in the last five years owes in large part to the broad-based innovation enabled by the SoC ecosystem model. How are the changing dynamics of SoCs driving changes in verification requirements, tools and flows and thereby changing the timing sign-off paradigm?
Thursday, August 28th, 2014
In our last post in series, part 4, we looked at the costs associated with debugging and sign-off verification. In this final posting, we propose a practical and efficient CDC verification methodology.
Template recognition vs. report quality trade-off
The first-generation CDC tools employed structural analysis as the primary verification technology. Given the lack of precision of this technology, users are often required to specify structural templates for verification. Given the size and complexity to today’s SOCs, this template specification becomes a cumbersome process where debugging cost is traded for setup cost. Also, the checking limitations imposed by templates may reduce the report volume, but they also increase the risk of missing errors. In general, template-based checking requires significant manual effort for effective utilization.
Thursday, July 31st, 2014
Last time we discussed practical considerations for designing CDC interfaces. In this posting, we look at the costs associated with debugging and sign-off verification.
Design setup cost
Design setup starts with importing the design. With the increasing complexity of SOCs, designs include RTL and netlist blocks in a Verilog and VHDL mixed-language environment. In addition, functional setup is required for good quality of verification. A typical SOC has multiple modes of operation characterized by clocking schemes, reset sequences and mode controls. Functional setup requires the design to be set up in functionally valid modes for verification, by proper identification of clocks, resets and mode select pins. Bad setup can lead to poor quality of verification results.
Given the management complexity for the multitude of design tasks, it is highly desirable that there be a large overlap between setup requirements for different flows. For example, design compilation can be accomplished by processing the existing simulation scripts. Also, there is a large overlap between the functional setup requirements for CDC and that for static timing analysis. Hence, STA setup, based upon Synopsys Design Constraints (SDCs), can be leveraged for cost-effective functional setup.
Design constraints are usually either requirements or properties in your design. You use constraints to ensure that your design meets its performance goals and pin assignment requirements. Traditionally these are timing constraints but can include power, synthesis, and clocking. (more…)