Jump to content

Recommended Posts

I am trying to extend uvm_cmdline_processor as follows, but my extended version, ivm_cmdline_processor is not working.  It seems like the *ref values* might not be getting passed correctly.  There is no error message.  The get_arg_values that is called with iclp is seen I know, because I receive a simulator warning about not using a void'() with the function.  (This warning occurs for both the uclp and iclp usages, as expected.)  I am not sure about my duplication of the get_inst function to create and return a singleton, but have tried versions of this code w/ and w/o it.

`include "ivm_cmdline_processor.svh"
module top;
   import uvm_pkg::*;

   ivm_cmdline_processor iclp;
   uvm_cmdline_processor uclp;

   string values[$];

   initial begin
      $display(">>>> START TEST.");

      iclp=ivm_cmdline_processor::get_inst();
      uclp=uvm_cmdline_processor::get_inst();

      iclp.get_arg_values("+",values);
      foreach (values[iii]) begin
        $display("iclp>>>%0d: %0s", iii, values[iii]);
      end

      uclp.get_arg_values("+",values);
      foreach (values[iii]) begin
        $display("uclp>>>%0d: %0s", iii, values[iii]);
      end

      $display(">>>> END TEST.");
   end
endmodule : top
import uvm_pkg::*;
class ivm_cmdline_processor extends uvm_cmdline_processor;

   static local ivm_cmdline_processor m_inst;

   static function ivm_cmdline_processor get_inst();
      if(m_inst == null) 
        m_inst = new("ivm_cmdline_proc");
      return m_inst;
   endfunction

   function new(string name = "");
      super.new(.name(name));
   endfunction : new

endclass : ivm_cmdline_processor
Reason for attempt:
I would like to add features to the uvm_cmdline_processor.  To start, I'd like to enhance +arg checking by checking that the +args supplied are from a list of valid +args.
 
Typos are too common from my fingers and without this functionality, typos go unnoticed.  (Once I even was in a different sim environment than I thought and was happily running a test with plusargs for a completely different testbench, wondering why things weren't working as I expected.)
 
I realize that I might create an object or 'shell', around uvm_cmdline_processor and do my checking in this 'shell'.  I have a version of this now, but I'd like to make it generic so that it may be used across 'all' testbenches.  Rather than polishing my shell, I am first trying to extend uvm_cmdline_processor and running into these problems.
 
Any ideas about this?
 
(I just discovered this next post from about 30min ago.  Thanks, Srini.  I think my problem is the same, but am not sure as I am not trying to 'mix' which handle (parent or child) points to my extended version of uvm_cmdline_processor.  Yes, I am confused about this.   re: http://forums.accellera.org/topic/1937-uvm-cmdline-processor-why-its-methods-are-non-virtual/ )

Share this post


Link to post
Share on other sites

Even if you extend the uvm_cmdline_processor, you can't replace the default one, because you can't override the original get_inst() static function (it's not virtual). This means you would anyway have to instantiate a parallel command line processor of your extended type. IMO, you're better of with the shell object that calls the methods of uvm_cmdline_processor. Pseudocode:

class my_plusarg_handler extends uvm_object;
  `uvm_object_utils(my_plusarg_handler)  // register it with the factory to be able to swap

  const protected uvm_cmdline_processor proc = uvm_cmdline_processor::get_inst();

  function new(string name = "my_plusarg_handler");
    check_plusargs();
  endfunction
  
  function int get_arg_value (string match, ref string value);
    return proc.get_arg_value(match, value);
  endfunction
  
  // export any other methods you need from uvm_cmdline_processor

  virtual function void check_plusargs();
    string plusargs[$];
    void'(uvm_cmdline_proc.get_plusargs(plusargs));
    
    // do your checks here (with regexes or whatever)
  endfunction

endclass

This way you can have an instance of my_plusarg_handler in your base test. If you have different lists of legal plusargs per test, then you can define subclasses of this class and override the check_args() function to reflect this and set a type override to this new class. More pseudocode:

class my_base_test extends uvm_test;
  my_plusarg_handler plusarg_handler;
  
  // boilerplate
endclass


class test_foo_plusarg_handler extends my_plusarg_handler;
  // boilerplate (registration, constructor)
  
  virtual function void check_plusargs();
    super.check_plusargs();  // do the general checks (if you need to)
    
    // implement your test_foo specific checks here
  endfunction
endclass


class test_foo extends my_base_test;
  // boilerplate
  
  // I'm assuming we're creating the handler in start_of_simulation or later
  // because we need the plusargs only during the run phase
  // but you can adapt this part to happen in an earlier phase
  function void end_of_elaboration(uvm_phase phase);
    set_type_override_by_type(my_plusarg_handler::get_type(), test_foo_plusarg_handler::get_type());
  endfunction

endclass

There was an old OOP maxim from the Gang of Four saying that you should favor object composition vs. object inheritance because it's more flexible and this is what we did here with the handler. Plus we also get to do factory overrides, something that wouldn't have been possible by just extending uvm_cmdline_processor.

 

I hope I understood your requirements correctly, if not, feel free to correct me and add some more details.

Share this post


Link to post
Share on other sites

hi,

 

if you just want to check the args then you dont need to override the cmdline processor. all you need are the arguments and you can get them anywhere. currently you cant override the cmdline processor.

 

btw: checking might be hard since not every +plusarg is for you. you might also consider that the oldstyle +plusargs (tool options) ala +incdir+... might have a dash variant (-incdir) during tool invocation. the difference between the two is that dash-args are checked which plus-args go unchecked (and then hope you dont have a typo).

 

/uwe

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...