Importing / exporting tasks via system verilog interface

Hello,

I have a legacy task in a module, which I want to be made available to a class.

The easiest way is to:

  1. create a task in a virtual interface.
  2. call the legacy task from this task using hardcoded paths.
  3. access this virtual interface’s task from a class.

The problem with the above approach is (2) hardcoding of paths.

Now I see the SV manual says that if you define a task as extern in an interface, you can import or export it via modports to other classes/modules. That way you won’t have to hardcode paths.

But the problem is extern isnt supported by questa 6.3d.

Do you guys have any ideas how to avoid hardcoding of paths?

Is there something in OVM which might help?

thanks,

Srishan.

Hi Srishan,

export/import in interfaces should work in Questa. AVM 1.0 used them extensively.

Your question might be answered by this previous [post=350]post[/post].

Dave

I have worked with several customers who have faced with the same issue. While creating reusable class-based uVCs with customers, I have used following technique that does not use extern functions. Being said that extern tasks/functions are supported in Incisive since then.

/*
* The goal of this example is to demonstrate how to reuse tasks/
* functions of a legacy VIP (module based TB) in a class based 
* TB. As you might have thought, the ugly way of doing this is
* to used OOMR in the CB-TB but then the CB-TB become 
* non-reusable.
*
* The main care about while doing this is not to use OOMR and
* have clean interface between CB-TB and MB-TB. OOMR are not
* acceptable because 
* (a) It breaks the reuse and scalability
* (b) if you have multiple instance of CB-TB and MB-TB then you
*     have to keep modifying interface definitions with new OOMRs
*     and some form of case statement to ID various instances.
*
* The cleaner way of doing this to create a wrapper BFM module that
* contains an "interface" and legacy BFM. The interface will define
* tasks/functions that will call tasks/functions from legacy BFM.
*/

module legacy_bfm;
  task automatic foo(input int x, output int y);
    y = x+1;
    $display("Lagecy BFM: got x=%0d, returning y=%0d", x, y);
  endtask // automatic
endmodule

interface mb_driver_if;
  task foo_if(input int x, output int y);
    bfm.foo(x, y);
  endtask 
endinterface 

module driver_wrapper;
  legacy_bfm  bfm();
  mb_driver_if ifc();
endmodule

module tb_top;

  class cb_driver;
    virtual interface mb_driver_if vif;
  
    function void set_vi(virtual interface mb_driver_if I);
      vif = I;
    endfunction // void

    task run();
      int y;
      vif.foo_if(53, y);
    endtask // run
  endclass // cb_driver

  driver_wrapper driver_wrapper_i();

  cb_driver cb = new;

  initial begin
    cb.set_vi(driver_wrapper_i.ifc);
    cb.run();
  end
endmodule // tb_top

Jigar,

It worked for me!
Many thanks for the simple and elegant solution.

-Srishan.

Can u please send me some example code for following steps.
I am ok with using hardcoded paths.
The easiest way is to:

  1. create a task in a virtual interface.
  2. call the legacy task from this task using hardcoded paths.
  3. access this virtual interface’s task from a class.
    Regards,
    Payal

Hello,
I have a legacy task in a module, which I want to be made available to a class.
The easiest way is to:

  1. create a task in a virtual interface.
  2. call the legacy task from this task using hardcoded paths.
  3. access this virtual interface’s task from a class.
    The problem with the above approach is (2) hardcoding of paths.
    Now I see the SV manual says that if you define a task as extern in an interface, you can import or export it via modports to other classes/modules. That way you won’t have to hardcode paths.
    But the problem is extern isnt supported by questa 6.3d.
    Do you guys have any ideas how to avoid hardcoding of paths?
    Is there something in OVM which might help?
    thanks,
    Srishan.