|
Verilog-AMS Design Objectives Document1. Introduction The Design Objective Document (DOD) is a working document that is the basis for the analog and mixed signal extensions to Verilog’95, called Verilog-AMS. A specification document will be produced in addition to this DOD which will be submitted to the Accellera Board for approval before submission to the IEEE standards committee. 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: <DO_number> ( <DO_classification> ) where DO_number 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 Verilog-A concepts and terminology will appear in the associated DOD Rationale document. DO_comments collects all the comments made about the objective. The structure of the DOD is as follows: 1. Introduction 2. General Guidelines 2.1. Scope of the Language 2.2. Analog Aspects 2.3. Mixed Digital-Analog Aspects 2.4. Relationship to 1076.1 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 2. General Guidelines
~add in text to describe the overall MS drawing~ DO2.0 (must) Design objectives must ensure a reasonable degree of portability (at the source level...model libraries and PLI), while giving enough freedom to the implementation. Rationale: To move libraries between different implementations of Verilog-AMS DO2.1 (must) A subset of Verilog-AMS must be defined that is suitable for description and simulation of continuous time systems at several levels. Rationale: This will provide a portable standard language for the description of complex continuous time models, including analog models, in a continuous time environment.
2.1. Scope of the Language DO2.1.1 (must) Verilog-AMS must be suitable for the description and simulation of analog, and/or mixed digital/analog systems at several abstraction levels. For example functional, behavioral, macromodel, and device levels. Verilog-AMS must not preclude any design methodology and must be technology independent. Rationale: As Verilog is primarily targeted towards the description and simulation of digital integrated circuits, Verilog-AMS must support the same objectives for analog and mixed analog-digital integrated circuits. Typical application areas of Verilog-AMS are IC design, ASIC design, PCB applications, mixed signal circuits and systems with emphasis on silicon. DO2.1.2 (should) Verilog-AMS should be suitable for the description and simulation of non-electrical (for example: 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 Verilog-AMS to support non-electrical systems as they are analogous to the electrical systems in their modeling requirements. The equations which describe state variable solutions of systems in the mechanical, thermal, etc. disciplines, are of the same form as the equations in the electrical discipline. DO2.1.3 (must) Verilog-AMS must be a "super-set" of Verilog’95. Any description that is valid in Verilog’95 must also be valid in Verilog-AMS, 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 Verilog’95 description.
2.2. Analog aspects DO2.2.1 (must) Verilog-AMS 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 Verilog. DO2.2.2 (must) Analog descriptions must re-use existing (Verilog’95) syntax where it already exists. Rationale: The structuring mechanisms of Verilog’95 and its programming facilities should be re-usable with little or no modifications for analog modeling with Verilog-A. DO2.2.3 (should) Verilog-AMS should not be restrictive in other types of analyses. Rationale: Verilog-AMS should let the door be open to whatever type of analysis that may become interesting to support in some next revision of the norm. DO2.2.4 (should) Definition to include the analog waveform values in $VCD_DUMP format. DO2.2.5 (must) Verilog-AMS must 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. Third party waveform viewing tools will depend on consistent units for display via PLI.
2.3. Mixed Digital-Analog Aspects DO2.3.1 (must) Verilog-AMS 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. DO2.3.2 (must) The basic A/D and D/A interaction mechanisms of Verilog-AMS must be completely defined. Rationale:
D02.3.3 (must) The model of the interface between the analog and digital instantiations of models must be customizable by the user. Rationale: a) For the mixed signal domain, the user must be able to define the A/D and the D/A port and signal value conversions. b) The simulator must be able to insert the model automatically. c) The user must be able to override this on an instance basis. DO2.3.4 (must) Time representation must maintain minimum loss in accuracy across mixed A/D and D/A interfaces. Rationale: Verilog 1364 specifies 64 bit integer TIC time, scaled by time scale, as the smallest event. This must be taken into account in the conversions to continuous time for both minimum resolvable events and the maximum run time.
2.4. Relationship to 1076.1 DO2.4.1 (desirable) It is desirable that all Verilog extensions covered in Verilog-AMS be inter-operable with all extensions to VHDL covered in 1076.1. If differences exist between digital Verilog (Verilog’95) and digital VHDL (VHDL’93) that are inconsistent with this objective, fixing this is not included in this objective. Rationale: For users and EDA vendors, the ability to move easily between Verilog-AMS and 1076.1 is desirable. 3. Analog Structures DO3.1 (must) Descriptions of components of analog behaviors must observe conservation-law or signal-flow semantics at continuous time. Rationale: Conservation-law semantics is required for the structural description of lumped-element systems (either electronic or from other disciplines). Signal-flow semantics is required by the need to describe analog systems at the system-level. DO3.2 (must) Verilog-AMS must provide a migration path for SPICE based libraries and netlists. Rationale: Prospective users of Verilog-AMS 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, Verilog-AMS, but forces it to allow a mechanism dealing with backward compatibility (i.e. how all the SPICE concepts can be translated into Verilog-AMS). a) Spice structural concepts must exist in Verilog-AMS. b) A PLI-A mechanism must exist to load model equation. c) Mechanism must exist to declare externally defined modules as built in primitives or as foreign language modules. d) Establish standard for common model names and equations. 4. Analog Behaviors DO4.1 (must) Verilog-AMS must support behavioral specifications of an analog system by a set of linear/nonlinear differential/algebraic equations and/or by a sequence of assignments. DO4.2 (must) Verilog-AMS must support the description of continuous time behavior both by explicit and by implicit equations described explicitly. Rationale: Although many examples of analog behavior specification can be formulated as explicit equations, there are cases where this is not possible, for instance roots of transcendental equations. Explicit example: y=F(x) Implicit example: F(x)=0 ; G(x)=F(x) ; x=F(x) DO4.4 (must) Verilog-AMS must provide a mechanism to access quantities that are used inside a module but not associated with ports (i.e. connection points satisfying the KCL/KVL semantics) from outside of the module. Rationale: The port list may be used by other netlist oriented programs such as ERC and other Verilog tools. Additional ports used only for some analysis or abstraction could cause problems. Thermal analysis, for example, might require additional ports to be added to module definitions. This would not allow pre-compiled libraries to be shipped independent of analysis. DO4.5 (must) Verilog-AMS must support the description of analog behavior that depends on time. Rationale: Time dependent models are used at higher levels of abstraction. This means that it must be possible to write time dependent equations. This feature is also needed to implement a time-dependent source. DO4.6 (must) Verilog-AMS must support simulation in terms of time steps and time points. Rationale: At higher levels of abstraction system behavior appears as discontinuous such as the bouncing ball and the friction example. Another point is the handling of discontinuous input stimuli (e.g. piece-wise linear). Three proposed bounding functions are: breakpoint, bound step, and threshold. DO4.7 (must) Verilog-AMS must provide a time derivative operator. Rationale: A time derivative operator is obviously needed to write analog behavior with differential equations. DO4.8 (must) Verilog-AMS must provide an integral operator. It must allow specification of optional DC solution or initial condition. Rationale: The integral form of a behavioral equation can always be transformed into a form using only time derivatives. Moreover, the integral operator is not always defined (e.g. in DC analysis). DO4.9 (must) Verilog-AMS must provide pre-defined mathematical functions (such as sine, cosine, exp, log, ln, etc.). Rationale: The default math functions will be defined by the choice of ‘C’ runtime math libraries. DO4.10 (desirable) It is desirable for Verilog-AMS to accept transfer functions described as rational polynomials (in s and z). DO4.11 (desirable) It is desirable for Verilog-AMS to accept table descriptions of behavior.
5. Interactions Between Analog and Digital DO5.0 (must) Default conversions between analog and digital connection points must 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 conversions are needed for the simulation and do not correspond to any physical component in the system.
5.1. Analog to Digital Interactions DO5.1.1 (must) A system-supplied thresholding function must be accessible to the user in defining customized thresholding functions. The user must be able to define what a "significant change" is that defines thresholds within the analog system. Rationale: Thresholding is a common way to define analog to digital interactions. A system-supplied thresholding function should satisfy most of the needs, provided that the user is able to change the threshold values. DO5.1.2 (must) Verilog-AMS must support at least the following analog to digital interaction mechanisms: a) a digital process must be able to read an analog value b) it must be possible to make a digital process sensitive to an analog value. Rationale: One primary goal of Verilog-AMS is to allow the description and the simulation of mixed digital-analog circuits. To that end, it is necessary to allow analog objects to be read within the digital description.
5.2. Digital to Analog Interactions DO5.2.1 (must) Verilog-AMS must support at least the following digital to analog interaction mechanisms: a) an analog behavioral model must be able to read a digital signal. b) 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 Verilog-AMS is to allow the description and the simulation of mixed digital-analog circuits. To that end, it is necessary to allow digital objects to be read within the analog description. DO5.2.2 (must) Verilog-AMS must address the problem of discontinuities that the digital part may produce due to the intrinsic properties of digital signals. 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. This DO is a special case of the problem described in DO4.1. 6. Simulation Mechanisms DO6.1 (must) Verilog-AMS must be implementable using a wide variety of simulation algorithms. DO6.2 (must) Verilog-A must define the mechanism related to the simulation of the analog part of a Verilog-A description. Rationale: The analog simulation mechanism (or analog simulation cycle) refers to the way the analog behavior described in the Verilog-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). DO6.2.1 (must) Verilog-AMS must define the mechanism related to the simulation of the mixed digital-analog descriptions. Rationale: The mixed analog-digital simulation mechanism (or mixed analog- digital simulation cycle) refers to the synchronization between the analog and the digital simulation kernels. This aspect aspects is very important to ensure a reasonable degree of portability for the models written in Verilog-AMS. DO6.3 (must) Verilog-AMS 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 circuits, 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). DO6.4 (must) A communication mechanism must be provided to pass information back and forth between the Verilog-A model and the analog simulation kernel. Only the communication mechanisms must 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 to perform statistical simulations, where the same model is simulated several times for different values of some specific parameters.
Revision History of Design Objectives Document Kim Hailey/Ira Miller 7/13/95 Version 2.0 note: |