Hi all, I modified the proposal according to Gord's comments. Thanks, Dmitry -----Original Message----- From: Gordon Vreugdenhil [mailto:gordonv@model.com] Sent: Wednesday, September 05, 2007 6:34 PM To: Korchemny, Dmitry Cc: sv-ac@eda-stds.org Subject: Re: [sv-ac] Review of 1728 "Introduce let statement" in the light of Gord's comments Dmitry, If you want to allow generate blocks since they are within the listed constructs, then by the same reasoning, there is no scope in which a sequence/property can not be declared since ALL scopes are enclosed by the listed constructs. Generally in the LRM, a list such as the one given is understood as meaning "directly in the declaration list of", not "in any nested construct of". So, assuming that the intent was to allow generate blocks, I would list those directly. "Can" is the word to use here (see 1.3). Gord. Korchemny, Dmitry wrote: > Hi Gord, > > I checked the LRM and I found that this is exactly the language used for > sequences and properties, for example: > > A property can be declared in any of the following: > - A module > - An interface > - A program > - A clocking block > - A package > - A compilation-unit scope > > Should we change the wording in the entire Clause 16? Don't the > constructs listed above already include the generate blocks as their > parts? On one hand they do, on the other hand, always procedures are > part of modules, but you cannot declare a property there. > > BTW, should it be "A property *can* be declared in any of the following" > or > "A property *may* be declared in any of the following"? > > Thanks, > Dmitry > > -----Original Message----- > From: Gordon Vreugdenhil [mailto:gordonv@model.com] > Sent: Wednesday, August 29, 2007 6:08 PM > To: Korchemny, Dmitry > Cc: sv-ac@eda-stds.org > Subject: Re: [sv-ac] Review of 1728 "Introduce let statement" in the > light of Gord's comments > > 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 --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
This archive was generated by hypermail 2.1.8 : Sun Sep 09 2007 - 07:41:00 PDT