But Mark, you've just argued away the 2005 text. Per 2005 a bind stmt in a generate CANNOT target things in the whole design, merely in the whole design other than the bind_instances created after the rest of the design. So there already was in 2005 a concept of the "main" design and the "bound" instances. Binds could not target the latter. That is NOT impacted by generates and the like. Gord. Mark Hartoog wrote: >> The problem is that binds can target *modules* and not just instances. It >> is going to be a nightmare in terms of design consistency (component >> based design) if a later bind can "infect" an unrelated part of the >> design. > > Binds targeting "modules" can also be in generated blocks or in modules instantiated in generate blocks. So even with this restriction a later bind can effect unrelated parts of the design. In fact a bind targeting a module any place in the design can affect the whole design. That is the way bind works. > >> bind was never intended to be used for design composition. If that is >> changing, I think that it is imperative to have rules in place that >> restrict a bind in one area of the design (ie. a bound instance) from >> causes changes elsewhere. Otherwise it will be chaos. > > I agree that bind was never intended to be used for design composition. For RTL design, I do not expect synthesis tools to support bind, so I don't think this will be a problem there. If people want to use bind to compose their test bench, then that is not a use that was ever intended, but I don't see it as a reason for adding silly, unenforceable restrictions in the LRM that would not really prevent it, even if vendors did enforce it. > > I think it is better to deal with the issue of abusing bind through education of users. Perhaps there are some good sensible ways to use bind to "compose" a test bench. > > > -----Original Message----- > From: Gordon Vreugdenhil [mailto:gordonv@model.com] > Sent: Saturday, June 13, 2009 8:46 AM > To: Mark Hartoog > Cc: Brad Pierce; SV_BC List; sv-ec@eda.org > Subject: Re: [sv-bc] Re: [sv-ec] Mantis 2721 -- binds to binds > > > > Mark Hartoog wrote: >> This restriction you quoted in the 2005 LRM is different from the restriction in 2721, so it definitely is not backwards compatible. > > > It is different, yes. But since the existing restriction does cover > a subset (ie. you could not have any bind into a bind_instance no matter > where the bind statement was) and the intent was pretty obvious, I > don't want to make things worse. > >> 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? > > I am not worried about implementing the elaboration side. > > > The problem is that binds can target *modules* and not just instances. It > is going to be a nightmare in terms of design consistency (component > based design) if a later bind can "infect" an unrelated part of the > design. > > bind was never intended to be used for design composition. If that is > changing, I think that it is imperative to have rules in place that > restrict a bind in one area of the design (ie. a bound instance) from > causes changes elsewhere. Otherwise it will be chaos. > > Gord > > >> 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. >> > > -- > -------------------------------------------------------------------- > Gordon Vreugdenhil 503-685-0808 > Model Technology (Mentor Graphics) gordonv@model.com > -- -------------------------------------------------------------------- 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.Received on Sun Jun 14 21:45:27 2009
This archive was generated by hypermail 2.1.8 : Sun Jun 14 2009 - 21:47:37 PDT