Mark Hartoog wrote: > 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. I don't entirely agree. This could have been handled in the user's code by adding a type parameter to the bound-in module and having the bind specify the type from the instantiating module. That would make everything work fine without having to have a priori knowledge of the type relationship via a package dependency. > 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. I agree. Gord. > > 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 <mailto:always@(y>) >> >> tmp[0] = a; >> >> y<=(!tmp[0]); >> >> end >> >> endmodule >> >> //======================================================== >> >> module i_x_t3 (input new_type x); >> >> new_type y; >> >> always@(x <mailto: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: >> http://www.eda.org/svdb/file_download.php?file_id=789&type=bug >> <http://www.eda.org/svdb/file_download.php?file_id=789&type=bug> >> >> We'd appreciate your insights if you see additional issues. >> >> Thanks, >> >> Karen > > -- -------------------------------------------------------------------- Gordon Vreugdenhil, Staff Engineer 503-685-0808 Model Technology (Mentor Graphics) gordonv@model.comReceived on Fri Apr 22 12:28:31 2005
This archive was generated by hypermail 2.1.8 : Fri Apr 22 2005 - 12:29:51 PDT