Graham is VP of Marketing at Real Intent. He has over 20 years experience in the design automation industry. He has founded startups, brought Nassda to an IPO and previously was Sales and Marketing Director at Internet Business Systems, a web portal company. Graham has a Bachelor of Computer … More »
Be Early to Be Better
May 16th, 2013 by Graham Bell
Today’s systems on chip (SoC) are deeply complex in new ways. A dozen or so years ago, a state-of-the-art processor such as the Intel Pentium 4 used 42 million transistors, was built on a 180nm process and relied upon discrete chips to handle its system interfaces. Scroll forward, and the Westmere processor that Intel introduced in 2012 uses 2.6 billion transistors and is built on a 32nm process. The chip includes ten 64bit x86 cores, L3 cache, graphics processing, DDR3 interfaces, virtualisation support and more. This trend to massive integration is even stronger in the mobile space, where SoCs bring together complex computing, communications and entertainment functions on one die.
It’s no longer possible to design all the subsystems of an SoC from scratch and expect to get the chip out in a reasonable timeframe, so today’s SoCs are complex integrations of new logic, IP blocks brought forward from previous designs, and functional and interface IP licensed in from third parties. Some companies are even using third-party IP to build their system interconnect, on the basis of that its communications management support and interfaces to other IP blocks will help get a design out more quickly. In effect, an SoC is a sea of interfaces.
The use of IP enables complex products such as the iPad, which is good for the consumer, but brings integration challenges for SoC designers and the verification teams that ensure their designs will work as planned. Individual IP blocks may be as complex as entire SoCs of five years ago, and may have internal clocking and power-management strategies which SoC designers need to be aware of. The integration of these complex blocks means that clock signals may have to negotiate up to 100 asynchronous clock domains as they cross block interfaces. Similarly, systemic power management strategies may involve coordinating power management within a block and among many blocks.
Managing the verification of such complex systems is challenging. The designs are large, so designers need tools with very high capacities. They need to be able to control the rising tide of uncertainty caused by clock signals that cross domains, and power-management strategies that create unknown (X) logic states when they blocks are turned on and off. Most of all, designers need these tools to tackle such problems at the highest level of abstraction possible, to speed up the verification process and stop the issues multiplying and becoming more obscure as the RTL design is decomposed to gates. Clock domain crossing (CDC) tools, engineered to recognize and analyze crossings for problems, are essential to help control the verification complexity involved in tackling a full SoC.
With the right tools, overcoming these issues can mean more than just a problem solved: by applying the right analytic tools, the design can actually be functionally improved. For example, linting tools that give early indications of potential design-for-test problems help avoid synthesizing untestable logic. Tools that understand the X states that are created at domain boundaries in complex designs, and how they propagate, can help avoid too much optimism about their impact at the RTL level (where X states can hide real issues), and too much pessimism about their impact at the gate level. The result: better analysis leads to better designs.
The same is true with ‘resetability analysis’, which considers whether it is necessary to take a reset signal to every node that the design says needs one, or whether it is possible to restrict the distribution of reset signals to a subset of critical nodes. If an early analysis shows that some nodes can do without a reset signal without affecting the logical function, which means less routing and lower power consumption on the final chip. Again: better analysis leads to a better design.
As SoCs have become more complex, so has the task of verifying that what is implemented on chip is what the designer intended. No single verification approach can deliver the certainty that design teams need to tape out, but a suite of tools that each address a particular issue can help build that confidence. Applying the tools may also do more than avoid errors: better analysis early in the design process can avoid issues propagating, and, by highlighting which issues matter and which can be safely ignored, give designers the freedom to improve their designs.