Dmitry, I really do appreciate the very serious attention that you and others have paid to my concerns and the significant effort that you have put into addressing those concerns. I have no substantive concerns with the current proposal. I did notice that in the list following: A let can be declared in any of the following: .... that generate blocks were not included. Given the example following in (d), I expect that was a minor oversight. Thanks again! Gord. Korchemny, Dmitry wrote: > Hi all, > > > > I had an action item to review Gord’s comments concerning the “let” > construct, especially how “let” interacts with the common SV elaboration > process. Gord’s comments were related to the original general proposal > and his comments have already been addressed in the updated version of > this proposal, which limits “let” usage to assertion area only. > Nevertheless, we would like to make sure that the current definition is > robust enough to allow potential backward compatible extensions in the > future. I am commenting below Gord’s notes from the point of view of the > backward compatibility and of the current definition problems only; I > leave his other statements uncommented even if I disagree with some of them. > > > > I compiled main Gord’s comments from different e-mails, and I hope I did > not miss anything significant, Gord is welcome to correct me if I did. > > > > Citation: > > > > The "let" construct is somewhere between a macro and a > > function. Allowing such a construct to participate > > arbitrarily through hierarchical references throughout > > the design is very troublesome. > > > > I have no substantial objection to "let" as an imported > > item from a package, nor to direct references to "let" > > in a local context. There are still some issues, but > > I think they are resolvable. > > > > End of citation > > > > DK: In the current proposal let is limited to packages or to the local > context only, and it is more similar to a macro than to a function. The > current definition should not prevent introducing hierarchical > references to “let” expressions in the future if decided. > > > > Citation > > > > Your working definition of "let" expansion following > > elaboration is extremely problematic from a large scale > > design standpoint. If one has very large sections of > > code that are separately compiled (in some vendor library) > > for which source is no longer available, it seems > > that a necessary restriction of implementations would > > be that hierarchical references to such "let" declarations > > would not be permitted. Such restrictions would ensure > > that no implementation is fully LRM compliant and that > > in real flows what users could expect to work would > > vary in an implementation dependent manner. Is that > > really a direction that everyone wants to follow? > > > > End of citation > > > > DK: This comment is related to the potential problems which can arise if > unlimited usage of hierarchical references to “let” expressions is > permitted. Whatever the limitation will be imposed to the hierarchical > reference if they are eventually introduced, the current definition will > remain backward compatible since the hierarchical references are > currently prohibited. I am dropping the remaining examples provided by > Gord illustrating problems with hierarchical references to “let” > expressions. > > > > Citation > > > > I understand that this problem already exists in the context > > of assertions constructs. I view "let" as being much > > more troublesome because it can interact with non-assertions > > contexts in widely different ways. It may be acceptable > > in an assertions context to have a somewhat restrictive > > model for implementation, but I am very concerned about > > such assumptions leak out into the general language. These > > assumptions, if encoded, can have a substantial impact > > on vendor models for separate compilation and how robust > > and flexible such models are over the language in general. > > > > End of citation > > > > DK: If “let” usage is extended in the future, all specific concerns will > have to be carefully examined. Hierarchical references to “let” will > introduce compilation performance penalty similar to that one introduced > by using parameters. This issue is not directly related to our discussion. > > > > Citation > > > > The assertions stuff is not in fact defined in terms > > of "inlining". It talks about the what the equivalent > > expressions are. A proposal like this should not > > introduce new terminology. > > > > End of citation > > > > DK: This instantiation semantics is discussed in 1549 for sequences and > properties. The “let” instantiation semantics is similar to that one of > the sequences. > > > > Citation > > > > By intent, Verilog talks about > > relationships between objects and *results* of elaboration. > > Requiring an *operational* model for generates would severely constrain > > implementations and would likely make various general flows that > > tools support considerably weaker. > > > > End of citation > > > > DK: If wanted to use “let” statement in a wider context: hierarchical > references, parameters and generate statements, one will have to define > the elaboration semantics. The current “let” definition should not > prevent choosing any backward compatible elaboration semantics (if this > has ever been done at all). > > > > Citation > > > > My comment was that requiring "inlining" and "declaration before use" > > is fundamentally at odds with the hierarchical name assumptions > > in Verilog. > > … > > So, why is there any "declaration before use" requirement whatsoever? > > > > If all of these follow full Verilog rules then you should not be > > trying to explain the name binding. If there are special restrictions, > > talk about them. > > > > End of citation > > > > DK: SV requires “declaration before use”, see 6.5 “Data must be declared > before they are used, apart from implicit nets”. Otherwise, they are > considered to be XMR (as in case of functions and tasks, for example). > “let” definition is consistent with this concept. Since we do not allow > XMRs “let”, “let” is required to be declared before it is used. > > > > Citation > > > > I simply do not buy the suggestion that has been made > > that "let" can both act like a function and act like a > > macro. I don't have any problem with having let be a > > "macro" like construct in packages where > > you are guaranteed to have visibility to the let body > > PRIOR to use. That was, I thought, what the key > > requirements were. Unfortunately, this has become > > seriously entangled in other constructs where the > > interactions are not nearly that simple. > > > > End of citation > > > > DK: In the current version of the proposal “let” body is visible prior > to use. I believe that this principle should remain if the proposal is > extended. Again, this will require defining the elaboration semantics. > > > > Citation > > > > The performance implications of implementing this > > (not to mention the semantics) for general cases makes > > me quite opposed to the generality of this proposal. > > > > End of citation > > > > DK: Generalizing “let” construct will introduce compilation performance > penalty similar to that one introduced by using parameters. But this > issue is not directly related to our discussion. > > > > Citation > > > > That is what I have been taking issue about -- the inlining > > semantics are simply not in keeping with the rest of the > > language and really indicate deep assumptions about elaboration > > which are simply not supported by the rest of the language nor > > play well with general language and flow interactions. > > > > … > > > > You (and others in AC) appear to have a particular *algorithm* > > in mind for elaboration. Things that fit the macro-like model > > for "let" AND fit the particular algorithm are valid while > > anything else is not. That appears to be driving your comments > > on generate, on bind, etc. > > > > Unfortunately, Verilog does *not* define elaboration algorithmically > > and any feature that requires such a definition is, as far as > > I am concerned, fundamentally flawed. That is part of why I > > claimed that other assertions constructs are flawed -- this isn't > > a simple "mantis bug" issue, but rather a fundamental misconception > > about how elaboration is defined and the relationships that must > > exist. > > > > As one specific example, there is nothing in Verilog that requires > > that generate loops be evaluated in order of declaration nor any > > requirement that the bodies be elaborated as part of index > > evaluation. One could evaluate just the loop header to determine > > the index set and then elaborate the loop body instances in any > > order whatsoever -- forwards, backwards, alphabetically, randomly, > > whatever. No approach would violate the fundamental relationships > > that exist. > > > > The reason that this works is that there are very carefully designed > > restrictions on the *relationships* between parameters, genvars, > > constant expressions, and hierarchical references that mean that > > you do not *need* to have an algorithmic definition of elaboration. > > > > It is apparent (to me) that the direction that is necessary to meet > > your assumptions is to define an algorithm for elaboration. I am, > > and will continue to be, strongly opposed to such an approach. The > > fact that the assertions sublanguage already appears to contain > > such assumptions is, in my mind, a fundamental flaw in the assertions > > language and not an aspect that I want to allow to pollute the > > rest of the LRM. Had there been sufficient time for review and > > redesign of the assertions sublanguage originally, I would have > > pushed very hard to ensure that the assertions constructs fit the > > rest of the language. I doubt there would be any willingness to > > re-examine those assumptions at this point so the best that I > > can do now from my perspective is to limit the damage of those > > assumptions. > > > > End of citation > > > > DK: Again, I don’t see how one can generalize let without defining a > (formal) semantics of elaboration. Our current definition does not cause > any of the issues Gord mentioned. > > > > Regards, > > Dmitry > -- -------------------------------------------------------------------- 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 Wed Aug 29 08:08:43 2007
This archive was generated by hypermail 2.1.8 : Wed Aug 29 2007 - 08:09:18 PDT