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

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.

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