A spectacular rise in SoC design complexity and size means it's critical to minimize lengthy problem detection and fix issues as early as possible using a comprehensive hierarchical SoC methodology. Here's why.
Spectacular is the only way 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 subsystems 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.
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 synthesize 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 200 MHz?
- What is my test coverage?
- What is the power consumption of this block?
- Are there any unsynchronized 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, signaling 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.