=============================================================================== 1076.1 Ballot Resolution Commitee Comment Resolution Report ------------------------------------------------------------------------------- CRR Number: 6 Topic Addressed: Frequency and noise calculation Related CRs: 21 (Mark Zwolinski, Univ. of Southampton, affirmative) 44 (Ernst Christen, Analogy, negative changed to affirmative) 69, 80, 82 (Garland J. Bayley, Analogy, negative) 211 (Georges Gielen, Katholieke Univ. Leuven, affirmative) 214 (Matthias Bauer, Siemens, affirmative) 215, 216 (Tom Kazmierski, Univ. of Southampton, affirmative) 219 (François Lemery, SGS-Thomson, affirmative) 220 (Jeffrey Wade Meyer, HP EEsof, affirmative) 244 (Ken Kundert, Cadence, negative) Relevant LRM Sections: 4.3.1.6, 7.6, 12.8, 14 Resolution Status: Partly in review by balloters =============================================================================== Comment Reports Summary ~~~~~~~~~~~~~~~~~~~~~~~ ---------------------------------------------------------------------- CR021 12.8 in the definition of analog extensions to VHDL includes reference to a noise analysis cycle and to a value of DOMAIN_TYPE called NOISE_DOMAIN. This value is not included in the definition of DOMAIN_TYPE in 14.2 NB Most of section 12.8 is missing from the integrated LRM, so this might be an editorial error. Proposed Resolution ~~~~~~~~~~~~~~~~~~~ The expectation that a VHDL-AMS simulator can perform a noise analysis is clearly stated (e.g. 12.4.6.5). Unless a NOISE_DOMAIN signal value exists, it is not possible to write noise models. Therefore the definition of DOMAIN_TYPE in 14.2 should include NOISE_DOMAIN. ---------------------------------------------------------------------- CR044 The description of frequency domain and noise analysis says at line 2345 that "this transformation is implementation dependent". This is wrong, everything related to these analyses is well defined by the language. In a number of places this section 12.8 refers to a value NOISE_DOMAIN for the DOMAIN signal. This is obsolete. The description of the steps is confusing as it could be interpreted that the linearized form is put in place before initialization. The title of the section is misleading since "analysis" has a specific meaning in VHDL. Proposed Resolution ~~~~~~~~~~~~~~~~~~~~ Replace this section by the following: 12.8 Frequency domain and noise calculation Frequency domain and noise simulation both use the small-signal form of the model obtained by applying either the frequency domain augmentation set or the noise augmentation set to the basic set and replacing each characteristic expression in the basic set by its linear form. The solution of this system of equations at a particular frequency yields the small-signal frequency domain or noise value for each of the quantities at that frequency. This calculation involves complex values rather than real values. The small-signal frequency domain values at frequency f are obtained by executing the following steps: 1. The model is initialized as described in section 12.6.4. 2. Simulation proceeds until the value of the predefined DOMAIN signal is FREQUENCY_DOMAIN after step d). 3. The simulation frequency is set to f. 4. The set of equations to be solved by the analog solver is determined as follows: - The frequency domain augmentation set is applied to the basic set. - Each characteristic expression in the basic set is replaced by its linearized form (see section 7.6). 5. The resulting (linear) system of equations is solved. Similarly, the small-signal noise values at frequency f are obtained by executing the following steps: 1. The model is initialized as described in section 12.6.4. 2. Simulation proceeds until the value of the predefined DOMAIN signal is FREQUENCY_DOMAIN after step d). 3. The simulation frequency is set to f. 4. The set of equations to be solved by the analog solver is determined as follows: - The noise augmentation set is applied to the basic set. - Each characteristic expression in the basic set is replaced by its linearized form (see section 7.6). 5. previous step 4. 6. previous step 5. 7. previous step 6. If the value of the predefined DOMAIN signal is FREQUENCY_DOMAIN, the predefined function FREQUENCY returns the value of the current simulation frequency; it returns 0.0 otherwise. It is an error if a call to the frequency function appears in an expression that is not part of a source aspect. ---------------------------------------------------------------------- CR069 I do not know analog simulation. Therefore, I have less chance of understanding the why and wherefore of the functions defined in this section. However, the description of the equivalent function is not clear enough for me to understand what it does. I do not understand why and "increment function" takes a difference. It is not clear to me whether or not these functions are to be in standard package or not. It seems to me that if they were to be in standard package, they would be generic (Ada meaning of generic) in their parameter and return types. However, VHDL does not have the generic capability of Ada. Furthermore, it does not appear to be the style of VHDL to have names such as EF, INCF, and PDF instead of EQUIVALENT, INCREMENT, and PARTIAL_DERIVATIVE. Proposed Resolution ~~~~~~~~~~~~~~~~~~~ Clarify the definition of these functions. Specify the level of their existence, e.g., are they in standard package or are the functional capabilities that the analog solver must have. Rename them in the style of VHDL. ---------------------------------------------------------------------- CR080 Line 2983 says that frequence cannot be called in a simultaneous statement. Lines 3309-3311 say it cannot be called at all by the VHDL user. Proposed Resolution ~~~~~~~~~~~~~~~~~~~ Make frequency more universally usable. ---------------------------------------------------------------------- CR082 According to the comments on lines 3309 to 3311, the frequency function cannot be called by the user. Therefore it should not be in standard package. However, the language definition gives the user no way to report the current frequency as he can report the current time with the function now. Proposed Resolution ~~~~~~~~~~~~~~~~~~~ Make the frequency function universally available. ---------------------------------------------------------------------- CR211 Need also frequency-domain description and modeling of analog circuits, for the ease of designers. ---------------------------------------------------------------------- CR214 I will approve the 1076.1 - Standard VHDL LRM - Analog and Mixed-Signal Extensions to VHDL 1076. I am not sure about the "Frequency Domain". It is not obvious to me how to use it for *Mixed* Signals. Perhaps the digital equivalent should be included. ---------------------------------------------------------------------- CR215 In the BNF definition for source-quantity-declaration: source-quantity-declaration ::= QUANTITY identifier-list : subtype-indication source-aspect ; the expressions in both SPECTRUM and NOISE clauses in source-sapect define the value of the declared source quantity only in the frequency domain: source-aspect ::= SPECTRUM *magnitude*-simple-expression , *phase*-simple-expression | NOISE *magnitude*-simple-expression (NB: underlined text (*text*, AV) denotes italics) However, each quantity must also have a value at each time point in a time-domain simulation. It woul also be useful to extend the range of source quantities and allow, in addition to spectral and noise source quantities, time-domain source quantities, i.e. quantities which represent time-domain excitations. Proposed Resolution ~~~~~~~~~~~~~~~~~~~ 1. Alter the BNF grammar for source-aspect as follows: source-aspect ::= [source-time-domain-aspect] [source-frequency-domain-aspect] source-time-domain-aspect ::= IS *magnitude*-simple-expression source-frequency-domain-aspect ::= SPECTRUM *magnitude*-simple-expression [ , *phase*-simple-expression ] | NOISE *magnitude*-simple-expression 2. Remove the second and third sentence in the paragraph beginning in line 434 (line 906 of draft, AV), section 4.3.1.6. 3. Add the following text at the end of the paragraph beginning line 434 (line 906 of draft, AV), section 4.3.1.6: The default time-domain magnitude in a source aspect is 0.0. Similarly, the default magnitude and phase in a source frequency domain aspect are 0.0. ---------------------------------------------------------------------- CR216 The last sentence in the paragraph beginning in line 434, section 4.3.1.6 (line 906 of draft, AV) stipulates that it is an error if the name of a source quantity appears in an expression in a source aspect. Note that a source quantity has an associated simultaneous equation whose left-hand side is the name of the source quantity and whose right-hand side is the source aspect. The above mentioned restriction prevents implicit equations for source quantities. However, implicit analog equations can occur elsewhere in VHDL-AMS and it would therefore seem sensible to allow them in source quantities. It should be noted that if the name of any quantity, not just the declared source quantity, appears in a SPECTRUM or NOISE clause, then the description may lead to a non-linear model and hence render the underlying frequency-domain simulation incorrect. This, however, is the subject of the semanic analysis in a specific VHDL-AMS implementation. The language definition is not concerned with the mathematical validity of the model. Proposed Resolution ~~~~~~~~~~~~~~~~~~~ Remove the last sentence in the paragraph beginning in line 434, section 4.3.1.6 (line 906 of draft, AV). ---------------------------------------------------------------------- CR219 The FREQUENCY DOMAIN simulation should be able to follow a TIME DOMAIN simulation and use the operating point found at any time. Proposed Resolution ~~~~~~~~~~~~~~~~~~~ Step i) If the value of Tn is 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. If DOMAIN was already equal to TIME_DOMAIN, the remainder of this step is skipped. - FREQUENCY_DOMAIN after 0 ns if a frequency domain or noise simulation will follow the initialization or time domain simulation. If DOMAIN was equal to TIME_DOMAIN or FREQUENCY_DOMAIN, the remainder of this step is skipped. Then, Tn is reset to 0.0. The next simulation cycle will be a delta cycle. ---------------------------------------------------------------------- CR220 The frequency domain and noise simulation extensions to the 1076.1 standard seem to be less flexible and powerful than the time domain aspects of the language. The noise analysis precludes any correlation between noise sources. This correlation is important in high frequency modeling and requires the specification of a complex correlation coefficient between two noise generators. The calculation of this correlation coeefficient requires complex math which is not supported by the language. Likewise the frequency domain analysis suffers from the lack of a complex data type. I realize that these issues were raised during the OPAL vs. JADE discussion, but I beleive that the language will suffer for the next 5 years because of this decision. The resulting standard (1076.1) looks like the noise and frequency domain analyses are an "unattractive appendage" to an otherwise well tought out language. However I believe that the standard needs to be ratified and approved as soon as possible. Hopefully my comments may be addressed in a future revision of the standard. ---------------------------------------------------------------------- CR244 Clocked analog circuits are periodically time-varying circuits, and so it is not possible to extract models that work in the frequency-domain from user-written descriptions of these types of circuits. Instead, special functionality has to be provided in the language, and that functionality must incorporate the frequency-domain model. This was done in the current proposal to a limited degree with the z-domain filters. However, these filters are too limited to represent practical clocked filters, such as those implemented with switched-capacitors. Proposals were presented in the LDC, but these proposals were ignored. Proposed Resolution ~~~~~~~~~~~~~~~~~~~ Since the requirements and objective documents clearly indicate that VHCD-AMS must provide these capabilities, we must reconsider the proposals that were made to the LDC and ignored. =============================================================================== Analysis and Action Taken ~~~~~~~~~~~~~~~~~~~~~~~~~ We have addressed the issues raised by CR021 in two parts. First, we have updated and fixed the definitions for frequency domain and noise calculation. In the draft LRM used for the ballot they were broken or absent. In particular, any reference to NOISE_DOMAIN has been removed: there is no such enumeration literal in type DOMAIN_TYPE, and none is needed. As additional changes to the definitions we have redefined the expression in the declaration of a noise source quantity to specify the power of the noise source rather than the magnitude. We also corrected the inconsistencies in the definition of the predefined function FREQUENCY. The corresponding modified definitions are included below. They also include a rationale for changing the semantics of a noise source quantity. In a second part we have created a summary of the capabilities of the VHDL 1076.1 language in the area of frequency domain and noise modeling. The summary includes examples demonstrating how to write noise models. Additionally, it documents the restrictions of the proposed solution. and it provides a rationale for the approach taken. The summary is also included below. This summary also addresses issues raised in CR211, CR214, CR220, and CR244. Section 12.8 has been completely reworked to address the issues raised in CR044. In response to CR069 we have made minor modifications to the definitions of linear forms in section 7.6. Specifically, we have moved unused definitions for linearity and independence to notes. We have not made any other changes because we believe that the purpose of the various functions to define the concept of the linearized form of an expression is clear from the context. What may not be clear is that the approach was chosen to be able to use the expression evaluation semantics of the VHDL language; the LRM traditionally doesn't provide a rationale. With respect to the names of these functions, they follow standard mathematical practices. In response to CR080 and CR082 we have modified the LRM language in sections 12.8 and 14.2 to remove the contradictions. However, it is not possible to make FREQUENCY universally available because the algorithms used in the majority of today's simulators do not support such use. Similarly, FREQUENCY cannot be called in a REPORT statement; in fact, this wouldn't make any sense because a report statement isn't present in the small- signal model used for a frequency domain calculation: it is eliminated as a consequence of linearization. In response to CR215, the only reason that source quantities are part of the language is that special treatment is necessary for small-signal sources. This proposal suggests to allow such sources also for large-signal analyses, specifically time domain. However, the necessary functionality is provided by the simple simultaneous statement. It is also not a good idea to "merge" a large-signal source with a noise source. No defaults are necessary in the current definition. In response to CR216, the restriction exists for definitional reasons, to avoid a confusion that otherwise might exist (and that seems to exist in this comment). When the characteristic expression corresponding to the source quantity is constructed as a consequence of the application of the frequency domain augmentation set or the noise augmentation set, the magnitude simple expression and phase simple expression are both evaluated, using the current values for the quantities. These values are the values at the quiescent point (because this is when the augmentation sets are applied). The value of a source quantity at that time is 0.0, so it is well defined. However, people seem to expect that it would provide a possibility to specify implicit equations including source quantities, which isn't the case. The issue raised in the second paragraph is related but the perceived problem does not exist. As just described, it is the value of the quantity that is used to construct the characteristic expression; the quantities don't appear any more in the characteristic expression. CR219 proposes to change the language definition to support frequency domain calculations not just at the quiescent point, but at any time. The Language Design Committee has discussed this issue at one of its meetings. The consensus was that it is sufficient to specify frequency domain and noise calculations at the quiescent point and leave it to tool implementations to provide such calculations at other points in time. The rationale for this decision was that the language definition should only cover a minimum functionality that satisfies the design objectives. This gives tool vendors the possibility to add value to their tools by providing such functionality, but does not make it mandatory for all implementations. Regarding CR244, the LDC has interpreted the design objectives to support lumped systems according to text books: support for systems that can be described by algebraic equations and ordinary differential equations. It has gone beyond this strict interpretation in two areas: - support for ideal delay, needed for compatibility with SPICE - support for ideal zero-order hold and z-domain transfer function, based on discussions at LDC meetings In each case it was imperative that complete semantics could be described for the extended functionality in all supported simulation regimes: DC, time domain, frequency domain. This has been accomplished for the ideal delay, ideal zero-order hold, and ideal z-domain transfer function. At the LDC meeting in November 1996 the balloter, a member of the LDC, suggested an extension to the syntax of the zero-order hold predefined attribute along with an informal suggestion of the intended semantics. However, an attempt to formalize the definition foundered when no closed-form frequency domain representation could be found after considerable effort by members of the LDC and outside experts brought in to consult on the problem. The balloter subsequently took on the action item to work out such a definition, but on March 3, 1997 he sent this note to the LDC: >Gentlemen, > I wrote up my proposal [ed.: on extending the syntax and semantics of the zero-order hold predefined attribute] > and in the process I was able to enhance it to >the point where it is surprisingly powerful and comprehensive. And that >causes a problem. Given my poor track record at getting my proposals >accepted by the LDC, I have decided not to submit it. It is simply too >valuable to expose to competitors given the poor likelihood that it would be >accepted as part of VHDL-A. > >So I am going to let the current proposal stand as it is. Even it its >current state, the proposal has considerable value. So I vote yes as >follows on the proposals: > >3.1: Kens proposal > >3.2: Yes > >Ken The LDC then voted and approved support for the ideal versions of ideal delay, zero-order hold and z-domain transfer function only, with a clear statement that extended functionality could be added at a later time, provided that closed-form semantics for nonideal effects in the frequency domain can be found. The BRC is not aware that such closed-form semantics exist, except through the email by the balloter who decided not to expose them. For these reasons the ballot resolution committee cannot pursue this issue further at this time. =============================================================================== Revised Definitions ~~~~~~~~~~~~~~~~~~~ section 4.3.1.6 at line 866 (394) source_aspect ::= *spectrum* !magnitude!_simple_expression , !phase!_simple_expression | *noise* !power!_simple_expression at line 908 (436) ... The type of the magnitude simple expression, phase simple expression and power simple expression in a source aspect must be that of the source quantity. ... [Rationale for defining a power simple expression instead of a magnitude simple expression: Each such magnitude simple expression would be the square root of some expression. Sqrt is defined in package math_real for a parameter of type real. This either would restrict the type of the noise source quantity to Real, or it would require the modeler to write his own sqrt function for the type of the noise source quantity. The modified definition using a power simple expression removes this issue: the sqrt function is applied to each scalar subelement of the power simple expression as part of noise calculation. section 7.6 at line 1426 (754) remove paragraph [Editorial: The content of this paragraph is attached as notes] at line 1434 (764) remove sentence "This expression is linear...". after line 1438 (768) NOTES 1--An expression E is linear with respect to a value bearing object whose name N appears in E if the value of PDF(N,V) is the same for any value V in the subtype of N. 2--An expression E is independent of an object denoted by N if the value of E is the same for any value V in the subtype of N. 3--The linearized form of an expression E is linear with respect to each quantity whose name appears in E. section 12.8 Replace in its entirety by the following: 12.8 Frequency domain and noise calculation The !small-signal model! is a set of characteristic expressions obtained by linearizing certain characteristic expressions of the model about a quiescent point. Frequency domain and noise calculation consists of the determination of the small-signal model followed by the calculation of the frequency domain value or the noise value for each quantity at a particular frequency. This calculation involves complex values rather than real values. The determination of the small-signal model involves the following steps: 1. The model is executed until the value of the DOMAIN signal is FREQUENCY_DOMAIN after step e). 2. The analog solver determines an explicit set of characteristic expressions. 3. Each characteristic expression in the explicit set and in the structural set is replaced by its linearized form (see section 7.6) with respect to all quantities whose names appear in the characteristic expression, evaluated at the values obtained in step 1. To calculate the frequency domain value for each quantity at a frequency F the simulation frequency is first set to F. Then, the frequency domain augmentation set is determined. Finally, the value of each quantity is determined such that the evaluation of each characteristic expression yields the value 0.0. The calculation of the noise values for each quantity at frequency F involves the following steps: a) The simulation frequency is set to F. b) The noise augmentation set is determined. c) For each noise source quantity in the model, the power simple expression is evaluated. d) For each scalar quantity in the model, one variable of the base type of the corresponding quantity is created in the noise kernel, and initialized to 0.0. e) For each scalar subelement Q of each noise source quantity in the model: 1. The characteristic expression whose tag denotes Q is replaced by the expression "Q - IEEE.math_real.sqrt(power)", where power is the value of the corresponding scalar subelement of the power simple expression of the noise source quantity evaluated in step c). 2. The value of each quantity is determined such that the evaluation of each characteristic expression yields the value 0.0. 3. The original characteristic expression replaced in step e.1 is restored. 4. For each scalar quantity in the model the square of the magnitude of its value is added to its corresponding variable. f) The value of each scalar quantity is set to the square root of its corresponding variable. The predefined function FREQUENCY returns the value of the simulation frequency. It is an error if a function call whose function name denotes the predefined function FREQUENCY appears in an expression that is not part of a source aspect. section 14 replace paragraph at line 3309 (1298) by - A function that returns the simulation frequency (see 12.8): =============================================================================== Frequency Domain and Noise Modeling Summary ====================================================================== Several comments attached to 1076.1 ballots raised questions about the capabilities of the language in the area of frequency domain and noise modeling. This is a brief description of these capabilities and a rationale. Additional information about this topic can be found in the white paper on "Frequency Domain Modeling and Simulation". 1. Frequency Domain Modeling ---------------------------- The capabilities supported by the extended language in this area were driven by the class of algorithms typically used in circuit simulators for this purpose. These algorithms are based on the small- signal model of the design and do not support general frequency domain modeling as it may be needed in very high-frequency applications such as microwaves. Therefore, the 1076.1 Language Design Committee has interpreted the corresponding design objectives DO7 and DO8 to mean SPICE-like capabilities for this release of the language, with suitable extensions that do not go beyond the capabilities of the target algorithms. A study group under the auspices of the VASG is already looking into extending the language to be more flexible in this respect. The language proposal includes three pieces that support limited frequency domain modeling capabilities. The first is the DOMAIN signal that can be used to write models that exhibit different behavior during time domain simulation, frequency domain simulation or while finding the quiescent point. Regardless of the domain, the behavior must be described as large-signal behavior, i.e. there can be no dependency on the simulation frequency and no expressions in the Laplace variable s. The following simple example of a time- dependent resistor demonstrates how this capability can be used. ENTITY rtime IS PORT (TERMINAL p,m: electrical); END ENTITY rtime; ARCHITECTURE demo OF rtime IS QUANTITY v ACROSS i THROUGH p TO m; BEGIN IF domain = frequency_domain OR now < 1.0e-6 USE i == v / 1.0e-6; ELSE i == v / now; END USE; END ARCHITECTURE demo; The second piece is the spectral source quantity. Such quantities were introduced in the language because any attempt to define a value for a quantity by means of a simultaneous statement with the intent to use this value for a small-signal analysis will fail as a consequence of linearization, i.e. the determination of the small- signal model. For example, the constant source model ENTITY csrc IS PORT (QUANTITY q: OUT real); END ENTITY csrc; ARCHITECTURE one OF csrc IS BEGIN q == 5.0; END ARCHITECTURE one; will constrain quantity q to 5.0 while finding the quiescent point and during a time-domain analysis, but linearization of the characteristic expression corresponding to the simple simultaneous statement will yield the expression q, i.e. the value of quantity q will be constrained to 0.0 during a frequency domain simulation. To get a nonzero value during a frequency domain simulation a spectral source quantity must be used, as demonstrated next. ARCHITECTURE two OF csrc IS QUANTITY qf: real SPECTRUM 1.0, 0.0; BEGIN q == 5.0 + qf; END ARCHITECTURE two; The semantics constrain the value of quantity qf to 0.0 except during a frequency domain simulation, when its value is constrained to 1.0. Linearization of the characteristic expression corresponding to the simple simultaneous statement yields the expression q - qf, which means that q will have the desired value. The semantics of expressions defining the value of a spectral source quantity guarantee that their evaluation yields, at each frequency, a constant value that will appear on the right hand side of the linear system of equations to be solved at each frequency. The value is constant because the expression is evaluated as a part of the determination of the frequency domain augmentation set. The expressions can include quantities other than source quantities, and function calls to the FREQUENCY function. This allows a modeler to describe stimulus that is frequency-dependent or whose value depends on the quiescent point (i.e. the DC operating point). The restriction of not supporting source quantities in these expressions intends to avoid a potential confusion on the part of the modeler: Since the value of each source quantity is 0.0 at the time the frequency domain augmentation set is determined, a source quantity appearing in such an expression would not have the effect that the modeler might have intended. The third piece supporting limited frequency domain modeling capabilities are the predefined quantities Q'Ltf, Q'Ztf and Q'Zoh. These quantities are documented in the draft LRM. The FREQUENCY function is restricted to being called in an expression in the declaration of a source quantity. This restriction is a consequence of the fact that general frequency domain modeling is not part of the scope of this version of the language. 2. Noise Modeling ----------------- The design objective DO9 relevant to noise modeling and simulation was interpreted by the Language Design Committee to require support for noise in both the time domain and the frequency domain. An analysis, documented in the white paper on "Frequency Domain Modeling and Simulation", yielded that no special language features are required for time domain noise modeling. For frequency domain noise the issues are quite similar to those discussed above. Therefore, the proposed solution for noise sources largely parallels that described above for spectral sources. For example, the model of a simple noisy resistor is ENTITY diode IS GENERIC (is0: real := 1.0e-14; rd: real := 0.1; n: real := 1.0; kf: real := 0.0; af: real := 1.0; ef: real :=1.0); PORT (TERMINAL p, m: electrical); END ENTITY diode; ARCHITECTURE one OF diode IS CONSTANT boltzmann: real := 1.3806226e-23; CONSTANT tk: real := 300.0; -- operating temperature in K CONSTANT vt: real := tk * boltzmann / 1.6021918e-19; QUANTITY v ACROSS i THROUGH p TO m; QUANTITY qth: real NOISE 4.0*boltzmann*tk/rd; QUANTITY qfl: real NOISE kf*abs(i)**af/FREQUENCY**ef; BEGIN ASSERT rd /= 0.0; i == is0 * (exp((v-rd*i)/(n*vt)) - 1.0) + qth + qfl; END ARCHITECTURE one; The expression in the noise source quantity declaration specifies the noise power (this is a recent change to the definition that simplifies noise modeling). The expression can include calls to the FREQUENCY function and quantities except source quantities. The expression is evaluated when the noise augmentation set is determined, which happens after the quiescent point has been determined. This allows noise spectra to be described that depend on the quiescent point and on the simulation frequency. Correlated noise sources can be described as shown in the following fragment: QUANTITY qns_common: real NOISE expression1; QUANTITY qns_1: real NOISE expression2; QUANTITY qns_2: real NOISE expression3; ... q1 == expression4 + qns_common + qns_1; q2 == expression5 + qns_common + qns_2; More complicated schemes, such as correlations with complex coefficients cannot be described because they are not supported by the target algorithms. 3. Frequency Domain Simulation for Event-driven Models ------------------------------------------------------ We are not aware of any algorithm that would support frequency domain simulation for general event-driven models. We are aware of algorithms to compute the frequency response of unit-delay and multi-rate models, but the VHDL language does not support such semantics. Given our interpretation of the design objectives we didn't plan to add them. For these reasons frequency domain and noise simulation in VHDL 1076.1 supports only the portion of the model described by simultaneous statements. However, we have introduced two predefined quantities Q'Zoh (a zero-order hold) and Q'Ztf (a z-domain transfer function) that will provide a modeler with limited capabilities to model switched systems. ===============================================================================