HOME    COMMUNITY    BLOGS & FORUMS    VIP Central
VIP Central
 

Bernie DeLay @ EDACafe on the Value of SystemVerilog, UVM-based VIP

Posted by VIP Experts on June 30th, 2015

Here, Synopsys R&D Director, Bernie DeLay, talks to EDACafe on the value of native SystemVerilog and UVM support in our VIP titles. He describes how our memory and protocol VIP have been built debug-friendly with Protocol Analyzer, and support constraint random verification for full functional coverage with back-annotation to executable verification plans.

EDACafe-Bernie-DeLay

You can learn more about our VIPs at Verification IP Overview.

Posted in AMBA, DDR, Debug, DesignWare, Ethernet, HDMI, LPDDR, Memory, Methodology, PCIe, SystemVerilog, Test Suites, USB, UVM | No Comments »

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 | Comments Off