RE: [sv-ac] hier reference as bind target

That may be so, but I don't see that implied in the LRM.

The LRM wording is

"If a bind_target_instance_list is present, the bind_instantiation is only inserted into the specified instances of the target scope."

It does not say how the "specified instances" are determined.

In fact, if we talk about "definition by example", then the example

"Example of binding a program instance to a specific instance of a module:

bind cpu: cpu1 fpu_props fpu_rules_1(a, b, c);

In the example above, the fpu_rules_1 instance is bound into the cpu1 instance of module cpu."

implies that there is only one such instance. It does not say something like "is bound into all instances of module cpu that are named cpu1."

Regards,
Shalom

> -----Original Message-----
> From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of
> Gordon Vreugdenhil
> Sent: Thursday, September 16, 2010 5:10 PM
> To: Bresticker, Shalom
> Cc: Daniel Mlynek; 'SV_AC List'
> Subject: Re: [sv-ac] hier reference as bind target
>
>
>
> On 9/16/2010 8:03 AM, Bresticker, Shalom wrote:
> > "for all instantiations of type target_module" that are found where?
>
> Globally -- that is what any module based bind does. The
> name list is just a qualification on the module based bind.
>
> Gord
>
>
> >
> > Shalom
> >
> >> -----Original Message-----
> >> From: Gordon Vreugdenhil [mailto:gordonv@model.com]
> >> Sent: Thursday, September 16, 2010 5:01 PM
> >> To: Bresticker, Shalom
> >> Cc: Daniel Mlynek; 'SV_AC List'
> >> Subject: Re: [sv-ac] hier reference as bind target
> >>
> >> I agree that the LRM does not clearly state the rules,
> >> but in the common spirit of "definition by example",
> >> the intent is pretty clear -- "for all instantiations
> >> of type target_module, if the name is in the list,
> >> do the bind".
> >>
> >> But the implications of that intent when applied
> >> to dotted names gets messy in a hurry.
> >>
> >> Gord.
> >>
> >> On 9/16/2010 7:43 AM, Bresticker, Shalom wrote:
> >>> I don't see that
> >>>
> >>> 1) bind target_module : i1, i2 checker ch1(a);
> >>>
> >>> is any better defined than
> >>>
> >>> 2) bind target_module : uut.i1, uut.i2 checker ch1(a);
> >>>
> >>> Daniel asked,
> >>>
> >>>>> A) should it be searched in $root?
> >>>>> B) Should it be searched in scope where bind is placed?
> >>>>> C) B and then A
> >>>>> D) should it be searched in whole design for path finishing with
> >> given hier paths?
> >>>
> >>> The same could be asked of (1) as well as of (2).
> >>>
> >>> I don't see that it is well defined in the LRM.
> >>>
> >>> I had assumed that the answer is (B), but now I am in doubt.
> >>>
> >>> Shalom
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf
> Of
> >>>> Gordon Vreugdenhil
> >>>> Sent: Thursday, September 16, 2010 4:22 PM
> >>>> To: Daniel Mlynek
> >>>> Cc: 'SV_AC List'
> >>>> Subject: Re: [sv-ac] hier reference as bind target
> >>>>
> >>>> Ah, sorry, I did misunderstand the question.
> >>>>
> >>>> The LRM is certainly not clear on how to interpret a
> >>>> hierarchical name in such scenarios. I don't think that
> >>>> was really ever the intent; in fact I would support a
> >>>> clarification that in this context only an "identifier"
> >>>> is allowed. That makes more sense to me in terms of
> >>>> intent and other interpretations of the path either
> >>>> reduce to trivialities or are so exceptional in terms
> >>>> of the LRM that I'd want a very thorough explanation of
> >>>> why such functionality is needed and exactly how it
> >>>> is interpreted.
> >>>>
> >>>> Gord.
> >>>>
> >>>>
> >>>> On 9/16/2010 1:03 AM, Daniel Mlynek wrote:
> >>>>> Unfortunatelly I have form my question not the way I wanted.
> >>>>> Lets start from the beginning:
> >>>>> There is a syntax in LRM allowing
> >>>>> 1) bind target_module : i1, i2 checker ch1(a); //simple names
> >> after
> >>>> :
> >>>>> or
> >>>>> 2) bind target_module : uut.i1, uut.i2 checker ch1(a); //hier
> >> names
> >>>> after
> >>>>> :
> >>>>>
> >>>>> The 1) option is well defined it should look for all instances
> with
> >>>> listed
> >>>>> names and bind a checked module into it if the instance is
> >>>> target_module
> >>>>> type. What should happened if the instance is not of
> target_module
> >>>> type is
> >>>>> controversial: -error, warning, ingore? IMHO ignore would be the
> >> best
> >>>>> solution otherwise in whole design the instance name would be
> >>>> reserved for
> >>>>> only one kind on modules
> >>>>>
> >>>>> The 2) case in not described in LRM at all. How should be the
> >>>> hierarchical
> >>>>> names in instance list searched:
> >>>>> A) should it be searched in $root?
> >>>>> B) Should it be searched in scope where bind is placed?
> >>>>> C) B and then A
> >>>>> D) should it be searched in whole design for path finishing with
> >>>> given hier
> >>>>> paths?
> >>>>>
> >>>>> DANiel
> >>>
> >>> -------------------------------------------------------------------
> --
> >>> Intel Israel (74) Limited
> >>>
> >>> This e-mail and any attachments may contain confidential material
> for
> >>> the sole use of the intended recipient(s). Any review or
> distribution
> >>> by others is strictly prohibited. If you are not the intended
> >>> recipient, please contact the sender and delete all copies.
> >>>
> >>
> >> --
> >> --------------------------------------------------------------------
> >> Gordon Vreugdenhil 503-685-0808
> >> Model Technology (Mentor Graphics) gordonv@model.com
> >
> > ---------------------------------------------------------------------
> > Intel Israel (74) Limited
> >
> > This e-mail and any attachments may contain confidential material for
> > the sole use of the intended recipient(s). Any review or distribution
> > by others is strictly prohibited. If you are not the intended
> > recipient, please contact the sender and delete all copies.
> >
>
> --
> --------------------------------------------------------------------
> 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.

---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

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