MIPI UniPro: Comprehensive Verification Testplan: Download Now!

We at Arrow Devices are committed to help developers build happy and robust standard interface IPs. We are starting with MIPI UniPro today.

As part of this initiative we have prepared the following actionable questionnaire and downloadable test plan that lists more than 600 test cases. All it takes is to answer the questionnaire and follow it up with five steps action plan of cross-referencing your verification plan with the test plan provided. The intent is to get to a single number (Verification Score), that will enable Managers, Technical leads, Verification engineers and those paranoid finger crossed designers to evaluate the strength of their verification plan. There by helping reduce the risk of new designs and increase the robustness of existing designs, by ensuring that none of the key items are missed.

Following verification checklist has been prepared for the MIPI UniPro Specification version 1.41. MIPI UniPro stack has 4 layers. Each layer requires its own verification strategy, which involves choosing the right combination of directed test cases and constrained random test cases. The following sections describe the verification strategy and focus areas for each layer.

MIPI Unipro L1.5 Layer

We believe this is the trickiest to verify amongst the four layers. It needs to be carefully verified. It has following focus areas of verification. The first three functional areas are mostly independent, with very little interaction between them. Several unique scenarios are required to cover all the areas. Hence, a good number of directed tests are needed along with the constrained random tests to get the desired coverage.

Verification focus areas:

Link startup sequences
PA Control Protocol (PACP)
Burst and Filler insertion
Error injection and recovery in all 3 areas

Key questions:

How many MIPI Unipro L1.5 link startup sequence variations are you verifying?
How are you verifying the different lane mapping possibilities and capability downgrading is taking place correctly?
How are you making sure lane-to-lane skew up to 2 symbols across lanes is tolerated? Are you introducing the lane-to-lane skew even during the initialization?
Do you know how many cross-bins coverage it takes to cover all the possible changes in the power mode configurations
Are you sure your DUT is capable of dealing with concurrent power mode changes?
How many types of burst marker corruptions are you verifying?
How many PA Control Protocol error injection cases are you verifying?

MIPI Unipro L2 Layer

L2 is the second most complex layer to verify in the MIPI UniPro Protocol stack. Unlike L1.5, L2 verification is not spread out in different independent areas. It has related and complex interacting logic. Constrained random tests will provide significant coverage. Hence fewer directed tests, as compared to L1.5, are required to get the complete coverage.

Verification focus areas:

Frame composition
Frame Sequence Number and credit management
TC1 and TC0 arbitration and Pre-emption
Error detection and retransmission
L1.5 interaction

Key questions:

How many Data link layer initialization scenarios are you verifying?
Are you covering the padding byte scenario with odd number of bytes in payload?
How are you checking if TC0 can continue to make forward progress when TC1 is blocked due to credits or FSN non-availability?
Are you exercising retransmissions with and without grouped acknowledgement?
How are you ensuring that the pre-emption feature verification is complete?
Have you verified L2 timer timeouts during data traffic? Are you asserting the various L2 timer start and stop conditions?
How are you verifying the L2 to L1.5 interactions?
How many L2 error injection cases are you verifying?

MIPI Unipro L3 Layer

No, L3 is not the third most complex layer to verify in UniPro Protocol stack. In MIPI UniPro 1.41 specification, L3 is a very thin layer. It’s mostly a pass through layer. Very few test cases are needed to cover it.

Key questions:

Are you verifying the Device Id corruption scenario?
Are you verifying the case wherein the DUT receives a long header even though it may not transmit long headers?

MIPI Unipro L4 Layer

L4 is the third most complex layer to verify in the UniPro Protocol stack. L4 verification, as is the case in L2, is not spread out in independent areas. It also has related and interacting logic. Constrained random will provide good bit of coverage. The number of directed cases required to get complete coverage will be even lesser than that of L2.

Verification focus areas:

Fragmentation on the Cport interface
Segmentation and re-assembly
CPort level arbitration
End-to-end (E2E) Flow control, CSD and CSV
Error injection scenarios

Key questions:

Are you covering the different sized fragments of messages on the CPort interface?
Are you covering zero sized segments?
How are you checking that the TC1 message entering UniPro stack before TC0 message does reach peer before TC0 message?
How are you checking in Multi CPort implementation the CPort blocked due to E2E credits is not blocking the transmission on other CPorts?
How many L4 error injection cases are you exercising?

DME

MIPI UniPro specification provides three different primitives for the control and status interface of the MIPI UniPro stack. They are:

Requests
Confirmations
Indications

Each layer provides a series of attributes meant for its control and status reporting. Apart from that, each layer has a set of indications defined for various important events taking place within the layer.

Most of the request, confirmation and indication primitives get exercised as part of the specific layer tests.

Key questions:

Are you verifying the power-on reset values of all attributes?
Are you accessing all the attributes of each layer?
Are you checking after hibernates exit, the DUT is retaining the attributes it is expected to retain and if the link is coming back up again?
Are you accessing invalid address spaces?
Are you checking after warm reset, the sticky registers are retaining the expected values?

Think Theoretically and Execute Practically!

Our Mantra for verification is “Think Theoretically and Execute Practically”. Hence apart from these critical questions we are also providing a complete test plan that can be cross-referenced to do a comprehensive check on completeness of your verification plan.

You may very well decide that a particular case might not be of interest to your current design. But its better to review and rule it out rather than ignore it altogether. This will help you get a clear picture of what has been verified and what hasn't. We recommend you follow the following 5 steps action plan.