HOME    COMMUNITY    BLOGS & FORUMS    VIP Central
VIP Central

Full Utilization of 16 GT/s PCIe Gen 4 Bandwidth – 2

Posted by VIP Experts on May 25th, 2016

PCI express Gen 4 implementation is marching towards the Gen 4 0.7 release. It’s important that not only physical layer delivers the 16 GT/s rate, but also the entire protocol stack should be capable of saturating the full allocated bandwidth. To saturate the full bandwidth, following two key features are gaining traction:

In our earlier blog,  we discussed about 10-bit extended tag. In this blog, we will discuss about the second feature scaled flow control credits. We will give a brief introduction of the feature to give a jump start to any one ramping up on the latest specifications, and also discuss corresponding verification challenges and solutions.

Scaled flow control credits

Current flow control mechanism allows maximum of up to 127 outstanding header credits and 2047 outstanding data credits. The Gen3 x16 link can’t saturate with these limits in certain scenarios. The flow control mechanism is enhanced with scaled flow control. In scaled flow control mechanism, the maximum outstanding header and data credits can be scaled by a factor of 1, 4 or 16 based on the programmable setting. Note that the credits remain unchanged, one header credit will still be 1 TLP header and one data credit remains to be 16 bytes. Following updates have been done to support scaling flow control: -

  • New capability structure called “Data Link Feature Extended Capability” has been added. It contains programmable control/status information about the local and peer support of the “Data Link Feature Support”
  • New DLLP called “Data Link Feature Exchange” has been added
  • New state called “DL Feature” has been added in the Data Link Control and Management State Machine as a part of the initialization
  • During the new state DL Feature a new extension is added to initialization. The new DLLP “Data Link Feature Exchange” is exchanged at every 34 us to figure out if the Flow control scaling is enabled
  • Init FC1, Init FC2 exchanged subsequently decide the scaling factor through the re-definition of the reserved bits as shown below
  • Subsequent UpdateFC protocol remains unchanged. The scaling factor in the UpdateFC must continue to match to the factor indicated during initial credit exchange protocol
Proposed updates to DLLP to support credit scaling (Courtesy: PCI-SIG)

Proposed updates to DLLP to support credit scaling (Courtesy: PCI-SIG)

Verification Challenges and Solution

Verification of the feature can be divided in 3 categories as described below: -

  • Normal operation
    • Directed test to verify if credit scaling with different programmed settings is reaching to its maximum values
    • Random credits usage with different scaling enabled
    • With multiple VCs, when one VCx is blocked the other VCy can continue to make forward progress if there is pending traffic
  • DL Feature state
    • Possible state transitions from and to DL Feature state
  • Error injection cases
    • New HdrScale and DataScale field corruptions
    • Issuing more credits than advertised
    • All the error injections leading to reporting of “Flow Control Protocol Error”, as defined in specification.

Synopsys VC VIP for PCIe supports latest specifications and makes it very easy to verify all the new features.

Authors:  Anand Shirahatti, Mohd Adil Khan, Jamshed Alum 

Posted in PCIe | No Comments »

AUTOMOTIVE… Vroom Vroom….

Posted by VIP Experts on May 17th, 2016

automtoive smoke cloud

One of the most important inventions of mankind is the “wheel”. What started as a small means of transportation has turned into a revolution that changed the dynamics of how the world runs today. Imagine a world without wheel – scary and impossible to accept. With the wheel around, the first step to automotive industry was laid with a simple carriage, and exponentially grew into one of the biggest economic sectors running over billions of automobiles.

From being simple users of these automobiles in earlier times, users have become smarter now and looking for differentiators in new automobiles. They demand more sophisticated infotainment systems and high-end features as a standard at a lower price. Being connected at all the times is the order of the day – an ecosystem on the move. There is tighter screw from governments on emission norms, fuel economy and safety features.

The move to autonomous vehicle is approaching to mass production rapidly. From manually controlled cars in yester years to more driver alerts to emergency intervention for driver assist package to monitored control for super cruise concept to autonomous driving – the growth in automotive technology is on fast track. Auto-on lamps, rain sensing wipers, brake assist, night vision, intelligent parking assist, traffic jam assist, blind spot detection – the list of automation is huge and ever growing to make driving a happy and safe experience.

Safety implies protection against any risk, danger, damage or cause of injury. Safety in automobiles cannot be compromised and it is the primary requirement to prevent any malfunctions or defects that may cause serious accidents. There have been many product recalls in recent times due to undetected safety issues leading to not only heavy financial losses but also a big dent on the popular automobile brands. Any defect, however small, if left in the design may lead to serious consequences. Hence, safety in the automotive industry is highly regulated. Automobiles have to comply with a certain number of norms and regulations. ISO 26262 standard is considered as one of the best practice framework for achieving automotive functional safety.

To conclude, with all the above automation, and safety measures, electronics in automobiles is already on a rise. Electronics and software now contribute a handsome 35% of the overall car cost and 90% of innovations and new features. Automotive protocols like Ethernet AVB, CAN, LIN, FlexRay are being deployed rapidly, especially in the Infotainment systems in automobiles. The day is not far when we would have driver-less cars roaming around us – fully safe and sound.

We will talk more about the above mentioned automotive protocols in our upcoming blogs.

Automotive Systems

Automotive Systems

Synopsys: Your verification partner for next-gen Automotive SoCs

Synopsys VC VIP for Ethernet AVB, CAN, LIN, FlexRay are based on native SystemVerilog, Universal Verification Methodology (UVM) architecture, and provides built-in protocol checks, coverage and verification plan for accelerated verification closure. VIP provides an extensive and customizable set of frame generation and error injection capabilities. In addition, source code test suites are also available to jumpstart verification of complex protocols. Wherever applicable, compliance test suites are also provided.

Authored by Jaspreet Singh Gambhir

Posted in Automotive, CAN, Ethernet AVB, FlexRay, LIN | No Comments »

MIPI D-PHY Revolutionizing Today’s Smartphone Market

Posted by VIP Experts on May 10th, 2016

We are capturing our memories in high-definition with the latest multi-megapixel cameras and playing back with the high resolution displays. This has led to a tremendous increase in data transfer and bandwidth requirements between peripherals and application processor in a mobile SoC. It’s challenging to support advanced multimedia features in the mobile phones by integrating megapixel cameras and superior resolution displays at a reduced cost and power consumption.

To overcome these limitations, MIPI D-PHY was defined which brought standardization and improved inter-operability and resolved the challenging requirements of higher bandwidth and reduced power and cost. Unlike many of the existing interfaces, MIPI D-PHY is unique because it can switch between high speed and low power mode in real time depending on the need to transfer large amounts of data or to conserve power to prolong the battery life. With the increase in MIPI D-PHY supported data rates up to 4.5Gbps in latest specifications, it is possible to send high bandwidth data over fewer lanes reducing the chip area and number of interface pins. Camera Serial Interface (MIPI CSI-2) and Display Serial Interface (MIPI DSI) are the two packet-based high level protocols that carry image data between the peripheral and the application processor. Both of these protocols use MIPI D-PHY at physical layer.

dphy

MIPI CSI-2 and MIPI DSI interface connections through MIPI D-PHY

All lanes travel from the DSI host to the DSI device, except for the first data lane (lane 0), which is capable of a bus turnaround (BTA) operation that allows it to reverse transmission direction. When more than one lane is used, these are used in parallel to transmit data, with each sequential byte in the stream traveling on the next lane. For example, if 4 lanes are being used, 4 bytes are transmitted simultaneously, one on each lane. The display and camera interfaces are lane scalable to save power by switching off the lanes for applications that do not require higher bandwidths.

MIPI D-PHY is gaining popularity with the increasing demand for high end devices that require higher bandwidth. With the increase in bandwidth up to 4.5Gbps, MIPI D-PHY is revolutionizing today’s smartphone market with lower cost and lower power consumption.

To know about Synopsys MIPI D-PHY and other MIPI VIP, please visit: www.synopsys.com/vip

Authored by Ajay Garg

Posted in Camera, CSI, D-PHY, Display, DSI, MIPI, MIPI, Uncategorized | No Comments »

Full Utilization of 16 GT/s PCIe Gen 4 Bandwidth

Posted by VIP Experts on May 3rd, 2016

PCI Express Gen 4 has been under development since late 2011 and targeting impressive data rate of 16GT/s. Internet of things (IoT) continues to grow on its promise of everything connected, and it will be extremely important to deliver the promised 16 GT/s bandwidth for the next generation servers and communication equipment.

PCI express Gen 4 implementation is marching towards the Gen 4 0.7 release. It’s important that not only physical layer delivers the 16 GT/s rate but the entire protocol stack should be capable of optimizing the full allocated bandwidth.

To utilize the full bandwidth, following two key features are gaining traction:

In upcoming PCIe blogs we will cover brief introduction to these features to give a jump start to any one ramping up on the latest specifications, and also discuss some of the verification challenges and solutions posed by the above features. The blog scope is limited to root complex and endpoints. Switches and bridges are not covered.

Why these two features gaining traction?

With the increased bandwidth of 16 GT/s, PCIe Gen 4 poses a new challenge of effectively utilizing the bandwidth to take the full advantage. Gen 4 latency has not changed and two key features have been introduced to handle the latency effectively. First one is the 10-bit extended tag to increase the total outstanding transactions and the second feature is scaled flow control credits to increase the total credits advertised and used. These two features together effectively hide the effect of latency and thus enable applications to saturate the link bandwidth to extract the full benefits of Gen 4 speed.

10-bit extended tag

10-bit extended tag increases the total tag field size from 8-bits to 10-bits. This increases the number of outstanding non-posted requests (NPRs) from 256 to 768.

Feature:

The feature is implemented by salvaging the reserved bits in the request header, device capability 2 register and device control 2 register.

  • Two reserved bits in request header Byte 1’s bits [7, 3] are re-defined to get two additional tag bits. Overloading the reserved bits in request header has one down side. The reserved bits initial value, which is ‘0’, cannot be re-used. Thus the total 10-bit extended tag space instead being 1024 outstanding tags is limited to 768 only. From 2-bits only 3 combinations [01, 10, 11] are usable. 256 * 3 = 768.  ‘00’ is not used.
Figure 1:  Request Header update for 10-bit extended tag support (Courtesy: PCI-SIG)

Figure 1: Request Header update for 10-bit extended tag support (Courtesy: PCI-SIG)

  • Device capability register 2, two more reserved bits [17,16] are utilized to add two new capabilities. One for the 10-bit Tag completer and second for 10-bit Tag requester. Note that Receivers/Completers that support the 10-bit Tag completer capability must handle 10-bit tags correctly regardless of their 10-bit Tag Requester Enable bit setting.
  • Device control 2 register’s reserved bit 11 is redefined for 10-bit tag requester enable control.

Verification of feature

From normal operation point of view, each of the non-posted requests individually and in combination should be able to reach the maximum of the 768 outstanding requests from requester enabled for the 10-bit extended tag feature. Enabling the requester capability from both sides and single side needs to be verified. This requires ability from VIP to block the completions when the DUT is acting as requester.

Error scenarios of the extended tag bit corruption needs to be verified. This can potentially take place in real systems, due to intermediate switch or peer not supporting the 10-bit extended tag.

Synopsys VC VIP for PCIe makes it easy to verify the new features.

Stay tuned, in our upcoming PCIe blog we will discuss about the second feature scaled flow control credits.

Authors:  Anand Shirahatti, Mohd Adil Khan, Jamshed Alum 

Posted in PCIe | No Comments »

VIP and Test Suites for Automotive Applications

Posted by VIP Experts on April 26th, 2016

The Automotive industry is going through a revolution with innovations like driver less car, connected vehicles, electric and hybrid engines. Google and Tesla driverless cars have covered millions of miles in testing and Chinese driverless car is also ready for testing. The innovation in automotive industry is driven by rapid deployment of integrated electronics and car chip market has grown at scorching rate to tens of billions. Synopsys is taking the innovation in car systems design and verification to next level and recently announced the expansion of its VC Verification IP (VIP) portfolio with CAN 2.0/FD/TT (ISO 16845 compliant), LIN, FlexRay™, and Ethernet Audio Video Bridging (AVB) protocols for the verification of automotive applications.

The comprehensive portfolio of VIP is the best verification solution for all systems of an intelligent connected automobile ranging from comfort, safety, powertrain, and camera to infotainment, connectivity, communication, memory and storage systems. Synopsys VIP for CAN is the industry’s first VIP with support of CAN TT along with CAN 2.0/FD.

Automotive Systems

Automotive Systems

These verification IP titles include test suites and spec-linking technology required to verify compliance to automotive standards. With the increase in demand for state-of-the-art integrated electronics in automobiles, Synopsys’ comprehensive VIP portfolio enables system-on-chip (SoC) teams to design next-generation electronic systems for safe, secure, smart, and connected automobiles.

Read More

For more information on Synopsys’ VIP portfolio, please visit: www.synopsys.com/vip

Authored by Ankur Jain

Posted in Automotive, CAN, Ethernet AVB, FlexRay, LIN, Uncategorized | No Comments »

Industry’s First SAS 24G Verification IP for Enterprise Storage Systems

Posted by VIP Experts on April 19th, 2016

How fast do we want to access our data? There is a never ending demand for faster and better storage technologies and SAS-4 24G is the latest addition to this. SAS (Serial-attached SCSI) offers an ideal solution for applications with substantial storage, backup and archiving demands. SAS is widely considered to be the prevalent interface for direct-attached storage and is used to support hard drive controllers in enterprise-grade server farms. SAS-4 has doubled the rate with 22.5G signaling and a more efficient 128b/150b encoding scheme to realize a usable data rate of 24G while retaining compatibility with 6G and 12 G.

Synopsys recently announced the availability of the industry’s first verification IP (VIP) to support the Serial-attached SCSI (SAS) 24G standard, making it the first VIP product line to support all SAS interface speed configurations. With increasing demands for the storage, backup and transmission of data, enterprise storage systems are challenged to rapidly transmit data across devices. Synopsys VC VIP for SAS delivers a comprehensive VIP solution for all SAS designs including the newly introduced 24G standard, enabling system-on-chip (SoC) teams to accelerate verification closure.

Read More

For more information on Synopsys’ VIP portfolio, please visit: www.synopsys.com/vip

Authored by Ankur Jain

Posted in SAS, SATA, Storage, Uncategorized | No Comments »

MIPI UniPro Stack Based Design and Verification

Posted by VIP Experts on April 12th, 2016

Mobile phone market is very competitive and time to market is very critical for mobile system designs. It becomes important that the IP design and verification cycle is continuously optimized. MIPI UniPro is a layered protocol for interconnecting devices within a mobile system and allowing them to exchange information at high-data rates. JEDEC UFS and MIPI CSI-3 are the typical applications defined on top of UniPro stack. UniPro specification defines a set of standard signaling at application and physical layers that allows the development and verification of individual IP blocks in parallel. In this blog, I would describe various verification topologies possible in a UniPro design and stack based architecture of Synopsys UniPro VIP.

UniPro protocol defines standard connections like:

  • CPort Interface – To talk to applications like CSI-3/UFS.
  • RMMI Interface – To talk to local MPHY.
  • Serial Interface – To talk to Peer MPHY.

In general, the UniPro design & verification cycle can be broken into various stages like application layer with CPort interface, UniPro stack with CPort & RMMI interface and MPHY with RMMI & Serial interfaces. Each of these individual IP blocks can be designed and verified in parallel before the final integration and verification. State of the art verification solution is necessary to reduce time to market and Synopsys UniPro stack based Verification IP enables mobile system design teams to achieve accelerated verification closure.  Synopsys UniPro stack based VIPs (CSI-3/UFS) can be configured to act only like an application with connections at CPort interface and subsequently to a full UniPro stack based VIP to communicate at Serial/RMMI interface.

Unipro VIP 1

UniPro Verification Topologies

In case of a standalone UniPro design, the VIP can be configured as a CPort VIP driving signals on application side and a full stack UniPro VIP can be connected on the other side of the DUT at serial/RMMI interface.

Unipro VIP 2

Standalone UniPro DUT Verification

Moreover, the UniPro stack itself can be configured into multiple individual layers for intermediate layer verification. In addition to individual block level verification, the VIP can then be used in a full-stack mode to verify the entire stack. The flexible VIP architecture provides protocol checks, functional coverage, and error injection at each layer of the UniPro stack.

UniPro Stack Based VIP

UniPro Stack Based VIP

Authored by Shyamal Sinha

Posted in MIPI, Mobile SoC, Uncategorized, Unipro, UniPro | Comments Off

Integrate USB Test Suite Quickly to Jump Start Verification

Posted by VIP Experts on April 5th, 2016

SoC being designed today are getting complex day by day and verification complexity increases exponentially not only due to the complexity of design but also due to the complexity of protocols. Emerging new protocols make it further difficult due to steep learning curve. Writing test cases to cover the entire protocol becomes 3-4 man year job for complex protocols like USB, PCIe, and Ethernet etc. Synopsys provides System Verilog/UVM source code test suites to verify complex protocols. Source code is provided and tests can be extended, and customized easily. You can save the efforts and time by using Synopsys test suites to jump start verification and achieve accelerated coverage closure. In this blog, we will give an overview of the USB test suite focusing on ease of integration and use.

The USB VIP Test Suite provides a common testbench for a type of USB DUT. For example, there is a common testbench tb_dut_usb_device for device DUT and a common testbench tb_dut_usb_host for host DUT. Different testbenches for other possible type of USB DUT are also provided. The testbench for a host DUT connected to a device VIP provides a host driver to translate data objects to DUT specific API sequences. There is also an xHCI driver for generic xHCI register model and memory operations, for example to create a command TRB and write it to a command ring, ring the command doorbell and watch the command completion event TRB. The testbench for a device DUT connected to a host VIP provides a device driver to translate data objects to DUT specific API sequences.

The intended connection with the DUT is achieved using the specific “connection parameter” in the top module. Tests for the intended “connection type” can be run in the testbench. The particular test configures the testbench environment through a configuration object. Testbench level environment (TB_Env) basically consists of two sub-environments: Host_Env and Device_Env, also TB_Env level virtual sequencer and TB_Env level collection of sequences. Host/Device Env consists of Host/Device_Env level virtual sequencer and Host/Device_Env level collection of sequences. So sequence written at the TB_Env level can be targeted to the Host/Device_Env level virtual sequencer. Virtual sequencer at this Host/Device_Env level consists of usb_transfer_sequencer and usb_service_sequencer and virtual_usb_sequencer. In the Host/Device driver, transfer/service received is either processed using the xHCI model (host DUT as USB controller) or can be redirected to virtual_usb_sequencer in Host/Device_Env which connects to sequencers of VIP agent and the processing of transfer/service is done by the VIP.

To integrate Synopsys USB VIP Test Suite to DUT, following SystemVerilog interfaces are used:

  • Application Interface – This interface uses the AXI/AHB interface to do CSR (Read/Write) to the controller and DMA accesses to the Memory (_mem).
  • Device/Host Interface – This is the USB interface which connects the USB VIP to DUT.
  • Device Specific Interface – This interface is used by the driver to poll for interrupts, events and status of the DUT, which will in turn control the USB Test Suite driver.

Figure shown below is an example of testbench for USB controller DUT with following settings:

  • DUT Type: USB Device
  • DUT Includes PHY: No
  • App Interface: AMBA AXI
  • USB 2.0 Interface: {UTMI|ULPI} and USB 3.0 Interface: {PIPE3}
USB Test Suite VIP integration with DUT

USB Test Suite VIP integration with DUT

In addition to USB test suite, Synopsys provides test suites for a wide range of bus, interface and memory protocols. All the test suites are easy to integrate and easy to use and are provided as source code for extension and customization. For more information on the architecture and scope of the SystemVerilog source-code test suites watch our video blog SystemVerilog Protocol Compliance: Why Source-code Test Suites?

Authored by Karim Aoua

Posted in Test Suites, USB | Comments Off

A Big Ethernet World: 10M to 400G

Posted by VIP Experts on March 29th, 2016

We are living in a connected world and there are over a billion Ethernet devices around the world today. It is very interesting how Ethernet has evolved from a simple standard supporting 10 Mbps to multitude of speed modes and ubiquitous applications. From being a standard that traditionally evolved with 10x speed jumps (10M, 100M, 1G, 10G, 100G), it is now growing rapidly at non-10x speed modes (2.5G, 25G, 40G, 50G, 200G, and latest 400G) and covering diverse application areas to satisfy consumer needs.

Join us to go around the big world of Ethernet in the upcoming blogs on the intricacies of the standard IEEE 802.3 – 2012 and draft committees working on 25/50/400G, its interpretations, common gotchas; defining verification strategies, writing test cases, UNH IOL Compliance suite, and so on and so forth. Let’s start the journey with this blog on early days of Ethernet. Bon Voyage.

Ethernet development started around 1974 and was commercially introduced as a DIX standard (acronym for DEC/Intel/Xerox) in 1980. It was made a standard as IEEE 802.3 in 1983 and since then, Ethernet has evolved to meet new bandwidth and market requirements.

It all started with a shared medium to send and receive data traffic over a half-duplex channel (only transmit or receive at a time). Installation was costly, reliability of data transfer was less and troubleshooting was tough. CSMA/CD (Carrier Sense Multiple Access with Collision Detection) was used as the mechanism to share the medium. Collisions detection and retransmission of data was enabled with the help of layers above Data Link layer. Excessive collisions were costly due to reduced throughput and system reset requirement in case of congestion on the medium. Modern Ethernet is full-duplex (can transmit and receive simultaneously) and the medium is no longer shared. Bandwidth gets fully utilized to obtain maximum data throughputs. The medium used to transfer data can be either coaxial, twisted pair or fiber optic. Ethernet standards continue to embrace new media, higher transmission speeds and additions to frame content with advent of time.

Depending on the area that Ethernet covers, it has been divided on 3 categories: Local Area Network (LAN), Metropolitan Area Network (MAN) and Wide Area Network (WAN). The computer networking technology evolved on the 7-layer ISO OSI (Open System Interconnection) reference model, which helped in standardizing communication between layers to provide an error-free path across a network. Ethernet standard provides services up to Data Link Layer, i.e. it covers the Physical layer (layer 1) and Data Link Layer (Layer 2), in the 7-layer OSI model. We will discuss more about the OSI reference model in detail in upcoming blog.

Ethernet-packet-frame

Stay tuned for upcoming blogs on Ethernet covering following topics in length and breadth (but will not limit ourselves to explore more).

  • Medium Access Control sublayer (MAC) for 10/100M, 1G: Clauses 4, 35
  • Medium Access Control sublayer (MAC) for 10/40/100G: Clauses 46, 81
  • Medium Access Control sublayer (MAC) for 25/50/400G: Clauses 106, 117
  • Physical Coding sublayer (PCS) for 1G Base-X: Clause 36
  • Auto-negotiation: Clause 37
  • Management Data Input Output (MDIO): Clauses 22, 45
  • Physical Coding sublayer (PCS) for 10G Base-X: Clause 48
  • Physical Coding sublayer (PCS) for 10G Base-R: Clause 49
  • Ethernet over Backplane
  • Auto-adaptation: Clause 72
  • Auto-negotiation: Clause 73
  • Forward Error Correction (FEC) for Base-R: Clause 74
  • Reed Solomon FEC (RS-FEC): Clause 108
  • Physical Coding sublayer (PCS) for 40/100G Base-R: Clause 82
  • Energy Efficient Ethernet (EEE): Clause 78
  • Consortium 25/50G
  • IEEE 25/50G
  • Physical Coding Sub-layer (PCS) for 400G Base-R: Clause 119
  • MAC interfaces: MII/GMII/RMII/RGMII/XGMII/XLGMII/CGMII/CDMII
  • Upper layer packets: Layer 2, 2.5, 3, 4 and 7: Include, VLAN, GRE, IPv4, IPv6, TCP, UDP, Tagged frames, etc.
  • IEEE 1588 Precision Time Protocol (PTP)
  • SGMII
  • QSGMII
Synopsys VC VIP for Ethernet

Synopsys VC VIP for Ethernet

Synopsys: Your Verification Partner for Next-Gen Networking and Communication SoCs

Synopsys VC VIP for Ethernet is implemented in native SystemVerilog/UVM architecture,  and provides built-in coverage, protocol checks, and Verdi protocol-aware debug. 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 jump start their own custom testing and achieve accelerated verification closure.

Synopsys provides a comprehensive Ethernet solution for all speeds, including 25G, 40G, 50G, 100G and recently 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.

Authored by Jaspreet Singh Gambhir

Posted in Automotive, Data Center, Ethernet, Ethernet AVB | Comments Off

Simplifying Debug of Memory Models

Posted by VIP Experts on March 24th, 2016

Synopsys VC VIP provides Verdi Protocol Analyzer, a protocol and memory aware debug environment . In my previous blog Debugging Memory Protocols with the Verdi Protocol Analyzer, I discussed the value add for using the Verdi Protocol Analyzer to debug memory protocols easily and efficiently. Also, I described how easy it is to look at a specific command as a transaction rather than as interpreted signals. In this blog I’m going to show another feature that makes Verdi Protocol Analyzer the tool of choice for debugging memory protocol issues and for validating proper system behavior. Furthermore, the tool can be used for verification of the command sequencer and the interaction between the DUT and the memory models. The feature, we are going to look at today, is synchronizing transactions to the corresponding signals.

To demonstrate the synchronization feature, I chose to use a complex command sequence to initialize the DDR memory. There are 15 DDR memory sequences or steps required for power-up initialization as listed in the Jedec Standard JESD79-4 section 3.3.1. These steps are depicted in the waveform shown in the Figure 3 of standard, as referenced below.

DDR  power-up initialization

Now let’s take a look at the same power-up initialization steps in Verdi Protocol Analyzer. Here instead of looking at a multitude of wiggling signals one can observe the 15 steps completed as 1 transaction. Furthermore, in Verdi one can highlight the initialization transaction and cross reference the start and end time of the sequence in nWave. This synchronization feature narrows down the area where the user can focus only on the initialization steps without getting bogged down with the other signals and time stamps that are not related to initialization.

This is demonstrated in the following screenshot.

snapshot

Synchronizing Memory Transactions and Signals

In conclusion, half or more of debug and verification time is cut by the Verdi Protocol Analyzer transaction/signals synchronization feature. Wish you fast and easy debugging.

Authored by Nasib Naser

You can learn more about Synopsys Memory VIP here.

Posted in DDR, Debug, DFI, Flash, HBM, HMC, LPDDR, Memory, Memory, Uncategorized | Comments Off