About 10 to 15 years ago, integrating interface IP into a system-on-a-chip (SoC) was pretty straightforward. The SoCs were far less complex, development cycles could be years long, and software development was barely even a consideration. The interface protocols that these SoCs relied on to communicate off-chip, such as USB, PCIe and Ethernet, were slower, simpler, and required fewer options to consider, so every company had in-house experts on the relevant protocol specification. These in-house experts were often involved in the protocol development process with the standard bodies as well. When SoC designers purchased IP to support interface protocols, all the designers needed from the IP suppliers was the IP block and some documentation.
Currently, SoCs are far more complex, time-to-market pressure is intense and SoC project costs are exploding. Protocols that run at higher speed, are used in everything from small consumer devices to server application, and must be backwards—compatible with multiple previous generations. SoC designers are creating more complex architectures to accommodate increasing complexity, speed, bandwidth and memory requirements. Software developers and SoC designers now struggle to understand the individual requirements of multiple IP blocks that are being integrated, and to create the optimized configuration that will enable their applications to run most efficiently. Once an afterthought, software development must now begin as early in the SoC development process as possible.
With the ever-increasing SoC design challenges, it is no longer enough for third-party IP suppliers to provide just IP blocks and some documentation. SoC designers, hardware engineers and software developers need more from their IP suppliers to help them meet schedules and SoC requirements. Hardware engineers need “known good” IP configurations that can be easily modified to explore design tradeoffs. Software developers need proven targets that allow them to start software development, bring-up, debug, and test earlier in the product development process. SoC designers require a complete IP interface ready for their SoC, including analysis and verification, or an interface IP subsystem that can be quickly integrated into the SoC. Meeting these needs requires IP suppliers to offer a full range of IP prototyping kits, software development kits (SDKs), and complete IP subsystems to reduce IP integration time and effort.
The most effective IP prototyping kits provide complete reference designs from which the SoC designer can implement the required custom logic. They allow the designer to copy provided RTL source code and start customizing the RTL for their own application. For smaller SoC design organizations, the availability of RTL source code enables designers to benefit from the IP supplier’s knowledge and kick-start the design. For larger scale organizations with very complex projects and tight deadlines, IP prototyping kits are not enough. These organizations need to reduce time to market and reduce their internal costs, so complete interface IP subsystems provided by the IP supplier is a more effective solution. Interface IP subsystems allow designers to take advantage of the IP supplier’s knowledge of, and insights into, the protocols and standards, combine that knowledge with their own knowledge of the SoC and implementation issues to develop a differentiated solution.
Acquiring IP from a third-party IP supplier comes with the expectation that the IP will just work. However, getting the IP to work in a prototype in the context of the actual SoC can be a steep climb with multiple aspects:
- Getting the prototype to work for exploring performance
- Validating the IP in the context of the system
- Delivering the prototype to the software team for early software development
In an ideal scenario, the IP supplier would remove any roadblocks for each of these three aspects. The designer could then immediately begin performance exploration and validate the IP in the system context from the moment the IP is available. Software developers could start learning the IP and writing the device driver before the SoC is complete.
Early in the process, when implementing the IP RTL code in an FPGA, SoC designers typically encounter problems related to differences in architecture of the clocks, memories, routing resources and handling of the high-speed interfaces. Since the SoC designer is not familiar with the IP RTL, understanding each of these issues and resolving them in the FPGA implementation can be quite complex and time-consuming. Debugging custom boards, PHY boards or the tool flow takes even more time and effort. Resolving all these issues can take months of research, working with the IP supplier or reverse-engineering the IP.
To achieve the ideal scenario, IP suppliers need to offer IP prototyping kits with preconfigured IP, prototyping hardware, FPGA-ready reference designs with integration logic, and a reference software stack. The whole system should be pretested, fully proven and simple to set up. With these ready-made kits, designers can reduce months of labor to minutes. In addition to these kits, IP suppliers need to provide a flow and tools to modify the design so designers can converge on the right configuration for their application. With such a solution, changes that used to take days could now be done in about an hour.
IP prototyping kits that can be used as software development kits are important to accelerate the development cycle. These kits enable developers to begin exploration immediately, to port the example driver and application, or to learn the protocol sequences and how to handle different backwards compatibility scenarios. By providing driver and application examples, IP suppliers can help software developers avoid the problems that often arise when software developers misunderstand the initialization and programing sequence.
Reconfiguring IP has traditionally been a lengthy process. Currently, IP suppliers who provide reconfiguration tools and flows enable hardware engineers to determine their optimal configuration quickly, and allow software development to proceed. With the proper tools and scripts for all the sequences in the required flow, reconfiguration for the prototyping kit can be completed in about an hour.
The tool flow provided by the IP supplier must include extensive debugging features with pre-instantiated examples. These debugging tools need to support complex software sequences. Supporting several seconds of debug waveforms enables designers to find the correct trigger, point and zoom in on an issue.
Once the configurations have been confirmed and software development starts, the SoC designer can focus on integration of the IP into the design. The SoC designer must be able to integrate the IP confidently while dealing with multiple configurations, clock domains, power domains, and still meet timing and performance requirements. Typically, integrating IP requires knowledge of multiple interfaces and options from the SoC to the controller IP, and then to the PHY IP. Using IP subsystems, all the SoC designer needs to do is provide the IP supplier with performance requirements and SoC specifics. The IP supplier can then modify the subsystem to meet the SoC requirements. The IP supplier also should include not only the configuration of the IP subsystem but also design functionality such as clock structures, reset requirements, low-power functionality and the SoC’s design-for-test (DFT) requirements.
Because IP suppliers work with multiple customers, they 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 different 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 to a 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 that 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 PHY/controller specification 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 same functionality or neither of them providing it. Using controller and PHY, or an IP subsystem, from the same experienced IP supplier can help designers avoid these issues because the supplier will have studied the specifications and supported multiple customers through these kinds of issues.
IP Subsystem Verification
Connecting and configuring the IP to create a subsystem is important. However, it is equally important to test and verify this new subsystem, not only in the context of the IP but also in the context of the SoC. There are several phases of this testing that the IP supplier must consider to meet the requirements of the SoC. For example, for many customers the initial phase upon receiving the IP subsystem is to first verify the functions as specified. Next is the integration of the IP subsystem into the SoC and verifying interconnectivity and even executing performance tests. Therefore, an extensive verification plan that clearly outlines and defines all tests with coverage including interconnectivity, interoperability, end-to-end data integrity test, and protocol checks is needed. In this way, the designer can easily understand and know which tests they need to port to the SoC level. In addition, if the subsystem includes IP from two different suppliers, the subsystem supplier should include additional tests that can identify known interoperability issues. By performing integrated testing, the IP supplier will help designers reduce integration and verification time from several weeks to a few days.
The other important aspect of SoC design is the analysis, not only of the design’s performance, but also of its implementation. This analysis should be done by scrutinizing the clock domain crossing (CDC), linting the RTL code, synthesizing the design, and completing timing checks to make sure the design will function in the required technology node. Of course, the IP supplier should be knowledgeable of the protocol, the IP and the configuration that will enable the design to meet the performance requirements, but the IP supplier also needs to execute all the implementation tasks to complete the IP subsystem deliverables.
In the most efficient SoC design processes, semiconductor companies design their own differentiated IP blocks, acquire high-quality third-party IP, configure it in an SoC-optimized way, 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 full range of IP prototyping kits, software development kits (SDKs), and complete IP subsystems, the IP supplier can play a significant role in enabling the SoC design team to focus on the development of differentiated blocks and help them reduce IP integration time and effort to meet time-to-market goals.