ARM should be applauded for the significant role it has played in bootstrapping and further enabling the SoC ecosystem model. By licensing its processor and digital IP instead of manufacturing its own chips, ARM has freed its partners to aggressively build and refine their products without being reliant on general purpose devices or rigid form factors. And it did not hurt that ARM’s advantage in the mobile space was the low-power architecture and instruction set designed to sip power rather than glug it. Going forward, the optimization and perpetuation of this model will depend on a deep commitment by the EDA industry to recognize and fill the specific needs inherent to this model. ARM has a made a significant commitment on its side and works closely with EDA companies to develop reference methodologies (RMs) for implementation flows that enable ARM licensees to customize, implement, verify and characterize ARM processors for their chosen process technologies.
A case in point is that an SoC today is really a sea of interfaces. This is a consequence of the building-block design style used to create them. Since system timing is dominated by the delays found in long interconnect wiring paths, large monolithic ICs have given way to designs that use a number of small blocks with signal crossing interfaces. Besides the timing issue, each block can be optimized for low-power operation using an independent supply voltage and clock frequency control.
As a consequence, much of the performance optimization is being targeted at these interfaces in the form of aggressive design of protocols and their implementation. A second consequence is that most of these interfaces are asynchronous or need to be modeled that way. In other words, it would be more correct to say that an SoC today is really a sea of aggressively designed asynchronous interfaces!
This prominence of interfaces in the modern SoC has big implications on verification requirements, tools and flows and is changing the sign-off paradigm.
For starters, Clock-Domain-Crossing (CDC) verification is now a first-order sign-off requirement. CDC bugs are insidious in that they can remain unnoticed until after tape out and deployment. Their difficulty lies in that they are at the intersection of functionality and timing and neither functional simulation nor static timing analysis meets their challenge. It used to be the case that the number of clock crossings in a chip was small enough that manual review sufficed. Not any more. With more than fifty clock domains per SoC, and SoC sizes in the hundreds of millions of gates, it is absolutely essential that CDC sign-off be automated by means of a specialized tool that has deep and first-principles domain expertise in asynchronous interface design techniques and the typical implementation idioms therein.
An important point to register is that correct clock-crossing interface design is predicated not just on correct circuit implementation, but also on correct protocol design. As a result, the first CDC sign-off must happen at the pre-synthesis RTL abstraction level to intercept any protocol design bugs.
A further truism is that CDC sign-off is only as good as the environment setup feeding into it. Improper clock grouping, clock propagation, mode setup, reset propagation, etc. can lead to incorrect CDC analysis and a bad sign-off.
There are two implications of the above statements on timing-constraints closure in the modern SoC.
First, until recently, timing constraints setup fed into the Quality-of-Results (QoR) steps of synthesis, physical design and static timing analysis. Going forward, timing constraints closure is being fed into a black-and-white verification sign-off step. The timing-constraints specification exercise is, therefore, no more just a question of dealing with over-designed paths and logic, or of compromising on the QoR spec. It now part of a verification sign-off step with an implication of possible very-expensive-to-fix field bugs if done incorrectly.
Second, CDC sign-off now starts at the pre-synthesis RT level. That is possible only if SoC-level timing-constraints are available at that stage. Basically, the obligation to plan, create and manage timing constraints has moved up an abstraction level.
All of the above points to the need for tools for precise CDC analysis and for full-featured timing-constraints creation and management starting at the RT level. These tools are missing from incumbent EDA flows, and it is clear that marginal improvements to existing tools and flows will not meet the needs. Real Intent is very much in the business of filling this need with its Meridian family of CDC and Constraints tools. In that respect, Real Intent will be a key player and a key enabler of the SoC ecosystem model.
How has your timing sign-off methodology changed recently?
Meridian tool flows from Real Intent provide pre-synthesis RTL and post-synthesis netlist verification of CDC and SDC for SoC timing sign-off.
Guest Partner Blogger:
ARM welcomes its wealth of Partners in the ARM Connected Community (CC) to submit guest blogs to be published on our multiple community blogs. If interested in participating please submit email inquiries to Tell.Us@arm.com.
The ARM Connected Community (CC) is an extensive ecosystem covering all aspects of ARM processor-based design, from chip implementation through to system and device design. The CC provides a platform for collaborative innovation, with multiple types of forums for members to work with one another, and with customers, to solve industry challenges, all with the purpose of enabling designers to focus on differentiating features and an accelerated time-to-market for ARM powered solutions.
0 Comments On This Entry
Please log in above to add a comment or register for an account
Show me the cache
on Yesterday, 09:24 AM
Ten Things to Know About big.LITTLE
on Jun 18 2013 10:59 AM
Mentor, Freescale, Samsung DAC talks: EDA, IoT & Mobile growth & challenges
on Jun 17 2013 08:59 AM
Big Things Were a Kickin' at DAC in Austin with ARM & ARM Partners
on Jun 13 2013 01:41 PM
Addressing the Challenges with SoC Integration and Verification
on Jun 05 2013 08:09 AM