HOME    COMMUNITY    BLOGS & FORUMS    VIP Central
VIP Central
 

Verifying MIPI interfaces in SoCs

Posted by VIP Experts on June 23rd, 2015

It is estimated that every smartphone now uses some aspect of the MIPI standards. Last year, one billion phones, and about 6 to 7 billion 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.

MIPI-System

MIPI interfaces make it easier to design complex smartphone SoCs. However, 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.

Since 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:

  • 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

Synopsys-MIPI-compliance-test-suite

General Schematic of MIPI Compliance Test Suite

You can learn more about 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 in this article.

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.

You can learn more about our comprehensive support for MIPI titles at VC Verification IP for MIPI.

Authored by Nitin Agarwal

Posted in Methodology, MIPI, UFS | No Comments »

Hands-on Memory Verification IP Workshops

Posted by VIP Experts on June 16th, 2015

Synopsys Memory Verification IP is modeled natively in SystemVerilog and supports the common verification standard UVM. Our models support 100% of the memory standard as specified by JEDEC.

Now you can take a deep dive into our VIP solutions at no cost with a hands-on workshop. The workshop will highlight and demonstrate how you can achieve rapid verification convergence on your JEDEC DDR based designs. Through a combination of lecture and lab, we’ll show you how to achieve success in verifying complex SoC designs that include advanced memory protocols such as DDR4/3, LPDDR4/3, UFS, eMMC, HBM, HMC and more.

You and your colleagues can register now for a workshop near you:

Schedule:  9:00 a.m. – 2:30 p.m.

Agenda

  • Synopsys Verification IP for DDR Memory Protocols
  • Testbench Configuration made easy with Memory VIP
  • Lab 1: Memory VIP Configurations
  • Lab 2: Memory VIP Checkers and Monitors
  • Lunch (provided by Synopsys)
  • Lab 3: Memory VIP Debug with Verdi
  • Lab 4: Memory VIP Coverage with Verdi

More Information
Please contact us by email at vipworkshops@synopsys.com to request a hands-on workshop in your area. Attendance at this event is free, and registration is required. Seating is limited and not all registrations will be accepted. All events are subject to cancellation. For more details, see Memory VIP Workshops.

Posted in DDR, eMMC, HBM, HMC, LPDDR, Memory, Methodology, ONFi, UFS | No Comments »

DAC 2015, San Francisco: Must-See Verification Sessions

Posted by VIP Experts on June 9th, 2015

It’s going to be an exciting week for  designers and verification engineers at the Design Automation Conference in San Francisco this week. Here’s a list of activities we recommend:

Tuesday June 9th 


Wednesday June 10th

Posted in Methodology, SystemVerilog, UVM | No Comments »

Performance Advantages of Synopsys VIP

Posted by VIP Experts on June 4th, 2015

In this video, you will learn how several users are benefiting from the performance advantage of using Synopsys VIP  http://bit.ly/1Kau83g

You can learn more about our VIPs at Verification IP Overview

Posted in Debug, SystemVerilog, Test Suites, UVM | No Comments »

Benefits of MIPI Soundwire

Posted by VIP Experts on June 2nd, 2015

In MIPI Soundwire: Digital Audio Simplified, we mentioned that digital audio formats, including Pulse Code Modulation (PCM) and Pulse Density Modulation (PDM), are target applications for MIPI Soundwire. Later, we discussed Digital Audio Streams and Channels. Here, we will talk about the merits MIPI Soundwire protocol has over other available digital audio interfaces.

For more information on MIPI Soundwire, you can download our whitepaper

Major PC audio and mobile companies have been concerned about the limitations of audio interfaces such as PDM, I2S, I2C, SLIMBus and HDAudio for some time. In 2012, the MIPI Alliance LML working group started working on standardization of the Soundwire Interface. In February 2015, the MIPI board adopted version 1.0 of Soundwire Specification. It has the following benefits over other interface technologies:

1. Soundwire supports double data-rate scheme, which reduces power consumption by 40%.

2. Clock-stop mode is provided to save power during idle periods.

3. Frame rate is adjustable to optimize bandwidth and reduce overhead.

4. It has embedded control and command which eliminates the need of other interfaces such as I2C or SPI.

5. The synchronization process uses dynamic sync pattern, which makes synchronization more robust against false synchronization.

6. The transfer protocol is unified for PCM, PDM and general non-audio data.

7. Commands and data are interleaved which reduces latency and it is good for PDM data.

8. It provides bulk transfer protocol for quick startup of devices with DSP capabilities.

9. It implementation is efficient: a simple slave can be as small as 4k gates.

In the next blog, we will discuss a typical use case of Soundwire interface, and how you can leverage Synopsys VIP for MIPI Soundwire to create a test scenario to quickly validate your Soundwire DUT.

For more information on MIPI Soundwire, you can download our whitepaper.

Posted in Methodology, MIPI, Soundwire | No Comments »

Configuring Memory VIPs

Posted by VIP Experts on May 28th, 2015

Here, Synopsys Applications Consultant, Vaish Ramachandran, describes how best we can use Synopsys’ VIP Configuration Creator for configuring memory VIPs http://bit.ly/1JcvSII

You can find more information on Synopsys Memory VIP at http://bit.ly/1Rl2liD

Posted in DDR, Debug, eMMC, HBM, LPDDR, Methodology, ONFi | No Comments »

Memory VIP Challenges

Posted by VIP Experts on May 26th, 2015

Behavioral Memory Models have been used for verification purposes for several years now. In the early days, modeling technology didn’t add much value to the usage model as designs were simple.

With increasing design complexity, and demand for more functionality driving SoC complexity and cost, memory verification models need to morph into a state that can ensure that memory requirements meet the demand of the design. A realistic way to achieve this is to develop these models in the most commonly used design and verification language, SystemVerilog.

You can find more information on Synopsys Memory VIP at http://bit.ly/1Rl2liD

Synopsys Memory Verification IP is modeled natively in SystemVerilog and supports the common verification standard UVM. Furthermore, these models follow 100% of the Memory standard as specified by Joint Electron Device Engineering Council (JEDEC) Solid State Technology Association, a semiconductor trade and engineering standardization organization.

Memory_VIP

Many challenges are faced when designers use a memory VIP, whether it is developed in-house or acquired from a third party vendor. These challenges vary from whether the use model is to design a Memory Controller, a DFI, a PHY or using the memory as a dummy memory device to validate other blocks on the SoC. Memories can be discrete such as DDR3 or DDR4, or In-Line such as DIMMs. The challenges encountered vary from usability, to functionality, to configurability. Working closely with users in the field, here is a list that we have created:

  1. Ease of integration
  2. Part selection
  3. Initialization control
  4. Coverage
  5. Protocol and timing checks
  6. Backdoor access
  7. Scoreboard hooks
  8. Debug support
  9. Protocol-centric debug
  10. Synchronized transaction and waveform view

Each challenge will be addressed in a subsequent blog post. So do come back :)

Authored by Nasib Naser

You can find more information on Synopsys Memory VIP at http://bit.ly/1Rl2liD

Posted in DDR, eMMC, HBM, LPDDR, Memory, ONFi | No Comments »

HDCP 2.2: Locality Check, SKE and Authentication with Repeaters

Posted by VIP Experts on May 21st, 2015

In The HDCP 2.2 Authentication Process – an Introduction, we discussed why we need HDCP, and the basic steps of the HDCP Authentication Process. We noted that an advanced version of RSA is the underlying cryptography standard used during the Authentication and Key Exchange (AKE). AKE is the first step in the authentication protocol. Here we will continue exploring the next 3 steps of the protocol: Locality Check, Session Key Exchange (SKE) and Authentication with repeater. You can learn more about the HDCP 2.2 Authentication Process by downloading our whitepaper, Demystifying the HDCP 2.2 Authentication Process.

Locality Check

This is an interesting checking mechanism introduced in HDCP2.X to ensure that the receiver and the transmitter are placed nearby. It prohibits sharing of HDCP2.2 protected content over a long distance.

The flow for locality check is shown in the figure below. The transmitter sends a random number (rn) to the receiver and expects the HMAC-SHA256 value L’ computed over rn and derived key Kd to be back within 20ms. In the case of failure of locality check, either due to timer expiration or mismatch between L and L’, it may result in Authentication failure. The protocol permits the transmitter to retry the locality check (up to 1024 attempts) by sending the LC_INIT message with a new rn value.

HDCP-Locality

Flow for Locality Check

Session and Key Exchange (SKE)

Successful completion of AKE and locality check affirms to the HDCP transmitter that the HDCP receiver is authorized to receive the HDCP protected audio visual content. So after the locality check, the transmitter can generate a random 128 bit session key (Ks) and encrypt it using the Master key exchanged during the AKE and send it to the receiver.

During SKE, the HDCP transmitter:

  1. Generates a secret pseudo random session key Ks and a 64-bit pseudo-random number Riv
  2. Encrypts this with the key derived from AES-128 encryption and sends the encrypted message SKE_SEND_EKS.

Then this session key Ks and Riv will be used in the encryption of the audio video content by the transmitter. The receiver will be able to decrypt the content using this key (remember the Symmetric key encryption technique).

Authentication with Repeaters

This is an optional step only needed when the receiver is a repeater device. This step is used to propagate the topology information to the transmitter. The repeater accumulates a list of the entire downstream receiver IDs as well as the number of levels in the topology tree. The transmitter also checks whether any of the receivers is in its revocation list.

Once authentication is successful, the transmitter can start encrypting the audio visual content using AES-128 bit encryption algorithms which is a very secure and fast encryption technique capable of providing high bandwidth. The key for the AES core is the session key (Ks) xor with the secret constant lc128. This secret constant is provided by DCP LLC.

You can learn more about the HDCP 2.2 Authentication Process by downloading our whitepaper, Demystifying the HDCP 2.2 Authentication Process.

Posted in HDCP, HDMI, Methodology | No Comments »

MIPI Soundwire: Digital Audio Streams and Channels

Posted by VIP Experts on May 19th, 2015

In MIPI Soundwire: Digital Audio Simplified, we mentioned that digital audio formats including Pulse Code Modulation (PCM) and Pulse Density Modulation (PDM) are target applications for MIPI Soundwire. Here we will discuss Digital Audio Streams and Channels.

For more information on MIPI Soundwire, you can download our whitepaper.

The figure below illustrates how Digital Audio is transferred between Codecs and System memory via Digital Audio Streams. A Codec (short for encoder-decoder) converts analog signals to digital streams, or vice versa. Digital Audio Stream is a logical or virtual connection, which may have one or many channels. For example: Stream-3 has two channels (Stereo) which are decoded by both Codec-A and Codec-C, while Stream-2 has a single channel (mono) – the input side of  the modem.

Soundwire-DigitalAudioStreams

Digital Audio Streams

The figure below shows a conceptual audio frame, and how a digital audio stream and its channels are transferred on the link. Each input or output signal in the link transmits a series of frames. A new frame starts every 20.83us (48KHz). A typical frame consists of command (control information) and payload (audio data). The audio data could be single stream or multiple streams together. Since the frame occurs at a fixed rate, streams can occupy more or less than one sample block every frame. In Figure 7, stream S-2 occupies two sample blocks. This implies that the sample rate for S-2 is 96 KHz. Moreover, S-2 has 4 channels of 20 bits each. So the stream sample block uses 80bits. The audio bit rate would be (80 bits) * (96KHz) = 7.68Mbps.

Soundwire-ConceptualAudioFrameComposition

Conceptual Audio Frame Composition

The total number of streams supported would depend on frame size and streams. Any unused space is filled with Filler/Null data.

For more information on MIPI Soundwire, you can download our whitepaper.

Posted in Methodology, MIPI, Soundwire | No Comments »

HDCP 2.2: Authentication and Key Exchange (AKE)

Posted by VIP Experts on May 14th, 2015

In The HDCP 2.2 Authentication Process – an Introduction, we discussed why we need HDCP, and the basic steps of the HDCP Authentication Process. We noted that an advanced version of RSA is the underlying cryptography standard used during the Authentication and key exchange. In HDCP 2.2 Authentication: RSA Cryptography, we discussed the basics of RSA Cryptography. In this blog post, we will dive into the details of Authentication and Key Exchange (AKE), which is the first step in the authentication protocol. You can learn more about the HDCP 2.2 Authentication Process by downloading our whitepaper, Demystifying the HDCP 2.2 Authentication Process.

The HDCP transmitter can start at any time even before a previous authentication is complete. HDCP Receiver’s public key Certificate is verified by the HDCP transmitter then the devices share a master key Km. This stored master Key Km accelerates the subsequent communication between HDCP transmitter and Receiver. Authentication also happens even if the transmitter doesn’t have a stored master Key corresponding to the HDCP receiver. These keys information are sent in form of messages. If we are using HDMI then these messages would go over the I2C based control bus in big endian format.

1024 bit wide Receiver’s public key is stored in the certificate which has the following content:

HDCP-Certificate

Below figure shows the flow for Authentication and key exchange:

HDCP-AKE-flow-without-stored-KmAuthentication and Key Exchange Flow (without stored Km)

Transmitter sends its own information to receiver which in turns sends its own certificate containing public key within 100ms time frame. Transmitter verifies the signature. As explained in the figure below, the failure of the signature verification will result in the Authentication abort:

HDCP-signature-verif-AKESignature Verification during AKE

After successful signature verification, if the transmitter doesn’t have the stored master key Km from the previous session, the transmitter generates a random 128 bit master key, encrypts it using the RSAES-OAESP encryption with receiver’s public key, and sends it to the receiver.

In addition to signature verification, the transmitter also checks that the receiver ID of the receiver is not present in the revocation list. It is a procedure to make sure that a receiver which has been compromised and identified will be tracked during authentication. If the receiver ID is found in the revocation list, AKE is aborted.

Upon receiving the encrypted Km, receiver decrypt it using the receiver private key (HDCP2.2 recommend using Chinese Remainder theorem to reduce effort as this is the most compute intensive step in the entire authentication flow). There is also a time limit bound of 1s for the entire decryption and the subsequent hash value calculation.

After the receiver successfully decrypts the km, it sends back the H_Prime, a HMAC-SHA-256 (see below section for details), hash value of the master key Km to the transmitter. This is to provide an acknowledgement to the transmitter that the receiver has indeed successfully decrypt the master Key Km.

Upon receiving the Hash value (H_prime) from the receiver, the transmitter checks against its own computed value. Upon successful comparison of the H_Prime, Authentication and key exchange is complete otherwise AKE is aborted.

HMAC SHA-256

In order to provide more authenticity for messages, HDCP2.2 uses Hash based Message Authenticity code(HMAC). The HMAC-SHA256 is a message authentication method which uses the underlying hash functions as SHA-256. The input to the HMAC-SHA256 is a key (which can be message). The output is the message access code which can be send back to originator of the message which can check the HMAC code against its own code and verify the message has been correctly received by the receiver.

Pairing

Before explaining the next step in the Authentication Flow, it is important to explain a process called Pairing. In the above AKE flow, it is explained how transmitter generates a master key Km if it doesn’t have the stored key Km. Now transmitter can store the received Km value for the next session and reuse it instead of generating a new Km, hence speeding up the entire flow of AKE. In the AKE flow after the receiver send H_Prime information to transmitter, it will send the AES encrypted master Key to the transmitter. Transmitter stores the Encrypted master key and master key itself. For subsequent session, The AKE flow with stored Km is illustrated in the figure below:

HDCP-AKE-with-stored-KmAuthentication and Key Exchange (With Stored Km)

 You can learn more about the HDCP 2.2 Authentication Process by downloading our whitepaper, Demystifying the HDCP 2.2 Authentication  Process.

Posted in HDCP, HDMI, Methodology | Comments Off