IP Subsystems: The Next Frontier for IP Integration

Designers are increasingly incorporating third-party standards-based IP in their designs, but are facing several challenges. With the increasing number of IP included in the design and with each of the IP becoming more and more complex, the effort to integrate all of the IP is taking much longer. Companies are spending as much on their overall integration effort as they are on their IP purchases. Of course, all this complexity must be dealt with while dealing with the pressures brought on by project schedules which are getting shorter and shorter.

What are the challenges facing the designer in using third-party IP? In this article we are going to take a look at the following challenges while using third-party IP in your SoC:

Many designers incorporating IP are not experts in the protocol they are integrating. In the early days of IP, the protocol expert at a given company would know the intimate details of the protocol, making the configuration and integration of the IP into the SoC fairly straightforward. Now, many of the people integrating the PHY and controller together are not experts in the protocol, and in many cases are not part of the SoC team integrating this “IP subsystem” into the SoC.

But how hard could this be? Isn’t the promise of IP that it is building blocks that just snap together and anyone can do it? Unfortunately, no! With today’s complex IP, especially around protocols like DDR, USB and PCIe, the IP usually contains several parameters which allow the IP to be configured to support a given usage of the IP within the context of the SoC. This is where the knowledge of the protocol comes in handy.

For example, the designer must review and set well over a 1,000 parameters in a controller. When configuring the controller, the designer must understand details such as the traffic profile; the impact setting buffer sizes has on the overall throughput of the SoC; the way the controller interfaces to the rest of the SoC, etc. Incorrectly setting these parameters can result in poor performance for the SoC or even an interface that won’t function properly and fails compliance testing.

Now what about connecting the controller to the PHY? In many cases, the interface between the controller and the PHY uses a defined industry standard, for example, UTMI for USB 2.0 or PIPE for PCIe and USB 3.0. This usually makes it fairly straightforward to connect a PHY and controller for a standard configuration. However, if you want to use the same PHY in a configuration that supports multiple protocols, logic has to be designed that connects the PHYs to multiple controllers and selects between them at the appropriate time.

Now the PHY and controller are configured and connected you can move on to the next step; correct? Remember this interface has to work as part of the SoC, so the next step is to add the subsystem to the SoC. You will need to determine the clocking requirements for the controller and the PHY and how they interface to one another and to the clock of the overall SoC. It’s likely that the PHY will provide the clock to the controller, but integrating it to the SoC may require multiple clock domains. For example, the PHY and controller may run on one clock domain that may be different than the SoC, which also may be different than the application interface of the controller, which is connected to an on-chip bus.

Similarly, the PHY and controller subsystem has to fit into the SoC’s overall interrupt architecture, the DMA architecture, and power management strategy for the whole chip. Each of these entities has significant requirements on the IP interface. For example, each protocol has different power down sequences to enter their low power states. These requirements must be taken into account when adding additional layers of power management across the interface. If the SoC requires power gating on top of the built-in low power features of the protocol, the power gating requirement has to be coordinated across the PHY and the controller. The complexity only increases when you have multiple interfaces on the SoC.

Most controllers and PHYs must be initialized and provide some type of debug and testability logic. If the PHY and controllers are from different providers, then part of the integration process is figuring out how to efficiently combine (or develop) the logic to initialize and the logic to support testability/debug logic into a coherent interface for the SoC. The AMBA APB protocol is often used as the interface for the logic that connects the testability/debug interfaces of the controller and PHY while providing the additional benefit of placing the interface into the memory map of the SoC.

Once all the RTL is complete, the designer still has to do verification and synthesis of the design. The designer can rely on the individual test-benches for each of the components to check their configuration. However, most of the test-benches that ship with the IP are for that IP and don’t cover interoperability of the components and the connection into the SoC. The designer will likely have to develop a new test-bench that will test the connection between the PHY and the controller, the additional logic added for interrupts, DMA, power management and test and debug. If this test-bench is designed correctly, all of the tests written at this level can be reused in the testing of the SoC.

Next is implementation. The designer has to take each of the individual constraint files, modify them, and combine them together where appropriate. The PHY usually has a digital layer that sits on top of the SerDes, so the constraints for the PHY need to be combined with the controller’s constraints and then all of this needs to be synthesized together. In addition to synthesis, the designer will have to run Lint tools with their rules across this subsystem, check for clock domain crossing, and check for adherence to other corporate design rules.

Subsystems

The IP business is undergoing a transition in how customers expect IP to be delivered. Designers are demanding more cost-effective ways to use third-party IP to add interfaces to their IP while leveraging the IP provider’s expertise to reduce risk for their SoC. It is clear that IP providers have the expertise in the protocol to help with customer in the configuration of the IP and the connection to the SoC. The key is to be able to provide a controller and PHY subsystem that is customized to the requirements for every unique SoC in a cost-effective way.

Synopsys, as part of the IP Accelerated Initiative, has developed IP subsystems that consist of pre-validated, fully integrated interface IP subsystems that are then customized to the customer’s specific requirements. By developing the interface IP subsystem ahead of time, the bulk of the design is complete, which enables the subsystem to be delivered very quickly while spreading the cost over several engagements. Using these pre-designed subsystems and Synopsys’ protocol expertise, Synopsys works with the SoC designer to gather the requirements of the SoC, determine design feasibility and verifying performance metrics. Then Synopsys configures the IP and customizes the pre-designed blocks in the subsystem for the clock and reset, DMA, Interrupts, test and debug. Synopsys’ DesignWare Interface IP Subsystems allow the designer to focus their efforts on differentiating their products while reducing risk and improving their time to market.

Summary

The key to Synopsys providing a cost-effective IP subsystem that is specific to an SoC is leveraging a series of pre-designed subsystem architectures, blocks, and test-benches. To ensure timely and efficient customization, Synopsys assembles and modifies IP blocks, adds custom blocks or features to meet the designer’s specification, and then verifies the subsystem in the context of the SoC. Delivering customized Interface IP Subsystems provide extra functionality and value over simply integrating a PHY and controller. With this approach, Synopsys can quickly provide a customized Interface IP Subsystem for each design that reduces cost and time while integrating the required features.