Global Sources
EE Times-Asia
Stay in touch with EE Times Asia
EE Times-Asia > EDA/IP

Advantages of hierarchical flow for SoC design

Posted: 21 Jan 2014 ?? ?Print Version ?Bookmark and Share

Keywords:system-on-chip? SoC? IP? RTL? hierarchical analysis?

Spectacular is that one word we can use to describe the rise in design complexity for system-on-chip (SoC) devices. Not long ago, 45nm SoCs with up to 80M gates were a huge design challenge. Now, 22nm and 14nm is around the corner, with design capacities of 500M gates or more. A leading graphics chip boasts 1.4B gates.

Along with size, complexity has also increased dramatically in numbers of clocks, clock domains, and power and voltage domains. The sheer number of IPs and amount of integration logic is amplifying small issues in power, testability, and routing congestion into large problems during assembly. It is no longer practical to rely on detection and cleanup of all these problems during integration. The loop to cycle back through IP suppliers, system architects and others will likely derail an ambitious SoC project.

From an integrator's point of view, primarily three factors determine the quality of the design:
???That all the IP to be used has been fully qualified, prior to integration, especially in the configurations the integrator plans to use
???The ability to quickly assess the quality of the integration, based on the above assumption
???To not have to wade through a blizzard of reports on issues inside IPs (which the integrator is not in a position to address), in order to find one or two potentially real issues at the integration level

This calls for a hierarchical approach to analysis and signoff: IP blocks and sub-systems must be fully qualified, in the configurations they will be used, and then abstracted for the purpose of quality and signoff at the SoC level, so the integrator need only see and address those issues unique to the integration.

Figure 1: An HTML dashboard.

What does this look like? For an internal block developer and for an IP supplier, the first steps are the same. You need to get to a quantifiable measure of RTL signoff for the target IP.

A partial list of care-abouts may include:
???Will the code compile correctly?
???Will it simulate correctly?
???Are my clocks and resets right?
???Will my code synthesise correctly?
???Do I have unintended latches or combo loops?
???Will gate level simulations match RTL level simulations?
???Are my state machines really complete?
???Will it fit and run at 200MHz?
???What is my test coverage?
???What is the power consumption of this block?
???Are there any unsynchronised clock domain crossings in the IP that will pose integration risk?
???Are there any non-standard design practices used in this IP that will make integration harder? Will my IP be adequately testable in an SoC context?
???What is an objective set of criteria to signoff against? And how do I create an abstraction of this IP which will be most useful to an integrator?
???Do I have the right timing constraints for SoC integration, especially timing exceptions? Is all of the above true across a representative set of likely user configurations?

An effective form of summary at this stage is an HTML dashboard (figure 1), signalling status of the component. This is a useful handoff to integrators who need to understand the degree to which an IP has been qualified before they pick it up.

The integrator's task
The integrator needs to ensure that the integration they create between all these IPs does not create new signoff problems. How might such a problem be possible if all the IP are clean? Just a few of the possibilities are:
???Creating a combination loop through unregistered paths in IPs
???Failing a synchronisation requirement which the IP assumes will be handled at integration
???Using an IP in a configuration which was not qualified and which has a previously unknown issue in that configuration
???Having IP with an input port assumed to be driven with slower clock but connected to faster clock source at the chip level

Analysis and signoff at this level cannot be skipped. But it can be greatly simplified. First, it is important to signoff and abstract IPs in the target configuration, if this was not already done by the IP provider. The abstraction step is significant. Without this, analysis is feasible but may take longer, both in run-time and analysis/debug time to bypass "don't care" issues inside the IP. As design size approaches those billion gate levels, hierarchical analysis based on abstractions becomes an important consideration.

To understand how this works, consider the example illustrated in figure 2.

Figure 2: As design size approaches those billion gate levels, hierarchical analysis based on abstractions becomes an important consideration.

1???2?Next Page?Last Page

Article Comments - Advantages of hierarchical flow for ...
*? You can enter [0] more charecters.
*Verify code:


Visit Asia Webinars to learn about the latest in technology and get practical design tips.

Back to Top