Wand Wires to be driven by Program Block and Module block > Forums

Forums

Subject: Wand Wires to be driven by Program Block and Module block

Posting to forums is available to community members only.
Login or Register

Rate this topic:

Author

Messages

mayank
Posts: 0
Online: User is Offline

3/29/2007 12:56 AM
Hi All, I have a design that have some bidirectional signals, driven one side by Verilog Module, next side by SV testbench. But signals should have a functionality of wand (wire-and) type only Both are interacting through SV Interfaces only. Three combinations I tried: from SV testbenchn, if I decleare logic a , b , it give errors inout port must be a net type when I declare them as wand a,b, and it give error while driving them through TB, it give error usage of 'intf_inst.b' inconsistent with 'net' object. when I declare with input and output types, it give error blocking and non-blocking assignments to heirarchical references in a program block are illegal What's the solution? Regards Mayank Sample code is as such 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

mayank
Posts: 0
Online: User is Offline

3/29/2007 5:24 AM
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Ύ] 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

TAM
Posts: 56
Online: User is Offline

3/29/2007 12:17 PM
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

mayank
Posts: 0
Online: User is Offline

3/29/2007 10:47 PM
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

TAM
Posts: 56
Online: User is Offline

3/30/2007 4:55 AM
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

mayank
Posts: 0
Online: User is Offline

3/30/2007 5:35 AM
Nice Suggestion Thanks Regards Mayank

TAM
Posts: 56
Online: User is Offline

3/30/2007 6:25 AM
Oops, sorry about the double post of the original source code there.

mayank
Posts: 0
Online: User is Offline

3/30/2007 10:38 PM
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

TAM
Posts: 56
Online: User is Offline

4/02/2007 7:18 AM
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?

Posting to forums is available to community members only.
Login or Register

Forums > Functional Verification > SystemVerilog > Wand Wires to be driven by Program Block and Module block