IEEE PAR 1076.1 VHDL Analog Extensions VHDL-A Design Objective Document Version: 2.3 Date: 6 sep 95 Document history: 2.3 27 oct 95 Alain Vachoux Integration of comments from vote on version 2.2: - corrected spelling and punctuation errors - DO14: reformulated design objective - DO18: improved rationale - DO29: new rationale from DOR - DO32: improved rationale - DO33: new formulation based on functionality rather than on a possible solution changed "logical states" to "values" (from Oct. 95 DASC meeting) - DO35: improved rationale - corrected cross-references between DOs and DRs. 2.2 23 jun 95 Alain Vachoux Integration of comments from first working group vote: - modified DO7 and DO8 - new DO9 (old DO9 is now DO9b) - new DO7b and DO8b - new formulation of DO36; corrected reference to DO28 - corrected cross-references between DOs and DRs - corrected misspelled words and badly formulated sentences 2.1 8 nov 94 Alain Vachoux, with Dan Fitzpatrick and Richard Shi Integration of comments about version 2.0. New consecutive numbering scheme. No more comments. In each section, design objectives are listed in the following priority order: must, should, and desirable. Version subject to ballot within the working group. 2.0 25 aug 94 Alain Vachoux, with Dan Fitzpatrick and Richard Shi Integration of comments from the reflector (discussion on March 1994 and following first language architecture team meeting in July 1994). New DOD structure. 1.6 23 feb 94 Dan Fitzpatrick, with Richard Shi and Alain Vachoux New version submitted to the 1076.1 reflector for comments. 1.5 feb 94 Dan Fitzpatrick, with Richard Shi and Alain Vachoux -1.2 Internal revisions following IEEE DASC meeting of January 94 in Tempe, AZ. 1.1 2 mar 93 Alain Vachoux Add new appendix A with consolidated list of submitted requirements, prepared by Mart Altmae and Kevin Nolan. 1.0 30 nov 92 Alain Vachoux Revised following meetings at DAC (Anaheim, June 92), EuroDAC (Hamburg, September 92) and IEEE DASS (Washington DC, October 1992). New document structure to highlight and to number the design objectives. 0.2 11 may 92 Robert Cottrell Revised following meeting at European VHDL Forum in Santander, Spain, 28 apr 92. 0.1 2 apr 92 Hazem El Tahawy Initial version prepared by Bergé, El Tahawy, Rodriguez and Rouquier. 1. Introduction --------------- The Design Objective Document (DOD) is a document that aims to serve as the basis on which the design of analog extensions to VHDL is performed. This work is done within the PAR 1076.1 standardization activities and it will produce a separate VHDL norm, called VHDL-A. The DOD was built from a list of design requirements submitted to the PAR 1076.1 for analog extensions to VHDL. The complete list of these requirements was collected by Mark Altmae and Kevin Nolan from separate European and North American requirements. The list of relevant requirements, further called Design Requirements (DR) in this document, is recalled in annex A of this document. Design requirements should be met by VHDL-A and are the focus of the language design activity. With justification, design requirements can also be postponed or discarded. The DOD contains a list of numbered Design Objectives (DO). A design objective has to be studied and possibly implemented in order to verify or improve its functionality. The general format of a DO is: ( ) where DO_number is of the form DOX, X = 1,2,... DO_classification is one of the keywords: *must*, *should*, or *desirable*. The meaning of these keywords are: *must* The objective is a basic fundamental requirement and cannot be compromised. *should* The objective provides useful functionality beyond the basics and provides significant benefits if met. Unmet *should* objectives can be used as a basis for requirements in subsequent re-standardizations. *desirable* The objective will enhance the usability and/or performance of the design. However, if not met, overall performance will not be severely compromised. Additionally, desirable objectives are to be used as a basis for new requirements in subsequent re-standardizations. DO_formulation is a compact formulation of the design objective. DO_rationale collects some comments to explain or to highlight specific aspects of the design objective. More complete definitions of VHDL-A concepts and terminology will appear in the associated DOD Rationale document. DR_reference(s) is an explicit reference of the form DRX, X = 1,2,..., to the design requirements (DR) supported by the design objective (see annex A). Some ideas are supported by one or several design requirements. Other ideas are not explicitly supported by any requirement, but appeared during analysis, or during discussions. The structure of the DOD is as follows: 1. Introduction 2. General Guidelines 2.1. Scope of the Language 2.2. Digital Aspects 2.3. Analog Aspects 2.4. Mixed Digital-Analog Aspects 3. Analog Structures 4. Analog Behaviors 5. Interactions Between Analog and Digital 5.1. Analog to Digital Interactions 5.2. Digital to Analog Interactions 6. Simulation Mechanisms Annex A: Consolidated List of VHDL-A Design Requirements 2. General Guidelines --------------------- This section provides general guidelines for the design of VHDL-A. DO0 (must) Design objectives must ensure a reasonable degree of portability, while giving enough freedom to the implementation. Rationale: The idea is to not consciously close the door on something that we already know about, but that we don't plan to implement now because it is not part of the current version of the norm. For example, one intention is to maintain portability without defining the simulation algorithm(s). The objective is however much broader and covers more than analyses. From: DR24, DR34. 2.1. Scope of the Language -------------------------- DO1 (must) VHDL-A must be suitable for the description and simulation of digital, analog, and mixed digital/analog systems at several abstraction levels (i.e. functional, behavioral, macromodel, and device levels). VHDL-A must be able to support any design methodology and be technology independent. Rationale: As VHDL is primarily targeted towards the description and simulation of digital systems, VHDL-A must support the same objectives for analog and mixed analog-digital systems. Typical application areas of VHDL-A are IC design, ASIC design, PCB applications, and electrical system design. From: DR4, DR16, DR29, DR39, DR40, DR41, DR46. DO2 (should) VHDL-A should be suitable for the description and simulation of non-electrical (i.e. mechanical, thermal, etc.) and mixed electrical/non-electrical systems. Rationale: In many modern systems it is not sufficient to model only the behavior of the electrical part. In power applications, for instance, the thermal properties must be considered to get an accurate picture of how a system works. Other examples are electro-mechanical systems, sensors etc. It is also natural to extend the scope of VHDL-A to also support non-electrical systems as they are analogous to the electrical systems in their modeling requirements. The differential equations which describe state variable solutions of systems in the mechanical, thermal, etc. disciplines, are of the same form as the differential equations in the electrical discipline. From: DR4, DR9. 2.2. Digital Aspects -------------------- DO3 (must) VHDL-A must be a "super-set" of VHDL'93. Any description that is valid in VHDL'93 must also be valid in VHDL-A, with the same simulation results. The only permitted exception to this is that new keywords introduced into the language may conflict with identifiers used in a VHDL'93 description. Rationale: From DO1, VHDL-A must include VHDL'93 as a support of digital description and simulation. From: DR16, DR21. 2.3. Analog aspects ------------------- DO4 (must) VHDL-A must at least support time-domain analysis of lumped-element electronic systems. Rationale: Lumped-element time-domain analysis is one of the most frequent types used in electronic design. Moreover, the resulting time-domain descriptions allow the most natural coupling with digital VHDL. From: DR16, DR29. DO5 (must) Analog descriptions must re-use existing (VHDL'93) syntax where appropriate. Rationale: The structuring mechanisms of VHDL'93 and its programming facilities should be re-usable with little or no modifications for analog modeling with VHDL-A. From: DR21. DO6 (should) VHDL-A should support time-domain analysis of lumped-element non-electrical systems. Rationale: A logical extension of DO4 consistent with DO2. From: DR9, DR16, DR29. DO7 (must) VHDL-A must support small-signal linear frequency analysis of lumped-element electronic systems. Rationale: Small-signal linear frequency analysis is already commonly available in circuit simulators such as SPICE, so many users will expect this capability from a VHDL-A simulator. From: DR16, DR29. DO7b (desirable) It is desirable that VHDL-A support large-signal non-linear frequency analysis of lumped-element electronic systems. Rationale: Large-signal non-linear frequency analysis and mixed time-frequency analysis are not out of the scope, but they need more study and therefore they might be taken into account in future releases of the language. From: DR16, DR29. DO8 (should) VHDL-A should support small-signal linear frequency analysis of lumped-element non-electrical systems. Rationale: A logical extension of DO7 consistent with DO2. From: DR9, DR16, DR29. DO8b (desirable) It is desirable that VHDL-A support small-signal linear and large-signal non-linear frequency analysis of lumped-element non-electrical systems. Rationale: A logical extension of DO7b consistent with DO2. From: DR9, DR16, DR29. DO9 (must) VHDL-A must support the noise modeling and analysis of lumped-element electronic systems. Rationale: Noise modeling and analysis is required for high dynamic range applications such as radio or telecom applications. From: DR16, DR29, DR42. DO9b (should) VHDL-A should not be restrictive in other types of analyses. Rationale: VHDL-A should leave the door open to whatever type of analysis that may become interesting to support in some next revision of the norm. From: General requirement from discussion. 2.4. Mixed Aspects ------------------ DO10 (must) VHDL-A must provide mechanism(s) that allow the analog and digital behavioral parts of a mixed description to interact. Rationale: Direct interaction of analog and digital components is not possible because they are not handled by the same simulation kernel. Therefore, a mechanism must be established to translate signals from analog-to-digital and vice versa. Translation involves in general both a value conversion and a conversion between two timing models. From: DR2, DR5, DR36. DO11 (must) The basic A/D and D/A interaction mechanisms of VHDL-A must be completely defined and make no use of the "foreign interface" of VHDL'93. Rationale: Portability is the main reason. VHDL-A will define a mixed simulation cycle based on A/D and D/A interactions. These ones are not allowed to vary between implementations since they will be part of the norm. Since the "foreign interface" in VHDL'93 allows the deferral of the implementation of some part of the description outside VHDL-A, this is an open door to different implementations and therefore contradicts the portability objective. From: DR24. D012 (should) The model of the interface between the analog and digital descriptions should be customizable by the user. Rationale: In order for VHDL-A to be technology independent, the user should be free to decide where to use A/D and D/A conversion mechanisms and also how they will work (i.e. how the translation between signals will be performed) during simulation. From: DR26, DR27. 3. Analog Structures -------------------- DO13 (must) VHDL-A must be capable of describing a digital, analog, and mixed digital/analog systems by structural composition of components. Rationale: Required for the hierarchical definition of analog and mixed behaviors. From: DR33, DR37. DO14 (must) Structural descriptions consisting of netlists of analog components that encapsulate analog behaviors must observe conservation-law and/or signal-flow semantics. Rationale: Conservation-law semantics are required for the structural description of lumped-element systems (either electronic or from other disciplines). Signal-flow semantics are required (1) by the need to describe analog systems at the system-level, and (2) the need to express the coupling effect between analog components, such as controlled sources. From: DR3, DR4, DR11, DR39, DR40, DR41, DR46. DO15 (should) VHDL-A should provide a migration path for SPICE based libraries and system descriptions (i.e. netlists). Rationale: Prospective users of VHDL-A are likely to have a large investment in SPICE libraries and netlists that they want to re-use. This does not require SPICE syntax to be included in, or understood by, VHDL-A, but forces it to allow a mechanism dealing with backward compatibility (i.e. how all the SPICE concepts can be translated into VHDL-A). From: DR8, DR14. DO16 (desirable) It is desirable that VHDL-A provides a mechanism to specify netlists conditional upon the value of a constant parameter (conditional netlists). A special case of this is collapsing 2 nodes. Rationale: The need to switch netlist description for a component upon some condition arises frequently in the analog design process. Generally speaking, the condition may be either static (i.e. known before simulation, the most common case), or dynamic (i.e. known during simulation). While static conditional netlist is the most common case, the effective use of dynamic conditional netlist is still to be demonstrated. Switching between a behavior model and netlist model should also be supported. From: New requirement from discussion. DO17 (desirable) It is desirable that VHDL-A provides a mechanism to specify regular array structures of instances, with constant dimensions. Rationale: The ability to specify regular analog array structure is useful for designing such circuits as artificial neural networks. From: New requirement from discussion. 4. Analog Behaviors ------------------- DO18 (must) VHDL-A must support behavioral specification of an analog system by a set of linear/nonlinear differential/algebraic equations and/or by a sequence of assignments. Rationale: Supporting behavioral descriptions is definitively a must since VHDL-A intends to be more powerful than SPICE. Even if VHDL were to be no more powerful than SPICE, this objective is required to have portable descriptions of lowest level of primitive devices. An equation describes a relation to be satisfied between quantities. Equations throughout the description(s) are solved simultaneously to perform analog simulation. From: DR18, DR25, DR30, DR34, DR44. DO19 (must) VHDL-A must support the description of continuous time behavior both by explicit and by implicit equations. Rationale: Although many examples of analog behavioral specification can be formulated as explicit equations, there are cases where this is not possible, for instance roots of transcendental equations. From: DR30, DR34. DO20 (must) VHDL-A must support mixed structural and behavioral specification for a single analog component. For this purpose, VHDL-A must provide a mechanism for the behavioral specification portion to access quantities associated with the structural specification portion and vice versa. Rationale: The description of an analog component in VHDL-A may include both structural and behavioral descriptions. Since each one may use quantities defined globally for that component, VHDL-A must provide a mechanism to designate unambiguously the quantity in use, but in the restriction that the general visibility rules of VHDL are satisfied. From: DR10, DR19, DR36. DO21 (must) VHDL-A must provide a mechanism to access quantities that are used inside an analog component but not associated with terminals (i.e. connection points satisfying the KCL/KVL semantics) from outside of the component. Rationale: The description of an analog component in VHDL-A may make use of quantities that are not associated with a connection point of the component satisfying conservation semantics, but rather with some coupling effect. Controlled sources are a typical example. From: DR8, DR19. DO22 (must) VHDL-A must support a mechanism to parameterize a model. The support must at least include parameters that are constants (static parameters). It is desirable to support parameters that vary during simulation (dynamic parameters). It must be possible to distinguish parameters that intentionally have been left unspecified from parameters having their default initial value. Rationale: Parameterization enables efficient and flexible modeling. It also fosters the creation of parts libraries. A typical example of a static parameter is a component value, while a typical example of a dynamic parameter is the temperature. The value of a dynamic parameter may come either from the solution of the system of equations or from some algorithmic computation, or from some external input stimuli. From: DR8. DO23 (must) VHDL-A must support the description of analog behavior that depends on the independent variable of an analysis. Rationale: Time dependent models and frequency dependent models are used often, particularly at higher levels of abstraction. This means that it must be possible to write time and/or frequency dependent equations. This feature is also needed to implement a time dependent source. From: DR8, DR22. DO24 (must) VHDL-A must support discontinuous analog behavior and waveforms. In particular, it must be possible to enforce an analog time step in response to some change in the analog part. Rationale: At higher levels of abstraction system behavior appears as discontinuous. Typical examples are the bouncing ball and the friction examples. Another point is the handling of discontinuous input stimuli (e.g. piece-wise linear). From: New requirement from discussion. DO25 (must) The maximum simulation time for a mixed analog/digital system must not be restricted by the minimum time resolution of VHDL'93. Rationale: If analog and digital kernels are synchronized with the VHDL'93 MTR of 1fs, the maximum simulation time of a mixed system is restricted to about 9s if the time is implemented as a double precision variable (53 bits of resolution => 2**53 * 1fs maximum time). This is clearly insufficient for some system applications where the time constants may easily be in the order of seconds (e.g. if a motor is involved). From: New requirement from discussion. DO26 (must) VHDL-A must provide a time derivative operator. Rationale: A time derivative operator is obviously needed to write analog behavior with differential equations. From: DR5, DR32, DR46. DO27 (must) VHDL-A must provide pre-defined mathematical functions (such as sine, cosine, exp, log, ln, etc.). It should also provide a way to define custom mathematical functions. Rationale: Ordinarily used mathematical functions must be made available in VHDL-A, as they are very useful in behavioral modeling. Such functions should not require the VHDL'93 "foreign" mechanism. Other functions like NAG or IMSL are outside of the scope of VHDL-A, but anybody who needs these functions can write a package and call them using VHDL'93 "foreign" mechanism. It may also be useful for a user to define their own (frequently used) functions. From: DR7, DR32, DR46. DO28 (should) VHDL-A should support the description of piecewise defined behavior. Rationale: There are modeling cases where equations may change according to some condition. Generally speaking, the condition may be either static (i.e. known before simulation), or dynamic (i.e. known during simulation). Dynamic conditional behavior is needed when the behavior depends on the operation of the system (e.g. transistor model). From: New requirement from discussion. DO29 (should) VHDL-A should provide an integral operator. It must be at least defined from time zero to the current simulation time. Rationale: The integral operator is needed for the matter of convenience. Every expression that involves an integral may be easily transformed into another one that uses a derivative. The integral operator must be defined from time zero to the current simulation time. Moreover, the integral operator is not always defined (e.g. in DC analysis). From: DR46. DO30 (should) VHDL-A should support the annotation of physical units to waveforms. Rationale: The annotation of simulation results with appropriate units would ease the interpretation of the results. The use of units may also improve the readability of the code. From: DR17. DO31 (desirable) It is desirable that VHDL-A support dimensional analysis. Rationale: The equations for different disciplines (electrical, mechanical, etc.) are written in units and dimensions relevant to the discipline. Some way of local unit declarations should be available, as well as dimension consistency checks. Another purpose is to allow the user to manipulate a quantity together with its related unit. This would ease the interpretation of the code and the simulation results. From: DR17, DR28. 5. Interactions Between Analog and Digital ------------------------------------------ DO32 (should) Default conversions between analog and digital connection points should be provided. Rationale: This would make the direct connection between analog and digital connection points legal without additional syntax. This might be required when analog-to-digital or digital-to-analog conversions are needed for the simulation and do not correspond to any physical component in the system. From: DR2, DR26, DR27. 5.1. Analog to Digital Interactions ----------------------------------- DO33 (must) The user must be able to define how changes of values of analog quantities have an effect on the values of digital signals. Rationale: Analog to digital interaction involves the transformation of an analog waveform, which is continuous in amplitude and in time, into a digital signal, which is quantized in amplitude and discrete in time. Therefore both a value conversion and a time conversion are to be performed and this has to be controllable by the user. From: DR2, DR5, DR13, DR27. DO34 (must) VHDL-A must support at least the following analog to digital interaction mechanisms: - a digital process must be able to read an analog value - it must be possible to make a digital process sensitive to an analog value. Rationale: One primary goal of VHDL-A is to allow the description and the simulation of mixed digital-analog systems. To that end, it is necessary to allow analog objects to be read within the digital description. From: DR27. 5.2. Digital to Analog Interactions ----------------------------------- DO35 (must) VHDL-A must support at least the following digital to analog interaction mechanisms: - an analog behavioral model must be able to read a digital signal - it must be possible to make an analog behavioral model sensitive to a digital signal. In particular, it must be possible to enforce an analog time step in response to an event on a digital signal. Rationale: One primary goal of VHDL-A is to allow the description and the simulation of mixed digital-analog systems. To that end, it is necessary to allow digital objects to be read within the analog description. Also, some change in signal values may or may not produce discontinuities in analog quantities. In the former case, a specific mechanism must be devised to ensure a correct computation of analog quantities. From: DR2, DR26. DO36 (should) VHDL-A should provide a mechanism to handle the intrinsic instantaneous change of digital signal values that affects the behavior of analog part. Rationale: The instantaneous change of a digital signals value is likely to produce numerical difficulties when computing the state of the analog part in reaction to this change. Some "smoothing" function should be defined to avoid this. This DO is a special case of the problem described in DO24. From: New requirement from discussion. 6. Simulation Mechanisms ------------------------ DO37 (must) Compliance with VHDL-A must not depend on the specification of an underlying simulation algorithm for the analog kernel. Rationale: There is not a single method to perform analog simulation. Depending on the needs, one may want to use a very accurate, but expensive (time and memory consuming), or a simplified, but fast, simulation method. This must not be precluded by the language. From: DR29. DO38 (must) VHDL-A must define the mechanism related to the simulation of the analog part of a VHDL-A description as well as the mechanism related to the simulation of mixed digital-analog descriptions. Rationale: The analog simulation mechanism (or analog simulation cycle) refers to the way the analog behavior described in the VHDL-A model (i.e. equations) must be handled during simulation, or, more specifically, must be handled for each of the available analyses (e.g. DC, transient, or small-signal frequency analyses). The mixed analog-digital simulation mechanism (or mixed analog-digital simulation cycle) refers to the synchronization between the analog and the digital simulation kernels. These aspects are very important to ensure a reasonable degree of portability for the models written in VHDL-A. From: DR1, DR23, DR35. DO39 (must) VHDL-A must support the specification of user-defined initial conditions. It must also provide a way to start the simulation in a consistent state. Rationale: The specification of initial conditions is inherent to the formulation of analog behavior with differential equations. For electronic systems, they are voltages across or currents through some branch in the circuit. Another aspect is the need to be able to compute the static (DC) operating point of the description, since a lot of analyses do rely on it to perform successfully (e.g. transient or small-signal frequency analyses). From: DR15, DR38. DO40 (should) A communication mechanism should be provided to pass information back and forth between the VHDL-A model and the analog simulation kernel. Only the communication mechanism should be defined, not the way the simulator will handle them. Rationale: Simulation control is needed in some form because analog simulation methods may use various numerical algorithms. The accuracy of the solution is usually related to a set of numerical tolerances, in order to decide whether the solution has converged or not, and also to the actual implementation of the numerical algorithms, because they are optimized towards this specific usage (e.g. limiting schemes to avoid numerical overflow). Another point related to simulation control is to allow statistical simulations to be performed, where the same model is simulated several times for different values of some specific parameters. From: DR6, DR12, DR45. Annex A: Consolidated List of VHDL-A Design Requirements -------------------------------------------------------- This annex summarizes all requirements submitted to the sub-par 1076.1 for analog extensions to VHDL. It includes the ones relating to analog matters, which were already submitted to the VHDL'92 restandardization effort, as presented by Kevin Nolan in his document on consolidated North American and European Analog VHDL Requirements, the additional ones collected by Mart Altmae, and finally a few new North American requirements, presented by Kevin Nolan at the VHDL-Forum meeting in Santander (April 92). Consolidated design requirements are numbered sequentially from 1 with the DR prefix. Also, cross-references to design objectives are given for each DR. DR1 Support for Continuous Time. Summary: The execution of a VHDL model must be extended from the notion of the evaluation of events at discrete points in time to the notion of continuous evaluation over continuous time. Supported by: DO38. DR2 Mixed mode support: conversion between analog and digital domains. Summary: Objects defined using discrete time semantics (signals) and continuous time semantics (waveforms) must be able to communicate with one another to provide the ability to perform mixed-mode simulation. Supported by: DO10, DO32, DO33, DO35. DR3 Support for analog pins and a way to connect them. Summary: Electrical circuits are typically described as an interconnection of elements that exhibit some electrical behavior. The connection points at the elements are defined in terms of ports. Each electrical port consists of two physical connection points that are defined as terminals (N-Port Theory). Supported by: DO14. DR4 Analog pin behavior conforming to conservation laws. Summary: The objective is to describe the physical operation of circuits. The most common method is the use of Kirchhoff's current and voltage laws. We therefore speak of electrical behavior in terms of currents flowing through the branches and the voltages across nodes of a network. Supported by: DO1, DO2, DO14. DR5 New operators and intrinsics to support domain conversion and the specification of derivatives. Summary: To support the conversion from analog domain to digital domain, a threshold function is needed in order to schedule events on the digital side. Conversely, a analog waveform generator function is needed to support the conversion of digital signals to analog waveforms. In order to model certain analog devices, a time-derivative operator is required. Supported by: DO10, DO26, DO33. DR6 Specification of error tolerances to be used by numerical algorithms used to solve the analog system. Summary: Since analog simulation employs numerical methods in order to solve a system of ordinary differential equations, an error tolerance must be specified to bound the numerical errors generated by these methods. Supported by: DO40. DR7 New data types and associated operators. Several new data types are required to model various systems. Complex numbers and/or phasors (polar coordinates) are needed to model filter networks, etc. Similarly, transcendental functions are required to model semiconductors. Supported by: DO27. DR8 Specification of generics whose value can be dependent on time or other system variables. Summary: It is necessary for modeling non-linear devices (e.g. semiconductors) to define models having the value of certain parameters vary as a function of time or the state of other simulation variables. Supported by: DO15, DO21, DO22, DO23. DR9 Definition of new pin types and semantics to be specified by users. Summary: To model systems containing non-electrical or hybrid devices, it must be possible to define custom pin types. For example, rotational pins would be used to model motors, thermal pins to describe self-heating electrical systems, etc. The conserved properties of these custom pin types most also be specified. Supported by: DO2, DO6, DO8. DR10 Ability to reference the through, (e.g. current) and across (e.g. voltage) components of analog entities. Summary: In conservative systems, behavior is described by specifying the relationship between dependent variables and the independent variables. In electrical systems, one might specify how the current through a device is a related to the voltage across its terminals. This requires access to the current through terminals and the voltage across them. Supported by: DO20. DR11 Ability to specify the conservation laws associated with a user defined pin type. Summary: For every type of pin that can be connected to other pins in a network, the properties of that pin which must be conserved has to be supplied. In electrical systems, the usual conservation laws are given by KVL and KCL. Analogous conservation laws must be specified for non-electrical systems. Supported by: DO14. DR12 Specification of error tolerances for a specific node. Summary: It is desirable to be able to specify the maximum relative error when using KCL to calculate the current through a specific node. According to KCL the current through any node will always sum to zero. The maximum relative error at that node would be the ratio of the difference between the currents flowing into the node to the currents flowing out. Supported by: DO40. DR13 Specification of an event trigger threshold to cause evaluation of a event-driven process body. Summary: In order to determine whether a digital event has occurred as a result of an analog state change, it is desirable to allow the specification of the minimum analog change threshold to control the evaluation of a process body. A higher value for this parameter would cause fewer evaluations of the process body and therefore faster simulation, a lower value would result in more evaluations, longer simulations, and possibly greater simulation accuracy at the analog transition points. Supported by: DO33. DR14 Allow specification of a foreign simulator interface. Summary: To allow VHDL to communicate with foreign (non-VHDL) simulators. Supported by: DO15. DR15 Inclusion of DC operating point analysis as part of time-zero initialization and a way to conditionally execute blocks based upon the initialization state. Summary: Electrical systems have what is called a dc operating point. This describes the quiescent state of the system at time-zero. Usually, before the simulation of a transient behavior, the dc operating point must be computed. To accommodate this, the initialization semantics of VHDL must be extended to include dc analysis. It is also necessary to control the execution of behavior blocks based upon the initialization state. In other words, it must be possible to only execute certain blocks at the dc operating point and at no other time. Supported by: DO39. DR16 Analog modeling. Summary: To allow the description of analog system/circuit behavior from the following perspectives: discrete-event models of digital circuits, continuous-time descriptions of analog circuits, frequency-domain descriptions of analog circuits and wave-domain descriptions of microwave circuits. Supported by: DO1, DO3, DO4, DO6, DO7, DO7b, DO8, DO9. Wave-domain descriptions of microwave circuits are outside the scope of VHDL-A. DR17 Physical quantities. Summary: Support for dimensional analysis of physical quantities. Supported by: DO30, DO31. DR18 Introduction of simultaneous equations. Summary: To allow the expression of relations between currents and voltages for any edge of the actual electrical network. These are equations (not assignments and they cannot apply to a signal). Supported by: DO18. DR19 Access to current value flowing through an electrical component. Summary: None. Supported by: DO20, DO21. DR20 At least two labels. Summary: Concerning whether or not any given simulator is conforming with IEEE-1076, it is desirable to have at least two different labels : - one for purely digital circuits : "VHDL-1076-92" ; - one for mixed, analog-digital, circuits : "AHDL-1076.1-93" ; - and possibly one for purely analog circuits, depending on how 1076.1 is specified. Also it is desirable to have a clear (static) criterion to identify a circuit (configuration, or entity plus architecture) as being digital, analog, or mixed. Supported by: Not considered, because not technical. DR21 Re-use digital constructs. Summary: Whenever an analog (or mixed) model uses the same kind of construct as a digital one, it is desirable to use exactly the same syntax and semantics as already defined in IEEE-1076-92, to avoid misunderstandings. Examples of constructs which can be shared by digital and analog: - type definition, function definition, sequential procedure definition - function or procedure call, ... Examples of constructs which are different in syntax and in semantics: - connection of several ports to a signal versus connection of several pins to a node - relation (or analog procedural model) versus digital process. Supported by: DO3, DO5. DR22 Definition of analog time. Summary: To perform mixed (analog-digital) descriptions and simulations, clear definitions are needed for the digital time (this already exists) and for the analog time (to be defined). Moreover the definition of the analog time should not be completely opposed to that of the digital time, to allow conversion and synchronisation. Supported by: DO23. DR23 Time synchronisation. Summary: To perform mixed (analog-digital) descriptions and simulations, clear definitions are needed for the conversion between analog and digital times. This problem is often cited and sometimes viewed as a simple problem of "type conversion": converting a digital date (an integer number of Femto-seconds) to and from an analog date (viewed as some kind of real number, possibly in seconds). Supported by: DO38. DR24 Portability of analog models. Summary: In the digital domain, the semantics is defined in such a way that models are portable: the same simulation leads to the same events happening at the same dates, whichever simulator is used. Portability is also desirable for analog (and mixed) models, but must be defined in a different way, to account for the fact that solving a set of differential equations may give different results to within some tolerance. Supported by: DO0, DO11. DR25 Use of existing methods. Summary: The structural constructs (pins and nodes, or others) and the functional constructs (relations, or others) used in analog models, and the implied semantics (KCL, equations, others, ...), must be such that the building and solving of the set of differential equations may be performed using existing, proven methods. Supported by: DO18. DR26 User control over Digital to Analog interactions. Summary: Interactions from the digital part to the analog part should be user-definable. This will allow technology-specific or application-specific interactions to be modelled at the desired level of abstraction. It will not prevent the use of "standard" packages for standard cases. Supported by: DO12, DO32, DO35. DR27 User control over Analog to Digital interactions. Summary: Interactions from the digital part to the analog part should be user-definable. This will allow technology-specific or application-specific interactions to be modelled at the desired level of abstraction. It will not prevent the use of "standard" packages for standard cases. Supported by: DO12, DO32, DO33, DO34. DR28 Dimensional analysis of physical types. Summary: It should be possible to write expressions involving physical quantities without having to overload the standard arithmetic operators. For example, it should be possible to multiply a variable of `type' voltage by one of `type' current and assign the result to something of `type' power without having to define an overloaded multiplication operator. Supported by: DO31. DR29 Domain of application. Summary: The mixed language to be specified in IEEE1076.1 should enable the user to perform not only electrical simulation of digital circuits, but also analog simulation of "truly" analog circuits. In the first case, the electrical (and timing) performances of a digital circuit (e.g. adder, register) may be checked, and simplified simulation techniques may be used. In the second case, the behavior of an analog circuit (e.g. operational amplifier) may be checked, and precise simulation my be necessary. Supported by: DO1, DO4, DO6, DO7, DO7b, DO8, DO8b, DO9, DO37. DR30 Several modeling techniques. Summary: The mixed language to be specified in IEEE 1076.1 should provide the user several modeling techniques for the analog parts. Modeling by equations has already been proposed (see requirement DR18). This method is simple and, in some cases, necessary. But it is well known that it leads to a greater number of equations in the equation-set. Procedural description should also be provided. In this method, analog blocks are seen as controlling their branch currents as functions of the node voltages (the node voltages are iteratively proposed by the analog kernel when solving the equation set, until the branch currents returned by analog blocks satisfy KCL). The "equation" method must be maintained and specified, because it is the only applicable method in some cases, but the "procedural" method must be added, because it will enable faster simulations. Supported by: DO18, D019. DR31 Consistency check for excitations and results in different analogue simulators. Summary: In analog design, variety of simulation tools must usually be used (high-level programming languages for system behavioural verification, linear ac simulators for frequency responses and time domain simulators for non-linear effects) and the main problem seems not be the actual simulation but being sure that what you have simulated is what you have in the schematics. Simulating small sub-blocks, either linear or non-linear, is possible by describing appropriate input signals by hand to that particular simulator, but verifying the correctness of the whole circuit cannot usually be done: you cannot be sure that connections between sub-blocks (especially between analog and digital parts) have the right polarity and so on. It seems obvious, that VHDL itself is useful only in very simplified behavioural time domain analysis of analog circuits. What I would consider very useful is that different architecture descriptions of VHDL could be used as links or source code to different analog simulators that may run parallel with digital VHDL simulation. VHDL itself would be used as a design framework which takes care that the types and waveforms of input and output signals remain consistent, no matter what simulator is used. Supported by: Not understood. This text seems to refer to a situation where different simulators are used in a very loosely coupled way, and the simulation of the whole circuit requires a lot a manual (and error-prone) operations, to feed the results of one simulator as stimuli to another simulator. It does not seem to envisage true mixed-mode simulation in VHDL-A. DR32 Analogue Modelling Requirements in VHDL. Summary: The following items would be required to give adequate analogue support in VHDL. 1/ Differential Equation specification for physical units eg di/dt, dv/dt. 2/ New standard physical type definitions to cover current and power units. 3/ A standard set of functions for often-used analogue sources eg sine, cosine, voltage/current controlled sources. 4/ New VHDL signal type definitions that can contain current, voltage and phase angle information. 5/ Overloading of standard operators to support real and imaginary numbers (ie to handle phase-angle summations) Supported by: DO26, DO27, DO30, DO31. DR33 Mixed entities required. Summary: When using 1076.1, it should be possible to describe and simulate mixed (analog plus digital) circuits, circuits having digital I/Os (e.g. bits or bit-vectors, whether input, output or three-state) and analog I/Os (e.g. analog input or analog output). Thus it should be possible to declare an entity as having, at the same time, (digital) PORTS and (analog) PINS (and possibly GENERICS and PARAMETERS). Supported by: DO13. DR34 Implementation issues. Summary: When defining 1076.1, attention should be paid to what is (easily ?) implemented and what is impossible (or nearly impossible) to implement. This should be done with the cooperation of people having an experience in the implementation of mixed simulators. Example of feasible things: - model an analog black box by a set of equations - model an analog black box by a procedural model - read a digital signal and use it in the analog behavior (with visibility rules) - read an analog voltage and use it in the digital behavior (with visibility rules) Examples of things which should be forbidden (by the syntax): - overwrite a digital signal from within an analog black box - overwrite an analog voltage from within a process - turn a voltage-source into a current-source and vice-versa. Supported by: DO0, DO18, DO19. DR35 Single Timing Semantic. Summary: Any extensions to the semantic timing model of VHDL should be incorporated into the existing timing model of the 92 standard or should handle the model used in the 92 standard. In particular, the evaluation of continuous-time models should be integrated with the evaluation of event-driven models into a single "simulation cycle" mechanism. Supported by: DO38. DR36 Pass Through of Analog Values. Summary: The transferal of analog values through a communication channel which passes through a mixed component which contains digital elements but does not involve mixed digital/analog operations on those values should not require a conversion to the digital domain. Supported by: DO10, DO20. DR37 Fully Intermixed Designs. Summary: Any extended language should allow the intermixing of any runtime statements, structural elements, or declarative statements within any of the structural blocks of the language. There should be no distinction between analog blocks/components/entities and digital blocks/components/entities. Supported by: DO13. DR38 Specification of Initial Analog Conditions. Summary: The initialization of a VHDL model must be extended from the current procedural notation to something that allows the inclusion of initial analog characteristics. Supported by: DO39. DR39 Specification of non-conservative analog systems. Summary: It should be possible to specify a non-conservative analog system to VHDL. A non-conservative (e.g. control) system use signal flow semantics to interconnect functional blocks. In other words, the signals form a directed graph of functional blocks. A functional block implements some function on the input signal(s), relating them to the output signal(s). Supported by: DO1, DO14. DR40 Top-down design methodology. Summary: VDHL must facilitate a top down design methodology for analog systems from very high levels of abstraction (e.g. H(s), Control Loops, etc.) down through their physical implementations. The must include the specification of S domain expressions and related transfer functions. Supported by: DO1, DO14. DR41 Z-domain expressions. Summary: VHDL must support the simulation of Sampled Data Systems and other DSP applications. The must include the specification of Z domain expressions and related transfer functions. Supported by: DO1, DO14. DR42 Noise modelling and simulation. Summary: VHDL must be able to model analog noise sources and allow them to be conditionally injected into the behavior of a model. Supported by: DO9. DR43 Analog delay. Summary: VHDL must be able to model an ideal analog delay. Supported by: Not explicitly supported by any DO. DR44 Ideal sources Summary: VHDL must be able to model ideal voltage and current sources. Supported by: DO18. DR45 Simulation time-step control. Summary: VHDL must allow the specification, from within a model, of the next time step the simulator is guaranteed to evaluate. Supported by: DO40. DR46 Miscellaneous functions and operators. Summary: VHDL must support the following functions and operators: - an integral operator which allows the specification of an initial condition - power of operator (** in FORTRAN) - random number function - transfer function whose arguments are the coefficients of S or Z poly's. Supported by: DO1, DO14, DO26, DO27, DO29.