[sv-bc] Re: [sv-ec] Mantis 2721 -- binds to binds

It is not clear whether that breaks compatibility.  The 2005 LRM has:

    It shall be an error for a bind statement to bind a bind_instantiation
    underneath the scope of another bind_instantiation.

So clearly one cannot have a bind statement inside a bind_instance that
targets something in any bind_instance (including its own).  So theoretically
one could bind outwards into the "original" design but remember that in
2005 the **intent** was that bind was only to be used in binding assertion
modules to other code.  I don't think anyone intended to permit the
outwards effect.  If people are abusing bind in such ways, I don't
really have that much sympathy.

The entire bind intent has gone beserk due to the lack of care in the
original rules.

I am loathe to have that continue to grow and not be at very least
"localized" in some manner as I have suggested.

Gord.

Brad Pierce wrote:
> SV-BC and SV-EC,
> 
> This ballot comment #135 proposes
> 
>     "It should be an error if a hierarchy introduced by a bind statement has further bind statements."
> 
> I think requiring that error would break backward compatibility.
> 
> Agree? Disagree?
> 
> Breaking backward compatibility is sometimes necessary, for example, it's good that 1364 fine-tuned generate in 2005.  But we ought to have a strong justification for doing so.
> 
> -- Brad
> 
> ________________________________________
> From: owner-sv-bc@eda.org [owner-sv-bc@eda.org] On Behalf Of Brad Pierce [Brad.Pierce@synopsys.COM]
> Sent: Friday, June 12, 2009 4:16 PM
> To: SV_BC List
> Cc: sv-ec@eda.org
> Subject: [sv-bc] FW: [sv-ec] Mantis 2721 -- binds to binds
> 
> ________________________________________
> From: owner-sv-ec@eda.org [owner-sv-ec@eda.org] On Behalf Of Gordon Vreugdenhil [gordonv@Model.com]
> Sent: Monday, June 08, 2009 8:45 PM
> To: SV_EC List
> Subject: [sv-ec] Mantis 2721 -- binds to binds
> 
> Although we didn't talk about 2721 at this week's meeting, I
> understand that there was some discussion of it last week.
> I just wanted to express my personal opinion on this issue
> before next week since I'll miss that meeting as well.
> 
> Steven had some good comments in the mantis notes:
> 
>     The old sentence says that you cannot perform a bind into the
>     hierarchy created by an earlier bind. You could have this error
>     without having a bind statement in the hierarchy created by bind.
>     You could have a bind statement that creates an instance c in
>     instance b, followed by a second bind statement that tries to
>     create an instance d in the newly created b.c.
> 
>     The new sentence says that you cannot have bind statements inside
>     the hierarchy created by a bind statement. Such a nested bind
>     statement might not be binding into the hierarchy created by the
>     outer bind statement. It could be binding elsewhere in the design.
> 
> 
> I agree with Steven's observation that the two issues are
> distinct, but I'd like to have a common model when thinking
> about what you can do.
> 
> In terms of reasoning about the design composition, it seems that
> it makes the most sense to consider a bind statement as applying
> to the portion of the design created by the "bind".  I think
> this makes sense with the following:
>     1) if a bind statement exists in a context not created by
>        a bind, the statement applies to the part of the design
>        not created by binds.
>     2) if a bind statement comes into existence by a bind instance,
>        that bind applies to the part of the design created by the
>        bind instance but not any part of the design created by
>        other bind statements.
> 
> In a sense this is a "localization" rule -- if you think about
> a "bind" as being associated with a fixed "region" of
> design topology then my intent is to restrict the effect of
> a bind to the set of instances created in the same "bind region".
> 
> This perhaps deals with both aspects -- you can't have two
> bind statements in a "bind region" impacting each other (the
> first restriction) but you can have additional binds impact
> localized sub-hierarchy.
> 
> 
> I would NOT be in favor of completely allowing any form of bind
> statement in a sub-hierarchy created by bind.  Such binds could
> easily "infect" other portions of a design and any semblance of
> design composition would be lost.  If we are going to weaken
> the rules, I think we need to be pretty careful to preserve
> "region based" reasoning about the impact of binds.
> 
> 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.
> 

-- 
--------------------------------------------------------------------
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.