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.