Interface IP Subsystems Speed TTM

It’s true that some designers prefer to buy controllers and PHYs separately, but many are asking IP vendors to provide pre-verified interface IP subsystems to reduce effort and time to market.


Interface protocol specifications start out simply, handling off-chip communication for SoCs. As more companies get involved in the specifications, each company adds features to address their market segments. Each new version of the protocol specification offers new features and increased speed, and the protocols are often overhauled to work at higher speeds and improve performance for applications ranging from small consumer devices to server applications. Along the way there are inevitable issues, so the standards include ECOs for certain use cases–all the while maintaining backwards compatibility.

When the protocols were simple, every company had in-house experts, but soon companies realized these resources could be better used to differentiate their chips and that purchasing interface IP from third-party IP vendors was more efficient. IP vendors create feature-rich products that meet all aspects of the specifications and also offer a wide range of configuration options. Configuration options are very helpful but require effort to learn and understand the tradeoffs of area vs. speed vs. power.
While some designers prefer to buy controllers and PHYs separately, many are asking their IP vendors to provide pre-verified interface IP subsystems to reduce their effort and time to market. Basically, designers want to buy the complete interface.

Defining an interface IP subsystem
An interface IP subsystem consists of a controller that interfaces between the on-chip communication infrastructure (typically a multi-stage interconnect using standard bus protocol at its ports) and the PHY block that connects with the external world through predefined protocols and electrical specifications (Figure 1). The blocks have to adhere to a public standard, such as the USB-IF specification or PCI Express standard.

Using high-quality third-party IP that has been used in many designs and is silicon-proven is effective in reducing cost and design risk for a semiconductor company. In theory, as everything is based on standards, integration should be easy. However, challenges can impede simple integration, including lack of knowledge of the standard or protocol, meeting performance requirements, and integration of the IP into the overall SoC.

Complete interface IP subsystems help designers because SoCs are becoming far more complex and time-to-market pressure is intense. SoC designers are creating more intricate architectures to accommodate ever increasing complexity, speed, bandwidth and memory requirements. SoC designers now struggle to understand the individual requirements of multiple IP blocks and to create an optimized configuration that will enable their applications to run most efficiently.

Figure 1: A complete interface IP subsystem includes the PHY, controller, and supplemental logic for clock, reset, DAM and interrupts, power management, debug and test, and verification IP

Figure 1: A complete interface IP subsystem includes the PHY, controller, and supplemental logic for clock, reset, DAM and interrupts, power management, debug and test, and verification IP

Interface IP integration challenges
Even when the IP blocks are proven, integrating the IP subsystem into the SoC architecture can be a challenge. Global signals to control power domains, clocks, and reset have to be applied correctly to the IP subsystem and coordinated with the rest of the SoC. After the initial subsystem is created, simulation and prototypes must be built and executed accurately and efficiently.

Understanding the timing requirements for the clocks and resets for the PHY is important because the PHY will otherwise not produce the desired functional behavior and performance. It can literally be “eye-opening” when the correct timing requirements are achieved. In the classic work split, the SoC team would typically work on the IP subsystem and then try to understand how each of the pins of IP is supposed to work and what the timing and test requirements are, for which detailed information from the IP supplier is needed. This analysis takes a lot of time, even though it’s just for the purpose of integrating the IP. Using complete interface IP subsystems can help mitigate these challenges.

IP suppliers as subsystem suppliers
Because IP suppliers work with multiple customers, IP suppliers are better suited than individual SoC designers for the task of building and configuring IP subsystems. In addition, each new project benefits from the IP supplier’s experience from previous projects, taking the IP reuse paradigm to the subsystem level. IP suppliers should offer services ranging from the integration of the controller and PHY, through integration of multiple protocols with common PHYs, all the way to complete subsystems that also include the software stack.

Integrating IP from multiple IP suppliers can be more complex. For example, when connecting IP using a controller and PHY from different suppliers, often the interface between them is not designed exactly to the standard. Even when it is, there is no way of performing interoperability testing between the controller and PHY, there is no simple way to confirm the connection is correct, nor is there a way to make sure all the signals have the correct functionality. Even if both IP suppliers test the interfaces thoroughly, if they have interpreted the specifications differently, the interfaces will behave differently. Also, sometimes the specification does not indicate where in the controller or in the PHY that certain functionality should be performed. This could lead to both IP suppliers providing the functionality–or neither. Using an IP subsystem from an experienced IP supplier can help designers avoid these issues because the IP supplier will have studied the specifications and supported customers through these kinds of issues. The IP teams have seen all of these issues when supporting customers with integration of IP and have put specific tests and configuration options in the interface IP subsystems to handle the limitations of integrating IPs from different IP vendors.

In the most efficient SoC design processes, semiconductor companies design their own differentiated logic and features, acquire high-quality third-party IP for standard interfaces, configure and optimize the IP for the SoC, and integrate all blocks into the SoC infrastructure of clocks, voltage supplies, on-chip buffer memories or registers, and test circuits. The SoC design team defines and drives the SoC-specific implementation details and hence imposes certain requirements on how the IP can be integrated. By providing a fully customized, analyzed and tested IP subsystem, IP suppliers like Synopsys can play a significant role in enabling the SoC design team to focus on the development of differentiated blocks and help them reduce standard IP interface integration time, cost and effort to meet their business goals (Figure 2). DesignWare Interface IP Subsystems fulfill the promise of delivering interface IP and SoC knowledge in one package and easing the pressure on the SoC designer.

Figure 2: Savings with DesignWare Interface IP Subsystems

Figure 2: Savings with DesignWare Interface IP Subsystems