Re: FW: [sv-bc] 0003605: UVM ubus example should not use controversial code with variable driven by mix of continous assignment and procedural assign

I've made a bit different workaround for this issue I use extra tmp 
variables conneted to dut instead using vif signals for read and write 
and then assign those tmp signal to vif signals in always processes - 
see modified dut instantation below:

reg read_tmp;
reg write_tmp;
always @read_tmp vif.sig_read=read_tmp;
always @write_tmp vif.sig_write=write_tmp;
dut_dummy dut(
     vif.sig_request[0],
     vif.sig_grant[0],
     vif.sig_request[1],
     vif.sig_grant[1],
     vif.sig_clock,
     vif.sig_reset,
     vif.sig_addr,
     vif.sig_size,
     read_tmp,
     write_tmp,
     vif.sig_start,
     vif.sig_bip,
     vif.sig_data,
     vif.sig_wait,
     vif.sig_error
   );

W dniu 8/7/2013 1:50 AM, Alsop, Thomas R pisze:
>
> Forwarding Steven and Brad's explanation and some suggestions Steven 
> made to fix this.  Thanks Guys! -Tom
>
> *From:*Steven Sharp [mailto:sharp@cadence.com]
> *Sent:* Tuesday, August 06, 2013 4:26 PM
> *To:* Alsop, Thomas R; Brad Pierce
> *Cc:* Arturo Salz
> *Subject:* RE: [sv-bc] 0003605: UVM ubus example should not use 
> controversial code with variable driven by mix of continous assignment 
> and procedural assign
>
> They might have been trying to create a multiply driven signal, but 
> there is no way to use a variable to do that.  Variables are either 
> updated with procedural writes, or they are treated like a "poor 
> man's" wire that can only be driven by a single continuous 
> assignment.  Mixtures or multiple drivers are forbidden because they 
> would not behave like a real wire.
>
> Your attempt to change this to a wire would allow it to be multiply 
> driven, but then a wire cannot be procedurally assigned through the 
> virtual interface.  Wires have to be continuously driven, and the 
> values of multiple continuous drivers then continuously resolved.
>
> To make this work, I think you would have to do something like the 
> following, which creates two continuous assignments driving the wire, 
> with one of the drivers using the value of a variable that can be 
> updated using the virtual interface. If you wanted the output port to 
> actually be able to drive a non-z value, you would need to add logic 
> to make sure that sig_read_driver was z any time the output port was 
> driving.
>
> interface iface;
>             logic clk;
> wiresig_read;
>
> logic sig_read_driver = 1'bz;
>
> assign sig_read = sig_read_driver;
>        endinterface
>
>        module dut(input clk,output reg xbus_read);
> initial xbus_read<=1'bz;
>             always @(posedge clk)begin
> xbus_read<=1'bz;
>                 $display("2: xbus_read<=1'bz");
>             end
>        endmodule
>
>        class C;
>             virtual iface vi;
>             function new(virtual iface i);
>                 vi=i;
>             endfunction
>             function drive;
> vi.sig_read_driver<=1; //write to sig_read_driver which drives sig_read
>                 $display("1: vi.sig_read<=1");
>             endfunction
>        endclass
>
>        module top;
>             iface iface_i();
>             dut uut(iface_i.clk,iface_i.sig_read);* //dut instantation 
> - continous drive of sig_read*
>             C c =new(iface_i);
>             initial iface_i.clk=0;
>             always #5 iface_i.clk = ~ iface_i.clk;
>             initial begin
>                 $display("START");
>                  $monitor($time,">>>>", iface_i.sig_read);
>                 @(posedge iface_i.clk)
> c.drive();
>                 @(posedge iface_i.clk);
>                 #1;
>                 $display("END");
>                 assert(iface_i.sig_read)else $fatal("fatal error");
>                 $finish;
>                 end
>
>        endmodule
>
> *From:*Alsop, Thomas R [mailto:thomas.r.alsop@intel.com]
> *Sent:* Tuesday, August 06, 2013 6:21 PM
> *To:* Brad Pierce
> *Cc:* Steven Sharp; Arturo Salz
> *Subject:* RE: [sv-bc] 0003605: UVM ubus example should not use 
> controversial code with variable driven by mix of continous assignment 
> and procedural assign
>
> Hold on, I see what I am missing Brad.  I didn't realize this was a 
> multiply driven port.  We do not do this that I know of here at Intel 
> unless we declare these buses to be wire types with the appropriate 
> pull strengths, etc...  Sorry, I completely missed that.  So really 
> the example needs to be updated so that it reflects the proper way to 
> model a high impedance driver.
>
> Would this be the appropriate change:
>
> interface iface;
>             logic clk;
> wire sig_read;
>        endinterface
>
>        module dut(input clk,output wire xbus_read);
> assign xbus_read =1'bz;
>             $display("2: xbus_read =1'bz");
>        endmodule
>
>        class C;
>             virtual iface vi;
>             function new(virtual iface i);
>                 vi=i;
>             endfunction
>             function drive;
> vi.sig_read =1;* //procedural drive of sig_read*
>                 $display("1: vi.sig_read =1");
>             endfunction
>        endclass
>
> Thanks!! -Tom
>
> *From:*Brad Pierce [mailto:Brad.Pierce@synopsys.com]
> *Sent:* Tuesday, August 06, 2013 2:59 PM
> *To:* Alsop, Thomas R
> *Cc:* Steven Sharp; Arturo Salz
> *Subject:* RE: [sv-bc] 0003605: UVM ubus example should not use 
> controversial code with variable driven by mix of continous assignment 
> and procedural assign
>
> Hi Tom,
>
> I don't know the reason for the LRM restrictions or if they are 
> sensible. According to 23.3.3.2,
>
> Procedural or continuous assignments to a variable connected to the 
> output port of an instance shall be illegal.
>
> If you're doing that, and it's working fine, then I'd suspect the LRM 
> is overly restrictive, or that there's a loophole for virtual 
> interfaces. In synthesis you would get a multiply-driven error, but 
> you wouldn't be synthesizing your testbench, and there's no problem in 
> simulation with multiply-driving.
>
> -- Brad
>
> *From:*Alsop, Thomas R [mailto:thomas.r.alsop@intel.com]
> *Sent:* Tuesday, August 06, 2013 2:41 PM
> *To:* Brad Pierce
> *Cc:* Steven Sharp
> *Subject:* RE: [sv-bc] 0003605: UVM ubus example should not use 
> controversial code with variable driven by mix of continous assignment 
> and procedural assign
>
> Hi Brad,
>
> By this definition every connection up through the module hierarchy is 
> a continuous assignment while at the leaf level module we drive these 
> signals with procedural assignments.  So we violate this everywhere in 
> our Intel designs.
>
> Thanks,
>
> -Tom
>
> *From:*Brad Pierce [mailto:Brad.Pierce@synopsys.com]
> *Sent:* Tuesday, August 06, 2013 2:11 PM
> *To:* Alsop, Thomas R
> *Cc:* Steven Sharp
> *Subject:* RE: [sv-bc] 0003605: UVM ubus example should not use 
> controversial code with variable driven by mix of continous assignment 
> and procedural assign
>
> Hi Tom,
>
> According to 23.3.3
>
> Each port connection shall be a continuous assignment of source to 
> sink, where one connected item shall be a signal source and the other 
> shall be a signal sink.
>
> I think this means that the output port connection in the following is 
> itself a continuous assignment.
>
>      dut uut(iface_i.clk,iface_i.sig_read);
>
>      //dut instantation - continous drive of sig_read*
>
> *module* dut(*input* clk, *output* *reg* xbus_read);
>
> -- Brad
>
> *From:*owner-sv-bc@eda.org <mailto:owner-sv-bc@eda.org> 
> [mailto:owner-sv-bc@eda.org] *On Behalf Of *Alsop, Thomas R
> *Sent:* Tuesday, August 06, 2013 2:01 PM
> *To:* sv-bc@eda.org <mailto:sv-bc@eda.org>
> *Cc:* Miller Hillel-R53776
> *Subject:* [sv-bc] 0003605: UVM ubus example should not use 
> controversial code with variable driven by mix of continous assignment 
> and procedural assign
>
> Question for the sv-bc team from a UVM bug that I own.
>
> Daniel Mlynek filed this UVM Users Guide bug awhile ago.  Looking more 
> closely at the code, I am not sure I agree with the fact that there is 
> any continuous assignment in here for the signal 'sig_read'.  I have 
> highlighted the relevant code below.  According to the latest LRM 
> clause 10.4, all cases of sig_read appear to be "triggered" 
> assignments.  Specifically the one that he calls continuous is the 
> instantiation of the dut, but in this case xbus_read is driven via an 
> initial block and within and always procedural block.  These are both 
> considered procedural assignments.  Am I missing something?
>
> http://www.eda.org/svdb/view.php?id=3605
>
> Thanks, -Tom
>
> Below code show the problem in UBUS.
> Variable sig_read is driven by both continous assignment in instance 
> port and procedural assignment via virtual interface.
> Such code is not currently officialy blocked by LRM but it is at least 
> controversial.
> Official example should not use such code pattern as good idea.
>
> interface iface;
>             logic clk;
> logic sig_read;
>        endinterface
>
>        module dut(input clk,output reg xbus_read);
> initial xbus_read<=1'bz;
>             always @(posedge clk)begin
> xbus_read<=1'bz;
>                 $display("2: xbus_read<=1'bz");
>             end
>        endmodule
>
>        class C;
>             virtual iface vi;
>             function new(virtual iface i);
>                 vi=i;
>             endfunction
>             function drive;
> vi.sig_read<=1;* //procedural drive of sig_read*
>                 $display("1: vi.sig_read<=1");
>             endfunction
>        endclass
>
>        module top;
>             iface iface_i();
>             dut uut(iface_i.clk,iface_i.sig_read);* //dut instantation 
> - continous drive of sig_read*
>             C c =new(iface_i);
>             initial iface_i.clk=0;
>             always #5 iface_i.clk = ~ iface_i.clk;
>             initial begin
>                 $display("START");
>                  $monitor($time,">>>>", iface_i.sig_read);
>                 @(posedge iface_i.clk)
> c.drive();
>                 @(posedge iface_i.clk);
>                 #1;
>                 $display("END");
>                 assert(iface_i.sig_read)else $fatal("fatal error");
>                 $finish;
>                 end
>
>        endmodule
>
>
> -- 
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean.
>
>
> -- 
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean. 


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.