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.
In this video, VIP Senior Manager Paul Graykowski of Synopsys gives an overview of the PCI Express Verification IP: http://bit.ly/1DTe6si
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.
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?
In this blog, I describe the necessary steps one has to take while writing a sequence to make sure it can be reusable. Personally, I feel writing sequences is the most challenging part in verifying any IP. Careful planning is required to write sequences without which we end up writing one sequence for every scenario from scratch. This makes sequences hard to maintain and debug.
As you may know, USB3.0 has a state machine called LTSSM (Link training and status state machine) which is responsible for
In my previous blog, AMBA based Subsystems: What does it take to verify them?, I had discussed some of the key verification challenges when it comes to verifying complex SOCs based on AMBA based subsystems. It was observed that it would indeed be useful to have an extensible AMBA based verification environment which can be tweaked minimally so that it can be reused for new systems or derivatives.
VIP manager Tushar Mattu of Synopsys describes how to program AXI-ACE VIP to generate error scenarios
VIP manager Tushar Mattu of Synopsys gives insights on how to effectively integrate uvm_reg with AXI VIP http://bit.ly/1xboMLS
Recently I worked with a user who was responsible for verifying an AXI interface. This user did not have a UVM background, but was conversant with SystemVerilog. The user was faced with the challenge of learning UVM as well as coming up to speed with an understanding of the VIP: both at the same time, under tight verification timelines. Figuring out how much UVM knowledge would suffice to integrate the VIP, then coding the testbench around the VIP to run and debug the verification environment, appeared to be the first few challenges. I proposed a simple approach: let us begin with a simple directed testbench, get some AXI tests going using the VIP, gain some confidence in terms of understanding the core functionality of the DUT and VIP, and then, in parallel, learn some UVM basics as well. Later, I suggested, he can move on to advanced testing using constrained-random verification where he will need more advanced UVM knowledge, for instance, the application of virtual sequences.