Interconnect IP Steers SoC Integration Into The Fast Lane

Intellectual property (ip), and its reuse, is expected to rev up soc development from conception to reality. And on paper, it does. But rarely do those selling IP cores tell you just how grueling their integration can be. System-on-a-chip (SoC) design can take much longer than one would hope, even on the second or third go-arounds with the same cores.

How can we make IP integration and reuse easier? By taking it up a notch in abstraction. And that's what Sonics Inc. has done with the Synapse 3220 addition to its portfolio of interconnect IP.

SoCs are exploding in complexity, with the number of functional blocks on a single die running up to at least 50 or more today and heading rapidly into the hundreds. Thus, a way must be found to minimize the number of objects being dealt with, and to ease the process of integration, verification, and subsequent reuse of IP.

A central connectivity issue in classical bus-based SoC architectures is the blocking transaction model, in which the interconnect is limited to servicing transactions between a processing element and peripherals one at a time. In such architectures, any other transactions are prevented from occurring until the transaction in progress is completed. The result can severely limit performance.

Take, for example, a situation in which a given SoC has multiple processors, such as a CPU core and a DSP along with other blocks that provide peripheral support. If one processor accesses a peripheral like a 32-kHz timer, it holds the bus until it receives a complete response from that timer. Many cycles could pass by before any other device can access the bus to initiate another transaction.

Stepping into this breach is Synapse 3220, an IP-based interconnect technology that addresses the overall complexity issues of SoCs. It also squarely faces the connectivity problems of systems with multiple processing elements and myriad peripherals.

The Synapse 3220 interconnect IP product is the latest in Sonics' family of SMART interconnect technologies. Launched in 1999 with the SiliconBackplane MicroNetwork IP offering, the SMART family is a plug-and-play SoC design methodology that hinges on an industry-standard socket called the Open Core Protocol (OCP).

The basic concept surrounding the OCP is that of a bus-independent interface for IP cores. The OCP can be thought of as a fully configurable "socket" that provides a standard format to develop a unique "agent" for each IP core. The resulting core-specific interface includes all of the signals required to describe the core's communications with the bus, including data flow, control, and verification and test signals. It provides a firm boundary around each core that's observable and controllable.

With the OCP as a foundation technology for defining an IP core's bus interface, a communication fabric or transport mechanism is needed. The Synapse 3220 introduction spawns a two-pronged architectural approach to that fabric. This approach brings numerous performance benefits that solve, in an elegant fashion, the issues associated with blocked bus transactions that are seen with traditional buses. It also embodies an SoC design approach that takes abstraction to the next level of hierarchy, reducing the number of objects to a level designers can grasp on a system basis.

The SiliconBackplane MicroNetwork IP product was conceived as a complete answer to the problems swirling around intercore communication on an SoC. However, SiliconBackplane is optimized to handle traffic between IP cores that are best described as "initiators," which is to say those cores that generate system traffic, and a relatively small number of IP cores that can be called "targets," or cores that are serviced by initiators. A CPU, or other processing element, is the best example of an initiator. Targets are exemplified by memories, DMAs, and off-chip communication cores, among others.

Since SiliconBackplane's introduction, though, SoC complexity—and particularly the number of targets—has skyrocketed. Synapse 3220 is the cornerstone of a divide-and-conquer strategy to manage it all (Fig. 1). It handles communication between the growing number of initiator IP cores and the even-faster-growing number of targets.

As complexity rises, Wingard sees large functional blocks being built up into a next-generation black box, or what Sonics refers to as a "tile." Think of Synapse 3220 as a generic nonblocking switch fabric aimed at connecting low-speed peripherals. "It has applications inside a tile for some of the local peripherals associated with things like booting the RTOS, as well as UARTs, timers, and others," says Wingard. "We also see Synapse 3220 being used between tiles or among tiles as a way of hooking up the I/O devices."

By virtue of its nonblocking nature, the interconnect provides low-latency access to a large number of low-bandwidth target cores that can be physically dispersed on the SoC. Many such cores can also be aggregated in a tile.

It's not as if there aren't other ways to approach the latency problems im-posed by a blocking bus structure. One alternative is to use private peripheral subsystems, or secondary buses, to interconnect a partitioned group of targets with the initiators that access them most. Such schemes can end up with buses running all over the die, eating up real estate and opening the door to signal-integrity nightmares.

Moreover, using private peripheral buses is a nonscalable and constraining approach that must be locked in during floorplanning. Any change in the SoC's functionality means a redesign for the related peripheral bus architecture.

According to Avner Goren, manager of wireless architectures at Texas Instruments (TI), Synapse 3220 meets various key objectives for his design group, chief of which is time-to-market. With that as an overall constraint, TI's key goals include limiting of power dissipation in the interconnect and efficient use of die area. Goren sees Synapse 3220 meeting all of these objectives in TI's wireless SoC platform design flow.

Synapse 3220 addresses many goals of SoC developers by being applied early in the architectural definition of a given SoC. The IP is instantiated through Sonics' SOCCreator, a graphical design environment for which the Synapse 3220 and SiliconBackplane interconnects are plug-ins. Within the environment, Synapse 3220 IP is generated on-the-fly as a compilable structure. It's combined with representations of IP cores at any level of abstraction from bus-functional models to register transfer level (RTL) to GDSII. Later in the design cycle, floorplanning information from tools such as Cadence's First Encounter can be imported in standard file formats. This provides relative positioning for the blocks so that the interconnect fabric is constructed in a physically optimized manner.

The environment sits at the front end of the SoC design flow. "We're delivering top-level RTL, integrating and making all the connections, carrying through any timing information and constraints that the architect has put into the system, and providing output that plugs into a standard ASIC design flow," says Dave Lautzenheiser, Sonics' director of marketing. Output from SOCCreator is in the form of RTL and shell scripts for synthesis for the SMART interconnect IP and for all other soft IP cores in the SoC.

A Synapse 3220 interconnect structure has what can be considered a "head end," where up to four initiators connect to it. Currently, it's restricted in that these four initiators must share the same clock regime. That head end consumes less than 25 kgates on the die. Through the Synapse 3220 interconnect, those four initiators can access up to 63 targets at 100 MHz or 40 at 166 MHz (Fig. 2).

Target cores can run at different clock rates from the initiator side, enabling support for a variety of clock dividers. "That means your 32-kHz timer can run real slow and not have to drag down the rest of the system," says Lautzenheiser. From a bandwidth standpoint, the initiator side has bandwidth set up so that it's equal or greater than that of the bandwidth at the largest target. In terms of physical span, at 0.13-µm process technology, Synapse 3220 supports total distances of up to 15 mm, where the longest span is 10 mm from the head end.

The interconnect's nonblocking nature stems primarily from the active agents at the point of interface with the OCP-IP socket associated with each core. The agents use a different protocol than the OCP-IP protocol itself. The resulting bounding of latencies in turn means deterministic response times.

Synapse 3220 employs threading on a hardware level, which is part of the OCP-IP architecture. Each thread is a separate data flow, and the interconnect supports up to four threads. Every thread's data flow is strictly ordered, with commands completed in the same order as they were issued. This is how an initiator IP core can access those terribly slow 32-kHz timers without delaying a high-priority request from the CPU to another core. The CPU's bus access is diverted to another thread, allowing it to complete before the 32-kHz timer access finishes.

A significant benefit to Synapse 3220 is its control of the interconnect's power dissipation. In a classic bus-based architecture, during any given transaction, all of the wires in the bus are driven, not just those from a given initiator to a given target. This wastes a significant amount of power. Synapse 3220 addresses the problem by activating only the required segment of the interconnect for a given transaction, while the rest is kept deactivated.

Moreover, individual IP cores can be switched off entirely or activated individually in software. A wake-on-access mechanism can be added for customized power control.

The interconnect brings an interesting approach to security. In traditional bus structures, security is often embodied in a separate IP core and is implemented in software with a hardware assist. It can be difficult to implement effectively. Synapse 3220 includes a built-in firewall-like function that can block transactions on a transfer-by-transfer basis, if desired.

The verification side of SMART interconnect technology and the SOCCreator environment is a significant advantage in terms of time-to-market, says TI's Goren. "It starts with the fundamental building block of the OCP. Sonics provides the layer on top of it. The whole concept of using a socket approach that enables you to isolate and decouple verification so that you perform it on the units rather than on the system is very attractive. Then your overhead in doing verification for the system is significantly smaller."

The key to SMART interconnect technology, from a verification perspective, is the decoupling of the communication between IP cores from their computational functionality. "The interconnect that we build turns the puzzle inside out," says Lautzenheiser, "because we adapt the interconnect to fit the needs of the IP cores in the system and not vice versa. In a traditional approach, you modify the IP cores so they can speak to all the other IP cores that they want to talk to in the system. Therefore, you lose the verification because now you've blurred that boundary."

"A big piece of the story on verification is that you can verify the blocks independently," says Wingard. "Further, you have to be able to guarantee that when you put them together, the environment in which you verified them is preserved. That's what the socket-based design element is all about."

Sonics Inc.,
2440 W. El Camino Real,
Suite 600, Mountain View, CA 94040;
(650) 938-2500;
www.sonicsinc.com.