CSI-2 Testbench User Guide 1 02

To The Point Solutions

CSI-2 Testbench

Version 1.02 Northwest Logic

Proprietary

Copyright 2015

Northwest Logic

User Guide

Table Of Contents

Copyright 2015 Northwest Logic, Inc. All rights reserved. This document contains Northwest Logic, Inc. proprietary information. Northwest Logic, Inc. reserves all

rights associated with this document and the information it contains. No part of this document may be reproduced or transmitted in any form by any means for any purpose without

the express written permission of Northwest Logic, Inc. Northwest Logic, Inc. reserves the right to makes changes to this document and associated specifications at

any time without notice. Northwest Logic, Inc. advises its customers to obtain the latest version of this document before relying on any information it contains.

Northwest Logic, Inc. assumes no responsibility or liability arising from the use of any information, product or services described in this document except as expressly agreed in writing with Northwest Logic, Inc.

Copyright 2015 Northwest Logic i Northwest Logic Proprietary

1 REVISION HISTORY .............................................................................................................................................. 1

2 OVERVIEW............................................................................................................................................................. 2

3 TASKS FOR GENERATING CSI-2 PACKETS ....................................................................................................... 4

3.1 SEND_SHORT_PACKET ......................................................................................................................................... 4 3.2 SEND_LONG_PACKET .......................................................................................................................................... 4 3.3 SEND_MULTIPLE_LONG_PACKETS ......................................................................................................................... 4 3.4 SEND_RX_VID_INTFC_FRAME ............................................................................................................................... 5

4 SUPPORT TASKS .................................................................................................................................................. 6

4.1 CLEAR_FRAMEDATA ............................................................................................................................................. 6 4.2 WRITE_FRAMEDATA ............................................................................................................................................. 6 4.3 PREPARE_FRAME ................................................................................................................................................. 6 4.4 ANNOUNCE_DATA_ID .......................................................................................................................................... 6

5 VERIFICATION TASKS .......................................................................................................................................... 7

5.1 TEST_SHORT_PACKETS ........................................................................................................................................ 7 5.2 TEST_LONG_PACKET_LENGTHS ............................................................................................................................ 7 5.3 VIRTUAL CHANNEL TEST ...................................................................................................................................... 7 5.4 RANDOM PACKET TEST ....................................................................................................................................... 8 5.5 ULPS MODE TEST .............................................................................................................................................. 8 5.6 MAXIMUM PACKET LENGTH TEST ......................................................................................................................... 8 5.7 ECC TEST ......................................................................................................................................................... 8 5.8 CRC TEST ......................................................................................................................................................... 9 5.9 UNSUPPORTED DATA TYPE TEST .......................................................................................................................... 9 5.10 RECEIVE VIDEO INTERFACE TEST ...................................................................................................................... 9 5.11 ULPS WITH HIGH SPEED PACKET TEST ............................................................................................................. 9

6 FUNCTIONAL COVERAGE ................................................................................................................................. 10

7 CSI2_PIXEL_FIFO .............................................................................................................................................. 10

8 LICENSING ........................................................................................................................................................... 11

9 FOR MORE INFORMATION ................................................................................................................................ 11

CSI-2 Testbench User Guide

Copyright 2015 Northwest Logic 1 Northwest Logic Proprietary

1 Revision History

This section tracks revisions made to this document by version number

Revision Date Changes

1.00 07/09/10 Initial Release.

1.01 10/24/13 Brought up to date with current test bench. Added section on functional coverage.

1.02 10/08/2014 Updated test description to include what functionality is verified and reported as failed if not actual does not match expected.



2 Overview

The CSI-2 Testbench provides a CSI-2 bus functional model for basic simulation of CSI-2 logic designs utilizing the Northwest Logic CSI-2 Controller Core. The CSI-2 Testbench contains a CSI-2 Transmit Bus Functional Model (csi2_tx_top), a CSI-2 Receive Bus Functional Model (csi2_rx_top), test scripts (csi2_tx_data_generator), a pixel FIFO (csi2_pixel_fifo), and logging functionality as illustrated in Figure 2-1. The CSI-2 Testbench can be used to test User Logic on the Receive, Transmit, or both the Receive and Transmit sides.

TXController DPHY DPHY

RXController

CSI2_Pixel_FIFO

LOG

PrimaryTransfer Tasks

Tasks

Test ControlCommands

csi2_tx_data_generator

User Logic

csi2_tx_top csi2_rx_top

csi2_tb

Figure 2-1 Typical Test Environment The CSI-2 Testbench is intended to for basic design simulation. It support supports the generation and receipt of packets. It is not a full Verification IP package. It does not support bus protocol monitoring, error injection, changing packet timing or perform detailed physical layer testing. It is provided with a basic set of test cases. It does not provide complete MIPI compliance testing. For ASIC customers, Northwest Logic recommends utilizing a third-party VIP to fully verify the design. Contact Northwest Logic for more information on its recommended third-party VIP provider.



The CSI-2 Testbench is available in Verilog 2001. VHDL customers may also use the CSI-2 Testbench by co-simulating with a simulator which supports Verilog and VHDL. Primary Testbench Components

csi_tb o Example top level testbench o The user customizes this file by adding their receive side logic and or replacing the

csi2_tx_data_generator module with their transmit logic. csi2_tx_data_generator

o Provides high level tasks for interfacing to the CSI2 TX BFM (csi2_tx_top) Tasks are simple to use and require very little MIPI CSI2 knowledge Can generate any CSI2 Low Level Protocol Packet Format Enables full control over packet data contents including auto generation of data Support for all data types

csi2_tx_top o Provides a CSI2 Transmit Bus Functional Model o Uses the Northwest Logic CSI2 Transmit Controller

Delivered in one of two formats Verilog source code when the Transmit Controller has been licensed Verilog netlist model otherwise

Easy to use user interface Enables generation of any CSI2 Low Level Protocol Packet Format Designed to easily interface to FIFOs for the pixel data

csi2_rx_top o Provides a CSI2 Receive Bus Functional Model o Uses the Northwest Logic CSI2 Receive Controller

Delivered in one of two formats Verilog source code when the Receive Controller has been licensed Verilog netlist model otherwise

Easy to use user interface Supports all CSI2 Low Level Protocol Packets Interface is designed to seamlessly stream data into FIFOs

csi2_pixel_fifo o Provides functionality to verify packets requested on the TX interface are received correctly at

the receive side. Supports all CSI2 Low Level Protocol Packet Formats Supports all CSI2 data types Logs results and status to the log file

Log o Transmit and Receive activity, status, and error information is logged to standard output o User can easily add information to the log



3 Tasks for Generating CSI-2 Packets

The following tasks are defined in csi2_tx_data_generator for users to generate CSI-2 packets.

3.1 send_short_packet

send_short_packet is xfer is one of two low level tasks that interface directly to the Transmit Bus Functional Model, the other is the send_long_packet task. Send_short_packet can be used to send any short packet type that conforms to the Low Level Protocol specified in the MIPI CSI2 specification.

Port Direction Size Description

vc Input [1:0] Virtual Channel number.

data_type Input [5:0] Data Type. Valid values for short packets are 0x00 0x0f. See the MIPI CSI2 specification for further definition of the valid values.

data_field Input [15:0] Short Packet data field. For frame sync packets, this field contains a frame number and for line sync packets this field is used as a line number. See the MIPI CSI2 specification for further definition.

CSI-2 short packets do not contain any payload data so all the information contained in a short packet is passed in with the call to the send_short_packet task. The send_short_packet task handles all interface handshaking with the Transmit Bus Functional Model.

3.2 send_long_packet

send_long_packet is xfer is one of two low level tasks that interface directly to the Transmit Bus Functional Model, the other is the send_short_packet task. send_long_packet can be used to send any long packet type that conforms to the Low Level Protocol specified in the CSI-2 specification.


vc Input [1:0] Virtual Channel number

data_type Input [5:0] Data Type. Valid values for short packets are 0x10 0x37. See the MIPI CSI2 specification for further definition of the valid values

wc Input [15:0] Length of payload in number of pixels The pixel data for CSI-2 long packets comes from a frame buffer that is maintained by the verification environment. The tasks for setting up the frame buffer are explained in following sections. The send_long_packet task handles all interface handshaking with the Transmit Bus Functional Model.

3.3 send_multiple_long_packets

send_multiple_long_packets is used to a specific number of multiple long packets of a requested data type and virtual channel number. The task sends a total of num_pkts of the type specified in the task. Note that only long data types are supported.


Vc Input [1:0] Virtual Channel number




wc Input [15:0] Length of payload in number of pixels num_pkts Input [15:0] Number of packets to send.

The pixel data for CSI-2 long packets

3.4 send_rx_vid_intfc_frame

The task send_rx_vid_intfc_frame is used to send a series of short and long packets like what is often seen from MIPI CSI2 cameras.


data_id Input [5:0] Data Type. Must use valid pixel data types, like RAW8, RAW10, etc. pix_cnt Input [11:0] Number of pixels in a line of video num_lines Input [4:0] Number of video lines in a frame

enb_fs_fe_delay Input Enable frame start and frame end packets enb_ls_le_pkts Input Enable line start and line end packets.



4 Support Tasks

The following tasks do not directly generate CSI-2 packets and are provided to facilitate use of the main packet generating tasks.

4.1 clear_framedata

The verification environment maintains a simple circular buffer as a frame buffer that is used to supply pixel data to the transmit BFM. A call to clear_framedata resets the pointers in the frame buffer resulting in an empty buffer.

4.2 write_framedata

write_framedata writes a pair of 24 bit pixels into the frame buffer.


writedata Input [47:0] Pair of 24 bit pixels. The frame buffer is sized to support the maximum pixel width of the CSI-2 TX controller pixel data inputs. If the actual pixel width is less than 24 bits the CSI-2 TX controller will disregard any of the unused bits.

4.3 prepare_frame

prepare_frame write initializes the frame buffer with a short sequence of 8 pixels. A short sequence of pixel values can be used for longer packets because the frame buffer operates in a circular buffer fashion, repeating the same 8 pixel values over and over again.

4.4 announce_data_id

announce_data_id performs a Verilog $write() using the data id passed to it to print the data_id in ascii. This task currently supports video data types only.


data_id Input [5:0] CSI-2 Data type. Only video types are supported.



5 Verification Tasks

Verification Tasks are used by Northwest Logic to verify the functionality of the CSI-2 Controller (TX) Core. These tasks may be of interest to users of the Testbench either directly or as examples of how to create higher level tasks using lower level tasks described in the previous sections.

5.1 test_short_packets

test_short_packets tests the transmission and reception of short packets using the Virtual Channel number passed in to the task. It tests all supported short packet data types, 0x00 to 0x0f while using a walking ones pattern in the short packet data field (the WC field).


vc Input [1:0] Virtual Channel number The verification tests run test_short_packets for the four supported Virtual Channel numbers, 0,1,2 and 3. Short packets received by the RX BFM are verified against the expected packet header field values (data type, virtual channel, word count) and errors are reported to the log file. The test also monitors the ecc error flags from the RX Controller, reporting any assertion of the ECC signals and stopping execution of the test at the point of failure. The test also verifies that the number of packets received matches the number transmitted.

5.2 test_long_packet_lengths

test_long_packet_lengths tests the transmission and reception of long packets using the Virtual Channel number passed in to the task along with a data type, start and end lengths. test_long_packet_lengths steps the packet size by the appropriate number of pixels for a given data type.


vc Input [1:0] Virtual Channel number


start_length Input [15:0] Start length for the requested test end_length Input [15:0] End length for the requested test

The verification tests runs a packet length test for all supported data types and lengths started at the smallest allowable packet size for a data type to the largest packet size for the data type. Received packets received by the RX BFM are verified against the expected packet value, payload data is compared to transmitted payload data, with errors reported to the log file. The test also monitors the ECC and CRC error flags from the RX Controller, reporting any assertion of the ECC and CRC signals and stopping execution of the test at the point of failure. The test also verifies that the number of packets received matches the number transmitted.

5.3 Virtual channel test

The virtual channel test calls test_short_packets and test_long_packet_lengths while varying the Virtual Channel number through all allowable values and all supported data types. Packets received by the RX BFM are verified for correct packet header values against the transmitted packet header values with errors are reported to the log file.



The test also monitors the ECC and CRC error flags from the RX Controller, reporting any assertion of the ECC and CRC signals and stopping execution of the test at the point of failure. The test also verifies that the number of packets received matches the number transmitted.

5.4 Random Packet Test

The Random Packet Length Test generates packets with randomized Virtual Channel, Data Type, and Payload length. The randomization of data types are focused to the data types that the CSI-2 TX and RX Controllers are configured to support. Randomized packets are transmitted from the TX controller and TX D-PHY to the Rx controller and RX DPHY. The testbench compares the received packet payload data to what was transmitted, reporting any errors that are detected. The receive side verifies that the correct VC, Data Type, word count, and payload data is received without any ECC or CRC errors. The test also verifies that the number of packets received matches the number of packets transmitted.

5.5 ULPS Mode Test

The ULPS Mode Test tests the ULPS mode entry of the CSI-2 TX controller and TX D-PHY and the detection of ULPS mode by the RX D-PHY and CSI-2 RX Controller. The ULPS Mode Test steps through all possible combinations of ULPS mode for the clock and data lanes, verifying that the RX side detects the expected ULPS state of the clock and data lanes properly, reporting any errors that it discovers, stopping the simulation upon detection of an error.

5.6 Maximum Packet Length Test

The Maximum Packet Length Test transmits a packet with the maximum payload length for each of the configured Data Types. Maximum payload length varies depending on the Data Type because some of the long Data Types specify that the number of pixels sent in a packet be a integer multiple of 1, 2, 4, or 8. The testbench transmits a maximum length packet for each data type, verifying proper reception of the packet and payload data, reporting any errors that it detects. The test also watches the RX Controllers ECC and CRC error status, reporting any ECC and CRC errors and stopping the simulation at the point of the error.

5.7 ECC Test

The ECC test requires that a module be inserted into the PPI interface in between the CSI-2 TX controller and the TX D-PHY that can insert single and double bit errors anywhere within a packet. This module is typically not delivered as part of a standard delivery. The ECC test verifies correct operation of the TX ECC generation and RX ECC error detection and correction. A series of packets are transmitted where single bit errors are introduced into the first 30 bits of the packet header (the two upper bits are not used by the CSI-2 protocol and always set to zero) . The testbench then verifies that the CSI-2 RX Controller properly detects single bit error and reports the correct bit position of the error, and corrects the single bit error. Double bit errors are tested by introducing two bit errors into the first 30 bits of the packet header. The testbench then verifies that the CSI-2 RX controller properly detects the double bit errors. Double bit errors are not correctable nor are the bit positions of the bit errors detectable. For the single bit error tests, the received payload data is compared to the transmitted data with errors reported to the log file and simulation stopping soon after the first error occurrence. The test also verifies that the number of received packets matches the number of transmitted packets.



5.8 CRC Test

The CRC test requires that a module be inserted into the PPI interface between the CSI-2 TX Controller and the TX D-PHY that can insert errors anywhere within a packet. This module is typically not delivered as part of a standard delivery. The CRC test transmits a series of packets, introducing bit errors into the payload portion and crc fields of the packet. On the receive side, the proper detection of the CRC error is verified, with any discrepancies reported to the log file. The test verifies that the received packet header fields are correct. This test does not verify the receive data since the receive data is guaranteed to be in error due.

5.9 Unsupported Data Type Test

The Unsupported Data Type Test verifies proper operation of the user generated packet feature of the Northwest Logic CSI-2 Controllers. The CSI-2 TX controller has a feature that enables users to generate packets with data types that the controller has not been configured to support. This feature is described in the CSI-2 User Guides. The test sends a series of user generated packets to the CSI-2 TX controller and verifies proper reception of the packet at the CSI-2 RX controller packer user interface. Received packet header information is compared to the transmitted packet headers with differences reported as errors, stopping the simulation near the reported error. The test also monitors the received ECC and CRC status, reporting any ECC and CRC errors and stopping the simulation. This test also verifies that the number of received packets matches the number of transmitted packets, reporting any discrepancies.

5.10 Receive Video Interface Test

The Receive Video Interface Test generates a typical TX video sequence via the CSI-2 TX controller. The test verifies that the correct sequence of video signaling is generated by the CSI-2 RX controller along with verifying proper reception of the video data. The test also monitors the received ECC and CRC status, reporting any ECC or CRC errors and stopping the simulation near the point of the error.

5.11 ULPS with High Speed Packet Test

The ULPS with High Speed Packet Test verifies that data lanes not in ULPS mode can be used to transmit data while other data lanes are in ULPS. The test starts with data lane 0 sending High Speed data with data lanes 1,2 and 3 in ULPS mode. The test then uses lanes 0 and 1 for High Speed transmission with data lanes 2 and 3 in ULPS. Finally, the test uses data lanes 0,1, and 2 for transmission and data lane 3 in ULPS. The test verifies that the correct number of packets are received as well as correct packet header and payload data is received, reporting any errors and stopping the simulation. This test also monitors the RX ECC and CRC error status, reporting any ECC or CRC errors and immediately stopping the simulation.



6 Functional Coverage

The Northwest Logic Testbench environment verifies the following CSI-2 functionality over 1,2,3 and 4 data lanes and various MIPI data lane rates (min, max and steps in between).

CSI-2 Function TX RX

All Short Packet Data Types Yes Yes All Long Packet Data Types Yes Yes

Long Packet Data Types, Minimum packet length Yes Yes Long packet Data Types, Maximum packet Length Yes Yes

Long packet Data Types, correct byte payload incremental lengths Yes Yes Single Bit ECC error detection correction NA Yes

Double Bit ECC error detection NA Yes CRC error detection NA Yes Clock Lane ULPS Mode Yes Yes

Data lane ULPS Mode, lanes 1,2,3 and 4 Yes Yes User generated packets (NWL defined feature) Yes Yes

Receive Video Interface NA Yes Correct generation of DPHY timing parameters (tgap, tpre, etc) Yes NA

Proper packing of Video Pixels into bytes Yes NA Correct unpacking of bytes into Pixels NA Yes

Continuous Clock Mode Yes Yes Non-Continuous Clock Mode Yes Yes Correct data lane management Yes Yes

Correct assertion of Receiver error flags (NWL feature) NA Yes Proper detection of unsupported data types at TX interface Yes NA

Proper operation at Minimum data lane rate Yes Yes Proper operations at Maximum data lane rate Yes Yes

Proper operation of packet user interface single pixel mode Yes Yes Proper operation of packet user interface double pixel mode Yes Yes Proper operation of packet user interface quad pixel mode Yes Yes

Proper alignment of pixel values on controller packet interfaces Yes Yes

7 CSI2_Pixel_FIFO

The csi2_pixel_fifo monitors the TX requests at the TX BFM (csi2_tx_top) user interface and constructs the packets it should expect to see at the RX BFM (csi2_rx_top) user interface. The constructed packets are stored in a FIFO and then read out as the RX BFM receives packets. Errors are logged to the log file. The CSI2_Pixel_FIFO is used in the verification simulations of the CSI-2 Controller Core (TX). It can be useful in user simulations to verify that TX Controller, RX Controller, and DPHY modules are functioning properly.



8 Licensing

The CSI-2 Testbench is delivered with Northwest Logics CSI-2 Controller Cores. It is not available on a stand-alone basis.

9 For More Information

For more information including licensing options, pricing and the latest version of this document: Visit our website at www.nwlogic.com

Send an e-mail to [email protected]

Call us at 503-533-5800 x309

Northwest Logic is located at: Address: 1100 NW Compton Drive, Suite 100

Beaverton, Oregon 97006 United States

Phone: 503-533-5800 Fax: 503-533-5900

Documents

CSI-2 Testbench User Guide 1 02