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.