RE: [sv-bc] Fwd: AW: Ballot feedback feedback

If you want to use types in a module that is bound into another module, these types need to be
defined in a package and imported into both modules. This can be somewhat incontinent. It may
require you to change the source code of the target module to move the type into a package. This
partially defeats the purpose of the bind statement, which was to insert the checker into the module
without changing the original source code.
 
Bind only creates an instance, it does not create a nested module. As far as I can see, the language
in 18.15 describes bind as creating a module, interface or program instance, and makes no mention of
nesting modules. 
 
Binds are handled during elaboration. What this seems to be asking is that the module I_x_t3 should
be reparsed as if it were a nested module inside its bind target during elaboration. While this
might be desirable from a usability point of view, I don't think this is technically possible.
 
Mark Hartoog
700 E. Middlefield Road
Mountain View, CA 94043
650 584-5404
markh@synopsys.com 

 
  _____  

From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Karen Pieper
Sent: Friday, April 22, 2005 10:05 AM
To: sv-bc@eda.org
Subject: [sv-bc] Fwd: AW: Ballot feedback feedback



Feedback from the entity describing the bind issue:




One example is shown attached. Here, a type
is declared in a module (here i_t3). In this module, a new type, call "new_type"
is declared.
 
Another module (i_x_t3) is bound to that module and uses the declared type
"new_type". An applicaiton example would be to sample that value for a later
check with an assertion.
 
As far as I remember, SystemVerilog requires, that a type must be declared before
its use. 
 
Now to the example: Assume, the bound module i_x_t3 is handeled like a
nested module at the end of module i_t3, then the new_type is declared
before, and is known to i_x_t3.
 
Assume however, that the i_x_t3 is handeled like a nested module inserted at
the beginning of the module, then type new_type is not declared at that
place. An error should be reported in that case.
 
To make this clear, I recommend, to define in the LRM, at which place a bound
module is inserted, and how the compile order of the bind statement influences
the place, the bound modules (in case there are more than one) are inserted.
 
 

//==========================================================

bind i_t3 i_x_t3 i_x_t3_inst(tmp);

//========================================================

module i_t3 (output logic y, input bit a);

typedef new_type logic[1];

new_type tmp;

always@(y)

tmp[0] = a; 

y<=(!tmp[0]);

end

endmodule

//========================================================

module i_x_t3 (input new_type x);

new_type y;

always@(x)

begin

  y = x;

   assert y = !x;

end

endmodule 
 
 
 
 


My letter requesting feedback:



        In the SV-BC, we are discussing one of your items: 

"bind" statement needs clarification according to the place the bound module, interface, program is
bound to. As an example: There is a program p with a type pt. Another program jap is bound to that
program p, and uses the declared type pt. This is only valid, if the type declaration is analysed
first, i.e. the jap program is "inserted" at the end of program p. Similarly, it must be specified,
how a set of bind statements is analysed. 

In the SV-BC, we believe that the ordering of bind statements is immaterial to understanding a
design.  Can you provide an example that demonstrates that this isn't so?

The committee has added language that defines that the bind statements are analyzed at the end of
the module.  The proposal can be found as added blue text in the attached html file on:

http://www.eda.org/svdb/bug_view_page.php?bug_id=0000627
The file:  <file:> http://www.eda.org/svdb/file_download.php?file_id=789
<http://www.eda.org/svdb/file_download.php?file_id=789&type=bug> &type=bug

We'd appreciate your insights if you see additional issues.

Thanks,

Karen