=============================================================================== 1076.1 Ballot Resolution Commitee Comment Resolution Report ------------------------------------------------------------------------------- CRR Number: 15 Topic Addressed: Meta issues Related CRs: 186, 187 (Stephen A. Bailey, Veribest, negative changed to affirmative) 239, 240, 243, 245 (Ken Kundert, Cadence, negative) Relevant LRM Sections: Resolution Status: Partly in review by balloters =============================================================================== Comment Reports Summary ~~~~~~~~~~~~~~~~~~~~~~~ ---------------------------------------------------------------------- 186 30 days to review and ballot on a standard this complex is insufficient time. Sixty days is required. I only hope my ballot makes it on time. ---------------------------------------------------------------------- 187 I would change my vote to positive if the scope of the PAR were changed to define a "trial-use" standard. This standard is not sufficiently specified to qualify for a full use designation. Proposed Resolution ~~~~~~~~~~~~~~~~~~~ Change the PAR to define a "trial-use" standard. ---------------------------------------------------------------------- 239 The only known way to efficiently implement a mixed-signal simulator is to allow the continuous-time kernel to run ahead of the event-driven kernel, and back up the continuous-time kernel when it is affected by an event. Analogy currently holds a key patent on this technology. IEEE bylaws require that Analogy offer to license their patent to anyone that wishes the implement the proposed standard under reasonable terms. To my knowledge, the IEEE has not yet received this assurances from Analogy on this issue. Proposed Resolution ~~~~~~~~~~~~~~~~~~~ Either ask for and receive assurances from Analogy that they will license their patent to anyone implementing the proposal under reasonable terms, or begin an investigation to determine if a new approach exists that is both practical and does not infringe on any known patents. ---------------------------------------------------------------------- 240 Providing an analog-only subset is important to the success of the proposed standard. It allows more rapid implementation of a VHDL-based tools analog circuits. It lowers the barrier to implementing a VHDL-based analog tools, meaning more vendors will develop such tools. Finally, it results in the availability of much less expensive VHDL-based analog tools (low cost analog-only and digital-only tools are readily available, but true mixed-signal tools tend to sell for a considerable premium). Thus, defining an analog-only subset will result more analog VHDL-based tools, sooner, and at lower cost. This can only dramatically increase the eventual use of VHDL. Proposed Resolution ~~~~~~~~~~~~~~~~~~~ Define an analog-only subset. ---------------------------------------------------------------------- CR243 It is very obvious that there will be two mixed-signal language standards, VHDL-AMS and Venlog-MS. Unfortunately, these two languages are quite different for no good reason other than the language definition committees for the two languages stubbornly refused to consider the ideas and approaches of the other. Instead of mixed-signal being an area were VHDL and Verilog come together, we have made it an area where the two continue to be very far apart. There is no good reason for this. There is no benefit that this difference brings the user of these languages. It only makes it more difficult to learn the two languages, and more difficult to link the two languages. In addition, the each language could benefit greatly from ideas in the other. If we consider the current proposal for VHDL-AMS, it currently has two serious limitations in its ability to handle top-down design and mixed-signal simulation. Both of these issues have been addressed in Verilog-MS. Proposed Resolution ~~~~~~~~~~~~~~~~~~~ Form a joint VHDL & Verilog AMS committee to consider pulling the languages together. ---------------------------------------------------------------------- 245 SPICE has been the de facto standard analog simulator for over 20 years, and there is a tremendous amount of infrastructure that exists to support SPICE. The current proposal is clearly incompatible with Spice, making it compatible with the existing infrastructure. In addition, the current proposal is completely silent on the subject of SPICE compatibility, and so information on what about the proposal is compatible with SPlCE, and what is not. Proposed Resolution ~~~~~~~~~~~~~~~~~~~ The question of compatibility with the following SPICE constructs needs to be addressed. 1. Netlists and netlist parameterization 2. Model statements, model libraries, and automatic model selection 3 Initial conditions and nodesets 4. Standard models ---------------------------------------------------------------------- =============================================================================== Analysis and Action Taken ~~~~~~~~~~~~~~~~~~~~~~~~~ ---------------------------------------------------------------------- 186 The 30 day ballot duration is imposed by the IEEE and the 1076.1 working group had no control on the review time. We agree that the material to review was quite complex but it was possible for the members of the balloting list to get information about the future standard before the ballot actually started. The balloting list closed on December 31, 1997 and the ballot package reached the balloters by end of July 97. Between these dates, we completed a set of white papers and made them publicly available on the web, along with all working group and language design meeting minutes and a tutorial. We understand that some balloters were not members of the 1076.1 working group, but we think it is the balloter's responsability to get informed on the material he/she volunteered to review and to vote on. The ballot time was extended by another 30 days to October 1st. It does not seem however that the IEEE was flexible enough to allow balloters that have sent their ballots in a hurry to meet the first deadline of September 1st to subsequently send additional comment reports. Finally, the complexity of the 1076.1 LRM is equivalent to the one of the 1076-1987 LRM and we are not aware of any such claim when the 1076-1987 document was balloted. We do not think this comment report needs a particular resolution, as the issue raised is general to any IEEE ballot. We take the problem as a procedural issue that would need to be discussed with the IEEE in conjunction with other procedural issues we experienced during the ballot (e.g. how to check that the the balloter's data are still valid six months after the balloting list is closed). ---------------------------------------------------------------------- 187 A trial-use standard is a standard that has a limited lifetime of 2 years. After that period, the standard can either be accepted as a full standard (if no comments were received) or it can be returned to the working group for further development and balloting. No ballot is required to upgrade a standard from trial-use to full status if no comments were received. The reasons to consider a trial-use standard are: - The working group did not reach immediate agreement on the proposed standard. - The technology being standardized is evolving rapidly. - It is difficult to resolve certain negative ballots. The balloter is suggesting that the language definition is not mature enough to achieve a full standard and that a trial-use standard would be more appropriate. We believe that none of the reasons to go for a trial-use standard that are mentioned above do actually apply to the 1076.1 effort: - A working group vote was carried out successfully before the IEEE ballot started. Several comments were issued at that time, but none of them raised severe issues that would need major changes in the language definition. - The foundations of the 1076.1 language are based on differential and algebraic equation theory that has been developed since more than 15 years and on classical circuit theory that is even older. Also, implementations of behavioral languages similar to the 1076.1 language on the top of electrical simulators such as SPICE have been available in commercial products for years. We believe that the technology to support the 1076.1 language is quite stable, although there is still room for optimization improvements. - We agree that some language aspects do not completely satisfy some balloters who voted negatively, e.g. the direct association of interface signals, interface terminals, and interface quantities, or the handling of tolerances. The language definition allows however either to use acceptable workarounds (in the case of port association), or to provide a general and flexible enough solution that lets the door opened for future improvements (in the case of tolerances). None of these issues would cause problems for 1076.1 implementations. We believe that the 1076.1 language proposal is fairly complete. It also consistently extends the 1076 language without breaking any existing definitions. It even improves some aspects that were too loosely defined in the 1076 language (e.g. the definition of time) and its development suggested enhancement requests to the base 1076 language. Finally, the PAR for a full standard was accepted by the IEEE Standards Board and changing its status to a trial-use standard would need another round of decisions from IEEE and would delay the availability of the standard in an unacceptable way. We also asked the balloter for clarification and we got the following answer: At 20:33 -1100 11.4.1998, Stephen A. Bailey wrote: > I'd like to get some clarification about the comment you made during > the IEEE ballot: > > "I would change my vote to positive if the scope of the PAR were > changed to define a "trial-use" standard. This standard is not > sufficiently specified to qualify for a full use designation." > > What do you mean by "not sufficiently specified"?. This comment was due to my ignorance as to the sufficiency of the specification of the analog solver. Unfortunately, I finished my review just prior to the deadline and was unable to find appropriate analog experts with which to discuss the issue. I believed that either the specification was insufficient or that the mathematical foundation that analog solvers are based upon were so rudimentary and obviously known (by people in the field) that it would be redundant and unnecessary to specify the mathematical theory underlying the solvers. Not knowing which was the case, I decided to vote negative until I could discover the answer. After submitting my ballot, I did follow-up and discuss the issue with Bill Bell, Ernst Christen and possibly others and was convinced that the latter was true. Therefore, you can officially consider my vote changed from negative to positive. The BRC recommends to keep going for a full standard. This is confirmed by the clarification we got from the balloter. ---------------------------------------------------------------------- 239 Analogy has sent a letter to the 1076.1 working group stating its position w.r.t. the Calaveras patent (US Patent Number 4,985,860 entitled "Mixed-mode-simulator interface". In essence, the letter makes any implementer of the VHDL 1076.1 standard aware of the existence of the Analogy's patent in the domain of mixed-signal simulation and states that it is possible to implement the VHDL 1076.1 standard without violating the patent. The letter will be part of the package to be sent to the IEEE Standards Board and will be included in the final version of the 1076.1 language reference manual. Our investigations on implementations of a mixed-signal simulation algorithm showed other possible ways: a) The ACSL Reference Manual Rev. 4.0 says in section 4.97: ...The automatic variable step algorithms such [as] Adams-Moulton or Gear's Stiff (IALG = 1 or 2) or Fehlberg (IALG = 8 or 9) reduce the time step in the region of a discontinuity in F at the expense of increased processing time, and it is debatable how good the error control mechanism works in the event of a discontinuity in one of the state variables. ... A possible penalty is that the variable step algorithms may have to be restarted after a discontinuity since they keep track of an estimate of derivatives (a Nordsieck vector) which will probably be invalidated at a switch point. ... b) We have heard about a discussion or paper where crossing events were "predicted" using the predictor of a predictor/corrector method, followed by a refinement of solving the equations repeatedly. We do not have a particular reference, unfortunately. c) The IDSIM2 mixed-mode simulation environment (D. Overhauser, I. Hajj, Proc. IEEE CICC'90 Conf., pp. 5.2.1-5.2.4) uses a Waveform Relaxation approach. The circuit to simulate is decomposed into several subcircuits that are further classified as being either digital or analog, which determines the kind of simulation algorithms to use (i.e. event-driven or continuous-time). Each subcircuit is individually scheduled to be simulated either for the entire simulation time interval or for the switching time of an input waveform. There is no use of time backtracking or rollback mechanism since the global simulation scheme is not event-driven. This kind of mixed-mode simulation scheme usually needs to iterate on the subcircuit simulations to converge to accurate waveforms. Practical simulation results show run-time gains regarding to SPICE2 results while maintaining good accuracy. d) In the paper "Evaluating Mixed-Signal Simulators" by D. Overhauser and R. Saleh (Proc. IEEE CICC'95 Conf., pp. 113-120), several commercial implementations of mixed-signal simulators are compared (Table 1, p. 120). Several tools use either the lock-step or the rollback mechanisms which are clearly identified as different from Analogy's proprietary Calaveras algorithm. We believe that the first part of the balloter's claim related to Analogy's letter of insurance is cleared as the required letter was provided to the 1076.1 working group. We also believe that, in the light of our investigations, the Analogy's Calaveras algorithm is not the only possible and efficient way to implement a mixed-signal simulator. ---------------------------------------------------------------------- 240 It is clear from the Design Objectives Document V2.3 that the 1076.1 Working Group never contemplated an analog-only language (however that is to be defined), but rather an extension to VHDL 1076.1 to accommodate analog and mixed signal modeling styles. The balloter refers to Design Requirement 20, part of the document from which the Design Objectives were derived, which reads in full as follows: 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. The phrase "...and possibly one for purely analog circuits, depending on how 1076.1 is specified" could be construed as a requirement for a subset supporting "purely analog circuits". However, this was not so construed during requirements review, and consequently no design objective mandating an analog-only subset was produced. Note that the requirement for a digital-only subset did result in several design objectives, and that these objectives have been met. Note also that the design objectives have been approved by the Working Group with a large majority. The balloter argues from commercial considerations for the desirability of another language that is easier and cheaper to implement than 1076.1. That question is outside the purview of this ballot review. These reasons indicate that comment report 240 is not relevant for the 1076.1 draft standard. We therefore propose to mark it as resolved. ---------------------------------------------------------------------- 243 The balloter states that VHDL-AMS and Verilog-AMS are unnecessarily different, and argues that this makes it more difficult to learn the two languages. He also cites as limitations of VHDL-AMS its ability to handle top-down design and mixed-signal simulation. The two issues are quite different, so we address them separately. 1. Language Differences ----------------------- There are indeed several differences between the VHDL-AMS and Verilog-AMS languages. Both languages are extensions to existing languages: VHDL 1076 and Verilog 1364. This heritage carries with it a large bag of boundary conditions and restrictions: syntactic structure type system expression evaluation semantics visibility rules language philosophy to name just the most important. The extensions must abide by these boundary conditions to make them smoothly fit with the base language, otherwise a person intimately familiar with the base language would be confused too easily when having to deal with a model in the extended language. Many of the differences between the two languages are due to their different heritage. The most obvious is the syntax, but the other boundary conditions leave their traces as well if consistency within the language (i.e. the base language and its extension) is a design goal. We believe that such consistency should be a design goal, making it more important than any potential compatibility with a language that has a different heritage. In other words, differences due to heritage are necessary. Other differences between the languages are due to different target audiences. Verilog-AMS appears to be closer to the hardware and specifically to IC design than VHDL-AMS, just like Verilog is closer to hardware than VHDL. This is demonstrated by Verilog-AMS' exclusive focus on conservation semantics and its predefined $temperature and $vt. VHDL-AMS is independent of a particular application area and also supports the system designer, following the target audience of its base language. We believe that such differences are useful, because there is no need for two languages that support exactly the same target audience. Some differences that appear to be arbitrary taken one at at time are justified when the context is changed to the language as a whole. For example, a nature in VHDL-AMS corresponds to a discipline Verilog-AMS; the nature of Verilog-AMS is unnecessary in VHDL-AMS, because that idea is subsumed by the VHDL-AMS subtype. For VHDL-AMS rationales for such decisions can be found in the white papers produced by its language design committee. We have not seen similar documentation for Verilog-AMS. We believe, however, that if the issue is the ease of learning both languages, then we should focus on the similarities that exist in spite of the different heritage and target audience. The following is an incomplete list of features and approaches that the two languages have in common, although the syntax and often the functionality details are slightly different. This list is based on the respective LRMs. concept VHDL-AMS Verilog-AMS ------------------------------------------------------------------------------ branches branch quantities named branches and unnamed branches branch quantities branch quantities access functions across across quantity potential(branch_name) through through quantity flow(branch_name) reference quantity 'Reference potential(node_name) pin flow 'Contribution flow(p,p) where p is a port name equation formulation sequential and simultaneous sequential only time derivative 'Dot ddt() integral over time 'Integ idt() ideal delay 'Delayed delay() slew limiting 'Slew slew() fixed transition time 'Ramp transition() Laplace transfer fct 'Ltf laplace_nd() and others z-domain transfer fct 'Ztf zi_nd() and others zero-order hold 'Zoh not available separately small-signal sources spectral source quantity ac_stim() noise sources noise source quantity white_noise(), flicker_noise(), noise_table() ranges for parameters part of subtype part of parameter declaration threshold crossing 'Above @cross both allow a model to only detect rising or falling crossings discontinuity break discontinuity step limiting step limit specification bound_step tolerances for quantities and equations for access functions and equations Based on these similarities many models look very similar in the two languages, provided the simultaneous procedural statement is used in VHDL-AMS to describe the model. One example is the model of a diode. Its Verilog-AMS description is: [various includes of .h files to establish the compilation context and meanings of names not locally declared] MODULE diode (anode, cathode); electrical anode, cathode; BRANCH (anode, cathode) d, c; PARAMETER REAL is0=1e-14, tau=0, cjo=0, rd=0, phi=0.7; REAL q; ANALOG BEGIN i(d) <+ is0 * (exp((v(d)-rd*i(d))/$vt) - 1); q = tau*i(d) - 2*cjo*sqrt(phi*(phi-v(c))); i(c) <+ ddt(q); END ENDMODULE; Its VHDL-AMS description is: USE disciplines.electrical_system.all; USE ieee.math_real.all; -- defines exp and sqrt USE work.constants.all; -- defines vt ENTITY diode IS GENERIC (is0 : real := 1.0e-14; tau, cjo, rd : real := 0.0; phi: real := 0.7); PORT (TERMINAL anode, cathode: electrical); END ENTITY diode; ARCHITECTURE one OF diode IS QUANTITY vd,vc ACROSS id,ic THROUGH anode TO cathode; QUANTITY q: charge; BEGIN PROCEDURAL BEGIN id := is0 * (exp((vd-rd*id)/vt) - 1.0); q := tau*id - 2.0*cjo*sqrt(phi*(phi-vc)); ic := q'dot; END PROCEDURAL; END ARCHITECTURE one; While the VHDL-AMS version is slightly more wordy than the Verilog-AMS version, much of the extra text is due to requirements of the VHDL language, in particular the separation of entity and architecture. What remains are the syntactic differences and the declaration of branch quantities vs. branch names, both quite superficial. We note that although the VHDL-AMS language mandates the declaration of quantity q, representing the charge in the junction, the corresponding variable q in the Verilog-AMS model is not required by the language: the argument q of the time derivative ddt(q) can be substituted by the expression on the RHS of the statement defining q. However, designers are often interested in the junction charge of a diode; therefore, production quality models are expected to include a declaration for this variable and a statement defining its value. The VHDL-AMS version of this model can be simplified in two ways. First, there is no need to declare two across quantities vd and vc between the same terminals: the semantics of the language ensure that both always have the same value, so one is sufficient. Second, the VHDL-AMS language provides an alternative way to write this model using simple simultaneous statements. The corresponding implementation again looks very similar to the Verilog-AMS model and to the procedural VHDL-AMS version: ARCHITECTURE two OF diode IS QUANTITY v ACROSS id,ic THROUGH anode TO cathode; QUANTITY q: charge; BEGIN id == is0 * (exp((v-rd*id)/vt) - 1.0); q == tau*id - 2.0*cjo*sqrt(phi*(phi-v)); ic == q'dot; END ARCHITECTURE two; Many other models can be written that demonstrate the similarities between the two languages. In some cases the Verilog-AMS probe/source model requires the use of irregular and idiosyncratic special cases to duplicate functionality that is straightforward in the VHDL-AMS notation. However, the Verilog-AMS notions of switch branches, unassigned sources and indirect branch assignments successfully patch these gaps. The restrictions on the placement of time derivatives in Verilog-AMS can always be overcome by introducing extra intermediate statements. Finally, those Verilog-AMS statement sequences that are legal according to the LRM but have no legal interpretation or multiple possible interpretations cannot be duplicated in VHDL-AMS without discovering the modeler's original intent by some indirect means. Overall, most models can easily be written in one language or the other with a similar sequence of statements, allowing for the differences in syntax. It is questionable whether such differences are important in practice. 2. VHDL-AMS Limitations ----------------------- We interpret the balloter's claimed limitations of VHDL-AMS for top-down design and mixed-signal simulation to refer to the Verilog-AMS capability of "configuring" a connection between ports of different kinds by means of the CONNECT statement. This issue has been addressed in a response to another comment by the same balloter; we will not repeat it here. However, it is important to point out that the functionality of VHDL-AMS as it relates to mixed connections has been agreed on by consensus in the language design committee after careful considerations and investigations. Additionally, an enhancement request for the base language, where the same issue exists, has been submitted for the next revision of VHDL 1076. 3. Cooperation between VHDL-AMS and Verilog-AMS Committees ---------------------------------------------------------- Engineering a successful convergence between two languages with such different design principles and audiences seems unlikely to succeed on technical, political and commercial grounds. Neither language reflects the best current thinking in programming languages. Perhaps the best hope is a new synthesis of software and system design languages, using what we can learn Verilog-AMS, VHDL-AMS, and the new object-oriented software languages. That synthesis will require time, experience, and deliberate effort. In the short term, end users may profit from cooperation between the committees related not the languages themselves but to the modeling environment. At the 1076.1 Working Group meeting at the University of Irvine last summer a proposal was made to co-develop semantics for a set of library models that designers expect to find in a vendor's package. Such models could then be implemented in both languages, providing a certain level of portability between designs using these models written in the two languages. The proposal was well received by members of both committees, but so far nothing has happened. We believe that a cooperation at this level is much more realistic than anything else. ---------------------------------------------------------------------- 245 The exact wording of DO15 is 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. The 1076.1 Language Design Committee (LDC) sponsored an investigation into the meaning and implication of this design objective with the intent to identify requirements on the language that are not covered elsewhere. The result has been documented in a white paper with the title SPICE RELATED ISSUES IN VHDL-A In addition to this white paper, several examples published on the 1076.1 web site as part of other white papers or tutorials demonstrate various ways to deal with SPICE netlists, parameters and model statements. Further, the 1076.1 language supports the definition of initial conditions. The issue of nodesets has been described briefly in the white paper on Initialization and DC Simulation in VHDL 1076.1 in the context of handling multiple solutions. This issue was discussed several times at LDC meetings, and the minutes indicate that a proposal to not deal with this issue in the language at this time was unopposed. The design objectives do not include the creation of a standard library, and the 1076.1 Working Group has always been clear about this aspect. Additionally, at the 1076.1 Working Group meeting in Irvine on June 13, 1997, a proposal was made to develop well defined semantics for models jointly with the Verilog-AMS group, starting with SPICE models. The intent of this proposal was a portable definition of models expected by users. There has been no activity on this particular proposal, but at least two groups are working on implementing SPICE models using the 1076.1 language. We have not heard of any issues discovered as part of these projects. We therefore believe that the issue of SPICE compatibility has been addressed adequately by the 1076.1 Working Group and its Language Design Committee. If there are any issues left, then the balloter must be more specific and describe in detail the perceived deficiencies. Otherwise, we will mark this comment report as resolved. =============================================================================== Revised Definitions ~~~~~~~~~~~~~~~~~~~ None. ===============================================================================