VIP Central

Keeping Pace with Memory Technology using Advanced Verification

Posted by VIP Experts on December 1st, 2015

My latest webinar, Keeping Pace with Memory Technology using Advanced Verification, begins by taking the audience back in time. To a time when memories had low density, slow performance, and required expensive silicon real estate. Then I fast forward back to the future when memory technologies have evolved to support huge densities, blazing fast speeds while keeping power consumption low, and all this within very small geometry.


I give an overview of various memory technologies, and the market segments they support. To keep pace with this memory technology evolution, design and verification tools, and methodologies to create and productize these technologies, have also evolved.

This memory evolution has created a whole new set of challenges for verification engineers. To be successful, verification must evolve to be thorough, efficient, and effective earlier in the design cycle. Also, it must rely on native support for SystemVerilog utilizing state of the art verification techniques for Testbench creation and customization, and Debug and Coverage closure.


A faster, proven and state-of-the-art front-end Memory verification infrastructure is required to tackle the complexities presented by the latest Memory innovations. Leveraging industry standard Universal Verification Methodology (UVM), enabling advanced protocol level debugging, and accelerated verification closure with built-in coverage and plans, verification engineers can confidently validate memory technology in a short period of time.

In my webinar, I review the evolution of memory technology leading to the latest developments in DDR, LPDDR, eMMC, High Bandwidth Memory (HBM) and Hybrid Memory Cube (HMC). I highlight key concerns in the verification of these protocols, and their contributions to overall System Validation complexity. Finally, I review successful methodologies and techniques that assure project success.

Register here for my webinar at no charge to learn all about it: Keeping Pace with Memory Technology using Advanced Verification. You can find more information on Synopsys Memory VIP here.

Authored by Nasib Naser

Posted in DDR, DFI, Flash, HBM, HMC, LPDDR, Memory | No Comments »

First Ethernet 400G VIP to Enable Next-Gen Networking and Communications SoCs

Posted by VIP Experts on November 24th, 2015

On Monday, Synopsys announced the availability of the industry’s first verification IP (VIP) and source code test suite to support the proposed IEEE P802.3bs/D1.0 Ethernet 400G standard (400GbE). To understand how it will enable next generation networking and communication systems, we take a look at the evolution of the Ethernet.

Evolution of the Ethernet

Ethernet was first commercially introduced in 1980. It was originally used to connect personal computers to other computers and shared resources like printers in an office.  Ethernet continued to grow to cover campuses and data centers, and then to connect these over metropolitan area networks (MAN) and wide area networks (WAN). This evolution of connectivity followed the 10X speed jumps from the 1980s to 2010 (10M, 100M, 1G, 10G, 40G and 100G) until we reached 100GbE. When the industry saw the challenges of making 100GbE affordable, the industry developed 40GbE as an interim, lower-cost step. 40GbE opened the door for non-10X steps in speed, including 25G, 50G and 400G.

Birthing a new generation of Ethernet was quite straightforward in the early years: enterprises wanted faster LANs. Vendors figured out ways to achieve that throughput. IT shops bought the speed boost with their next computers and switches. It is a lot more complicated now with carriers, Web 2.0 giants, cloud providers and enterprises all looking for different speeds and interfaces. Facebook, for instance, said in 2010 that it already had a need for Terabit Ethernet in its data centers. With billions of Ethernet devices in use on networks around the world, it is harder to define a specification that satisfies everyone.

Modern networks are built on a hierarchy of devices, with “deeper” switches or routers networking the edge devices together for full connectivity. This has encouraged the use of successively faster trunks as port speeds have increased. More traffic implies more capacity. But traffic does not impact the WAN or LAN uniformly—and therefore the needs may be vastly different in different types of networks.

Cloud computing encourages the creation of dense, highly connected data centers. Cloud applications often have more components, and are horizontally integrated than traditional applications, which makes traditional multi-tiered LAN switching performance more problematic. In a cloud data center, even 10 GbE server/storage interfaces connected in a four- or five-layer structure might drive switch interface speeds to 400G or more in the deeper layers. When clouds are created by linking multiple data centers over fiber, a super-Ethernet connection is almost inevitable. This is where we need faster Ethernet switches: to connect cloud data centers and support optical metro aggregation and OTN-based cloud core networks.

“The 400GbE development effort, started in the IEEE 802.3 Ethernet Working Group back in March 2013, remains driven by the need to provide higher speed solutions for core networking applications that depend on the aggregation of data.” said John D’Ambrosia, earlier this year in Enterprise Networking Planet. John is the Chairman of the Ethernet Alliance and Chief Ethernet Evangelist in the CTO office at Dell. In November 2013, the IEEE’s 400 Gb/s Ethernet Study Group” approved project objectives for four different link distances of 400GbE. These were approved by IEEE 802.3 Working Group in March 2014.

Last week, Facebook announced it is testing a 100 Gbit/second top-of-rack Ethernet switch for its next-generation data centers. Networking hardware vendors, like Cisco, Arista, and Mellanox, already offer 100 GbE switches. 

Enabling Next-Gen Networking and Communication SoCs

As the need for increased bandwidth to support video-on-demand, social networking and cloud services continues to rise, Synopsys VC VIP for Ethernet 400G enables system-on-chip (SoC) teams to design next-generation networking chips for data centers with ease of use and integration.


Synopsys VC VIP for Ethernet uses a native SystemVerilog Universal Verification Methodology (UVM) architecture, protocol-aware debug and source code test suites. Synopsys VC VIP is capable of switching speed configurations dynamically at run time, and includes an extensive and customizable set of frame generation and error injection capabilities. In addition, source code UNH-IOL test suites are also available for key Ethernet features and clauses, allowing teams to quickly jumpstart their own custom testing and speed up verification time.

Synopsys thus provides a comprehensive Ethernet solution for all speeds, including 25G, 40G, 50G, 100G and the newest 400G standards.

You can learn more about Synopsys VC VIP for Ethernet and  source code UNH-IOL test suites here.

Posted in Data Center, Ethernet, Methodology, SystemVerilog, Test Suites, UVM | No Comments »

Accelerate your MIPI CSI-2 Verification with a Divide and Conquer Approach

Posted by VIP Experts on November 19th, 2015

MIPI Alliance’s CSI-2 (Camera Serial Interface) has achieved widespread adoption in the smartphone industry for its ease-of-use and ability to support a broad range of imaging solutions. MIPI CSI-2 v1.3, which was announced in February 2015, also offers users the opportunity to operate CSI-2 on either of two physical layer specifications: MIPI D-PHY, which CSI-2 has used traditionally, as well as MIPI C-PHY, a new PHY that MIPI first released in September 2014. Products may implement CSI-2 solutions using either or both PHYs in the same design. MIPI CSI-2 v1.3 with C-PHY provides performance gains and increased bandwidth delivery for realizing higher resolution, better color depth, and higher frame rates on image sensors while providing pin compatibility with MIPI D-PHY.

MIPI CSI-2 poses unique verification and debugging challenges: multiple images formats, several different image resolutions, multiple virtual channels, different types of long packets and short packets, error injection scenarios, ultra-low power mode, and support for MIPI C-PHY and D-PHY. Since MIPI CSI-2 is considered a mature technology – it has been around for a decade – it also demands a short time to market cycle. So how should you as a developer meet the challenges of increasing complexity along with shortening schedules?

Your verification schedule can be significantly cut down when you use Synopsys’ built-in MIPI CSI-2 test suites, monitors and coverage models along with our CSI-2 VIP. Test sequences and scoreboard are customizable. Coupled with the protocol analyzer, it further enables you to cut down the debug cycles, which is another big bottleneck in achieving functional closure.


You can learn more about how Synopsys’ MIPI CSI-2 customizable test suite with the coverage model can accelerate your CSI-2 verification by downloading one of our customer case studies here. This article describes a divide-and-conquer approach that enabled them to verify the MIPI PHY and the MIPI MAC separately. They also discuss how the scoreboard and IDI monitor provided good compatibility to work with their design’s custom interface on the application side. Also, the highly configurable architecture of the VIP and test suites will enable them to reuse their entire testbench for future updates of the design as well as updates to MIPI specifications.

Here’s where you can learn more about Synopsys’ VC Verification IP for MIPI CSI-2 and CSI-2 Test Suites, and the customer case study for using a divide-and-conquer approach.

Authored by Anand Shirahatti

Posted in C-PHY, Camera, CSI, D-PHY, MIPI | No Comments »

Synopsys AMBA 5 AHB5 Verification IP: What’s It All About?

Posted by VIP Experts on November 11th, 2015

This week, at ARM Techcon 2015, Synopsys announced the availability of our VC Verification IP for the new ARM AMBA 5 Advanced High-Performance Bus 5 (AHB5) interconnect. The AHB5 protocol is an update to the widely adopted AMBA 3 AHB3 specification. It extends the TrustZone security foundation from the processor to the entire system for embedded designs. AHB5 supports the newly announced ARMv8-M architecture which drives security into the hardware layer to ensure developers have a fast and efficient way of protecting any embedded or Internet of Things (IoT) device.

AHB5 can enable high-performance multi-master systems with support for exclusive transfers and additional memory attributes for seamless cache integration.  It adds multiple logical interfaces for a single slave interface so you can address multiple peripherals over one bus.

The new AHB5 protocol also enables closer alignment with the AMBA 4 AXI protocol, enabling easier integration of AXI and AHB5 systems. AHB5 also adds support for secure/non-secure signaling so peripherals can keep state correctly. AHB5 also adds support for user signals.


The existing AHB system environment, which is part of the AMBA system environment, supports AMBA AHB2 and AHB3-Lite. Now, we have extended support for AHB5 protocol. Users simply have to change a few configuration attributes and required signal connections for that configuration.

In addition, Synopsys offers advanced system-level capabilities for the ARM AMBA 5 CHI and AMBA 4 ACE protocols. The AMBA 5 CHI is an architecture for system scalability in enterprise SoCs, while AMBA 4 ACE is used for full coherency between processors. The expanded capabilities of Synopsys VIP include system level test-suites, a system monitor, protocol-aware debug and performance analysis. With the growth of cache-coherent designs, checkers and performance analysis are required. The system-level capabilities of Synopsys VIP enable SoC teams to further accelerate time to first test and improve overall verification productivity.

Synopsys VIP features SystemVerilog source code test-suites, which include system-level coverage for accelerated verification closure. The VIP now also offers performance measurement metrics for in-depth analysis of throughput, latency and bottlenecks across cache coherent ports. Synopsys VIP also features system monitors, which interact with other VIP to ensure cache coherency across the system, accurate protocol behavior and data integrity.

To learn more, register for our webinar on November 18th: A Holistic Approach to Verification: Synopsys VIP for ARM AMBA Cache Coherent Interconnects on VIP support for ARM Cache Coherent Interconnects.

Posted in AMBA, SystemVerilog, Test Suites | No Comments »

ARM TechCon: Optimize SoC Performance with Synopsys Verification IP and Verdi Unified Debug

Posted by VIP Experts on November 5th, 2015

Companies developing complex ARM-based SoC designs have to constantly keep up with evolving interface standards and proliferating protocols a recurring problem that is resource-intensive and time-consuming. Orchestrating these multiple protocols is critical to extracting maximum SoC performance a key competitive differentiator. Achieving high performance while ensuring correct protocol behavior is best addressed by a combination of transaction-based, protocol-aware verification and debug environments. Synopsys VIP coupled with the Verdi unified debug platform spans verification planning, simulation debug, coverage, HW-SW debug and emulation debug, and helps tackle this challenge end-to-end.


This training session at ARM TechCon 2015 explains how Verdi’s native Protocol Analyzer and Memory Protocol Analyzer help ensure protocol correctness, and how Verdi Performance Analyzer measures individual protocol performance on Synopsys VIP such as AMBA CHI, ACE, AXI. Additionally, the presentation addresses how these advanced capabilities lend themselves to analyzing performance on non-standard SoC interfaces. Capturing dataflow with the Verdi ‘VC apps’ API allows observation of the entire test environment and measures performance at interfaces of interest. Verdi provides a unified environment for designers to analyze this information, uncover actionable insights and drive design decisions to maximize SoC performance.

Please join us at ARM TechCon on Wednesday, November 11.

SpeakerJohn Elliott  |  Sr. Staff Engineer, Synopsys
Location:  Mission City Ballroom M1
Date:  Wednesday, November 11
Time:  2:30pm – 3:20pm

Posted in AMBA, CHI, Debug, Methodology | No Comments »

PCIe Gen4 – VIP/IP Solution with Protocol-Aware Debug and Source Code Test Suites

Posted by VIP Experts on October 27th, 2015

Today’s PCIe verification engineers have to trade-off between verification completeness and demanding time to market, and the new Gen4 specification makes it more challenging.  This video highlights Synopsys’ complete PCIe Gen4 solution that includes implementation IP (Controller/PHY), Verification IP, protocol-aware debug and source code test suites to accelerate verification closure.

Here’s where you can learn more about Synopsys’ VC Verification IP for PCIe and PCIe Test Suites.

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

Synopsys NVMe VIP Architecture: The Host Protocol Layers

Posted by VIP Experts on October 20th, 2015

Our previous post on NVMe was an overview of the NVMe protocol. We will now start looking closer at the VIP-proper, looking initially at the NVMe Host Protocol layers. This will provide an introductory overview of sending commands to the NVMe Controller.

Here’s where you can learn more about Synopsys’ VC Verification IP for NVMe and for PCIe.

 A High-Level View of the VIP

There are several major blocks to the VIP as shown here:


The NVMe VIP Host Methodology Layers

The UVM Methodology Interface – this allows users and their test-cases to control, monitor and request commands of the NVMe Host VIP via the transaction-oriented UVM methodology. Sequencer and Register models provide access to the VIP.

The NVMe VIP Host Protocol Layers

This implements the NVMe Host-side Protocol – everything from creating data structures (e.g. queues, PRPs and SGLs) in Host Memory to pushing requests into queues to ringing doorbells and fielding interrupts and popping completion queues.

The NVMe Controller VIP

This is the NVMe Controller Model – it responds to the register accesses sent to it, including reads/writes of the various configuration and control registers, handling doorbells, reading and writing Host Memory (to access queues and data) and essentially implementing the NVMe Controller side specification.

In this post, we will be concentrating on the NVMe VIP Host Protocol Layers (in the above Figure, this is the area surrounded by the dashed line.)

Layers of the NVMe VIP Host

Although in the above diagram, the Host Protocol Layer is shown as part of a larger VIP system, it can also be considered as a standalone VIP in its own right. We will, in fact, describe the various layers of the VIP in this way, hiding the UVM methodology, PCIe protocol and the NVMe Controller as much as possible.

A quick review of the NVMe protocol will help us explain the use of the various layers; we’ll go over some examples of NVMe configuration, control and commands, emphasizing those layers that are involved. Here are the layers that we’ll be discussing:


There are only three layers we will be dealing directly with, but to start out, we will use a trivial NVMe Test Case to help use explain the function of the various layers. The VIP Host Layer has a simple-to-use Verilog-based command interface – the various NVMe configuration and commands are mapped to Verilog tasks/functions to implement the NVMe Host. Note that although the command interface is easy to use, under the covers this is a full NVMe application and driver layer that handles much of the protocol leg-work where a “BFM” would be out of its league.

Here’s our trivial test-case (we are not showing some of the task arguments or checking error status just as a simplification – our plan here is to describe the VIP functionality in terms of the test-case commands.) On with it…

// We will assume that the PCIe stack is setup and running
bit [63:0] base_addr = 32’h0001_0000;	// Ctlr NVMe BAR base addr
// Tell the host where the controller has its base address
AllocateControllerID(base_addr, ctlr_id, status);
// Create the Admin Completion and Submission Queues
ScriptCreateAdminCplQ(ctlr_id, num_q_entries, status);
ScriptCreateAdminSubQ(ctlr_id, num_q_entries, status);
// Send an Identify Controller Command
data_buf_t #(dword_t) identify_buffer;		// identify data
identify_buffer = new(1024);
ScriptIdentify(ctlr_id, 0, identify_buffer, status);

Ok, enough for now. A few comments on the above test-case – these are the actual tasks to call to accomplish the various configuration and commands (minus a few arguments as mentioned above). The various tasks that start with the word Script are actual NVMe commands. If they don’t start with Script, they are a VIP configuration utility (e.g. AllocateControllerID() ).

All these commands are implemented at the above NVMe Command Layer (denoted in Red in the figures) – this is the Verilog Interface Command Layer.

We start with the AllocateControllerID(base_addr, ctlr_id, status) task call. This generates a request to the NVMe Queueing Layer to build us a data structure that keeps track of our attached controller(s). The returned ctlr_id is used as a “handle” for any communication to that controller. You will note that later NVMe commands (prefixed by Script…) use the ctlr_id to determine the destination of the command. One can call AllocateControllerID() each time for as many controllers as one wants to access, an unique handle will be returned for each.

Once we have gotten the handle to communicate with the Controller, we then can use it – we call ScriptCreateAdminCplQ(ctlr_id, num_q_entries, status) to do several things for us (see diagram below):

  • In the NVMe Queuing Layer, we allocate some memory from the pool of NVMe memory and create a data structure in Host Memory: a Completion Queue of the requested depth.
  • The register transactions for the appropriate (ACQS and ACQB) registers are built. (Note that Admin Queues are built by writing to the Controller’s NVMe register space).
  • The registers are written. This is done by creating appropriate PCIe MemWr TLP transactions in the NVMe Protocol Interface Layer which are then sent to the PCIe Transaction Layer to cause a write to the appropriate register(s) on the controller.


The Admin Submission Queues are created analogously with ScriptCreateAdminSubQ(). Note that the host-side memory management is done for you, as well as managing the associated queue head and tail pointers. In addition the VIP is checking the memory accesses to those queues to make sure they follow the spec (e.g. a submission queue should not be written to by the controller.)

Once the Admin Queues have been built, we can now use them to communicate admin NVMe commands to the controller. In this case, we will call the NVMe Identify Controller command, used to gather detailed information about the controller. The ScriptIdentify() task (see figure below) is used for both Identify Controller and (if the first argument is non-zero) and for Identify Namespace. Since the Identify commands return a 4KB (1024 dword) buffer of identify information, we allocate that prior to calling the task.

Since the Identify command requires a memory buffer to exist in host memory (to hold the contents of the Identify data), that is allocated in host memory and passed as a buffer in the submitted command. Once the controller receives the command (by reading the Admin Submission Queue), it executes the Identify command, and uses the underlying (PCIe) transport to move the data from the controller to the host.


Once the command has been completed, and the host has retrieved the completion queue entry (and verified the status), the host can then copy that buffer data from host memory to the identify_buffer provided by the user. Note that the VIP is taking care of building all the appropriate data structures and also generates (and responds to) the associated transactions to execute the command while all the time monitoring the protocol.


We’ve gone over the basic layers and architecture of the Synopsys NVMe VIP, and you should now have an idea of how NVMe commands are sent to the controller via those layers. More detail follows in upcoming episodes, including more VIP details and features, more advanced topics in the NVMe protocol and the use of other Verification Methodologies (such as UVM) to configure, control, monitor and submit commands with the VIP.

Thanks again for browsing, see you next time!

Authored by Eric Peterson

Here’s where you can learn more about Synopsys’ VC Verification IP for NVMe and for PCIe.

Posted in Methodology, NVMe, PCIe, UVM | No Comments »

MIPI UniPro: Major Differentiating Features, Benefits and Verification Challenges

Posted by VIP Experts on October 13th, 2015

MIPI UniPro is a recent addition to mobile chip-to-chip interconnect technology. It’s got many useful features to meet the requirements of mobile applications. That’s perhaps why Google’s Project Ara has selected MIPI UniPro and MIPI M-PHY as its backbone interconnects.

In this blog post, we describe three differentiating features, benefits and their verification challenges. All the discussion is referenced to MIPI UniPro 1.6.

  1. Achieving Low power consumption through Power mode changes and hibernation
  2. Flexibility in chip-to-chip lane routing through Physical Lane mapping
  3. Enhanced QoS through CPort arbitration & Data link layer pre-emption

You can learn more about our VC VIP for Unipro and M-PHY here.

1. Achieving Low power consumption through Power mode changes and hibernation


MIPI UniPro provides six power modes to meet different needs. In SLOW mode, it supports seven gears with operational speed ranging from 3Mbps to 576Mbps per lane. In FAST mode, it supports three gears with operational speed ranging from 1.5Gbps to 6Gbps per lane. Both SLOW and FAST can be coupled with automatic M-PHY’s BURST closure during traffic gaps called AUTO. In the complete absence of traffic hibernate mode is used. All unconnected lanes shall be put in OFF mode. UniPro allows independent power mode settings for both transmit and receive direction.

UniPro allows the dynamic selection of number of lanes, gear and power mode per direction using Power mode change request (DME_POWERMODE) and hibernate state transitions through (DME_HIBERNATE_ENTER and DME_HIBERNATE_EXIT) primitives. MIPI UniPro L1.5 Layer accomplishes these requests through the PHY Adapter Configuration Protocol (PACP) frames of the type PACP_Pwr_Req and PACP_PWR_Cnf.  Traffic is paused briefly during the power mode change procedure. Power mode settings are applied simultaneously after completion of power mode change procedure on both ends and traffic is resumed.


This feature allows MIPI UniPro in achieving optimal “performance per watt” of power through setting of appropriate power mode. Based on the application’s data traffic bandwidth and latency requirements, it can scale the number of lanes and operational speed of lanes in each direction dynamically.

Verification Challenge

Following parameters gives rise to large state space

  • 6 different power modes
  • 7 gears in SLOW mode and 3 gears in the FAST mode
  • Up to 4 lanes and it can be scaled down to any value
  • Asymmetric setting of the mode, gear and lanes in both direction

Functional verification will have to cover the unique combination of all of the above power mode state space (mode x lane x gear). Additionally two more important transition combinations have to be covered:

  • Transitions from one possible unique combination of power mode to another possible unique combination (~1600 combinations)
  • Hibernate entry and exit from each of the unique power mode state

This would require a constrained random stimulus support. The constrained random stimulus generation is not quite straight forward. It will have to take in to consideration:

  • Current power mode state
  • Capabilities of the both the peer and local device

Based on above parameters the legal power mode changes will have to be initiated from both the VIP and DUT side.

2. Flexibility in chip-to-chip lane routing through Physical Lane mapping


UniPro allows using multiple lanes (max up to 4) to scale the bandwidth. UniPro Phy adapter layer takes care of distribution and merging of data. During the L1.5 layer’s multi-phase initialization sequence the total number of lanes connected and their physical to logical lane mapping gets determined.


Training sequence identifying the logical and physical lane mapping. Source: MIPI


This feature provides the flexibility in the UniPro’s chip-to-chip lanes routing. Considering the small footprint requirement for mobile hardware this will surely ease printed circuit board designer’s life.

Verification challenge

From verification point of view need to cover the following:

  • Different number of lanes connected, and
  • Every physical lane getting mapped to every possible logical lane

Typically through configuration, the number of lanes connected and for connected lanes the logical to physical mapping used needs be randomized. Based on this configuration, the VIP will drive the specified number of lanes and advertise appropriately to the DUT.

3. Enhanced QoS through CPort arbitration & Data link layer pre-emption


MIPI UniPro supports two traffic classes traffic class 0 (TC0) and traffic class 1 (TC1). Traffic class 0 support is mandatory while traffic class 1 support is optional. Priority based arbitration between traffic classes is supported. The MIPI UniPro stack, right from its transport Layer L4 to the data link layer L2, is traffic class aware to provide enhanced Quality of Service (QoS).

At the transport layer level, the logical data connection is the connection oriented port (CPort). It is mapped to either TC0 or TC1. Cports mapped to higher priority traffic class will have precedence over CPorts mapped to lower-priority traffic class. Within a traffic class, segment level round robin is the default arbitration scheme.

To reduce delays and to improve Quality of service (QoS) at the data link layer level, it can insert high priority frames within a lower priority data frame under transmission. This feature is called pre-emption. It’s an optional feature. This concept is extended to other control frames as well for improving the latency and reducing the bandwidth wastage during retransmission.


Composition with pre-emption (Traffic class Y > X). Source: MIPI


CPort arbitration and pre-emption provide fine control over latency of communication. This enables improved QoS. This feature can be used for latency sensitive traffic.

Verification challenge

From the verification point of view, we need to address:

  • Meeting the overall intent of QoS feature
  • Ensuring that the pre-emption feature is functionally implemented correctly

QoS feature intent can be verified by measuring the latency on both transmit and receive path of the DUT. This can be done as additional functionality of the scoreboard. The scoreboard can record the time stamp of the messages entering and exiting ports of DUT on both CPort and serial line. The latency of transmit and receive path of DUT can be checked against the desired configured value. Any violations can be flagged as warnings or errors based on the percentage violations.

To ensure that the pre-emption feature is functional, both the legal and illegal pre-emption cases needs to be exercised. Based on the supported priorities table for DL arbitration scheme, there are 18 illegal and 35 legal pre-emption scenarios possible. Both legal and illegal cases must be covered on both transmit and receive path of the DUT including multi-level pre-emptions.

For all these features verification, a well-architected Verification IP plays a critical role. Verification IP with right level of flexibility and control can significantly accelerate the closure of verification.

Authored by Anand Shirahatti, Divyang Mali, Naveen G

You can learn more about our VC VIP for Unipro and M-PHY here.

Posted in Methodology, MIPI, Mobile SoC, MPHY, Unipro | Comments Off

Get Ready for IoT with Synopsys PCIe VC Verification IP Workshop

Posted by VIP Experts on October 6th, 2015

Internet of Things (IoT) is connecting billions of intelligent “things” to our fingertips. The ability to sense countless amounts of information that communicates to the cloud is driving innovation into IoT applications. Servers powering the cloud will have to scale to handle these billions of intelligent things. As a preparation to that PCIe Gen 4 has been introduced. It is capable of supporting 16 T transfers/s. Current primary market driver for the PCIe Gen4 application seems to be server storage space.

Also PCI-SIG and MIPI are collaborating on supporting MIPI MPHY with PCIe: MPCIe is a version of the PCIe protocol for the mobile interconnect.

PCIe had its own evolution with Gen1, Gen2, Gen3 and now Gen4. With every new generation, the speed has doubled and so is the increase in complexity. A proven PCIe Verification IP with support for all the speeds can significantly reduce the verification schedule. If such a Verification IP is also bundled with test suite and coverage suite it can certainly reduce the risk of verification. What if such Verification IP also comes bundled with support for protocol aware debug in Verdi?

Synopsys offers all these features in a single PCIe VC Verification VIP offering:

  • Support for Gen1, Gen2, Gen3 and Gen 4 speeds
  • Support for MPCIe
  • Supporting for the NVMe application
  • Includes a bundled test suite
  • Built-in support for protocol-aware debug in Verdi


Come experience our product hands-on through a PCIe Workshop in your region. This workshop will provide you a unique opportunity to learn about:

  • Ease of programming interface of VC Verification IP for doing normal transfers, error injection and low power scenarios
  • Various outputs generated by the VC Verification IP for debug, Learn to use different abstraction of debug information for different level of debug from signals to text logs to protocol aware debugs within single Verification IP
  • How to integrate the user DUT in to the test suite environment and get it going quickly

Recently, PCIe workshops were held in Mountain View, California, and Bangalore, India. Participants in these workshops told us that they loved the new feature of Verdi to facilitate protocol aware debug and coverage back annotations. Error injection capabilities coupled with various debug capabilities at each layer gave them the confidence to left-shift verification closure. 

Free registration is now open for Shanghai-China, Tokyo-Japan, Austin-Texas and Herzelia-Israel.

Authored by Sadiya Ahmed, Anunay Bajaj and Anand Shirahatti

Posted in Debug, Methodology, MIPI, MPHY, PCIe, SystemVerilog | Comments Off

Protocol Debug for Complex SoCs

Posted by VIP Experts on September 29th, 2015

Here, Bernie DeLay, group director for Verification IP R&D at Synopsys, talks to Ed Sperling of Semiconductor Engineering about the challenges of debugging protocols in complex SoCs.

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

Posted in AMBA, DDR, Debug, Memory, Methodology, PCIe, Processor Subsystems, Storage, USB | Comments Off