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

"for all instantiations of type target_module" that are found where?

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.

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