Wand Wires to be driven by Program Block and Module block

Or putting in simple terms, How to assign values to wire signal types of interface from a class object ??
i.e. how to make it possible to change class_intf_inst.a =0; by calling the function         p.change_interface();

As it is giving the error This or another usage of 'class_intf_inst.a' inconsistent with 'net' object

sample code is:

interface intf( input logic clock);
    wand a,b;
endinterface

program main (intf intf_inst);
     int count =0;
     class packet;
          virtual intf class_intf_inst;
          function new (virtual intf intf_inst);
                class_intf_inst =intf_inst;
          endfunction
          task change_interface;
              class_intf_inst.a =0;
          endtask
       endclass
      packet p =new (intf_inst);
 
 
initial begin
    while (1) begin
        #15;
        $display ( "program a = %b, b = %b ",intf_inst.a, intf_inst.b);
        p.change_interface();
        count = count +1;
        if (count >1000) $finish;
    end
  end
  assign intf_inst.b = count[0];
  assign intf_inst.a = 1'b1;
endprogram

task indp_task;
endtask


module top;
    reg data_value, clock;
    intf intf_inst (clock);
    main m(intf_inst);
    initial begin
          clock =0;
            forever begin
                  #10 clock = ~clock;
                  $display ("    top a = %b, b = %b ",intf_inst.a, intf_inst.b);
            end
    end
endmodule

Even though this is SystemVerilog, you still have to deal with some of the restrictions enforced by the underlying Verilog language itself. In that language, you cannot make behavioral assignments directly to a "net" type. A net type like wand can have multiple drivers. You can only make behavioral assignments to a single driver of the net. Then Verilog will resolve the multiple drivers into their final value.

interface intf( input logic clock);
wand a,b;
logic b_driver;

assign b = b_driver;

modport port (inout a,b);

endinterface

program main (intf intf_inst);
int count =0;
initial begin
while (1) begin
#10;
intf_inst.b_driver = 1'b1;

If you truely wanted the port to be bidirectional, you might want to put a control on the behavioral driver you are creating:

interface intf( input logic clock);
wand a,b;
logic b_driver,b_ctrl;

modport port (inout a,b);

assign b = b_ctrl ? b_driver : 'bz;

endinterface

Thanks Tam for your information. But in this case we are increasing the no. of wires in the interface (as we are adding logic type signals to be driven by SV TB),  which is not according to the standard or specification.

Any turn-arounds for it ?
Regards
Mayank

If you can't instantiate the external driver in the interface (which is a resonable restriction), then you'll have to instantiate it elsewhere, probably in the block that describes the dut's environment. This works:

interface intf( input logic clock);
wand a,b;

modport port (inout a,b);

endinterface

program main (intf intf_inst);
int count =0;
initial begin
while (1) begin
#10;
intf_inst.b = 1'b1;
count = count +1;
if (count >1000) $finish;
end

end
endprogram

module top;
reg data_value, clock;
intf intf_inst (clock);
main m(intf_inst.port);
assign intf_inst.a = data_value;

initial begin
clock =0;
forever begin
#10 clock = ~clock;
end
end
endmodule
% more testit.sv
interface intf( input logic clock);
wand a,b;

modport port (inout a,b);

endinterface

program main (intf intf_inst, output logic b_driver);
int count =0;
initial begin
while (1) begin
#10;
b_driver = 1'b1;
count = count +1;
if (count >1000) $finish;
end

end
endprogram

module top;
reg data_value, clock;

// External drivers for bi-directional pins
logic b_driver;
assign intf_inst.b = b_driver;
assign intf_inst.a = data_value;

intf intf_inst (clock);
main m(intf_inst.port,b_driver);

initial begin
clock =0;
forever begin
#10 clock = ~clock;
end
end
endmodule

Nice Suggestion
Thanks Regards
Mayank

Oops, sorry about the double post of the original source code there.

Fine. Do we have to keep passing  this output logic b_driver, all the way to class object instances and thier functions. For small designs its OK, but for bigger designs and testbenches, it will  become too cumbersome.  Where you are assigning by multiple object functions etc.

Any turn around for this ??

Regards

Fine. Do we have to keep passing  this output logic b_driver, all the way to class object instances and thier functions. For small designs its OK, but for bigger designs and testbenches, it will  become too cumbersome.  Where you are assigning by multiple object functions etc.

Any turn around for this ??

Regards

Oops sorry !! for triple post, including this post.

I'm sorry that you find this burdensome. But it is the way that the Verilog language works. If you have multiple drivers on a net, you will have to describe each of them and assign their values separately. You are going to have to "keep passing" something around to the different blocks of code that can change the driver's value. How does it differ between passing the resolved net or its external driver?