[sv-ec] RE: [sv-ac] Name resolution for bind -- AC feedback requested

Hi Gord,

 

I have a question on your question. There are three pieces to a bind:

 

1. the bind statement

2. the target module/instance

3. the module to be bound

 

I think you may be confusing the bind statement with the module to be
bound. The bind statement does have visibility to all signals of the
target.  But the module to be bound only has visibility provided via the
ports listed in the bind statement. 

 

Example:

 

module my_target ();

     reg a, b, c;

     ....

endmodule

 

module my_module_to_be_bound (c,d);

     reg c, d;

     ....

endmodule

 

bind my_target my_module_to_be_bound my_inst_name(a,b);

 

This example is equivalent to:

 

module my_target ();

     reg a, b, c;

     ....

     my_module_to_be_bound my_inst_name(a,b);

endmodule

 

So the module to be bound has visibility to a and b only, since these
were ports in the bind statement. As with any other module that is
instantiated, if there are types defined, then you would need to import
those types in the module that you are binding and in the target module
since you cannot pass these definitions via ports.  So, I would state
that "This means that if a module that is to be bound bind

needs to explicitly reference types shared with the target instance,

such types would need to live in a package and be referenced

explicitly in the bind statement module that is to be bound."

 

Can you rephrase the questions below to clarify what part of bind you
mean?  Do you mean the bind statement or the module to be bound?

 

The basic questions are as follows:

   1) can a bind reference all visible names (including wild-card

      imports) of the target  

   2) can a bind reference compilation unit items from the

      bind target context

   3) can a bind reference types in the target context

 

 

Lisa

-----Original Message-----
From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of
Gordon Vreugdenhil
Sent: Tuesday, October 23, 2007 10:15 AM
To: SV_EC List; sv-ac@eda.org
Subject: [sv-ac] Name resolution for bind -- AC feedback requested

 

This note raises some name resolution questions in the

context of "bind".  The issues were discussed on Monday's meeting

with no consensus but no huge disagreements either -- we

just need to decide and clarify some of the text.

 

 

 

The name resolution group would request that AC review the

following and provide feedback immediately as clarifications

need to be made by EC before its deadline.

 

 

 

 

There are bits of somewhat contradictory wording in the LRM that

lead one to different conclusions in terms of what a bind

statement can refer to in the context of the target.

 

The bits of wording in 22.10 that are confusing are:

 

     No semantic changes to the assertions are introduced due to

     this feature. It is equivalent to writing properties external

     to a module, using hierarchical path names.

 

and

 

     When an instance is bound into a target scope, the effect will

     be as if the instance was present at the very end of the target

     scope. In other words, all declarations present in the target

     scope are visible to the bound instance.

 

 

The basic questions are as follows:

   1) can a bind reference all visible names (including wild-card

      imports) of the target

   2) can a bind reference compilation unit items from the

      bind target context

   3) can a bind reference types in the target context

 

 

Arturo believes that the original intent was that the names

referenced by the bind must actually be declared in that context.

Ignoring types, this roughly boils down to names that could be the

target of some hierarchical reference.  This is supported by

the first of the quoted statements above and is also what

my (Gord's) expectation was.

 

 

Mark H. wanted to make sure that everyone was Ok with that
interpretation

as it is somewhat contradictory with the "very end of the target" rule

which could be read as allowing reference to imports (including only

potential imports via a wildcard) and references to the compilation
unit.

 

 

There are various issues that arise if one does not restrict the

visibility to the "declared" items.  In particular, if one binds

into a nested module, having a new reference to a name could

cause problems due to bringing a new name into a scope via an

import.  This could cause a bind to *create* an error in the

target module.  We don't think that would be good behavior.

 

 

 

On the type reference issue, both Mark H. and I believe that

there are basic parsing issues that arise in terms of type

management.  We agree (I think) that types and explicit package

references must be parsed in the context of the bind statement,

not the context of the bind target.  This means that if a bind

needs to explicitly reference types shared with the target instance,

such types would need to live in a package and be reference

explicitly in the bind statement.  We do not think that this

compromises the intent or functionality of bind.

 

 

Gord

-- 

--------------------------------------------------------------------

Gordon Vreugdenhil                                503-685-0808

Model Technology (Mentor Graphics)                gordonv@model.com

 

 

-- 

This message has been scanned for viruses and

dangerous content by MailScanner, and is

believed to be clean.

 


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