From assertion perspective ::
’ bind ’ allows us to keep design logic separate from the assertion logic . Designers do not like to see anything in RTL that isn’t going to be synthesized . ’ bind ’ helps in that direction
Consider following code ::
module designmodule ( da , db , dclk );
input da , dclk ;
output logic db;
always @( posedge dclk ) db <= da;
endmodule
module propertymodule ( pa , pb , pclk );
input pa , pb , pclk ;
property rc1;
pa |=> pb ;
endproperty
baseP:assert property ( @( posedge pclk ) rc1 ) else $display($time , " property fails ");
endmodule
[Q1] What’s the difference between following 2 Scenarios ::
// Scenario1 :: Using bind
module tb1;
bind designmodule propertymodule dpM ( .pa( da ) , .pb( db ) , .pclk( dclk ) );
endmodule
// Scenario2 :: Without bind
module tb2;
logic ta , tb , tclk;
designmodule DM ( .da(ta) , .db( tb ) , .dclk( tclk ) ) ;
propertymodule PM ( .pa( ta ) , .pb( tb ) , .pclk( tclk ) );
endmodule
One possible answer is Scenario2 applies to only specific instance of designmodule whereas with Scenatio1 applies to every instances of designmodule .
[Q2] Are there any further differences between the two ?
**Significance of instance created by ' bind ' construct ::**
Within Scenatio1 , an instance of propertymodule named ' dpM ' is created by default within every instance of designmodule .
By default in Verilog a module declaration in itself doesn't do anything ( unless it's top_tb ) , one needs to instantiate it for the logic defined within it to work .
Hence simply declaring propertymodule doesn't do anything , one needs to create an instance of propertymodule for the assertions to execute .
bind construct creates the instance of propertymodule for the assertions to trigger .
This explains the significance of instance name created by bind construct for assertion based logic .
**[Q3] For non-assertion based module / interface what's the significance of the instance name ?**