The purpose of this article is to present the verification process of HDL Design House MIPI® CSI2 TX IP core using Questa® VIPs by Mentor, A Siemens Business.
ABOUT THE CSI2 PROTOCOL
Camera Serial Interface 2 (CSI2) defines communication protocol between a peripheral device (camera) and a host processor. It is intended for point-to-point image and video transmission between transmitter (camera) and receiver (host processor). It is mostly used in mobile and automotive industry. High performance and low power are the key features.
CSI2 TRANSMITTER IP
HDL Design House's CSI2 Transmitter IP (HIP3900), a silicon proven IP, was successfully integrated into million gate LSI that was implemented in Fujitsu's 65nm process technology. It supports high speed video transmission protocol used in automotive applications – The Automotive Pixel Link (APIX®).
The key features of HIP3900 are:
- High level of robustness and ability to detect and handle incomplete lines (lines that contain fewer number of pixels than configured horizontal resolution)
- Incomplete frames (frames that contain fewer number of lines than configured vertical resolution)
- Ability to handle non-continuous input data stream (where pixels belong to one line do not arrive back- to-back)
The HIP3900 is a fully synthesizable design with ~60K gates without the internal FIFOs. There are four Pixel interfaces, dedicated for attaching up to four Cameras. Only one camera stream can be processed at a time. Since a physical layer is supposed to be connected to PPI interface, the HIP3900 uses D-PHY and supports up to 4 data lanes for data transmission in high speed mode. The HIP3900 is software configurable using ~35 registers, 32bit wide each, that are split into configuration, status, and power group registers. The registers are accessed through AHB-Lite slave port using 8/16/32bit access. Software can use interrupt output pin for indication if any error has been detected during transmission. The HIP3900 architecture is shown in the picture below.
Based on the current registers configuration, input data stream (coming from the one active camera) is stored in the Camera Buffer. The data stored in the Camera Buffer is later reformatted and packed into CSI2 packets. Based on the current transmission mode (High or Low speed), CSI2 packets are forwarded to HS/ESC signals at the PPI interface.
The HIP3900 verification was based on constrained-random verification approach which represents an effective method to achieve the coverage goals quickly and with low number of tests. Another very important advantage of the constrained-random verification compared to the directed testing is that it helps in exercising corner-case scenarios that would otherwise most probably be missed, consequently finding the corner-case defects. The verification environment is a self-test by using run time (also known as "online") checkers, ensuring correctness of the DUT functionality and simplifying error analysis and debug at the same time. The functional coverage provided with the verification environment represents a metric that measures functional testing completeness.
The testbench verification environment is developed using SystemVerilog language and it aligned with UVM-1.2 methodology. CSI2 and AHB-Lite QVIPs, developed by Mentor, A Siemens Business, are used in the testbench environment as such. All other testbench components were developed from scratch.
Mentor's QuestaSim 10.5a was used in simulations for the tests run and debug.
The HIP3900 verification process, as most IP level verification processes, starts with verification planning and testplan creation. Testplan is a document which contains requirements or features that need to be verified in design, verification metrics that will be collected from the testbench environment and the linking of requirements or features to the metrics (tests, cover points, crosses, assertions). The HIP3900 testplan is written in XML format using the OpenOfficeTM tool. The Questa OpenOffice Add-On feature proved to be convenient and helpful, since its usage sped up the testplan development. The provided ability to read collected coverage database stored in the Unified Coverage Database format (ucdb) and extract the list of all verification metrics made linking very simple and quick. Since both QVIPs (CSI2 and AHB) are delivered together with the testplans, CSI2 and AHB testplans are simply ported into the HIP3900 testplan, additionally speeding up the testplan development. At the end, HIP3900 testplan contained only features and requirements that are IP specific while AHB and CSI2 are assumed to be covered by the respective testplans.
The testbench verification environment is composed of the following components:
- Camera VIP
- AHB-Lite QVIP
- CSI2 QVIP
- Register Abstract Layer (RAL) – composed of register block, predictor and adapter
The Camera VIP is a component that is used to generate and drive a variety of input data stream (in terms of data formats and resolutions) onto the DUT Pixel Interface. It also provides a possibility for error injection (less number of pixels in a line than configured horizontal resolution or fewer lines in a frame than configured vertical resolution). Apart from generating and driving the data stream, the Camera VIP provides functionality for monitoring, checking and providing appropriate events. Events that are detecting any event at the interface such as frame start, frame end, line start and line end were very useful for synchronization with IP and prediction. For collecting data stream in terms of camera lines and frames, the monitor also provides an analysis port that can be used to send these events and collected camera transactions to the attached subscriber for further processing. The monitor is also where the coverage collection takes place. There are four instances of the Camera VIP that are attached to four physical DUT pixel interfaces.
AHB-Lite Questa® VIP
The AHB-Lite Questa VIP is used as an active master agent. It is used to verify the DUT AHB interface implementation. Its built-in sequences are used to generate different kinds of AHB traffic. QVIP monitor provides protocol checks and coverage collection. Apart from protocol checks and coverage collection, the monitor also collects the AHB bus transactions, and sends them through an analysis port to the attached subscriber.
CSI2 Questa® VIP
The CSI2 Questa VIP is used as an active master ppi processor agent. The main purpose of this component (its monitor) in the verification environment is to:
- Collect the CSI2 traffic at the PPI interface and send it to the scoreboard for further processing.
- QVIP monitor provides assertions that ensure correct DUT behavior at the PPI interface. CSI2 Questa VIP is fully responsible to check if the DUT is protocol compliant.
- Coverage collection. CSI2 Questa VIP coverage is used as measurement of what portion of CSI2 protocol feature has been excesses.
The Scoreboard class represents a DUT reference model. It is used to predict output data stream based on the current DUT configuration and input data stream. It also provides assertions that compare the collected output data stream with the predicted one and, in that way, verifies proper DUT functionality.
Since the HIP3900 IP is a software configurable device and contains registers, there is a need to emulate registers in verification environment and verify their functionality. The Register Assistant UVM was used for generating SV/UVM register package. As an input, the Register Assistant UVM uses a simple spreadsheet (CSV) document where the registers are described. Prior to generation of an output (SV/UVM register package in terms of SV source code), the Register Assistant UVM provides and runs certain built-in checks (e.g. address overlapping) that verify a sort of sanity correctness of the input file. The UVM register generator allows a register to be accessed through the bus cycle (frontdoor) but also allows registers to be accessed directly from verification environment via hierarchical path (backdoor) providing a way for fast register access (in zero simulation time).
The Register adapter is a component that is used to convert a register accessing transaction into the corresponding AHB bus transaction.
The Register predictor is a component that is used to convert the collected AHB bus transaction into the corresponding register transaction. In case of a write register transaction, the predictor updates the register within register block based on its fields attributes, while in case of a read register transaction the predictor compares value driven by the DUT with the one predicted by the register block.
The testbench verification environment architecture is presented in the picture below.
The picture above also shows the data flow. Each test (except for the register tests), starts with DUT configuration which is done using a register sequence. The Register adapter is responsible for converting the registers accesses into an AHB sequence and for sending that sequence to the AHB QVIP sequencer. The AHB QVIP sequencer forwards the AHB sequence items to its driver and the driver translates the AHB sequence items into traffic driven over the DUT AHB interface. Once the AHB QVIP monitor collects the AHB transaction from the bus, it sends that transaction to the register predictor which, based on the collected data, updates the testbench register model or compares the collected data with the expected ones.
Once the configuration phase is done, the tests start a Camera sequence to generate various frames. The Camera sequencer takes the frames from the Camera sequence and passes them to its driver which translates frames into traffic driven at the DUT pixel interface. The Camera monitor is responsible for collecting lines and frames from the pixel interface. It sends the collected lines and frames to the attached subscriber (in this case, the scoreboard) via its analysis port for further processing. The monitor also informs the scoreboard when any other event (frame start, frame end, line start, line end) is detected at the interface.
The CSI2 QVIP monitor is responsible for monitoring signals at the DUT PPI interface. Each time when the monitor collects a CSI2 packet (a short or a long one), it sends it to the attached subscriber (scoreboard) for further processing. The monitor also provides protocol checks which are used to ensure that the DUT does not violate the PPI protocol.
The scoreboard class contains two analysis exports. One of them provides functionality for predicting CSI2 packets based on the collected Camera line, frame or events (frame start, frame end, line start, line end) and the current DUT configuration. The predicted CSI2 packets are stored in a scoreboard queue. The second export provides functionality for comparing the collected CSI2 packets with the predicted ones.
The Interrupt Service Routine (ISR) sequence is monitoring the DUT interrupt line at all times. Once the line is driven (active) high, the ISR sequence performs certain actions (checks whether the interrupt occurrence was expected or not, reads status registers, clears the interrupt, etc.).
In order to exercise erroneous scenarios and the HIP3900 features where the errors (in terms of invalid lines or frames) were expected, some of the CSI2 QVIPs errors need to be refined for the test scenarios with error injection.
The register related tests do not involve a data stream so the data flow is a bit different. The purpose of these tests is to ensure that the DUT registers can be read and written using any AHB size (byte, half word, word). The AHB VIP built-in sequences are used to implement the register related test scenarios.
Throughout tests and regression run, the verification progress is measured using Questa® Verification Management Tracker. The HIP3900 testplan, written in xml format, with imported CSI2 and AHB-Lite testplans and metrics linked to their requirements, is converted and reformatted into ucdb format (reformatting done by QuestaSim). The collected coverage from one or more tests (regression) is merged with ucdb testplan (merging done by QuestaSim). The merged coverage can be opened in QuestaSim and analyzed in Verification Management Tracker. Apart from showing holes in the coverage, this also provides information on missing connections (request -> metrics) and tests ranking. A very useful feature of the Verification Management Tracker is the possibility of generating html reports, which represents a convenient and effective way to share the progress facts.
Mentor QVIPs are well documented. They are delivered with user guides written in pdf format and with html documents that describe QVIPs classes, the class members (fields, functions, tasks) and other components that are used. Besides documentation, the QVIPs delivery also contains testplans which can easily be ported into other testplans and speedup time needed for developing testplan related to protocol specific feature and focus planning to non-protocol features of the DUT. Another useful part of the QVIPs delivery are the demonstration examples which show how the QVIPs can be used. The existence of the examples simplifies QVIPs usage and instantiation to a great extent.
The use of AHB and CSI2 Mentor QVIPs is a more efficient solution compared to the option of building the two from scratch. Not only did the use of CSI2 and AHB-Lite QVIPs reduce testbench development time but it also minimized the risk of misunderstanding AHB and CSI2 protocol specifications, thus preventing defect occurrence in verification. Mentor VIPs proved to be error free, as they have been already used by many customers and in different applications.
Since QVIPs were tested with the silicon proven HIP3900 as well as on other projects with different applications we can treat them as golden models and with high level of confidence and reliability.
Back to Top