SystemC is heating up in India – raise to the occasion and be part of this ecosystem

In the midst of a cold winter across India, there is some good news for those SystemC enthusiasts. While some in the industry thought the SystemC is being slow in adoption, there has been a constant need for moving up in abstraction in designing electronic systems. Over the past several years several ESL experiments have been carried out by local semiconductor/system companies in India. Incase you are deeply involved in this silent storm, here is your opportunity to broadcast your work as part of The Indian SystemC User’s Group (ISCUG). Abstracts are due by mid-Feb. See details at: www.iscug.in and you may download the CFP (Call For Papers from: http://www.cvcblr.com/downloads/iscug_CallForContribution.pdf

See you at ISCUG!

UVM and callbacks – a pragmatic application

Many users find the factory feature in UVM as quite satisfying and easy to use and believe callbacks are not needed in UVM. However callback is a popular design pattern in software domain (see: http://stackoverflow.com/questions/946834/is-there-a-design-pattern-that-deals-with-callback-mechanism).

It is infact one of the very nice things that came from VMM to UVM. Though it is not that often used in UVM as in VMM, there are some pertinent use cases that makes the callbacks very handy in UVM as well. For instance consider a recent customer requirement that we handled:

How to terminate Testcase on Max Error Count Reached?

Of-course UVM has this support, but little “hidden” (see http://www.cvcblr.com/blog/?p=203 for similar stuff on VMM). You use the function:

set_report_max_quit_count(2); // Quit after 2 errors

However in the context of “phasing” this “terminates/interrupts” the phasing rather “abruptly”. While the UVM developers believe this is fine as default behavior we see more and more users would rather have the “report_phase” execute even in such cases. This helps in having a comprehensive display of test failures, status etc.

The good news though is that such usage has been “predicted” by UVM (was present in VMM as well, infact with very similar use model of pre_abort).

The uvm_component base class has a pre-defined callback named pre_abort – its documentation is below:

umv_component::pre_abort()

Function: pre_abort This callback is executed when the message system is executing a <UVM_EXIT> action. The exit action causes an immediate termination of the simulation, but the pre_abort callback hook gives components an opportunity to provide additional information to the user before the termination happens.

 

So in our case we added:

function void custom_reporter();
  uvm_report_server server;
  `uvm_info (get_name, "Custom reporter..", UVM_MEDIUM);
  server = uvm_report_server::get_server();

  if ((server.get_severity_count(UVM_ERROR) +
       server.get_severity_count(UVM_FATAL)) > 0)
       fail_banner();
  else if (server.get_severity_count(UVM_WARNING) > 0)
       warning_banner();
  else
       pass_banner();
endfunction

function void pre_abort();
  custom_reporter();
endfunction

function void report_phase(uvm_phase phase);
  super.report_phase(phase);
  custom_reporter();
endfunction

Notice that we used a custom System Verilog function named custom_reporter and called it in the callback pre_abort. What is also shown above is that it can be shared by regular route – i.e. the report_phase.

In case you want to see a full working example, contact us via info@cvcblr.com and we would be glad to assist.

Have fun verifying with SystemVerilog, UVM & VMM and in case you need to get trained on any of these, check out: http://cvcblr.com/trainings