Subject: Re: Call for vote on IR1117 Date: Tue, 30 Sep 1997 17:38:20 -0800 From: "Stephen A. Bailey" I most emphatically disagree with this IR's resolution. If one is to remove oneself from reality and remain cloistered within protected ivy-covered halls, then the resolution is easy and perfect. The problem is that real users need to use VHDL to do real work. As such, the language needs to do reasonable things when presented with reasonable code. The original proposed resolution attempts to take the user into account. The ISAC recommendation only looks at the LRM as a _Bible_ handed down by some deity and blessed with intrinsic truth. In reality, we all know it is a pragmatic document which defines a good language but also contains many quirks which often frustrate the user. This IR unmasks one of those quirks. It deserves better treatment. All IR analysis and resolution work needs to take into account the user and whether or not the proposed resolution would make the users' life easier or not. The user benefits can then be weighted against language purity and LRM correct-by-construction concerns. Unfortunately, (I'm now being redundant), the ISAC analysis and recommendation only takes into account the later and leaves the user out in the cold. What overriding language purity or other concerns exist that would override the language ease-of-use issue in this case? I have no idea because none are presented. (I also see no recognition in the ISAC analysis and recommendation that certain VHDL vendors chose the "non-standard" interpretation. Why did they do so? Just to ensure that their products would fail the existing LRM compliance tests? I think not! The ISAC should not view any vendor or any given number of vendors as de facto defining the VHDL standard. However, some effort should be expended when different vendors have different implementations of an issue to determine why they do. And, the results of this analysis effort should be documented.) Finally, neither Peter, Phil nor anyone else should take this response personally. In the history of VHDL, academics have had plenty of support by other non-academic language purists. If we can't start to take the first baby steps at making VHDL an easier language to use (without unduly sacrificing language and model quality) with these IRs, then how can we hope to do anything more? What is the compelling language quality or model quality issue that requires the ISAC recommendation over the proposed resolution? Stephen Bailey ---------------------------------------------------------------- Subject: Re: Call for vote on IR1117 Date: Wed, 1 Oct 1997 02:37:31 -0400 From: "Philip A. Wilsey" >From: "Stephen A. Bailey" >Date: Tue, 30 Sep 1997 17:38:20 -0800 >Reply-to: stephen@srbailey.com >Priority: normal >X-mailer: Pegasus Mail for Win32 (v2.42) > >I most emphatically disagree with this IR's resolution. >If one is to remove oneself from reality and remain >cloistered within protected ivy-covered halls, then the >resolution is easy and perfect. shooting the messenger doesn't change the message. >The problem is that real users need to use VHDL to >do real work. As such, the language needs to do >reasonable things when presented with reasonable >code. The original proposed resolution attempts to take the >user into account. The ISAC recommendation only >looks at the LRM as a _Bible_ handed down by some >deity and blessed with intrinsic truth. In reality, we all >know it is a pragmatic document which defines a >good language but also contains many quirks which >often frustrate the user. This IR unmasks one of those >quirks. It deserves better treatment. however, in this case, the LRM is clear. regards, p. wilsey ---------------------------------------------------------------- Subject: IR 1117 - It's Legal! Date: Wed, 1 Oct 1997 10:33:34 -0700 (PDT) From: Bill Paulsen All, With regard to IR 1117, in which the following is said to be illegal because all other subelements of the signal s do not have drivers: p3 : process is -- illegal begin s(0) <= '1'; wait; end process p3; In my opinion the LRM clearly indicates that this process is NOT illegal. I think the original intent of the LRM is to permit examples like the above, and to be "user friendly". Hence, Peter Ashenden's recommendation to not change the LRM is good. The ISAC analysis of the problem is wrong. Those implementations that permit the above example are following the LRM correctly. Section 4.3.1.2, lines 196-198, of the '93 LRM says: "If a subelement of a resolved signal of composite type had a driver in a given process, then every scalar subelement of that signal must have a driver in the same process, and the collection of all of those drivers taken together constitute one source of the signal." This paragraph defines yet another way that drivers for a signal are to be created during elaboration. Note that the LRM in NOT defining an error condition here! Instead, the LRM is describing exactly how drivers on a signal are to be created. The other ways that drivers are to be created on a signal are: Through a signal assignment statement, as described in Section 12.6.1, first paragraph. By a signal being associated with an OUT or INOUT formal signal parameter in a subprogram call. A correct simulator tool should follow Section 4.3.1.2, and each subelement of s "must have a driver" in process p3. During elaboration, drivers in process p3 for all sublements of s must be created. (Don't forget, for all the other subelements of s which are not explicitly assigned to in the signal assignment statement, the driving values are from the default value of s.) Bill Paulsen Oct. 1, 1997 ---------------------------------------------------------------- Subject: Re: Call for vote on IR1117 Date: Wed, 01 Oct 1997 14:57:09 -0400 From: Peter Ashenden Steve, Thank you for your response. I regret that you found it necessary to use such a hostile tone in your reply. Please let us review the issue objectively. This issue has two aspects. The first is an interpretation of the current LRM. ISAC cannot change VHDL-93, it can only clarify and interpret the specification of that language. The analysis in IR1117 is that a process with a driver for any element of a resolved composite signal must have drivers for all elements. If a tool vendor does not enforce this, they are not compliant with the standard. Other tool vendors do enforce it and so are compliant. The second aspect is the question of whether to change the language in a future standardization round, as proposed by the issue author. You stated your view at the ISAC meeting in July, and we agreed to seek user input by posting to comp.lang.vhdl. I attached the posted message in the call for votes. Of the six responses I received, only one was in favour of the change. I interpreted this and the very small number of responses as an indication that the user community has no strong preference for the change. One argument in favour of the status quo is that a change to the language specification would require all compliant vendors to change their tools. Leaving the specification unchanged would require those non-compliant vendors to change their tools if they want to become compliant. The documents arrached to the call for votes did indeed present an argument against the change: The disadvantage of the proposed change is that is removes the ability of an analyzer to detect some errors of omission. If the modeller inadvertently omits assignments to some elements of a composite resolved signal, the analyzer would infer drivers for those elements. This is an argument in support of the underlying design philosophy of the language, that errors should be detectable as early as possible, preferably at analysis time. The respondent to the c.l.v post who was strongly against the change also argued on this ground. I hope you will take to opportunity to respond in an objective and professional manner. Thanks. PA ---------------------------------------------------------------- Subject: Re: IR 1117 - It's Legal! Date: Wed, 01 Oct 1997 15:11:27 -0400 From: Peter Ashenden Bill, > Section 4.3.1.2, lines 196-198, of the '93 LRM says: > > "If a subelement of a resolved signal of composite type had a driver > in a given process, then every scalar subelement of that signal must have > a driver in the same process, and the collection of all of those drivers > taken together constitute one source of the signal." > > This paragraph defines yet another way that drivers for a signal > are to be created during elaboration. > > Note that the LRM in NOT defining an error condition here! We discussed this interpretation at the meeting in Paris. The concensus there was that this paragraph IS defining a constraint on a model. We interpreted the words "must have a driver" as constraining, as opposed to words such as "has a driver", or "is defined to have a driver", which are prescriptive. The constraining interpretation is consistent with other uses of the word "must" in the LRM. Examples: In 1.1: "If a simple name appears at the end of an entity declaration, it must repeat the identifier of the entity declaration." In 1.1.1.2: "Moreover, the ports of a block may be associated with an expression in order to provide these ports with constant driving values; such ports must be of mode in." "The actual, if a port or signal, must be denoted by a static name (see 6.1 )." And so on. (The were just the first few I came across searching for "must". I continued searching through Chapter 1, and all uses were similar in sense.) These cases make it clear that the word is used in a constraining sense, not a prescriptive sense. Based on this argument, the model discussed in the issue report is indeed illegal. If we wanted to make it legal, we would have to change the language. I hope this clarifies the analysis. Cheers, PA ---------------------------------------------------------------- Subject: Clarification: vote on IR1117 Date: Wed, 01 Oct 1997 15:16:35 -0400 From: Peter Ashenden Dear colleagues, Just to clarify what you are asked to vote on for IR1117 - the analysis and recommendation in the IR, not the proposed change in the accompanying document. That was for information. I apologize for any confusion I might have caused. Cheers, PA ---------------------------------------------------------------- Subject: Re: Call for vote on IR1117 Date: Wed, 1 Oct 1997 16:16:21 -0800 From: "Stephen A. Bailey" > however, in this case, the LRM is clear. Then I guess my previous effort was wasted because the desired message was not communicated. I understand that the LRM is clear. The problem is that that is not *the* issue. The issue is one of ease of use for the user. Why can't the language specification change to create a driver for the entire basic encompassing the element(s) being driven? What harm does that do to the language? IMHO (and, based on the existence of other non-compliant simulators in this area, I would guess others agree), making the change provides a service to the user, who does not need to explicitly drive more subelements than necessary, without damaging the language. I wasn't trying to shoot the messenger. Quite the opposite, I want the messenger alive and well. My goal is to broaden the messenger's (and others') perspective. I was making, perhaps overly so, a major effort to get everyone to consider the user perspective when it comes to VHDL. We have a great set of people who do an excellent job reading, understanding and interpreting the LRM. Let's put some of that brain power into trying to assess language issues from the user perspective as well. There is nothing wrong with recognizing that there are points beyond those immediately raised by an IR's initial issue statement. It is not an infrequent occurrence that while analyzing an IR, the ISAC member(s) discover that there are other points. In fact, this specific IR was discussed in Paris and I made the point then that there are non-compliant implementations when it comes to this issue and that the reason(s) for the non-compliance needed to be investigated. Furthermore, I indicated the high likelihood that the non-compliant implementations would choose to remain non-compliant if the ISAC makes the recommendation that was put out to vote. I'm a reasonable person. If someone can make the case why replacing the ISAC recommendation put to vote with the IR's original proposed resolution (with appropriate changes to chap 4) would be damaging to VHDL or to the user, then I can be persuaded. In the absence of an analysis and recommendation that addresses the ease-of-use issue and the language/model quality issue (not just "is the LRM clear"), I have only my own analysis and judgment to rely on. And that judgment says we are not doing right by the user. Stephen Bailey ---------------------------------------------------------------- Subject: Re: Call for vote on IR1117 Date: Thu, 02 Oct 1997 10:18:56 -0400 From: Peter Ashenden Steve, Thank you for clarifying your message. May I propose that you vote on IR1117 as a question of interpretation of the existing LRM, and consider the proposed change as an input to the VHDL-98 restandardization? Cheers, PA ---------------------------------------------------------------- Subject: Re: Call for vote on IR1117 Date: Thu, 2 Oct 1997 10:39:26 -0800 From: "Stephen A. Bailey" > May I propose that you vote on IR1117 as a question of > interpretation of the existing LRM, and consider the proposed change > as an input to the VHDL-98 restandardization? What does that mean? I vote yes on the IR and then submit a new IR and (persuasively/forcefully) request that ISAC address it for VHDL-98? Is ISAC willing to take on additional requests for '98? If so, I have encountered another issue that is worth exploring for the same reasons. But, I suspect there will be reluctance, if not from within ISAC, then within VASG, to add items to the '98 list. In the 1117 case, there is an existing IR. So, nothing new is being added. Or is there a two step process where the 1st step is a "strict" analysis and recommendation for resolving IRs followed by a more general evaluation of IRs for additional language change considerations for VHDL '98? Or, something else .... Stephen Bailey ---------------------------------------------------------------- Subject: Re: Call for vote on IR1117 Date: Thu, 2 Oct 1997 11:33:33 -0800 From: "Stephen A. Bailey" > Of the six responses I received, > only one was in favour of the change. I interpreted this and the > very small number of responses as an indication that the user > community has no strong preference for the change. Unfortunately, (through no fault of yours) the return is too small and the method of sampling unscientific. Thus, we should not place an inappropriate weight to it. > One argument in favour of the status quo is that a change to the > language specification would require all compliant vendors to change > their tools. Leaving the specification unchanged would require > those non-compliant vendors to change their tools if they want to > become compliant. This is not an argument. It is a statement of fact. What did you wish to accomplish by making the statement? The only thing that comes to mind is to do whatever takes the least collective effort on the vendors part. However, this is problematic in two ways. First, there is no data to suggest that the number of compliant implementations is greater than non-compliant (leaving open the question of market share). Second, and more importantly, it would set the precedence of defining what is best for VHDL not by careful objective, rational analysis, but by strength in numbers. > The documents arrached to the call for votes did indeed present an > argument against the change: > > The disadvantage of the proposed change is that is removes > the ability of an analyzer to detect some errors of > omission. If the modeller inadvertently omits assignments to > some elements of a composite resolved signal, the analyzer > would infer drivers for those elements. > > This is an argument in support of the underlying design philosophy > of the language, that errors should be detectable as early as > possible, preferably at analysis time. The respondent to the c.l.v > post who was strongly against the change also argued on this > ground. This argument is problematic. Without knowing the designer's intent, how is one to know whether or not the designer failed to assign to all of the elements of the composite signal that he intended? In general, it is impossible for a tool to detect errors of omission (beyond syntax) because it only knows what a designer did, not what he intended to do. Therefore, the goal is unattainable. If viewed from the opposite perspective, one can make the argument that requiring all elements of the basic signal to be driven even though the designer only wishes to drive a proper subset of those elements is a violation of VHDL's documentation design goals. It obfuscates the fact that all of the logic embodied by the process defining the driver exists only to compute future values for specific elements. Now we are starting to discuss the analysis that I have said in previous messages was missing. The argument for making the change that I believe has the most weight is that we (VeriBest) were requested by users to make the change to be non-compliant because that was the behaviour that users expected and thought reasonable. I can find no argument that can trump what I learned as a teenager working in retail: "The customer is always right." I'm not saying the users should design the language, but in this case, I see no compelling reason not to accomodate their expectations. (BTW, while customers complained when we were compliant, none have done so since we changed. Again, more data should be collected from other vendors, users and their experience to complete the analysis of the issue.) Stephen Bailey ---------------------------------------------------------------- Subject: Re: Call for vote on IR1117 Date: Tue, 7 Oct 1997 14:48:15 -0800 From: "Stephen A. Bailey" I apologize for sending yet another email on this subject. However, I have identified another piece of data that should be considered when analyzing this issue and determining how to vote. By changing the ISAC Recommendation to modify the language such that a driver for the entire basic signal is implicitly created is consistent with how the language currently works in the closest analogue I can find. Specifically, if an entity declaration contains an INOUT, OUT or BUFFER mode port, then a source is defined for any actual signal associated with that port. Note, if this port is composite typed and resolved, a source is defined for all elements and all basic signals. This source exists whether the implementing architecture contains driver(s) (or sources via association with lower level ports) for the entire port, only some elements of the port or no portion of the port. In the case where the port does not have driver(s) or source(s) for each element, the simulator must implicitly provide the source value through some implementation mechanism. It is not a modeling error if the port has no drivers or lower level sources. Perhaps someone can explain to me how this situation differs from the "driving less than the basic signal" situation of IR 1117, but I currently see no essential distinction. Stephen Bailey ---------------------------------------------------------------- Subject: Re: Call for vote on IR1117 Date: Wed, 08 Oct 1997 10:19:36 -0400 From: Peter Ashenden Steve, You raise an interesting point, but unfortunately I can't find the LRM sections that support it. Specifically, I can't find a section that states that a source is defined for each basic signal. It would be helpful if you could cite the relevant sections. There are two aspects to consider in your argument. The first in what happens in the association between the port and the actual signal or signals, and the second is what happens within the entity. Consider the first aspect. In 4.3.1.2 lines 183-186, the LRM defines sources for a signal: A signal may have one or more sources. For a signal of a scalar type, each source is either a driver (see 12.6.1 ) or an out, inout, buffer, or linkage port of a component instance or of a block statement with which the signal is associated. For a signal of a composite type, each composite source is a collection of scalar sources, one for each scalar subelement of the signal. In the case under consideration (a composite resolved port), the port may be associated with one or more actual signals in the following ways: (1) It may be associated in whole with a non-resolved composite signal (2) It may be associated in whole with a resolved composite signal. (3) Subelements of the port may be associated individually or by slices with actual signals. In case (1), the paragraph quoted above specifies that there is a composite source for the actual signal, comprising scalar sources, one per subelement. In case (2), LRM 4.3.1.2 lines 190-195 specify that there is likewise a composite source for the actual signal, comprising scalar sources, one per subelement: If a subelement or slice of a resolved signal of composite type is associated as an actual in a port map aspect (either in a component instantiation statement or in a binding indication), and if the corresponding formal is of mode out, inout, buffer, or linkage, then every scalar subelement of that signal must be associated exactly once with such a formal in the same port map aspect, and the collection of the corresponding formal parts taken together constitute one source of the signal. If a resolved signal of composite type is associated as an actual in a port map aspect, that is equivalent to each of its subelements being associated in the same port map aspect. Case (3) has two subcases. (3a) The actual signals do not include any elements or slices of resolved composite signals. (3b) The actual signals include a subelement or slice of a resolved composite signal. Case (3a) is covered by 4.3.1.2 lines 183-186: there is a source for each actual signal. Case (3b) is additionally covered by 4.3.1.2 lines 190-195: the association list must include associations for all of the elements of the resolved composite actual signal, and these associations constitute a source for that signal. This is exactly analogous to the requirement that if there is a driver in a process for one element of a composite resolved signal, there be a driver for all elements. Now consider the second aspect, namely, what happens inside the entity. The resolved composite port of the entity is itself a signal (specified in 1.1.1.2 line 91). Thus all that we have discussed before about requirements for drivers for composite resolved signals applies to the port in this case. In summary, the notions of sources and drivers for signals are two related but distinct concepts. For composite resolved signals, the LRM currently states that a model must include whole sources. Such a source may take the form of associations with formal ports in an association list, in which case the model must include associations for all elements of the signal in that association list. Alternatively, such a source may take the form of drivers within a process, in which case the model must include drivers for all elements of the signal in the process. We have discussed the possibility of changing the language to relax the requirement relating to drivers. Now that you raise the question of sources, the proposed language change should extend to them as well, for consistency. The difficulty there lies in defining what it means to define an implicit source. Presumably, it would imply defining an implicit driver. Would you care to flesh this out? Cheers, PA ---------------------------------------------------------------- Subject: Re: Call for vote on IR1117 Date: Wed, 8 Oct 1997 09:10:41 -0700 (PDT) From: Bill Paulsen I think Steve has proposed a new way that drivers can be created. There is no VHDL syntax to create a create a driver. Instead, drivers are to be created during elaboration, following rules in the LRM. (Hence, my claim that "must have a driver" means that when only a part of a composite signal is assigned to, then it seems like a valid interpretation to create drivers for all subelements. There is no explicit way to write in VHDL that you want a driver. Driver is not an object class, and cannot be explicitly declared.) I think Steve is suggesting that the LRM be changed so that whenever a composite signal is assigned to, then there will be drivers for all subelements of the composite. Bill Paulsen ---------------------------------------------------------------- Subject: Re: Call for vote on IR1117 Date: Wed, 8 Oct 1997 14:54:01 -0800 From: "Stephen A. Bailey" In response to Bill Paulsen: I did not propose new ways to create drivers. I only said that: "In the case where the port does not have driver(s) or source(s) for each element, the simulator must implicitly provide the source value through some implementation mechanism. It is not a modeling error if the port has no drivers or lower level sources." However, read on ... In response to Peter Ashenden: > You raise an interesting point, but unfortunately I can't find the > LRM sections that support it. Specifically, I can't find a section > that states that a source is defined for each basic signal. It > would be helpful if you could cite the relevant sections. Thanks, Peter. You at least partially did it for me. > In the case under consideration (a composite resolved port), the > port may be associated with one or more actual signals in the > following ways: > > (1) It may be associated in whole with a non-resolved composite > signal > > (2) It may be associated in whole with a resolved composite signal. > > (3) Subelements of the port may be associated individually or by > slices with actual signals. > ... This is important information, but not the information that gets to the essence of the point I was making. The focus is not on how the actual is associated with the port. The focus is on the fact that the port has no drivers or sources. Yet, the port does define a source for the actual. Thus, that source must be taken into consideration in determining the value of the actual. So, the question is where does the value of that source come from? The LRM is clear as to what the value of the source is (it is the explicit or implicit default value of the port). But something somewhere in the tool must get that source value into the determination of the actual's value. It might be a contributing source for resolution, it might directly determine the actual's value (no resolution) or it might go through a conversion function first. One way to implement this is to create a dummy driver that supplies the initial value, but otherwise never has any transactions scheduled for it. I'm sure other ways exist. Also note that this is true for any undriven subelements of the port if the port is composite typed and driver(s) are defined for only a proper subset of all the port's elements. My point being that for consistency, if the LRM does not require the (entire) port to be driven or sourced in order for it to contribute a source value to the actual, then how is that different from not requiring the entire basic signal to be driven yet define the implicit driving values for the portion of the basic not driven? The appropriate LRM section is 12.6.2, specifically for the resolved case: "If S has no source, then the driving value of S is given by the default value associated with S (see 4.3.1.2). ... If S is a resolved signal and has one or more sources, then the driving values of the sources of S are examined." (Note: from the above wording, one could make the case that the LRM *requires* the creation of an implicit driver since the undriven/unsourced port must provide a "driving value" as a source of the actual signal.) > We have discussed the possibility of changing the language to relax > the requirement relating to drivers. Now that you raise the > question of sources, the proposed language change should extend to > them as well, for consistency. The difficulty there lies in > defining what it means to define an implicit source. Presumably, it > would imply defining an implicit driver. Would you care to flesh > this out? Thanks for pointing this out. I hadn't considered it when I made the previous post because it is a different, although related, issue. The difference is that to modify the LRM as you suggest is required for consistency, would introduce the concept of implicitly defined sources. While I've documented how the concept of implicitly defined drivers already exists in the LRM, I know of no corresponding existence of implicit sources. On the practical side, I believe it would be easier for a user to uncover model bugs related to implicit drivers than ones related to implicit sources. Otherwise, I'm not entirely happy with this difference either because no matter how you slice it, there are inconsistencies in the LRM. In this case, the inconsistencies all revolve around the fact that VHDL has not mechanism for grouping items into "atomic" objects for signals. Until it does, I don't think a comprehensive resolution is possible that eliminates all inconsistencies. Nonetheless, for reasons already stated, I believe the best resolution for this IR is to have a driver for the entire basic even if only part of the basic is assigned. The source issue can be left as is. Stephen Bailey ---------------------------------------------------------------- Subject: Re: Call for vote on IR1117 Date: Fri, 10 Oct 1997 15:48:11 -0400 (ADT) From: "Paul J. Menchini" Peter, > Attached is ISAC IR1117 for you to review and vote on. - YES, with comments In the short-run, do not change the LRM. (This may mean VHDL'98 is also unchanged in this arena.) However, given the debate, I think that this subject deserves a closer look. I haven't yet had the time do do it myself, but I think we should. Paul ---------------------------------------------------------------- Subject: vote on IR 1117 Date: Mon, 13 Oct 1997 15:13:20 -0700 From: cswart@analogy.com I vote YES in IR 1117 Summary: Problem with Composite Resolved Signal Even with all the heat this IR has generated I feel that the LRM is clear, that the error detection capability supplied by leaving the wording as is outweighs the ease of use issue.