=============================================================================== 1076.1 Ballot Resolution Commitee Comment Resolution Report ------------------------------------------------------------------------------- CRR Number: 2 Topic Addressed: Predefined DOMAIN signal Related CRs: 4 (Hisashi Sasaki, Toshiba Corp., affirmative) 81 (Garland J. Bayley, Analogy, negative) 146, 147, 151, 163 (Steven Greenberg, Analogy, negative changed to affirmative) Relevant LRM Sections: 2.2, 4.3, 12.6, 12.8, 14.2 Resolution Status: Partly in review by balloters =============================================================================== Comment Reports Summary ~~~~~~~~~~~~~~~~~~~~~~~ ---------------------------------------------------------------------- CR004 I cannot trace the behavior of DOMAIN signal. Need more explanation. Proposed Resolution ~~~~~~~~~~~~~~~~~~~ It is better to separate the explanation for transient analysis, frequency analysis (noise analysis), etc. into the each simulation cycle. The unification to single simulation cycle for many analysis is not easy to read. Consistency with VHDL (digital) should be restricted to transient analysis, because the original simulation cycle is only related to transient analysis. ---------------------------------------------------------------------- CR081 Implicit signal domain is explicitly declared on line 3300. Proposed Resolution ~~~~~~~~~~~~~~~~~~~ Place comment symbol in front of the declaration. ---------------------------------------------------------------------- CR146 The definition of implicitly declared signal DOMAIN is defined explicitly. Proposed Resolution ~~~~~~~~~~~~~~~~~~~ The definition of implicitly declared signal DOMAIN needs to be commented out in the definition of Package STANDARD. The comment informs the reader of what DOMAIN is. ---------------------------------------------------------------------- CR147 There is no statement in the LRM that prevents the user from assigning to implicit signal DOMAIN Proposed Resolution ~~~~~~~~~~~~~~~~~~~ There needs to be a statement that forbids there to be a source for the implicit signal DOMAIN. There is such a statement for the implicit signal GUARD. In section 9.1, there appears the statement "The implicit signal GUARD must not have a source." ---------------------------------------------------------------------- CR151 It is hard to fathom what the original text was saying in "this rule also holds ... and also for the implicit signal GUARD ...". It is impossible for me to understand how the implicit signal DOMAIN could be added to this rule. It seems to be saying the implicitly declared signal DOMAIN must be explicitly declared. This seems to be a contradiction. Proposed Resolution ~~~~~~~~~~~~~~~~~~~ Either remove DOMAIN from the list or clarify how one explicitly declares an implicitly declared signal. ---------------------------------------------------------------------- CR163 Step i of the simulation cycle says: "i) If the value of the DOMAIN signal is TIME_DOMAIN, or if Tn = 0.0, the remainder of this step is skipped. Otherwise, the driver of the implicit DOMAIN signal is assigned one of the following waveforms: - TIME_DOMAIN after 0 ns if a time domain simulation will follow, or - FREQUENCY_DOMAIN after 0 ns if a frequency domain or noise simulation will follow. Then Tn is reset to 0.0. The next simulation cycle will be a delta cycle" The inference I draw is that if there are any delta cycles at time 0, then Tn will be 0. This means that the DOMAIN signal will not be reset. What you get is a relaxation cycle between analog and digital without the advancement of time with DOMAIN set to INITIALIZATION_DOMAIN. You only get this relaxation with zero delay models. I am not sure there is any benefit to having the INITIALIZATION_DOMAIN extend beyond the initialization phase. It may just lead to confusion. If this is needed for frequency or noise domain, then perhaps something special needs to be done for those cases. It is not clear anyway what it means to say "frequency domain or noise simulation will follow". Does this mean that simulation will proceed no further in time? If it were to proceed further in time, we would be simulating with DOMAIN set to FREQUENCY_DOMAIN. This can't be right. Proposed Resolution ~~~~~~~~~~~~~~~~~~~ Drop the "or if Tn = 0.0" from the condition of when step i is skipped. Clarify the meaning of "frequency domain or noise simulation will follow". =============================================================================== Analysis and Action Taken ~~~~~~~~~~~~~~~~~~~~~~~~~ The comment report CR004 appears to look for a rationale for the DOMAIN signal. The rationale can be found in the white paper on Initialization and DC Simulation in VHDL 1076.1 The purpose of the DOMAIN signal is to allow a user to write a model whose behavior is described by different equations during DC analysis (i.e., while finding the quiescent point), time domain analyses, and frequency domain analyses. This is why the value of the DOMAIN signal doesn't change until quiescence has been reached, which is when time is about to advance for the first time. As a consequence, the phrase "or if Tn = 0.0" is an important part of the definition and cannot be removed. Additional modifications to the DOMAIN signal are that it is now an explicit signal, and the name of one of the enumeration literals was changed from INITIALIZATION_DOMAIN to QUIESCENCE_DOMAIN, to avoid confusions with initialization phase. The behavior of the signal is completely described by the initialization phase and step i) of the simulation cycle. To clarify the issue, step i) of the simulation cycle has been reworded, and a note has been added to section 12.6 indicating that no user process can contain a driver for the DOMAIN signal. We have decided to keep a single definition for initialization phase and simulation cycle that is shared by the various analyses. Otherwise information would be duplicated, which is not in the style of the LRM because it is error prone. =============================================================================== Revised Definitions ~~~~~~~~~~~~~~~~~~~ section 2.2 remove DOMAIN signal everywhere section 4.3 at line 748 (123) remove DOMAIN signal section 4.3.1.2 at line 817 (239) remove DOMAIN signal section 12.6 at line 2083 (584) remove the word implicit after line 2087 (589) NOTE--Since the kernel process contains a driver for the DOMAIN signal, and since the type of the DOMAIN signal is an unresolved type, no other process can contain a driver for the DOMAIN signal. section 12.6.2 at line 2102 (640) remove DOMAIN signal at line 2111 (707) remove DOMAIN signal section 12.6.3 at line 2125 (735) remove DOMAIN signal at line 2130 (740) remove paragraph section 12.6.4 at line 2186 (808) remove first sentence [Rationale: the initial value of the DOMAIN signal is handled by an explicit initial value in its declaration] at line 2225 (865) remove the word implicit at line 2227 (867) - FREQUENCY_DOMAIN after 0 ns if the simulation cycle is executed as described in section 12.8 - TIME_DOMAIN after 0 ns otherwise section 12.8 will be handled in its entirety in another change request (see also CR044). section 14.2 at line 3298 (1287) *type* DOMAIN_TYPE *is* (QUIESCENCE_DOMAIN, TIME_DOMAIN, FREQUENCY_DOMAIN); [Rationale: INITIALIZATION_DOMAIN is causing a confusion because it extends past the initialization phase. An alternative could be DC_DOMAIN, but this is only correct if there are no initial conditions] at line 3300 (1289) *signal* DOMAIN: DOMAIN_TYPE := QUIESCENCE_DOMAIN; ===============================================================================