VIP Central

PCIe: Monitors and Test Suites

Posted by VIP Experts on April 30th, 2015

In this video, Paul Graykowski of Synopsys gives an overview of the PCI Express VIP Monitor and Test Suites http://bit.ly/1DHIdyQ

You can learn more about our VIPs at Verification IP Overview, or download the Datasheet for PCIe and MPCIe.

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

MIPI Soundwire: Pulse Code Modulation (PCM)

Posted by VIP Experts on April 28th, 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.

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

In this blog post, we will discuss PCM.


Most current digital audio systems (computers, compact discs, digital telephony etc.) use multi-bit Pulse Code Modulation (PCM) to represent the sound signal. PCM has the advantage of being easy to manipulate. This allows signal-processing operations to be performed on the audio stream, such as mixing, filtering, and equalization. As shown in Figure 1, Analog to PCM conversion consists of three steps:  Sampling, Quantizing and Encoding.


Figure 1. Pulse Code Modulation 

Sampling: As shown in Figure 2, Sampling is reduction of a continuous signal to a discrete signal. It is also called digitization of time. It results in a sample, which is discrete (digital) in time but continuous (analog) in amplitude. Sampling rate, i.e. samples taken per second, is an important factor while doing sampling and it is necessary to capture audio covering human hearing range. Human beings can hear frequencies in the range of 20Hz to 20KHz. Nyquist theorem says that sampling rate should be double the frequency of highest frequency signal.  So, in order to preserve the quality of sound sensed by the human ear, roughly 40Khz sampling rate is required. That is why 44.1Khz (CD) and 48Khz (DVD, DV) are the most common sampling rates for digital audio.


Figure 2. Sampling

Quantization: It is the process of mapping a large set of input values to a (countable) smaller set such as rounding values to some unit of precision. After this step, the sample is discrete in time and amplitude as well, as illustrated in Figure 3. A device or algorithmic function that performs quantization is called a Quantizer. The round-off error introduced by quantization is referred to as quantization error. The number of available discrete levels of amplitude determines quantization error, and it depends on the number of bits per sample. If we use more bits to quantize a signal, its quality will be better. For instance, an 8-bit sample will have 28 = 256 discrete levels. In terms of Singal-to-Noise Ratio (SNR), each additional bit increases the SNR by 6dB (improve signal quality). It is represented by following formula:




Common PCM samples are of 8, 16, 20 and 24 bits wide.


Figure 3. Quantization

Based on this information, one can decide what kind of sampling rate and sample bits are appropriate for a specific target application. Let us consider the case of the human voice signal in a telephone system: Frequency range 80 ~ 3.4 KHz], Human ear can tolerate SNR of 40 [dB].

To transmit human voice in digitized form based on Nyquist theorem, we need a sampling rate = 2*3.4 [kHz] = 6800 [samples/sec]. Based on SNR formula: 40 [dB] = 6*m + 1.76 ⇒ Number of bits per sample = 7.

Encoding: It is simply converting sample data into digital traffic, which includes interface dependent framing data as well.

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

Posted in Methodology, MIPI | No Comments »

PCIe: Accelerating Debug

Posted by VIP Experts on April 23rd, 2015

In this video, Paul Graykowski of Synopsys gives an overview of the PCI Express VIP’s capabilities that will support your efforts to accelerate the debug process:

You can learn more about our VIPs at Verification IP Overview, or download the Datasheet for PCIe and MPCIe.

Posted in Debug, PCIe, SystemVerilog, UVM | No Comments »

The HDCP 2.2 Authentication Process – an Introduction

Posted by VIP Experts on April 21st, 2015

When digital content is transmitted, it is susceptible to unauthorized copying and interceptions. Hence protecting content has become an important factor in the transmission of audiovisual content. In 2003, Intel developed an encryption technique called the High-bandwidth Digital Content Protection (HDCP) protocol to protect audio and video data between a transmitter (transmitting the audio visual content such as a Blu-ray player) and a receiver such as a Monitor. If a transmitting device is transmitting the content HDCP protected then the receiver must also support HDCP in order to receive the content correctly.

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

HDCP protocol is now managed by Digital Content Protection (DCP), LLC, an Intel subidiary, which licenses technologies for the protection of commercial digital content. For every HDCP protected digital content must follow the HDCP protocol and also must have a license issued by DCP, LLC.

History of HDCP
In earlier devices that support the 1.X version of HDCP, such as HDCP1.4, the receiver demonstrates that it has valid secret keys, device private key. Transmitter authenticates that the receiver has valid keys, and then both devices share a secret session key that will be used during encryption as depicted in Figure 1. The authentication strength was reasonable using SHA-1 encryption algorithm in key exchanges. Most of the authentication and encryption was proprietary between devices that support HDCP1.4. Encryption uses a proprietary stream cipher.


Introduction to HDCP2.2
HDCP 2.2 specification applies state of the art cryptography standards, such as RSA and AES, and uses them in authentication and encryption respectively which makes it much more secure than the previous HDCP1.X protocols.

HDCP 2.2 protocol works in 3 phases: the first phase, Authentication, is to verify that the receiver is genuine and authorized to receive the digital content. During the second phase, Encryption, transmitter can start sending the encrypted data to receiver, which will then decrypt it using keys exchanged during the authentication step. In the event that legitimate devices are compromised, the third phase, Renewability, allows the HDCP transmitters to identify such compromised devices and prevent transmission of HDCP content.

HDCP2.2 Authentication Protocol
Before transmitting the audio visual content, the transmitter must make sure using the authentication protocol that the receiver is genuine and authorized to receive the protected content.

The Authentication Protocol consists of:
1. Authentication and key exchange (AKE): Checks that the receiver contains a valid un-revoked public key certificate.
2. Locality Check: A check to make sure that the receiver is placed nearby and restricts the transmission to a locality.
3. Session key exchange (SKE): A common shared session key is exchanged which will be used to encrypt the data itself.
4. Authentication with repeater: An option step when sink is a repeater i.e., Subsequent sink device can be attached. Transmitter checks that none of the receivers in the topology is un-authorized.

In the next blog post, we will discuss the basics of RSA cryptography. An advanced version of RSA is the underlying cryptography standard used during the Authentication and key exchange.

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 »

PCIe VIP: Accelerating Verification

Posted by VIP Experts on April 16th, 2015

In this video, Paul Graykowski of Synopsys gives an overview of the PCI Express VIP’s capabilities that will support your efforts to accelerate the verification process: http://bit.ly/1CWit0q

You can learn more about our VIPs at Verification IP Overview, or download the Datasheet for PCIe and MPCIe.

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

MIPI Soundwire: Digital Audio Simplified

Posted by VIP Experts on April 14th, 2015

MIPI Alliance has come up with a new protocol standard for sound interface called SoundWire. SoundWire is a robust, scalable, low complexity, low power, low latency, two-pin (clock and data) multi-drop bus that allows for the transfer of multiple audio streams and embedded control/commands. To understand its specification and design verification needs, it is important to understand basics of digital audio transmission.

Traditionally, sound is recorded and transmitted as analog signals. However analog signal is sensitive to noise: it is difficult to send analog signals over a long distance without introducing significant noise. It is also expensive to transmit high quality analog signals over short distances. The solution to this problem is digitization of analog signals: send it in digital form, and again convert it to analog for sound reproduction. This process involves a number of steps and adds complexity to the system, but it is more reliable and cost effective. If designed properly, the degradation of signal due to digitization can be insignificant. 

You can learn more about the common digital audio formats, Pulse Code Modulation (PCM) and Pulse Density Modulation (PDM), which are target applications for MIPI Soundwire, by downloading our whitepaper.


Pulse Code Modulation (PCM)


Pulse Density Modulation (PDM)


Posted in Methodology, MIPI | No Comments »

Freescale and Xilinx Engineers: Managing SoC Verification Complexity

Posted by VIP Experts on April 9th, 2015

At DVCon 2015, a couple of our key customers shared their viewpoints on how they manage growing verification complexity. This video begins with Michael Sanie highlighting the Synopsys Verification Continuum, and several key technologies that currently address the industry’s need to “Shift-Left” for faster time-to-market. Later, Amol Bhinge of Freescale and Prashanth Gurunath of Xilinx share how their leading SoC design teams have achieved success by collaborating with Synopsys.

Industry Leaders Verify with Synopsys
Michael Sanie, Senior Director of Verification Marketing

Addressing Unique Verification Challenges of Mixed-signal with VCS AMS
Prashanth Gurunath, Sr. Member Technical Staff Engineer

Reducing SoC Verification and Software Validation Turn Around Time
Amol Bhinge, Senior SoC Verification Manager

See more at: http://www.synopsys.com/Tools/Verification/FunctionalVerification/Pages/dvcon-2015-video.aspx#sthash.unWqj90D.dpuf

Please let us know if you are interested in hearing more such stories and viewpoints from leading engineering teams.

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

PCIe Verification IP Overview

Posted by VIP Experts on April 7th, 2015

In this video, VIP Senior Manager Paul Graykowski of Synopsys gives an overview of the PCI Express Verification IP: http://bit.ly/1DTe6si

You can learn more about our VIPs at Verification IP Overview, or download the Datasheet for PCIe and MPCIe.

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

AMBA: Stitch it all up to ACE your Test

Posted by VIP Experts on April 2nd, 2015

The ARM® AMBA4® specification for the connection and management of functional blocks in a system-on-chip (SoC) now features Advanced eXtensible Interface (AXI)™ coherency extensions (ACE)™ in support of multi-core computing. The ACE specification enables system-level cache coherency across clusters of multi-core processors. When planning the functional verification of such a system, these coherency extensions bring their own complex challenges, such as system-level cache coherency validation and cache state transition validation. At any given time, it’s important to verify that the ACE interconnect can maintain cache coherency across the different ACE masters in the system. With coherency support now in the hardware, together with an associated support protocol, the complexity of the system and the underlying components has increased substantially.  The verification of such systems thus faces several challenges. Let’s get a grasp of the requirements on the stimulus generation infrastructure  for validating a cache coherent system.

Here’s where you can find more information on our Verification IP.

An AMBA ACE interconnect-based system can have a variety of masters and slaves connected by a coherent interconnect. Individually, each master and slave component can support a complete ACE, ACE-Lite™, AXI4™ or AXI3™ protocol and can work with a different bus widths or clock frequencies. The different permutations involve the following parameters:  cache states, transaction types, burst lengths and sizes, snoop mechanisms, snooped cache states, snoop responses, support for speculative fetches, support for snoop filtering, and user-specified scheduling of interconnect.

All these cross combinations lead to a very large verification space, creating four key challenges:

  1. Generating stimulus mapped to all of these include, ensuring each individual master, slave or interconnect is fully compatible with the protocol it supports;
  2. Ensuring all possible combinations of concurrent access among initiating masters, snooped masters and slave main memory are verified and are in compliance with the ACE specification;
  3. Ensuring all user-specific features are covered and working as expected; and
  4. Ensuring the completeness of verification

How do you go about creating a stimulus generation infrastructure that can handle all these?

Here we try to show you how it can be done? The idea is to ensure you have all the right building blocks to start with and progressively organize them and stitch them together to get to what you need.

Credits: http://www.geekalerts.com/lego-tonka-heavy-assault-truck/

What we do in our VC Verification IP (VIP) is something very similar: we start with some tried and tested native SystemVerilog UVM atomic sequences and progressively move toward creating complicated ones. Given the functionality that UVM provides, it is much more convenient to stitch together low-level, proven or validated scenarios to create more complex ones. Instead of creating a flattened implementation in the sequence body, hierarchical or nested sequences can be created to leverage the basic sequences which have been created earlier. This can go up to multiple levels of hierarchy and thus it becomes possible to converge towards meeting the requirements of the most complex scenarios.

As the complexity increases across multiple ACE components, there might be a requirement to coordinate the sequences across multiple sequencers and drivers. These are achieved through virtual sequences and sequencers. The other important functionality from a stimulus generation perspective is the grouping of sequences and the creation of hierarchical sequences. In UVM, similar sequences can be grouped together into a sequence library. Using the UVM base classes, you can create the library infrastructure which would allow any sequence to be registered to the sequence library through the library APIs. Once the library is picked in the simulation, the default functionality causes a random number of sequences to be picked up and executed. Thus, the sequence library which ships with the AXI VIP can be used can be used as a starting point for meeting the user’s requirements.

The default mode of sequence library can be modified by changing the parameters of the associated configuration class. Thus, one can enable a specific number of sequences to be picked up, enable random cyclic sequences, as well as program a user-defined sequence execution.

Creating custom rules for the sequence library would help not only to streamline multiple sequences in different simulations but also to avoid redundancy and move progressively toward convergence of all interesting system-level scenarios. Hence, without having to write multiple tests, I can create custom-defined sequence execution across multiple sequence libraries, across different interfaces, through a virtual sequencer, resulting in a stimulus management setup that helps meet all the stimulus generation requirements much faster.  In some of the  scenarios, the sequences have to be aware of the functional configuration to enable reconfiguration based on the system-level requirements. VC VIP leverages most of the functionality provided by the UVM Resource Mechanism to provide the configurability and the sophisticated stimulus generation requirements in the ACE context. The configurability enabled through the Resource Mechanism is a very interesting topic in itself, and I can talk about it in a subsequent post.

Here I have an example which shows how to create custom sequence generation requirement using the sequence collection. Let us take the case where we need to verify all the cacheline states associated with a Readclean transaction. (“ReadClean is a read transaction which is used in a region of memory that is shareable with other masters. A ReadClean transaction is guaranteed not to pass responsibility for updating main memory to the initiating master. Typically a ReadClean transaction is used by a master that wants to obtain a clean copy of a cache line, such as a master with a write-through cache.”) So, what how do you initiate such a transaction?

A ReadClean transaction would require a cache line initialization followed by cache line invalidation, then a basic Readclean. Lets see what you have as building blocks. First, you take the ‘cache line initialization’ sequence which initializes the cache line states of a master’s cache and its peer’s caches to a set of random but valid states. This ensures that all the different cache line state transitions for a coherent transaction initiated by a master are verified. This would require a sequence which would write into the initiating masters local cache. Data is now dirty in local cache. This would be followed by another master initiating a ‘write’ into memory. Data is now clean in local cache and the data in cache matches the data in memory. This is followed by a ‘BasicReadShared’ which will read data into per master’s local cache by getting clean data from the initiating Master.  Then you would need a sequence that invalidates cache lines of a master. This would be your cache line invalidation sequence. This may be required for non-speculative load transactions.  Finally , you need to have a basic Readclean sequence:

A  complete verification scenario can be mimicked using the nested sequences and virtual sequences. With the hierarchical approach, it becomes relatively easy to model any scenario generation requirements regardless of how complicated they are. This approach when combined with the virtual sequences helps to leverage this functionality across multiple interfaces and is highly relevant in the system context as shown above. Thus, multiple virtual sequences that are part of the library can perform a combination of different sequential coherent transactions from different masters to the same slave or different slaves.

As the complexity of protocols continues to increase and evolve, the infrastructure required for their verification needs to scale up in sophistication as well. Advanced Methodologies such as UVM have been continually evolving to keep up with the many complex requirements. Verification of basic cache coherent systems is in itself challenging. The additional complexity that the ACE protocol brings demands a lot from the verification methodology used. The  functionality provided with the UVM library with respect to sequence generation, distributed phasing and configuration management as well as the recent updates  (available through the UVM-1.2 library) can enables VIP implementations to leverage these to meet the verification requirements in different systems.

Authored by Amit Sharma

Here’s where you can find more information on our Verification IP.

Posted in AMBA, Methodology, SystemVerilog, UVM | No Comments »

Virtual Sequences in UVM: Why, How?

Posted by VIP Experts on March 31st, 2015

In my previous blog post, I discussed guidelines to create reusable sequences. Continuing on this thread, here I am going to talk about virtual sequences and the virtual sequencer. Common questions I hear from users include: why do we need a virtual sequence? How can we use it effectively?

Here’s where you can find more information on our Verification IP

Most UVM testbenches are composed of reusable verification components unless we are working on block-level verification of a simple protocol like MIPI-CSI. Consider a scenario of verifying a simple protocol; In this case, we can live with just one sequencer sending the stimulus to the driver. The top-level test will use this sequencer to process the sequences (as described in the previous blog post). Here we may not need a virtual sequence (or a virtual sequencer).

But when we are trying to integrate this IP into our SOC (or top-level block), we surely want to consider reusing out testbench components, which have been used to verify these blocks. Let us consider a simple case where we are integrating two such blocks: two sequencers driving these two blocks. From top-level test, we will need a way to control these two sequencers.

This can be achieved by using a virtual sequencer and virtual sequences. Other way of doing it is to call sequence’s start method explicitly from the top-level test by passing the sequencer to the start method.

I am going to explain this usage by taking an example, where USB host is integrated in an AXI environment. Let’s see how we can control USB sequencer and AXI sequencer from top-level test. For this particular test, I want to configure the AXI registers and then send USB transfers. For configuring AXI registers am using a sequence say axi_cfg_reg_sequence and for sending USB transfers am using the sequence (usb_complex_sequence) which I have used in the previous blog post. Below is an example where multiple sequencers are controlled without using a virtual sequence.

//Top-level test where multiple sequencers are controlled from the
//phase method.
class axi_cfg_usb_bulk_test extends uvm_test;

  //Sequences which needs to be exercised
  usb_reset_sequence u_reset_seq;
  axi_reset_sequence a_reset_seq;
  usb_complex_sequence u_bulk_seq;
  axi_cfg_reg_sequence a_cfg_reg_seq;

  function new (strint name=”axi_cfg_usb_bulk_test”,
                uvm_component parent=null);
  endfunction: new

  //Call the reset sequences in the reset_phase
  virtual task reset_phase (uvm_phase phase);
    //Executing sequences by calling the start method directly by passing the
    //corresponding sequencer

  virtual task main_phase (uvm_phase phase);
    //Executing sequences by calling the start method directly by passing the
    //corresponding sequencer
endclass: axi_cfg_usb_bulk_test

This is not the most efficient way of controlling the sequencers as we are directly using the simple sequences inside the test and making it complex. By doing this, we cannot reuse these complex scenarios further to develop more complex scenarios. Rather if we try to create a sequence and use this sequence in the test, then we can re-use these sequences in other tests (or sequences) as well. Also it will be easier to maintain and debug these sequences compared to creating entire scenario in the top-level test.

Having understood why we need virtual sequence and virtual sequencer, let’s see how this can be achieved by taking the same example shown above.

First thing we need to do is to create a virtual sequencer. Note that virtual sequences can only associate with virtual sequencer (but not with non-virtual sequencer). Virtual sequencer is also derived from uvm_sequencer like any other non-virtual sequencer but is not attached to any driver. Virtual sequencer has references to the sequencers we are trying to control. These references are assigned from top environment to the non-virtual sequencers.

//Virtual sequencer having references to non-virtual sequencers
Class system_virtual_sequencer extends uvm_sequencer;
  //References to non-virtual sequencer
  usb_sequencer usb_seqr;
  axi_sequencer axi_seqr;

  function new (string name=”usb_ltssm_bulk_test”,
                uvm_component parent=null);
  endfunction: new


endclass: system_virtual_sequencer

//Top level environment, where virtual sequencer’s references
//are connected to non-virtual sequencers
class system_env extends uvm_env;
  //Agents where the non-virtual sequencers are present
  usb_host_agent usb_host_agent_obj;
  axi_master_agent axi_master_agent_obj;
  //Virtual sequencer
  system_virtual_sequencer sys_vir_seqr;


  function new (string name=”system_env”, uvm_component parent=null);
  endfunction: new

  function void connect_phase(uvm_phase phase);
    //Assigning the virtual sequencer’s references to non-virtual sequencers
    sys_vir_seqr.usb_seqr = usb_host_agent_obj.sequencer;
    sys_vir_seqr.axi_seqr = axi_master_agent_obj.sequencer;
  endfunction: connect_phase

endclass: system_virtual_sequencer

Now we have virtual sequencer with the references to our non-virtual sequencers, which we want to control, let’s see how we can control these non-virtual sequencers using virtual sequences.

Virtual sequences are same as any other sequence but it is associated to a virtual sequencer unlike non-virtual sequences, hence it needs to indicate which non- virtual sequencer it has to use to execute the underlying sequence. Also note that virtual sequence can only execute sequences or other virtual sequences but not the items. Use `uvm_do_on/`uvm_do_on_with to execute non-virtual sequences and `uvm_do/`uvm_do_with to execute other virtual sequences.

//virtual sequence for reset operation
class axi_usb_reset_virtual_sequence extends uvm_sequence;


  //non-virtual reset sequences
  usb_reset_sequence u_reset_seq;
  axi_reset_sequence a_reset_seq;

  function new (string name=” axi_usb_reset_virtual_sequence”,
                uvm_component parent=null);
  endfunction: new


  task body();
    //executingnon-virtual sequence on the corresponding
    //non-virtual sequencer using `uvm_do_on
    `uvm_do_on(a_reset_seq, p_sequencer.axi_seqr)
    `uvm_do_on(u_reset_seq, p_sequencer.usb_seqr)
  endtask: body

endclass: axi_usb_reset_virtual_sequence

//virtual sequence for doing axi register configuration
//followed by USB transfer
class axi_cfg_usb_bulk_virtual_sequence extends uvm_sequence;


  //Re-using the non-virtual sequences
  usb_complex_sequence u_bulk_seq;
  axi_cfg_reg_sequence a_cfg_reg_seq;

  function new (string name=” axi_cfg_usb_bulk_virtual_sequence”,
                uvm_component parent=null);
  endfunction: new

  task body();
    //executingnon-virtual sequence on the corresponding
    //non-virtual sequencer using `uvm_do_on
    `uvm_do_on(a_cfg_reg_seq, p_sequencer.axi_seqr)
    `uvm_do_on(u_bulk_seq, p_sequencer.usb_seqr)
  endtask: body

endclass: axi_cfg_usb_bulk_virtual_sequence

In the above virtual sequence, we are executing axi_cfg_reg_sequence and then usb_complex_sequence. Now having virtual sequence and virtual sequencer ready, let’s see how we can execute this virtual sequence from the top-level test.

//Top-level test where virtual sequence is set to virtual sequencer
class axi_cfg_usb_bulk_test extends uvm_test;
  virtual function void build_phase(uvm_phase phase );

    //Configuring variables in underlying sequences
    uvm_config_db#(int unsigned)::set(this,

    //Executing the virtual sequences in virtual sequencer’s 
    //appropriate phase.
    //Executing reset virtual sequence in reset_phase
             "env.sys_vir_seqr.reset_phase", "default_sequence",

    //Executing the main virtual sequence in main_phase
                     "env.sys_vir_seqr.main_phase", "default_sequence",
  endfunction : build_phase

Until now we understood why and how we can use virtual sequences. We should also keep few things in mind while using virtual sequence and virtual sequencer to save a lot of debugging time.

1. While configuring the variables in the sequences (which are executed using virtual sequences) we have to use path thru virtual sequence. In above example, using the non-virtual sequencer path for setting the variables in the lower level sequence, will not work.

uvm_config_db#(int unsigned)::set(this,”env.usb_host_agent_obj.sequencer.u_bulk_sequence”,”sequence_length”,10);

Even though u_bulk_sequence is running on the usb_host_agent_obj.sequencer, this will not work because this sequence is created by the virtual sequence and hence hierarchal path should be from virtual sequence but not using non-virtual sequencer. So the right way of setting variables is using the virtual sequence path.

uvm_config_db#(int unsigned)::set(this,”env.sys_vir_seqr.axi_cfg_usb_bulk_virtual_sequence.u_bulk_sequence”,”sequence_length”,10);

This is also true for factory overrides. For example below factory override will not work for the same above reason.

set_inst_override_by_type(”env.usb_host_agent_obj.*”,usb_transfer_item::get_type(), cust_usb_transfer_item::get_type());

In the above example we are trying to change the underlying sequence item with a new derived type from top-level test. For doing this we need to use the virtual sequencer path.

set_inst_override_by_type(”env.sys_vir_seqr.*”,usb_transfer_item::get_type(), cust_usb_transfer_item::get_type());

Rules of Thumb are:
• If the sequence is created by a virtual sequence directly or indirectly, then any hierarchical path in factory overrides or in configurations should use virtual sequencer’s hierarchical path.
• If the sequence is created by a non-virtual sequence, then any hierarchical path in factory overrides or configurations should use non-virtual sequencer’s hierarchical path.

2. Even though we have virtual sequencer to control multiple sequencers, in some tests, we may just need a single sequencer (for example USB sequencer alone). In such cases, we have to use the non-virtual sequencer’s hierarchical path directly (not the virtual sequencer’s reference path) for configuring the variables or factory overrides. Using the virtual sequencer’s reference path will not work as the hierarchy of non-virtual sequencer is incorrect.

uvm_config_db#(uvm_object_wrapper)::set(this, “env.sys_vir_seqr.usb_seqr.main_phase”, “default_sequence”, usb_complex_sequence::type_id::get());

Above configuration will not work, as non-virtual sequencer (usb_seqr/usb_host_agent_obj.sequencer) is actually created in the agent, so the parent for this sequencer is agent but not the virtual sequencer, though the reference is in virtual sequencer. Hence we should not use virtual sequencer path when trying to set variables in the actual sequencer, instead we have to use the hierarchical path through the agent (actual parent to the sequencer).

uvm_config_db#(uvm_object_wrapper)::set(this, “env.usb_host_agent_obj.sequencer.main_phase”, “default_sequence”, usb_complex_sequence::type_id::get());

3. Whenever we are using virtual sequencer and want to control non-virtual sequencers from virtual sequencer, make sure to set the default_sequence in all the actual sequencers to null.

uvm_config_db#(uvm_object_wrapper)::set(this, “env.usb_host_agent_obj.sequencer.main_phase”, “default_sequence”, null);
uvm_config_db#(uvm_object_wrapper)::set(this, “env.axi_master_agent_obj.sequencer.main_phase”, “default_sequence”, null);

This is important because if there is any default_sequence set, then our non-virtual sequencer will be running both the default_sequence and the sequence from the virtual sequence. To control non-virtual sequencers solely from virtual sequencer, we need to set the default_sequence of the non-virtual sequencers as null.

I hope you find this post useful for understanding virtual sequences and save debugging time with the guidelines outlined. I am sure there will be other guidelines while using virtual sequences, which we learn the harder way debugging complex environments; please share any such guidelines with me.

Authored by Hari Balisetty, Broadcom

Here’s where you can find more information on our Verification IP.

Posted in AMBA, Debug, Methodology, MIPI, SystemVerilog, USB, UVM | No Comments »