Verifying MIPI interfaces in SoCs
Verifying MIPI interfaces including CSI-2, CPHY, DPHY, MPY, Unipro and the UFS host controller on complex SoCs – should you make or buy the necessary VIP?
The standard interfaces promoted by the MIPI Alliance for use in smartphone SoCs have been very successful. It is estimated that every smartphone now uses some aspect of the MIPI standards, and that last year, 1bn phones and about 6 to 7bn phone ICs included a MIPI interface of some sort. MIPI interfaces, especially for cameras and displays, have spread beyond the mobile world into other markets, such as automotive, industrial, medical, the IoT and the digital home/office.
Figure 1 MIPI interfaces are helping to standardize the interconnect architecture of smartphones (Source: MIPI Alliance)
MIPI interfaces make it easier to design complex smartphone SoCs, but verifying that they are working correctly provides little differentiating value for the end product. The challenge for design and verification teams, therefore, is to implement robust verification environments for MIPI-based designs as efficiently as possible. Developing in-house verification IP (VIP) and test-benches can be costly and time-consuming, especially if they are to exercise the complex traffic patterns, corner cases, errors and exceptions of the more advanced MIPI interfaces. This strategy also puts the verification team at risk of false or missed failures, from poorly implemented or maintained VIP, and may limit VIP reusability from the block to the SoC level.
It may be better to acquire MIPI VIP and testbenches from a commercial provider that can offer a common look, feel, and use model for all VIP and test-benches and so reduce the time it takes the verification team to learn their use. Users of such VIP should also benefit from the fact the VIP has been tried out in multiple contexts and so will model the MIPI protocols, corner cases and error states comprehensively. Commercial VIP is also likely to have been optimized for performance on multiple simulators, and may be delivered with various debug aids.
Because the MIPI interface standards are hierarchical, with the more complex interfaces using aspects of the simpler interfaces, MIPI VIP and verification testbenches tend to have a number of common features, such as:
- a requirement to both drive the device under test (DUT) and capture its output
- the ability to drive the VIP or the DUT from the application side, in cases in which the VIP is acting as a transmitter to the DUT
- reusable data-integrity scoreboarding, so that data-streams can be compared before and after the interface under test
- access to the programming registers of the DUT through a configurable interface
- configurability and customization capabilities
- reusability of the entire verification environment
Figure 2 General schematic of MIPI compliance test suite (Source: Synopsys)
In the following examples we’ll see how these common elements recur throughout a suite of MIPI VIP and test-benches, and the way in which more complex MIPI protocols build on lower-level blocks.
A verification environment for the MIPI CSI-2 camera interface
Figure 3 A verification environment for the CSI-2 interface (Source: Synopsys)
This testbench is used to verify a CSI-2 host controller, in this case driven by a CPHY or DPHY physical layer interface. The DUT is driven by camera VIP, which acts as a standard camera data source. The PHY DUT is driven over a serial interface from the camera VIP, while the CSI-2 receiver DUT registers are accessed over, in this case, an APB master VIP block.
The VIP includes a complete test suite that can drive all the traffic necessary to exercise the different versions of the CSI-2 specification, as well as PHY-layer tests. This ensures the DUT is fully verified with respect to each part of the specification. The VIP environment also has a data integrity scoreboard to ensure that the traffic coming out of the DUT is the same as the traffic going in to it.
Having a complete test-suite with a reusable testbench environment for verifying both the protocol layer and the PHY should reduce the time for verification and coverage closure.
Verifying a multi-camera CSI-2 environment
Figure 4 Verifying a multi-camera CSI-2 subsystem (Source: Synopsys)
The verification of a multi-camera CSI-2 subsystem builds on the block-level environment developed in the previous example. A customizable I2C or similar register bus is used here for CCI programming, and a customizable APB or other register bus is used to program the registers of the host. The testbench is flexible enough to verify any combination of CPHY- or DPHY-based CSI-2 cameras or host controllers.
Verifying the MIPI DSI display interface
Figure 5 The verification environment for a MIPI display interface (Source: Synopsys)
The DSI protocol is similar to CSI-2, and therefore its verification environment shares some characteristics as well. MIPI has architected the DSI host controller so that the VIP that drives it from the application side does so over a DBI or DPI interface. This means the VIP needs DBI or DPI transmitter IP, as well as a test suite to drive the DSI host controller from the application side. As in previous blocks, the interface to the DUT programming registers is configurable.
The DSI device VIP has two scoreboards, one each on the DPI and APB buses. The DPI scoreboard compares the image data traffic across the DPI interface that is input to the DUT with the data flowing over the DSI interface at the output of the DUT.
The APB scoreboard compares the expected traffic that the DSI host controller should have generated with the actual traffic transmitted by the DSI host controller.
The VIP and testbench can be used at the subsystem or SoC level. It can also be used to verify a DSI display DUT.
Verifying a MIPI DPHY or CPHY interface
This diagram shows a verification strategy for a MIPI DPHY or CPHY in a camera (CSI-2) or display (DSI) environment.
Figure 6 The verification of a MIPI CPHY or DPHY builds on other MIPI interface verification environments (Source: Synopsys)
The verification environment for CPHYs and DPHYs reuses elements of the DSI and CSI-2 verification environments, and of their data integrity scoreboarding strategies. The testbench has been developed to offer complete verification at block level of these PHYs, whose specification continues to evolve rapidly. Tests cover all transmission modes, multi-lane environments, error conditions, protocol checking and functional coverage.
Verifying a MIPI MPHY environment
Figure 7 It’s particularly important to verify an MPHY implementation because of its widespread use (Source: Synopsys)
The MIPI MPHY is widely used in smartphone and other SoCs, on its own and as part of higher level protocols such as mobile PCI and SuperSpeed USB. The MPHY is already available in four versions, and is frequently updated by MIPI.
To verify it completely, users need to test many types of traffic, including those generated by higher level interfaces, and check all control and data flows for any number of TX and RX lanes. It is also important to verify complex features such as lane-to-lane skew, dithering, clock jitter, as well as protocol and timing checks at the RMMI and serial interfaces.
The VIP and test-bench must also be designed so that it doesn’t need any changes when the user moves to newer versions of the specification.
Verifying the MIPI Unipro interface
Figure 8 The MIPI Unipro interface is the most complex to verify (Source: Synopsys)
The MIPI Unipro interface is the most complex to verify, thanks to the multiple layers in the protocol. To verify this interface, the VIP and testbench needs to act on both sides of the DUT. From the application side, the VIP connects to the DUT through the CPORT interface. On the PHY side, it connects to the RMMI interface. The testbench also needs scoreboards, as before, on the TX and RX paths, as well as a configurable way to program the DUT’s registers.
Verifying the Unipro interface takes an exhaustive set of tests that focus on complex scenarios such as link startup and reset, which should be delivered as a reusable test suite with verification plans and a coverage model.
Verifying a JEDEC UFS host controller or device with HCI layer
Figure 9 The verification environment for UFS needs a programming layer that can drive the UFS controller and the DUT (Source: Synopsys)
The JEDEC UFS standard builds on the MIPI Unipro and MPHY blocks. Figure 9 shows a UFS host controller, which can be verified using the testbench shown to any level of the UFS stack, for example: the UFS DUT only at the CPORT interface; UFS and Unipro at the RMMI interface; and UFS, Unipro and MPHY at the serial interface.
The verification environment needs a programming layer that can drive the UFS controller and the DUT, from the application side. It also needs to support the use of customizable application-side buses. And, as before, there need to be scoreboards for traffic from the host controller and from the DUT onto the UFS controller.
Make versus buy
As we have seen, there are a lot of common factors in these approaches to verifying MIPI interfaces. IP blocks need to be exercised with a robust set of protocol checks, corner cases, error injection and functional-coverage models to ensure that they comply with the protocols. The VIP and related testbenches need to be kept up-to-date with rapidly evolving specifications and bug fixes. And the verification needs to be rigorous, especially for lower-level blocks such as the PHYs, because more complex interfaces such as UFS rely on them.
Synopsys offers a comprehensive portfolio of VIP for MIPI interfaces, and application using MIPI interfaces, which meets these criteria and offers a common user experience. The portfolio supports the latest versions of the MIPI specifications, and offers comprehensive test suites with functional coverage models, with protocol-aware debug to reduce debug turnaround time. Finally, the VIP blocks are written in SystemVerilog for use on a wide range of simulators.
Further information
For a complete list of VIP protocols visit: www.synopsys.com/VIP
Author
Nitin Agrawal is a CAE manager in the verification group in Synopsys India. Agarwal joined Synopsys more than eight years ago and is responsible for leading a large team of engineers deploying verification IP across key customers. Prior to joining Synopsys, he was at Interra Design Systems working in the area of EDA product development and formal verification. Agarwal has extensive experience across the multiple protocols under the MIPI umbrella and has worked extensively in architecting and implementing verification environments for advanced mobile platforms.
