This is part 3 in our series of blogs on revealing the secret sauce that makes up the art of verification! In part 1 and 2 of this series, we covered the MIPI Unipro Verification Testplan and MIPI M-PHY Verification Testplan.
Today, we continue on this journey and present to you the MIPI CSI-3 Verification testplan. If it is a ready made solution you are looking for, then check out our MIPI CSI-3 Verification IP Solution. Given that MIPI D-PHY has been updated with new features that improve the offered bandwidth, we might see MIPI CSI2 get an extra burst of life. But we at Arrow devices continue to be excited about the MIPI CSI3 possibilities and are committed to help early adopters of the MIPI CSI-3.
This verification testplan has been prepared for the MIPI CSI3 Specification version 1.0 . MIPI CSI-3 is an end application, which uses UniPort-M as its underlying serial data communication channel. UniPort-M is made up of MIPI UniPro, a reliable transport stack, and M-PHY as a physical layer.
Before jumping in to the tesplan, you might want to check out the MIPI CSI-3 verification- Top 3 challenges as well. Impatient much? You can skip right to the end and Get Your MIPI CSI-3 Testplan HERE >>
MIPI CSI3, CAL can work as a HOST or DEVICE. The following sections describe the verification focus areas and verification strategy for both HOST as well as DEVICE configurations.
The following functionalities form the main verification areas in MIPI CSI3:
- Configuration Protocol for Camera (CPC)/ Legacy Cameral Control Interface (CCI) for Attribute access
- Configuration Protocol for Camera (CPC) for Notifications
- Camera and Host Data Plane (HDP/CDP) – Image and Video transfers
- Interaction with MIPI UniPro protocol stack
The following sections will describe focus areas and key verification questions for each of the main verification areas described above.
1. Configuration Protocol for Camera (CPC)/ Legacy Cameral Control Interface (CCI) for Attribute access
Configuration protocol for camera (CPC) is meant for camera device discovery and configuration. There is a standard address map defined by the MIPI CSI 3 specification. While CPC is protocol specified, with the CSI 3 supporting access to camera device attributes from 4 bytes to 4096 bytes granularity, CSI 3 will continue to support the legacy (CSI2) approach to access CCI attributes as well. CPort ID 2 has been dedicated for it. Directed tests for accessing all regions of the address map and randomizing the CPC parameters sent for every image transfer initialization should cover this area.
Verification areas you should focus on:
- Ability to access all the regions of the address map
- CPC Protocol
Key questions you should ask:
- Are you accessing all key regions of the entire Address map?
- Are you checking that the order of the CPC RESPONSEs matches the order of the CPC GETs especially when multiple of them are sent at a time?
- Are you covering different combinations of Transfer End Mark (TEM) and Transfer Start Mark (TSM) fields?
- Are you checking that a single CPC PDU is not spanning more than one Attribute packet (CSI3 Header)?
- Are you checking that double word aligned CPC PDUs are mapped into little endian byte aligned Attribute packets?
- Is DUT able to skip the reserve data type CPC PDU in-between among Attribute packet containing multiple CPC PDUs?
- Are you accessing non-existent or non-gettable attributes and checking that the Camera device returns zeroes?
- Are you asserting that there are no EOPs seen on the Configuration CPort?
2. Configuration Protocol for Camera (CPC) for Notifications
Notifications are primarily used for sending error conditions, status information and embedded data associated with an image frame. Embedded data is used to transmit arbitrary payloads, such as information about certain aspects of the image traffic. Embedded data may be interleaved with pixel payload data on the same CPort or transmitted separately on a different CPort.
Constrained random verification is best suited to cover the embedded data cases while directed tests can be utilized for special status or error event notifications.
Verification areas you should focus on:
- Non-interleaved notifications
- Interleaved notifications
Key questions you should ask:
- Are you covering Non interleaved notifications on both CPC and CCI interface (if supported)?
- Are you asserting that the non-interleaved NOTIFY PDU is transported with one Attribute packet directly followed by EOP in the absence of TxBuffer overflow?
- Are you asserting that the non-interleaved NOTIFY PDU is transported with multiple Attribute packets followed by a single EOP in case of TxBuffer overflow?
- Are you verifying non-embedded data NOTIFY PDU’s reception on both CPort 2 and Notification channel CPort (if supported)?
- Are you covering all three types of interleaved data transmission?
- Are you asserting that all the embedded data of a particular frame number is received, before the frame number changes?
3. Camera and Host Data Plane (HDP/CDP) – Image and Video transfers
Data plane handles the payload and configuration data transfer. It converts the image payload and attributes into byte stream and vice versa. It also recovers from the transport layer congestions through its Tx Buffer overflow mechanism. Multiple pixel streams can be concurrently transmitted from the camera device to the host. Every pixel stream is transmitted on its own dedicated virtual channel attached to a specific CPort. Considering the 32 data formats, various sizes and Tx Buffer overflow possibilities, constrained random verification is best suited to cover this area.
Verification areas you should focus on:
- All data formats and sizes
- FFHEADER and Tx Buffer overflow handling
- Concurrency across the VCs
Key questions you should ask:
- Are you covering all image data types (total of: 32) specified in specification
- UNCOMPRESSED: 17
- COMPRESSED: 12
- JPEG: 3
- Are you verifying dynamic VC characteristics changes?
- Are you checking Tx buffer overflow does not occur during EOP and header transmission?
- Are you covering multiple Tx buffer over flow for single image frame?
- Are you covering all 8 Tx buffer overflow scenarios with different FFHeader and CSI3_TX_RESUME_INTERVALn values for both image and embedded data?
- Are you verifying scenarios of a single frame counter being shared across multiple virtual channels (if supported)?
- Are you covering the error case wherein an image frame or embedded data is started without having terminated the previous one with EOP?
4. Interaction with UniPro protocol stack
UniPort-M provides a high speed, bidirectional and serial communication channel. MIPI CSI3 would use asymmetric configurations. Interaction is required for transferring the CSI3 packets and UniPort-M control & status. Data transfer interaction would be covered by constrained random verification of CSI3 data plane. UniPort-M control & status interaction can be covered with a set of directed tests. It's assumed that UniPort-M itself would come in pre-verified.
Verification areas you should focus on:
- CPort interface handling and arbitration
- UniPro configuration and Control
Key questions you should ask:
- Are you asserting that the CAL for Camera configuration and CCI bridging CPort respect End-to-end flow control?
- Asserting CAL sending EOM Packet to local UniPro CPort interface in the case of overflow?
- Are you covering the Local and Peer UniPort attribute access to all layers with DME_GET/DME_SET and DME_PEER_GET/DME_PEER_SET?
- Are you covering all types of resets, especially Link reset, Endpoint reset and Soft reset (if supported) ?
- Are you modeling the UniPort Link initialization sequence and power mode changes sequence completely and correctly?
The Camera Command Set (CCS,[MIPI07]) must be standardized in order to reduce risks and accelerate the MIPI CSI 3 adoption.
Get Your MIPI CSI-3 Testplan HERE >>
Stay tuned for the further updates to the checklist as we continue to build it further! We will also incorporate CSI 3 version 1.2 updates soon!
Author: Chandra Bhushan Singh