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
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.