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

This restriction you quoted in the 2005 LRM is different from the restriction in 2721, so it definitely is not backwards compatible.

There is no question that customers are abusing binds in ways they were never intended to be used, but how would this restriction improve the situation?

Bind statements can be in generate blocks and can appear in modules that have generated instantiations, so unrolling generates can add binds to the design. Modules that are instantiated by bind can contain generates that need to be unrolled.

What is the harm in a module with bind instantiations containing bind statements or some module in the hierarchy underneath is containing bind statements? How would making this restriction prevent customers from "abusing" bind?

There are some significant questions about how bind is expanded. I just saw another bug report from a customer trying to use a bind instantiation to create an interface instance that was connected to an interface port in the non-generate design hierarchy. Is this suppose to be legal? Clearly some binds can go into generated instantiations, but binds that do not could be expanded before parameter values are finalized and the generate unrolling begins. Note that since modules can access parameters and types from module ports in constant expressions, the interface instance that is connected to an interface port must be instantiated before generates are unrolled. This is the reason 25.3 says:

"If the actual of an interface port connection is a hierarchical reference
to an interface or a modport of a hierarchically referenced interface, the hierarchical reference shall
refer to an interface instance and shall not resolve through an arrayed instance or a generate block."

It does not say it cannot be a bind instance, but so far I have been trying to tell customers that was an oversight in the LRM, and when it excluded generated instances, it meant to exclude bind instances too.

I'm not sure if other vendors allow this or not yet. If no one has allowed this, then it is not too late to forbid it. I know we currently do not enforce the restriction proposed in 2721 and I'm pretty sure we have customers using it already. That means that horse is already out of the barn. We will never be able to enforce that restriction, especially since there is no good reason for the restriction.


-----Original Message-----
From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Gordon Vreugdenhil
Sent: Friday, June 12, 2009 7:54 PM
To: Brad Pierce
Cc: SV_BC List; sv-ec@eda.org
Subject: [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.


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