1.4 SOC Design Challenges | From ASICs to SOCs: A Practical Approach

Why does it take longer to design SOCs compared to traditional ASICs? To answer this question, we must examine factors influencing the degree of difficulty and Turn Around Time (TAT) for designing ASICs and SOCs. Usually for an ASIC, the following factors influence TAT:

Frequency of the design
Number of clock domains
Number of gates
Density
Number of blocks

Another factor that influences TAT for SOCs is system integration ( mainly integrating different silicon IPs on the same IC) that is one of the key factors in TAT. In a typical SOC, you deal with complex data flows and multiple cores such as CPUs, DSPs, DMA, and peripherals. Therefore, resource sharing becomes an issue. Figure 1.5 shows a bus-based approach to integration. Here, the architecture is tightly coupled , which is advantageous for performance, area, and efficiency. However, communication between IPs becomes very complicated.

Figure 1.5. A Traditional SOC Architecture (Copyright 2002, Sonics, Inc.)

graphics/01fig05.jpg

Let's examine this approach, as it is common practice among chip architects and designers. Here the CPU, DMA, and the DSP engine all share the same bus (the CPU or the system bus). Also, there are dedicated data links and a lot of control wires between blocks. Additionally, there are peripheral buses between subsystems. As a result, there is excessive interdependency between blocks and a lot of wires in the chip. Therefore, verification, test, and physical design all become difficult to fulfill.

A solution to this system integration is to use an intelligent , on-chip interconnect that unifies all the traffic into a single entity. An example of this is Sonics' SMART Interconnect SiliconBackplane MicroNetwork.

A MicroNetwork is a heterogeneous, integrated network that unifies, decouples, and manages all of the communication between processors, memories, and input/output devices. Figure 1.6 shows an SOC design using MicroNetwork architecture. An example of a MicroNetwork is Sonics' SiliconBackplane, which guarantees end-to-end performance by managing all communications among IP cores, as well as ensuring high-speed access to the shared memories common in typical SOC designs.

Figure 1.6. Sonics' SiliconBackplane Used in SOC Design Architecture (Copyright 2002, Sonics, Inc.)

graphics/01fig06.gif

SiliconBackplane uses a standard core interface known as the Open Core Protocol (OCP), which delivers the first openly licensed, core -centric protocol. OCP comprehensively fulfills system-level integration requirements. The OCP defines a comprehensive, bus-independent, high-performance, and configurable interface between IP cores and on-chip communication subsystems. OCP is a functional superset of the Virtual Socket Interface (VSI) Alliance virtual-component-interface (VCI) specification, and enables SOC designers and semiconductor IP developers to prepare their cores for plug-and-play integration using Sonics' SiliconBackplane. Appendix B provides more information on OCP.

An SOC designer can optimize the design under development by optimizing the SiliconBackplane using a development environment developed by Sonics. Configuration and tuning parameters can be efficiently selected to optimize the SiliconBackplane and, as a result, to optimize the SOC design. The development environment consists of tools to wrap and package IP cores for integration as well as an automated basic configuration of the SiliconBackplane, and stimulus/performance analysis tools for successively refining SOCs.

When compared to a traditional CPU bus, an on-chip interconnect such as Sonics SiliconBackplane has the following advantages:

Higher efficiency
Flexible configuration
Guaranteed bandwidth and latency
Integrated arbitration

Design verification is another key challenge in designing SOCs. Verification has to happen at all levels of hierarchy, such as core/IP level, interface, and chip level. The integration of several cores on a single chip brings with it new challenges to the testing methodology even when the individual cores have design for test (DFT) already built in. The cores may have different types of testability: scan, built-in self-test (BIST), and functional. The integrator of the cores must decide on a coherent test style from the outset and choose the cores accordingly . This, in turn, implies that the integrator has access to a number of IP providers and he or she has established an acceptance criterion for cores.

Chapter 3 covers the verification of cores and SOCs in more detail.

Top