Saturday 3 December 2016

Mentors Graphics U2U Conference, Dec - 2 2016, Bangalore : Updates

Hi Readers,

  Attended Mentor Graphics User 2 User 2016 on Dec 2, Bangalore. Summarizing the same below

 U2U India got an outstanding response with houseful gathering of VLSI Engineers, Conference started  with Welcome speech by Ruchir Dixit, Technical Director,  on Congnitive shift to transformative Decisions - briefed on the adoption of new technologies , explained using some general examples as shown below.

 Figure 1: Ajay to Dhoni as wicket keeper for Indian cricket Team.

Later Walden Rhines, Chairman, given a keynote on Next wave of semiconductor Growth with actual data vs  predicted growth data  from previous years.

Industry keynote speech on "Make In India" is delivered by Kiron shah , MD , Velankani Group, he played a video which showed his achievements from last 9 months..from setting up plant to shipping etc..

Latter Attended sessions in Functional Verification Track. There were 8 papers in this session on Qformal, Veloce and QVIP etc..

We have presented 2 papers on Qformal from our company, I was co-author for one of the paper titled " Using Questa Formal Connect Flow to Improve Quality and Productivity".

  Figure 2:  U2U Slide 

We got an outstanding response from the audience, The full paper can be found in U2U archives shortly.


Conference provide lot of networking opportunities , met some old friends and made new friends as well, besides learning new technologies. wishing you to meet you again in next U2U - 2017.

Happy Reading..!

Vikas Billa 

Wednesday 26 October 2016

DVCon -16, USA papers are available now for download.

DVCon -16, USA papers are available now for download.

Please download our paper and presentation on "UVM_Events"

Please write to us for suggestions/comments.

Happy Reading,
Vikas Billa

Sunday 3 July 2016

Wednesday 22 June 2016

The Overlooked Gems of UVM : UVM Report Catcher, UVM Heartbeat and UVM Events

This paper is submitted for 53rd Design Automation Conference , please find the slides for the same.

1.       Report catcher file.

class error_report_catcher_c extends uvm_report_catcher;
  //new constructor
  virtual function action_e catch();
    if(get_severity() == UVM_ERROR && get_id() == "MON_CHK_NOT_VALID") begin
      return CAUGHT;
    else begin
      return THROW;
endclass : error_report_catcher_c


class invalid_test extends base_test_c;

  // report catcher to suppress errors
  error_report_catcher_c error ;
  /// \fn new_constructor
  /// \fn build_phase
virtual function void build_phase(uvm_phase phase);
      error = new();
      uvm_report_cb::add(null,error) ;
      // User configurations
      uvm_config_db#(env_config_c)::set(this, "*" , “env_cfg", env_cfg);
      // Calling the error sequence
      uvm_config_db#(uvm_object_wrapper)::set(this, “uvc.tx_agent.tx_sequencer.main_phase","default_sequence",valid_invalid_seq_c::type_id::get());
  endfunction : build_phase

endclass : invalid_test

Typically an ASIC or a SOC will have multiple resets and which adds other dimension to reset verification wherein verification engineer need to ensure that the modules in the chip react only to the desired resets and ignore others. On-the-fly reset must be taken into account by all the modules of testbench and housekeeping must be made accordingly.

Figure I is a representation of stimulus life-span and flow in a reset aware test-bench. Apart from reset agent, the Verification environment has two other agents which can be reset individually by applying agent1 reset or agent2 reset respectively, or simultaneously by applying a global reset. Reset agent from Figure I will be continuously monitoring the reset interface and triggers the reset event on successful capture of any of the above mentioned resets. All other components in the test bench will waiting for a respective reset even trigger.

 Here is how the 4 major components Drive, Monitor, Scoreboard and Sequences must behave on capturing the reset event:

1) Must not drive data under reset and wait until reset is removed.  (t4 from figure 1)
2) Must stop driving the bus and send item_done on reset application. (t4 from figure 1)
3) Must complete the transaction if there was no reset while the transaction is in progress.(t5 and t6 from figure 1)

1) Must be monitoring the bus and trigger report error for conditions on bus which are not expected under reset. (t4 from figure 1)
2) Must treat the bus data as invalid if a reset is applied in between a transaction. (t4 from figure 1)

1) On application of the reset all the FIFO’s must be flushed. (t4 from figure 1)

1) Immediately after reset the configuration sequence must be driven before driving any other sequence. (t6 from figure 1)

Reset is an important state of an IP and the test-bench needs to be designed to accommodate and handle this state. Here are simple steps with code samples to make your test-bench reset-aware:

Triggering interrupts from sequences:
As a part of stimulus

Triggering a global reset event:
global_reset_ev = cfg.event_pool.get(“global_reset”);
In case of Agent1 reset:          

Triggering an Agent1 reset event:
agent1_reset_ev = cfg.event_pool.get(“agent1_reset”);      

Triggering an Agent2 reset event:
agent2_reset_ev = cfg.event_pool.get(“agent2_reset”);      

In reset aware components: Components shall wait for respective interrupts and implement their reset behavior upon successful reception of interrupts.

forever begin : Reset_service
   fork   : capture_reset

The on-the-fly reset can be made more elegant by usage of customized uvm_phases, this approach is out of this paper scope.

Happy Reading ...!

Monday 20 June 2016

VLSI Workshop

I got an opportunity to speak with the budding engineers on VLSI and it's Job opportunities.

please click on the below link for the slides.

Workshop Slides

Workshop Pics:

Will upload the Audio soon.

Tuesday 14 June 2016

Handshake Mechanism : Driver or Sequence?

In this article, I am sharing my thoughts on whether the Response handling mechanism should be in Driver or sequence?
The most common form of sequence - driver use models is the scenario where the sequencer sends sequence item to the driver, which process the item to the pin level  protocol format and also the driver needs to respond to the pin-level information or send back the response to the sequence.

For example as shown in below figure the Protocol requires an ACK/NACK handshake from DUT after every 8 bits of data. Depending upon the Response the next set of action is taken place.

                                                                                                    Figure 1: Serial Protocol 

          For the above protocol format the state Machine logic is implemented in Driver. It is easy to have such a logic in driver than sequence. Let us discuss in detail.

Figure 2: State Machine Logic Implemented in Driver

 After analyzing, it was decided that for this protocol format the Response handling mechanism should be  in Driver than in sequence because of the following Reasons.

1) If we have Response logic in sequence, the user who uses the VIP has to have in-depth protocol Knowledge in writing sequences/test cases and sequence looks more complex and takes time in coding/debugging them.
Figure 3:  Handshake Mechanism: Response Control in Sequence

2)   If we have Response logic in Driver, coding the sequence will become simpler but the driver logic is complex and sometimes we may require more flags to control the logic which will be bit confusing.

                                    Figure 4:  Handshake Mechanism: Response Control in Driver

A good VIP implementation shall consider such scenarios and arrive at a trade-off based on the protocol requirements.

Monday 30 May 2016

System Verilog : Soft Constraints

 Soft constraints are default constraints which hold true until contradicted by another similar constraint.

Let us understand this concept with the following examples.

1.    We have a packet class with address variable, which is limited in between 10 and 100.

class packet;
  rand bit[7:0] address;
  constraint address_c {
    address inside {[10:100]};

program test();
  packet p;
  initial begin
    $display("address value is %0d" , p.address);

Output:  address value is 53

The output is 53 which is in between 10 and 100.

2.   Let us apply a inline constraint stating that address should be equal to 200.

class packet;
  rand bit[7:0] address;
  constraint address_c {
    address inside {[10:100]};

program test();
  packet p;
  initial begin
    assert(p.randomize() with { p.address==200;} );
    $display("address value is %0d" , p.address);

Output: Error

Error-[CNST-CIF] Constraints inconsistency failure, 19
  Constraints are inconsistent and cannot be solved.
  Please check the inconsistent constraints being printed above and rewrite

"", 19: test.unnamed$$_3.unnamed$$_1: started at 0ns failed at 0ns
                Offending 'p.randomize() with {
(p.address == 8'hc8);
address value is 0

The output is 0, here the randomization failed due to constraint conflict i.e. we have given an inline value for address which is out of the range i.e. in between 10 to 100, in such scenarios we need to switch off the corresponding constraints as shown below.

 class packet;
  rand bit[7:0] address;
  constraint address_c {
    address inside {[10:100]};

program test();
  packet p;
  initial begin
    assert(p.randomize() with { p.address==200;} );
    $display("address value is %0d" , p.address);

output: address value is 200

3.  Let us change the code slightly and use soft keyword before address variable in constraint block as shown below.

class packet;
  rand bit[7:0] address;
  constraint address_c {
    soft address inside {[10:100]};

program test();
  packet p;
  initial begin
    assert(p.randomize() with { p.address==101;} );
    $display("address value is %0d" , p.address);

output: address value is 101

In the above code there is no need to use additional constructs like constraint_mode(0) , here the inline constraint of {p.address == 101 } will have the priority and the solver solves this instead of above declarative constraint ( constraint address_c { soft address inside {[10:100]};  } )

These soft constraints can be used to check the error/illegal scenarios.
 So the output here is 101.

 Happy Learning.

 Please provide your feedback if any.

Vikas Billa

Thursday 31 March 2016

DVCON-16 Paper : A 360 Degree View of UVM Events : Presentation Slides

Paper A 360 Degree View of UVM Events

Presenting you the highlight slides for reference.

For full paper and presentation slide please do write to us.

Saturday 27 February 2016

Solar System and Verification IP

The right process for a verification IP development is planning, development and closure. These steps are compared with the planets of a solar system. Each step in VIP development is assigned with a planet as explained below.

Figure 1: Solar System

Solar System
Verification IP
Verification Plan
Agents Development
Testbench Development
Assertions and Functional Coverage Development
Test Cases Development
Regression and Debug
Fixing Testbench or Test cases
Coverage Closure
Release – User guide, Product Documents etc...

Table 1: Verification IP compared with Solar System

Further to above planets there are scary looking asteroids in solar system which are treated as bugs. These bugs may be DUT bugs or Testbench bugs.

                                        Figure 2:  Verification IP Development Steps

Thursday 14 January 2016

DAC - 15 : Poster Presentations

Please find the posters from the below link.

Paper Title: VIP Development Techniques – A view into Controlling Features Effectively

Link: VIP_Development_Techniques.pdf

Abstract:  VIPs offer range of benefits including reusability aspects, plug and play features and providing all the necessary hooks and functionalities in a single entity with a standard framework.

The standard framework (Driver, Monitor and Sequencer) has evolved over a decade as part of the methodology developments and enhancements.

We can argue that feature segregation between VIP components depends upon protocols/standards. However there are common aspects which one need to be aware of and are important for controlling the flow of information within and outside the VIP.

This paper presentation highlights some of those techniques focused on ACTIVE path (Interactions between driver and sequence item) of the Verification IP.

Paper Title: Developing Common UVM Testbench for Simulation and Emulation Platforms to Reduce Verification Effort Across Different Abstraction Levels

Link: Abstarction_Levels.pdf

Abstract: Today’s traditional verification flow involves verification at multiple levels of abstraction. So the testbench also needs to be adjusted/modified at different abstractions from transaction-level simulation, RTL simulation to hardware acceleration.

An ideal solution is to make use of an advanced, automated verification environment across different abstraction levels, which helps in enhancing the overall performance gain, productivity and faster verification closure.

Thanks for reading, please inbox me for any queries/suggestions

Friday 8 January 2016

DVCON -15 India : A Reusability Combat in UVM : Callbacks vs Factory

Please find the poster at the below  link


If you need full length paper or if you have any Questions please inbox me.