From clsi!rtpuv1!mench@uunet.UU.NET Thu Oct 11 15:11:00 1990 Return-Path: Received: from suntan.viewlogic.com by twix (4.0/SMI-4.0) id AA27650; Thu, 11 Oct 90 15:10:54 EDT Received: from uunet.uu.net by suntan.viewlogic.com (4.0/SMI-4.0) id AA26993; Thu, 11 Oct 90 15:09:41 EDT Received: from clsi.UUCP by uunet.uu.net (5.61/1.14) with UUCP id AA09130; Thu, 11 Oct 90 15:10:12 -0400 Received: from rtpuv1.UUCP by clsi.clsi.COM (4.0/SMI-4.0) id AA02510; Thu, 11 Oct 90 12:14:41 EDT Message-Id: <9010111614.AA02510@clsi.clsi.COM> Received: by rtpuv1 (DECUS UUCP w/Smail); Thu, 11 Oct 90 10:25:19 EDT Date: Thu, 11 Oct 90 10:25:19 EDT From: Paul Menchini To: oclive@Viewlogic.COM Subject: My comments on IR 95 Status: RO Gentlemen, I have looked over Doug's revision of 95 and have the following comments. 1. I suggest that the first four paragraphs of "VASG-ISAC Recommendations for IEEE Std 1076-1987" (the one that starts "In attempting ...", and the enumerated paragraphs) belong in "VASG-ISAC Analysis & Rationale." 2. I have a pedagogical problem with the first sentence of Doug's suggested replacement language ("For the purpose ...."). This is basically an editorial comment; it also may imply that the notion of basic signal can be used only with reference to the determination of driving values. This second point is the more serious one, for we may decide to use the notion of "basic signal" elsewhere in the LRM. If we were to forget to delete this editoral sentence, we may find ourselves debating "the son of 95" in a couple of years. 3. Finally, I have some questions regarding the third and fourth bulleted paragraphs under "The driving value of any basic signal B ...." I note that a linkage port is considered a source of B (see Section 4.3.1.2, paragraphs 7 and 8 on page 4-6). Is this a problem? In particular, what is the driving value of the formal part of the association whose formal part is a linkage port or subelement or slice of a linkage port? Also, I'm lost on the last sentence of the third bulleted paragraph: "The driving value of a formal port is obtained by evaluating ...." I'm not sure that I know how to interpret the clause starting with "using the driving value of the signal ...." Other than these comments, I think it looks pretty good. From dunlop@inmet.inmet.com Fri Oct 12 06:22:54 1990 Return-Path: Received: from suntan.viewlogic.com by twix (4.0/SMI-4.0) id AA01137; Fri, 12 Oct 90 06:22:52 EDT Received: from inmet.inmet.com by suntan.viewlogic.com (4.0/SMI-4.0) id AA28395; Fri, 12 Oct 90 06:21:28 EDT Received: by inmet.inmet.com (4.0/inmet.com) id AA15352; Fri, 12 Oct 90 06:21:38 EDT Date: Fri, 12 Oct 90 06:21:38 EDT From: dunlop@inmet.inmet.com (Doug Dunlop) Message-Id: <9010121021.AA15352@inmet.inmet.com> To: crc@synopsys.com, cswart@mentor.com, dunlop@inmet.inmet.com, hookway@decsim.enet.dec.com, larry@synopsys.com, mackey@a.isi.edu, mench@clsi.com, oclive@Viewlogic.COM, stank@ibm.com, uunet@vntage!anz.inmet.com Subject: Re: Paul's 0095 Comments Status: RO Here are my reactions to Paul's 0095 comments and a revision of the IR. > 1. I suggest that the first four paragraphs of "VASG-ISAC Recommendations for > IEEE Std 1076-1987" (the one that starts "In attempting ...", and the > enumerated paragraphs) belong in "VASG-ISAC Analysis & Rationale." Good idea. Done. > 2. I have a pedagogical problem with the first sentence of Doug's suggested > replacement language ("For the purpose ...."). This is basically an > editorial comment; it also may imply that the notion of basic signal can be > used only with reference to the determination of driving values. This second > point is the more serious one, for we may decide to use the notion of "basic > signal" elsewhere in the LRM. If we were to forget to delete this editoral > sentence, we may find ourselves debating "the son of 95" in a couple of years. I think the editorial sentence here is OK. It seems the introduction of this new concept needs some form of motivation. Of course, if in VHDL92 we extend the use of the new concept we will need to edit this section that motivates the idea. To me the second sentence "Basic signals are those whose driving values ..." is important in describing the intuition behind the idea and it needs to be preceded by a sentence that says we've got a new idea now. Specific suggestions for re-wording this introduction are welcome. > 3. Finally, I have some questions regarding the third and fourth bulleted > paragraphs under "The driving value of any basic signal B ...." I note > that a linkage port is considered a source of B (see Section 4.3.1.2, > paragraphs 7 and 8 on page 4-6). Is this a problem? In particular, what is > the driving value of the formal part of the association whose formal part is a > linkage port or subelement or slice of a linkage port? This is something left undefined by the language. I don't know if it is a problem or not. Out simulator does not allow use of linkage ports in the simulated model. I've added this as a potential outstanding issue in the long-term section. > Also, I'm lost on the last sentence of the third bulleted paragraph: "The > driving value of a formal port is obtained by evaluating ...." I'm not > sure that I know how to interpret the clause starting with "using the driving > value of the signal ...." This sentence is unchanged from the VHDL87 LRM. I agree the sentence is confusing. I think the intent is clear. I wanted to re-use as much existing LRM language as possible so it would be clear exactly what was changing here and what problems were being solved. I've added a remark about it in the long term-section. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% VHDL Issue Number: 0095 Classification: Language Definition Summary: Composite resolved signals undefined with subelement null transaction. Related Issues: Relevant LRM Sections: 2.4, 12.6.1 Key Words and Phrases: Null transaction, resolved signal, composite signal Current Status: ISAC-Approved ----------------------- Date Submitted: 1989/02/10 Author of Submission: Doug Dunlop Author's Affiliation: Intermetrics, Inc. Author's Post Address: 4733 Bethesda Ave #415 Bethesda, MD 20814 Author's Phone Number: (301) 657-3775 Author's Net Address: dunlop@inmet.inmet.com ----------------------- Date Analyzed: 1990/10/01 Author of Analysis: Doug Dunlop Description of Problem ---------------------- If a source of a composite guarded resolved signal has some subelement sources defined by a null transaction and some not defined by a null transaction, the LRM does not specify what should be passed to the resolution function for this source. Proposed Resolution ------------------- For each source of a composite guarded resolved signal the subelement sources must be either all determined by a null transaction or none determined by a null transaction. VASG-ISAC Analysis & Rationale ------------------------------ The problem described above does appear to be a flaw in the definition of the language. There are several possible ways of addressing this problem. First, the "partially null" source could somehow be passed into the resolution function. This approach is problematic because it introduces a number of difficulties such as how the resolution function would detect a partially null source and what value would be obtained if it read a partially null source. A second approach is to declare a partially null source to be completely null, i.e., the source would not be represented in the input to the resolution function. A disadvantage with this approach is that a partially null source can be viewed as an indication of suspicious behavior and is possibly a symptom of a model flaw. Hence we favor a third approach which is to declare a partially null source to be an error condition. Note that many vendors treat simulation-time errors by announcing the error, taking corrective action, and proceeding with the simulation. A reasonable corrective action in this case is to treat the partially null source as though it were completely null. In attempting to precisely state the desired semantics for resolved signals, the following additional difficulties have become apparent: (a) The definition of the driving value of a signal (LRM 12.6.1) does not accurately take into account composite resolved signals; in particular, no distinction is made between composite resolved signals and composite non-resolved signals. This seems contrary to the intent behind resolved signals. (b) The definition of the driving value of a signal does not explicitly cover register signals. Register signals are explained toward the end of LRM 12.6.1 but the definition of signal driving values is misleading since it does not distinguish these signals. (c) There appear to be two different definitions for the driving value of a resolved signal that has no sources. By the first element of the four- element list near the bottom of Page 12-10, the resolution function is not invoked for such a signal. But the fourth element of this list also seems to apply and in this case the resolution function determines the driving value of the signal. The way the list elements are worded suggests that it was the intent that this case be covered exclusively by the first list element. VASG-ISAC Recommendation for IEEE Std 1076-1987 ----------------------------------------------- The following is the proposed LRM-style wording to correct these problems. This text is intended to be a replacement for the LRM 12.16.1 paragraphs beginning "For a scalar signal S, ..." on Page 12-10 (including the four- element list), "For a composite signal R, ..." (which immediately follows), and "For any signal other than one declared with the signal kind *register*" (near the end of Page 12-11). For the purpose of defining the driving value of a signal, the notion of a basic signal is introduced. Basic signals are those whose driving values imply the driving values for all other signals. A basic signal is one satisfying the following properties: o It is either a scalar signal or a resolved signal, and o It is not a subelement of a resolved signal. The driving value of any basic signal B is determined as follows: o If B has no source, then the driving value of B is given by the default value associated with B (see Section 4.3.1.2). o If B has one source that is a driver and B is not a resolved signal (see Section 4.3.1.2), then the driving value of B is the value of that driver. o If B has one source that is a port and B is not a resolved signal, then the driving value of B is the driving value of the formal part of the association element that associates B with that port (see Section 4.3.3.2). The driving value of a formal part is obtained by evaluating the formal part, using the driving value of the signal denoted by the formal designator in place of the formal designator. o If B is a resolved signal and has one or more sources, the driving values of the sources of B are examined. It is an error if any of these driving values are a composite where one or more subelement values are determined by the null transaction (see Section 8.3.1) and one or more subelement values are not determined by the null transaction. If B is of signal kind *register* and all the sources of B have values determined by the null transaction, then the driving value of B is unchanged. Otherwise, the driving value of B is obtained by executing the resolution function associated with B, where that function is called with an input parameter consisting of the concatenation of the driving values of the sources of B, with the exception of the value of any source of B whose current value is determined by a null transaction. The driving value of any non-basic signal S is determined as follows: o If S is a subelement of a resolved signal R, the driving value of S is the corresponding subelement value from the driving value of R. o Otherwise (S is a non-resolved composite signal), the driving value of S is equal to the aggregate of the driving values of each of the basic subelements of S. NOTE: The definition of the driving value of a basic signal exhausts all cases with the exception of a non-resolved signal with more than one source. This condition is declared to be an error in Section 4.3.1.2. VASG-ISAC Recommendation for Future Revisions --------------------------------------------- (1) There are several potential issues related to the computation of signal driving values that are not addressed by this IR. These need to be reviewed with the next revision of the standard: (a) What is the driving value of the formal part of the association whose formal part is a linkage port or subelement or slice of a linkage port? Does it matter that this is not defined? (b) The definition above concerning an unresolved signal with one source that is a port makes use of the VHDL87 LRM sentence: The driving value of a formal part is obtained by evaluating the formal part, using the driving value of the signal denoted by the formal designator in place of the formal designator. As some find this sentence confusing, it should be reviewed. Clearly the intent is to take the driving value of the formal port (the formal designator), apply any type conversion on the formal side, and make this result the new driving value of the actual signal. (c) Is a REGISTER signal active when its last driver turns off? Would it be inconsistent if it were active at this point but yet its resolution function did not run? (2) Consider whether the V7.2 notion of "atomicity" should be put back in the language. Notice a V7.2 atomic signal is very similar to the notion of a "basic" signal discussed above.