From jabarby Thu Oct 13 08:11:13 1994 To: 1076-1-request@epfl.ch Subject: please add me to the <1076-1@epfl.ch> mailing list Return-Receipt-To: jabarby please add me to the (VHDL-A) <1076-1@epfl.ch> mailing list. Thank you. -- Jim Barby VLSI Group, University of Waterloo, Waterloo, Ontario, Canada, N2L 3G1 519-888-4567x3995, FAX 519-746-5195 From alain.vachoux@leg.de.epfl.ch Thu Oct 13 08:43:16 1994 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Thu, 13 Oct 94 08:43:13 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Thu, 13 Oct 94 08:43:07 -0400 Message-Id: <9410131243.AA05247@vlsi.uwaterloo.ca> Received: from c3imac12.epfl.ch by sicmail.epfl.ch with SMTP (PP) id <14696-0@sicmail.epfl.ch>; Thu, 13 Oct 1994 13:42:48 +0100 X-Sender: vachoux@c3i9.epfl.ch Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="========================_40381980==_" Date: Thu, 13 Oct 1994 13:45:16 +0100 To: jabarby@vlsi.uwaterloo.ca From: alain.vachoux@leg.de.epfl.ch (Alain Vachoux EPFL-LEG/C3i) Subject: Re: please add me to the <1076-1@epfl.ch> mailing list --========================_40381980==_ Content-Type: text/plain; charset="us-ascii" >please add me to the (VHDL-A) <1076-1@epfl.ch> mailing list. You are now registered in the 1076.1 mailing list. The effective modification of the mailing list will take place on next night. I'd like to know in addition whether you'd like to be a voting member or not. The 1076.1 working group considers two different kinds of balloting processes: - An internal voting process to agree on directions to take to develop the VHDL-A proposal. This process does not imply the IEEE at all. I enclose a copy of our Policies document to let you know about this process. You may want to become a 1076.1 voting member; please let me know. - The official IEEE balloting process to adopt a working group proposal as a new IEEE standard. I also enclose the official form to let register you to the IEEE. Thanks for your interest. Regards, Alain Vachoux 1076.1 Secretary --========================_40381980==_ Content-Type: multipart/header-set; boundary="========================_40381980==_D" --========================_40381980==_D Content-Transfer-Encoding: base64 Content-Type: application/applefile; name="%Policies_(mar_94)" Content-Disposition: attachment; filename="%Policies_(mar_94)" AAUWBwACAAAAAAAAAAAAAAAAAAAAAAAAAAMAAAADAAAAPgAAABEAAAAJAAAATwAAACAA AAACAAAAbwAAAahQb2xpY2llcyAobWFyIDk0KVRFWFRRRUQxAQAA+QBeAAAAAAAAAAAA AAAAAAAAAAAAAAABAAAAAU4AAABOAAAAWmFsdWF0aW9ub24gIzEpYXNlKW9kbwAAZHJ3 MkRBRDJgEVBvbGljaWVzIChtYXIgOTQpAgAAAFRFWFRRRUQxAQAAAFRFWFRRRUQxAQAA +QBeAAAAAAAAAAAAAAAAAAAAAAAAqXZp4QAAMtMAAAGoAFaJEUV4ZW1wbGVzIFNMIE5B TkQyOTRuICMxKWFzZSlvZG8AAGRydzJEQUQyYAADAf8AAAj/////ABz//wAAVokNRI5j b21wb3NpdGlvbmMgU2V0NG4gIzEpYXNlKW9kbwAAZHJ3MkRBRDJgAAEB/wAACP////8A HP//AAAB4RJuZQAAACoACQZNb25hY28AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAEAAYABAAAABQB2gAoAdz/6AHEAAAAAAAAAAAAAAAAAQAAAAFOAAAATgAA AFoBEXCIIigAAAAcAFoAAkVGTlQAAAAaRVRBQgAAACZFUUVEAAAAMgPr//8AAAAAAAAA AAPr//8AAAAuAAAAAAPr//8AAAA2AAAAAA== --========================_40381980==_D Content-Type: text/plain; name="Policies_(mar_94)"; charset="us-ascii" Content-Disposition: attachment; filename="Policies_(mar_94)" Policies of the 1076.1 Working Group on Analog Extensions to VHDL ============================ March 1994 1. Purpose ---------- The purpose of 1076.1 Working Group (WG) is to develop analog extensions to VHDL, i.e. to enhance VHDL such that it can support the description and simulation of circuits that exhibit continuous behavior over time and over amplitude. As of summer 1993 the IEEE Computer Society, through its Standards Activity Board (SAB), has approved the 1076.1 WG under PAR1076.1. The purpose of this document is to establish policies for the operation of the 1076.1 Working Group. 2. Organization --------------- Under IEEE policies and procedures, each Working Group needs to elect an Executive Committee consisting of a chair, a vice-chair, and a secretary. The WG chair is elected by the members of DASC, the Design Automation Standards Committee. The WG is free to establish rules how to organize itself in any other respect, including how the other committee members are elected. In order to facilitate holding WG meetings in both the United States and in Europe, the 1076.1 Working Group intends that each WG position (with the exception of the WG secretary) be held by two people, a chair and a vice-chair. One of the two should be European, the other American. All (except the WG chair, as described above) are elected by the voting members of the WG. The WG forms subcommittees as it sees fit. Each subcommittee has a chair and a vice-chair. Currently, there are four subcommittees: - Requirements - Language Design - Validation - Documentation 3. Membership ------------- Under IEEE policies and procedures, each Working Group needs to establish rules regarding its membership, in particular with respect to voting rights. The following policy is designed to allow all who are interested to be voting members, while disqualifying those who do not take the time to fulfill their obligations. 3.1. The 1076.1 Working Group maintains a mailing list that is open to any interested individual or organization. Material posted to the mailing list is owned by the WG. Use of such material for other than WG purposes requires approval of the Executive Committee. 3.2. Everyone who is on the 1076.1 mailing list is automatically a non-voting member of the Working Group. Non-voting members will remain on the 1076.1 mailing list as long as they are interested. 3.3. The mailing list is publicly available on the repository maintained by the Working Group. Non-voting members can have their name withheld from the published mailing list. 3.4. Everyone who attends a Working Group meeting automatically becomes a voting member of the Working Group. 3.5. Anyone who wants to change his or her status (e.g. a non-voting member to become a voting member, or vice-versa) needs only to send email to the 1076.1 Secretary and request it. Status changes received during an ongoing vote will be processed when the vote closes, i.e. the list of voting members is frozen from the date of announcement of the vote until the vote closes. Current members of the 1076.1 mailing list will be asked through email to sign up as voting members if interested. New members to the mailing list will be asked at sign up time whether they want to be voting members. 3.6. According to IEEE rules Working Group Chairs are not eligible to be voting members. 3.7. To remain a voting member you must fulfill your obligation to vote on matters presented for a vote. 3.8. The following rules govern disqualification from voting WG member status: a. Failure to vote (abstention counts as a vote). Reinstatement is automatic upon request after the 1st "offense." Upon second and subsequent "offenses", the Executive Committee can reinstate voting member status after hearing the reason for the "offense." b. Exception: You may send mail if you know you will be out of town for a period oftime to prevent disqualification in the event of a vote during your absence. 4. Votes and Elections ---------------------- 4.1. Votes Under IEEE policies and procedures, a WG needs a quorum to conduct business. A quorum is 50% of the voting membership. The Working Group votes on issues that are related to its process and the results it produces. The Executive Committee decides what specific issues have to be voted on by the WG members. However, if 20% of the voting members request that an issue be voted on, the Executive Committee has to abide. 4.2. Elections The WG chair is elected for a two year term by the DASC membership. The vice-chair, the secretary and the subcommittee chairs and vice-chairs are elected by the voting members of the WG for a two year term. The election is by the "approval" method where a voter may vote for any number of candidates and the one with the most votes wins. Candidates will be nominated by the membership. 4.3. Process Issues to vote on are sent to the mailing list prior to a WG meeting. The issues are discussed at that meeting. The arguments of the discussion are then also sent to the mailing list, to educate the voting members who did not attend the meeting. This second mailing marks the beginning of the voting period. In the case of elections the voting period begins when the nominations for WG positions are sent to the mailing list. The voting material sent to the mailing list includes a deadline for returning the votes, which must allow for a voting period of at least three weeks. Votes have to be returned to the WG Secretary either by email or by fax. The result is announced to the mailing list ASAP, and also at the next WG meeting. 5. Working Group Phases ----------------------- The work on the VHDL extensions consists of several phases, each yielding specific results. Note that some of the phases are overlapping. 5.1. Requirements Gathering This phase consists of gathering and soliciting requirements from as wide an audience as possible. The results are collected in a Requirements Document. 5.2. Requirements Analysis The Requirements Document is analyzed to determine which issues are relevant to the language, and ambiguities and contradictions are resolved. The result is a Design Objective Document (DOD) and a DOD Rationale. 5.3. Language Design During this phase the actual extensions to VHDL are designed, based on the design objectives. This includes both language design as well as extending the canonical simulator model described in the VHDL LRM. The result of this phase is documented in Language Extension Specifications (LES) and in an LES Rationale. 5.4. Language Validation Validation runs in parallel to language design, as it is important to constantly question the design work and provide feedback to the language designers. More formal aspects of validation start at a later time. They include a Requirements Trace, benchmarks, LRM reviews and possibly other reports. 5.5. Language Reference Manual This phase starts after the language design phase but then overlaps with it. The LRM is developed based on the the VHDL'93 LRM and the LESs resulting from the language design work. It only describes the extensions with respect to the VHDL'93 LRM, i.e. it is not a standalone document. 5.6. Standardization This phase consists of several subphases: - Determination of what is in the balloting package. - Formation of a balloting group. This is done by the IEEE. - Ballot according to IEEE rules: 75% of the balloting group must return a vote, and 75% of all returned votes must be positive. - Ballot resolution: All comments must be answered. Resolving negative ballots may require revising the LRM. Ballot and ballot resolution may have to be repeated if the proposed extensions do not pass the ballot. Once it has passed the final step is to submit the draft standard to the SAB's Review Committee. 6. Submissions to the Working Group ----------------------------------- In order to best achieve its goal, the 1076.1 Working Group depends on the active participation of as many people as possible. The WG therefore encourages its members to actively participate in its discussions, to provide feedback (like reviews) and to suggest improvements (e.g. new requirements, proposals for organizational or policy changes, etc.). Such input can be provided in any form, although the most likely methods will be presentations at Working Group meetings and memoranda. The WG distinguishes between two kinds of issues: - Current issues. These are the issues that the WG is currently working on. Discussion on such topics at meetings or on email is completely free and is not affected by the rules described below. - Other issues. These include issues that the WG has already approved by vote, and future issues that the WG will have to consider. Submissions related to such issues are processed according to the following rules. a) Submissions to the 1076.1 Working Group go first to the Executive Committee, consisting of the chair, the vice-chair and the secretary. b) Based on the issue raised in the submission the Executive Committee will distribute the submission to one of its subcommittees, as follows: - Organizational and policy issues Executive Committee - Requirements, Design Objectives, Requirements subcommittee Design Objectives Rationale - Organization and rationale for LES Language Design subcommittee - Specific LES LES group leader, through Language Design subcommittee - Validation issues Validation subcommittee - Documentation issues, including LRM Documentation subcommittee c) The group having been assigned a submission investigates its impact and, together with the Executive Committee, prepares a response proposing how the submission should be handled. If necessary, other subcommittees or people can be involved to prepare the response, at the discretion of the assigned subcommittee. d) The response is presented to the 1076.1 community ASAP, at the latest by the next Working Group meeting. Submissions made less than a calendar month prior to a Working Group meeting will be brought to the attention of the participants at the meeting, but are not due at that meeting. The Executive Committee decides whether the response to a submission is presented and discussed at the WG meeting when it is due. e) The Working Group has the final decision on how the submission will be handled. The decision is based on the response prepared by the assigned subcommittee and is made by casting a vote according to the rules described in section 4.3. 7. Addresses ------------ 1076.1 Executive Committee Chair: Jean-Michel Berge Centre National d'Etudes de Telecommunications CNS-CCI Chemin du Vieux Chene - BP 98 F-38243 Meylan Cedex France phone: (+3376) 764-335 fax: (+3376) 903-443 email: berge@cns.cnet.fr Vice-chair: Ernst Christen Analogy Inc. P.O. Box 1669 9205 SW Gemini Drive Beaverton, OR 97075-1669 USA phone: (503) 520-2720 fax: (503) 643-3361 email: christen@analogy.com Secretary: Alain Vachoux Swiss Federal Institute of Technology Electronics Laboratories LEG/C3i - Ecublens CH-1015 Lausanne Switzerland phone: (+4121) 693-6984 fax: (+4121) 693-4663 email: alain.vachoux@leg.de.epfl.ch 1076.1 Mailing List Reflectors (information to all members of the mailing list): 1076-1@epfl.ch European address ahdl1076@cadence.com US address Submit new names to be put on the mailing list to 1076-1-request@epfl.ch Submit to 1076.1 Executive Committee only: 1076-1-exec@epfl.ch 1076.1 Repositories: ftp nestor.epfl.ch (or ftp 128.178.50.20) Material related to the 1076.1 WG is in the directory incoming/vhdl/analog ftp ftp.uu.net (or ftp 192.48.96.9) Material related to the 1076.1 WG is in the directory doc/standards/ieee/1076.1/analog --========================_40381980==_D-- --========================_40381980==_ Content-Type: multipart/header-set; boundary="========================_40381980==_D" --========================_40381980==_D Content-Transfer-Encoding: base64 Content-Type: application/applefile; name="%Balloting_group_(mail)" Content-Disposition: attachment; filename="%Balloting_group_(mail)" AAUWBwACAAAAAAAAAAAAAAAAAAAAAAAAAAMAAAADAAAAPgAAABYAAAAJAAAAVAAAACAA AAACAAAAdAAAAahCYWxsb3RpbmcgZ3JvdXAgKG1haWwpVEVYVFFFRDEBAAAPAB0AAAAA AAAAAAAAAAAAAAAAAAAAAAEAAAABTgAAAE4AAABa//xXwcABZhJgyCBuAAwwrv/6IG4A CDCu//wfLv//Tq0aQmFsbG90aW5nIGdyb3VwIChtYWlsKS5iYWtvAgAAAAAAVEVYVFFF RDEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACquyRvAAAOWQAAAagfLcY8SG3Eph8u//9O rQ4KfgFCZx8u//9Ibe3UTq0OKhAfSIA/ADAfEC4AEGc0QmcfLv//SG3t1Ehu//hOrQ9K EB9mXh8u//9OrQ4iQmcfLv//SG3t1Ehu//hOrQ9KHh9gQEJnHy7//0ht7dRIbv/4Tq0O +hAfZipCZx8u//9IbcVOAAAAKgAJBk1vbmFjbwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAQABgAEAAAAFAAAADQAGP/0AAD//wAADlgAAA5YAAABAAAAAU4A AABOAAAAWgEQyDQiKAAAABwAWgACRUZOVAAAABpFVEFCAAAAJkVRRUQAAAAyA+v//wAA AAAAAAAAA+v//wAAAC4AAAAAA+v//wAAADYAAAAA --========================_40381980==_D Content-Type: text/plain; name="Balloting_group_(mail)"; charset="us-ascii" Content-Disposition: attachment; filename="Balloting_group_(mail)" ******************************************************************************* ****** ATTENTION ANYONE INTERESTED IN ANALOG AND DIGITAL DESIGN!! ********* ******************************************************************************* BELOW IS AN APPLICATION FORM TO JOIN THE ANALOG EXTENSION TO VHDL BALLOTING GROUP. IF YOU ARE INTERESTED "CUT" ALONG THE DOTTED LINE, FILL OUT THE FORM AND EITHER: MAKE A HARD COPY AND MAIL IT TO ROSEMARY TENNIS AT THE ADDRESS GIVEN AT THE BOTTOM. OR: MAKE A HARD COPY AND FAX IT TO ROSEMARY TENNIS AT 908-562-1571 OR: E-MAIL IT TO r.tennis@ieee.org NOTE: Sorry about duplicate invitations, please ignore them. The balloting list was compiled by: S. Peter Liebmann : peterl@compass-da.com and Stan Krolikoski: stank@compass-da.com and consists of the following groups: 1076.1 working group, SCC30, VITAL, MHDL, DASC, 1076 balloting group, Japan Electronics Industrial Association and ECSI. If anyone can think of any other interested parties, please send them this invitation or contact Peter Liebmann. --------------------------------cut here--------------------------------------- The Design Automation Standards Committee of the IEEE Computer Society invites you to ballot on: P1076.1: STANDARD VHDL LANGUAGE REFERENCE MANUAL- ANALOG EXTENSIONS RETURN DEADLINE: November 1, 1994 SCOPE: The IEEE 1076 Language has limited Analog Modeling capability. Appropriate Language extensions will be defined to extend the language to better support mixed analog/digital simulation. Most likely extensions will be in the form of new language extensions encapsulated as separable from the 1076 language. Hence the request for a separate PAR. PURPOSE: Add better mixed mode simulation capability to the IEEE 1076 Language. Your Category of Interest in this Standards Ballot (i.e. do you use or produce the items in this standard?): User Producer Academic General (NOTE: Please choose only ONE of the above. If you have any combination of Interests, check the General Interest Category) Please Print Clearly: New address? Yes or No Name: Phone: Company: Fax: Mailing Address: E-Mail: IEEE or Computer Society Membership Number Check here if not a member of IEEE or the Computer Society Balloter's Responsibility If you become part of the balloting body, you will have 30 days to review and respond to the draft. In order for the Sponsor Ballot to be valid, at least 75% of the ballots sent must be returned. For that reason: VOTERS HAVE AN OBLIGATION TO RESPOND. Eligible voters are members of the IEEE or Computer Society and non-members will comment as Parties of Interest. For Membership Application, Call (908) 562-5524 Signature: Date: If you want confirmation that this form has been received by the IEEE Standards Office, please enclose a stamped, pre-addressed post card along with this form. Please return by November 1, 1994 to: Rosemary Tennis IEEE Standards Office 445 Hoes Lane, PO. Box 1331 Piscataway, NJ 08855-1331 Fax: 908/562-1571 E-mail: r.tennis@ieee.org --========================_40381980==_D-- --========================_40381980==_ Content-Type: text/plain; charset="us-ascii" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Alain Vachoux Swiss Federal Institute of Technology (EPFL) Dept. of Electrical Engineering Integrated Systems Center (C3i) e-mail: alain.vachoux@leg.de.epfl.ch EL-Ecublens Phone: (+41) 21 693 69 84 CH-1015 Lausanne, Switzerland Fax: (+41) 21 693 46 63 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --========================_40381980==_-- From 1076-1-request@sicmail.epfl.ch Thu Oct 13 22:20:21 1994 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Thu, 13 Oct 94 22:20:19 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Thu, 13 Oct 94 22:20:15 -0400 Received: from mailgate.Cadence.COM by sicmail.epfl.ch with SMTP (PP) id <18509-0@sicmail.epfl.ch>; Fri, 14 Oct 1994 03:00:50 +0100 Received: (from smap@localhost) by mailgate.cadence.com (8.6.8/8.6.8) id TAA08924 for <1076-1@epfl.ch>; Thu, 13 Oct 1994 19:00:27 -0700 Received: from cds2072.cadence.com(158.140.24.54) by mailgate.cadence.com via smap (V1.0mjr) id sma008861; Thu Oct 13 18:59:58 1994 Received: from mailgate.cadence.com (mailgate.cadence.com [158.140.2.1]) by cds2072.Cadence.COM (8.6.4/8.6.8) with ESMTP id SAA01299 for ; Thu, 13 Oct 1994 18:59:13 -0700 Received: (from smap@localhost) by mailgate.cadence.com (8.6.8/8.6.8) id SAA08834 for ; Thu, 13 Oct 1994 18:58:23 -0700 Received: from vhdl.vhdl.org(198.31.14.3) by mailgate.cadence.com via smap (V1.0mjr) id sma008801; Thu Oct 13 18:57:34 1994 Received: by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA20514; Thu, 13 Oct 94 18:56:05 PDT Date: Thu, 13 Oct 94 18:56:05 PDT From: jose@vhdl.org (Jose Torres) Message-Id: <9410140156.AA20514@vhdl.vhdl.org> To: math@vhdl.org Subject: 9/94 minutes from Math package meeting VHDL MATH PACKAGE WORKING GROUP, P1076.2 Minutes of meeting in Grenoble, 23 September 1994 Present: Jose Torres, Synopsys (Chair), jose@synopsys.com Peter Sinander, European Space Agency (Minutes), psi@wd.estec.esa.nl Sylvie Hurat, Thomson-CSF, hurat@sctf.thomson.fr Adam Morawiec, Artemis/ECSI, Adam.Morawiec@imag.fr Next meeting: most probably at VIUF in November at Washington, DC, USA. 1. INTRODUCTION P1076.2 Working Group members are: - J. Torres, Synopsys (Chair) - C. Swart, Mentor Graphics - A. Zamfirescu, Intergraph - D. Hanson, University of Mississippi The VHDL math packages consist of basic functions and type conversions for real and complex types, and will be placed in the IEEE library. There are two packages: MATH_REAL and MATH_COMPLEX. A testbench will be prepared for each package, but it will not formally be part of the standard just a reference (see further section 4). 2. NEW RELEASE OF MATH PACKAGE A new release of the math package will be placed on the VI server in October. Several bugs were detected in the previous version, which have been corrected in the new version. The package is available through anonymous ftp from vhdl.org, in the directory /vi/math/package, file names are: math_head.9.30.94.vhd math_body.9.30.94.vhd The packages can be retrieved as follows: ftp vhdl.org username: anonymous password: ftp> cd /vi/math/package ftp> get math_head.9.30.94.vhd ftp> get math_body.9.30.94.vhd ftp> bye 3. PLANNED ACTIVITIES The work on the testbench is still in progress. There is a need for more effort in this task, and anybody that could provide help should contact Jose Torres. The ballot constituency will take place in October/November, by invitation through the math package reflector as well as direct e-mail to certain persons. The balloting is planned for January 1995. The IEEE approval is currently foreseen for mid 1995. There is a possibility that Rita Clover will help with the preparation of the standard, which need to be written according to the IEEE standard format. 4. IMPLEMENTATION DETAILS The body of the math package is written in VHDL, though in most cases simulator vendors will implement it in C-code for optimized performance. The minimum precision is that of the VHDL LRM; minimum 6 bits precision in a range from -1E38 to 1E38 is required, but an implementation is allowed to provide higher precision. Sylvie Hurat stressed the importance of a double precision version of the Math packages becoming available, since this is required for system simulations and analog VHDL. It is important that other WGs (particularly the analog WG) do not define their own packages. It is proposed to ballot the single-precision version of the packages now, and later create a double precision version by overloading the funtions when the double precision data type is defined by the analog WG. No new functions should be added for the double precision versions. See further section 5. It was agreed at the meeting that the precision of the constants declared should at least cover the IEEE-754 double precision accuracy, i.e. 16 digits. It is required that the functions detect and report invalid parameters (out of range), but underflow/overflow detection is optional. The severity level can be defined by the user, with the default being Error. The package will be written to conform with both VHDL-1987 and VHDL-1993. 4. TESTBENCHES AND VERIFICATION APPROACH The testbench, which is not part of the standard and will be provided as a reference only. In principle, the test bench will exercise all data points for all the functions in each package, it will compare the outputs from an implementation against a set of "golden" outputs, and will produce a report with differences found. Final details on the process are still being worked out. It is important to note that the math package results may be slightly different on different workstation combinations due to the workstations particular support for floating point arithmetic, which may not be immediately apparent to the average VHDL user. However, since most workstations use the IEEE-754 floating point format the variations will be limited in practice. 5. OPEN ISSUES Jose Torres has proposed to start the balloting process even though the testbenches have not been completed. This was considered as a practical approach by the meeting participants, since the testbench is not part of the standard. The final decision will be taken by the WG members. It is desirable that all IEEE packages should report errors in a standardized way, so contact is necessary with the other IEEE WGs. The contents of the error messages should also be reviewed to be understandable and useful for the average VHDL user (and not only for numerical experts). The coordination with the analog WG is minimal, no formal feedback has yet been received from this WG. However, Sylvie Hurat who is following that WG stated that they have basically defined what functions they need. Another question is whether double precision reals will be called Real or renamed to a new type called Float. Jose Torres will contact J.-M. Berge or A. Vachoux to obtain formal comments from the analog WG. 6. MISCELLANEOUS Jose Torres mentioned that the activity on the e-mail reflector has been low during the past months, but should increase with the event of the new release of the package and the balloting process. It was stated that no problems are expected with vendors adopting the Math packages, since this topic does not seem to be a controversial one and different vendors have provided input or offered a version of their own packages as a starting point for this standard. From 1076-1-request@sicmail.epfl.ch Fri Oct 14 19:26:53 1994 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Fri, 14 Oct 94 19:26:51 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Fri, 14 Oct 94 19:26:47 -0400 Received: from mailgate.Cadence.COM by sicmail.epfl.ch with SMTP (PP) id <06932-0@sicmail.epfl.ch>; Fri, 14 Oct 1994 23:50:22 +0100 Received: (from smap@localhost) by mailgate.cadence.com (8.6.8/8.6.8) id PAA24860 for <1076-1@epfl.ch>; Fri, 14 Oct 1994 15:50:16 -0700 Received: from cds2072.cadence.com(158.140.24.54) by mailgate.cadence.com via smap (V1.0mjr) id sma024761; Fri Oct 14 15:49:24 1994 Received: from mailgate.cadence.com (mailgate.cadence.com [158.140.2.1]) by cds2072.Cadence.COM (8.6.4/8.6.8) with ESMTP id PAA07861 for ; Fri, 14 Oct 1994 15:49:19 -0700 Received: (from smap@localhost) by mailgate.cadence.com (8.6.8/8.6.8) id PAA24738 for ; Fri, 14 Oct 1994 15:49:16 -0700 Received: from vhdl.vhdl.org(198.31.14.3) by mailgate.cadence.com via smap (V1.0mjr) id sma024685; Fri Oct 14 15:48:49 1994 Received: from chronos.synopsys.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA02527; Fri, 14 Oct 94 15:47:21 PDT Received: from gaea.synopsys.com by chronos.synopsys.com with SMTP id AA21826 (5.65c/IDA-1.4.4 for ); Fri, 14 Oct 1994 15:43:25 -0700 Received: from jose.synopsys.com by gaea.synopsys.com with SMTP id AA28903 (5.65c/IDA-1.4.4 for ); Fri, 14 Oct 1994 15:43:23 -0700 Received: by jose.synopsys.com (4.1/SNPS-Sub02) id AA24261; Fri, 14 Oct 94 15:43:22 PDT Date: Fri, 14 Oct 94 15:43:22 PDT From: jose@Synopsys.COM (Jose Torres) Message-Id: <9410142243.AA24261@jose.synopsys.com> To: math@vhdl.org Subject: vhdl math package (declaration) ------------------------------------------------------------------------ -- -- This source file may be used and distributed without restriction. -- No declarations or definitions shall be included in this package. -- This package cannot be sold or distributed for profit. -- -- **************************************************************** -- * * -- * W A R N I N G * -- * * -- * This DRAFT version IS NOT endorsed or approved by IEEE * -- * * -- **************************************************************** -- -- Title: PACKAGE MATH_REAL -- -- Library: This package shall be compiled into a library -- symbolically named IEEE. -- -- Purpose: VHDL declarations for mathematical package MATH_REAL -- which contains common real constants, common real -- functions, and real trascendental functions. -- -- Author: IEEE VHDL Math Package Study Group -- -- Notes: -- The package body shall be considered the formal definition of -- the semantics of this package. Tool developers may choose to implement -- the package body in the most efficient manner available to them. -- -- History: -- Version 0.1 (Strawman) Jose A. Torres 6/22/92 -- Version 0.2 Jose A. Torres 1/15/93 -- Version 0.3 Jose A. Torres 4/13/93 -- Version 0.4 Jose A. Torres 4/19/93 -- Version 0.5 Jose A. Torres 4/20/93 Added RANDOM() -- Version 0.6 Jose A. Torres 4/23/93 Renamed RANDOM as -- UNIFORM. Modified -- rights banner. -- Version 0.7 Jose A. Torres 5/28/93 Rev up for compatibility -- with package body. -- Version 0.8 Jose A. Torres 9/2/94 Rev up for compatibility -- with package body. -- Version 0.9 Jose A. Torres 9/30/94 Rev up for distribution ------------------------------------------------------------- Library IEEE; Package MATH_REAL is -- -- commonly used constants -- constant MATH_E : real := 2.71828_18284_59045_23536; -- value of e constant MATH_1_E: real := 0.36787_94411_71442_32160; -- value of 1/e constant MATH_PI : real := 3.14159_26535_89793_23846; -- value of pi constant MATH_1_PI : real := 0.31830_98861_83790_67154; -- value of 1/pi constant MATH_LOG_OF_2: real := 0.69314_71805_59945_30942; -- natural log of 2 constant MATH_LOG_OF_10: real := 2.30258_50929_94045_68402; -- natural log of10 constant MATH_LOG2_OF_E: real := 1.44269_50408_88963_4074; -- log base 2 of e constant MATH_LOG10_OF_E: real := 0.43429_44819_03251_82765; -- log base 10 of e constant MATH_SQRT2: real := 1.41421_35623_73095_04880; -- sqrt of 2 constant MATH_SQRT1_2: real := 0.70710_67811_86547_52440; -- sqrt of 1/2 constant MATH_SQRT_PI: real := 1.77245_38509_05516_02730; -- sqrt of pi constant MATH_DEG_TO_RAD: real := 0.01745_32925_19943_29577; -- conversion factor from degree to radian constant MATH_RAD_TO_DEG: real := 57.29577_95130_82320_87685; -- conversion factor from radian to degree -- -- attribute for functions whose implementation is foreign (C native) -- attribute FOREIGN : string; -- predefined attribute in VHDL-1992 -- -- function declarations -- function SIGN (X: real ) return real; -- returns 1.0 if X > 0.0; 0.0 if X == 0.0; -1.0 if X < 0.0 function CEIL (X : real ) return real; -- returns smallest integer value (as real) not less than X function FLOOR (X : real ) return real; -- returns largest integer value (as real) not greater than X function ROUND (X : real ) return real; -- returns integer FLOOR(X + 0.5) if X > 0; -- return integer CEIL(X - 0.5) if X < 0 function FMAX (X, Y : real ) return real; -- returns the algebraically larger of X and Y function FMIN (X, Y : real ) return real; -- returns the algebraically smaller of X and Y procedure UNIFORM (variable Seed1,Seed2:inout integer; variable X:out real); -- returns a pseudo-random number with uniform distribution in the -- interval (0.0, 1.0). -- Before the first call to UNIFORM, the seed values (Seed1, Seed2) must -- be initialized to values in the range [1, 2147483562] and -- [1, 2147483398] respectively. The seed values are modified after -- each call to UNIFORM. -- This random number generator is portable for 32-bit computers, and -- it has period ~2.30584*(10**18) for each set of seed values. -- function SRAND (seed: in integer ) return integer; -- -- sets value of seed for sequence of -- pseudo-random numbers. -- It uses the foreign native C function srand(). attribute FOREIGN of SRAND : function is "C_NATIVE"; function RAND return integer; -- -- returns an integer pseudo-random number with uniform distribution. -- It uses the foreign native C function rand(). -- Seed for the sequence is initialized with the -- SRAND() function and value of the seed is changed every -- time SRAND() is called, but it is not visible. -- The range of generated values is platform dependent. attribute FOREIGN of RAND : function is "C_NATIVE"; function GET_RAND_MAX return integer; -- -- returns the upper bound of the range of the -- pseudo-random numbers generated by RAND(). -- The support for this function is platform dependent, and -- it uses foreign native C functions or constants. -- It may not be available in some platforms. -- Note: the value of (RAND() / GET_RAND_MAX()) is a -- pseudo-random number distributed between 0 & 1. attribute FOREIGN of GET_RAND_MAX : function is "C_NATIVE"; function SQRT (X : real ) return real; -- returns square root of X; X >= 0 function CBRT (X : real ) return real; -- returns cube root of X function "**" (X : integer; Y : real) return real; -- returns Y power of X ==> X**Y; -- error if X = 0 and Y <= 0.0 -- error if X < 0 and Y does not have an integer value function "**" (X : real; Y : real) return real; -- returns Y power of X ==> X**Y; -- error if X = 0.0 and Y <= 0.0 -- error if X < 0.0 and Y does not have an integer value function EXP (X : real ) return real; -- returns e**X; where e = MATH_E function LOG (X : real ) return real; -- returns natural logarithm of X; X > 0 function LOG (BASE: positive; X : real) return real; -- returns logarithm base BASE of X; X > 0 function SIN (X : real ) return real; -- returns sin X; X in radians function COS ( X : real ) return real; -- returns cos X; X in radians function TAN (X : real ) return real; -- returns tan X; X in radians -- X /= ((2k+1) * PI/2), where k is an integer function ASIN (X : real ) return real; -- returns -PI/2 < asin X < PI/2; | X | <= 1 function ACOS (X : real ) return real; -- returns 0 < acos X < PI; | X | <= 1 function ATAN (X : real) return real; -- returns -PI/2 < atan X < PI/2 function ATAN2 (X : real; Y : real) return real; -- returns atan (X/Y); -PI < atan2(X,Y) < PI; Y /= 0.0 function SINH (X : real) return real; -- hyperbolic sine; returns (e**X - e**(-X))/2 function COSH (X : real) return real; -- hyperbolic cosine; returns (e**X + e**(-X))/2 function TANH (X : real) return real; -- hyperbolic tangent; -- returns (e**X - e**(-X))/(e**X + e**(-X)) function ASINH (X : real) return real; -- returns ln( X + sqrt( X**2 + 1)) function ACOSH (X : real) return real; -- returns ln( X + sqrt( X**2 - 1)); X >= 1 function ATANH (X : real) return real; -- returns (ln( (1 + X)/(1 - X)))/2 ; | X | < 1 end MATH_REAL; --------------------------------------------------------------- -- -- This source file may be used and distributed without restriction. -- No declarations or definitions shall be included in this package. -- This package cannot be sold or distributed for profit. -- -- **************************************************************** -- * * -- * W A R N I N G * -- * * -- * This DRAFT version IS NOT endorsed or approved by IEEE * -- * * -- **************************************************************** -- -- Title: PACKAGE MATH_COMPLEX -- -- Purpose: VHDL declarations for mathematical package MATH_COMPLEX -- which contains common complex constants and basic complex -- functions and operations. -- -- Author: IEEE VHDL Math Package Study Group -- -- Notes: -- The package body uses package IEEE.MATH_REAL -- -- The package body shall be considered the formal definition of -- the semantics of this package. Tool developers may choose to implement -- the package body in the most efficient manner available to them. -- -- History: -- Version 0.1 (Strawman) Jose A. Torres 6/22/92 -- Version 0.2 Jose A. Torres 1/15/93 -- Version 0.3 Jose A. Torres 4/13/93 -- Version 0.4 Jose A. Torres 4/19/93 -- Version 0.5 Jose A. Torres 4/20/93 -- Version 0.6 Jose A. Torres 4/23/93 Added unary minus -- and CONJ for polar -- Version 0.7 Jose A. Torres 5/28/93 Rev up for compatibility -- with package body. -- Version 0.8 Jose A. Torres 9/2/94 Rev up for compatibility -- with package body. -- Version 0.9 Jose A. Torres 9/30/94 Rev up for distribution ------------------------------------------------------------- Library IEEE; Package MATH_COMPLEX is type COMPLEX is record RE, IM: real; end record; type COMPLEX_VECTOR is array (integer range <>) of COMPLEX; type COMPLEX_POLAR is record MAG: real; ARG: real; end record; constant CBASE_1: complex := COMPLEX'(1.0, 0.0); constant CBASE_j: complex := COMPLEX'(0.0, 1.0); constant CZERO: complex := COMPLEX'(0.0, 0.0); function CABS(Z: in complex ) return real; -- returns absolute value (magnitude) of Z function CARG(Z: in complex ) return real; -- returns argument (angle) in radians of a complex number function CMPLX(X: in real; Y: in real:= 0.0 ) return complex; -- returns complex number X + iY function "-" (Z: in complex ) return complex; -- unary minus function "-" (Z: in complex_polar ) return complex_polar; -- unary minus function CONJ (Z: in complex) return complex; -- returns complex conjugate function CONJ (Z: in complex_polar) return complex_polar; -- returns complex conjugate function CSQRT(Z: in complex ) return complex_vector; -- returns square root of Z; 2 values function CEXP(Z: in complex ) return complex; -- returns e**Z function COMPLEX_TO_POLAR(Z: in complex ) return complex_polar; -- converts complex to complex_polar function POLAR_TO_COMPLEX(Z: in complex_polar ) return complex; -- converts complex_polar to complex -- arithmetic operators function "+" ( L: in complex; R: in complex ) return complex; function "+" ( L: in complex_polar; R: in complex_polar) return complex; function "+" ( L: in complex_polar; R: in complex ) return complex; function "+" ( L: in complex; R: in complex_polar) return complex; function "+" ( L: in real; R: in complex ) return complex; function "+" ( L: in complex; R: in real ) return complex; function "+" ( L: in real; R: in complex_polar) return complex; function "+" ( L: in complex_polar; R: in real) return complex; function "-" ( L: in complex; R: in complex ) return complex; function "-" ( L: in complex_polar; R: in complex_polar) return complex; function "-" ( L: in complex_polar; R: in complex ) return complex; function "-" ( L: in complex; R: in complex_polar) return complex; function "-" ( L: in real; R: in complex ) return complex; function "-" ( L: in complex; R: in real ) return complex; function "-" ( L: in real; R: in complex_polar) return complex; function "-" ( L: in complex_polar; R: in real) return complex; function "*" ( L: in complex; R: in complex ) return complex; function "*" ( L: in complex_polar; R: in complex_polar) return complex; function "*" ( L: in complex_polar; R: in complex ) return complex; function "*" ( L: in complex; R: in complex_polar) return complex; function "*" ( L: in real; R: in complex ) return complex; function "*" ( L: in complex; R: in real ) return complex; function "*" ( L: in real; R: in complex_polar) return complex; function "*" ( L: in complex_polar; R: in real) return complex; function "/" ( L: in complex; R: in complex ) return complex; function "/" ( L: in complex_polar; R: in complex_polar) return complex; function "/" ( L: in complex_polar; R: in complex ) return complex; function "/" ( L: in complex; R: in complex_polar) return complex; function "/" ( L: in real; R: in complex ) return complex; function "/" ( L: in complex; R: in real ) return complex; function "/" ( L: in real; R: in complex_polar) return complex; function "/" ( L: in complex_polar; R: in real) return complex; end MATH_COMPLEX; From 1076-1-request@sicmail.epfl.ch Fri Oct 14 20:07:47 1994 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Fri, 14 Oct 94 20:07:44 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Fri, 14 Oct 94 20:07:37 -0400 Received: from mailgate.Cadence.COM by sicmail.epfl.ch with SMTP (PP) id <07005-0@sicmail.epfl.ch>; Fri, 14 Oct 1994 23:59:13 +0100 Received: (from smap@localhost) by mailgate.cadence.com (8.6.8/8.6.8) id PAA25302 for <1076-1@epfl.ch>; Fri, 14 Oct 1994 15:59:03 -0700 Received: from cds2072.cadence.com(158.140.24.54) by mailgate.cadence.com via smap (V1.0mjr) id sma025277; Fri Oct 14 15:58:14 1994 Received: from mailgate.cadence.com (mailgate.cadence.com [158.140.2.1]) by cds2072.Cadence.COM (8.6.4/8.6.8) with ESMTP id PAA08196 for ; Fri, 14 Oct 1994 15:58:09 -0700 Received: (from smap@localhost) by mailgate.cadence.com (8.6.8/8.6.8) id PAA25252 for ; Fri, 14 Oct 1994 15:58:03 -0700 Received: from vhdl.vhdl.org(198.31.14.3) by mailgate.cadence.com via smap (V1.0mjr) id sma025231; Fri Oct 14 15:57:29 1994 Received: from chronos.synopsys.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA02535; Fri, 14 Oct 94 15:48:06 PDT Received: from gaea.synopsys.com by chronos.synopsys.com with SMTP id AA21848 (5.65c/IDA-1.4.4 for ); Fri, 14 Oct 1994 15:43:59 -0700 Received: from jose.synopsys.com by gaea.synopsys.com with SMTP id AA28918 (5.65c/IDA-1.4.4 for ); Fri, 14 Oct 1994 15:43:55 -0700 Received: by jose.synopsys.com (4.1/SNPS-Sub02) id AA24266; Fri, 14 Oct 94 15:43:54 PDT Date: Fri, 14 Oct 94 15:43:54 PDT From: jose@Synopsys.COM (Jose Torres) Message-Id: <9410142243.AA24266@jose.synopsys.com> To: math@vhdl.org Subject: VHDL math package (body) -- current version --------------------------------------------------------------- -- -- This source file may be used and distributed without restriction. -- No declarations or definitions shall be included in this package. -- This package cannot be sold or distributed for profit. -- -- **************************************************************** -- * * -- * W A R N I N G * -- * * -- * This DRAFT version IS NOT endorsed or approved by IEEE * -- * * -- **************************************************************** -- -- Title: PACKAGE BODY MATH_REAL -- -- Library: This package shall be compiled into a library -- symbolically named IEEE. -- -- Purpose: VHDL declarations for mathematical package MATH_REAL -- which contains common real constants, common real -- functions, and real trascendental functions. -- -- Author: IEEE VHDL Math Package Study Group -- -- Notes: -- The package body shall be considered the formal definition of -- the semantics of this package. Tool developers may choose to implement -- the package body in the most efficient manner available to them. -- -- Source code and algorithms for this package body comes from the -- following sources: -- IEEE VHDL Math Package Study Group participants, -- U. of Mississippi, Mentor Graphics, Synopsys, -- Viewlogic/Vantage, Communications of the ACM (June 1988, Vol -- 31, Number 6, pp. 747, Pierre L'Ecuyer, Efficient and Portable -- Random Number Generators), Handbook of Mathematical Functions -- by Milton Abramowitz and Irene A. Stegun (Dover), Regents of -- the University of California. -- -- History: -- Version 0.1 Jose A. Torres 4/23/93 First draft -- Version 0.2 Jose A. Torres 5/28/93 Fixed potentially illegal code -- Version 0.3 Jose A. Torres 11/21/93 Fixed code in log,ceil,floor -- and round -- Version 0.4 Jose A. Torres 9/2/94 Modified/fixed code in the -- following functions: -- ceil, floor, round, "**", -- exp, log, sqrt, cbrt, sin, cos, -- asin, acos, atan, atan2, tanh, -- acosh, atanh -- Version 0.9 Jose A. Torres 9/30/94 Rev'd up for distribution. -- and additional changes in sqrt ------------------------------------------------------------- Library IEEE; Package body MATH_REAL is -- -- some constants for use in the package body only -- constant Q_PI : real := MATH_PI/4.0; constant HALF_PI : real := MATH_PI/2.0; constant TWO_PI : real := MATH_PI*2.0; constant MAX_ITER: integer := 27; -- max precision factor for cordic constant MAX_COUNT: integer := 50; -- max count for number of tries constant MIN_EPS: real := 0.000001; -- min eps for convergence criteria -- -- some type declarations for cordic operations -- constant KC : REAL := 6.0725293500888142e-01; -- constant for cordic type REAL_VECTOR is array (NATURAL range <>) of REAL; type NATURAL_VECTOR is array (NATURAL range <>) of NATURAL; subtype REAL_VECTOR_N is REAL_VECTOR (0 to max_iter); subtype REAL_ARR_2 is REAL_VECTOR (0 to 1); subtype REAL_ARR_3 is REAL_VECTOR (0 to 2); subtype QUADRANT is INTEGER range 0 to 3; type CORDIC_MODE_TYPE is (ROTATION, VECTORING); -- -- auxiliary functions for cordic algorithms -- function POWER_OF_2_SERIES (d : NATURAL_VECTOR; initial_value : REAL; number_of_values : NATURAL) return REAL_VECTOR is variable v : REAL_VECTOR (0 to number_of_values); variable temp : REAL := initial_value; variable flag : boolean := true; begin for i in 0 to number_of_values loop v(i) := temp; for p in d'range loop if i = d(p) then flag := false; end if; end loop; if flag then temp := temp/2.0; end if; flag := true; end loop; return v; end POWER_OF_2_SERIES; constant two_at_minus : REAL_VECTOR := POWER_OF_2_SERIES( NATURAL_VECTOR'(100, 90),1.0, MAX_ITER); constant epsilon : REAL_VECTOR_N := ( 7.8539816339744827e-01, 4.6364760900080606e-01, 2.4497866312686413e-01, 1.2435499454676144e-01, 6.2418809995957351e-02, 3.1239833430268277e-02, 1.5623728620476830e-02, 7.8123410601011116e-03, 3.9062301319669717e-03, 1.9531225164788189e-03, 9.7656218955931937e-04, 4.8828121119489829e-04, 2.4414062014936175e-04, 1.2207031189367021e-04, 6.1035156174208768e-05, 3.0517578115526093e-05, 1.5258789061315760e-05, 7.6293945311019699e-06, 3.8146972656064960e-06, 1.9073486328101870e-06, 9.5367431640596080e-07, 4.7683715820308876e-07, 2.3841857910155801e-07, 1.1920928955078067e-07, 5.9604644775390553e-08, 2.9802322387695303e-08, 1.4901161193847654e-08, 7.4505805969238281e-09 ); function CORDIC ( x0 : REAL; y0 : REAL; z0 : REAL; n : NATURAL; -- precision factor CORDIC_MODE : CORDIC_MODE_TYPE -- rotation (z -> 0) -- or vectoring (y -> 0) ) return REAL_ARR_3 is variable x : REAL := x0; variable y : REAL := y0; variable z : REAL := z0; variable x_temp : REAL; begin if CORDIC_MODE = ROTATION then for k in 0 to n loop x_temp := x; if ( z >= 0.0) then x := x - y * two_at_minus(k); y := y + x_temp * two_at_minus(k); z := z - epsilon(k); else x := x + y * two_at_minus(k); y := y - x_temp * two_at_minus(k); z := z + epsilon(k); end if; end loop; else for k in 0 to n loop x_temp := x; if ( y < 0.0) then x := x - y * two_at_minus(k); y := y + x_temp * two_at_minus(k); z := z - epsilon(k); else x := x + y * two_at_minus(k); y := y - x_temp * two_at_minus(k); z := z + epsilon(k); end if; end loop; end if; return REAL_ARR_3'(x, y, z); end CORDIC; -- -- non-trascendental functions -- function SIGN (X: real ) return real is -- returns 1.0 if X > 0.0; 0.0 if X == 0.0; -1.0 if X < 0.0 begin if ( X > 0.0 ) then return 1.0; elsif ( X < 0.0 ) then return -1.0; else return 0.0; end if; end SIGN; function CEIL (X : real ) return real is -- returns smallest integer value (as real) not less than X -- No conversion to an integer type is expected, so truncate cannot -- overflow for large arguments. variable large: real := 1073741824.0; type long is range -1073741824 to 1073741824; -- 2**30 is longer than any single-precision mantissa variable rd: real; begin if abs( X) >= large then return X; else rd := real ( long( X)); if X > 0.0 then if rd >= X then return rd; else return rd + 1.0; end if; elsif X = 0.0 then return 0.0; else if rd <= X then return rd + 1.0; else return rd; end if; end if; end if; end CEIL; function FLOOR (X : real ) return real is -- returns largest integer value (as real) not greater than X -- No conversion to an integer type is expected, so truncate -- cannot overflow for large arguments. -- variable large: real := 1073741824.0; type long is range -1073741824 to 1073741824; -- 2**30 is longer than any single-precision mantissa variable rd: real; begin if abs( X ) >= large then return X; else rd := real ( long( X)); if X > 0.0 then if rd <= X then return rd; else return rd - 1.0; end if; elsif X = 0.0 then return 0.0; else if rd >= X then return rd - 1.0; else return rd; end if; end if; end if; end FLOOR; function ROUND (X : real ) return real is -- returns integer FLOOR(X + 0.5) if X > 0; -- return integer CEIL(X - 0.5) if X < 0 begin if X > 0.0 then return FLOOR(X + 0.5); elsif X < 0.0 then return CEIL( X - 0.5); else return 0.0; end if; end ROUND; function FMAX (X, Y : real ) return real is -- returns the algebraically larger of X and Y begin if X > Y then return X; else return Y; end if; end FMAX; function FMIN (X, Y : real ) return real is -- returns the algebraically smaller of X and Y begin if X < Y then return X; else return Y; end if; end FMIN; -- -- Pseudo-random number generators -- procedure UNIFORM(variable Seed1,Seed2:inout integer;variable X:out real) is -- returns a pseudo-random number with uniform distribution in the -- interval (0.0, 1.0). -- Before the first call to UNIFORM, the seed values (Seed1, Seed2) must -- be initialized to values in the range [1, 2147483562] and -- [1, 2147483398] respectively. The seed values are modified after -- each call to UNIFORM. -- This random number generator is portable for 32-bit computers, and -- it has period ~2.30584*(10**18) for each set of seed values. -- variable z, k: integer; begin k := Seed1/53668; Seed1 := 40014 * (Seed1 - k * 53668) - k * 12211; if Seed1 < 0 then Seed1 := Seed1 + 2147483563; end if; k := Seed2/52774; Seed2 := 40692 * (Seed2 - k * 52774) - k * 3791; if Seed2 < 0 then Seed2 := Seed2 + 2147483399; end if; z := Seed1 - Seed2; if z < 1 then z := z + 2147483562; end if; X := REAL(Z)*4.656613e-10; end UNIFORM; function SRAND (seed: in integer ) return integer is -- -- sets value of seed for sequence of -- pseudo-random numbers. -- Returns the value of the seed. -- It uses the foreign native C function srand(). begin return(-1); -- *** dummy return value for VHDL compliance *** -- (actual return value is the one generated by -- the C function srand()) end SRAND; function RAND return integer is -- -- returns an integer pseudo-random number with uniform distribution. -- It uses the foreign native C function rand(). -- Seed for the sequence is initialized with the -- SRAND() function and value of the seed is changed every -- time SRAND() is called, but it is not visible. -- The range of generated values is platform dependent. begin return(-1); -- *** dummy return value for VHDL compliance *** -- (actual return value is the one generated by -- the C function rand()) end RAND; function GET_RAND_MAX return integer is -- -- returns the upper bound of the range of the -- pseudo-random numbers generated by RAND(). -- The support for this function is platform dependent, and -- it uses foreign native C functions or constants. -- It may not be available in some platforms. -- Note: the value of (RAND / GET_RAND_MAX) is a -- pseudo-random number distributed between 0 & 1. begin return(-1); -- *** dummy return value for VHDL compliance *** -- (actual return value is a function of the platform) end GET_RAND_MAX; -- -- trascendental and trigonometric functions -- function SQRT (X : real ) return real is -- returns square root of X; X >= 0 -- -- Computes square root using the Newton-Raphson approximation: -- F(n+1) = 0.5*[F(n) + x/F(n)]; -- constant eps : real := MIN_EPS; constant relative_err : real := eps*X; variable count : integer := 1; variable inival: real; variable oldval : real ; variable newval : real ; begin -- check validity of argument if ( X < 0.0 ) then assert false report "X < 0 in SQRT(X)" severity ERROR; return (0.0); end if; -- get the square root for special cases if X = 0.0 then return 0.0; else if ( X = 1.0 ) then return 1.0; -- return exact value end if; end if; -- get the square root for general cases inival := exp(log(x)*(0.5)); -- Mathematically correct but imprecise oldval := inival; newval := (X/oldval + oldval)/2.0; -- check for both absolute and relative error while ( (( abs(newval -oldval) > eps ) OR ( abs(newval -oldval) > relative_err)) AND ( count < MAX_COUNT ) ) loop oldval := newval; newval := (X/oldval + oldval)/2.0; count := count + 1; -- for future use if a count limit needed end loop; return newval; end SQRT; function CBRT (X : real ) return real is -- returns cube root of X -- Computes square root using the Newton-Raphson approximation: -- F(n+1) = (1/3)*[2*F(n) + x/F(n)**2]; -- constant eps : real := MIN_EPS; constant relative_err : real := eps*abs(X); variable inival: real; variable xlocal : real := X; variable negative : boolean := X < 0.0; variable oldval : real ; variable newval : real ; variable count : integer := 1; begin -- compute root for special cases if X = 0.0 then return 0.0; elsif ( X = 1.0 ) then return 1.0; else if X = -1.0 then return -1.0; end if; end if; -- compute root for general cases if negative then xlocal := -X; end if; inival := exp(log(xlocal)/(3.0)); -- mathematically correct but -- imprecise oldval := inival; newval := (xlocal/(oldval*oldval) + 2.0*oldval)/3.0; -- check for absolut and relative errors and max count while ( (( abs(newval -oldval) > eps ) OR ( abs(newval -oldval) > relative_err)) AND ( count < MAX_COUNT ) ) loop oldval := newval; newval :=(xlocal/(oldval*oldval) + 2.0*oldval)/3.0; count := count + 1; end loop; if negative then newval := -newval; end if; return newval; end CBRT; function "**" (X : integer; Y : real) return real is -- returns Y power of X ==> X**Y; -- error if X = 0 and Y <= 0.0 -- error if X < 0 and Y does not have an integer value begin -- check validity of argument if ( X = 0 ) and ( Y <= 0.0 ) then assert false report "X = 0 and Y <= 0.0 in X**Y" severity ERROR; return (0.0); end if; if ( X < 0 ) and ( Y /= REAL(INTEGER(Y)) ) then assert false report "X < 0 and Y \= integer in X**Y" severity ERROR; return (0.0); end if; -- compute the result if ( X = 0 ) then return (0.0); end if; return EXP (Y * LOG (REAL(X))); end "**"; function "**" (X : real; Y : real) return real is -- returns Y power of X ==> X**Y; -- error if X = 0.0 and Y <= 0.0 -- error if X < 0.0 and Y does not have an integer value begin -- check validity of argument if ( X = 0.0 ) and ( Y <= 0.0 ) then assert false report "X = 0.0 and Y <= 0.0 in X**Y" severity ERROR; return (0.0); end if; if ( X < 0.0 ) and ( Y /= REAL(INTEGER(Y)) ) then assert false report "X < 0.0 and Y \= integer in X**Y" severity ERROR; return (0.0); end if; -- compute the result if ( X = 0.0 ) then return (0.0); end if; return EXP (Y * LOG (X)); end "**"; function EXP (X : real ) return real is -- returns e**X; where e = MATH_E -- -- This function computes the exponential using the following series: -- exp(x) = 1 + x + x**2/2! + x**3/3! + ... ; x > 0 -- constant eps : real := MIN_EPS; -- precision criteria variable reciprocal: boolean := x < 0.0;-- check sign of argument variable xlocal : real := abs(x); -- use positive value variable oldval: real ; -- following variables are variable count: integer ; variable newval: real ; variable last_term: real ; begin -- compute value for special cases if X = 0.0 then return 1.0; else if X = 1.0 then return MATH_E; end if; end if; -- compute value for general cases oldval := 1.0; last_term := xlocal; newval:= oldval + last_term; count := 2; while ( abs(newval - oldval) > eps OR count < MAX_COUNT ) loop if reciprocal and newval > 1.0E19 then return 0.0; end if; oldval := newval; last_term := (last_term / (real(count))) * xlocal; newval := oldval + last_term; count := count + 1; end loop; if reciprocal then newval := 1.0/newval; end if; return newval; end EXP; -- -- auxiliary functions to compute LOG -- function ILOGB(X: real) return integer IS --return n such that --1 <= abs(x)/2^n < 2 variable n: integer := 0; variable y: real := abs(x); begin if(y = 1.0 or y = 0.0) then return 0; end if; if( y > 1.0) then while y >= 2.0 loop y := y/2.0; n := n+1; end loop; return n; end if; -- O < y < 1 while y < 1.0 loop y := y*2.0; n := n -1; end loop; return n; end ILOGB; function LDEXP(x:real; n:integer) RETURN real IS --return x*2^n begin return x*(2.0 ** n); end LDEXP; function LOG (X : real ) return real IS -- Copyright (c) 1992 Regents of the University of California. -- All rights reserved. -- -- Redistribution and use in source and binary forms, with or without -- modification, are permitted provided that the following conditions -- are met: -- 1. Redistributions of source code must retain the above copyright -- notice, this list of conditions and the following disclaimer. -- 2. Redistributions in binary form must reproduce the above copyright -- notice, this list of conditions and the following disclaimer in the -- documentation and/or other materials provided with the distribution. -- 3. All advertising materials mentioning features or use of this -- software must display the following acknowledgement: -- This product includes software developed by the University of -- California, Berkeley and its contributors. -- 4. Neither the name of the University nor the names of its -- contributors may be used to endorse or promote products derived -- from this software without specific prior written permission. -- -- THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' -- AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, -- THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A -- PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR -- CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, -- EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, -- PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR -- PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY -- OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT -- (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE -- USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH -- DAMAGE. -- -- NOTE: This VHDL version was generated using the C version of the -- original function by the IEEE VHDL Mathematical Package -- Working Group (CS/JT) constant N: integer := 128; -- Table of log(Fj) = logF_head[j] + logF_tail[j], for Fj = 1+j/128. -- Used for generation of extend precision logarithms. -- The constant 35184372088832 is 2^45, so the divide is exact. -- It ensures correct reading of logF_head, even for inaccurate -- decimal-to-binary conversion routines. (Everybody gets the -- right answer for integers less than 2^53.) -- Values for log(F) were generated using error < 10^-57 absolute -- with the bc -l package. type REAL_VECTOR is array (NATURAL range <>) of REAL; constant A1:real := 0.08333333333333178827; constant A2:real := 0.01250000000377174923; constant A3:real := 0.002232139987919447809; constant A4:real := 0.0004348877777076145742; constant logF_head:real_vector(0 TO N) := ( 0.0, 0.007782140442060381246, 0.015504186535963526694, 0.023167059281547608406, 0.030771658666765233647, 0.038318864302141264488, 0.045809536031242714670, 0.053244514518837604555, 0.060624621816486978786, 0.067950661908525944454, 0.075223421237524235039, 0.082443669210988446138, 0.089612158689760690322, 0.096729626458454731618, 0.103796793681567578460, 0.110814366340264314203, 0.117783035656430001836, 0.124703478501032805070, 0.131576357788617315236, 0.138402322859292326029, 0.145182009844575077295, 0.151916042025732167530, 0.158605030176659056451, 0.165249572895390883786, 0.171850256926518341060, 0.178407657472689606947, 0.184922338493834104156, 0.191394852999565046047, 0.197825743329758552135, 0.204215541428766300668, 0.210564769107350002741, 0.216873938300523150246, 0.223143551314024080056, 0.229374101064877322642, 0.235566071312860003672, 0.241719936886966024758, 0.247836163904594286577, 0.253915209980732470285, 0.259957524436686071567, 0.265963548496984003577, 0.271933715484010463114, 0.277868451003087102435, 0.283768173130738432519, 0.289633292582948342896, 0.295464212893421063199, 0.301261330578199704177, 0.307025035294827830512, 0.312755710004239517729, 0.318453731118097493890, 0.324119468654316733591, 0.329753286372579168528, 0.335355541920762334484, 0.340926586970454081892, 0.346466767346100823488, 0.351976423156884266063, 0.357455888922231679316, 0.362905493689140712376, 0.368325561158599157352, 0.373716409793814818840, 0.379078352934811846353, 0.384411698910298582632, 0.389716751140440464951, 0.394993808240542421117, 0.400243164127459749579, 0.405465108107819105498, 0.410659924985338875558, 0.415827895143593195825, 0.420969294644237379543, 0.426084395310681429691, 0.431173464818130014464, 0.436236766774527495726, 0.441274560805140936281, 0.446287102628048160113, 0.451274644139630254358, 0.456237433481874177232, 0.461175715122408291790, 0.466089729924533457960, 0.470979715219073113985, 0.475845904869856894947, 0.480688529345570714212, 0.485507815781602403149, 0.490303988045525329653, 0.495077266798034543171, 0.499827869556611403822, 0.504556010751912253908, 0.509261901790523552335, 0.513945751101346104405, 0.518607764208354637958, 0.523248143765158602036, 0.527867089620485785417, 0.532464798869114019908, 0.537041465897345915436, 0.541597282432121573947, 0.546132437597407260909, 0.550647117952394182793, 0.555141507540611200965, 0.559615787935399566777, 0.564070138285387656651, 0.568504735352689749561, 0.572919753562018740922, 0.577315365035246941260, 0.581691739635061821900, 0.586049045003164792433, 0.590387446602107957005, 0.594707107746216934174, 0.599008189645246602594, 0.603290851438941899687, 0.607555250224322662688, 0.611801541106615331955, 0.616029877215623855590, 0.620240409751204424537, 0.624433288012369303032, 0.628608659422752680256, 0.632766669570628437213, 0.636907462236194987781, 0.641031179420679109171, 0.645137961373620782978, 0.649227946625615004450, 0.653301272011958644725, 0.657358072709030238911, 0.661398482245203922502, 0.665422632544505177065, 0.669430653942981734871, 0.673422675212350441142, 0.677398823590920073911, 0.681359224807238206267, 0.685304003098281100392, 0.689233281238557538017, 0.693147180560117703862); constant logF_tail:real_vector(0 TO N) := ( 0.0, -0.00000000000000543229938420049, 0.00000000000000172745674997061, -0.00000000000001323017818229233, -0.00000000000001154527628289872, -0.00000000000000466529469958300, 0.00000000000005148849572685810, -0.00000000000002532168943117445, -0.00000000000005213620639136504, -0.00000000000001819506003016881, 0.00000000000006329065958724544, 0.00000000000008614512936087814, -0.00000000000007355770219435028, 0.00000000000009638067658552277, 0.00000000000007598636597194141, 0.00000000000002579999128306990, -0.00000000000004654729747598444, -0.00000000000007556920687451336, 0.00000000000010195735223708472, -0.00000000000017319034406422306, -0.00000000000007718001336828098, 0.00000000000010980754099855238, -0.00000000000002047235780046195, -0.00000000000008372091099235912, 0.00000000000014088127937111135, 0.00000000000012869017157588257, 0.00000000000017788850778198106, 0.00000000000006440856150696891, 0.00000000000016132822667240822, -0.00000000000007540916511956188, -0.00000000000000036507188831790, 0.00000000000009120937249914984, 0.00000000000018567570959796010, -0.00000000000003149265065191483, -0.00000000000009309459495196889, 0.00000000000017914338601329117, -0.00000000000001302979717330866, 0.00000000000023097385217586939, 0.00000000000023999540484211737, 0.00000000000015393776174455408, -0.00000000000036870428315837678, 0.00000000000036920375082080089, -0.00000000000009383417223663699, 0.00000000000009433398189512690, 0.00000000000041481318704258568, -0.00000000000003792316480209314, 0.00000000000008403156304792424, -0.00000000000034262934348285429, 0.00000000000043712191957429145, -0.00000000000010475750058776541, -0.00000000000011118671389559323, 0.00000000000037549577257259853, 0.00000000000013912841212197565, 0.00000000000010775743037572640, 0.00000000000029391859187648000, -0.00000000000042790509060060774, 0.00000000000022774076114039555, 0.00000000000010849569622967912, -0.00000000000023073801945705758, 0.00000000000015761203773969435, 0.00000000000003345710269544082, -0.00000000000041525158063436123, 0.00000000000032655698896907146, -0.00000000000044704265010452446, 0.00000000000034527647952039772, -0.00000000000007048962392109746, 0.00000000000011776978751369214, -0.00000000000010774341461609578, 0.00000000000021863343293215910, 0.00000000000024132639491333131, 0.00000000000039057462209830700, -0.00000000000026570679203560751, 0.00000000000037135141919592021, -0.00000000000017166921336082431, -0.00000000000028658285157914353, -0.00000000000023812542263446809, 0.00000000000006576659768580062, -0.00000000000028210143846181267, 0.00000000000010701931762114254, 0.00000000000018119346366441110, 0.00000000000009840465278232627, -0.00000000000033149150282752542, -0.00000000000018302857356041668, -0.00000000000016207400156744949, 0.00000000000048303314949553201, -0.00000000000071560553172382115, 0.00000000000088821239518571855, -0.00000000000030900580513238244, -0.00000000000061076551972851496, 0.00000000000035659969663347830, 0.00000000000035782396591276383, -0.00000000000046226087001544578, 0.00000000000062279762917225156, 0.00000000000072838947272065741, 0.00000000000026809646615211673, -0.00000000000010960825046059278, 0.00000000000002311949383800537, -0.00000000000058469058005299247, -0.00000000000002103748251144494, -0.00000000000023323182945587408, -0.00000000000042333694288141916, -0.00000000000043933937969737844, 0.00000000000041341647073835565, 0.00000000000006841763641591466, 0.00000000000047585534004430641, 0.00000000000083679678674757695, -0.00000000000085763734646658640, 0.00000000000021913281229340092, -0.00000000000062242842536431148, -0.00000000000010983594325438430, 0.00000000000065310431377633651, -0.00000000000047580199021710769, -0.00000000000037854251265457040, 0.00000000000040939233218678664, 0.00000000000087424383914858291, 0.00000000000025218188456842882, -0.00000000000003608131360422557, -0.00000000000050518555924280902, 0.00000000000078699403323355317, -0.00000000000067020876961949060, 0.00000000000016108575753932458, 0.00000000000058527188436251509, -0.00000000000035246757297904791, -0.00000000000018372084495629058, 0.00000000000088606689813494916, 0.00000000000066486268071468700, 0.00000000000063831615170646519, 0.00000000000025144230728376072, -0.00000000000017239444525614834); variable m, j:integer; variable F1, f2, g, q, u, u2, v: real; variable zero:real := 0.0;--made variable so no constant folding occurs variable one:real := 1.0; --made variable so no constant folding occurs -- double logb(), ldexp(); variable u1:real; begin -- check validity of argument if ( x <= 0.0 ) then assert false report "X <= 0 in LOG(X)" severity ERROR; return(REAL'LOW); end if; -- Argument reduction: 1 <= g < 2; x/2^m = g; -- y = F*(1 + f/F) for |f| <= 2^-8 m := ilogb(x); g := ldexp(x, -m); j := integer(real(N)*(g-1.0)); -- C code adds 0.5 for rounding F1 := (1.0/real(N)) * real(j) + 1.0; --F1*128 is an integer in [128,512] f2 := g - F1; -- Approximate expansion for log(1+f2/F1) ~= u + q g := 1.0/(2.0*F1+f2); u := 2.0*f2*g; v := u*u; q := u*v*(A1 + v*(A2 + v*(A3 + v*A4))); -- case 1: u1 = u rounded to 2^-43 absolute. Since u < 2^-8, -- u1 has at most 35 bits, and F1*u1 is exact, as F1 has < 8 bits. -- It also adds exactly to |m*log2_hi + log_F_head[j] | < 750 -- if ( j /= 0 or m /= 0) then u1 := u + 513.0; u1 := u1 - 513.0; -- case 2: |1-x| < 1/256.The m- and j- dependent terms are zero -- u1 = u to 24 bits. -- else u1 := u; --TRUNC(u1); --in c this is u1 = (double) (float) (u1) end if; u2 := (2.0*(f2 - F1*u1) - u1*f2) * g; -- u1 + u2 = 2f/(2F+f) to extra precision. -- log(x) = log(2^m*F1*(1+f2/F1)) = -- (m*log2_hi+logF_head(j)+u1) + (m*log2_lo+logF_tail(j)+q); -- (exact) + (tiny) u1 := u1 + real(m)*logF_head(N) + logF_head(j); -- exact u2 := (u2 + logF_tail(j)) + q; -- tiny u2 := u2 + logF_tail(N)*real(m); return (u1 + u2); end LOG; function LOG (BASE: positive; X : real) return real is -- returns logarithm base BASE of X; X > 0 begin -- check validity of argument if ( x <= 0.0 ) then assert false report "X <= 0.0 in LOG(BASE, X)" severity ERROR; return(REAL'LOW); end if; -- compute the value return ( LOG(X)/LOG(REAL(BASE))); end LOG; function SIN (X : real ) return real is -- returns sin X; X in radians variable n : INTEGER; variable nx : real; constant eps : real := MIN_EPS; begin if (abs(x) < eps) then return (0.0); elsif ( x > 0.0) then nx := x / MATH_PI; nx := nx - floor(nx); if (nx < eps) then return (0.0); end if; else nx := x / MATH_PI; nx := nx - ceil(nx); if (abs(nx) < eps) then return (0.0); end if; end if; if (x < 1.6 ) and (x > -1.6) then return CORDIC( KC, 0.0, x, 27, ROTATION)(1); end if; n := INTEGER( x / HALF_PI ); case QUADRANT( n mod 4 ) is when 0 => return CORDIC( KC, 0.0, x - REAL(n) * HALF_PI, 27, ROTATION)(1); when 1 => return CORDIC( KC, 0.0, x - REAL(n) * HALF_PI, 27, ROTATION)(0); when 2 => return -CORDIC( KC, 0.0, x - REAL(n) * HALF_PI, 27, ROTATION)(1); when 3 => return -CORDIC( KC, 0.0, x - REAL(n) * HALF_PI, 27, ROTATION)(0); end case; end SIN; function COS (x : REAL) return REAL is -- returns cos X; X in radians variable n : INTEGER; variable xlocal, int_part : real; constant eps : real := MIN_EPS; begin if (abs(x) = HALF_PI) then return (0.0); elsif ( x > 0.0) then xlocal := x / HALF_PI; int_part := floor(xlocal); xlocal := xlocal - int_part; if (xlocal < eps) and ((INTEGER(int_part) rem 2) = 1) then return (0.0); end if; else xlocal := x / HALF_PI; int_part := ceil(xlocal); xlocal := xlocal - int_part; if (abs(xlocal) < eps) and ((INTEGER(int_part) rem 2) = 1) then return (0.0); end if; end if; if (x < 1.6 ) and (x > -1.6) then return CORDIC( KC, 0.0, x, 27, ROTATION)(0); end if; n := INTEGER( x / HALF_PI ); case QUADRANT( n mod 4 ) is when 0 => return CORDIC( KC, 0.0, x - REAL(n) * HALF_PI, 27, ROTATION)(0); when 1 => return -CORDIC( KC, 0.0, x - REAL(n) * HALF_PI, 27, ROTATION)(1); when 2 => return -CORDIC( KC, 0.0, x - REAL(n) * HALF_PI, 27, ROTATION)(0); when 3 => return CORDIC( KC, 0.0, x - REAL(n) * HALF_PI, 27, ROTATION)(1); end case; end COS; function TAN (x : REAL) return REAL is -- returns tan X; X in radians -- X /= ((2k+1) * PI/2), where k is an integer variable n : INTEGER := INTEGER( x / HALF_PI ); variable v : REAL_ARR_3 := CORDIC( KC, 0.0, x - REAL(n) * HALF_PI, 27, ROTATION); begin if n mod 2 = 0 then return v(1)/v(0); else return -v(0)/v(1); end if; end TAN; function ASIN (x : real ) return real is -- returns -PI/2 < asin X < PI/2; | X | <= 1 begin if abs x > 1.0 then assert false report "Out of range parameter passed to ASIN" severity ERROR; return x; elsif abs x = 0.0 then return 0.0; elsif abs x < 0.9 then return atan(x/(sqrt(1.0 - x*x))); elsif x > 0.0 then return HALF_PI - atan(sqrt(1.0 - x*x)/x); else return - HALF_PI + atan((sqrt(1.0 - x*x))/x); end if; end ASIN; function ACOS (x : REAL) return REAL is -- returns 0 < acos X < PI; | X | <= 1 begin if abs x > 1.0 then assert false report "Out of range parameter passed to ACOS" severity ERROR; return x; elsif abs x = 1.0 then return 0.0; elsif abs x > 0.9 then if x > 0.0 then return atan(sqrt(1.0 - x*x)/x); else return MATH_PI - atan(sqrt(1.0 - x*x)/x); end if; else return HALF_PI - atan(x/sqrt(1.0 - x*x)); end if; end ACOS; function ATAN (x : REAL) return REAL is -- returns -PI/2 < atan X < PI/2 begin return CORDIC( 1.0, x, 0.0, 27, VECTORING )(2); end ATAN; function ATAN2 (x : REAL; y : REAL) return REAL is -- returns atan (X/Y); -PI < atan2(X,Y) < PI; Y /= 0.0 begin if y = 0.0 then assert false report "atan2(x, 0.0) is undetermined, returned 0,0" severity NOTE; return 0.0; end if; if x = 0.0 then if y > 0.0 then return 0.0; else return MATH_PI; end if; end if; if y > 0.0 then if x > 0.0 then return CORDIC( y, x, 0.0, 27, VECTORING )(2); else return -CORDIC( y, -x, 0.0, 27, VECTORING )(2); end if; else if x > 0.0 then return MATH_PI - CORDIC( -y, x, 0.0, 27, VECTORING )(2); else return -MATH_PI + CORDIC( -y, -x, 0.0, 27, VECTORING )(2); end if; end if; end ATAN2; function SINH (X : real) return real is -- hyperbolic sine; returns (e**X - e**(-X))/2 begin return ( (EXP(X) - EXP(-X))/2.0 ); end SINH; function COSH (X : real) return real is -- hyperbolic cosine; returns (e**X + e**(-X))/2 begin return ( (EXP(X) + EXP(-X))/2.0 ); end COSH; function TANH (X : real) return real is -- hyperbolic tangent; -- returns (e**X - e**(-X))/(e**X + e**(-X)) variable xlocal, pos_result: real; variable negative: boolean; begin negative := ( x < 0.0); if negative then xlocal := -x; else xlocal := x; end if; if ( xlocal <= 1.0e-10 ) then pos_result := xlocal; elsif ( xlocal > 22.0 ) then pos_result := 1.0; else pos_result := (EXP(xlocal)-EXP(-xlocal))/(EXP(xlocal)+EXP(-xlocal)); end if; if negative then return -pos_result; else return pos_result; end if; end TANH; function ASINH (X : real) return real is -- returns ln( X + sqrt( X**2 + 1)) begin return ( LOG( X + SQRT( X**2 + 1.0)) ); end ASINH; function ACOSH (X : real) return real is -- returns ln( X + sqrt( X**2 - 1)); X >= 1 begin if abs x < 1.0 then assert false report "Out of range parameter passed to ACOSH" severity ERROR; return x; end if; return ( LOG( X + SQRT( X**2 - 1.0)) ); end ACOSH; function ATANH (X : real) return real is -- returns (ln( (1 + X)/(1 - X)))/2 ; | X | < 1 begin if abs x >= 1.0 then assert false report "Out of range parameter passed to ATANH" severity ERROR; return x; end if; return( LOG( (1.0+X)/(1.0-X) )/2.0 ); end ATANH; end MATH_REAL; --------------------------------------------------------------- -- -- This source file may be used and distributed without restriction. -- No declarations or definitions shall be included in this package. -- This package cannot be sold or distributed for profit. -- -- **************************************************************** -- * * -- * W A R N I N G * -- * * -- * This DRAFT version IS NOT endorsed or approved by IEEE * -- * * -- **************************************************************** -- -- Title: PACKAGE BODY MATH_COMPLEX -- -- Purpose: VHDL declarations for mathematical package MATH_COMPLEX -- which contains common complex constants and basic complex -- functions and operations. -- -- Author: IEEE VHDL Math Package Study Group -- -- Notes: -- The package body uses package IEEE.MATH_REAL -- -- The package body shall be considered the formal definition of -- the semantics of this package. Tool developers may choose to implement -- the package body in the most efficient manner available to them. -- -- Source code for this package body comes from the following -- following sources: -- IEEE VHDL Math Package Study Group participants, -- U. of Mississippi, Mentor Graphics, Synopsys, -- Viewlogic/Vantage -- -- History: -- Version 0.1 Jose A. Torres 4/23/93 First draft -- Version 0.2 Jose A. Torres 5/28/93 Fixed potentially illegal code -- Version 0.3 Jose A. Torres 9/2/94 Fixed COMPLEX_TO_POLAR() -- Version 0.9 Jose A. Torres 9/30/94 Rev'd up for distribution -- ------------------------------------------------------------- Library IEEE; Use IEEE.MATH_REAL.all; -- real trascendental operations Package body MATH_COMPLEX is function CABS(Z: in complex ) return real is -- returns absolute value (magnitude) of Z variable ztemp : complex_polar; begin ztemp := COMPLEX_TO_POLAR(Z); return ztemp.mag; end CABS; function CARG(Z: in complex ) return real is -- returns argument (angle) in radians of a complex number variable ztemp : complex_polar; begin ztemp := COMPLEX_TO_POLAR(Z); return ztemp.arg; end CARG; function CMPLX(X: in real; Y: in real := 0.0 ) return complex is -- returns complex number X + iY begin return COMPLEX'(X, Y); end CMPLX; function "-" (Z: in complex ) return complex is -- unary minus; returns -x -jy for z= x + jy begin return COMPLEX'(-z.Re, -z.Im); end "-"; function "-" (Z: in complex_polar ) return complex_polar is -- unary minus; returns (z.mag, z.arg + MATH_PI) begin return COMPLEX_POLAR'(z.mag, z.arg + MATH_PI); end "-"; function CONJ (Z: in complex) return complex is -- returns complex conjugate (x-jy for z = x+ jy) begin return COMPLEX'(z.Re, -z.Im); end CONJ; function CONJ (Z: in complex_polar) return complex_polar is -- returns complex conjugate (z.mag, -z.arg) begin return COMPLEX_POLAR'(z.mag, -z.arg); end CONJ; function CSQRT(Z: in complex ) return complex_vector is -- returns square root of Z; 2 values variable ztemp : complex_polar; variable zout : complex_vector (0 to 1); variable temp : real; begin ztemp := COMPLEX_TO_POLAR(Z); temp := SQRT(ztemp.mag); zout(0).re := temp*COS(ztemp.arg/2.0); zout(0).im := temp*SIN(ztemp.arg/2.0); zout(1).re := temp*COS(ztemp.arg/2.0 + MATH_PI); zout(1).im := temp*SIN(ztemp.arg/2.0 + MATH_PI); return zout; end CSQRT; function CEXP(Z: in complex ) return complex is -- returns e**Z begin return COMPLEX'(EXP(Z.re)*COS(Z.im), EXP(Z.re)*SIN(Z.im)); end CEXP; function COMPLEX_TO_POLAR(Z: in complex ) return complex_polar is -- converts complex to complex_polar begin if ( z.re = 0.0 ) then if ( z.im = 0.0 ) then return COMPLEX_POLAR'(0.0, 0.0); elsif ( z.im > 0.0 ) then return COMPLEX_POLAR'(z.im, MATH_PI/2.0); else return COMPLEX_POLAR'(-z.im, -MATH_PI/2.0); end if; end if; return COMPLEX_POLAR'(sqrt(z.re**2 + z.im**2),atan2(z.im,z.re)); end COMPLEX_TO_POLAR; function POLAR_TO_COMPLEX(Z: in complex_polar ) return complex is -- converts complex_polar to complex begin return COMPLEX'( z.mag*cos(z.arg), z.mag*sin(z.arg) ); end POLAR_TO_COMPLEX; -- -- arithmetic operators -- function "+" ( L: in complex; R: in complex ) return complex is begin return COMPLEX'(L.Re + R.Re, L.Im + R.Im); end "+"; function "+" (L: in complex_polar; R: in complex_polar) return complex is variable zL, zR : complex; begin zL := POLAR_TO_COMPLEX( L ); zR := POLAR_TO_COMPLEX( R ); return COMPLEX'(zL.Re + zR.Re, zL.Im + zR.Im); end "+"; function "+" ( L: in complex_polar; R: in complex ) return complex is variable zL : complex; begin zL := POLAR_TO_COMPLEX( L ); return COMPLEX'(zL.Re + R.Re, zL.Im + R.Im); end "+"; function "+" ( L: in complex; R: in complex_polar) return complex is variable zR : complex; begin zR := POLAR_TO_COMPLEX( R ); return COMPLEX'(L.Re + zR.Re, L.Im + zR.Im); end "+"; function "+" ( L: in real; R: in complex ) return complex is begin return COMPLEX'(L + R.Re, R.Im); end "+"; function "+" ( L: in complex; R: in real ) return complex is begin return COMPLEX'(L.Re + R, L.Im); end "+"; function "+" ( L: in real; R: in complex_polar) return complex is variable zR : complex; begin zR := POLAR_TO_COMPLEX( R ); return COMPLEX'(L + zR.Re, zR.Im); end "+"; function "+" ( L: in complex_polar; R: in real) return complex is variable zL : complex; begin zL := POLAR_TO_COMPLEX( L ); return COMPLEX'(zL.Re + R, zL.Im); end "+"; function "-" ( L: in complex; R: in complex ) return complex is begin return COMPLEX'(L.Re - R.Re, L.Im - R.Im); end "-"; function "-" ( L: in complex_polar; R: in complex_polar) return complex is variable zL, zR : complex; begin zL := POLAR_TO_COMPLEX( L ); zR := POLAR_TO_COMPLEX( R ); return COMPLEX'(zL.Re - zR.Re, zL.Im - zR.Im); end "-"; function "-" ( L: in complex_polar; R: in complex ) return complex is variable zL : complex; begin zL := POLAR_TO_COMPLEX( L ); return COMPLEX'(zL.Re - R.Re, zL.Im - R.Im); end "-"; function "-" ( L: in complex; R: in complex_polar) return complex is variable zR : complex; begin zR := POLAR_TO_COMPLEX( R ); return COMPLEX'(L.Re - zR.Re, L.Im - zR.Im); end "-"; function "-" ( L: in real; R: in complex ) return complex is begin return COMPLEX'(L - R.Re, -1.0 * R.Im); end "-"; function "-" ( L: in complex; R: in real ) return complex is begin return COMPLEX'(L.Re - R, L.Im); end "-"; function "-" ( L: in real; R: in complex_polar) return complex is variable zR : complex; begin zR := POLAR_TO_COMPLEX( R ); return COMPLEX'(L - zR.Re, -1.0*zR.Im); end "-"; function "-" ( L: in complex_polar; R: in real) return complex is variable zL : complex; begin zL := POLAR_TO_COMPLEX( L ); return COMPLEX'(zL.Re - R, zL.Im); end "-"; function "*" ( L: in complex; R: in complex ) return complex is begin return COMPLEX'(L.Re * R.Re - L.Im * R.Im, L.Re * R.Im + L.Im * R.Re); end "*"; function "*" ( L: in complex_polar; R: in complex_polar) return complex is variable zout : complex_polar; begin zout.mag := L.mag * R.mag; zout.arg := L.arg + R.arg; return POLAR_TO_COMPLEX(zout); end "*"; function "*" ( L: in complex_polar; R: in complex ) return complex is variable zL : complex; begin zL := POLAR_TO_COMPLEX( L ); return COMPLEX'(zL.Re*R.Re - zL.Im * R.Im, zL.Re * R.Im + zL.Im*R.Re); end "*"; function "*" ( L: in complex; R: in complex_polar) return complex is variable zR : complex; begin zR := POLAR_TO_COMPLEX( R ); return COMPLEX'(L.Re*zR.Re - L.Im * zR.Im, L.Re * zR.Im + L.Im*zR.Re); end "*"; function "*" ( L: in real; R: in complex ) return complex is begin return COMPLEX'(L * R.Re, L * R.Im); end "*"; function "*" ( L: in complex; R: in real ) return complex is begin return COMPLEX'(L.Re * R, L.Im * R); end "*"; function "*" ( L: in real; R: in complex_polar) return complex is variable zR : complex; begin zR := POLAR_TO_COMPLEX( R ); return COMPLEX'(L * zR.Re, L * zR.Im); end "*"; function "*" ( L: in complex_polar; R: in real) return complex is variable zL : complex; begin zL := POLAR_TO_COMPLEX( L ); return COMPLEX'(zL.Re * R, zL.Im * R); end "*"; function "/" ( L: in complex; R: in complex ) return complex is variable magrsq : REAL := R.Re ** 2 + R.Im ** 2; begin if (magrsq = 0.0) then assert FALSE report "Attempt to divide by (0,0)" severity ERROR; return COMPLEX'(REAL'RIGHT, REAL'RIGHT); else return COMPLEX'( (L.Re * R.Re + L.Im * R.Im) / magrsq, (L.Im * R.Re - L.Re * R.Im) / magrsq); end if; end "/"; function "/" ( L: in complex_polar; R: in complex_polar) return complex is variable zout : complex_polar; begin if (R.mag = 0.0) then assert FALSE report "Attempt to divide by (0,0)" severity ERROR; return COMPLEX'(REAL'RIGHT, REAL'RIGHT); else zout.mag := L.mag/R.mag; zout.arg := L.arg - R.arg; return POLAR_TO_COMPLEX(zout); end if; end "/"; function "/" ( L: in complex_polar; R: in complex ) return complex is variable zL : complex; variable temp : REAL := R.Re ** 2 + R.Im ** 2; begin if (temp = 0.0) then assert FALSE report "Attempt to divide by (0.0,0.0)" severity ERROR; return COMPLEX'(REAL'RIGHT, REAL'RIGHT); else zL := POLAR_TO_COMPLEX( L ); return COMPLEX'( (zL.Re * R.Re + zL.Im * R.Im) / temp, (zL.Im * R.Re - zL.Re * R.Im) / temp); end if; end "/"; function "/" ( L: in complex; R: in complex_polar) return complex is variable zR : complex := POLAR_TO_COMPLEX( R ); variable temp : REAL := zR.Re ** 2 + zR.Im ** 2; begin if (R.mag = 0.0) or (temp = 0.0) then assert FALSE report "Attempt to divide by (0.0,0.0)" severity ERROR; return COMPLEX'(REAL'RIGHT, REAL'RIGHT); else return COMPLEX'( (L.Re * zR.Re + L.Im * zR.Im) / temp, (L.Im * zR.Re - L.Re * zR.Im) / temp); end if; end "/"; function "/" ( L: in real; R: in complex ) return complex is variable temp : REAL := R.Re ** 2 + R.Im ** 2; begin if (temp = 0.0) then assert FALSE report "Attempt to divide by (0.0,0.0)" severity ERROR; return COMPLEX'(REAL'RIGHT, REAL'RIGHT); else temp := L / temp; return COMPLEX'( temp * R.Re, -temp * R.Im ); end if; end "/"; function "/" ( L: in complex; R: in real ) return complex is begin if (R = 0.0) then assert FALSE report "Attempt to divide by (0.0,0.0)" severity ERROR; return COMPLEX'(REAL'RIGHT, REAL'RIGHT); else return COMPLEX'(L.Re / R, L.Im / R); end if; end "/"; function "/" ( L: in real; R: in complex_polar) return complex is variable zR : complex := POLAR_TO_COMPLEX( R ); variable temp : REAL := zR.Re ** 2 + zR.Im ** 2; begin if (R.mag = 0.0) or (temp = 0.0) then assert FALSE report "Attempt to divide by (0.0,0.0)" severity ERROR; return COMPLEX'(REAL'RIGHT, REAL'RIGHT); else temp := L / temp; return COMPLEX'( temp * zR.Re, -temp * zR.Im ); end if; end "/"; function "/" ( L: in complex_polar; R: in real) return complex is variable zL : complex := POLAR_TO_COMPLEX( L ); begin if (R = 0.0) then assert FALSE report "Attempt to divide by (0.0,0.0)" severity ERROR; return COMPLEX'(REAL'RIGHT, REAL'RIGHT); else return COMPLEX'(zL.Re / R, zL.Im / R); end if; end "/"; end MATH_COMPLEX; From 1076-1-request@sicmail.epfl.ch Mon Oct 17 14:46:32 1994 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Mon, 17 Oct 94 14:46:28 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Mon, 17 Oct 94 14:46:22 -0400 Received: from mailgate.Cadence.COM by sicmail.epfl.ch with SMTP (PP) id <08107-0@sicmail.epfl.ch>; Mon, 17 Oct 1994 19:15:22 +0100 Received: (from smap@localhost) by mailgate.cadence.com (8.6.8/8.6.8) id LAA11113 for <1076-1@epfl.ch>; Mon, 17 Oct 1994 11:15:13 -0700 Received: from cds2072.cadence.com(158.140.24.54) by mailgate.cadence.com via smap (V1.0mjr) id sma011026; Mon Oct 17 11:14:36 1994 Received: from mailgate.cadence.com (mailgate.cadence.com [158.140.2.1]) by cds2072.Cadence.COM (8.6.4/8.6.8) with ESMTP id LAA23846 for ; Mon, 17 Oct 1994 11:14:34 -0700 Received: (from smap@localhost) by mailgate.cadence.com (8.6.8/8.6.8) id LAA10121; Mon, 17 Oct 1994 11:05:25 -0700 Received: from vhdl.vhdl.org(198.31.14.3) by mailgate.cadence.com via smap (V1.0mjr) id sma009992; Mon Oct 17 11:04:41 1994 Received: by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA07571; Mon, 17 Oct 94 10:58:16 PDT Date: Mon, 17 Oct 94 10:58:16 PDT From: jose@vhdl.org (Jose Torres) Message-Id: <9410171758.AA07571@vhdl.vhdl.org> To: analog@vhdl.org, isac@vhdl.org, math@vhdl.org, parallel@vhdl.org, tac@vhdl.org, vhdledif@vhdl.org, vhdlsynth@vhdl.org, vital@vhdl.org, waves@vhdl.org Subject: Call for participants in the VHDL Math Package balloting group ************************************************************************* ATTENTION! STANDARD VHDL MATHEMATICAL PACKAGES ARE COMING .... ************************************************************************* YOU ARE INVITED TO PARTICIPATE IN THE BALLOTING GROUP for STANDARDIZING VHDL MATHEMATICAL PACKAGES. IF INTERESTED, PLEASE USE THE APPLICATION FORM that appears below. "CUT" along the dotted line, fill out the form and either: Send a hard copy by mail to Rosemary Tennis at the address given at the bottom, or Fax it to Rosemary Tennis at 908-562-1571, or E-mail to rtennis@stdsmail.ieee.org For e-mail, please make sure to enter Re: P1076.2 in the subject line. If you are interested in previewing the packages, these can be downloaded from the vhdl.org machine. The packages are in ftp: //vhdl.org/vi/math/package/math_head.9.30.94.vhd //vhdl.org/vi/math/package/math_body.9.30.94.vhd or //vhdl.org/vi/math/package/math_package.tar.Z or in other words: ftp vhdl.org username: anonymous password: ftp> cd /vi/math/package ftp> get math_package.tar.Z ftp> bye Please send all technical feedback on these packages to: math-request@vhdl.org Thank you, - Jose A. Torres, Working Group Chair, PAR 1076.2 (jose@vhdl.org) ----------------------------- cut here ---------------------------------------- The Design Automation Standards Committee of the IEEE Computer Society invites you to ballot on P1076.2: Standard VHDL Language Mathematical Package Return deadline: November 17, 1994 SCOPE: Definition of a set of standard mathematical packages for VHDL that include most oftenly used real and complex elementary functions. Examples are trigonometric, hyperbolic, random number generators, etc. PURPOSE:Many model descriptions need this type of mathematical functions. However, IEEE Standard 1076 does not provide as part of the language a pre-defined standard set of mathematical functions for this purpose. This Standard will define a set of packages, with a basic set of mathematical functions, to allow portability of VHDL descriptions that use this type of functionality. Your Category of Interest in this Standards Ballot (i.e., do you use or produce the items in this standard?): User__ Producer__ Academic__ General Interest__ (Note: Please choose only ONE of the above. If you have any combination of Interests, check the General Interest Category) Please Print Clearly: New address? Yes or No Name: Phone: Fax: Company: Mailing Address: EMail: Home address (important: confidential; it will only be used in case of returned mail): IEEE or Computer Society Membership Number_______________ Check here if not a member of IEEE or the Computer Society ______ Balloter's Responsibility If you become part of the balloting body, you will have 30 days to review and respond to the draft. In order for the Sponsor Ballot to be valid, at least 75% of the ballots sent must be returned. For that reason: VOTERS HAVE AN OBLIGATION TO RESPOND. Eligible voters are members of the IEEE or Computer Society and non-members will comment as Parties of Interest. For Membership Application, Call (908) 562-5524 Signature: Date: If you want confirmation that this form has been received by the IEEE Standards Office, please enclose a stamped, pre-addressed post card along with this form (if sent by mail) or indicate that you want a "return receipt" if sent by e-mail. ____Yes, I want to be part of the DASC Balloting Pool. Please return by November 17, 1994 to: Rosemary Tennis IEEE Standards Office 445 Hoes Lane, PO. Box 1331 Piscataway, NJ 08855-1331 Fax: 908/562-1571 From 1076-1-request@sicmail.epfl.ch Tue Oct 18 04:13:08 1994 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Tue, 18 Oct 94 04:13:05 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Tue, 18 Oct 94 04:13:01 -0400 X400-Received: by mta sicmail.epfl.ch in /PRMD=switch/ADMD=arCom/C=ch/; Relayed; Tue, 18 Oct 1994 08:43:02 +0100 Date: Tue, 18 Oct 1994 08:43:02 +0100 X400-Originator: 1076-1-request@sicmail.epfl.ch X400-Recipients: non-disclosure:; X400-Mts-Identifier: [/PRMD=switch/ADMD=arCom/C=ch/;sicmail.ep.290:18.09.94.07.43.02] Priority: Non-Urgent Dl-Expansion-History: 1076-1@epfl.ch ; Tue, 18 Oct 1994 08:43:02 +0100; From: "Jean-michel.Berge" Message-Id: To: analog_reflector <1076-1@epfl.ch> Subject: DASC Schedule/ call for agenda items X-Mailer: Mail*Link SMTP/MS 3.0.0 Here's the November DASC Meeting Schedule as received from Paul today. Note that, as decided in Grenoble, we will try in the future to meet the last day of the DASC. This time our general meeting is on Thursday. If you want to add some points to the agenda (In addition to WG status report and different sub-committee reports), please send your suggestions to me. I will send the agenda on the reflector by the end of this week. Thanks, Jean-Michel IEEE Computer Society Design Automation Standards Committee Meetings in Conjunction with the Fall 1994 VHDL International Users' Forum The Ritz Carlton Hotel Tysons Corner, Virginia 17-18 November 1994 (Note: Due to the small number of groups meeting, no Saturday meetings are scheduled.) Thursday, 17 November 8:00 AM-5:00 PM VHDL Analog Extensions Working Group--P1076.1 Contact: Jean-Michel Berge, Chair +33 76 76 43 35 CNS-CCI +33 76 90 34 43 Chemin Du Vieux Ch#016#ne-BP 98 berge@cns.cnet.fr MEYLAN CEDEX F-38243 FRANCE This meeting will take place in the Plaza room. 8:00 am-12:00 n VHDL Analysis and Standardization Group--P1076 Contact: Clive Charlwood, Chair 415-694-4307 Synopsys, Inc. 415-965-8637 [Fax] 700 East Middlefield Road crc@synopsys.com Mountain View, CA 94043-4033 This meeting will take place in the Attache room. 8:00 am-12:00 n VHDL-EDIF Interoperability Working Group--P1165 Contact: J. Bhasker, Chair 215-770-3983 AT&T Bell Labs 215-770-2773 [Fax] 1247 South Cedar Crest Boulevard, 2R242 jb7@mhcnet.att.com Allentown, PA 18103 This meeting will take place in the Boardroom room. 1:00 pm-5:00 pm VHDL Timing Methodology Working Group--P1076.4 Contact: Victor Berman, Chair 508-446-6276 Cadence Design Systems, Inc. 508-262-6777 [Fax] 270 Billerica Road berman@cadence.com Chelmsford, MA 01824 This meeting will take place in the Attache room. 1:00 pm-5:00 pm VHDL Parallel Simulation Study Group Contact: John Willis, Chair 507-253-8403 IBM Corporation willis@vnet.ibm.com 3605 Hwy. 52 North Rochester, MN 55901-7829 This meeting will take place in the Consulate room. 1:00 pm-5:00 pm System Design & Description Language Study Group Contact: Dave Barton, Chair 703-827-2606 Intermetrics, Inc. 703-827-2609 [Fax] 7918 Jones Branch Drive, Suite 710 McLean, VA 22102 dlb@hudson.wash.inmet.com This meeting will take place in the Boardroom room. 5:30 pm-7:30 pm DASC Steering Committee Meeting & Plenary Session Contact: Paul Menchini, Chair 919-990-9506 Menchini & Associates 919-990-9507 [Fax] 2 Davis Drive mench@mercury.interpath.net P.O. Box 13036 Research Triangle Park, NC 27709-3036 This meeting will take place in the Plaza room. Friday, 18 November 8:00 am-12:00 n VHDL Shared Variables Working Group--P1076a Contact: Steve Bailey 510-659-0901, x227 Vantage Analysis Systems, Inc. 510-659-0129 [Fax] 47211 Lakeview Boulevard sab@vas.com Fremont, CA 94538 This meeting will take place in the Consulate room. 8:00 am-12:00 n VHDL Synthesis Package Working Group--P1076.3 Contact: Alex Zamfirescu 415-691-6426 Intergraph Electronics 415-691-6061 [Fax] 381 East Evelyn Avenue azamfire@edaca.ingr.com Mountain View, CA 94041 a.zamfirescu@ieee.org This meeting will take place in the Boardroom room. 8:00 am-12:00 n Open Modeling Study Group Contact: Gabe Moretti, Chair 415-691-6434 Intergraph Electronics 415-691-9016 [Fax] 381 East Evelyn Avenue gabe@dazixca.ingr.com Mountain View, CA 94041 This study group has been proposed to the DASC Chair and will be discussed at the DASC Steering Committee meeting on 17 November. This meeting will take place in the Ambassador room. 1:00 pm-5:00 pm Object-Oriented Extensions to VHDL Study Group Contact: Doug Dunlop, Chair 703-827-2606 Intermetrics, Inc. 703-827-2609 [Fax] 7918 Jones Branch Drive, Suite 710 dunlop@wash.inmet.com McLean, VA 22102 This meeting will take place in the Consulate room. From 1076-1-request@sicmail.epfl.ch Fri Oct 21 12:15:28 1994 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Fri, 21 Oct 94 12:15:22 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Fri, 21 Oct 94 12:15:15 -0400 Received: from c3imac12.epfl.ch by sicmail.epfl.ch with SMTP (PP) id <21215-0@sicmail.epfl.ch>; Fri, 21 Oct 1994 16:28:27 +0100 X-Sender: vachoux@c3i9.epfl.ch Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 21 Oct 1994 16:30:59 +0100 To: 1076-1@epfl.ch From: alain.vachoux@leg.de.epfl.ch (Alain Vachoux EPFL-LEG/C3i) Subject: Re: Q&A Everybody, Here is the answer of the VHDL-A executive committee (Ernst Christen, Alain Vachoux and myself) to Dan's questions. Nothing has been deleted in Dan's message, but the text has been preceded by '>'. If some of you are not satisfied by the answers to these questions, please react quickly and we will add information or put them on our next agenda. Thanks, Jean-Michel PS: I'm posting this message on behalf of Jean-Michel Berge since his email does not seem to work correctly at this time. Alain. ******************************************************************** >Everyone, >It has been requested that I summarize some of the questions that some >of us consider to be unresolved. Some of these questions regard the >recent changes in charter of the Tiger Team, clarification of the >processes used within the working group and some are more general in >nature. >In general, wrt the Tiger Team, I do not necessarily disagree with the >work being done - especially revisiting architectural issues. >However, I am definately opposed to the establishment of a closed >group under a specific charter, and then changing that charter while >still maintaining closed membership. In addition, having a closed >sub-group that takes precedence over the working group meetings as a >whole is not appropriate. In addition, I believe that the process >does not exist or is ill-defined to make anything that comes out >of the effort useful. >These questions are in general meant for the executive committee to >answer. However, comments from others would probably be helpful and >valuable, as there are a variety of opinions out there (I believe). >Regards, >--Dan >-------------------------------------------------------------------- > >A summary of questions and open issues: > > -- general procedure and objectives questions. > -- TT/LDT objectives, participation, and organization. > -- submission and review of les. >General Procedures and Objectives >--------------------------------- > > Answers to the following questions would clarify what the overall > objectives of the group are and tend to remove the disagreements > caused by differing personal opinions: This is also our main goal. >Q) Would the effort by the WG be better described as either a) >Developing analog extensions for VHDL, or b) Developing an analog >standard based on VHDL. > > a) Please elaborate on which one and why. >From the very beginning in 1989, the activities of first the study group and now the working group were clearly towards developping analog extensions to VHDL. The reason for this comes both from end user requests, many of which are clearly related to mixed analog/digital modeling and simulation, and the understanding that for serious modeling of analog and mixed analog/digital systems, particularly at higher abstraction levels, a fully integrated language environment including both continuous time and discrete time (event-driven) capabilities is a necessity. The spirit of the subPAR Jean-Michel Berge submitted to IEEE was concerning the development of an analog extension for VHDL and it is clearly stated in the Design Objective Document that VHDL-A will be a superset of VHDL'93. So far, this objective has not been contested. >Q) Many of the difficulties of reaching consensus are due to the >different expectations of those participating in the working group. >Of these, > a) What do you believe to be the expectations of the VHDL >community (the group under which this subpar is sponsored)? It is our experience that there are no uniform expectations of the VHDL community. Some people seem to be completely ignorant of any analog, others are indifferent, but those who have a certain interest in analog seem to support our effort and direction. RQ: The following questions are referring to representatives of users and vendors. These notions have no meaning in the context of our Working Group since according to IEEE bylaws working groups consist solely of individuals. We will therefore answer the questions by referring to "individuals with analog design background" and individuals with tool building background". > b) What do you believe to be the expectations of those representing >users participating in the process? A standard language for the description and simulation of analog and mixed analog/digital systems that allows for robust exchange of design information between companies and between tools. As VHDL is gaining more and more momentum, users are expecting more and more from the language. Actually, VHDL is becoming larger at each new version of the standard, but it also allows to define specific guidelines without having to change anything in the syntax (e.g. model interoperability, synthesis guidelines, etc.). Needs from "analog" users ask for more control over the description of their design (i.e. direct access to the behavior), more freedom in the selection of the appropriate abstraction level, and an efficient way to simulate mixed signal systems. > c) What do you believe to be the expectations of the vendors >participating in the process? The ability to provide a uniform language environment to their customers, allowing complete design description for analog, digital and mixed analog/ digital circuits and systems. Once the VHDL-A language has been standardized, the vendors will be able to compete with the simulation capabilities they can provide. Building an efficient analog simulation tool is not an easy task any vendor is able to do. Moreover, building an efficient mixed signal simulation tool is another step. Due to the number of possible simulation algorithms, the competition is promising to be very active (and interesting). > d) Of the vendors participating, in what ways would their > expectations be different from the design/user community as a whole. We believe that the expectations of end users and vendors are quite similar. Differences exist, though, when it comes to motivation. Additionally, "individuals with tool building background" tend to have important knowledge that helps to avoid solutions that are either unimplementable or too expensive. On the other hand, they might be tempted to guide the process towards a solution close to what they are already proposing, or planning to propose, to their own customers. A contribution inspired from a proprietary implemen- tation must not be rejected by the WG because it is coming from a vendor, rather than from a user. A standard always reflects a consensus of all the people involved, both from the end user and the vendor community. > e) How can unrealistic (technical or otherwise) expectations > in the forms of requirements, schedules, etc. be dealt with? There are two questions here: * Unrealistic expectations in the forms of requirements: Requirements have been discussed by the Working Group since 1992, and we seem to be close to reaching consensus on the design objectives. Therefore, potentially unrealistic requirements have already been removed. Note also that several of the people in the WG have related experience from previous (typically proprietary) work, which helps to filter out unrealistic requirements ans expectations. * Unrealistic schedule A standardization process is quite different from a usual project within a company. Ressources are volunteers, and no direct (hierarchical) control can be applied by the different chairs. Furthermore, the process is open, therefore new inputs can delay the process. Unlike projects within a company, a standardization process is mostly based on consensus, not on a dictate or a democratic vote. This starts early, with design objectives, and carries through till balloting time. As we know, predicting how long it will take to reach consensus is almost impossible. This mainly explains that standardization process ever met its original schedule. Unfortunately, schedule is a necessity when chairing such a process. "alone we go faster, together we go further... but with no schedule we go nowhere". Schedules are proposed by the executive committee (based on consultations with its sub-committees) and discussed by the group (this will be the case in the next VHDL-A agenda). A good schedule is short but realistic. An unrealistic schedule has no benefit for the working group and has to be updated. Categorizing something as unrealistic always implies some control by some group of people over the whole process. As an open process, any IEEE standardization process is managed by few people that are accredited by the whole working group. These people are then responsible to filter out any unrealistic input, providing they inform the whole WG with the action to take and they take into account any feedback from the WG. >Q) Which of the following factors define the constraints on the >schedule within the working group sessions? Please explain the >rationale behind the choice(s) made. > > a) Meeting proposed schedules. > b) Meeting technical criteria. > c) Other or combination of above. The 1076.1 WG consists of several subcommittees. A 1076.1 WG session is an opportunity for all these subcommittees to share information and to re-synchronyze everybody on the same track. Subcommittee meetings are held separately, driven by the needs of the subcommittee and organized by its chair. A 1076.1 WG session is essential to meet the schedule, while subcommittee meetings are necessary to meet technical criteria. >Q) What is the process used to define what the schedule is or should >be for completion of the different phases? The schedule is proposed by the Executive Committee after consultation with the subcommittees; it must be accepted by the whole WG. It may change according to a review of the work performed and to a re-evaluation of the time needed to reach the goals of the WG. WG sessions are used to perfom this review. The phases are defined in the Policies document (section 5). The accuracy of such schedules, however, is usually problematic. We have all heard about software projects indicating a completion time between 90% and 200% of the originally estimated duration. In a standardization process, the score is most likely worse, because new input can be fed into the proccess at any time. Q) Long term, there is the option of rolling the 1076.1 work into the VHDL standard as a whole. What is being done to insure that this is possible with the current version of the proposed extensions versus requiring retrofitting at a future time of consolidation? VHDL experts are participating actively in the 1076.1 WG. They monitor the process and screen the proposed analog extensions to detect any inconsistency that might occur relative to the current version of VHDL. Other facts: o VHDL-A will be a superset of VHDL o Various teams are reviewing the dovcuments o A newly formed committee within VASG will have to approve our changes before ballot (from the language point of view) o periodic briefing of VASG about our work are guarantees of the consistency. >Tiger Team / Language Design Team > --------------------------------- Now Language Architecture Team. >Q) The original charter of the Tiger Team (now Language Design Team) >was to hash out differences between the existing LESs. However, wrt >the minutes presented, the charter has been changed by the group to >define general language design issues. > a) As no change in charter was agreed upon by the working > group, under what conditions was this change authorizied? The creation of this team was proposed at the San Diego meeting in order to accomplish two goals: - resolve outstanding issues in language design - pass as much information as possible in the LRM team The first goal includes "hashing out differences between the existing LESs", but consists of a lot more. In fact, at the San Diego meeting, many outstanding language design issues were listed that go beyond the topics addressesd by the LESs. We believe that the Tiger Team has worked within the mandate defined within this meeting. All the work done so far within this group qualifies as resolving outstanding issues, which in our opinion also includes identifying such issues. The TT has reported all of its steps to the WG, including detailed minutes of all its meetings. Also, this team is open to every working group member. Please note also that as shown in Jean-Michel's transparencies of Grenoble (available on the FTP server) and said within the minutes, the LAT is part of the Language Design Team, as are the LES groups. It is the LDT's responsibility to find the best organization suited for the language design phase. b) Why would the current makeup of the Tiger Team be effective as a Language Design Team (as the membership of this group as limited to those that were in the group at its inception)? The Language Design Team consists of: * LES Group teams (4 teams) * LAT (Language Architecture Team) All these teams depend on each other and on the Language Design Team. All teams are open to anybody. However, participation in an LES group is easier because these groups have been using mainly email reflectors to do their work (but this may change). Participation in the LAT is more difficult because this team has chosen to meet regularly for 3 or 4 days, once in Europe and once in the US, making a participation quite time consuming. Still, several people have attended meetings of this team and contributed to its progress that were not in the group at its inception: Jacques Rouillard, Ken Bakalar, Dominique Rodriguez. Others are expected at future meetings. > c) Does reducing the working group meeting to five hours so >because "key people" cannot make certain times and to accomodate >Tiger Team meetings lessen, or perceive to, the role of the working >group? During last DASC in Grenoble, the VHDL-A meeting started (officially at 10h) at 11h and ended at 19h. It was the longest meeting of all the DASC groups. But the fundamental question is not how long a meeting is, but what its purpose should be. Once the purpose is known the time needed to accomplish the purpose can be estimated. In the past, much of the meeting time was spent on educating new attendees about what the effort is all about etc. With the availability of tutorials and conference presentations this need has been addressed, and the WG meeting can now focus on WG business. At the Grenoble meeting this issue was discussed by the WG, with the result that the main purpose of a WG meeting is status reports of the individual sub-committees and coordination between sub-committees. It was estimated that this would take about one day. >Q) Working groups set up by the IEEE tend to be volunteer in nature. >As such, the general participation method can be both sporadic and >varying as well as involve international travel. > a) Given the rigorous proposed schedule for the standardization >process, more suited to full time participants, how is general participation >within the process to be supported? > b) Can any of the problems above be resolved with greater and > more frequent communication that can be shared by all? While it is apparent that a standardization process can be greatly accelerated by full time participants, the reality is that most people are involved sporadically or at most part time. The IEEE rules do not distinguish between such categories, and providing transparency is the task of the WGs. In the 1076.1 WG, it seems possible to have almost full involvement of some people. It is the responsability of the Executive Committee to ensure that the other members of the WG are adequately informed about the work done by the full time participants, in order to allow them to participate at their pace. In the past all information was indeed made available, resulting in many discussions over email, with much positive information fed back to the full time team. We are open to suggestions to even improve the current situation. Note that certain documents (such as minutes of the (old) Tiger Team) have always been published soon after the meetings and between DASC meetings. It is always possible to ask more but you have to know that having sub-groups reporting only during DASC is the way used in many other groups. Anyway, we will try to make the email reflector traffic bigger (note that certain persons already complained it was too much). > c) Large working group meetings have been seen to be a >hindrance to getting anything done as many concepts and previously >discussed items have to be reviewed for new members or members who >do not >attend regularly. Alleviating this would require more extensive >documentation than is currently available. Could clear and up to date >documentation be used to maintain sync within the working group and >also used for the documentation required for the standardization process? The FTP server and various tutorials and conference presentations are serving this purpose. Note that concerning the FTP server, most of the available documentation is only working documentation. This means that documents are not always well polished and complete. > d) As a rule, can working group participants expect meetings > to be 1/2 day in the future (historically: Dallas '93 - 2 days, > Hamburg '93 - 1 day, San Jose '93 - 2 days, Tempe '94 - 2 days, > San Diego '94 - 2 days)? (See also previous answer concerning the purpose of such meetings) We would like to keep a certain flexibility in this domain. We do not have rules but a wish: the general VHDL-A meeting should occur the last day (the third or the second, depending of the DASC) of the DASC meeting in order to allow subgroups (requirements, validation, LAT, LES Groups and documentation ) to meet before and report fresh news. >Processes Related LES Submission and Review >------------------------------------------- >Q) The fact that there are many LESs would indicate that there is an >overall strategy with regard to expressing behavior, domain >conversion, etc. The Rationale document describes how the LESs >support the DOD, but it does not provide a high-level view of language >design. > a) If such a document describing the high-level overview of >the analog extensions exists, can it not be used to maintain focus in >the working group? > b) If there is no document/general understanding, does it not >make the effectiveness of separate LES groups (as they have been set >up) difficult? How is it possible to insure that consistency of the > LESs is maintained? The document exists and is called VHDL-A rationale, version 2.0. As this title is misleading (confusion with the DOD rationale), the document will be renamed VHDL-A Language Architecture Document. It is currently being revised as part of the work of the Language Architecture Team. > c) Within the current process, how does one perform some cost >vs. benefit analysis of proposals? (the basis for this question is >typical of a user at the Hamburg '93 WG meeting who requested that for >every addition to accomodate analog extensions, two existing >constructs be thrown out.) Discussion and compromise. When discussion is too uncertain, votes may be performed (see pins/ports vote last spring). Note that the goal is to reach consensus, which implies that most objections have been processed and the remaining ones understood. While this process does not provide a real cost vs benefit analysis, it guarantees a high level of certainty that the proposal is sound. >Q) Some of us are especially concerned about the process for >submitting, accepting, and revising LESs. As the TT/LDT is now going >through a top-down review/re-write, all of the following are even more >relevant. The LAT uses a top-down approach, while the LESs have been written in a bottom-up manner. This may seem inconsistent, but you have to consider that the bottom-up methodology is very popular among analog designers. Indeed, the LESs have provided the basis for many discussions, trade-offs and compromises, but as with any bottom-up approach there is a danger that commonalities get overlooked. Therefore, although the LAT is fully aware of the concepts defined in the LESs, it has chosen the top-down approach which makes it easier to detect common ground. Once the work of the LAT is complete, changes will occur in the LES groups. These changes may imply the creation of new LES (one about Analog Time has already been identified) , updates and possibly destruction of LES. > a) What are the general criteria for accepting LESs? See before > b) Under what guidelines is a specific LES deemed necessary? >Under what circumstances would a proposed extension be deferred for >possible inclusion in later revisions? The proposed extensions are based on the DOD, which reflects the consensus of the WG for the VHDL-A functionality. Because the whole process operates by consensus, it is the WG who could postpone certain extensions for a later revision. Typically, relevant proposals would be expected to be be made by the LDT. So far, several pieces have been postponed: late typing, overloaded entities, support for noise analysis, dimensional analysis and possibly others. > c) How is the impact on existing LESs evaluated wrt > consistency, design objectives, etc? There are several phases to ensure LES consistency. First, it is the responsability of the LES group to develop the LES compatible with the language architecture and with the other LESs developped by the same group. Then, it is the LAT's responsability to maintain overall consistency. Finally, the validation team is in charge to validate the LES in terms of consistency (against language consistency), in terms of implementability and in terms of DO traceability. We are currently looking for volunteers to reenforce this team but during the whole process, the WG at large is welcome to contribute. > d) If an LES is meant to satisfy one DO, but infringes on > another, what is the resolution process? See previous answer. > e) What process determines that all the requirements for >meeting a DOD are met before an LES becomes accepted (completeness and >dependency requirements)? For example, if LES-xx is defined to meet >DO-oo, but DO-oo also requires LES-yy and LES-zz, what process >prevents LES-xx from being advanced in the specification? No LES are currently accepted. Some versions are written. The LAT is responsible to maintain the consistency between the LESs. No LES may be accepted alone. A whole set of consistent LESs will be proposed to the WG for acceptance. >Q) With regards to the process, would clarification of the overall >design criteria, followed by a resubmission the current LESs through a >process that accounts for the aforementioned criteria be a useful >exercise? For example, move aside all existing LESs, begin with >integrating/re-integrating what is necessary for fundamental >requirements, and proceed from there. > a) Why or why not would this be an acceptable course of action? This process has been proposed and adopted by the LAT. > b) If another objective within this excercise was to simultaneously >prepare necessary documentation and justify the extensions for the >standardization process, could not be exercise be integrated as a >parallel process that does not impact the overall schedule. The documentation team is supposed to work in parallel with the language design work as much as possible. There are two kinds of documentation: the WG documentation which is necessary to design the extensions (DOD, Language Architecture Document, LESs, etc.), and the documentation which will serve as a base for the IEEE ballotting process (mainly the LRM). So far, the 1076.1 Documentation Team is responsible for the second kind of documentation. The first kind of documentation is thightly coupled with the design of the extensions and is therefore created as part of the language design or earlier. >Q) With regards to validation. A couple of major objectives is to >define the completeness of the extensions, as well as weaknesses and >conflicts with the existing VHDL specification. > a) Realistically, what is the impact and dependencies of the > current validation effort on meeting the proposed schedule? i.e., > what level of validation is requiredbefore the LRM can be completed > and submitted with a high level of confidence and at what time must > this be done in the process? This is a domain were no metrics exist. From other standardization efforts we can say that the validation task has to be stopped at one moment or another. Usually, validation task issues rise again during negative ballot resolution. > b) The archive site nestor.epfl.ch has a subdirectory entitled >validation. However, within the directory there is only a list of the >status of the validation effort wrt models etc. As there are many new >extensions being proposed in terms of syntax and semantics, why >haven't these models been posted to the reflector or in the obvious >place on the archive site? We need ressources for the validation task. A call for volunteer has been sent during last meeting in Grenoble and is still open. Two persons have anwered positively. The executive committee is especially attentive to these issues. The archive site is only reflecting this status. From 1076-1-request@sicmail.epfl.ch Mon Oct 24 02:12:09 1994 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Mon, 24 Oct 94 02:12:02 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Mon, 24 Oct 94 02:11:57 -0400 Received: from psi.com by sicmail.epfl.ch with SMTP (PP) id <13194-0@sicmail.epfl.ch>; Mon, 24 Oct 1994 06:45:21 +0100 Received: from analogy.com (analogy.analogy.com) by psi.com (4.1/2.1-PSI/PSINet) id AA04671; Mon, 24 Oct 94 01:45:16 EDT Received: from miller.analogy.com ([149.117.72.253]) by analogy.com (4.1/Shared_Spool_1.3) id AA11336; Sun, 23 Oct 94 22:36:38 PDT Received: from satyr.analogy.com by miller.analogy.com (4.1/SMI-3.2) id AA14107; Sun, 23 Oct 94 22:46:24 PDT Received: by satyr.analogy.com (5.0/SMI-SVR4) id AA12430; Sun, 23 Oct 1994 22:45:27 +0800 Date: Sun, 23 Oct 1994 22:45:27 +0800 From: christen@analogy.com (Ernst Christen) Message-Id: <9410240545.AA12430@satyr.analogy.com> To: 1076-1@epfl.ch Subject: Meeting of Language Architecture Team Content-Length: 704 All, The next meeting of the 1076.1 Language Architecture Team (the former tiger team) will be held at the Compass site in Columbia MD, on the following days: Wednesday, November 16 Friday, November 18 Saturday, November 19 Specific information with the address, instructions how to get there, and an agenda will follow. In order to get an idea about how many people to expect, I'd like to ask everybody who is planning to attend to send me email by November 12. As discussed at the WG meeting in Grenoble, meetings of the LAT are open to all members of the WG. However, the team can best profit from your expertise if you can attend the meeting on all three days. Thanks. Ernst Christen Chair LAT From 1076-1-request@sicmail.epfl.ch Tue Oct 25 18:44:29 1994 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Tue, 25 Oct 94 18:44:24 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Tue, 25 Oct 94 18:44:18 -0400 Received: from sol.compass-da.com by sicmail.epfl.ch with SMTP (PP) id <02098-0@sicmail.epfl.ch>; Tue, 25 Oct 1994 23:06:15 +0100 Received: from adhara.columbia.compass-da.com (adhara.columbia.compass-da.com [162.17.30.14]) by clsi.columbia.compass-da.com (8.6.9/8.6.9) with ESMTP id SAA06531 for <1076-1@epfl.ch>; Tue, 25 Oct 1994 18:05:12 -0400 Reply-To: peterl@compass-da.com Received: (from peterl@localhost) by adhara.columbia.compass-da.com (8.6.9/8.6.9) id MAA01865 for 1076-1@epfl.ch; Mon, 24 Oct 1994 12:22:48 -0400 Date: Mon, 24 Oct 1994 12:22:48 -0400 From: Peter Liebmann Message-Id: <199410241622.MAA01865@adhara.columbia.compass-da.com> To: 1076-1@epfl.ch Subject: LAT minutes, Grenoble, Fr Minutes of the 1076.1 Language Architectural Team Meeting Grenoble, France September 23 - 27, 1994 Before I begin the minutes I, along with the other members of the team, would like to express our gratitude for the hospitality provided to us by CNET, in particular Denis. I. THE MEETING The third meeting of the language architectural team (formally the tiger team) was held at CNET in Grenoble on September 23, 26 and 27, 1994. The meeting was attended by Ernst Christen (Chair), Peter Liebmann, Denis Rouquier, Ken Bakalar, Serge Garcia Sabiro, Dave Smith and Jean-Jose Mayol on the first day, and Ernst Christen , Peter Liebmann, Denis Rouquier, Serge Garcia Sabiro, Dave Smith, Ken Bakalar and Dominique Rodriguez on the final two days. It was decided that Peter Liebmann will compile these as well as all future minutes. II. First Meeting: Sept. 23 1. Open issues Ernst began with a discussion some of the slides he will present at the 1076.1 working group meeting on Sept. 24. He first listed the major open issues or concepts yet to be defined: - interpretation domain - how to define an algorithm independent real simulator - A/D D/A Interaction, analog events - simulation cycle - dc steady state (operating point) - elaboration - packaging - what is to be added to package standard, - an additional analog package - simulation control - scope of names/declarations - implicit object declaration - branches and contributions We all agreed that we will need 5-6 more meetings to finalize the design. This will carry us into March. 2. Accomplishments We briefly talked about our accomplishments which were discussed in the previously minutes. 3. Working guideline for this and future meetings: Ernst also presented working guidelines which were from a Compass - Synopsys - IMT presentation: Upward Compatibility Preserve Strong Typing Separate Declaration and Functionality Unification of Timing Semantics Preserve Determinism Preserve Generality Preserve Scope of VHDL (Gate to System) Preserve intermixed abstraction levels Preserve Concurrency Preserve and Improve Consistency Preserve and Improve Portability No Application-specific Packages Minimize Implementation Impact Maximize Implementation Efficiency 4. How to proceed with this meeting - Review the minutes of the last meeting at Columbia - Review LESs - Are they clear - Is anything missing - how does a particular LES fit with the rest on an architectural level 5. Last minutes: We decided to accept the last meetings minutes as is and address objections and add omissions in these minutes. We went through the minutes section by section and came up with a list of open issues. In this section, I will make reference to the previous minutes by its part and subpart. I will also address open issues with the preface OPEN ISSUE #. PART I. In the second to last paragraph "We managed to complete this work by the end of four-day meeting" is not accurate since there are open issues. Ken brought up the question of wanting discrete rather than continuous time points in the ideal simulator. OPEN ISSUE 1. Is ideal simulator without iterations realistic? (Denis) OPEN ISSUE 2. Static transformation versus dynamic transformation between procedural and equational form? (JJ) PART II. 1. Does the example given for units justify a new analog typing system? OPEN ISSUE 3. Justification of typing system is missing. What is it? (Ken) OPEN ISSUE 4. Not separate dimensional analysis from units. (Serge) 2. OPEN ISSUE 5. Resolve issues with application packages - how to get standards effort started. (DWS) 3. OPEN ISSUE 6. Implicit versus Explicit equations relation to algorithms. (Serge) 4. OK 5. OPEN ISSUE 7. Explore the usage of Interface Node and Interface Quantity along with actual/formal and mapping concepts. (Ken) (This is the question of PORTs containing interface nodes and quantities rather than PINs) PART III. 1. Syntax Ground Rules: In the last meeting we decided on some temporary syntax so we could continue the discussion in an efficient manner. OPEN ISSUE 8. Implications of contributions (Ken) - How does contribution affect syntax ground rules? (Ernst) - What is contribution assignment? (DWS) 2. Expressiveness of procedural part vs equational part: OPEN ISSUE 9. What does equivalence mean between procedural and equational? (Serge) 3. RELATION Structure OPEN ISSUE 10. Variable assignment in relation? Variable lifetime in relation? (JJ) - The discussion of variable assignment we had in Columbia was missing from the minutes (JJ). What we said was that we know there is a problem, but in order to continue our discussion, we will note the problem and deal with it later. - NOTE: Variable assignment has a different meaning in VHDL-A than in the LRM (a variable can be set equal to an unknown in VHDL-A). 4. Concept of Ideal Simulator OPEN ISSUE 11 Ideal simulator needs only discrete time points (Ken). JJ: This section does not address all the discussion. The discussion also addressed shared variables. 5. OK 6. Statement kinds in RELATIONs In this section, we should not give BNF syntax. for example, if_statement defines a syntax, we really mean "if type statement". NOTE: The following discussion is related to the type of statements allowed in a RELATION. This will take us to the end of day 1. 7.1 equation_statement Four more OPEN ISSUEs 12 solving for variables in a equation (Serge) 13 Structured equations (Serge) 14 Non-numeric expressions in equations (Ken) 15 Labels in equations (mandatory, uniqueness?) (Serge) 7.3 Procedure_call_statement OPEN ISSUE 16 Procedure calls in procedurals? (Serge) 8. ddt and integ Three more OPEN ISSUEs 17. Boundary value problems? (Peter) 18. ddt as function? (Serge) 19. ddt of functions? (Serge) 9. Assertion_statement OPEN ISSUE 20. simultaneous assertions? (Ken) 10, 11 OK, 12. Subprograms OPEN ISSUE 21. q'ddt in subprograms? (Serge) 13. OK 14. Transformation Rules from the Procedural Part to the Equational Part: (JJ) What is missing is that we also discussed that there are different ways to define semantics in the procedural part. 15. Semantic rules OPEN ISSUE 22. How do we define a quantity in an if/case branch if that quantity is not evaluated: IF (a > 3) q1 %= expression endif What is q1 when a <= 3? III. Second meeting Sept. 26 We decided to proceed by resolving LES issues, in particular LES-E(3) (sequential assignments) and LES-K (equation statements). We started with a discussion of LES-K but left it for a more general discussion. For completeness, I will include parts of the LES-K discussion although no conclusions were reached. 1. LES-K Serge questioned how we reach a solution or what is a simulator. We started talking about equations vs. unknowns. We did NOT assume the number of equations = number of unknowns. We said there are 2 ways to define a solution: either by direct algorithm or by showing how to write the equations. Dave and Ken questioned whether the direct algorithm is fundamental. If we take the equation approach, we will assume the number of equations = number of unknowns. Serge brought up an interesting problem of polynomials which is one equation with many solutions. We decided to leave this for now and look at procedurals, how they are related to equationals and how the equations which are solved for by an analog kernel are related to procedurals and equationals. 2. Semantics of Procedurals A general idea of a solution was stated by Serge: At a solution, execute the procedural part for each model with the quantities which have been found and the values of the quantities will be the same after the execution. Quantities are invariant at a solution. a) Variables Peter presented the following example to try to define how to deal with variables: PROCEDURAL; QUANTITY q := 1; q %= 2*q +1 -- q will always be -1 VARIABLE v:=1; v :=2*v+1; -- is v always 3? We came up with four choices: 1. variables are reinitialized each time (as in the example above) 2. v = -1 (it is solved for as a quantity 3. v = v(last time point) 4. v = v(last iteration) We agreed to eliminate 4 Serge asked if 3. has meaning in freq. domain. We should decide whether to accept 1, 2 and 3 Ken: look at the consequences in the time domain. QUESTION: we do not want any solution to depend on the number of iterations or number of time points calculated ... this will REALLY break portability. b) Quantities The purpose of the following discussion is to define what happens to undefined quantities and what does "undefined" mean. Another way of looking at the problem is to establish a relation between a procedural and an equational part - can this relation be made static or should it be dynamic. We start with two definitions of a solution: DENIS's approach: A solution is a set of values for each quantity such that using these values to run the procedural no quantities change. A solution is a set of values for some quantities and for the others take the last value and run the same check. ERNST's approach: A solution is defined as stable when it is such that if we enter a set of values for each q in the procedural, and execute each statement as defined we get the same values. Additionally, the equation statements all have the character that the left and right hand sides have the same values. Additionally, there is the requirement that for a quantity for which no quantity assignment appears and which does not appear in the equational part the value which is used is the value for q'last_value. The interaction between the equational and the procedural part lead to a discussion of "are the number of equations to be solved determined dynamically or statically?". For example, consider the following example: procedure if(case) q1 %= 2; else q2 %= 3; endif equational f(q1,q2) == 0; In a static determination, this will be over specified (ie. if "case" is false, we have q1 = q1'last_value and q2 = 3) In a dynamic determination, we alternate between solving between q1 and q2 in the equational part. ERNST argued for the dynamic case saying it will be identical to an equational representation equational if(case) use q1 == 2; else q2 == 3; endif; f(q1,q2) == 0; Why have two meanings? PETER said that the case procedural if(case) q1 == 2; endif; if(case') q2 == 3; endif; equational f(q1,q2) == 0; could lead to code that will work part of the time and then stop working if cond and cond' overlap or do not touch on boundaries since we will get either an over determined set, an under determined set or a solvable set. Also, such code may be hard to debug if cond and cond' are moving targets. Additionally, such a situation can be modeled in the equational part where the full range must be defined in a conditional, so that no functionality is lost. SERGE argued for the static determination and said that listing unknowns in the equational part will solve problems like this. TO SUM UP it was stated - a lot of people complain about the restrictions in procedurals: - to list unknowns in equational part - to previously define quantities used on right hand side. - Can we remove restrictions - ACTION ITEM ... explore it. Also can we reduce number of restrictions (do we lose ease and power of expressions). - SERGE warned that KCL and KVL may cause a problem if the unknowns are not specified in the equational part (we may not be able to tell which are known and which are unknowns). We have at least well defined our differences!! - Static vs. dynamic determination of the set of equations to solve. IV. Third meeting Sept. 27 1. How to define the system of equations we wish to solve We summed up that: we are aiming at defining how to determine the number of equations vs the number of unknowns. The problem was stated by Serge and Ernst: SERGE: How do we know how many equations and how many quantities must be solved for in a system? Determine if there are enough equations. For this, we can easily compute the number of equations, statically or perhaps not as in Ernst's formulation. Because there is no loop in equationals we can find the number of equations in the equational part. For the procedural part we can have some problems since some part of the sequence can be dynamic. For this we can only estimate the maximum or minimum number of equations and sometimes the static number. ERNST: What are the conditions under which the equations created from the procedural and equational are solvable? Number of equations versus quantities. We also stated that we need coupling between the equational and procedural part to define the set of equations. Also, is it desirable to analyze statically or dynamically. Necessary conditions: - for n quantities there are n equations needed - the Jacobian is non-singular (the Jacobian is the matrix formed by taking the partial derivative of the equations with respect to the quantities), To SUM UP we came up with four possible propositions to solve the first condition (REMINDER: the statements in the equational part are "equation_statements"): PROPOSITION 1: Number of equations created by procedural part is static => number of equation_statements is static PROPOSITION 1A Serge's comment about minutes (paraphrased): From the LESs and comments during the last few days, we have proposition 1 + no implicit equation into the PROCEDURAL part. PROPOSITION 2: number of equations created by procedural part plus the number of equation_statements is static PROPOSITION 3: consolidate all statements into the equational section with functions PROPOSITION 4: merge equation_statements and equations in the procedural sections Some discussion: KEN: Dynamic loop has problem in prop 2. Prop1: the mechanism for being static is q'last_value is used for undefined quantities. We all agreed that for 1 and 2, we are not losing functionality - only modeling style. Do we allow implicit equations in procedural part? For example: q1 %= sin(q1) ACTION ITEM: Each person will take the above 4 propositions and generate a list of pluses and minuses for each. 2. Analog drivers We defined three uses of analog drivers: future - to define future analog waveform values reset - to handle discontinuity (two values at same time point) simultaneous resolution of the equation - to hold values which are used for doing the solution. Needed to handle multiple procedural sections and the ordering. It was stated that the ability to define breakpoints solves the first two uses. A full resolution of the driver issue was postponed until we reached further understanding about relations. However, there was discussion which is stated below (thanks to Dave's notes). Observation by Ken: Need a new way to define a function of time since none of the existing mechanisms are sufficient. Comment by David: Another basic mechanism that can be used to address some of these problems is the concept of specifying that a solution must be found at a particular point of time. This can be used to help address the first two issues (future and reset). Suggestion by Ken: Try to approach the problem by using a requirements directed discussion to arrive at a solution, keeping in mind what has been done already. A signal driver's value is determined by a collection of drivers which are resolved to a single value. In the quantity driver there is only one source. The VHDL driver update mechanism is peculiar and used to model the concept of delayed assignment on a gate. It models the transition from the real world to the abstract world. It is not obvious, in particular with respect to inertial delay. His feeling is that a more general capability is needed for analog. The way that quantities get their values is not by resolution of multiple values but simultaneous solution. Serge: What has been attempted is to try to solve some of the problems dedicated to the analog world. Ken and Ernst: The concept of analog driver is clear. Now the concept needs to be more rooted in the description of the relation. How created, how updated, delayed assignments, relation to equation. Ken: A more general mechanism may be to have a special way to define a function. Serge: Are you asking for a specific mechanism that is written by the user? The driver as defined is an implicit mechanism, not defined by the user. It seems that what you are doing is to make the mechanism explicit. Ken: It is only implicit somewhat. It is explicit in that it is noted by the user as a delay. We need to examine each of the areas and determine what is fundamental. A digital signal driver is fundamental to the notion of time. The analog driver is not fundamental to the concept of time. Ernst: It appears that a lot of the qualities of this concept depend on our common understanding of the relation/equations in general. And since we apparently agreed, but have not resolved all of the issues, he suggests that we postpone the discussion of the analog drivers until we have a firm understanding of how the equations are represented and what the mean. It is a lot of issues that depend on the resolution of that. This is one of them. Only when this is resolved can we make a firm statement of how this functionality can be resolved. Peter: What does point three of analog drivers mean? Serge: Because we have multiple relations/procedural parts we need to make sure that the sections are executed independent of order, the result of the evaluation of the sections is independent of the order. Ken: So where is the problem that the driver solves. The definitional form is valid with multiple procedurals. Serge: The vq's are part of the propositional form from the other discussion. Ken: In that sense the notion of a driver is used in the propositional form of the solved state. A variable is simpler than the concept of a driver. Ernst: A driver is a function which returns a value at a given time. Serge: No. A driver is initialized at one moment, after it is registered it is called as needed. 3. Contributions and branches We started a discussion of contribution statements as defined in LES-J(3). This lead to one disagreement and one problem. We all agreed that there can be two duel descriptions, one by branches and the other by contributions (as in LES-J(3)). However, the semantics of the the two descriptions will be different. The semantics of the present description lead to the following: DISAGREEMENT: In LES-J(3) a contribution in a procedural may be given by: (n1,n2).i %= exp; which is translated to: n1.i %= -exp; n2.i %= exp; We all agree that this is what happens, but the way it is defined at present, is if one writes: procedural (n1,n2).i %= exp; (n1,n3).i %= exp1; what we get is exp1 overwrites n1.i ( n2.i is left intact). We are left with: n1.i %= -exp1; n2.i %= exp; n3.i %= exp1; In other words half of (n1,n2).i is overwritten which some of us feel is confusing and makes modeling certain systems very sloppy. Many procedurals must be used to define a single system with many branches origination at a single point. PROBLEM: How to access a contribution or even a single quantity from a particular design entity as an observable. For example, I have an instantiation of a component: i1: entity xxx pin map (n1=>nx, n2=>ny, ... I may want to look at the total current contribution of xxx to node "nx" (we know the total from all contributions is zero). For example, such a value could be used in a power calculation. Ernst suggested that ideally, we would like a "peep hole" into the instance of this entity. V. SUMMARY We have well defined the problems in 5 areas and pinpointed the possible solutions. I, for one, feel that with these definitions, and the action items given, we can quickly resolve these issues at the next architectural team meeting. The areas are: - Default variable and quantity assignment in procedurals - Are the equations to be solved by the analog kernel determined statically or dynamically. Also, how the procedural and equational part of a relation are to be related to these equations. - Do we need analog drivers or are other mechanisms sufficient. We discussed the present LESs but still have issues and questions. - Contribution meaning (for branches ... branches have yet to be defined). Again, we discussed the present LESs and still have issues and questions. - How to observe quantities and contributions of a design entity (for example in a post processor). Finally, I want to state that resolution of these five areas will solve many of the issues raised in day one of this meeting. From 1076-1-request@sicmail.epfl.ch Tue Oct 25 18:55:10 1994 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Tue, 25 Oct 94 18:55:06 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Tue, 25 Oct 94 18:55:01 -0400 Received: from sol.compass-da.com by sicmail.epfl.ch with SMTP (PP) id <02097-0@sicmail.epfl.ch>; Tue, 25 Oct 1994 23:06:06 +0100 Received: from adhara.columbia.compass-da.com (adhara.columbia.compass-da.com [162.17.30.14]) by clsi.columbia.compass-da.com (8.6.9/8.6.9) with ESMTP id SAA06528 for <1076-1@epfl.ch>; Tue, 25 Oct 1994 18:05:11 -0400 Reply-To: peterl@compass-da.com Received: (from peterl@localhost) by adhara.columbia.compass-da.com (8.6.9/8.6.9) id NAA02013 for 1076-1@epfl.ch; Tue, 25 Oct 1994 13:46:42 -0400 Date: Tue, 25 Oct 1994 13:46:42 -0400 From: Peter Liebmann Message-Id: <199410251746.NAA02013@adhara.columbia.compass-da.com> To: 1076-1@epfl.ch Subject: LAT minutes, Grenoble, Fr Minutes of the 1076.1 Language Architectural Team Meeting Grenoble, France September 23 - 27, 1994 Before I begin the minutes I, along with the other members of the team, would like to express our gratitude for the hospitality provided to us by CNET, in particular Denis. I. THE MEETING The third meeting of the language architectural team (formally the tiger team) was held at CNET in Grenoble on September 23, 26 and 27, 1994. The meeting was attended by Ernst Christen (Chair), Peter Liebmann, Denis Rouquier, Ken Bakalar, Serge Garcia Sabiro, Dave Smith and Jean-Jose Mayol on the first day, and Ernst Christen , Peter Liebmann, Denis Rouquier, Serge Garcia Sabiro, Dave Smith, Ken Bakalar and Dominique Rodriguez on the final two days. It was decided that Peter Liebmann will compile these as well as all future minutes. II. First Meeting: Sept. 23 1. Open issues Ernst began with a discussion some of the slides he will present at the 1076.1 working group meeting on Sept. 24. He first listed the major open issues or concepts yet to be defined: - interpretation domain - how to define an algorithm independent real simulator - A/D D/A Interaction, analog events - simulation cycle - dc steady state (operating point) - elaboration - packaging - what is to be added to package standard, - an additional analog package - simulation control - scope of names/declarations - implicit object declaration - branches and contributions We all agreed that we will need 5-6 more meetings to finalize the design. This will carry us into March. 2. Accomplishments We briefly talked about our accomplishments which were discussed in the previously minutes. 3. Working guideline for this and future meetings: Ernst also presented working guidelines which were from a Compass - Synopsys - IMT presentation: Upward Compatibility Preserve Strong Typing Separate Declaration and Functionality Unification of Timing Semantics Preserve Determinism Preserve Generality Preserve Scope of VHDL (Gate to System) Preserve intermixed abstraction levels Preserve Concurrency Preserve and Improve Consistency Preserve and Improve Portability No Application-specific Packages Minimize Implementation Impact Maximize Implementation Efficiency 4. How to proceed with this meeting - Review the minutes of the last meeting at Columbia - Review LESs - Are they clear - Is anything missing - how does a particular LES fit with the rest on an architectural level 5. Last minutes: We decided to accept the last meetings minutes as is and address objections and add omissions in these minutes. We went through the minutes section by section and came up with a list of open issues. In this section, I will make reference to the previous minutes by its part and subpart. I will also address open issues with the preface OPEN ISSUE #. PART I. In the second to last paragraph "We managed to complete this work by the end of four-day meeting" is not accurate since there are open issues. Ken brought up the question of wanting discrete rather than continuous time points in the ideal simulator. OPEN ISSUE 1. Is ideal simulator without iterations realistic? (Denis) OPEN ISSUE 2. Static transformation versus dynamic transformation between procedural and equational form? (JJ) PART II. 1. Does the example given for units justify a new analog typing system? OPEN ISSUE 3. Justification of typing system is missing. What is it? (Ken) OPEN ISSUE 4. Not separate dimensional analysis from units. (Serge) 2. OPEN ISSUE 5. Resolve issues with application packages - how to get standards effort started. (DWS) 3. OPEN ISSUE 6. Implicit versus Explicit equations relation to algorithms. (Serge) 4. OK 5. OPEN ISSUE 7. Explore the usage of Interface Node and Interface Quantity along with actual/formal and mapping concepts. (Ken) (This is the question of PORTs containing interface nodes and quantities rather than PINs) PART III. 1. Syntax Ground Rules: In the last meeting we decided on some temporary syntax so we could continue the discussion in an efficient manner. OPEN ISSUE 8. Implications of contributions (Ken) - How does contribution affect syntax ground rules? (Ernst) - What is contribution assignment? (DWS) 2. Expressiveness of procedural part vs equational part: OPEN ISSUE 9. What does equivalence mean between procedural and equational? (Serge) 3. RELATION Structure OPEN ISSUE 10. Variable assignment in relation? Variable lifetime in relation? (JJ) - The discussion of variable assignment we had in Columbia was missing from the minutes (JJ). What we said was that we know there is a problem, but in order to continue our discussion, we will note the problem and deal with it later. - NOTE: Variable assignment has a different meaning in VHDL-A than in the LRM (a variable can be set equal to an unknown in VHDL-A). 4. Concept of Ideal Simulator OPEN ISSUE 11 Ideal simulator needs only discrete time points (Ken). JJ: This section does not address all the discussion. The discussion also addressed shared variables. 5. OK 6. Statement kinds in RELATIONs In this section, we should not give BNF syntax. for example, if_statement defines a syntax, we really mean "if type statement". NOTE: The following discussion is related to the type of statements allowed in a RELATION. This will take us to the end of day 1. 7.1 equation_statement Four more OPEN ISSUEs 12 solving for variables in a equation (Serge) 13 Structured equations (Serge) 14 Non-numeric expressions in equations (Ken) 15 Labels in equations (mandatory, uniqueness?) (Serge) 7.3 Procedure_call_statement OPEN ISSUE 16 Procedure calls in procedurals? (Serge) 8. ddt and integ Three more OPEN ISSUEs 17. Boundary value problems? (Peter) 18. ddt as function? (Serge) 19. ddt of functions? (Serge) 9. Assertion_statement OPEN ISSUE 20. simultaneous assertions? (Ken) 10, 11 OK, 12. Subprograms OPEN ISSUE 21. q'ddt in subprograms? (Serge) 13. OK 14. Transformation Rules from the Procedural Part to the Equational Part: (JJ) What is missing is that we also discussed that there are different ways to define semantics in the procedural part. 15. Semantic rules OPEN ISSUE 22. How do we define a quantity in an if/case branch if that quantity is not evaluated: IF (a > 3) q1 %= expression endif What is q1 when a <= 3? III. Second meeting Sept. 26 We decided to proceed by resolving LES issues, in particular LES-E(3) (sequential assignments) and LES-K (equation statements). We started with a discussion of LES-K but left it for a more general discussion. For completeness, I will include parts of the LES-K discussion although no conclusions were reached. 1. LES-K Serge questioned how we reach a solution or what is a simulator. We started talking about equations vs. unknowns. We did NOT assume the number of equations = number of unknowns. We said there are 2 ways to define a solution: either by direct algorithm or by showing how to write the equations. Dave and Ken questioned whether the direct algorithm is fundamental. If we take the equation approach, we will assume the number of equations = number of unknowns. Serge brought up an interesting problem of polynomials which is one equation with many solutions. We decided to leave this for now and look at procedurals, how they are related to equationals and how the equations which are solved for by an analog kernel are related to procedurals and equationals. 2. Semantics of Procedurals A general idea of a solution was stated by Serge: At a solution, execute the procedural part for each model with the quantities which have been found and the values of the quantities will be the same after the execution. Quantities are invariant at a solution. a) Variables Peter presented the following example to try to define how to deal with variables: PROCEDURAL; QUANTITY q := 1; q %= 2*q +1 -- q will always be -1 VARIABLE v:=1; v :=2*v+1; -- is v always 3? We came up with four choices: 1. variables are reinitialized each time (as in the example above) 2. v = -1 (it is solved for as a quantity 3. v = v(last time point) 4. v = v(last iteration) We agreed to eliminate 4 Serge asked if 3. has meaning in freq. domain. We should decide whether to accept 1, 2 and 3 Ken: look at the consequences in the time domain. QUESTION: we do not want any solution to depend on the number of iterations or number of time points calculated ... this will REALLY break portability. b) Quantities The purpose of the following discussion is to define what happens to undefined quantities and what does "undefined" mean. Another way of looking at the problem is to establish a relation between a procedural and an equational part - can this relation be made static or should it be dynamic. We start with two definitions of a solution: DENIS's approach: A solution is a set of values for each quantity such that using these values to run the procedural no quantities change. A solution is a set of values for some quantities and for the others take the last value and run the same check. ERNST's approach: A solution is defined as stable when it is such that if we enter a set of values for each q in the procedural, and execute each statement as defined we get the same values. Additionally, the equation statements all have the character that the left and right hand sides have the same values. Additionally, there is the requirement that for a quantity for which no quantity assignment appears and which does not appear in the equational part the value which is used is the value for q'last_value. The interaction between the equational and the procedural part lead to a discussion of "are the number of equations to be solved determined dynamically or statically?". For example, consider the following example: procedure if(case) q1 %= 2; else q2 %= 3; endif equational f(q1,q2) == 0; In a static determination, this will be over specified (ie. if "case" is false, we have q1 = q1'last_value and q2 = 3) In a dynamic determination, we alternate between solving between q1 and q2 in the equational part. ERNST argued for the dynamic case saying it will be identical to an equational representation equational if(case) use q1 == 2; else q2 == 3; endif; f(q1,q2) == 0; Why have two meanings? PETER said that the case procedural if(case) q1 == 2; endif; if(case') q2 == 3; endif; equational f(q1,q2) == 0; could lead to code that will work part of the time and then stop working if cond and cond' overlap or do not touch on boundaries since we will get either an over determined set, an under determined set or a solvable set. Also, such code may be hard to debug if cond and cond' are moving targets. Additionally, such a situation can be modeled in the equational part where the full range must be defined in a conditional, so that no functionality is lost. SERGE argued for the static determination and said that listing unknowns in the equational part will solve problems like this. TO SUM UP it was stated - a lot of people complain about the restrictions in procedurals: - to list unknowns in equational part - to previously define quantities used on right hand side. - Can we remove restrictions - ACTION ITEM ... explore it. Also can we reduce number of restrictions (do we lose ease and power of expressions). - SERGE warned that KCL and KVL may cause a problem if the unknowns are not specified in the equational part (we may not be able to tell which are known and which are unknowns). We have at least well defined our differences!! - Static vs. dynamic determination of the set of equations to solve. IV. Third meeting Sept. 27 1. How to define the system of equations we wish to solve We summed up that: we are aiming at defining how to determine the number of equations vs the number of unknowns. The problem was stated by Serge and Ernst: SERGE: How do we know how many equations and how many quantities must be solved for in a system? Determine if there are enough equations. For this, we can easily compute the number of equations, statically or perhaps not as in Ernst's formulation. Because there is no loop in equationals we can find the number of equations in the equational part. For the procedural part we can have some problems since some part of the sequence can be dynamic. For this we can only estimate the maximum or minimum number of equations and sometimes the static number. ERNST: What are the conditions under which the equations created from the procedural and equational are solvable? Number of equations versus quantities. We also stated that we need coupling between the equational and procedural part to define the set of equations. Also, is it desirable to analyze statically or dynamically. Necessary conditions: - for n quantities there are n equations needed - the Jacobian is non-singular (the Jacobian is the matrix formed by taking the partial derivative of the equations with respect to the quantities), To SUM UP we came up with four possible propositions to solve the first condition (REMINDER: the statements in the equational part are "equation_statements"): PROPOSITION 1: Number of equations created by procedural part is static => number of equation_statements is static PROPOSITION 1A Serge's comment about minutes (paraphrased): From the LESs and comments during the last few days, we have proposition 1 + no implicit equation into the PROCEDURAL part. PROPOSITION 2: number of equations created by procedural part plus the number of equation_statements is static PROPOSITION 3: consolidate all statements into the equational section with functions PROPOSITION 4: merge equation_statements and equations in the procedural sections Some discussion: KEN: Dynamic loop has problem in prop 2. Prop1: the mechanism for being static is q'last_value is used for undefined quantities. We all agreed that for 1 and 2, we are not losing functionality - only modeling style. Do we allow implicit equations in procedural part? For example: q1 %= sin(q1) ACTION ITEM: Each person will take the above 4 propositions and generate a list of pluses and minuses for each. 2. Analog drivers We defined three uses of analog drivers: future - to define future analog waveform values reset - to handle discontinuity (two values at same time point) simultaneous resolution of the equation - to hold values which are used for doing the solution. Needed to handle multiple procedural sections and the ordering. It was stated that the ability to define breakpoints solves the first two uses. A full resolution of the driver issue was postponed until we reached further understanding about relations. However, there was discussion which is stated below (thanks to Dave's notes). Observation by Ken: Need a new way to define a function of time since none of the existing mechanisms are sufficient. Comment by David: Another basic mechanism that can be used to address some of these problems is the concept of specifying that a solution must be found at a particular point of time. This can be used to help address the first two issues (future and reset). Suggestion by Ken: Try to approach the problem by using a requirements directed discussion to arrive at a solution, keeping in mind what has been done already. A signal driver's value is determined by a collection of drivers which are resolved to a single value. In the quantity driver there is only one source. The VHDL driver update mechanism is peculiar and used to model the concept of delayed assignment on a gate. It models the transition from the real world to the abstract world. It is not obvious, in particular with respect to inertial delay. His feeling is that a more general capability is needed for analog. The way that quantities get their values is not by resolution of multiple values but simultaneous solution. Serge: What has been attempted is to try to solve some of the problems dedicated to the analog world. Ken and Ernst: The concept of analog driver is clear. Now the concept needs to be more rooted in the description of the relation. How created, how updated, delayed assignments, relation to equation. Ken: A more general mechanism may be to have a special way to define a function. Serge: Are you asking for a specific mechanism that is written by the user? The driver as defined is an implicit mechanism, not defined by the user. It seems that what you are doing is to make the mechanism explicit. Ken: It is only implicit somewhat. It is explicit in that it is noted by the user as a delay. We need to examine each of the areas and determine what is fundamental. A digital signal driver is fundamental to the notion of time. The analog driver is not fundamental to the concept of time. Ernst: It appears that a lot of the qualities of this concept depend on our common understanding of the relation/equations in general. And since we apparently agreed, but have not resolved all of the issues, he suggests that we postpone the discussion of the analog drivers until we have a firm understanding of how the equations are represented and what the mean. It is a lot of issues that depend on the resolution of that. This is one of them. Only when this is resolved can we make a firm statement of how this functionality can be resolved. Peter: What does point three of analog drivers mean? Serge: Because we have multiple relations/procedural parts we need to make sure that the sections are executed independent of order, the result of the evaluation of the sections is independent of the order. Ken: So where is the problem that the driver solves. The definitional form is valid with multiple procedurals. Serge: The vq's are part of the propositional form from the other discussion. Ken: In that sense the notion of a driver is used in the propositional form of the solved state. A variable is simpler than the concept of a driver. Ernst: A driver is a function which returns a value at a given time. Serge: No. A driver is initialized at one moment, after it is registered it is called as needed. 3. Contributions and branches We started a discussion of contribution statements as defined in LES-J(3). This lead to one disagreement and one problem. We all agreed that there can be two duel descriptions, one by branches and the other by contributions (as in LES-J(3)). However, the semantics of the the two descriptions will be different. The semantics of the present description lead to the following: DISAGREEMENT: In LES-J(3) a contribution in a procedural may be given by: (n1,n2).i %= exp; which is translated to: n1.i %= -exp; n2.i %= exp; We all agree that this is what happens, but the way it is defined at present, is if one writes: procedural (n1,n2).i %= exp; (n1,n3).i %= exp1; what we get is exp1 overwrites n1.i ( n2.i is left intact). We are left with: n1.i %= -exp1; n2.i %= exp; n3.i %= exp1; In other words half of (n1,n2).i is overwritten which some of us feel is confusing and makes modeling certain systems very sloppy. Many procedurals must be used to define a single system with many branches origination at a single point. PROBLEM: How to access a contribution or even a single quantity from a particular design entity as an observable. For example, I have an instantiation of a component: i1: entity xxx pin map (n1=>nx, n2=>ny, ... I may want to look at the total current contribution of xxx to node "nx" (we know the total from all contributions is zero). For example, such a value could be used in a power calculation. Ernst suggested that ideally, we would like a "peep hole" into the instance of this entity. V. SUMMARY We have well defined the problems in 5 areas and pinpointed the possible solutions. I, for one, feel that with these definitions, and the action items given, we can quickly resolve these issues at the next architectural team meeting. The areas are: - Default variable and quantity assignment in procedurals - Are the equations to be solved by the analog kernel determined statically or dynamically. Also, how the procedural and equational part of a relation are to be related to these equations. - Do we need analog drivers or are other mechanisms sufficient. We discussed the present LESs but still have issues and questions. - Contribution meaning (for branches ... branches have yet to be defined). Again, we discussed the present LESs and still have issues and questions. - How to observe quantities and contributions of a design entity (for example in a post processor). Finally, I want to state that resolution of these five areas will solve many of the issues raised in day one of this meeting. From 1076-1-request@sicmail.epfl.ch Tue Oct 25 21:46:40 1994 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Tue, 25 Oct 94 21:46:28 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Tue, 25 Oct 94 21:46:25 -0400 Received: from gatekeeper.ray.com by sicmail.epfl.ch with SMTP (PP) id <19812-0@sicmail.epfl.ch>; Wed, 26 Oct 1994 02:12:35 +0100 Received: from localhost (mailer@localhost) by gatekeeper.ray.com (8.6.4/8.6.5) id VAA11565 for <1076-1@epfl.ch>; Tue, 25 Oct 1994 21:11:41 -0400 Received: from sud2.ed.ray.com by gatekeeper.ray.com; Tue Oct 25 21:09:57 1994 Received: from SUD2.ED.RAY.COM by SUD2.ED.RAY.COM (PMDF V4.2-10 #4335) id <01HIPGEPHWY88WXE9U@SUD2.ED.RAY.COM>; Tue, 25 Oct 1994 21:12:49 EDT Date: Tue, 25 Oct 1994 21:12:49 -0400 (EDT) From: "Joe Gwinn, 508-440-3330" Subject: More on "Z" To: 1076-1@epfl.ch Message-Id: <01HIPGEPI6LE8WXE9U@SUD2.ED.RAY.COM> X-Envelope-To: 1076-1@epfl.ch X-Vms-To: IN%"1076-1@epfl.ch" X-Vms-Cc: GWINN Mime-Version: 1.0 Content-Transfer-Encoding: 7BIT This is in response to Alain's and Dave Barton's emails of 12-Oct, both in response to my 11-Oct comments on the formal language "Z". As presented to me and others a year or two ago, Z was as I described, a finite- state language. Dave insists that Z is based on predicate (lambda?) calculus. Perhaps there is more than one version of Z. Anyway, even if Z is as Dave describes (and I grant that he knows more about Z than I), the horror story about the fate of LIS in POSIX still stands. As to the lack of success of formal languages when applied to practical (=large and messy) problems, I also stand by that statement. The only exception is proving the correctness of mutual exclusion primitives and the like; for such applications, formal methods appear to be absolutely required. As for using Z (or any other formal language) to specify or explain VHDL-A, I would recommend caution. For one thing, formal-language descriptions are generally hard for non-experts to read, let alone assess and understand. This has historically been one of the great problems with formal languages. One root cause seems to be that the language had to be defined in a simple and rigid manner, or mathematical tractability, the point of the formality, was lost. The sad history of formal languages was much discussed during the POSIX LIS wars. The final compromise was to allow working groups to use LIS if they wished, but not to require it. One group of twenty continues to use LIS, and they are far from writing specific and ballotable language interfaces. Their sole reason for retaining LIS is that they plan both Ada and C bindings to the same underlying interfaces, and LIS is seen as a suitable interlingo. There is certainly nothing wrong with Alex Zamfirescu and Z-minded friends going off as a small group and analyzing the VHDL-A proposals using Z as an intellectual tool, and reporting problems found back to the larger working group. The objection is to letting any Z creep into the VHDL-A standard. Joe Gwinn LIS = Language Independent Specification, an informal formal language, if that makes any sense. JG. From 1076-1-request@sicmail.epfl.ch Wed Oct 26 10:20:42 1994 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Wed, 26 Oct 94 10:20:34 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Wed, 26 Oct 94 10:20:25 -0400 Received: from potomac.wash.inmet.com by sicmail.epfl.ch with SMTP (PP) id <03802-0@sicmail.epfl.ch>; Wed, 26 Oct 1994 14:48:48 +0100 Received: by potomac.wash.inmet.com (4.1/SMI-4.1) id AA12286; Wed, 26 Oct 94 09:48:21 EDT Date: Wed, 26 Oct 94 09:48:21 EDT From: dlb@potomac.wash.inmet.com (David Barton) Message-Id: <9410261348.AA12286@potomac.wash.inmet.com> To: GWINN@SUD2.ED.RAY.COM Cc: 1076-1@epfl.ch In-Reply-To: <01HIPGEPI6LE8WXE9U@SUD2.ED.RAY.COM> (GWINN@SUD2.ED.RAY.COM) Subject: Re: More on "Z" Joe Gwinn writes: As presented to me and others a year or two ago, Z was as I described, a finite- state language. Dave insists that Z is based on predicate (lambda?) calculus. Definitely predicate, not lambda calculus. Lambda calculus oriented languages, such as Haskell, ML, and Miranda, are implementable (evaluable? calculational?), where the predicate calculus (and the Z notation) is not. As for the rest, we must agree to disagree. Any interested in industrial case studies, including the Hayes text I cited in my last post and a rather large study just completed by Susan Gerhart, among others, is welcome to drop me a line privately via Email. (Well, agree to disagree about general utility. I am not at all sure about the usefulness of applying a Z notation formalism to VHDL-A, given the simulation oriented semantics proposed for it. A formal semantics has not been a goal of the working group; however, from having looked at the formal semantics of digital VHDL for some years as time has allowed, I shudder to contemplate what the analog kernel will do to the complexity of a formal description of VHDL-A. I share Joe's concern here. I am not against trying, I just am more than aware of the conceptual complexity of the task that awaits anyone who attempts such a task.) Dave Barton dlb@wash.inmet.com From 1076-1-request@sicmail.epfl.ch Wed Oct 26 15:13:32 1994 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Wed, 26 Oct 94 15:13:29 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Wed, 26 Oct 94 15:13:25 -0400 Received: from psi.com by sicmail.epfl.ch with SMTP (PP) id <15598-0@sicmail.epfl.ch>; Wed, 26 Oct 1994 19:53:15 +0100 Received: from analogy.com (analogy.analogy.com) by psi.com (4.1/2.1-PSI/PSINet) id AA00520; Wed, 26 Oct 94 14:52:55 EDT Received: from rising_star.analogy.com (torres) by analogy.com (4.1/Shared_Spool_1.3) id AA03716; Wed, 26 Oct 94 11:44:01 PDT Received: by rising_star.analogy.com (5.0/SMI-SVR4/CprMtn) id AA00047; Wed, 26 Oct 1994 11:49:37 +0800 Date: Wed, 26 Oct 1994 11:49:37 +0800 From: dws@torres.analogy.com (David W. Smith) Message-Id: <9410261849.AA00047@rising_star.analogy.com> To: 1076-1@epfl.ch Subject: Z X-Sun-Charset: US-ASCII Content-Length: 1794 A comment. At the meeting in Grenoble I suggested that the use of a formal (using the term very loosely) way of describing the language semantics would be helpful for the purposes of architectural analysis and for writing the LRM. The suggestion was made that the use of Z might be appropriate. I do not think that I ever intended the LRM to be written in a formal language. That is truly unreadable. I do believe that a better method needs to be used for describing the LESs/language design that makes far less use of provisional syntax and more use of definitions is required. Z is not it. David W. Smith ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :: David W. Smith Analogy, Inc. (Analogy) :: :: Phone: 503-626-9700 9205 S.W. Gemini Dr. :: :: Fax: 503-643-3361 P.O. Box 1669 :: :: Email: dws@analogy.com Beaverton, OR 97075-1669 :: :: :: :: Analogy(R), Calaveras(R) Algorithm, DesignStar(R), Frameway(R) :: :: Hypermodel(R), and MAST(R) are registered trademarks of Analogy;:: :: InSpecs(TM) is a trademark of Analogy; :: :: AHDL(R) and Analogy HDL(R) are trademarks of :: :: Analogy, registered in Germany and the U.K.; :: :: PowerExpress(R), and WaveCalc(R) are trademarks of :: :: Analogy, registered in France; and :: :: SABER is a registered trademark of American Airlines, Inc., :: :: licensed to Analogy. :: ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: From 1076-1-request@sicmail.epfl.ch Wed Oct 26 15:16:41 1994 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Wed, 26 Oct 94 15:16:39 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Wed, 26 Oct 94 15:16:36 -0400 Received: from babbage.ece.uc.edu by sicmail.epfl.ch with SMTP (PP) id <15386-0@sicmail.epfl.ch>; Wed, 26 Oct 1994 19:39:46 +0100 Received: from thor.ece.uc.edu (root@thor.ece.uc.edu [129.137.8.118]) by babbage.ece.uc.edu (8.6.9/8.6.3) with ESMTP id OAA05431 for <1076-1@epfl.ch>; Wed, 26 Oct 1994 14:39:25 -0400 Received: from tomcat.ece.uc.edu (lunye@tomcat.ece.uc.edu [129.137.8.138]) by thor.ece.uc.edu (8.6.9/8.6.6) with ESMTP id OAA04363 for <1076-1@epfl.ch>; Wed, 26 Oct 1994 14:39:24 -0400 From: Lun Ye Received: (lunye@localhost) by tomcat.ece.uc.edu (8.6.9/8.6.4) id OAA20341 for 1076-1@epfl.ch; Wed, 26 Oct 1994 14:39:20 -0400 Message-Id: <199410261839.OAA20341@tomcat.ece.uc.edu> Subject: Re: More on "Z" To: 1076-1@epfl.ch Date: Wed, 26 Oct 1994 14:39:18 -0400 (EDT) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 680 Joe Gwinn wrote: >As presented to me and others a year or two ago, Z was as I described, a >finitestate language. Dave insists that Z is based on predicate (lambda?) >calculus. Perhaps there is more than one version of Z. Z is based on predicate calculus, => Z is not executable => you have to have some experts in Z and predicate calculus etc to tell you what you write in Z makes any sense => a nice way to specify things formally but way beyond general public's reach. people complain the LRM (for VHDL) constantly. wait until they see things in Z! Lun -- Lun Ye, Dept. of ECE, U. of Cincinnati Cincinnati, OH 45221-0300 (513)556-4772(O) From 1076-1-request@sicmail.epfl.ch Wed Oct 26 17:44:08 1994 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Wed, 26 Oct 94 17:44:05 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Wed, 26 Oct 94 17:44:02 -0400 Received: from m1.cs.man.ac.uk by sicmail.epfl.ch with SMTP (PP) id <17399-0@sicmail.epfl.ch>; Wed, 26 Oct 1994 22:17:40 +0100 Received: from panda.cs.man.ac.uk by m1.cs.man.ac.uk (4.1/SMI-4.1:AL5l) id AA08748; Wed, 26 Oct 94 21:16:38 GMT Date: Wed, 26 Oct 94 21:16:35 GMT From: Hilary Kahn Message-Id: <9410262116.AA12717@panda.cs.man.ac.uk> To: 1076-1@epfl.ch, dws@torres.analogy.com Subject: Re: Z What about EXPRESS? Hilary Kahn From 1076-1-request@sicmail.epfl.ch Thu Oct 27 03:48:43 1994 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Thu, 27 Oct 94 03:48:41 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Thu, 27 Oct 94 03:48:38 -0400 X400-Received: by mta sicmail.epfl.ch in /PRMD=switch/ADMD=arCom/C=ch/; Relayed; Thu, 27 Oct 1994 08:28:15 +0100 Date: Thu, 27 Oct 1994 08:28:15 +0100 X400-Originator: 1076-1-request@sicmail.epfl.ch X400-Recipients: non-disclosure:; X400-Mts-Identifier: [/PRMD=switch/ADMD=arCom/C=ch/;sicmail.ep.678:27.09.94.07.28.15] Priority: Non-Urgent Dl-Expansion-History: 1076-1@epfl.ch ; Thu, 27 Oct 1994 08:28:15 +0100; From: "Jean-michel.Berge" Message-Id: To: analog_reflector <1076-1@epfl.ch> Subject: ZZZZ X-Mailer: Mail*Link SMTP/MS 3.0.0 (I know I missed certain mails on the topic due to email problems, sorry if I repeat something already said) I both agree with David Smith and Lun Ye mails: Put Z descriptions within the LRM or use them as support of discussion between language designers is unrealistic to me. It does not mean that I neglect the benefits of formal descriptions in our process, but their use has to be restricted to the validation phase. As far as I know Z, B, or other formal languages, they do not allow to describe a given algorithm but the specification of algorithms (Alex or Dave, correct me if I am wrong). This is why, only "implementation" (algorithms fitting the Z description) of Z descriptions are executable. For a given Z description, different implementations of the algorithm are possible. I am not sure this approach will help us. On the other hand, at the validation phase, we could probably use Z in another way: describing properties of our language and proving them. If we could find volunteers for that, it would be interesting to ask them to define the "invariants" (properties) of our language first... One of my main concern about this approach is that, since VHDL-A is an extension of VHDL, I am not sure it will not be necessary to formalize VHDL as a whole to have results... In that case, Express (as proposed by Hillary) is certainly a good candidate since the work has already (partially?) been done for the "digital" part. But do we have volunteers?.... Thanks Jean-Michel From 1076-1-request@sicmail.epfl.ch Thu Oct 27 09:11:26 1994 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Thu, 27 Oct 94 09:11:22 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Thu, 27 Oct 94 09:11:12 -0400 Received: from c3imac12.epfl.ch by sicmail.epfl.ch with SMTP (PP) id <18125-0@sicmail.epfl.ch>; Thu, 27 Oct 1994 12:51:41 +0100 X-Sender: vachoux@c3i9.epfl.ch Message-Id: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="========================_19399118==_" Date: Thu, 27 Oct 1994 12:54:16 +0100 To: 1076-1@epfl.ch From: alain.vachoux@leg.de.epfl.ch (Alain Vachoux EPFL-LEG/C3i) Subject: Comments on DOD 2.0 --========================_19399118==_ Content-Type: text/plain; charset="us-ascii" Everybody, Here are messages that occurred during a private discussion about DOD 2.0. The whole set of comments on DOD 2.0 is anyway available in our anonymous ftp archive site (nestor.epfl.ch) in the directory incoming/vhdl/analog/working/mail/Re-DOD_2.0 As a summary, I give here the new versions of the DOs that were proposed during the discussion: DO13b 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. DO13c [new, decoupled from previous DO13b] It is desirable that VHDL-A provides a mechanism to specify regular array structures of instances, with constant dimensions. DO14a [new, should be located just after existing DO14] VHDL-A must support the description of continuous time behavior both by explicit and by implicit equations. 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. DO14b VHDL-A should support the description of piecewise defined behavior. DO17 (should) [DO12] VHDL-A should support a mechanism to parameterize a model. The support includes parameters that are constants (static parameters) and 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 part 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. DO24 VHDL-A should support the annotation of physical units to waveforms. I'm going to incorporate all comments on version 2.0 into a new version 2.1 which will be subject to ballot within the working group. Regards, Alain --========================_19399118==_ Content-Type: application/mac-binhex40; name="Re-DOD_2.0_(private)" Content-Disposition: attachment; filename="Re-DOD_2.0_(private)" (This file must be converted with BinHex 4.0) :&&*P,8424#!b,M!J+("bDACKG'8T!&4&@&44483a!!!!!*Zh!!!"U%qa$5-M)b- M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b- M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b-02NCbEfdJCQPdHN"MB@4PEQ0P,Q0 [E5"8D(8J6f0d)$%c)$)`1M)`)%e&9#!a16Nd$9JY3A9dD'9ZG'PMBA4TEfiY9f& bEQPZCcSJBf4c-M!h-Lj$B@4PEQ0P,N0266SJ5'pcG#"XEf0KE'K[Fh3JC'PNELG d)(9cC5")48a2)!dJ)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)("bEh4[BfpX$9J Y3A9dD'9ZG'PMBA4TEfiY9f&bEQPZCcSJBf4c-M!h-Lj$B@4PEQ0P,N0266SJCQP dHL"[GfjPC#"`FQpMCA0c)'4[D@jR)#eLF`e8EcSJ)NTPB@iYE@PMD'9X,N*PFQG P)L!mDQ9KELeYD@0SC@`ZBQ9bCf9!Bfjc,Q0ZCA3ZCR)q$80M1L""E'&TEL"@B@0 SEh9i)$aKE'&TELjfB@0SEh9i3'aPCbjNC5jPF'CX,Q0S2L`0)#!J)#!J)#"%B@i JCQPdHR"KG(*TBfXJ2'CTG(T!Bf4c-M!h-Lj$B@4PEQ0P,N0266iX$5!J)#!J)#! J4A*ZFh3J2'0SFQPcG'9Z3'&ZB@a[ChNZBfpY2Je6G@*UC@0d1L"5C6SJ4%p%)$) Z-!e%BA4P1L"'FQNX)$%d)%pMG#!a16Nd)$%a1M)f1M!e)#d`0c!`$8CbEfdk)%4 KEQPPE#"'DA4k8'&dFQPMDb!mCQPdHN"MB@4PEQ0P,Q0[E6i08h4KG(9c1L"5$3e *EL"YCA0cB@GP)$aZ-63c-$Nb1$Bj1#ii-MFf0N"YFfeKD@`q,#"hFQpdC6S0$3e 2EL"%6d3Y-Li`,#"T)'4[ELGd)'YZEhFJGfKKG#"hBA-JD'&ZC'9N)'peG#"TEL" (FQ9ZEf*XC5`JBR9d)(4SCA0P)'0[E@ePER4c$@&`F'aj)(4[)(4SC5"fCA*cD@p Z)(4SBA3JB@aKD@iJFf9ZG#"[GA3Z$3dJ)#dJFQ9YEhCP)'0[E@ePER4c,JdJ)#d JFQ9YEhCP)'&ZH5"LB@0VGf&bC#"bC@CPFQ9ZBf9c)(4[)'pXC#"fCA*cD@pZFb" [CL"%6d3J+&YG)(*PCR-JG'mJ-5if+5i0)#!Y)%42-60L)'4[CA-JEQpd)'&NC#" KERPdD'PZCb"dD'&d)'4[CA-JEQpd)'&XFQ9KC(NJCAKTFh3JGfPdD'PZ)(CSC'` X)!ePH'0PF(4TEQF0)#!J)'0[E@ePER4c)(*PCf&bC'PZCb!LC(PZB@eTBb"ZCA4 XDA0dD@jR)L"hD'PMD#"T)'4[ELGd)'*PE'PPGQ8JD'&c)'9fCA)JBQ9PEJdJ)#! JC'9YEfjcG(*KG'9N,L!JG'KPFQ8JDA-JB5"ND@CQCA*PEQ0P)'*PG(GPC@iJD'& ZC'aTEQFJG'KP)'0SB@jRD@jR)'*PD'&fD@pb$5!J)#"[CL"KEL"PE'9YC@jd)'P Z)(4PFQec)'pQ)(4SC5"PFA9KG'P[ER-JDA3JFQ9aG@PbCA-J+'8ZCbiX)'PNC@& X)(*PE'&j)'pb$5!J)#"cGfPdBfJT,#"KEQ3JC(PZB@eTBf&XE(NJBfKKEQGTEQF JG'KP)'jPG'aTFh3Z)#"dD'Pc)'Pc)'%JE@&bCfPZB@aXH5!0BQ9ZC@CTBfPKE!d J)#!JEf*UC@0dDACP)'C[FL"dD'pcC5"dD'&d)(G[G@aN)(4jF'PMB@aXH5"eFf8 JGQKNE#eK)(4SBA3JCR9bG'KPFL"MEfjQGA0PFb!0)#!J)(4SD@jRFbi0)#!Y)%4 2-64L)(0KE@8JBfpYE@9ZG(-JBA-J4%ma-f)Z$5!J,5"%6c%f)'Pc)'PZBfpZFfP cG'9ZG#iJ)&4SC5"bBA4TEfjKE#"eFf9c)'%JBfpZG(*[E'aPC#"cEh9bBf8JCQp b)!eUGA0dD@CTBf&dD@pZ$5!J)#"[CL"KBf0PFh-JG'mJD@jdCA*ZB@`JFA9KER4 TG'PPFb`JD'phCACPFL"dD'Pc)#*TEQC[FQeKG'P[EL)JDA-JB@acEb!0BACKD@a KBQaP$5!J)#"KG#"dD'8JG'9bE@PZB@`JE'9fC@`JB@jN)(G[G@aN)'PZC'PMBA4 P)(4[)'eP)(4SBA3JG'KP)'pZBf8JC'PcBh9cFf9N)!ecH@jdBAJ0)#!J)'pQ)'& XE'phD@jR)'&MBf9cFb"dEb"dCA*YD@jKE#"MGA*bC@jdFb!SC'&XE'&c,#!j-LN JGfpeE'3JFh9QCQPMC5"KEQ3J$AG[G@aN$5!J)#"cBA4TFfCj)(4SDA-JFQ9aG@P bC@ePER3Z$5!J,5"%6c%h)'4eF'aTBf&dCA-JCAKTFh4TEQFJBfpZFh4bG@0dFb" TEL"fD'4X)#KRC@jPFQPMFb"KFQ8JFh4KG'PM)!e`BA*KE@9dCA*c+3dJ)#!JB@j N)'4jEQ&YD@-JF'&bB@ePG'9bFb"MB@iRG#"LC5"NEfjP)'&ZHAGKH5"KFb"dD'9 j)'aPB@3JG'mJFfPdG@&dD@pZFb"[CL!0)#!J)'j[ELeMD'&bCf8JBfpZFf9bGQ& dD@pZ,L!JG'KP)(*KG'P[EQ&X)(9cD@jR)(4PEA"PFQ&dGA*P)'&c)'&Z)'9iB@e `E'8JEfBJ$5!J)#"NH@jKE@PM)(CKFQPKBQaP)'Pc)'PZBfpbFQ9MG#"KE(0[)#d JG'9YF'9bBA4eFQ8JGfpeE'3JEQ9PC#"dEb"LC5"KEL!0G@jVEQphEJdJ)#!JG'm JBQ8JFfpXGQ9N)'C[FL"TEL"dD'8JFhPcG'9Y)'pQ)'9aG@&dD@pZFbi0)#!Y)%4 2-M3JDA-JE@pbC5"[CL"K)(4[Ef`JDA0cG@8Z$3d0,5e%B@iJ$5-M)b-M)b-M)b- M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b- M)b-M)b-M)b-M)b-M)b-M)b-M)b-02NCbEfdJBfKbDA0dC@j!B@jKE'pRH5jMEfd J9'Ke)%pMG#!a-b!b-cSa0b"0493J-6Nj0!e%BA4P1L"'FQNX)$%d)%pMG#!a16N d)$%d1M)c1M)b)#X`1$!`$8CbEfdk)'0SFQPcG'9Z3'&ZB@a[ChNZBfpY)#K&FQj cG#"$D(*TFh4PELN09'mk)'CTG(T!Bf&NC@jMC5jMEfd08h9LDQ9MG$SJ8Q8k)%4 24#!b,M!03f-k)'&XB@PZ,RCKBfK[GAK!E'9R,Q4P,Q9`CQ`ZBfJX)'0SFQPcG'9 Z3'eKD@aSEh0d,Q&ZB@a[ChNZBfpY$90dBA4eFcSJ8Jd09'KTFb"TFb"K)'0[E@e PER3JG'mJ4'&Z*h-JFQ9cF'pZFf8JEfiJ4%p%)$)Z-#iJ3A-JB5"RC@jPFQ&X)'0 [E@ePER3JDA3JBA"`C@&bF`edD'&d)%4KELGc)("[D@jdFb"SBACP)'*PC@iJE@& NC5"LBA0PC#"[EL"dD'8JBA0cG@e`G'P[EL"dD'&d)(GSBA3JBh9bFQ9ZG'aj)!e TFb"TEL"@5%4-)'4[CA-JEQpd)'KKGQ8JG'mJBQ8JFh"PBfPQD@9N,L"8D'Pc)(0 PC@ec)'4KEQGPFQpeFb"dEb"YC5`JBQ9MBA9cC3eTG#"bCA&eDA*PFb"KEL"TEL" NCA"dD#"VEQphE'9NCf8JEfBJ9NK%6#"KE(*PB@4j)'&d)(4SC5"cG'&RC5"[CL" NDA0MGA0cD@jR$A*PFA9TFQ9YC@jdFbiJ55"`CA*cEfjKE'aj)(G[G@aN)'&bCh9 P)(4SBA3JG'KP)%424#"cD'peE'3JD@jME(9NC5"hD'&d)(GP$@*PE'PPGQ8JGf8 JEQ9PC#"TEL"dCA*YFb"[CL"bCA&eDA*PE@9ZG(-X)(*PCf&bC'aPFh-JEfBJGfK KG#"@5%4-)'0eFR*PER4XH3e`FQpfD@4PFbiJ5A3JDA-JG'KPEL"dD'8JG'&cDb" [CL"dD'8J6%48)(4[)("bEh"[Ff8JG'KKG#"K)'GTGQ9Z)'pLDQ9MG'PfC3eSBA- JB@abC@&NH5"LC@9Z)'ePG#"LH5"PH'PcG'PZCb"MEfjcG(*eBh4c,L"8D'8JFQ9 KFfpZ)'C[FL"YH5"`Eh0TG'P[EL"TF`edD'&d)%NJF(*PCQ9b)(4[)'KKGQ8JFQ9 NG@jNB@jMD@9c)'pfCA)JE@PcFfPZCb"cEfePG'KTEQFJD@e`Eh*dB@jd,Jdq$6j 2EL"%6d3Y-Li`,#"T)'4[ELGd)'YZEhFJGfKKG#"hBA-JD'&ZC'9N)'peG#"TEL" (FQ9ZEf*XC5`JBR9d)(4SCA0P)'0[E@ePER4c$6jKF("XH5"dEb"dD'8JGQ9bFfP [EL"dD'&d)'&XB@PZ)(0PER3JEh9d,Jdq$6iJ)#dJFQ9YEhCP)'0[E@ePER4c,Jd q)#!Y)(*PE@pfC5"KERNJBQ&MDhGKFQ3JFQ9QCA*PEQ0PFb"dEb"[E'3JGQ9bFfP [ER-JEfBJ4%p%)#KEA5"bC@Cc)(4[)$%Z0LNZ$6iJ)#dJ4%ma-f)JC'pPFb"ZEh3 JB@4N)'&ZHA4SD@jR)(4SBA3JC'pPFb"ZEh3JB@abC@&NH5"PH'PcG#"hDA4SD@i JGQKNE#`J$@9iBf9`G'PZC`dq)#!J)'0[E@ePER4c)(*PCf&bC'PZCb!LC(PZB@e TBb"ZCA4XDA0dD@jR)L"hD'PMD#"T)'4[ELGd)'*PE'PPGQ8JD'&c)'9fCA)J$@* PC@i02L!J)#"NC@e[ER0dFQ&dC@3Z)#"dD'9bC5"TFb"K)'4TCQCPFQ9ZBf8JBQ9 dGf9PEL"SB@jNE'PZCb"dD'8JBfKKEQGTEQFJ$@*PD'&fD@pb$6iJ)#!JEfBJB@i JC@aPE@9ZG#"TEL"dCA*YFb"[CL"dD'8JCA&eBA4TEfjc)'Pd)(*PFA9TFQ9c)#K P,QFZ,#"TC'9KE#"bC@aKH5"[FJdq)#!J)(0hDA4MD#NX)'&ZC#"NH@jKE@PMB@a XH5"MD'&ZCfPZCb"dD'8JEQ9dE'PcG#iJ)(4SDA-JDA-JB5"YBA*RD@jKE'aj)!e LC@jPCQPMD@&X$6iJ)#!JEf*UC@0dDACP)'C[FL"dD'pcC5"dD'&d)(G[G@aN)(4 jF'PMB@aXH5"eFf8JGQKNE#eK)(4SBA3JCR9bG'KPFL"MEfjQGA0PFb!02L!J)#" dD'PZCh-Z$6iJ)#dJ4%ma0')JFf&YC5"MEfeYC@jdFb"KFb"%6c%cBLi055"LC@a TCACP)(4SBA3J4%ma-f)JB@jN)%42-64L)'&bC5"aG@PdC5"ND@CQCA*PER3Z)%4 2-60L)'&NC(*PFh0PFb"cG(*eBh4eFQ&X$@&cF'9MG(-X)'aTDf8JBfpZC'PdD@p ZB@`JEQ9dE'PcG'PZCb`JGfKTE'8J4%ma0')JFh"PBfPQD@9c)(4SBA3JG'KP)'* PD'&fD@pb$@pQ)'%JC'9fD@0P)'eKH5"LC5"cF'9MD@CTC@3JBRNJC'PQCQ9bC@j d)'9aG@&dD@pZFb"TEL"ND@CQCA*PER3JFQ9RD@pZFb"[CJe[F'9bBA4TEfiZ)%P Z)'CKBh3X)'Pd)'Pc)(4SC5"ND@CQCA*PEQ0P)(4SBA3J4'&Z)'&XFfmJE@9ZG'P [ER-Z)%NJBf&Z)(9ZC'9b,3ecG'&ZC#`JG'K[G@GS,#"hD'9bC5"%B@iRFb"MEfe YC@jdFb"KFQ8JBfpYD@jR)'CbEfdX)'&ZC#"*)(G[G@aN)'aTDf8JG'm0Fh9RCf9 cG#"dEb"TEA"bEhCP)'&ZC#"ME'&bD@Cj)(4SC5"QEh*YG@aKG'P[EL"[CL"LEh4 S)%42Fb`JCQpb)'PZFh4KEQ0P1Jd04%ma-f)05A3JDA-JC'9cDA*KBQaP)(4SBA3 J9NK%6#e")("bEhCTC'9c)'%JE@9MD'&ZDA0Y)(4[)(0`C@0TCRNJEQ9dE'PcG(- J$@0[EQ4TG'P[EQ&X$A9`EfiJG'KP)(CKE(9P)'pQ)'%JBfpZFh4KER3JF'&bB@e PG'9b)#KMEfjNDA4TEfjKE#"ZCA4XDA0dFbNZ)%%JFh"PBfPKE#"MBA0P$@pQ)(4 SDA-JDA-JBfpXE'&`FfPZCb!b)'j[C'9c,Jd04%ma-f-05A3JDA-JC'9cDA*KBQa P)(4SBA3J9NK%6#e")("bEhCTC'9c)'%JE@9MD'&ZDA0Y)(4[)(0`C@0TCRNJFQ9 RG@aKFL"KFR*KH3ecG(*eBh4eFQ9c)'pQ)'PZFh4KEQ0PFb`JGfPdD#"MEfjcG'& ZG#"ND@ePER0TEfjc,Jd04%ma0')09NK%6#e")(0SEh9XC#"cGA"`Eh*d)(4SC5" NCA0MFQP`G'P[EL"[CL"`D@9MCAGTFf8JC'9QD@jPC#"LC@KKGQP[FLi0$6iJ)#d J4%ma0L"TFb"TEQ0[ER0TFh4PER3Z)#"8D'8JFQ&dD@pZB@`JGA0PFb"K)'0[ER4 bEfaXC@3JFfpeFQ0P)'C[FL!0DR9cG'PQD@0KG'P[EJdq)#!J)'pQ)'&MBf9cFb" dEb"TER4PFQjKE#"aG@&ZG'PdD@9c,#"SEhGPGQ9b)(4SDA-J)QPZCQpbE@&dD@p Z)L"TFb"KE(0[)!eKGQ&TE'&LE'802L!J)#"KG#"dD'8JG'9bE@PZB@`JE'9fC@` JB@jN)(G[G@aN)'PZC'PMBA4P)(4[)'eP)(4SBA3JG'KP)'pZBf8JC'PcBh9cFf9 N)!ecH@jdBAJ02L!J)#"[CL"KE'a[GfPZCb"KBf0PFh-JG'mJG'9bE@PZB@`JBh9 bFQ9ZG(-J+'4KE'aKFb`J16)T)(G[G@aN)(0eCQCTBf8JB@jN)!ehEh9XC!dq)#! J)(0KG'PcCRNJG'KTFb"bCA&eDA*PE@9ZG#i055"NEfiRG#"VEQph)(GSBA3JDA- JD@jMEfjcDA0dC@jd)(GTG'JJG'KTFb"%6biJ3A-JG'mJG'KP)(*PFh3JEfBJG'K P)'0[E@ePER3X$@Pd)'&`F'9KFR-JG'mJE@8JG'KKG#"%B@iJDA-JE@&VD@jR)'& Z)'&cFh9YF(4TEfiJG'KKG#"[EQaj)(4PFQeTEQ&X)(&eB@jdDA4TCA-0GfpeE'3 JBQ8JGA0PC#"TEL"MEfjdFQpXE'9N)(0[GA*MCA-JCA4M,L"*G#"TFb"fCA*j)'9 KFhNJG'mJBh*PBA4P)'&Z)'9iB@e`E'80GfKPFQ8JG'KTFb"TFb"ZEh3JG'KP)'0 KFf8X)'NZC5iJGfKPFQ8JG'KP)(&eB@jdDA4j)'Pc)("eFQ9XH5"TER4PFQjKE#" dEb"K$@e[C'9X,L""E(0[,#"dD'8JFQ9QCA*PEQ0P)(4[)%4KE'aKFb!j-L"TFb" TEQ&`F(*[F(*TBA4P)'PZ)(4SC5"%6d3X)(GSCA*P$AGP)(0SEh9XC#"ZEh3JB@j dD@0TF'&dC5"KERNJE'&ZCh9KCf8JC'9cD@GZ,Jd02L!J,5"%6c%h)'4eF'aTBf& dCA-JCAKTFh4TEQFJBfpZFh4bG@0dFb"TEL"fD'4X)#KRC@jPFQPMFb"KFQ8JFh4 KG'PM)!e`BA*KE@9dCA*c+3dq)#!J)'&ZC#"NH@jKE@PM)("KFQ&YCA4PFR-JBf& Z*h3JBQ8JC'pZC5"KERPhBANJBA-JG'KPH5"XC@&N)(4[)(0TG(9KG'P[ER-JEfB J$6iJ)#!JEQpZ,@0SBA*RC5"MEfjcCA*fBA4TEfiZ)#"dD'8JFQ&dD@pZB@`JGA0 TEQFJG'9YF'9bBA4eFQ8JBA-JB@iJCAKKEA"XC5"[CL!02L!J)#"NH@jKE@PM)(C KFQPKBQaP)'Pc)'PZBfpbFQ9MG#"KE(0[)#dJG'9YF'9bBA4eFQ8JGfpeE'3JEQ9 PC#"dEb"LC5"KEL!0G@jVEQphEJdq)#!J)(4[)'*P)(0[E(CPC#"QEh)JD@iJG'K P)(0jFh4PE5"[CL"PFA9KG'P[ER-Z$8NJBQ9XD@9fC5"dD'&d)(4SDA-J4%mJDA- JCA0cC@jdD@&X,L"ADA4SEh9d)'0KFQ9QG@`JB@jKE(PcDA-JEfBJG'KP)'0KF'& LD5d0E'PdD@9c)("bEhCTC'9N)'*j)'GPEQ9bD@0c)(GP)'0KEQj[G#"KFh0eE@8 JG'KKG#"dD'9j)("bEhCTC'8JFh9QCQPMD@9ZG!eQG@jMG'P[EQ&XDA4j)'C[FL" KEQ&XEfFJE@pNC@aTEQFX)("KFR4TBh9XBA*XH5"MEfjcD@4PFQPZCb"dD'8JEQp dC5"TEJecC@0dD@pZ)$%Z-5ia,M%Z)'pQ)(4SC5"@5%4-*cNc)%a565`JGfKTBfJ JFf9PEA-JG'mJD@jND@0KG'8JG'KKG#"RC@jPFQPMF`ehCA*P)'0bC@&dC@3JGfP dD#"YG@0S)(0TEA"XCA)JCR9ZBh4TEfjKE'PdH5"TEL"YD@jN,L""Fb"dEb"NH@j KE@PM)("KFQ&YCA4PFR-X$8NJC'PcB@GbC@8JG'KKG#"dD'9cC5"XC@&N)(4[)(0 TG(9KG'P[ER-JEfBJEQpZ,@0SBA*RC5"MEfjcCA*fBA4TEfiJB@jj)'e[FQ80G'K KEL"KERPdD'PZCb"PE(0P)'PZ)(4SC5"XB@jRG@&RC5iJ8Q9QCA*TEQFJG'mJG'K P)'9iB@e`E'9c)("bEhCTC'9N)'*j)%YPEJe,G@jNCA*d)(0PGQ9bB@`JE@pZG'K c)'&REb"TER4PEQ4TEQFJG'mJFh9`F'pbG#"dD'Pc)'0XB@PY,#"*)'*PE'PPGQ8 JG'KKG!ejEh8JBf&ZEQpd)'*XB@eP)(4SC5"XB@jRG@&RC5"TCL"K)(GbEfjRE(N JGh*TG(4PEL"YEf4PE(-JC'pPFb"ZEh3JCfPfC5"dD'8J$@0[FR*PBh3JFfPYG@a KG'P[EL"bCA0eE(4c,Jd02L!J,5"%6c)d)'Pc)'e[FQ8JEfBJB5"dEfpX)'PcFh9 P,Je1Eh3JFQ9KE'aj,L"8D'8JC'PcF'aKH5"TFb`JBR9d)(4SC5"dEfpX)'eeFh3 JCf9d)(4SC5"TEQC[FQeKG'P[EL"QFQpY)(0[E@8Y$AGSCA*P,L"*)(G[G@aN)'K [Gf9fCA)JFh9RCf9cG#"dEb"bC@e[GQ8JG'KP)(*PCQ9bC@jMC5"dEb"[GA4`GA3 JC'PcF'aKH5"QFQpY)!edD'8J4%mJB@jN)(0KH3d04%mb0!e@5%4-,8%JFfK[G@a N)(0eF("[FR3JG'KP)'&ZEQpdBA4TEfiJEfBJF'KjFfPMB@`JG@jTG(-JG'mJGf& fC@C[FQec,Jd0$89bER0d$5-M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b- M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b- 02NCbEfdJBfKbDA0dC@j!B@jKE'pRH5jMEfdJ9'Ke)%pMG#!a-b!b-cSd0b"0493 J-6Nj0!e%BA4P1L"'FQNX)$%d)%pMG#!a16Nd)$%d1M8d1M3j)#X`1$!`$8CbEfd k)'0SFQPcG'9Z3'&ZB@a[ChNZBfpY)#K&FQjcG#"$D(*TFh4PELN09'mk)'&XB@P Z,RCKBfK[GAK!E'9R,Q4P,Q9`CQ`ZBfJX)'CTG(T!Bf&NC@jMC5jMEfd08h9LDQ9 MG$SJ8Q8k)%424#!b,M!03f-k)'0SFQPcG'9Z3'eKD@aSEh0d,Q&ZB@a[ChNZBfp Y$90dBA4eFcSJ8Jd04'&Z,#""E'&TEL`05A3JDR9cG#"[Bf0eFR*PC#"dEb"YC5" dD'&d)%NJCQpbCfpd)(0[E@9dD'PZCb"TEL"YH5"`FQ9fD@peFb"PE@&TE#i08Q9 YC@eLCA)JG'KP)'0[E@ePER4c)'eKC'8JBRNJ6@&bDb"DGfpXD@jcDfNJB@*[GA3 JG@jNC@CTEQ9N)("KFQ&YCA4PFR-0+'KTFb"PE@&TE#"QFQpY)%TeE(NJ0#NZ)%N JBQ9XD@9fC5"dD'&d)(GP)(0SEh9XC#"TEQ0XG@4P)'&c)'&Z)'9iF'aTBfPd$A* PFA9TFQ9YC@jd)(4SBA3JDA3JEA9cG#"LC5"`Eh0cD@*XC5"dEb"SB@jNE'8JF'& bB@ePG'9b)(CKE(9PFb"dD'&d)'KKGQ80D@jdC@jdD@pZB@aXH5"LC@9Z)'aPCR3 JG@jNC@CTEQ9N,L"8D'Pc)'0[G@aN)'*P)'&NC'9N)(4[)%42-6FZ$94SB@jVFbi 04A*ZFh30)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b- M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)`dq4R*[E5"QDA4 k3'0KC'9ZBf8ZBfpY)%CbD5"2Bh3J-63J-$%k-63J6898)$%j1630@#e"GA4SC@j dD@0KG'P[ELeABA*ZD@jR1L"MC(-b-$Fb,N0KC'9ZBf8Z3dp01L")Eh0d)'a[Bf& XD'pcG#"ND@4Z*h3JGA0P)%K&6%mJ$5!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#! JF(*[G'pMEf`0@#e"GA4SC@jdD@0KG'P[ELeABA*ZD@jR1L"MC(-b-$Fb,N0KC'9 ZBf8Z3dp01L"QDA4k)'phEQ9N)("bEf0PFh-JC'pTEQFJ,@*c$94[1L"MD(*TFh4 PEN"KEQ&XEfGj,Q0[E5!S4A*ZFh3J3fKbDA0dC@iT$80M1L"QDA4k3'0NFc)`0c) Z3f&NC@jMC5j$6ddX)'&XB@PZ,RCKBfK[GAK!E'9R,Q4P,Q9`CQ`ZBfJ08h9LDQ9 MG$SJ8Q8k)%424#!b,M!04'&dC6SJ4R*T,#!a0#"2Bh3J-6Nj0#!a06Se-6Sb0L! Y-$F`-!e'FQpY1L"%B@jTC@`J4QPdHP"KG(*TBfXJ2'CTG(T!Bf&NC@jMC5jMEfd q$90dBA4eFcSJ8Jd05@iJE@9cFf&RC5!m163a-$%d-M%b-bj"36!h0MBf3(0KG(P b,Q&ZB@a[ChNZBfpY2L`JGh*[G'8k$3e&FQjcG#`0$8NJC'pZ*h3JG'KTEQXJBA0 cG@eTEQFJF'9[F'aP)(9ZC'9bFh4KEQ3JCR9ZC'&YC@jdB@`J9NK%6#"MEfjMCA" dFb"TFb"dEfm0EA9MD#"[CL"K)(0dFQ9dBfJZ)#""CR4PFL"KE'`X)'PZ)'eKERN JF'aKBf9c,#"dD'8J4%p%)'0[ER0TFh4PER4XH5"bC@CPFR-0BQ&MDb"dEb"@5%4 -*cNc,L!J5@BJDA3JDA-JEQ9MCA0cBA*j)'C[FL"ME'&bD@CTBf&dD@pZ,#"dD'9 Z)(0[)'*P)'Pd,#"LGA30G'mJBQ8JBfpZFfPcG'9ZG#"dD'8J4%p%)(0SEh9XC#" SBACP)'&XE#"MBA0PFb"XD@YP)(4SDA-JBfaKFQPQD@9N,#"KEQ3JD@i0G'KKG#" MBA0P)'Pd)'TeFh3JE@PRD(3JBQ8JG'p[)'*TCbi0$8ej)("bC@CPFQ9ZBf8JDA- JEf*fD@peFfaj)'eeBfJJE@pbC5"YD@jTE@&XFh3JB@jN)(4[)(4SC5"`EfPZG#i 0$94SC5"QEfaXEhGTEQFJBfKKEQGPFb"KFQ8J6dXJGfPdD#"YC5`JBR9d)'&RB@P Z)%42-60M)'Pc)'&XFQ9KC(NJBfpfCA*PC#!0BRNJCAKTFh4ZCb"@5%4-)'0[ER0 dFR9MG(-JDA0Z*h3JDA3r)#"CEh9b)(0eCfGPFh4PC#"%6c%dBL"NEf9cELGd)!e bC@&XE(NJE'p[Db"KERPdD'PZCb"XD@YP)(4SC5"fCA*cD@pZ)'PZ)%&XB@PZ*h- JC'pMG@ePER3Z$3em)#!0I#!J4%ma-f)0I#!J5A3JDA-JC'9cDA*KBQaP)(4SBA3 J9NK%6#e")("bEhCTC'9c)'%JE@9MD'&ZDA0Y)(4[)(0`C@0TCRNJEQ9dE'PcG(- J$@0[EQ4TG'P[EQ&X$A`J)(9`EfiJG'KP)(CKE(9P)'pQ)'%JBfpZFh4KER3JF'& bB@ePG'9b)#KMEfjNDA4TEfjKE#"ZCA4XDA0dFbNZ)%%JFh"PBfPKE#!0Bf&cC3e m)#"[CL"dD'Pc)'Pc)'0[E'aKF(0TEQFJ-L"ZEf4PFbi0I#!J$A`J)%42-60M$A` J)%Pd)'Pc)'4PFfPbB@*XC5"dD'&d)&C)4%`Y35"`FQpfD@4PFb"K)'ePBfKKEQP cE5"dEb"cF'9MD@Cj)(*PCh9XBA)JBA*bBAN0I#!JFh4bG@0dGA*PFb"[CL"TER0 dB@jMCA-X)(GTG'JJBfpZFh4KER3JC'PYC@jcD@pZFbi0I#!J$A`J)%42-64L$A` J)&C)4%`Y35"cD'peE'3JFh9`F'pbG#"dD'8JC'9cBh*TF(4TEfiJEfBJF'PPBf9 hDA0P)'4PCQPZC@3JBQ9SBACTEh)Z$A`J)!d0I#!J2L!J,5"%6c%f)'Pc)'PZBfp ZFfPcG'9ZG#iJ)&4SC5"bBA4TEfjKE#"eFf9c)'%JBfpZG(*[E'aPC#"cEh9bBf8 JCQpb)!eUGA0dD@CTBf&dD@pZ$A`J)$iJ)#!JEfBJB@0MCA0c)(4[)'PZG'9bEQ& X)(&eB@jdDA4TCA-X)'K[Gf9fCA)JG'KTFb!LD@jQEh*YBA4TEfiL)'Pc)'&XFfm J$@&fB@PXB@*XC3em)#!q)#!J)'&d)(4SC5"dCA*YD@jKE#"XCACPE#"KEQ3JGfp eE'3JD@jND@0KG'8JG'mJE@8JG'KKG#"dD'8JEfjMC5"NDA0MGA0cC@3J$A0jER4 KH!em)#!q)#!J)'pQ)'&XE'phD@jR)'&MBf9cFb"dEb"dCA*YD@jKE#"MGA*bC@j dFb!SC'&XE'&c,#!j-LNJGfpeE'3JFh9QCQPMC5"KEQ3J$AG[G@aN$A`J)$iJ)#! JFf&dDA0QH5"dD'Pc)(*PFA9TFQ9YC@jd,Jem)#"*)'4[ELGd)'YZEhFJGfKKG#" TFb"TEQ0[ER0TFh4PER3JGfPdD#"dD'Pc)%42,L""Fb"dEb"dD'8JFQ9cG#"[CL" dD'8J$@0[E@ePER3X$A`J)'Pd)'&`F'9KFR-JG'mJE@8JG'KKG#"%B@iJDA-JE@& VD@jR)'&Z)'&cFh9YF(4TEfiJG'KKG#"[EQaj)(4PFQeTEQ&X)!eaG@&ZG'PdD@9 c$A`J)(G[G@aN)'*P)(9cC@3JD@iJBfpZG(*[E'aPC#"cEh9bBf9c)'9dBbiJ5A3 JDA-JGQ9bH5"PBA0j)(4[)'0bC@&dC5"KEL!0CAKKEA"XC3em)#"hD'9bC5"dD'P c)'Pc)'j[G#"dD'8JBf&cC5`JD5jP,L"hD'9bC5"dD'8JFA9KER4TG(NJDA-JF(9 bC@aj)'PZG'9bEQ&X)(4[)'%0I#!JE@pNC@`Z)%&XFfmX)(4SC5"bC@CPFQ9ZBf8 JG'mJ4'&XE'&c)$Nb)'Pc)'PZBA"`FQp`FQPKG'8JD@iJG'KP)%424#`JGfKPFQ8 0I#!JGf8JFfK[G@aN)'j[G#"KER4TBfP`BA4P)'&ZH5"XB@jRG@&RC5"NCA0TCfi Z$3e*)'4[ELGd)(GKER3JG'mJF(9d)'&ZH5"TEA"XC@ePER4KG'P[EL"KFh"PBh4 c)'PZ)(4SC5"%6d3X)'CbB@jVE(NJ55"LC@aTCACP)%N0D'&fC5"LC@9Z)(4SC5" LD@GRCA0d)'&NGQpMBA4P)'pQ)'j[G#"NEfPZCb"dD'Pc,L!J5'phCACPFL`JG'K TFb"%6b"TFb"`FQ9dG(N0EA9MD#"dD'9bC5"dEb"cGA"`Eh*d)(4SC5"498&19%P 8@5"MEfjMCA"d)#KhD'PMD#"*)(0dD@aX)'4[ELGd)'jPBf9cFf&bD@aj$@&RFQ9 P)(GTG'JJCQpb)&C)4%`T)#dJB@jN)'&c)(0eBfJJBfpeE'3JD@iJBfpZBf9`G#" QEh)JG'KP)(*KG'P[EQ&X)'GTGQ9Z$@*P)'4[EQ8JDR9cG#"KFb"hC@aX)(GTG'J JG'KP)&4&8NdZ55"KEQ3J9%9565j@)(0dG@CQ)#KhD'PMD#"hBA-JF(*PFf9ZG'9 N)'PZ$84KE'aKFbFj-bNZ$3e*)'4[ELGd)'*PE'PPGQ8JD@iJGQ9bH5"PBA0TE(N JBh*PBA4PC#"PH'&YF'aPFb`J55"LC@aTCACP)'pZE(NJCAKKEA"XCA-JG'KKG!e bC@CXC@0d)(4SC5"eFf8JE@pNC@`JBA*P)(*PE'9fB@jd,Jd0I#!J$A`J)$iJ)#d J4%ma0b"NGA"XD@0KG'9c)'9iDA0dD@jR)'0[ER0dFR9MG(-JD@iJGQKNE#!SCf9 ZCA*TBh-JBA*P)(0dBA4TBb!0F'&bB@ePG'9bFbN0I#!J2L!J)#"KEQ3JC(PZB@e TBb"`BA*KE@9dCA*c)'0KELGd)'*P)'4[EQ8JB@jjGf&j)'&c)(4SCANJE'9KC#" dEb"cDA4eBA4TEfjc)!e[CL!0I#!J2L!J)#"ZEfiYBfKKFQGP)'0[ER0PFRCKG'P [ELiJ)(4SC5"bBA4TEfjKE#"eFfPZCb"dC@e`CA*KG(9bC5"KFb"KEL"PH'&YF'a P)!e[CL!0I#!J2L!J)#"NH@jKE@PM)(CKFQPKBQaP)'Pc)'PZBfpbFQ9MG#"KE(0 [)#dJG'9YF'9bBA4eFQ8JGfpeE'3JEQ9PC#"dEb"LC5"KEL!0G@jVEQphEJem)#! q)#!J)(4[)'*P)(0[E(CPC#"QEh)JD@iJG'KP)(0jFh4PE5"[CL"PFA9KG'P[ER- Z$A`J)%NJBQ9XD@9fC5"dD'&d)(4SDA-J4%mJDA-JCA0cC@jdD@&X,L"ADA4SEh9 d)'0KFQ9QG@`JB@jKE(PcDA-JEfBJG'KP)'0KF'&LD5d0I#!JE'PdD@9c)("bEhC TC'9N)'*j)'GPEQ9bD@0c)(GP)'0KEQj[G#"KFh0eE@8JG'KKG#"dD'9j)("bEhC TC'8JFh9QCQPMD@9ZG!em)#"QG@jMG'P[EQ&XDA4j)'C[FL"KEQ&XEfFJE@pNC@a TEQFX)("KFR4TBh9XBA*XH5"MEfjcD@4PFQPZCb"dD'8JEQpdC5"TEJem)#"cC@0 dD@pZ)$%Z-5ia,M%Z)'pQ)(4SC5"@5%4-*cNc)%a565`JGfKTBfJJFf9PEA-JG'm JD@jND@0KG'8JG'KKG#"RC@jPFQPMF`em)#"hCA*P)'0bC@&dC@3JGfPdD#"YG@0 S)(0TEA"XCA)JCR9ZBh4TEfjKE'PdH5"TEL"YD@jN,L""Fb"dEb"NH@jKE@PM)!e `BA*KE@9dCA*c,!em)#"*)'4TFf&RFQ9P)(4SBA3JG'KPFf8JE'9KC#"dEb"cDA4 eBA4TEfjc)'pQ)'j[ELeMD'&bCf8JBfpZFf9bGQ&dD@pZ)'&ZH5"YEh*P$A`J)(4 SB@iJB@jjG'KTEQFJC@acC5"TEL"dD'8JE'&ZCh9KCf8Z)&*PCQ9bD@jR)(4[)(4 SC5"PH'&YF'aPFb"`FQpfD@4PC#"LH5",C@i0I#!J5h9ZC'9bG#"cCACPFQ&X)'e [ER4SFb"KCfmJD@jdC@jND@jR)(4[)(0eF("[FR3JG'KTFb"ME'&TE5`J55"LC@a TCACP)(4SBA30I#!JH@pe)'0KEQj[G#"LE'&YC5"dD'8JE'&ZCh9KCf8JD@BJB5" hFQpZCfaj)(GbDA4dC@iJE@pNC@ac)'4[CA-JEQpd)'GTGQ8JG'KP)!em)#"MEh* bC@0d)(0TEA9XBA4TEfiJFQ9cG@adFbi0I#!J$3e`E'9KFf8JC'9cBh*TBQ8JG'K P)'pdD'9b)'&cF'9MG(-JEfBJG'KP)'aKEQGeB@GP)(4SBA3JE'9KC#"dEb"`FQp LE'9YFb"[CJeZEfiYBfKKFQGP)'0[ER0PFRCKG'P[EL"LC@0KGA0P)'NJB@dJD@j dCA*PFh4PC#"TEL"VEQphD@jR,#"TCL"[EQaj)'C[FL"YH3e`CA*cEfjKE#"LC@j PCQPd,Jd0@@pe)'eKH5"ZEh3JBQ8JB@*XC5"dEb"LE'&YC5"dD'8JE'&ZCh9KCf8 JCQpb)(4SCA0P)(4jF'9c)'pQ)("bEf*XC@ec,#"LGA3JGfKj$A"eFfJJCQpb)'0 [ER0dFR9MG(-JG'KKG#"PEQ0[GA*KCf8JF(*[BQaPEA-r$3e5C@GKFQ4TEQFJH@p eFL"QEfaXEhFYGA!JEfiJG@jcCA3JCf9ZCA*TBh-X)'ej)(9ZC'9bFh4KEQ3JEfB J9NK%6#"TFb"dD'&d$@GPEQ9bD@0c)(4SBA3JBA*P)(9ZFf9d)'&ZC#"NEb"ZEh3 JD'&fC5"NC@CKG@ad)(CKE(9PFb"TFb"KEL"PFR*[FLiJ)&0PC@ec$@9aG@&XE(N JBA-JBA"`E'PMB@*XC5"dEb"@5%4-,8%Z$3e8D'8JCQpXE'phD@jR)'0SB@jRC5" TFb"25bi0$A`J)%42-M30I#!J9NK%6#e")(0SEh9XC#"cGA"`Eh*d)(4SC5"KEQj [G'&dD@pZ)'pQ)("SHA0TBf&X)(9ZDA4c)(4[)(GKGQ9QEh*YFbi0I#!J$3dY,84 KEJdM)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b- M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b-M$6j'FQpY)'0SFQPcG'9 Z3'&ZB@a[ChNZBfpY)%CbD5"2Bh3J-63J-$)k-6BJ6898)$%j16304'&dC6SJ4R* T,#!a0#"2Bh3J-6Nj0#!a0cSb-cSe15!V-$J`-!e'FQpY1L"MD(*TFh4PEN"KEQ& XEfGj,Q0[E5!S4A*ZFh3J3fKbDA0dC@iT$94[1L"QDA4k3'0KC'9ZBf8ZBfpY$90 eBQTPBh3k)&*P1L"%6d3J-Li`$80M1L"KE'&TELjfB@0SEh9i3'aPCbjNC5jPF'C X,Q0S,#"MD(*TFh4PEN"YB@PXD'pcG#jKEQ&XEfGj,Q0[E3e6G'&dGA-k)&)0$94 SDA-JDA-JD@iJFQ9cF'pZFf8JG'mJ4'&Z*h-JC@eKD@`Z$3dq55"NEfiRG#"dD'P ZDb"KFh0eE@PZCb"`C@p`E'8JG@jNCA*cG'&ZC#"QG@jNB@ePER4KE#"@5%4-)'0 [EQ0PF(4c)'Pc)(4[E`dqEA9MD#"[CL"K)(0dFQ9dBfJZ)#""CR4PFL"KE'`X)'P Z)'eKERNJF'aKBf9c,#"dD'8J4%p%)'0[ER0TFh4PER4XH5"bC@CPFR-02Q*KBfX JG'mJ9NK%6#Fj-biJ)%PQ)'Pd)'Pc)'jPBf9cFf&bH5"QEh)JBfaKFQPQD@0KG'P [EL`JG'KPEL"cEb"LC5"TG#`JBR9d$6jdEb"LC5"MEfjcDA0dC@jd)(4SC5"%6d3 JFfK[G@aN)'KKGQ8JB@aX)'0KFf9c)'aTDf8JG'KTFb"ME'&bD@CTC@3X)'&ZC#" TEJdqG'KKG#"MBA0P)'Pd)'TeFh3JE@PRD(3JBQ8JG'p[)'*TCbi02Jdq6ANJF(* PCQ9bC@jMC5"TFb"[BRCTEh9cE(NJEA9MD#"YEh*P)'eTEQPYB@acG#"KEQ3JG'm JG'KP)("[D@jd,Jdq$8NJB@dJEQpd)(0KH@PZCb"dD'8JE@PZD@eKE'PcG#"KF(" bEf&MD#"TFb"LB@3X)'&XE#"*)(GKFb"dFRPTEQFJG'mJFf&j)'Pc$A4SBA3JDA3 JDA-JBQ9dG'9b)(4[)(0`C@aX)'peG#"YEh*P)#KdD'&d)'eKH5"LC5"bC@4eEQ4 KER3JB@jN)'pLGQP[GA-T)!edD'&Z)(4[)'C[FQGPG#"cEfePG'KTEQFZ$3dq9'K P)'C[E'a[GfPZCb"MD'&ZCf9c)'&bC5"25b"hDA4S)'eP,#"LGA3JB@GKD@iJ4%m a-f-JDA-JB@abC@&NH5"MEhCPFQ9N)!dqBRNJCAKTFh4ZCb"@5%4-)'0[ER0dFR9 MG(-JDA0Z*h3JDA3r)#"CEh9b)(0eCfGPFh4PC#"%6c%dBL"NEf9cELGd)!dqFQ9 KE'aj)'a[EfXJB@jjG'KTEQFJE'PVC5"dD'8JGQ9bFfP[EL"TEL""E'&TELGc)'4 [Bh9YC@jd,Jdq$8Pd)'Pc)("bEf*KBQaj)(4bG@8JG'KKG#"%6c%cBb"TFb"MEhC PFQ9N)'*j)(4SC5"(48j&8N&845"cG'&dC@ePER3X)'*eG#"hD'm0Dfj[Gh-JGfP dD'peG#"K)'4PG'&TE'9N)'&ZB@ajFfPc,L"0H5"fCA*cD@pZ)'pQ)%42-64L)'0 XBA*TCQPPFb"dD'8JD@jdC@jd1`eTG#"TEQ0XG@4PFb"`D@9MCA-JEfBJG'KP)(* KG'P[EQ&XC5"TEL"dD'8JEf*UC@0dDACP,Jd02R`J)!dqI#!J4%ma-f)02R`J)%P d)'Pc)'4PFfPbB@*XC5"dD'&d)&C)4%`Y35"`FQpfD@4PFb"K)'ePBfKKEQPcE5" dEb"cF'9MD@Cj)'jPG'aTFh4c)!eMEfjNDA4TEfjKE!dqI#!JGA"[EL"dD'8JGQ& XG@8JEfBJB5"MEfjcG'&ZG#"`BA*KE@9dCA)J+'0[EQ4TG'P[EQ&X)'jPG'aTFh4 c+5iJ35"cF'9MD@&X)!eMBA0P$6jm)#"[CL"dD'Pc)'Pc)'0[E'aKF(0TEQFJ-L" ZEf4PFbi02R`J)!dqI#!J4%ma-f-02R`J)%Pd)'Pc)'4PFfPbB@*XC5"dD'&d)&C )4%`Y35"`FQpfD@4PFb"K)'ePBfKKEQPcE5"dEb"cF'9MD@Cj)(*PCh9XBA)JBA* bBAN02R`J)(0dFR9MG(9bCA-JEfBJD@jcG'&ZBf9c,#"hDA4S)'0[ER0dB@jd)'4 TE@9ZFfP[ER-Z$6jm)#!02R`J)%42-64L$6jm)#"@5%4-,8%JFfK[G@aN)(0eF(" [FR3JG'KP)'4PFf0bDA"dD@pZ)'pQ)("TC@0PGfPcC5"NC@CTEQ9N)'*PD'&fD@p b,JdqI#!J$6i02R`J)$iJ)#dJ4%ma0L"TFb"TEQ0[ER0TFh4PER3Z)#"8D'8JFQ& dD@pZB@`JGA0PFb"K)'0[ER4bEfaXC@3JFfpeFQ0P)'C[FL!0DR9cG'PQD@0KG'P [EJdqI#!J2L!J)#"[CL"KBf0PFh-JG'mJD@jdCA*ZB@`JFA9KER4TG'PPFb`JD'p hCACPFL"dD'Pc)#*TEQC[FQeKG'P[EL)JDA-JB@acEb!0BACKD@aKBQaP$6jm)#! q)#!J)'&d)(4SC5"dCA*YD@jKE#"XCACPE#"KEQ3JGfpeE'3JD@jND@0KG'8JG'm JE@8JG'KKG#"dD'8JEfjMC5"NDA0MGA0cC@3J$A0jER4KH!dqI#!J2L!J)#"[CL" KE'a[GfPZCb"KBf0PFh-JG'mJG'9bE@PZB@`JBh9bFQ9ZG(-J+'4KE'aKFb`J16) T)(G[G@aN)(0eCQCTBf8JB@jN)!ehEh9XC!dqI#!J2L!J)#"cBA4TFfCj)(4SDA- JFQ9aG@PbC@ePER3Z$6jm)#"*)'4[ELGd)'YZEhFJGfKKG#"TFb"TEQ0[ER0TFh4 PER3JGfPdD#"dD'Pc)%42,L""Fb"dEb"dD'8JFQ9cG#"[CL"dD'8J$@0[E@ePER3 X$6jm)#"TG#"KF("PBA*c)(4[)'eP)(4SBA3J4'&Z)'Pc)'eKDfPZCb"KEL"KFh0 eEA"dD@pZ)(4SBA3JEfjXH5"dCA*YD@jKE#!0FA9KER4TG'PPF`dqI#!JGfpeE'3 JBQ8JGA0PC#"TEL"MEfjdFQpXE'9N)(0[GA*MCA-JCA4M,L"*G#"TFb"fCA*j)'9 KFhNJG'mJBh*PBA4P)'&Z)!ePH'&YF'aP$6jm)#"hD'9bC5"dD'Pc)'Pc)'j[G#" dD'8JBf&cC5`JD5jP,L"hD'9bC5"dD'8JFA9KER4TG(NJDA-JF(9bC@aj)'PZG'9 bEQ&X)(4[)'%02R`J)'e[C'9X,L""E(0[,#"dD'8JFQ9QCA*PEQ0P)(4[)%4KE'a KFb!j-L"TFb"TEQ&`F(*[F(*TBA4P)'PZ)(4SC5"%6d3X)(GSCA*P$6jm)#"hC5" cD'peE'3JEQpd)'&ZG'PMDA"KG'8JB@jj)'aKEQGeB@GP)'4PFfPRELi02Jdq55" NEfiRG#"hB@jd)(4[)("eG#"KERNJD@e`E'9YC@jdBA4TEfiJBA0`C@0dFb"TEL" dD'8J4%p%,#"QFQ&ZDfaj)%NJBQ9XD@9fC5"*$6jSBACP)'*PC@iJG'KP)'*TCfG PFh3JB@4fEf0KG'8JEfBJEQpd)'4[D@jR)(4SDA-Z)#")EhGPGQ9b,#"dD'Pc)%4 2)'Pc)("bCA4dH3dqEA9MD#"dD'9bC5"dEb"cGA"`Eh*d)(4SC5"498&19%P8@5" MEfjMCA"d)#KhD'PMD#"*)(0dD@aX)'4[ELGd)'jPBf9cFf&bD@aj$6jKCh*PC5" hDA4S)'C[FL"@5%4-+5!Y)'&ZC#"KFb"cG@0S)'0[G@aN)'PZ)'0[EQ0PF(3JCQp b)(4SC5"bBA4TEfjKE#"RDACPEJdqBQ8JC'pZC5"UGA0d)'&c)(GPE'`JGfPdD#" dD'8J9%9565j*)'&ZC#"849*0,PBJFh4eCQBJ+(GSD@0S)(GKFb"`FQ9cC@jdC@3 JD@i02N4KE'aKFbFj-bNZ$6i09'KTFb"%6b"cBAPc)'j[G'KTEQFJB@*[GA3JD@e `E'9YC@jdBA4TEfiZ)&*KG'KPFL`JDA3JFf&jFb"dD'&d)'Pd)'eeFh3JBQ8J$A" [Fh0TBQaP)(4[)'&MBf9cFb"QEh)JD@jcG'&ZBf8JBR*KEQ0S)'0eFR*PER4c)'4 PCQPZC@3JFfpYCAGSCA*P)'PZ)'%J$@0[EA"[EQ9ZG#"QFQpY)'peG(0TC'8JG'K P)'0[EA"[EQ9ZG#iJ5A3JC'pPFb"ZEh3JFf&j)'K[Gb"dD'Pc)'Pc)(4[)'*P$@& MBfpYF'aTFfKPC#`JB@jN)(GSD@aP)'Pd)(9cCA-JG'KP)'GPEQ9bD@-JG'9bE5" aG@&ZG'PdH5"bBA4SCA)JG'KKEL"LFQ&ZBfJJ$@0eFR*PER4c)'pb)(4SC5"XD@Y P,#"dD'Pc)'4[CA-JEQpd)'PYF'aj)'&d)'&XE#"dD'8JCAKTFh4PEQ0P)'pQ)'% J899"6P4*9&NZ$8PQ)(P[G5"`FQ9QCA)JGf&fC@C[FQdJBA3JG'KKG#"`E'&MC5` JG'KTFb"TFb"QD@jP)(GTG'JJE@8Z$3dq55"NEfiRG#"LC@aTCACP)'PZ)(CPFRN JC@&cD@aj)'0bC@&dC@3JCAKKEA"XCA-X)%NJBQ9XD@9fC5"[EQaj)'9iB@e`E'9 c)(4SBA302R*PCQaPBh3JG'KP)(9cC5"YEf4PE#"KFQ8JFQ9XCACKER3Z$6i02R` J)!dqI#!J2L!J,5"%6c%h)'4eF'aTBf&dCA-JCAKTFh4TEQFJBfpZFh4bG@0dFb" TEL"fD'4X)#KRC@jPFQPMFb"KFQ8JFh4KG'PM)!e`BA*KE@9dCA*c+3dqI#!J2L! J)#"KEQ3JC(PZB@eTBb"`BA*KE@9dCA*c)'0KELGd)'*P)'4[EQ8JB@jjGf&j)'& c)(4SCANJE'9KC#"dEb"cDA4eBA4TEfjc)!e[CL!02R`J)$iJ)#!JEQpZ,@0SBA* RC5"MEfjcCA*fBA4TEfiZ)#"dD'8JFQ&dD@pZB@`JGA0TEQFJG'9YF'9bBA4eFQ8 JBA-JB@iJCAKKEA"XC5!0EfBJ$6jm)#!q)#!J)'4jEQ&YD@-JGQ&bD@&LE'8JDA- JD@jMEh*bC@0d)'&XFfmJ,5"dC@e`CA*KG(9bC5"hEh9XC#"ZC@9N)(4[)'*P)'& Z)!eeEQYZEhGZ$6jm)#!q)#!J)(4[)'*P)(0[E(CPC#"QEh)JD@iJG'KP)(0jFh4 PE5"[CL"PFA9KG'P[ER-Z$6jm)#"*)'*PE'PPGQ8JG'KKG#"dD'Pc)%42)'Pc)'9 cFf9ZG'PKE#iJ9fPdD'peG#"MBA*PCR9X)'&ZB@ajFfPc)'pQ)(4SC5!0Bf&`B@* T,3dqI#!JE'PdD@9c)("bEhCTC'9N)'*j)'GPEQ9bD@0c)(GP)'0KEQj[G#"KFh0 eE@8JG'KKG#"dD'9j)("bEhCTC'8JFh9QCQPMD@9ZG!dqI#!JCR9ZBh4TEfjKE'P dH5"QEh)JB@jKE'pR)'e[C'9XD@jR,#"`BA*dD@0eE'&bE(NJBfpZFfPNCA*TEQF JG'KP)'j[G'8JD@i02R`J)(0PBh4TEfiJ-5ia,M%Z-5iJEfBJG'KP)&C)4%`R16- J6&*0,#"hD'PMD#"cC@9YFb"dEb"TEQ4TBf&dC5"dD'&d)'GPEQ9bD@0c$6jm)#" hCA*P)'0bC@&dC@3JGfPdD#"YG@0S)(0TEA"XCA)JCR9ZBh4TEfjKE'PdH5"TEL" YD@jN,L""Fb"dEb"NH@jKE@PM)!e`BA*KE@9dCA*c,!dqI#!J55"NDA0KCh*PC5" dD'&d)(4SCA0P)'aPB@3JG'mJFfPdG@&dD@pZFb"[CL"ZEfiYBfKKFQGP)'0[ER0 PFRCKG'P[EL"KERNJ$@e[FQ802R`J)(4SB@iJB@jjG'KTEQFJC@acC5"TEL"dD'8 JE'&ZCh9KCf8Z)&*PCQ9bD@jR)(4[)(4SC5"PH'&YF'aPFb"`FQpfD@4PC#"LH5! 05f9Z$6jm)#",G@jNCA*d)(0PGQ9bB@`JE@pZG'Kc)'&REb"TER4PEQ4TEQFJG'm JFh9`F'pbG#"dD'Pc)'0XB@PY,#"*)'*PE'PPGQ8JG'KKG!dqI#!JH@pe)'0KEQj [G#"LE'&YC5"dD'8JE'&ZCh9KCf8JD@BJB5"hFQpZCfaj)(GbDA4dC@iJE@pNC@a c)'4[CA-JEQpd)'GTGQ8JG'KP)!dqI#!JBfpbFQ9MG#"cD@eeE'&dD@pZ)(*PFh9 XG(-Z$6jm)#!02JdqF'aPBA0P)'4PFf0bD@*P)(4SC5"[G'KPFL"KFh"PBh4c)'p Q)(4SC5"XB@jRG@&RC5"dD'&d)'aPB@3JG'mJF(*[BQaPEA-JEfB02Qj[ELeMD'& bCf8JBfpZFf9bGQ&dD@pZ)'*PBf&eFf8JD5"KE5"TER4PFQ9cG'9N)'PZ)'YZEhG TEQFX)'PQ)'pZE(NJCQpb)'ej$6j`CA*cEfjKE#"LC@jPCQPd,Jdq$9GPE'`X)%Y PELGc)'9iB@e`E'8JGf&c)'%JBf&`B@0TG'pb)(GSD@0S)'KP)'PYF'aPE@9ZG'9 N)(0[E@9dD'PZCb"XD@YP$3dJ)#!J)#!J)&*&6%&858p1$5!J)#!J)#!J)#!J)#! J)#"&899"9%P26P-0)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J+(!XELNZD5!p25" M+Q4NG#JSF#aZ+5jf+6X0)#!J)#!J)#"&6N3J8N9-394*6dil$3e)DA-JBfaKD@d JGf&c)(4SBA3JD@BJBb"TFb"NCA"PEQ4PER3JEfiJG'PYC5"dD'&d)(4SDA-JE@p NC@`JGfpeE'3JCfPfC3ehFQpZCb"bCA0eE(4c,L")C5"KFh0eE@9N)(4SBA3JG'K P)(CKE(9P)'pQ)'-JDA-JF(*[GQPNC@3JBA-JB5"`BA*KE@9dCA)0G'mJG'KP)'e [C'9X)#KT,Q8Z)'&c)'%J4d9149**3bNZ)%NJE@PRD(3JDR9cG#"KFb"hC@aX)'4 PCQPZC5"M)'&c)'%JG'PYC3eNCA"PEQ4PER3JGQ&XG@8JD@jcD@4P)(4SC5"KFQ0 SDA4PBh4eFQ8X)'&ZC#"dD'8JFf&YC5"`FQpLE'9Y)'9iDA0dFbiJ$8&ZEh4SCA) JCAKKEA"XC5"TF`d0)#!J)#!J)#"548a"9%P26JdJ)#!J)#!J)#!J)#!J)#!J8&* 23d9%99*"6!dJ)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#"Z,QNJ1MdJ+'-V-5NUC'4 d+#K`,'iT,RBT1`dJ)#!J)#!J)#!J)#!J)#!J49&9394*6dj6$5!J)#!J)#!J)#! J)#!J)#!J)#!J)#!J)(!ZD5!p25"M+Q4NG#JSF#aZ+5jf+6X0)#!J)#!J)#"&6N3 J8N9-394*6dil$3e*EL"[G'KPFL"hEh*NFb`JEQpZ,@0SBA*RC5"MEfjcCA*fBA4 TEfiJDA-JEQpd)'%JF(*[BQaPE5"bC@aKG'9N)(4[)(4TE@8J$@4PF'9ZC'9ZG#" YEf4PE#"`BA*KE@9dCA*c,Jd02PP[G5"YBANJEQpd)'*P)'&LE'8JG'mJBQaKE@8 JG'KP)'aKEQGeB@GP)'C[FL"dD'9cC5"dHA"PFb"[CL"`FQpLE'9YFb`JBR9d)(G SH3dqF(9cD#"QEh)JBfpZFh4bG@0dFb"dD'&d)'9ZBfpeFQ&RC5"`FQpLE'9YFcm 02Je*EL"YH5"[F'PZD@pZ)'Pd)'Pc)'j[G#"dD'8JBfpZFh4bG@0dFb"dD'&d)'9 ZBfpeFQ&RC5"`FQpLE'9YFb`JDA3JDA-JG'KPDA)J$@PYF(*[F'9b)(9cC5i0$6j 5C@GKFQ4TEQFJH@peFL"QEfaXEhFYGA!JEfiJG@jcCA3JCf9ZCA*TBh-X)'ej)(9 ZC'9bFh4KEQ3JEfBJ9NK%6#"TFb"dD'&d$6jRC@jPFQPMFb"dD'&d)'&bC5"eER0 PG#"KEQ3JC'mJEQpd)'KKGQ8JC'9QBA9XG#"fB@aeCA-JDA-JB@iJCA*bEh)Z)#" 6C@9YF`dqCA&eB@aXH5"KFb"KF("XD@0KBQaP)(4[)&C)4%`Y35i02Je8D'&d)'P c)'j[G#"hD'&d)%NJE@9KER3X)(4SEh9RD#iJ6@&bDb"DGfpXD@jcDfNRFb"MEfe YC@jd,#"hD'PMD#"*)(0eF("[FR30BfpYF'aPG'9XH5`JDA-JG'mJBQ8JB@*XC5" dEb"XC@&fC5"K)(CKE(9P)'PZG'9ZG'P[EQ&XE(NJG@jcF'9MD@CTC@3X)'&ZC#! 0G'KPEL"LC@PZCb"KBQaP)(4[)'4PG'9MG#"hD'9dD'9b)'Pd)'KKFb"LC@9Z)(0 `C@0TCQPPC#"[FL"ZEh3Z)%eKFQXRF`ePH'&YF'aPFb"MEfeP)'CbEfdJ8e"*3d8 JBfpNC5`JGfKPFQ8JG'KTFb"dC@0SEQPaG@8JD'&c)'*PC@iJGA0PC#"KE'`JEhC PFJedD'8JF'aKBf8X)("KFR4TBh9XBA*XH5"hDA4S)'e[C'9X)("KFQ&YCA4PFR- Z)&4SC5"TEA"XC@ePER4KG'P[EL"[CL"dD'Pc$@0[G@aN)'*P)(4[)'KKGQ8JB5" cF'9MD@&X)'0[ER0dB@jd,#"cBANJ98j68%9$58C*483X)(GSD@0S)'Pc)'4TFh4 TEQGeDA0SB@*XC3eQFQpY)'pdD'9b)'CXEf&dD@jR)("[D@jd)(CKE(9PFb`JB@j N)(4SC@iJC'9QBA9XG#"MCA*dB@PZ)("KFQ&YCA4PFR-JG'm0G'KTFb"fB@aeC5i J$3e&FQjcG!dM)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b- M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b-M$6j'FQpY)'C TG(T!Bf&NC@jMC5jMEfdJ8h9Z)%pMG#!a0L!a16Sc0L"0493J-6Nj0!eB,8&eG'K PER4TBf&dD@pZ,9GKFQjTEQFk)'0NFc)`0c)Z3f&NC@jMC5j$6ddk)%K[Fh3JE'p MB@aSEh0d)'4TC'iRG#"eFf8J5%9-6b!0)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#! J)#"`FQpdEf0[E!eB,8&eG'KPER4TBf&dD@pZ,9GKFQjTEQFk)'0NFc)`0c)Z3f& NC@jMC5j$6ddk)'CTG(SJEhGZC@3JF(*[Bf9cFb"NEfPZCb!YBR-09'mk)'0SFQP cG'9Z3'&ZB@a[ChNZBfpY)#K&FQjcG#"$D(*TFh4PELN03f-k)'CTG(T!Bf4c-M! h-Lj$B@4PEQ0P,N0265`JB@aKD@iZGQ&MD'peH%"XC@FZC'8ZCA"QE#jMD!e6G@* UC@0d1L"5C6SJ4%p%)$)Z-!e%BA4P1L"0EfiX)$%h)%pMG#!a16Nd)$%`1M3b1M) c)#d`0c!`$8CbEfdk)%4KEQPPE#"'DA4k8'&dFQPMDb!mCQPdHN"MB@4PEQ0P,Q0 [E6i08h4KG(9c1L"5$3e*EL"YCA0cB@GP)$`j0$%`-68`-$)c,N&"-$Jf-M&!Ff& dHA)ZB@jKE'pRH5jMEfdq,#"hFQpdC6S0I#!J2Jem)#!qF'aPBA0P)'4PFf0bD@* P)(4SC5"[G'KPFL"KFh"PBh4c)'pQ)(4SC5"XB@jRG@&RC5"dD'&d)'aPB@3JG'm JF(*[BQaPEA-JEfB0I#!J2Qj[ELeMD'&bCf8JBfpZFf9bGQ&dD@pZ)'*PBf&eFf8 JD5"KE5"TER4PFQ9cG'9N)'PZ)'YZEhGTEQFX)'PQ)'pZE(NJCQpb)'ej$A`J)$j `CA*cEfjKE#"LC@jPCQPd,Jem)#!q$A`J)&GPE'`X)%YPELGc)'9iB@e`E'8JGf& c)'%JBf&`B@0TG'pb)(GSD@0S)'KP)'PYF'aPE@9ZG'9N)(0[E@9dD'PZCb"XD@Y P$A`J)!em)#!J)#!J)&*&6%&858p1$A`J)#!J)#!J)#!J)#!J)#"&899"9%P26P- 0I#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J+(!XELNZD5!p25"M+Q4NG#JSF#aZ+5j f+6X0I#!J)#!J)#"&6N3J8N9-394*6dil$A`J)!em)#")DA-JBfaKD@dJGf&c)(4 SBA3JD@BJBb"TFb"NCA"PEQ4PER3JEfiJG'PYC5"dD'&d)(4SDA-JE@pNC@`JGfp eE'3JCfPfC3em)#"hFQpZCb"bCA0eE(4c,L")C5"KFh0eE@9N)(4SBA3JG'KP)(C KE(9P)'pQ)'-JDA-JF(*[GQPNC@3JBA-JB5"`BA*KE@9dCA)0I#!JG'mJG'KP)'e [C'9X)#KT,Q8Z)'&c)'%J4d9149**3bNZ)%NJE@PRD(3JDR9cG#"KFb"hC@aX)'4 PCQPZC5"M)'&c)'%JG'PYC3em)#"NCA"PEQ4PER3JGQ&XG@8JD@jcD@4P)(4SC5" KFQ0SDA4PBh4eFQ8X)'&ZC#"dD'8JFf&YC5"`FQpLE'9Y)'9iDA0dFbiJ$A`J)%& ZEh4SCA)JCAKKEA"XC5"TF`em)#!0I#!J)#!J)#"548a"9%P26Jem)#!J)#!J)#! J)#!J)#!J8&*23d9%99*"6!em)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#"Z,QNJ1Md J+'-V-5NUC'4d+#K`,'iT,RBT1`em)#!J)#!J)#!J)#!J)#!J49&9394*6dj6$A` J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)(!ZD5!p25"M+Q4NG#JSF#aZ+5jf+6X0I#! J)#!J)#"&6N3J8N9-394*6dil$3ejC@&S,L!JH@peFL"bD@GSG#iJ)'*[G'JJBA* P)("bEf*XC@ec,L!JD'phCACPFL`JEfjP)'Pc)(9ZC'9b)(4SC5"MEfjdFQpX$@p Q)(4SC5"`CA*cEfiJC'pTEQFJG'KP)'e[C'9XD@jR)#KSDA-JCQ&eE(3T,#"dD'8 JEh4SCA)JDA-JG@jNCA)JG'KP)'0[ER4bEf`0EfBJG'KP)(9cCA)J+'j[G#"dD'8 JE@pNC@aPFR-JCQ&eE(3T,L!JG'KPFf8JBA*P)(4hEb"fCA*j)'4TCQCPFQ9ZG#" cBf9ZBA*TEh-Z$@&c)'pZC5"[CL"dD'8JE'&bCf9cG#"fC@jNEh*c)'pQ)'&ZB@a [Cb"YEf4PE(-X)'Pd)(G[G@aN)(0PC@dJG'mJE@8JG'KKG!ejEh8JGfpeE'3JBQ8 JE@pbC5"MEfjMCA*ZC@3JB@*[GA3JG'KTFb"`EfPZG#"dD'&d)'&ZH@pZC5i0$A` J)%PZ)'ej)'p`D@jTEfiJDA3JDA-JEQpd)(4SC5"MEfjcG(*eBh4c)(4SBA3JC@j MEh9bB@GP)("bEf*XC@ec,#"TG#"TFb"dD'9TFL!0I#!JD@e`FQp`CA)JGA0P,Jd 0DA3JDA-JE@pbC5"XD@YPE(NJG'KKG#"`C@p`E'8JG'KKG#"NCACPE'p`)'e[C'9 XFb"hD@aX)'KKGQ8JB5"RFQ9KG'9b$A9ZC'9bFh4KEQ4TEQFJEfBJER9YCA*TBf& X)'PcFh9PFb"dD'&Z)(0[E@9[EQ8JF(9XE'PZCb"`BA*dFb"[GA3JEfBJB5!0E'P LFQ&bH5iJ)'0[ER0dFR9MG(-JG'KKG#"PEQ0[GA*KCf8JB@*eFf8X)(GSD@aP)'p QCQ9bD@jR)'aTG(4XC5"TEJebCA4eFQiJ+'NJD'&fC@iRG#"cC@9Z)'&ZH@pZC5" MEfeP)(9`)(GTG'JJE@pbC5"dD'&Z)'%JBfpeF'aP)'pQ)'aTEQ80CAKKEA"XC5" eFfPZCb"dD'Pc+5`JFfK[G@aN)'*P)'&fEfPNC@3Z$3dY,@4KEJdM)b-M)b-M)b- M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b- M)b-M)b-M)b-M)b-M)b-M)b-M)b-M$94[1L"%B@jTC@`J4QPdHP"KG(*TBfXJ2'C TG(T!Bf&NC@jMC5jMEfdq,#"MD(*TFh4PEN"KEQ&XEfGj,Q0[E3e'FQpY1L"KE'& TELjfB@0SEh9i3'aPCbjNC5jPF'CX,Q0S)#K"E'&TEL"@B@0SEh9i)%934N`Y6%9 (,d-cD5N08h9LDQ9MG$SJ8Q8k)%424#!b,M!03f-k)!e#Bf-k)!eB,8&dG'&MD'e PER4c1L!0$84KEL`J4A*ZFh3X$3eAD(NJC'PNELGd)(P[G5"`GA3JH@peFL"MEfe YC@jdFb"[EL"dD'8JFQ9QE'9MG'pb2b""E'`JG'KTFb"NDA0MGA0cD@pZ)(0SEh9 XC#!0BQ8JEfBJD@jdCA*PFh3JG'mJEh4SCA)JF'9[F'aP,#"KG#"XC@&cG#"dD'8 JCQ9h)'pZCA-JG'KKG#"KE(*PB@4j)'GKGQ8JFfpYC5!0BfpYE@9ZG(-JEfiJG'K P)%424#!b,M!JBA-JGf9XE#i0$84KEL"cBAPc1Jdq)#!Y)(*PE@pfC5"MEfeYC@j dFbi02L!J,5"bC@e[GQ8JB@jj)'*KBfYhBA*N)(*PCQ9bC@jMCA-JG'mJEfaN)(C PFR0TEfjc)'pQ)%424#!S@edJFQ9QFb"dEb!a,MBT,Jd09'KTFb"hD@aX)'*P)'4 [EQ8JCQpb)(4SC5"fCA*cD@pZ)(4SC5"A4b"hD@aX)'KKGQ8JG'mJGQpdC5"[ELi J3@j[G'KPFL"`EfPZG$SJ$A4[)'GPG#"K)'0[ER0TFh4PER3JER9YBQ9bD@jR)(0 MD'9YC5"hDA4SEh9d)'K[E'9c)#K%6c-`)'Pc)'eTFh0TEQFT)'&ZC#"hDA4S)!e ZCAFJ4%pc)'PZBfaeC'9N)#KZEb"YEh*P)(0[E@9dD'PZCb"XD@YP)%42@')T,Jd 03@*[GA3JG'KP)%424#"`D'PXEh0[F'Kj1Je*)(4SD@jV)(GP)'&XE#"KCh*PC5" dD'&d)(4SC5"%6d3JFfK[G@aN)'*P)'&c)'0[EQ0TFf8JBA-JF'pcFfPLE'8Z)%p Z)(4SC5!0Eh4SCA)JD'&ZC#`JDA3JB@acEb"cD'peE'3JBQ8JFf9XCLeMEfjdB@P ZC@3JGfPdD#"YD@jTEA9Y)(*PCQ9bC@jMCA-JG'mJ$@9iG'9bEQ&X)(0dG@CQ,#" KE(4SEh9RD#"cG@0S)(*PCQ9bC@jMCA-JBf&ZEQpd)'*P)'&fEfPNC@3J+'8ZCbi JG'mJ9NK%6#`JG'mJ$903580&+5iJ55"cC@0[EQ3J4A*ZFh3JG'mJB@aXEhFJFfp YC5"bC@4eEQ4KER3JEh)JEf*fD@peFb"cG'&dC@ePER4c)'PZ)(4SC5"%6h-J$@P Q)(4SCANJBR*TEQFJFfpYC5"ME'&bD@CTBf&dD@pZ)'pb)'PQ)(4SCANJE@&VC5" dD'8J4%p%)'e[FQ8JFf9XCLeMEfjdB@PZC@3Z)%NJ$@&XFfmJG'KTEQXJDA3JDA- JD@e`Eh*dB@jd)(4[)'0XC@&bE(NJFh4KG'8JB@aX)(4SC5"ZC@0PFh0KFRNJFQ9 aG@PbC@ePER4c,#!0CACPEL"TCL"dD'9j)'eTCfKd)'*P)'CeE'CTE'aPC#"hDA4 S)'9iDA0dD@jR)&C)4%`JBfpZBf9`G(-Z)%Pd)'Pc)'j[G#"dD'8JCfpKE#!0EfB JG'KP)%424#"dEb"`FQpfD@4P)'C[FL"dD'Pc)'YTEQ3JEfBJG(*KBfPZCbi0$84 2-60L)#KKEQ3J4%ma-f-T1Je&FQjcG#"`FQp`Eh0PFb"dEb"cF'aTG#"%6c%cBL" TER4[)(4hEb"cCA"KFQ&dC5"%6h-k)'pZC5"KBQpeG#"dD'8JBfpZC'PdD@pZB@` J$@jPG'aTFh3JB@jN)'pZC5"KBQpeG#"bC@GeE'&b)'&ZB@a[Cb"cG(*eBh4eFQ9 c,L"8D'Pc)'Pc)%p,)(GTG'JJE@8Z)&*KG'P[EQ&XCA-J$@&XFfmJD'&fC5"dEb" LC5"cF'aTG#"TER4[)(4hEb"`BA*dFbi0$842-64L1Je&FQjcG#Gc)'jPGb"bCA" SFQ&cC@ePER3k)#*@5%4-,8%JFfK[G@aN)(0eF("[FR3JG'KP)'4PFf0bDA"dD@p Z)'pQ)("TC@0PGfPcC5!0C'9QD@jPC#"LC@KKGQP[FL)JC'pPFb"ZEh3JFQ9KE'a j)'*bD@jR)'0XBA*TCQPMBA4TEfiJG'mJE@8Z)%NJG'KTEQXJG'KKG#"dD'8J$A" bCACTEh9c)(0PER4PEQ0P)'&XEfjR)(GTG'JJDA4c)(*KG'P[EQ&XC5"KE(*PB@4 j)'0XC@&bE(NJFh4KG'9N)(GSBA3J$5*MEfjNDA4TEfjKE#"LC@KKGQP[FL)JE@9 KER-Z)%NJGfpeE'3JDf9PF#"dD'Pc)%42)'&c)'Pc,Jd04'&Z)(0KHA-k$6jdD'P c)'Pc)'%JE@&bCfPZB@aXH5"LC@jPCQPMD@&X$6iJ)#!JEf*UC@0dDACP)'C[FL" dD'pcC5"dD'&d)(G[G@aN)(4jF'PMB@aXH5"eFf8JGQKNE#eK)(4SBA3JCR9bG'K PFL"MEfjQGA0PFb!02L!J)#"dD'PZCh-Z$89fC@iJE@&bCfPZB@aXH5"LC@jPCQP MD@&X,#"KEL"[BQTPBh4TGQ8JDA-JB@iJEf*UC@0dDACP,L"8D'8J+Q4PFfPbB@* XC5SJ$A"bEh"PFR4j)'Pc)'&XFfmJD'9bC5"dEb"MBA4MD#"eF#"dD'Pc)'YTEQ3 JEfBJ4%mZ$3e%6c%f1Je*)'&XFfmJC'pZ*h3JFf9P)'&ZH5"TEA"XC@ePER4KG'P [EL"KFh"PBh3JD@iJG'KTFb"%6b"KFb"TG#"TFb"MGA*bC@jdE(NJ$A0dBA4PC#i J9'KP)(4PFQdJ)R&eB@jdDA4j)L"eFf9N)'pZE(NJFQ9QCA*c)(4[)(0[E@8JB@j KE'pR)(GKGQ9QEh*Y)(4SBA3JBfpeE'3J$@*P)(*PB@3JEh)JGh*TG(4PEL"TER0 TC'8JFfpYC5"KEQ&XEfFJBfpYF'pZC@jd,L"1Eh4SD@jR)'e[FQ8Z)%j[)(9`F'9 bBf&cC5!0899"6P4*9&NJDA-JGA0PC#"hD'PMD#"YD@GSG#"TEQ4TBf&dC5"cEfe P)'jPGb"VCAPhEh*N)'pb)(0[E@8JEQ9h)'pLDQ9MG#"TEL!09NK%6#e",L"*G#" TFb"eF#"dEb"dD'8JE'&ZCh9KCf8JC'9cD@GZ)(4[)'4PBfPNC5"TCL"dD'8JG'9 bE5!LFA9KER4TG(NL)'jPC@4c)!eK)'jPGb"[BQTPBh3JEh)JEQpd,Jd055"KCh* PC5"hDA4S)%4KEL"dD'&d)(4SDA-JDfPZC#"[CL"TEQC[FQeKG'P[EL!UE@&j)'* P+L"KE(0[)'&fB@PXB@*XC5"dD(*[G@GS)!edD'8JG'9bE@PZB@ac)#K,3d`[5eC -)'0[EQjPBh4TEfiJF'pTER4c+5iJ55"dD'PZDb"SEhGPGQ9b)'Pd)'eTCfKd)'* P)(9cC@CeE#!0G'mJF(*[GQPNC5"dD'8JGA0PFL"hDA4S)'&ZEh4SCA)JD@jdCA* QB@0P)'ePBfKKEQPcE5"hD'PMD#"NEf9c)'j[G#"NCA"PEQ3JEfiJ$8YTFQ0SD'p QCLGc)(0PE@&ZG'PMFb`JCA0`C@0TB@aXH5"QEh)JFfPREQ&X,@CXEhFJCh*KF'J JC'9cBh*TF(4TEfjc)#KhD'PMD#!09NK%6#e")'Pc)(0eF("[Ff9N)(4[)(0eF(" [FR3JBA-JGf9XE#`JFf9P)%42-6)T,L"")'e[C'9X)'pQ)'%JBfpZG(*[E'aPC#! 0FfpeFQ0P)(9cD@jR)(4SDA-JBf&`B@*TE'PdH5"TFb"TEQ4PC@3JE@pbC5"KBR0 dFQ&MG#"dD'&Z)'&Z)'9aG@PfB@aPER3JBfPbBh9TG#!0E'9fC@`JC'9cBh*TF(4 TEfiJGA0TEQFJEfjXH5"dCA*YD@jKE(-Z$3e%6c%h1Je%B@iJFf&jFcSJ)R4SC5" bBA4TEfjKE#"eFfPZCb"dC@e`CA*KG(9bC5"KFb"KEL"PH'&YF'aP)'pQ)'4jEQ& YD@-JGQ&bD@&LE'8JDA-J$@PZBfpbFQ9MG#"KE(0[)#dJG'9YF'9bBA4eFQ8JGfp eE'3JEQ9PC#"dEb"LC5"KEL"eEQYZEhGZ)(4[)'*P)(0[E(CPC#"QEh)JD@iJ$A4 SC5"cHA0dC@dJEfBJCA&eBA4TEfjc,L)0$8NJB@GbC@8JG'KKG#"dD'9bC5"YBAN JBQ8JFfpYC5"MEfjQGA0TEfiJD'9bC5iJ3A-JB5"NH@jKE@PM)("KFQ&YCA4PFL" YBANJGQ&bH5!0C(9bD@jR)(0TEA9XBA4TEfiX)'Pd)'eTCfKd)'*P)'9TG'KPFL" MEfe`GA4PC#"dD(*[G@GS)(4SC5"cEfaeG'P[EL"[CL"dD'8J$A0jFh4PE5"[CL" PFA9KG'P[ER-X)'pb)'Pd)'eTCfKd)'*P)'pZE(NJBfpYF(9dC@3JF(*[Bf9NGA* KE'aj)#KT,Q8Z)'j[G#!0BfpZFfPNCA*PC#"KFb"KEL"eEQYZEhGZ+5iJ5@iJG'K P)'C[FQePFL"MBA0P,#"dD'8JG'9YF'9bBA4eFQ8JE@PRD(3JBfpYC5"QFQpY)!e K)(4SCA*YB@`JBfpYF'pZC@jd)#KdHA"TBf&XE(NJG'KbEh9RD#"K)(&eB@jdDA4 j)'&c)%42-6BJBA0VFb"QEh)T,L"*EL"dD'8J$@aKG(4PFL"MBA0P,#"TG#"YD@G SG#"MEfeP)'CbEfdJFfpYC5"TER"eG#"cG'PYG@aT)(4SBA3JC'9cBh*TBQ9c)'K [Gb"dD'8J$A4PEA"PFQ&dGA*P)'9fEfafCA-JD@iJG'PYC5`JEh)JBQ9MBA9cC5! UFh9MBf9cFfPfC5SJFfPYG@aKG'P[EL"KFQ8JBQ9TEQFJ$A*PFA9TFQ9N)'C[FL" dD'8JFf&YC5"NCA0MFQP`G'P[EL!SBA-JGfPdD#"dD'8J8e"*3d8J,P4&69!JBfp ZG(*[E#"cG'&dC@ePER3T,L!05@iJG'KTFb"MBA0P,#"dD'8JF'&bB@ePG'9b)(* PB@aXH5"KBh4c)'&c)'%JFh4KG'PM)'pZC5"hD'PdD'PZ)'pZC5"cD@eeE'&dD@p Z)!ebG@iZ$3e9ER0`C@0TCQPPC#"`BA*KE@9dCA*c)#K*)(G[G@aN)'j[G#"MB@a X)(4SC@dJG@jNC@CTEQ9N+5"TFb"KEQpdD'9b)("[D@jd)%9bER0d)!eTFb"bD@G SG#"dEb"bC@0KE'`Z)%&Z)(9ZFh"PBfPQD@9N)("KFQ&YCA4PFL!UC'pPFbSJD'& fC5"K)(CKE(9P)(GSD@0S)'Pc)!eeFh9KE'aj)'%JC'9QBA9XG#"fB@aeC5iJ9fK KG#"TFb"ZC@9NC@3JD'9bC5"TFb"K)'ePBfKKEQPcE5"dEb"TEQ4TBf&dC5"dD'& d)!ecD@jMC5"dD'8JGA0PFL"ND@3JEQpd)'GTGQ8JB@jj)(CKE(9P)'C[FL"K)(" KFR4TBh9XBA)JF'&bB@ePG'9b,#"K)(0`C@0TCQPM)!eKFh0TCfjYC@jd)'pb)'0 [EA"eG'&dD@pZ)'Pc)(4[)'*P)("PFQC[FQePC#"dEb"RCA3JG'KP)'4PCQ&eE(3 JGQ&XG@8Z)%PZ)(4SC5!0Bf&cC5"[CL"K)(0TEQGXC5"KFh0TCfjYC@jd,#"dD'8 JCAKTFh4TEQFJC'9QBA9XG#"PH("bCA0cD@pZ)'C[FL"RC@jPFQPM)!e`BA*KE@9 dCA*c)'eTCfKd)'*P)(0eCQCTBfPPER3Z)%K[Gf9fCA)X)'j[G'KTEQFJCAKTFh4 c)(PPG#"TCL"cEfeP)'&XCfpbDA4SE@PM)!eMEfe`GA4KG'P[EL"TFb"ZC@9NC@3 Z$3e"Fb"K)(*PFh9XG#`J55"hEh9XC#"`FQp`Eh0P)(4[)#KdFRNJG'mT)'PYF(* [GQ8JG'KP)'0XBA*TG(NJEfBJ4%ma0b"KEQ3JDA4c)!ebBA4TEfjKE'8JG'KTFb" hBANk$3e%6c%h)#KcD'peE'3T)&Y%6c%bA3dJ)#!J)&C)4%`Y35"cD'peE'3JFh9 `F'pbG#"K)'ePBfKKEQPcE5"dEb"`BA*KE@9dCA*THQ8JB5"YEf4PE#iJ9'KP)(0 eF("[FR30)#!J)#"TEQ0XG@4PFb"`BA*KE@9dCA*c)(4SBA3JBA*P)'0[ER0dB@j dFb!SFh4KG'PM)("KFQ&YCA4PFR-T)'&ZC#"dD'&d)(CKFRN0)#!J)#"NGA*TEQF JFfPYG@aKG'P[EL!SC(PZB@eTBb"`BA*KE@9dCA*c+5iJ9'KP)(0eF("[FR3JB@a cEb"TEQ0XG@4PF`dJ)#!J)(9ZFh"PBfPQD@9N)("KFQ&YCA4PFR-X)'NZC5iJF'& bB@ePG'9bFb"hDA4S)'%JC'9QBA9XG#"fB@aeC5"dD'&d)'KKGQ8JG'm0)#!J)#" LC5"MEfe`GA4PC#"TEL"dD'8JBf&cC5"hD'9Z)'j[)(CKE(9P)'Pc)'9iF'aTBfP dE(NJCfPfC@iZ$3dJ)#!J)&*KG'P[EQ&XC6S0)#!J)#"3BA*KE@9dCA*THQ&dD@p Z)'9ZB@*XCA-JC@CQD@0TC@jd)'&ZC#"QE'9iD@*XC5"YEf4PE'PZCbiJ5A3JB@a cEb"QEh0dCA*c$5!J)#!JG'KP)'0bC@&dD@pZ)'pQ)("KFR3JE'PLFQ&bD@9c,L" ")(4jF'PMB@`JCAKKEA"XC5"[CL"K)(0dBA4TBb"`BA*KE@9dCA)JDA-0)#!J)#" K)'0[EA"[EQ9ZG#"fB@aeC5`JGfKTE'8JB5"dHA"TBf&X)'9iB@e`E'8JEfBJB5" NH@jKE@PM)("KFQ&YCA4PFL"TFb"dD'80)#!J)#"dC@e`CA*KG(9bC5i0)#!J)#" 8D'8JGQ&XG@8JEfBJB5"NH@jKE@PM)("KFQ&YCA4PFL"YBANJBfpYC5"PDA4SCA) JCR*[E5"dD'8JFfpXGA4TEfiJEfBJG'KP$5!J)#!JFhPcG'9Y)'pQ)'9aG@&dD@p ZFb"[FL"QFQpY)(0[E@8JB@aREh*TG'KYD@-JBfpYF(9dBA4TEfiX)'pb)'CbEfd JFfpYC3dJ)#!J)'9iG'9bEQ&X)'PZF(9d)(0dD@eeE'NZ$3e%6c%d1Je**fdJCf9 dG'PZCb"[EL"dD'Pc)'ePFh0KCf8JG'mJCfPfC5"KEQpdD'9b)'0[E@ePER3JB@* [GA3J4%ma0#iJ55GY)'j[G#"cEb"cGA*P)!eZEhFJDA3JGf&c)'%JCfp[C#"TC'9 K)(4[)(*PE@pfC5"dD'8JFh4KG'9YC@jd)#*&FA9KG'P[ER-JBf&Z)'*P)'9iF(* PFh0PC#!0C@PdD'9b)'9iF'aTBfPdE(NJEh)JD@e`E'PMDA4XH5)JCR*[E5"dD'8 J4%mZ)%NJGf&c)'&bCh9TEQFJG'KKG#"dD'Pc)'YTEQ3JEfBJ$A0dBA4PE@9ZG#" TFb"KEL"KFQ0SDA4PBh4eFQ&X)'&cF'9MG#`JFQ&dD'9b)(4SB@iJB5"bCA&eDA* PE@9ZG#"KFh"PBh3Z)%NJGfpeE'3J$@YPCA!JG'KTFb"cG'&dC@ePER3JD@iJG'K P)%42)(0TEQ0P)'Pd)'4PEQpdCA-JB5"NCA0MFQP`G'P[EL"cG(PXC5"dEb"LC5! 0Fh9`F'pbG'9N)(*KG'KPFL"dD'&Z)'%JFh"PBfPQD@-JC'9cD@GZ)'0SEfPMC5i 0$8CTEQ&XE(NX)%NJD'&fC5"cEfeP)(&eCA0dD@pZFb"KBQpeG#"dD'8JEQ9iG#" cG'9`FcS0,5"%Eb"jEh8JB@GbC@8J+'pb)'4[)(P[G5"dD'PZDb"TG#"TFb"hEh* dD#NJG'mJF(9d)'&XE#"dD'Pc)("bDACKG'8JC'PcBh9cFfP[EL!0EfiJG'KP)(* PCQaPBh4[FMm0,5"%B@iX)'eKH5"*)'G[)'pZ)(GTG'JJG'KP)'e[C'PQD@0KG'P [ER-JEfBJG'KP)%424#!b,M!JB@jN)("bEhCTC'8JB5"fCA*cD@pZ)!db,M%JG'& VD@jR)'PZG'mJB@0MEh9ZG#"KE'`JBfpYE@9ZG(-J55"RBA4SCA*PC$mJ9Q9bFfP [EL!b,M%JDA-JD@jdC@jNC@3JG'mJBQ8J$A4SC5"cG@*UC@0d)'pQ)'%JGQpdC5" hD'PdD'PZ)(4SC5"A4bi0)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b- M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)`d q4R*[E5"MD(*TFh4PEN"KEQ&XEfGj,Q0[E5"8D(8J6f0d)$)`)$)`1M)h)%e&9#! a16Nd$84KG'8k)%CbD5`J-M%J6f0d)$%j163J-6%k-c3k0$-J+c!i-$!04R*[E6S JBfKbDA0dC@j!B@jKE'pRH5jMEfdJ+%9bER0d)%0SFQPcG'9Z+3e8EcSJB@aKD@i ZGQ&MD'peH%"XC@FZC'8ZCA"QE#jMD#`JBfKbDA0dC@j!B@jKE'pRH5jMEfdX)'C TG(T!Bf&NC@jMC5jMEfd08h9LDQ9MG$SJ8Q8k)%424#!b,M!08h4KG(9c1L"5$3e "E'&TEL`J4'&Z,!d02NNJB@abC@&NH5"cC@jd)(P[G5"dD'Pc)'ePFh0KCf8JEfi J6@pZC'&j)$%h,#"LGA3JBA-J55"ND@4Z*h3JCf9d)'&ZH3dqFQ9KBh4TEfiJG'm JDA3X)%NRE5"`Eh0dD@jR)'Pd)'&RB@PZ,Jdq$9GPE'`X)%NJGf&c)'peG#"[CL" dD'8JEfCQD@0P)'C[FL"YEh0d)'pQ)(4SC5"hC@9V,Jd02PGSH5"ND@4Z*h3JH@p e)("eG#"jEh9b)'0[E@ePER4c)'pZ)(4SC5"bC@CXC@0dEh)r)%&XE#"dD'Pc)'4 TFf0eFh0TEfi02R0SEh9XC#"LC5"[CL"TER4PFQ9cG#"dEb"[G'KPFL"`C@p`E'8 X)'&d)'aPBA0d)(4SC5"QCAFJEfjPFb"dD'&d)'&XFQ9KC(N02QGKGQ8JFfpYC5" MEfeYC@jdFb"[EL"dD'8J4%p%)$)Z-#"KFb"hC@aX,Jdq$8&RFQ9PC#iJ55"bCA0 `EfjNC@3JEfjXH5"dEb"dD'8JFfeKE'`JBfPbBfaP)'*PBf&eFf8JG'KTFb"TFb" SEhFJG'KP)'4TFf0eFh0TEfi0Fh4KFR4PC#iJ5A3JF(*[BQ&LE(NJGf&c)'%JBQ& N)'PNC@%Z$3dq,LiZ$6j%6c%dBMS02N9bER0d*h-JEQ9h)(*PF'KbBA0PE@9ZG$S J)PC)4%`Y35"cD'peE'3JFh9`F'pbG#"dD'8JC'9cBh*TF(4TEfiJEfB02R"TC@0 PGfPcC5"NC@CTEQ9N)'*PD'&fD@pb)L"NEf9c)'j[G#"bC@&XE(NJBR*TEQFJBfa KFQPQD@0KG'P[EL"dEb"YC5iJ53dqG'KTEQXJG'KKG#"dD'8JF(*PGQP[GA-JFf9 ZG'9ZBf8JB@a[EQFJGfPdD#"TG(-JFQ&dD@pZB@aP)'&XFQ9KC(NJBfaPBA*XH3d qFh4KG'9N)(GSBA3J)Q0[EQ4TG'P[EQ&X)'*PD'&fD@pb)L"YC@&ZFbiJ55"hEh9 XC#"VC@9`)(4SDA-J4%mJBA-JDA-Z$3e8D'9bC5"TFb"K)'eKDQpb)'4TCQCPFQ9 ZBf8JBQ9dGf9PEL"dD'8JBh9bFQ9ZG#"QEh*YG@aKG'P[EL"[CL"dD'Pc)%42)'& ZC#!0E@PZC6SJG'KP)'PZCQpbE@&dD@pZ)'&LEh9d)(GSCA*P)'&ZC#"SEhFJFh9 MD#"QG@jMG'P[EQ&XDA4j)(G[G@aN)'*P)(9cC@3Z$94SC5"MGA*bC@jd)'C[FQe eE'&dD@pZ)#KhDA4SEh9d)(4SC5"bBA4TEfjKE'8T)'4[CA-JEQpd)("bEhCTC'8 JB5"cBfp`C3eQEh)JG'KP)'0[EQ4TG'P[EQ&X)'*PD'&fD@pb)(0`C@0TCQPMBA4 TEfiX)'C[FL"TER0dB@jMC5"dD'9bC5"TFb"ZE`eTEQ4TBf&dD@pZ)(GSCA4SCA) JDA3JDA-JFh9QCQPMD@9ZG#"dEb"cGA"`Eh*d)'%JFh4KG'PM)'0[EQ4TG'P[EL` JEh)JGfKPG'KPFJeNH@jKE@PM)'0[EQ4TG'P[EL"KFQ8JEQ9PC'9N,L"2EL"dD'8 JEh4SCA)JD'&ZC#`JD@BJGf8JG'&XDb"KBQpeG#"`D@9MCAGTFf80C'9QD@jPC#" LC@KKGQP[FL`JGf8JC'mJEQpd)(9`)'CbEfjd)'&cFh9YC5"dD'&d)'0[EQ4TG'P [EQ&X)(0dBA4PE@9ZG(-JBA*P$A4SC5"cEfaeG'P[EL"dEb"dD'8JF(*[BQaPE5` JBR9d)'PQ)(4SCANJBA*P,#"hC5"KE(0[)'PYF'aj)(4SBA3JG'KP)'0[EQ4TG'P [EJeYGA0d)'*P)'4jEQ&YD@-Z$6i02LiZ,Jdq4%ma0MS02NNJB@acEb"NEfiRG#" cC@8JB@jj)'PYF'aPE@9ZG'&dD@pZ)'&cF'9MG#"TEL"dD'Pc)%42)'&c)'Pd)'P c)'0eFR*PER4XH3dqFh4KG'9N,L"8D'8JG'9bE5!LFA9KER4TG(NL)(9cC@3JEfj XH5"bC@CPFR-JG'mJFfpYC5"KEQ&XEfFJGf&fC@C[FQdJG'KKG!dqBfpeE'3JBQ8 JFQ9KC#"[FL"hFQPdG'9Z)'PZFfPNC5"cEfeP)'&ZB@a[Cb"MEfe`EfjPER3Z)%j [G'KTEQFJE@pbC5iJ6Qm02R9`F'9bBf&cC5"498&19%P8@5"TFb"eFf9N)(GSD@0 S)'eTCfKd)'PZC'PMBA4P)(0[E@8JEQ9h)'YPHAG[FQ3JEh)JFfpYC3dqEQ9h)'p LDQ9MG#"TEL"@5%4-,8%Z)%Pd)'Pc)(9`)(4[)(4SC5"XB@jRG@&RC5"NCA0TCfi JG'mJC'9MD@4P)'PQ)(4SC5"dCA*Y$6iLFA9KER4TG(NL)'jPC@4c)'%JEQ9h)'p LDQ9MG#"[FL"ZEh3Z$6i02NNJB@GbC@8JGfPdD#"%B@iJG'KKG#"dD'Pc)'YTEQ3 JEfBJD@jQEh*YBA4TEfiJ+QeKH5"LC5SJB@acEb"KGQ&TE'&LE'802R4SFQpeCfJ JG'KP)(4PFQeTEQ&XFb!S5d0-,dY@6#"MEfjZC@0dD@pZ)("[D@jdFbNZ)%NJG'K TEQXJD'phCACPFL"TG#"YD@GSG!dqBQ8JGA0PCR9X)(4[)("bEhCTC'8JG'KP)(9 cCA)JGfPdD#"KEQpdD'9b)'PZG'9bCQ&MC5"YC@0SB@jTFfdJGfKTBfJJC'pPF`d qEQpd)'4PF'9ZC#"[EL",DA*MD'K[CQBRFb"cC@eKER4TBh-X)'9cF'9MD@&XE(N JCQpb)(0TCfjKE#eQE'ph)'GbBA"S$6jNCA0MFQP`G'P[ER-J+(GSD@0S)&C)4%` Y35"TFb"cGA"`Eh0PC#"dEb"cGA"`Eh*d)'&c)(GPE'`X)(0PC5"%6c%b+5iJ33d qE@pNC@`JEfBJB5"MEfjdFQpXE'9N)(0[GA*MC5"eFfPZCb"dD'Pc)'0KF'&LD@a TG(NJDA-JD@jNC@9N)'e[FQ8JB@*cG(*KBh302R4SB@iJB@iJCA&eDACKE'9ZG#" MDA*MG@Pd)'aPGQ9X)'4PFf0bDA"dD@pZ)(9cD@jR)'pZE(NJG'9bE@PZB@ac,Jd q$8NJG'KTEQXJG'KP)'PYF'pbG'&ZG#"`EfPZG#"SCA*P)'Pc)(4SBA3JDA3J+Qe KH5"LC5SX)'*eG#"TG#"TFb"ZEh3JCh9KFQ&ZG'9PC#i03A-JB@iJCAKKEA"XC5` JG'KP)'*KFf8YC@eTG(4PFL"MGA*bC@jd)'PZ)'%JG(*KER0TFh4[FL"TFb"ZEh3 JBACKD@aKBQaP$@&d)'%JG'9bE@PZB@`Z$6j%6c%h1Jdq4'&Z)(0KHA-k)#*dD'8 JFQ&dD@pZB@`JGA0TEQFJG'9YF'9bBA4eFQ8JBA-JB@iJCAKKEA"XC5"[CL"NH@j KE@PM)(CKFQPKBQaP$6jTFb"TEQ0[FR*PBh3JB@acEb!Y)(4PEA"PFQ&dGA*P)(G [G@aN)'jPC@3JG'mJBQ8JB@iJG@jVEQphEL"dEb"LC5"cEfafC@302QC[FL"TEL" dD'8JFhPcG'9Y)'pQ)'9aG@&dD@pZFbiL$6i02NNJB@GbC@8JG'KKG#"dD'9bC5" YBANJBQ8JFfpYC5"MEfjQGA0TEfiJD'9bC5iJ3A-JB5"NH@jKE@PM)("KFQ&YCA4 PFL"YBAN02RCKFRNJC(9bD@jR)(0TEA9XBA4TEfiX)'Pd)'eTCfKd)'*P)'9TG'K PFL"MEfe`GA4PC#"dD(*[G@GS)(4SC5"cEfaeG'P[EL"[CJdqG'KP)(0jFh4PE5" [CL"PFA9KG'P[ER-X)'pb)'Pd)'eTCfKd)'*P)'pZE(NJBfpYF(9dC@3JF(*[Bf9 NGA*KE'aj)#KT,Q8Z$6jZEh3JBfpZFfPNCA*PC#"KFb"KEL"eEQYZEhGZ+5iJ5@i JG'KP)'C[FQePFL"MBA0P,#"dD'8JG'9YF'9bBA4eFQ8JE@PRD(302Q0[E@8JCR* [E5"K)(4SCA*YB@`JBfpYF'pZC@jd)#KdHA"TBf&XE(NJG'KbEh9RD#"K)(&eB@j dDA4j)'&c)%42-6BJBA0VF`dqCQpb+5iJ5@iJG'KP)'aKG(4PFL"MBA0P,#"TG#" YD@GSG#"MEfeP)'CbEfdJFfpYC5"TER"eG#"cG'PYG@aT)(4SBA302Q4PFf0bD@* PFb"SEhFJG'KP)(4PEA"PFQ&dGA*P)'9fEfafCA-JD@iJG'PYC5`JEh)JBQ9MBA9 cC5!UFh9MBf9cFfPfC5S02R0TEA9XBA4TEfiJBA*P)'*PD@jR)(*PFA9TFQ9N)'C [FL"dD'8JFf&YC5"NCA0MFQP`G'P[EL!SBA-JGfPdD#"dD'8J8e"*3d802Lj848e 3)'0[ER4bEf`JFh4KG'9YC@jd+5iJ5@iJG'KTFb"MBA0P,#"dD'8JF'&bB@ePG'9 b)(*PB@aXH5"KBh4c)'&c)'%02R0dBA4TBb"[EQ8JGfKTG'KTEL"[EQ8JFfPYG@a KG'P[EL"bG@iZ$6i055"hBA-JG'KP)'pZC5"hD'mJEh*TCfPZB@aXH5"`FQp`Eh0 PC#"dD'8JEQpdD@pZ)'pQ)'4jEQ&YD@-JF'&bB@ePG'9bFbiJ3A30G'KKG#"dD@e P)%NJD'&N)'%JGQ9bH5"cF'9MD@CTBb"KEQ3JFQ9cG(*TBh4PC#"TC'9K)'pQ)(G SBA3JG'KTFb"cD'peE'30Fh9`F'pbG$SJCAK`FQ9cFfP[ER-J+'pb)'CeEQ0dD@p ZFbNJGfK[Ff8JGQ&XG@9c)'&bC5!UD@jNCA"PEQ4PER3U)'pQ)(4SC3ecEfaeG'P [EL"[CL"dD'8JFhPcG'9Y)'pQ)%4"4A-Z)&0eBfJJCAK`FQ9cFfP[ER-JGfpeE'3 JG'KPEL"[EQaj)'4PF'9ZC#"[EL!0BfpZFh4KER4c)'&ZC#"dD'8JD@jNCA"PEQ4 PER3JGQ&bD@&LE'8JEfBJG'KP)'&ZB@ajFfPc,#"P,QFZ)(4TE@8Z)%PZ)'pdD'9 b$AG[FQ4c,#"TG#"hEh9XC#"LC5"`Eh0cD@*XC5"dEb"SBACP)'%JG'PYC5"NCA" PEQ4PER3JFQ9cDA0dEh)JBRNJFfPYF'aj$A0`C@0TCRPTEQFJG'KP)(4TE@8JC'9 `C@jNC@jMH5"KFb"dD'8JFQ9cDA0dB@jMC5"fB@aeC5iJ55"ND@3JFR9XC5"[GA3 JG'KTEQGc$@aTDf8JGQpXG'&RC5"MEfjdFQpXE'9N)(*PFfPcG'pbFb`JBQ9MBA9 cC5"dD'9Z)(4SC5"NDA0dD@jMG'P[EL"LCA4hC@9Z$@%JF'&bB@ePG'9b)'&ZC#" [G'KPFL"MEfjdFQpXE'PZCb"fB@aeCA-JCf9d)'*XGA*bC@3J+'Pc)(4SC5"MEfj dFQpXE'PZC`efEfadB@GP)'pQ)'%JGQpXG'&RC5"MEfjdFQpXE'9N)(C[E(4KCf8 JFfpeFQ0P)'%JF'&bB@ePG'9b2bNZ)%PZ)'ej)'pbD@GTEQ&X$A0dBA4PE@9ZG#! SGfKTBfJJDA-JFQ9`C@&dC@3JD'9bC5NJ$5!J)#!J)#!J9NK%6#e")'eeFh3JFh9 `F'pbG#"K)'ePBfKKEQPcE5"dEb"`BA*KE@9dCA*THQ8JB5"YEf4PE#i0)#!J)#! J)#"8D'8JFh9`F'pbG#"YGA0d)'PZBfaeC'8JF'&bB@ePG'9bFb"dD'&d)'&bC5" MEfjcG'&ZG(-Z$5!J)#!J)#!J5A3JFfK[G@aN)'PZBfaeC'8JF'&bB@ePG'9bFb" dD'&d)(CKFRNJBA-JB5"QG@jMG'P[EL"[CJdJ)#!J)#!J)(4SC5"TEQ4PF'9ZC'9 ZG#"fBA*TB@*XC5"[CL"KEL"KEQ&XHA0TFbi055"KE(0[)'eKC'8JB5"ME'9KFL" NDA0dD@jMG'P[EL"LCA4hC@9Z)(4SC5"TEA"[FR4KEQ0P)'pQ)(4SC5"dGfmJF'& bG(-Z)%PQ)!eTG#"TFb"ZEh3JF'pcFfPLE'8JG'mJF'&bB@ePG'9bDATP)'%JE@p NC@`X)(GP)'eeFh3JGh*TG'8JFf9`BA*KG'8J$@&bBfKTG'9MG(9bCA-0CQpb)'9 KBfJJFQ9cDA0dB@jMC5"fB@aeC5`JGfKTBfJJDA-JEf*fD@peFfaj)'KTCfKXH5" eEQ4PFfPbB@*XC5iJ6fiJG'KP)'pdD'9b$@KKEQ3X)'PQ)(GP)'4[ELGd)(0eF(" [FR3JC(PZB@eTBb"`BA*KE@9dCA*c)(4SC5"hBANJ55"NDA0MGA0cC@3JG'KPE5` JG'KPFQ80DA-JEQmJBQPR)'a[Fh-JBA-JG'KTFb"ZC@9N)'Pc)'j[G#"KFb"eBQP aG@PdEh9c,#"KEQ3JDA3JBf&Z)'*P)(0KG'PcCQPPC!eLH5"hFQPdD@jR)'&ZEh4 SCA)JBA*MD'PdC@0dGA*P,L"*)'&Y)'j[G#"bC@&XE(NJD(9ZCb"eF#"[EL"dD'8 JC(PZB@eTB`e`BA*KE@9dCA*c)(4SC5"hBANJ55"`FQp`Eh0PC#"dD'9Y,#"KEQ3 J55"hEh9XC#"ZEh3JD'&fC5"K)("bEf*XC@dJG'mJE'9KGQ80G'KPE5"[GA3Z$3e 8D'8JBh9bFQ9ZG#"fCA*cD@pZ)'pQ)(4SDA-J4%mJD'&c)'GPEQ9bB@aTHQ9N)(4 SC5"ZEh4TEfiJEfBJB5"NH@jKE@PM)!e`BA*KE@9dCA)X)'&ZC#"dD'Pc)(0PC@e c)(4[)'eP)(4[)'*P)(4SC5"MBA9cC5"[CL"dD'8JC'PcBh9cFfP[ELiJ3A-J55" cB@PN$@&LEhCP,#"dD'8JC'PcG'PZBh4TEfiJBQ9dGf9PEL"MEfjdFQpXE'PZCb" hBACPCQpbEA-JB@jN)("KFQ&YCA4PFR-JCf9d)!eLE(9bFQ9N,!eKEQ3JFfpYC5" `C@p`E'8JC'pZ*h3JBfpZFfPNCA)JBfpZG(*[E'aTEQFJGf&fC@C[FQec)'&c)(" KFQ&YCA4PFR-Z)%eKH@*P$AGP)(0SEh9XC#"NFQp`)(4SC5"ZEh4TEfiJEfBJC(P ZB@eTBb"`BA*KE@9dCA*c)'&XE(4[Cf9dD'9b,L"*)'4[ELGd)(4SD@jV$AGP)(G TE'`JE'p[Ff8JB@jjG'KTEQFZ$3dq9@jcF'9MD@CTC@3JF'&bB@ePG'9bFb!S55" hEh9XC#"ZEh3JBf&XE#"dD'9Y)(9ZC'9QD@jPC#NJDA-JB@j[G'KPFL"`EfPZG!d q4A*ZFh3JDA-JFQPRD(3JG'mJFQ9MB@aX,L""EL"eER0`C@0TCQPPC#"`BA*KE@9 dCA)J+Q4[CA-U)'KKGQ8JB5"fB@aeC3dqGfKTBfJJDA-JGA0eB@aXH5"K)'4PCQ& eE(3JGQ&XG@8Z)&GSBA3JDA-JEQ9PC'9N)'KPFQ8JDA-JB5"YC@0SB@jTFfdJG'm 02QPZC'PMBA4P)(4SBA3JFfPZBf8JG'KP)(9cCA)JC'PN)'j[G#"RDACP)'&ZH5" fB@aeC5"QEh)JB5"`BA*dD@0eE'&b$6j`BA*KE@9dCA)X)'%JFh"PBfPQD@-JBA0 cD@GZE@9ZG#"[FL"MEfe`GA4KG'P[EL"TFb"dEb"LC5"`CA*QEh*YC@3JG'mJCf9 d$6jdD'8JC'9QBA9XG#"fB@aeC5iJ5@iJG'KP)'0KFf8JEfBJB5"cD@jRE'8JBA0 cD@GZE@9ZG#`JG'KP)'9iDA0dD@jR)'4PCQ&eE(302Q9iF(*PFh0TEfiJCQpb)'G PEQ9bD@-JF'&bB@ePG'9bFb"YD@GSG#"LC5"cG@CQD@0TC@jd,L")EhGPGQ9b,#" ZEh4SD@jR$6jPH'PcG(-JH@9d)'PQ)(0[E@8JB@aREh*TG'KYD@-JBfpYF(9dBA4 TEfiJDA-JEQ9PC'9N,Jdq$8&XB@PZ,#"jEh9b)(0dBA4PE@9ZG#"dD'&d)'&Z)(9 ZFh"PBfPQD@9N)("KFQ&YCA4PFL"NEf9c)'KKGQ8JB5"fB@aeC5"TF`ebC@aKG'9 N)(4[)&C)4%`Z)%PQ)(P[G5"REb"LB@0V)(4[)%eKFQXJ@RG[E'PZFfYT*h-JE@9 cFf&RC5`JD'8JBfaPBA*XH5!0Fh4KG'9c)'%JBf&cC5"hD'9bC5"dD'8J9NK%6#" YC@0SB@jTFfdJEfBJG'KP)'4PCQ&eE(3JD@jTG'PKE#"fB@aeC5"TFb"ZEh3J$A0 eCQCTBfPPER3JGfPdD'peG#"KC'4TG'P[EQ&X)(0PE@&ZG'PMFbiJ4Qpb)(4SDA- JFQ9KFfpZ,#"TG#"TFb"TEA"[FR4KER30G'mJBf&`G(9bC5"SDA-JD@jdC@jd)'P Z)%42-6FX)'&c)%NJG(*j)(4[)'4[)'*PE'ph,L""G#"dD'8JE'9KFh3X)(4SC5! LD5jP,L)0F'&bG#"cD'peE'3JBQ8JFQ9YEhCPC#i0$6j"Fb"K)(*PFh9XG#`J55" hEh9XC#"`FQp`Eh0P)(4[)#KdFRNJG'mT)'PYF(*[GQ8JG'KP)'0XBA*TG(NJEfB J4%ma0b"KEQ302QPdFb"bBA4TEfjKE'8JG'KTFb"hBANk$6i02N42-6FJ+(0SEh9 XC#NJ@d42-6*G$6iJ)#!J)&C)4%`Y35"cD'peE'3JFh9`F'pbG#"K)'ePBfKKEQP cE5"dEb"`BA*KE@9dCA*THQ8JB5"YEf4PE#iJ9'KP)(0eF("[FR302L!J)#!JD@j ME(9NCA-JF'&bB@ePG'9bFb"dD'&d)'&bC5"MEfjcG'&ZG(-J+(0dBA4TBb"`BA* KE@9dCA*c+5"KEQ3JG'KKG#"fBA*j$6iJ)#!J)'4eFQPZCb"cD@eeE'&dD@pZ)#K NH@jKE@PM)("KFQ&YCA4PFR-T,L"8D'8JFh9`F'pbG#"KE(0[)'PZBfaeC'9c$6i J)#!J)(9ZFh"PBfPQD@9N)("KFQ&YCA4PFR-X)'NZC5iJF'&bB@ePG'9bFb"hDA4 S)'%JC'9QBA9XG#"fB@aeC5"dD'&d)'KKGQ8JG'm02L!J)#!JBQ8JBfpYF(9dC@3 JD@iJG'KP)'0KFf8JGfKPEL"ZEb"fB@aeC5"TFb"PH("XD@0TG'aj)'GTGQ9Z,Jd q$5!J)#!J)#!J,LiZ)%Pd)'eeFh3JBQ8JF'pcFfPLE'8JG'mJC'PcG'PZCh9TFfJ JF'&bB@ePG'9bFb"dD'&d)'PZG'9ZG'P[EQ&XE(N0)#!J)#!J)#"SBACP)'*PC@i JE'9QG#"eER0`C@0TCQPPC#"QFQpY)("KFQ&YCA4PFR-JD'&fD@jR)(4SC@Pb)'4 PCQ&eE(3J$5!J)#!J)#!JD@jTG'PKE#"fB@aeC5i0$6iJ)#!J)&*KG'P[EQ&XC6S 02L!J)#!J8'&bB@ePG'9bDATKG'P[EL"PEQ&LE'9c)'9QCQPMD@9ZG#"KEQ3JCQa PH'PLE'8JE@pNC@aTEQFZ)%Pd)'&XFfmJCQpcG'9bF`dq)#!J)#"dD'8JBh*PBA4 TEfiJEfBJF'&bG#"XD@*bBA*TCA-Z)%%JG(P`D@0KE#"PH'&YF'aP)'pQ)'%JFh4 KG'PM)("KFQ&YCA4PFL!0DA-02L!J)#!JB5"MEfe`EfjPER3JGQ&XG@8X)(GSD@a P)'%JG(P`D@0KE#"PH'&YF'aP)'pQ)'%JC(PZB@eTBb"`BA*KE@9dCA)JDA-JG'K P$6iJ)#!J)(4PEA"PFQ&dGA*P,Jdq)#!J)#"8D'8JGQ&XG@8JEfBJB5"NH@jKE@P M)("KFQ&YCA4PFL"YBANJBfpYC5"PDA4SCA)JCR*[E5"dD'8JFfpXGA4TEfiJEfB JG'KP$6iJ)#!J)(0jFh4PE5"[CL"PFA9KG'P[ER-JEh)JCR*[E5"cEfeP)'&XCfp bDA4SE@PM)'0[EA"eG'&dD@pZ,#"[FL"QFQpY)(0[E@802L!J)#!JCAKdCA*ZB@` JD@j`GA3JFh4TEA9XD5i02Jdq4%ma0$S02NNRE5"RCA4dD@jR)'pZ)(4SDA-JE@9 cFf&RC5"dEb"RDACP)'&ZEh4SCA)JBfpYE@9ZG#"KBQpeG#"%6c%d,L"**fdJEQp d)(0[$6jcGA*P)'j[Gb"TG#"hBA-JB5"REfpN)'PNC@%JG'mJFQ9YEhCP)(4SC5" cG'&dC@ePER3J)N9aG@&dD@pZFb"MB@iJBQ802Q9iF(*PFh0PC#"PDA4SCA)JCAK `E'PMDA4XH5"[FL"TEA"XD@0TG'aj)L"QFQpY)(4SC5"%6biJ55"hBA-JBA*RG@P ZCb"dD'&d$6jdD'Pc)'YTEQ3JEfBJFh4KG'9YC@jd)'Pc)'&Z)'&bBfKTG'9MG(9 bB@`JBA0`C@0d,#"bBA4SCA)JG'KKEL"K$6jbCA&eDA*PE@9ZG#"KFh"PBh3Z)%N JGfpeE'3JDf9PF#"dD'Pc)(0dBA4PE@9ZG#"TEL"dD'8J4%mJFfPZBf8JDA3JC'9 ZEh4PF`dqB5"NCA0MFQP`G'P[EL"cG(PXC5"dEb"LC5"cGA"`Eh*dC@3JFQ&dD'9 b)(4SB@iJB5"cF'9MD@CTBb"NCA0TCfiJBfK[D@0P,Jdq$8NJG'KTEQXJG'KKG#" cEfePG'KTEQFJB@*[GA3JCAK`E'PMDA3JB@jN)'PYF'aTBfPd)'9aG@&dD@pZFb" cD'peE'3JBQ8JFf&TC#`0BR9d)(9ZFQ9XBA4PC#"dEb"K)'4PFf0bDA"dD@pZ)(0 dH@aP,L"*EL"YH5"[F'PZD@pZ)(4SC5"NCA0MFQP`G'P[EL"cG(PXC3eTFb"KEQp dD'9b)'PcFh9P,#"KEQ3JGf8JFfK[G@aN)'j[G#"YDAJJG'KP)(4hEbiJ55"hEh9 XC#"`FQp`Eh0P)(4[)'0bC@&dC5!0$842-64K$9C)4%`Y35"YGA0d)(0eF("[FR3 JG'KP)'4PFf0bDA"dD@pZ)'pQ)'0[ER4TER9[GA-JG'PYC5"LC@KKGQP[FL"LEh4 S)'*j$@9iF'aTBfPd)'&ZC#"LH5"TEA"XD@0TG#"PFA9KG'P[ER-Z$3e5BA4TEfj KE'803@adD'peCfJJE@&ZH5"PH'&YF'aPFb"[CL"KEQ&XEfFJBQ9SBACTEh)JFh" PBfPQD@0KG'P[EL"MB@iJBQ8JCQpbEA9XBA4PC#"KF`ePH("XD@0TG#"PFA9KG'P [ER-X)(4SCA*P)'&bC5"MBA0PFb"hD'9bC5"dD'Pc)'Pc)'j[G#"`Eh0cD@*XC5` JCQpb)'PZFh4KEQ0P$A*[Eh4c)'pQ)(4bB@jcBf9ZC'9ZG'&X)'9aG@&dD@pZFbi 0)#!J)#!J)#!0$6j'D@jKE'aj,#"*)'KKGQ8JFfpYC5"aG@9cG'P[ER-JB@*[GA3 JG'KP)'jPH(3JFh4PF(-k$6iY)%4[)(P[G5"KCh*PC5!SEh)JC'mJH@pe)(4SD@j V)'Pd)'Pc)(G[FR4S+5"dEb"`GA3JB@aX)(4SDA-JF(*TGQ&dC3dqC'PcBh9cFfP [EL"[EL"dD'8JFQ9QE'9MG'pb2`d03@*cEfaeG'9XH5i0$94SB@jVFbi04A*ZFh3 0)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b- M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)`dq4R*[E5"QDA4k3'0KC'9 ZBf8ZBfpY)&4eC5"2Bh3J-M8J-6Nk-c3J6898)$%j1630@#e"GA4SC@jdD@0KG'P [ELeABA*ZD@jR1L"MC(-b-$Fb,N0KC'9ZBf8Z3dp01L")Eh0d)'a[Bf&XD'pcG#" ND@4Z*h3JGA0P)%K&6%mJ$5!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!JF(*[G'p MEf`0@#e"GA4SC@jdD@0KG'P[ELeABA*ZD@jR1L"MC(-b-$Fb,N0KC'9ZBf8Z3dp 01L"QDA4k)'phEQ9N)("bEf0PFh-JC'pTEQFJ,@*c$94[1L"KE'&TELjfB@0SEh9 i3'aPCbjNC5jPF'CX,Q0S)#K"E'&TEL"@B@0SEh9i)%934N`Y6%9(,d-cD5N03f- k)'CTG(T!Bf4c-M!h-Lj$B@4PEQ0P,N0265`JDQ9KELeYD@0SC@`ZBQ9bCf9!Bfj c,Q0ZCA3ZCR)X$5!J)#!J)#!JBfKbDA0dC@j!B@jKE'pRH5jMEfd08h9LDQ9MG$S J8Q8k)%424!e%BA4P1L"AC@3X)$)f)%pMG#!a16Nd)$%`1M-j1M)i)#d`0c!`$8C bEfdk)%4KEQPPE#"'DA4k8'&dFQPMDb!mCQPdHN"MB@4PEQ0P,Q0[E6i08h4KG(9 c1L"5$3e*EL"YCA0cB@GP)$aKB@3d-MJd0$!h-$)a-$!dC$-b1%"E-6)i,M%h1#i a15ic-9dq,#"hFQpdC6S0I#!J$A`J)%NJG'KTEQXJDA3JDA-JG'PYC5"ZEhFJG'm JF(*[Bf9PC#"dEb"dD'8JBQ&XE'pdG'PZCb"[CL"%6d3JGQ9bFfP[EL!b,M!J+'p b$A`J)$)Z-5`JD@BJBfpYE@9ZG(-JBA*P)(4KDf9Z)'PZG'mJB@0MEh9ZG#NZ)%P Z)'ej)("bCACTEh9c)'ePFh0KCf8J+%pMG#iJ-6FT$A`J)%NJBA0VC@3JH@pe)(P [GA)JEh"TEQP[EL"KBQpeG#"dD'8JGf&j)(4[)("bEf0PC@3X)'*eG#"*)'4TC#" ZEh3JCf9d)'&ZH3em)#"KER0hCA)Z)%NJGfpeE'3JBAC[D@3JG'mJCfmJD@jdEb" dD'8JFf&YC5"VD@jN)'pQ)("bEf*XC@ec)'ej)'PZDA4TBA4TGQ8JD@i0I#!J3A9 RGA0d)'KKFb"LFQpeCfKd)'pZ,#"LGA3J55"cD'&XE#"KERPhBANJD@jTG'PKG'8 JG'KP)(C[G'PZCb"`FQpMCA0c$A`J)'ejFf9XCL"TCL"*)'4[ELGd)'GPG#"KERN JEQ9hFb"QFQpY)(P[G5"eER4TE#"1EhCPE@*PFL!aFh3Z$A`J)!d03@aKD@iX$3e *)'GKGQ8JEANJBfpYE@9ZG(-X)(GSD@0S)(GPFQ8JC'9LBA4PC#"TEL"dD'8JCQp XE'phD@jR)'4TFf0eFh0TEfi0B5"hD'PXC5"LB@0V,L!J5@BJH@pe)'KKGQ8JG'P YC5"dEb"eF'4KG'8J-Li`)#dq)$)Z-5`JF'aPBA0P)'4[,!edD'&d)(*PCQaPBh3 JG'KP)(*PFh9XG#"[CL"dD'pcC5"MEfeYC@jdFbiJ)%NJB@dJBh9bFQ9ZG'aj)(G [FQYTEQFJEfiJ$@ePCA4TEQFJB5"NC@&NE'PZC5`JFfmJF(*[BQ&LE(NJGfpZ*h3 JBQ8JB@*XC5"dEb"RCA3JG'mJDA3JBA-JCQ&cG#!0BA-JH@pe)'0[G@aN)'pb)'e TCfKd)'aTDf8Z)#")EhGPGQ9b,#"*)(0dD@aX)(GKER3JG'mJFf9P)'Pd)'*PCQp bC3eTG#"TFb"`Eh0dC@3Z$3eADA4S)(*PCf&bC#"dEb"cEfeP)'pQ)(4SC5"MEfj dC@jd,#"*)(0dD@aX)'0[ER4PEQ3JG'KKG#"MBA"KBQPXDA4TCA-0G'KKG#"KFQ8 JC'9QD@jPC#"hDA4SD@iJ9NK%6#"NEb"ZEh3JEQ9PC#"dEb"LC5"cG'&dC@3JBA- JEf*UC@0dDACPF`dSBA-JG'KPFQ8JBA*P)'&`F'&bC@jdE(NJFfp[)'eKERNJ9NK %6#"PH("PFR4c)'e[EQPdEh*TEQFJB@jN)'PZGQpXGQ9N$@PZ)(4SC5"`FQpMCA0 c)(4SDA-JFfK[G@aN)'CeFR4SCA)JBQ8JG@jZC@0PFh0KFRNT,L!J4%ma0Q)JFQ9 aG@PbCA-0BQ9dG'9b)(*KG'P[EQ&XDATKG'P[EL"LC@0KGA0P)(4SC5"MGA*bC@j d)'pZC5"NEf9c)'j[G#"UGA0dD@Cj)'Pd,!e[FL"TG#"cD'peE'3JBQ8JGh*TG(4 PEL"cG@0S)(4SBA3JFA9KER4TG(NJD@jQEh*YBA4TEfiJFfK[G@aN)'*P)!e[BR4 KD@jPC#"QFQpY)(4SC5"dCA*YD@jKE(-Z)#"+GA0dD@CTBf&dD@pZ)'C[FL!LBfp eF'aTEQFL)'eeFh3JD'&fC3eXC@GTG'PYBA4P)(*PBA0[ER-JB@jN,fpb)'jPC@4 c,L!J4A0[G'9bD@-JFQ&dD@pZB@aPFb"dD'&d)'4[)'j[G#!0BA"`E(NJG'mJ58- JB@jN,fpb)(0jFh4PE5"cD@eeE'&dD@pZ)'&bC5"ZEh3JB@0MCA"dB@*XC5"KFb" cG@0S,L!J5@B0C@jRD@jPCA*c)(GKER3JG'mJC'mJG'KKG#"dHA"P)'pQ)(0TEA9 XBA4TEfiX)%eKG'*KBL"[FL"0BA4SC@eKG'PMB3ehD@aX)("bEf*KBQaj)'&XGf& jFb"LC5"dD'8JG'p[E#"[CL"MD'pTBf8Z$3eADA4S)(*PCf&bC#"dEb"dD'8JC'P cBh9cFfP[EL"bC@GKFQ4TEQFJG'KP)%424#`JDA3JDA-JCQPZC5"hDA4S)'eP$A4 [)("eG#"TG#"eF#"KFb"XEfjR)'&c)'Pd)'Pc)'PZ)'0SFQpZEfa[CfPMB@`JEh* NCA)JB@jN)'j[G'KTEQF0DA-JE@PcFfPZCbiJ)%&XFfmX)'%JFh9YE@&bH5"[CL" dD'8JBfKKEQGPFb"[CL"dD'8JC'PcBh9cFfP[EL"cD'peE'30F(*[BQ&LE(NJBQ8 JF'pcG'9N)'&d)(4SC5"dEh!J+(4SDA-JGf&c)'9cF'9MD@&XE(NJEQpd)'0XC@& b)(4[)'eP$@&c)'eeBfJJEfBJDA3JGf&c)%4KELGc)'p`D@jTEfiX)%9bER0d*h- JEh"TEQP[EL`J3@aKD@jc*h-JEh"ZD@pZ,!ePG'-T,Jd0I#!J3@acEb`J55"dD'P ZDb"TG#"TFb"dD@eP)(4[)'G[)'pZ)(GTG'JJG'KP)%424#"5BA4TEfjKE'8Z)&* TBfKKFQ3JB@jN$A`J)'ejFf9XCL"SBACP)'&XFQ9KC(NJGfpbDf9N)'%JE'pd)'p Z)'Pd)'&ZC#"hC5"hEh9XC#"`FQp`Eh0P)(P[G5"K)'jPG`em)#"fCA*cD@pZ)(4 [)("bCA0PER3JG'mJG'KP)(GSEfaP)&G(,Jem)#!0$@*dGb`JGfKj)(GKFfiRG#" bD@0SBA*N)'PZGQpXGQ9N)'pZ)(4SCA0P)'4TFf0eFh0TEfjc)(*PCf&bC'PZCb" dD'8JC'pN2`d0,5eNB@i0$A"c1L"T)'KKGQ9Z*h3JC'9MD@4PC#"hD'9Z)'&ZC#" TCL"T)(GTE'`JFQ9`E(NJG'mJG'KP)#*KER0hCA*c)(4[$@ej)(&eCA0dD@pZFb) JF'pcG#`JBR9d)'NJC'pZ*h3JB@GbC@8JGfPdD#"K)(0TCfjQD@0KER3JF'pbG'P [EL`JB@jN$@%JE'pd)(GKFb"XC@Cd)(9ZBA0hCA*PC#i0)b-M)b-M)b-M)b-M)b- M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b-M)b- M)b-M)b-M)b-M)b-M)b-M)`eReJ!!!3!!!!&1!!!!6J!!!&SJE@PcFfPZCbNJB@j N)(GTG'JJEQ9h)%42Fb"TEQ0XG4K5C5e%6d3J-Li`)#K`FQPfBA4P+5jLB@XJ!J! !!&4&!!"849K8889%-3!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!+V95jS!!*Zh!!! "U'GbC@8JG'KKG#"dD'8J4%p%)(0SEh9XC#"LC5"KFb"MEfjMDA0P)'&c)("[Fh0 TBQaP,L"2EL"dD'8JEh4SCA)JD'&ZC#`JDA3JB@acEb"cD'peE'3JBQ8JFf9XCLe MEfjdB@PZC@3JGfPdD#"YD@jTEA9Y)(*PCQ9bC@jMCA-JG'm!!!!U!!N'6@pZB@0 [!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!"!!'!!3!!!!8!GS !5!!8rr3!!2rr!!!!!!!!QlF!!!%!!!!"6J!!!%i!!!"D!4"TT#2q!!!!(!"D!!* &4Nj8!!!!'N9838)!!!!Q49&&4!!!!$)$krrr!!!!!!!!!!!$krrr!!!!,J!!!!! $krrr!!!!0J!!!!"UJ3: --========================_19399118==_ Content-Type: text/plain; charset="us-ascii" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Alain Vachoux Swiss Federal Institute of Technology (EPFL) Dept. of Electrical Engineering Integrated Systems Center (C3i) e-mail: alain.vachoux@leg.de.epfl.ch EL-Ecublens Phone: (+41) 21 693 69 84 CH-1015 Lausanne, Switzerland Fax: (+41) 21 693 46 63 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --========================_19399118==_-- From 1076-1-request@sicmail.epfl.ch Thu Oct 27 10:47:59 1994 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Thu, 27 Oct 94 10:47:56 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Thu, 27 Oct 94 10:47:48 -0400 Received: from potomac.wash.inmet.com by sicmail.epfl.ch with SMTP (PP) id <22033-0@sicmail.epfl.ch>; Thu, 27 Oct 1994 15:16:40 +0100 Received: by potomac.wash.inmet.com (4.1/SMI-4.1) id AA05986; Thu, 27 Oct 94 10:16:12 EDT Date: Thu, 27 Oct 94 10:16:12 EDT From: dlb@potomac.wash.inmet.com (David Barton) Message-Id: <9410271416.AA05986@potomac.wash.inmet.com> To: jean-michel.berge@cns.cnet.fr Cc: 1076-1@epfl.ch In-Reply-To: (jean-michel.berge@cns.cnet.fr) Subject: Re: ZZZZ Jean Michel writes: As far as I know Z, B, or other formal languages, they do not allow to describe a given algorithm but the specification of algorithms (Alex or Dave, correct me if I am wrong). Formal languages are ``sold'' on their ability to specify an algorithm without constraining its actual implementation; however, this should not be taken to mean that they cannot completely specify the implementation if this is desired. An algorithm can be specified to any desired level of detail in Z, B, VDM, the Larch shared language, or any other formal notation. The question here is, ``why bother?''. Such a description would be considerably more turgid, and more impenetrable, than the same algorithm written in C, Ada, Haskell, or (for that matter) VHDL. Now, there are formal language systems in which specifications and implementations are given in the same language. These tend to ``bridge the gap'' between the predicate and lambda calculi by allowing functional descriptions of sets and set theory. This gives most (not all) of the power of the full predicate calculus without requiring the ``domain switch'' of other methods. Eric Hehner is the best known proponent of this methodology. However, all this is digression, and far from the point; those interested further, contact me directly and I will try to direct you appropriately. On the other hand, at the validation phase, we could probably use Z in another way: describing properties of our language and proving them. If we could find volunteers for that, it would be interesting to ask them to define the "invariants" (properties) of our language first... One of my main concern about this approach is that, since VHDL-A is an extension of VHDL, I am not sure it will not be necessary to formalize VHDL as a whole to have results... Good point. There is work on a formal semantics for VHDL going on at various places; Phil Wilsey at the University of Cincinatti has a contract to produce such a formal sematantics at present. ORA of Itheca, NY has a partial formal semantics that they use in their formal specification and proof tool. The Aerospace Corporation also did a partial formal semantics a couple of years ago that they used in a translation to their proof tool. Some work has been done in this area in France as well; Dominique Borrione is well known here, among others. So it is not like we would be starting from complete scratch. However, having looked at the problem to an extent, extending this to cover the analog kernel seems to me (without time to do a full evaluation) an extremely complex task. Emphasis on extremely. In that case, Express (as proposed by Hillary) is certainly a good candidate since the work has already (partially?) been done for the "digital" part. But do we have volunteers?.... Having worked in both EXPRESS and Z, I offer the following evaluation that is purely personal and not endorsed by anyone other than little old me (although Hilary will jump all over me if I say something wrong, I am sure). First: EXPRESS is excellent at modeling the information manipulated by and codified in a given language, including VHDL-A. An information model has the benefit if giving some precision to a lot of concepts that are at best talked about somewhat vaguely. There is a reason the EIA is using EXPRESS for many standards, including EDIF; for an interchange format, it is close to ideal. Additionally, EXPRESS is suitable for modeling the static semantics of the language (what is normally informally called the ``semantic checks'' that a compiler might make, including type checking and the like). Here the match is a little less ideal, since most of the type checking and other relationships will be defined in an EXPRESS model as functions and procedures, which are algorithms like any other algorithm. It is at least as good (for example) as a YACC specification of the front-end compiler. However, in the crucial parts of the specification you are specifying an algorithm, as in most other programming languages. This disadvantage is often outweighed by the advantage of being able to work directly with the information model, which can be a mighty advantage (working with concepts set out in the information model directly). However, EXPRESS is not suitable (in my opinion) for specifying the dynamic semantics of a language. The problem here is modeling the concept of transitions between and the relationships among those transitions between states. This is not impossible by any means (EXPRESS is, after all, Turing equivalent); however, it usually means modeling the program state as an entity and specifying the meaning of different language constructs as a relationship between the ``before'' and ``after'' state of the program with respect to each language construct. This is not impossible (again); however, keeping the information entities associated with the state separate from those associated with the language constructs and using functions to specify those relationships is pretty difficult. There are formalisms designed specifically for defining dynamic semantics, and using one of those is probably more suitable. One more thing: doing models is a complex task, and time consuming. I doubt the ability of the committee (in spite of the excellent work done thus far) to generate EXPRESS models as a volunteer activity. Someone would probably have to fund such modeling. Even properly reviewing the models takes time (a fact that is constantly underestimated in modeling projects and budgets). The review might be done on a volunteer basis, but I strongly urge anyone entering on such a task to avoid underestimating the effort involved. All the above is my personal opinion only. Dave Barton dlb@wash.inmet.com From 1076-1-request@sicmail.epfl.ch Fri Oct 28 17:23:24 1994 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Fri, 28 Oct 94 17:23:21 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Fri, 28 Oct 94 17:23:18 -0400 Received: from psi.com by sicmail.epfl.ch with SMTP (PP) id <15878-0@sicmail.epfl.ch>; Fri, 28 Oct 1994 21:40:55 +0100 Received: from analogy.com (analogy.analogy.com) by psi.com (4.1/2.1-PSI/PSINet) id AA07421; Fri, 28 Oct 94 16:17:34 EDT Received: from miller.analogy.com ([149.117.72.253]) by analogy.com (4.1/Shared_Spool_1.3) id AA20293; Fri, 28 Oct 94 13:07:48 PDT Received: from satyr.analogy.com by miller.analogy.com (4.1/SMI-3.2) id AA24432; Fri, 28 Oct 94 13:18:00 PDT Received: by satyr.analogy.com (5.0/SMI-SVR4) id AA00658; Fri, 28 Oct 1994 13:17:00 +0800 Date: Fri, 28 Oct 1994 13:17:00 +0800 From: christen@analogy.com (Ernst Christen) Message-Id: <9410282017.AA00658@satyr.analogy.com> To: 1076-1@epfl.ch Subject: LAT meeting location Content-Length: 1630 All, As previously announced, the next meeting of the 1076.1 Language Architecture Team will be held at the Compass site in Columbia MD, on the following dates: Wednesday, November 16 Friday, November 18 Saturday, November 19 On Thursday, November 17, we will have our 1076.1 WG meeting at the Ritz Carlton Hotel in Tysons Corner, VA. Compass Design Automation is located at 5457 Twin Knolls Road Columbia, MD 21045 To get to this place: from Washington DC: take I-95 North toward Baltimore from Baltimore-Washington airport take 195 out of the airport take I-95 South toward Washington then, for both: exit to 175 West toward Columbia take 175 to Thunderhill Road (past Dobbin Rd and Tamar Drive) turn left at light, then make first right turn onto Twin Knolls Road the entrance to Compass is the last right turn (right after the Hilton) Accommodation: - If you also attend VIUF and stay at or near the Ritz Carlton Hotel in Tysons Corner you will have a commute of about 1 hour to Columbia. - Otherwise, you can stay at the Columbia Hilton, which is right next to Compass (the second to last right turn on Twin Knolls Road). To call the Hilton, use either (800) 235-0653 or (410) 997-1060. To make reservations, mention Compass for a discount. To get to Compass from the hotel, exit through the side entrance (double doors) and walk straight to the building next door. It's about 50 yards. As I said in my previous message, I'd like to get an idea who will attend this meeting, for organizational reasons. So, please drop me an email if you plan to attend. Thanks. Ernst Christen chair LAT From 1076-1-request@sicmail.epfl.ch Tue Nov 1 05:38:10 1994 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Tue, 1 Nov 94 05:37:59 -0500 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Tue, 1 Nov 94 05:37:56 -0500 Received: from inet-tsb.toshiba.co.jp by sicmail.epfl.ch with SMTP (PP) id <15638-0@sicmail.epfl.ch>; Tue, 1 Nov 1994 11:21:58 +0100 Received: from tis2.tis.toshiba.co.jp (tis2) by inet-tsb.toshiba.co.jp (5.67+1.6W/2.8Wb) id AA13551; Tue, 1 Nov 94 19:21:18 JST Received: from tis4.tis.toshiba.co.jp (tis4) by tis2.tis.toshiba.co.jp (5.67+1.6W/6.4J.6-R05) id AA21041; Tue, 1 Nov 94 19:21:42 JST Received: from eecisa by tis4.tis.toshiba.co.jp (5.52/6.4J.6-R06) id AA00178; Tue, 1 Nov 94 19:29:49 JST Received: from roku.eec.toshiba.co.jp (eecjsf) by eecisa.eec.toshiba.co.jp (4.1/6.4J.6-R1) id AA08182; Tue, 1 Nov 94 19:18:17 JST Return-Path: Received: by roku.eec.toshiba.co.jp (8.6.9+2.4Wb3/3.3W-roku_Master) with ESMTP id TAA20217; Tue, 1 Nov 1994 19:16:56 +0900 From: "VHDL analog mail by (CA1)H.Sasaki 94.1.18" Message-Id: <199411011016.TAA20217@roku.eec.toshiba.co.jp> Date: Tue, 1 Nov 1994 19:20:26 +0900 To: 1076-1@epfl.ch Subject: (VHDL-A) MSK Encoder by HDL-A Cc: jvl-analog@nttica.ntt.jp, jvlwg@nttica.ntt.jp Dear VHDL-A people, As I have wrote a my first "executable" VHDL-A (HDL-A) description, I will send this to the reflector. I don't adhere syntax detail, but rather I would like to confirm the usefulness of A/D-mixed behavioral description. If you have an idea on more elegant modeling for my description, could you tell me? Mr. Oliver, could you tell me what is the best procedure to paticipate in evaluation activity? I would like to join you. I have a plan to write more VHDL-A descriptions such as digital modulations/ digital servo technology. I will sent all to this reflector( or other more appropriate reflector you want). Best regards, ----------------------------------------------------------- -- Hisashi Sasaki, Ph.D. Specialist -- -- BIPOLAR ANALOG DESIGN AUTOMATION, TOSHIBA CORPORATION -- -- 580-1, HORIKAWA-CHO, SAIWAI-KU, KAWASAKI 210, JAPAN -- -- PHONE: +81-44-548-2604 FAX: +81-44-548-8970 -- -- E-MAIL: 000092040542@tg-mail.toshiba.co.jp (office) -- -- PXI04522@niftyserve.or.jp (home) -- ----------------------------------------------------------- --------------------------- MSK.HDLA ----------------------------------- -- TITLE: MSK (Minimum Shift Keying) -- AUTHOR: Hisashi Sasaki, TOSHIBA -- e-mail: sasaki@roku.eec.toshiba.co.jp -- 000092040542@tg-mail.toshiba.co.jp -- DATE: 13.10.94 -- LASTUPDATE: 31.10.94 -- LANGUAGEVERSION: HDL-A -- CODESTATE: INVALID [VALID] -- HISTORY: -- Initial 13.10.94 [INVALID] -- HDL-A 28.10.94 [INVALID] -- 31.10.94 [VALID] for tran -- -- DESCRIPTION: I expalin by example of omega=7*pi/2, -- -- ak: new symbol, ak_old: previous symbol -- -- phi, local start phase of osc., is given by: -- -- (note: new local start phase is indenendent from -- the value of new symbol "ak". ) -- -- | old phi=0 | old phi=pi -- -----+------------+-------------- -- old ak=1 | 0.0 | pi A*cos(4*pi*t/T+phi) -- old ak=0 | pi | 0.0 A*cos(3*pi*t/T+phi) -- -- this table shows that -- when (ak_old=1 AND phi=0.0) OR (ak_old=0 AND phi=pi), -- phi := 0 -- when (ak_old=0 AND phi=0.0) OR (ak_old=1 AND phi=pi), -- phi := pi -- -- SCHEMATIC: -- msk.cir -- -- CODE: -- HDL-A Version v1.1.3a for sun4c -- STIMULI: -- given in msk.cir -- -- EXPECTED_RESULTS: -- OK: -- Text, Formulas, Curves : Format PROPSAL EPS -- RESULTS: -- SIMULATION_ENGINE: ESIM V2.1.2d -- DATE: 31.10.94 -- RESULT_STATE: INVALID [VALID] -- ... -- PROBLEM_LOG: -- Description.... -- (OPEN [SOLVED]) ENTITY msk IS GENERIC( omega1, -- carrier angular freq. of center T, -- time interval between two symbols A: REAL -- amplitude of modulated output ); -- PORT(ak: IN BIT); -- input PIN(s:ELECTRICAL); -- output END ENTITY msk; ARCHITECTURE msk1 OF msk IS SIGNAL ak : BIT; -- squence of symbols VARIABLE ak_old: INTEGER; -- 0/1 to show old "ak" VARIABLE phi: REAL; -- phase determined by previous symbol VARIABLE old_phi: REAL; VARIABLE omega2: REAL; -- driving angular freq. -- ( maybe, "t" is reserved by system... ) VARIABLE local_start_time: REAL; -- for osc. BEGIN PROCESS -- generator of seq of symbols BEGIN ak <= '0', '1' AFTER 100ns, '0' AFTER 100ns, '1' AFTER 100ns, '1' AFTER 100ns, '0' AFTER 100ns, '1' AFTER 100ns, '0' AFTER 100ns, '0' AFTER 100ns, '1' AFTER 100ns, '0' AFTER 100ns; L1: LOOP WAIT FOR 100ns; ak <= not ak; END LOOP; END PROCESS; RELATION PROCEDURAL FOR INIT => s.v %= A; phi := 0.0; old_phi := 0.0; local_start_time := 0.0; IF ak='1' THEN omega2 := omega1+(pi/T/2.0); ak_old := 1; ELSE omega2 := omega1-(pi/T/2.0); ak_old := 0; END IF; PROCEDURAL FOR DC => -- no operation -- s.v %= 0.0; PROCEDURAL FOR TRANSIENT => IF event(ak) AND ak='1' THEN omega2 := omega1+(pi/T/2.0); IF (ak_old=1 AND phi=0.0) OR (ak_old=0 AND phi=pi) THEN phi := 0.0; ELSE -- phi := pi; END IF; ak_old := 1; -- save for next local_start_time := current_time; END IF; IF event(ak) AND ak='0' THEN omega2 := omega1-(pi/T/2.0); IF (ak_old=1 AND phi=0.0) OR (ak_old=0 AND phi=pi) THEN phi := 0.0; ELSE -- phi := pi; END IF; ak_old := 0; local_start_time := current_time; END IF; s.v %= A*cos( omega2*(current_time - local_start_time) + phi ); END RELATION; END ARCHITECTURE msk1; ------------------------ MSK.cir ------------------------------------------ * Simple MSK (Minimum Shift Keying) #com H. Sasaki, 28.10.1994, for HDL-A #endcom .HDLALIB /local/eecrip/usr3/sasaki/eldo/v4.3.3/examples/hdla/sasaki-lib .model msk(msk1) macro lang=hdla y1 msk(msk1) + generic: omega1=10.99557429e7 T=100.0n A=5.0 ! omega1==(7/2)*pi/T + pin: 1 r1 1 0 10K .tran 1n 1.0u .plot tran v(1) .plot tran SG(y1->ak) .option noascii .end ------------------ end of mail --------------------- From 1076-1-request@sicmail.epfl.ch Wed Nov 2 01:17:26 1994 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Wed, 2 Nov 94 01:17:13 -0500 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Wed, 2 Nov 94 01:17:10 -0500 Received: from inet-tsb.toshiba.co.jp by sicmail.epfl.ch with SMTP (PP) id <03305-0@sicmail.epfl.ch>; Wed, 2 Nov 1994 06:56:55 +0100 Received: from tis2.tis.toshiba.co.jp (tis2) by inet-tsb.toshiba.co.jp (5.67+1.6W/2.8Wb) id AA28613; Wed, 2 Nov 94 14:56:06 JST Received: from tis4.tis.toshiba.co.jp (tis4) by tis2.tis.toshiba.co.jp (5.67+1.6W/6.4J.6-R05) id AA05211; Wed, 2 Nov 94 14:56:29 JST Received: from eecisa by tis4.tis.toshiba.co.jp (5.52/6.4J.6-R06) id AA08438; Wed, 2 Nov 94 15:04:40 JST Received: from roku.eec.toshiba.co.jp (eecjsf) by eecisa.eec.toshiba.co.jp (4.1/6.4J.6-R1) id AA02277; Wed, 2 Nov 94 14:52:59 JST Return-Path: Received: by roku.eec.toshiba.co.jp (8.6.9+2.4Wb3/3.3W-roku_Master) with ESMTP id OAA21680; Wed, 2 Nov 1994 14:51:43 +0900 From: "VHDL analog mail by (CA1)H.Sasaki 94.1.18" Message-Id: <199411020551.OAA21680@roku.eec.toshiba.co.jp> Date: Wed, 2 Nov 1994 14:55:13 +0900 To: 1076-1@epfl.ch Subject: (VHDL-A) Sliding Mode Control by HDL-A Cc: jvlwg@nttica.ntt.jp Dear all, Here is another HDL-A description for "Sliding Mode Control", which is one of most promising robust control. I feel direct description of equation solving by simulation-engine is not so good. For simplicity, I would like to write only two parts: PROCEDURAL INIT => ... EQUATION (yy) FOR TRANSIENT => ... and wouldn't write other parts which implement solution. (Please see below for details.) System must be determined only by its equations and its initial states, not by determined by solution process for denotational view. Best regards, ----------------------------------------------------------- -- Hisashi Sasaki, Ph.D. Specialist -- -- BIPOLAR ANALOG DESIGN AUTOMATION, TOSHIBA CORPORATION -- -- 580-1, HORIKAWA-CHO, SAIWAI-KU, KAWASAKI 210, JAPAN -- -- PHONE: +81-44-548-2604 FAX: +81-44-548-8970 -- -- E-MAIL: 000092040542@tg-mail.toshiba.co.jp (office) -- -- PXI04522@niftyserve.or.jp (home) -- ----------------------------------------------------------- -------------------------- smc.hdla ------------------------------- -- TITLE: An elementary example for "Sliding Mode Control" -- AUTHOR: Hisashi Sasaki, -- Bipolar Analog Design Automation, TOSHIBA Corp. -- DATE: 12.10.94 -- LASTUPDATE: 02.11.94 -- LANGUAGEVERSION: HDL-A v1.1.3a for sun4c -- CODESTATE: INVALID [VALID] -- HISTORY: -- Initial 12.10.94 [INVALID] -- 31.10.94 [INVALID] for HDL-A -- 01.11.94 [VALID] for HDL-A -- DESCRIPTION: -- An introductionary example found in the book: -- Kenzo Nomami, Kouki Den -- Sliding Mode Control (in japanese) -- page 3-5 -- (ISBN 4-339-03157-7) -- -- System Equations: -- ddt(x) == y -- ddt(y) == 2*y - x - x*S(x,y) -- where S(x,y) is the switching as -- S(x,y) := +4 when x*(0.5*x+y) > 0 -- -4 when x*(0.5*x+y) < 0 -- -- (note) arcitecture "a2" and "a3" are pasted together, -- and yielding "a1", sliding mode system. -- -- SCHEMATIC: none "smc.cir" -- CODE: HDL-A v1.1.3a -- STIMULI: Edlo -- -- EXPECTED_RESULTS: -- not yet: Text, Formulas, Curves : Format PROPSAL EPS -- RESULTS: -- SIMULATION_ENGINE: VESIM V2.1.2d -- DATE: 02.11.94 -- RESULT_STATE: INVALID [VALID] -- ... -- PROBLEM_LOG: -- Description.... -- (OPEN [SOLVED]) -- ENTITY vss IS GENERIC (a, b, inita, initb : ANALOG); PIN (x, y : NKN ); END ENTITY vss; ARCHITECTURE a1 OF vss IS -- Sliding Control: convergence STATE sy, ssy, yy, c : ANALOG; BEGIN RELATION PROCEDURAL FOR INIT => a := 1.0; b := -2.0; inita := 1.0; -- initial for yy initb := 1.0; -- initial for ddt(yy) PROCEDURAL FOR DC => sy := initb; IF yy*(0.5*yy + sy) > 0.0 THEN c := 5.0; ELSE c := -3.0; END IF; ssy := (x.a - b*sy - c*inita)/a; EQUATION (yy) FOR DC => yy == inita; PROCEDURAL FOR AC, TRANSIENT => sy := ddt(yy); ssy := ddt(sy); y.a %= yy; IF yy*(0.5*yy + sy) > 0.0 THEN c := 5.0; ELSE c := -3.0; END IF; EQUATION (yy) FOR TRANSIENT, AC => x.a == a*ssy + b*sy + c*yy; END RELATION; END ARCHITECTURE a1; ARCHITECTURE a2 OF vss IS -- periodically diverse STATE sy, ssy, yy, c : ANALOG; BEGIN RELATION PROCEDURAL FOR INIT => a := 1.0; b := -2.0; inita := 1.0; -- initial for yy initb := 1.0; -- initial for ddt(yy) PROCEDURAL FOR DC => sy := initb; c := 5.0; ssy := (x.a - b*sy - c*inita)/a; EQUATION (yy) FOR DC => yy == inita; PROCEDURAL FOR AC, TRANSIENT => sy := ddt(yy); ssy := ddt(sy); y.a %= yy; c := 5.0; EQUATION (yy) FOR TRANSIENT, AC => x.a == a*ssy + b*sy + c*yy; END RELATION; END ARCHITECTURE a2; ARCHITECTURE a3 OF vss IS -- exponentially diverse STATE sy, ssy, yy, c : ANALOG; BEGIN RELATION PROCEDURAL FOR INIT => a := 1.0; b := -2.0; inita := 1.0; -- initial for yy initb := 1.0; -- initial for ddt(yy) PROCEDURAL FOR DC => sy := initb; c := -3.0; ssy := (x.a - b*sy - c*inita)/a; EQUATION (yy) FOR DC => yy == inita; PROCEDURAL FOR AC, TRANSIENT => sy := ddt(yy); ssy := ddt(sy); y.a %= yy; c := -3.0; EQUATION (yy) FOR TRANSIENT, AC => x.a == a*ssy + b*sy + c*yy; END RELATION; END ARCHITECTURE a3; ------------------- smc.cir ---------------------- * An Elementary Sliding Mode Control (SMC) #com H. Sasaki, TOSHIBA, 1994/11/02. #endcom .HDLALIB /local/eecrip/usr3/sasaki/eldo/v4.3.3/examples/hdla/sasaki-lib .model vss(a1) macro lang=hdla .model vss(a2) macro lang=hdla .model vss(a3) macro lang=hdla y1 vss(a1) ! Sliding Mode Control + generic: a=1.0 b=-2.0 inita=1.0 initb=1.0 + pin: 1 2 y2 vss(a2) ! periodically diverse + generic: a=1.0 b=-2.0 inita=1.0 initb=1.0 + pin: 3 4 y3 vss(a3) ! exponentially diverse + generic: a=1.0 b=-2.0 inita=1.0 initb=1.0 + pin: 5 6 r1 1 0 10M r2 2 0 10M r3 3 0 10M r4 4 0 10M r5 5 0 10M r6 6 0 10M .tran 1m 10 .plot tran v(y1->yy) v(y1->sy) .plot tran v(y2->yy) v(y2->sy) .plot tran v(y3->yy) v(y3->sy) .plot tran v(2) v(4) v(6) .option noascii .end ------------------ end of mail --------------------- From 1076-1-request@sicmail.epfl.ch Thu Nov 3 18:32:52 1994 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Thu, 3 Nov 94 18:32:45 -0500 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Thu, 3 Nov 94 18:32:41 -0500 Received: from gatekeeper.ray.com by sicmail.epfl.ch with SMTP (PP) id <09694-0@sicmail.epfl.ch>; Fri, 4 Nov 1994 00:04:48 +0100 Received: from localhost (mailer@localhost) by gatekeeper.ray.com (8.6.4/8.6.5) id SAA11837 for <1076-1@epfl.ch>; Thu, 3 Nov 1994 18:02:57 -0500 Received: from sud2.ed.ray.com by gatekeeper.ray.com; Thu Nov 3 18:02:03 1994 Received: from SUD2.ED.RAY.COM by SUD2.ED.RAY.COM (PMDF V4.2-10 #4335) id <01HJ1UIXNCTS8X3MO7@SUD2.ED.RAY.COM>; Thu, 3 Nov 1994 17:59:45 EST Date: Thu, 03 Nov 1994 17:59:45 -0500 (EST) From: "Joe Gwinn, 508-440-3330" Subject: Comments on comments on DOD 2.0 -- Quasi-static parameters To: 1076-1@epfl.ch Message-Id: <01HJ1UIXW7428X3MO7@SUD2.ED.RAY.COM> X-Envelope-To: 1076-1@epfl.ch X-Vms-To: IN%"1076-1@epfl.ch" X-Vms-Cc: GWINN Mime-Version: 1.0 Content-Transfer-Encoding: 7BIT I have been following the net traffic on DOD 2.0, and have a comment to offer: DO17. It seems to me that there are three kinds of parameters, not just two, and that failing to include the third kind is the root cause of the debate about allowing dynamic parameters. The three are: static (constant), quasi-static (change slowly enough that they can be handled as if they are constant without undue error), and dynamic (must be handled as if it were a variable). There was a long dabate on the net about the need for quasi- static parameters some time ago; we should resurrect it, as it appears to have been forgotten. Anyway, static and quasi-static parameters would be handled by the simulation engine as if they were constant. This would allow for instance the temperature to be stepped or swept slowly during the simulation of a circuit. A dynamic parameter would be handled exactly like a variable in simulation. This would allow the handling of a voltage-variable capacitor in a parametric amplifier circuit, or a capacitance microphone. Charge *is* conserved in such circuits, although we may chose to model the device such that energy is not conserved. The sole difference between dynamic and quasi-static (and static) parameters is their rate of change. If the parameter's rate of change is small enough that the error committed by treating the paramater as a constant is acceptable to the user, then the constant is deemed quasi-static. If the parameter is in fact constant, it is deemed static. Otherwise, it's dynamic. This is a very common approach in continuous system simulation, and has been for decades. Joe Gwinn From 1076-1-request@sicmail.epfl.ch Fri Nov 4 12:21:05 1994 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Fri, 4 Nov 94 12:20:58 -0500 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Fri, 4 Nov 94 12:20:54 -0500 X400-Received: by mta sicmail.epfl.ch in /PRMD=switch/ADMD=arCom/C=ch/; Relayed; Fri, 4 Nov 1994 17:48:22 +0100 Date: Fri, 4 Nov 1994 17:48:22 +0100 X400-Originator: 1076-1-request@sicmail.epfl.ch X400-Recipients: non-disclosure:; X400-Mts-Identifier: [/PRMD=switch/ADMD=arCom/C=ch/;sicmail.ep.039:04.10.94.16.48.22] Priority: Non-Urgent Dl-Expansion-History: 1076-1@epfl.ch ; Fri, 4 Nov 1994 17:48:22 +0100; From: "Jean-michel.Berge" Message-Id: To: analog_reflector <1076-1@epfl.ch> Subject: VHDL-A meeting Agenda (Last version) X-Mailer: Mail*Link SMTP/MS 3.0.0 IEEE Computer Society Design Automation Standards Committee Meetings in Conjunction with the Fall 1994 VHDL International Users' Forum The Ritz Carlton Hotel Tysons Corner, Virginia Thursday, 17 November 8:00 AM-5:00 PM VHDL Analog Extensions Working Group--P1076.1 Contact: Jean-Michel Berge, Chair +33 76 76 43 35 CNS-CCI +33 76 90 34 43 Chemin Du Vieux Ch#016#ne-BP 98 berge@cns.cnet.fr MEYLAN CEDEX F-38243 FRANCE This meeting will take place in the Plaza room. Here is the last (final?) version of the agenda of our next meeting. You may notice that several questions of the open discussion have already been asked at the Grenoble meeting and solutions have been proposed. It seems anyway interesting to revisit them in order to collect the ideas of the whole working group. o Status of the work (Jean-Michel Berge, 30 min + Questions) o Dod Rationale (Alain, 1 hour + Questions) o Architecture Definition Document (first draft): (Ernst, 2 hrs + Questions) o Validation task status (?) o Documentation task status (Peter, 15 min + Questions) o Open discussion: - call for volunteers especially (but not only) analog designers for validation - general schedule too agressive or too conservative? - communication Mechanisms short or long working group meetings during DASC? What is the purpose of such meetings? From 1076-1-request@sicmail.epfl.ch Wed Nov 9 07:44:28 1994 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Wed, 9 Nov 94 07:44:19 -0500 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Wed, 9 Nov 94 07:44:15 -0500 Received: from gatekeeper.bosch.de by sicmail.epfl.ch with SMTP (PP) id <11731-0@sicmail.epfl.ch>; Wed, 9 Nov 1994 13:22:30 +0100 Received: by gatekeeper.bosch.de (5.65/rg-150294); id AA11850; Wed, 9 Nov 94 12:13:12 +0100 Received: by si4640.si.bosch.de (5.65/fma-120691); id AA28788; Wed, 9 Nov 1994 12:15:54 GMT Received: by sh.bosch.de (5.65/DEC-Ultrix/4.3) id AA13583; Wed, 9 Nov 1994 12:13:51 GMT Received: from miranda by fli.sh.bosch.de (5.0/SMI-SVR4-DNI-8.0) id AA19186; Wed, 9 Nov 1994 12:11:45 --100 Received: by miranda (5.0/SMI-SVR4) id AA00429; Wed, 9 Nov 1994 12:11:42 --100 Date: Wed, 9 Nov 1994 12:11:42 --100 From: moser@fli.sh.bosch.de (Eduard Moser) Message-Id: <9411091111.AA00429@miranda> To: 1076-1@epfl.ch Cc: moser@fli.sh.bosch.de Subject: Variables (? val) Reply-To: moser Content-Length: 2511 during writing models for the validation suite I came to the following question: Does there exist a VARIABLE (type analog) for communication within the equational set statement. And what is the meaning of a variable within another timestep. The example below can be written without variables, but on more complex models, it is often useful and practical to use variables (values in MAST), which values has only meaning within this particular timestep. Further, I would like to whom may I send examples for syntactical and semantical check. (I had problems with the definition of characteristic tables). Eduard -- Electrical Motor - electrical part -- using characteristic tables: -- Ubuer: brush voltage in relation to rotor angle velocity -- the function tablin is somewhere else defined and gives -- linear interpolations a characteristic table and a value. PACKAGE data_emotel_pkg IS CONSTANT Ubuer_tabx : VectorType := (7.0, 0.0, 0.5, 1.25, 2.5, 5.0, 12.5 , 20.0); CONSTANT Ubuer_taby : VectorType := (7.0, 0.0, 0.3, 0.4, 0.55, 0.95, 1.3, 1.7); FUNCTION Ubuer_func (fp1 : analog) return analog; END PACKAGE; PACKAGE BODY data_emotel_pkg IS FUNCTION Ubuer (fp1 : analog) return analog IS BEGIN return tablin(Ubuer_taby,Ubuer_tabx,fp1); END; END data_emotel_pkg; USE work.data_emotel_pkg.all ENTITY emotel is COUPLING ( USteller : IN analog; -- external voltage Mot_X : IN analog; -- motor position (angle) Mot_w : IN analog; -- motor angle velocity ext_Mi : OUT analog; -- internal momentum ext_IMot : OUT analog); -- current GENERIC ( Ra : float := 1.5; -- rotor resistens La : float := 0.002; -- rotor induction c : float) := 0.035; -- relation between voltage and momentum END emotel; ARCHITECTURE ascet OF emotel IS QUANTITY Mi : analog; QUANTITY IMot : analog; QUANTITY i : analog; BEGIN EQUATION SET VARIABLE Uind : analog; -- local variable syntax ???? VARIABLE diff_i : analog; -- local variable syntax ???? PROCEDURAL FOR transient => Mi := c * i; -- internal momentum Uind := c * Mot_w; -- induced voltage diff_i := (USteller - (Ra * i) - Uind - Ubuer(i)) / La; ext_Mi = Mi; -- internal momentum ext_IMot = i; -- current EQUATION (i) FOR transient => ddt(i) == diff_i; END EQUATION; END EQUATION SET; END ARCHITECTURE; From 1076-1-request@sicmail.epfl.ch Wed Nov 9 07:45:34 1994 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Wed, 9 Nov 94 07:45:31 -0500 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Wed, 9 Nov 94 07:45:26 -0500 Received: from mail.Germany.EU.net by sicmail.epfl.ch with SMTP (PP) id <11891-0@sicmail.epfl.ch>; Wed, 9 Nov 1994 13:26:12 +0100 From: domino Received: by mail.Germany.EU.net with UUCP (8.6.5:29/EUnetD-2.5.1.a) via EUnet id NAA22145; Wed, 9 Nov 1994 13:27:45 +0100 Original-Received: from tom.anacad.de anacad.de by anacad.de (4.1/SMC-5.11) Pp-Warning: Illegal Received field on preceding line Received: by tom.anacad.de (5.0/SMI-SVR4) id AA22421; Wed, 9 Nov 1994 13:11:02 --100 Date: Wed, 9 Nov 1994 13:11:02 --100 Message-Id: <9411091211.AA22421@tom.anacad.de> To: peterl@compass-da.com Cc: 1076-1@epfl.ch In-Reply-To: <199410251746.NAA02013@adhara.columbia.compass-da.com> (message from Peter Liebmann on Tue, 25 Oct 1994 13:46:42 -0400) Subject: Re: LAT minutes, Grenoble, Fr Content-Length: 2088 c'est bon, j'ai retrouve la dernieres version des minutes, as tu reflechi a ces deux acttions item: > - a lot of people complain about the restrictions in procedurals: > - to list unknowns in equational part > - to previously define quantities used on right hand side. > > - Can we remove restrictions - ACTION ITEM ... explore it. > Also can we reduce number of restrictions (do we lose > ease and power of expressions). > > Proposition 1: > Number of equations created by procedural part is static > => number of equation_statements is static > > PROPOSITION 1A Serge's comment about minutes (paraphrased): > From the LESs and comments during the last few days, we > have proposition 1 + no implicit equation into the PROCEDURAL part. > > PROPOSITION 2: > number of equations created by procedural part plus the number of > equation_statements is static > > PROPOSITION 3: > consolidate all statements into the equational section with functions > > PROPOSITION 4: > merge equation_statements and equations in the procedural sections > ACTION ITEM: > stuff deleted > Each person will take the above 4 propositions and generate a list of > pluses and minuses for each. > > Domino +--------------------------+------------------------------------------+ | |||| DON'T | Dominique RODRIGUEZ domino@anacad.de | | (00) HAVE A BART| ANACAD - HDL Group (VHDL & HDL-A) | | /-------\/ MAN | Tel : +49 731 954 54 17 | | / | || +------------------------------------------+ | * ||----|| | La Terre n'appartient pas a l'homme, | | ^^ ^^ | mais l'homme appartient a la Terre. | | SIMPSON'S COW | Seattle (chef indien) | +--------------------------+------------------------------------------+ From 1076-1-request@sicmail.epfl.ch Wed Nov 9 10:52:40 1994 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Wed, 9 Nov 94 10:52:37 -0500 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Wed, 9 Nov 94 10:52:33 -0500 Received: from mail.Germany.EU.net by sicmail.epfl.ch with SMTP (PP) id <22159-0@sicmail.epfl.ch>; Wed, 9 Nov 1994 16:39:04 +0100 From: domino Received: by mail.Germany.EU.net with UUCP (8.6.5:29/EUnetD-2.5.1.a) via EUnet id QAA11666; Wed, 9 Nov 1994 16:40:38 +0100 Original-Received: from tom.anacad.de anacad.de by anacad.de (4.1/SMC-5.11) Pp-Warning: Illegal Received field on preceding line Received: by tom.anacad.de (5.0/SMI-SVR4) id AA24194; Wed, 9 Nov 1994 16:36:00 --100 Date: Wed, 9 Nov 1994 16:36:00 --100 Message-Id: <9411091536.AA24194@tom.anacad.de> To: 1076-1@epfl.ch In-Reply-To: <9411091211.AA22421@tom.anacad.de> (message from domino on Wed, 9 Nov 1994 13:11:02 --100) Subject: Re: LAT minutes, Grenoble, Fr Content-Length: 863 > > c'est bon, j'ai retrouve la dernieres version des minutes, > > as tu reflechi a ces deux acttions item: > Sorry, this was a personnal mail, send by error to the reflector Domino +--------------------------+------------------------------------------+ | |||| DON'T | Dominique RODRIGUEZ domino@anacad.de | | (00) HAVE A BART| ANACAD - HDL Group (VHDL & HDL-A) | | /-------\/ MAN | Tel : +49 731 954 54 17 | | / | || +------------------------------------------+ | * ||----|| | La Terre n'appartient pas a l'homme, | | ^^ ^^ | mais l'homme appartient a la Terre. | | SIMPSON'S COW | Seattle (chef indien) | +--------------------------+------------------------------------------+ From 1076-1-request@sicmail.epfl.ch Wed Nov 9 10:55:04 1994 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Wed, 9 Nov 94 10:55:00 -0500 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Wed, 9 Nov 94 10:54:57 -0500 X400-Received: by mta sicmail.epfl.ch in /PRMD=switch/ADMD=arCom/C=ch/; Relayed; Wed, 9 Nov 1994 16:13:56 +0100 Date: Wed, 9 Nov 1994 16:13:56 +0100 X400-Originator: 1076-1-request@sicmail.epfl.ch X400-Recipients: non-disclosure:; X400-Mts-Identifier: [/PRMD=switch/ADMD=arCom/C=ch/;sicmail.ep.282:09.10.94.15.13.56] Priority: Non-Urgent Dl-Expansion-History: 1076-1@epfl.ch ; Wed, 9 Nov 1994 16:13:56 +0100; From: " (Mark Zwolinski)" Message-Id: <17791.9411091514@louis.ecs.soton.ac.uk> To: 1076-1@epfl.ch Subject: Re: Variables (? val) X-Sender: mz@louis.ecs.soton.ac.uk Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailer: >during writing models for the validation suite I came to the following >question: > Does there exist a VARIABLE (type analog) for communication within > the equational set statement. And what is the meaning of a variable > within another timestep. > > The example below can be written without variables, but on more > complex models, it is often useful and practical to use > variables (values in MAST), which values has only meaning within > this particular timestep. > I have the same question. I too have tried writing models and have found that there needs to be a VARIABLE declaration in the EQUATION SET/RELATION. This does not appear in the LESs that have been written so far! Mark ================================================================== Mark Zwolinski mz@ecs.soton.ac.uk Dept. of Electronics & Computer Science, University of Southampton Southampton SO17 1BJ Tel. (0)1703 593528 Fax. (0)1703 592901 From 1076-1-request@sicmail.epfl.ch Wed Nov 9 12:37:32 1994 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Wed, 9 Nov 94 12:37:20 -0500 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Wed, 9 Nov 94 12:37:14 -0500 Received: from psi.com by sicmail.epfl.ch with SMTP (PP) id <25464-0@sicmail.epfl.ch>; Wed, 9 Nov 1994 18:06:43 +0100 Received: from analogy.com (analogy.analogy.com) by psi.com (4.1/2.1-PSI/PSINet) id AA27233; Wed, 9 Nov 94 12:05:28 EST Received: from miller.analogy.com ([149.117.72.253]) by analogy.com (4.1/Shared_Spool_1.3) id AA25684; Wed, 9 Nov 94 08:55:31 PST Received: from satyr.analogy.com by miller.analogy.com (4.1/SMI-3.2) id AA14541; Wed, 9 Nov 94 09:06:43 PST Received: by satyr.analogy.com (5.0/SMI-SVR4) id AA10067; Wed, 9 Nov 1994 09:05:41 +0800 Date: Wed, 9 Nov 1994 09:05:41 +0800 From: christen@analogy.com (Ernst Christen) Message-Id: <9411091705.AA10067@satyr.analogy.com> To: moser@fli.sh.bosch.de Subject: Re: Variables (? val) Cc: 1076-1@epfl.ch Content-Length: 1375 Eduard Moser asks > >during writing models for the validation suite I came to the following >question: > Does there exist a VARIABLE (type analog) for communication within > the equational set statement. And what is the meaning of a variable > within another timestep. > > The example below can be written without variables, but on more > complex models, it is often useful and practical to use > variables (values in MAST), which values has only meaning within > this particular timestep. > >Further, I would like to whom may I send examples for >syntactical and semantical check. (I had problems with >the definition of characteristic tables). > and then gives an example of a motor written in VHDL-A. Here is an answer to these questions. The Language Architecture Team has in it last 2 meetings spent a lot of time trying to solidify the definition of the semantics of the equations. Part of this discussion is the question how existing VHDL objects like signals and variables interact with equations. The idea is that both signals and variables can be used in equations. However, at this time no conclusion has been reached, and the LAT will continue to discuss this question. As far as the examples go, the focal point should be the Validation chair, Oliver Fischer-Binder. He then will have to coordinate with the Language Design team. Ernst Christen From 1076-1-request@sicmail.epfl.ch Wed Nov 9 17:45:48 1994 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Wed, 9 Nov 94 17:45:42 -0500 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Wed, 9 Nov 94 17:45:37 -0500 Received: from psi.com by sicmail.epfl.ch with SMTP (PP) id <29965-0@sicmail.epfl.ch>; Wed, 9 Nov 1994 23:12:11 +0100 Received: from analogy.com (analogy.analogy.com) by psi.com (4.1/2.1-PSI/PSINet) id AA08533; Wed, 9 Nov 94 17:12:04 EST Received: from miller.analogy.com ([149.117.72.253]) by analogy.com (4.1/Shared_Spool_1.3) id AA27460; Wed, 9 Nov 94 14:02:17 PST Received: from satyr.analogy.com by miller.analogy.com (4.1/SMI-3.2) id AA15287; Wed, 9 Nov 94 14:13:32 PST Received: by satyr.analogy.com (5.0/SMI-SVR4) id AA12645; Wed, 9 Nov 1994 14:12:29 +0800 Date: Wed, 9 Nov 1994 14:12:29 +0800 From: christen@analogy.com (Ernst Christen) Message-Id: <9411092212.AA12645@satyr.analogy.com> To: 1076-1@epfl.ch Subject: LAT meeting Content-Length: 1477 All, As announced previously, the 4th meeting on the LAT will take place in conjunction with the 1076.1 WG meeting, as follows. Dates ----- Wednesday, November 16 Friday, November 18 Saturday, November 19 Let's start on Wednesday at 8:45 am. Location -------- Compass Design Automation 5457 Twin Knolls Road Columbia, MD 20845 Phone: (410) 992-5700 I have provided directions earlier. Attendees --------- According to the responses I received so far the meeting will be attended by the following people (some only for part of the meeting) Ken Bakalar kenb@compass-da.com Jean-Michel Berge berge@cns.cnet.fr Ernst Christen christen@analogy.com Oliver Fischer-Binder olli.fischer@rt.bosch.de Howard Ko Howard_Ko@pdxml1.mentorg.com Peter Liebmann peterl@compass-da.com Dominique Rodriquez domino@anacad.de Richard Trihy trihy@cadence.com Alain Vachoux alain.vachoux@leg.de.epfl.ch Meeting Agenda -------------- Review of minutes of last meeting Review of action items Everybody: Analysis of propositions 1 through 4 described in minutes of September meeting Ken B.: Quantities, nodes, terminals etc. Continuation of language architecture discussion Open issues from last meeting (see minutes) Questions raised in summary of last minutes Analog time and digital time General LAT agenda sent to reflector earlier Please let me know if you have any questions related to this meeting. Thanks. Ernst Christen Chair LAT From 1076-1-request@sicmail.epfl.ch Thu Nov 10 14:54:32 1994 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Thu, 10 Nov 94 14:54:24 -0500 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Thu, 10 Nov 94 14:54:20 -0500 Received: from psi.com by sicmail.epfl.ch with SMTP (PP) id <19943-0@sicmail.epfl.ch>; Thu, 10 Nov 1994 20:30:10 +0100 Received: from analogy.com (analogy.analogy.com) by psi.com (4.1/2.1-PSI/PSINet) id AA20161; Thu, 10 Nov 94 14:29:53 EST Received: from miller.analogy.com ([149.117.72.253]) by analogy.com (4.1/Shared_Spool_1.3) id AA03521; Thu, 10 Nov 94 11:19:44 PST Received: from satyr.analogy.com by miller.analogy.com (4.1/SMI-3.2) id AA18085; Thu, 10 Nov 94 11:31:03 PST Received: by satyr.analogy.com (5.0/SMI-SVR4) id AA24934; Thu, 10 Nov 1994 11:30:01 +0800 Date: Thu, 10 Nov 1994 11:30:01 +0800 From: christen@analogy.com (Ernst Christen) Message-Id: <9411101930.AA24934@satyr.analogy.com> To: 1076-1@epfl.ch Subject: (lang) D/A Conversion Content-Length: 3552 D/A Conversion Issues ===================== The purpose of this message is to start a new discussion thread related to D/A conversions. To introduce the problem, let us assume we have the following relationship between voltages on the analog side and the values of a logic signal S: A/D signal D/A voltage value voltage > 2.5 V '1' 4.5 V <= 2.5 V '0' 0.5 V where D/A voltage describes the voltage to be driven by the logic values of S. Let us also assume that a change of the value of S should be propagated to the analog side as a smooth trajectory between the two voltage levels with a non-zero rise or fall time. The following is a picture showing the D/A interface as it ideally should be. '1' --------+ +--------- | | | | '0' +---------------+ 4.5 ------\ /------- \ / 2.5 \ / \ / 0.5 \-----------/ --------------+-+-+-----------+-+-+------> time t1 ta t2 t3 tb t4 i.e. at the time ta or tb of the change in logic value (the time of the event on S) the analog value should already have changed to the half way point between the two voltage levels. This would make A/D and D/A conversion symmetrical with respect to the threshold at 2.5 V. Now to the problem. To provide a D/A conversion capability as just described it would be required to look into the future of the driver of S and start the trajectory of the analog waveform BEFORE the event on S is processed, at t1 or t3, respectively. This is dangerous, as the relationship between the change in the analog waveform and the event on S is potentially non-causal. Consider the case where the driver of S changes between t1 and ta or between t3 and tb, thereby cancelling the event at ta or tb. In this scenario spikes would be created on the analog waveform which are not present in real life. Rather, they are introduced as artefacts of modeling, specifically the modeling of the A/D and D/A interface. One way to avoid this problem is to start the trajectory on the analog side at the time of the event, as follows. '1' --------+ +--------- | | | | '0' +---------------+ 4.5 --------\ /----- \ / 2.5 \ / \ / 0.5 \-----------/ ----------------+---+-----------+---+-----> time ta tb t1 t2 t3 t4 This would restore causality in the D/A conversion and avoid any spikes, as the analog value only starts to change when the event on S is processed (and therefore is known to be there). However, there is an error in timing which is in the order of 0.5 times the rise or fall time of the analog waveform. I'd like to start a focused discussion about this issue. To clearly distinguish these two cases let them be labeled case A and case B: - case A: potentially non-causal, but symmetrical - case B: always causal, but small timing error The purpose of the discussion is to identify all the issues related to this problem, along the lines of (but not restricted to) - why either case is preferable - why either case is acceptable or not acceptable - why one case is a must and the other won't work - what other problems exist with either of the two cases - are there other possibilities The Language Architecture Team will then use the results of this discussion as input for its design of the semantics of the D/A interface. I don't want to set a time limit for the discussion right now, but it will have a clear termination, and the discussion results will be summarized to the reflector. Ernst Christen Chair LAT From 1076-1-request@sicmail.epfl.ch Fri Nov 11 13:52:27 1994 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Fri, 11 Nov 94 13:52:21 -0500 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Fri, 11 Nov 94 13:52:16 -0500 Received: from psi.com by sicmail.epfl.ch with SMTP (PP) id <06830-0@sicmail.epfl.ch>; Fri, 11 Nov 1994 19:27:34 +0100 Received: from analogy.com (analogy.analogy.com) by psi.com (4.1/2.1-PSI/PSINet) id AA29183; Fri, 11 Nov 94 13:19:54 EST Received: from miller.analogy.com ([149.117.72.253]) by analogy.com (4.1/Shared_Spool_1.3) id AA09655; Fri, 11 Nov 94 10:10:02 PST Received: from satyr.analogy.com by miller.analogy.com (4.1/SMI-3.2) id AA21091; Fri, 11 Nov 94 10:21:26 PST Received: by satyr.analogy.com (5.0/SMI-SVR4) id AA06433; Fri, 11 Nov 1994 10:20:24 +0800 Date: Fri, 11 Nov 1994 10:20:24 +0800 From: christen@analogy.com (Ernst Christen) Message-Id: <9411111820.AA06433@satyr.analogy.com> To: 1076-1@epfl.ch Subject: Re: (lang) D/A Conversion Content-Length: 5879 I got this response from Dan Damon at Mentor Graphics. I forward it to the WG at large for discussion. Ernst -------------------------------------------------------------------------- >From Dan_Damon@pdxml1.mentorg.com Thu Nov 10 16:39:22 1994 >From: "Dan Damon" Subject: Re: FWD>(lang) D/A Conversio To: "Ernst Christen" , Rob_Hughes@pdxml1.mentorg.com, Howard_Ko@pdxml1.mentorg.com, Doug_Lundin@pdxml1.mentorg.com Reply to: RE>FWD>(lang) D/A Conversion Continuum currently uses case B, which is really a timing error, but we will be able to implement case A when negative timing is available. (Gate thruput will not be negative, just less than it was.) Case A reflects reality, since there is always a delay in the output driver. The only case where there is no delay is a wired "AND" or "OR". In these cases, it is resolved correctly on the analog site anyway. This talk of non-causuality is techno-babble on analogy's part since real parts have real delays. --Dan -------------------------------------- Date: 11/10/94 4:14 PM To: Dan Damon >From: Doug Lundin Dan, Rob, howard, What happens in continuum? Is this an issue? doug -------------------------------------- Date: 11/10/94 11:34 AM >From: Ernst Christen Received: by pdxml2.mentorg.com with SMTP;10 Nov 1994 11:33:57 U Received: from sicmail.epfl.ch by newsgw.mentorg.com (8.6.4/CF5.22R) id OAA19018; Thu, 10 Nov 1994 14:33:10 -0500 Received: from psi.com by sicmail.epfl.ch with SMTP (PP) id <19943-0@sicmail.epfl.ch>; Thu, 10 Nov 1994 20:30:10 +0100 Received: from analogy.com (analogy.analogy.com) by psi.com (4.1/2.1-PSI/PSINet) id AA20161; Thu, 10 Nov 94 14:29:53 EST Received: from miller.analogy.com ([149.117.72.253]) by analogy.com (4.1/Shared_Spool_1.3) id AA03521; Thu, 10 Nov 94 11:19:44 PST Received: from satyr.analogy.com by miller.analogy.com (4.1/SMI-3.2) id AA18085; Thu, 10 Nov 94 11:31:03 PST Received: by satyr.analogy.com (5.0/SMI-SVR4) id AA24934; Thu, 10 Nov 1994 11:30:01 +0800 Date: Thu, 10 Nov 1994 11:30:01 +0800 >From: christen@analogy.com (Ernst Christen) Message-Id: <9411101930.AA24934@satyr.analogy.com> To: 1076-1@epfl.ch Subject: (lang) D/A Conversion Content-Length: 3552 D/A Conversion Issues ===================== The purpose of this message is to start a new discussion thread related to D/A conversions. To introduce the problem, let us assume we have the following relationship between voltages on the analog side and the values of a logic signal S: A/D signal D/A voltage value voltage > 2.5 V '1' 4.5 V <= 2.5 V '0' 0.5 V where D/A voltage describes the voltage to be driven by the logic values of S. Let us also assume that a change of the value of S should be propagated to the analog side as a smooth trajectory between the two voltage levels with a non-zero rise or fall time. The following is a picture showing the D/A interface as it ideally should be. '1' --------+ +--------- | | | | '0' +---------------+ 4.5 ------\ /------- \ / 2.5 \ / \ / 0.5 \-----------/ --------------+-+-+-----------+-+-+------> time t1 ta t2 t3 tb t4 i.e. at the time ta or tb of the change in logic value (the time of the event on S) the analog value should already have changed to the half way point between the two voltage levels. This would make A/D and D/A conversion symmetrical with respect to the threshold at 2.5 V. Now to the problem. To provide a D/A conversion capability as just described it would be required to look into the future of the driver of S and start the trajectory of the analog waveform BEFORE the event on S is processed, at t1 or t3, respectively. This is dangerous, as the relationship between the change in the analog waveform and the event on S is potentially non-causal. Consider the case where the driver of S changes between t1 and ta or between t3 and tb, thereby cancelling the event at ta or tb. In this scenario spikes would be created on the analog waveform which are not present in real life. Rather, they are introduced as artefacts of modeling, specifically the modeling of the A/D and D/A interface. One way to avoid this problem is to start the trajectory on the analog side at the time of the event, as follows. '1' --------+ +--------- | | | | '0' +---------------+ 4.5 --------\ /----- \ / 2.5 \ / \ / 0.5 \-----------/ ----------------+---+-----------+---+-----> time ta tb t1 t2 t3 t4 This would restore causality in the D/A conversion and avoid any spikes, as the analog value only starts to change when the event on S is processed (and therefore is known to be there). However, there is an error in timing which is in the order of 0.5 times the rise or fall time of the analog waveform. I'd like to start a focused discussion about this issue. To clearly distinguish these two cases let them be labeled case A and case B: - case A: potentially non-causal, but symmetrical - case B: always causal, but small timing error The purpose of the discussion is to identify all the issues related to this problem, along the lines of (but not restricted to) - why either case is preferable - why either case is acceptable or not acceptable - why one case is a must and the other won't work - what other problems exist with either of the two cases - are there other possibilities The Language Architecture Team will then use the results of this discussion as input for its design of the semantics of the D/A interface. I don't want to set a time limit for the discussion right now, but it will have a clear termination, and the discussion results will be summarized to the reflector. Ernst Christen Chair LAT From 1076-1-request@sicmail.epfl.ch Fri Nov 11 13:52:37 1994 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Fri, 11 Nov 94 13:52:29 -0500 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Fri, 11 Nov 94 13:52:25 -0500 Received: from psi.com by sicmail.epfl.ch with SMTP (PP) id <06881-0@sicmail.epfl.ch>; Fri, 11 Nov 1994 19:31:44 +0100 Received: from analogy.com (analogy.analogy.com) by psi.com (4.1/2.1-PSI/PSINet) id AA29143; Fri, 11 Nov 94 13:18:19 EST Received: from miller.analogy.com ([149.117.72.253]) by analogy.com (4.1/Shared_Spool_1.3) id AA09652; Fri, 11 Nov 94 10:08:22 PST Received: from satyr.analogy.com by miller.analogy.com (4.1/SMI-3.2) id AA21088; Fri, 11 Nov 94 10:19:47 PST Received: by satyr.analogy.com (5.0/SMI-SVR4) id AA06429; Fri, 11 Nov 1994 10:18:44 +0800 Date: Fri, 11 Nov 1994 10:18:44 +0800 From: christen@analogy.com (Ernst Christen) Message-Id: <9411111818.AA06429@satyr.analogy.com> To: 1076-1@epfl.ch Subject: Re: (lang) D/A Conversion Content-Length: 5252 I got this response from Ron Vogelsong at Harris. I forward it to the WG at large for discussion. Ernst ------------------------------------------------------------------------ >From rsv@mlb.semi.harris.com Thu Nov 10 13:45:32 1994 >From: rsv@mlb.semi.harris.com (Ron Vogelsong) To: christen@analogy.com Subject: Re: (lang) D/A Conversion The 'non-causal' solution is by all means the most rational description of a digital-to-analog conversion. The real issue is under what conditions this type of conversion is possible. '1' --------+ +--------- Digital | | Signal | | '0' +---------------+ . . . . 4.5 ------\ . . /------- Analog \. ./ Output 2.5 \ / .\ /. 0.5 . \-----------/ . . . --------------+-+-+-----------+-+-+------> time t1 ta t2 t3 tb t4 IF the logic section is accessible, any one of several methods can be used to 'correct' the signal that's driving the analog output. We've used several with some success: 1) If the digital signal is being driven by a simple buffer/inverter type of element, describe the analog output as the model of that buffer, based on the INPUT to that buffer. Thus the system will be fully causal with no real difficult timing issues. This is also the optimal solution for the analog simulator, as it can schedule its future timesteps to not overstep the output transition that hasn't happened yet, and the behavioral buffer model can be designed to respond as realistically as desired to narrow input pulses. (This approach can also be applied to more complex gates than buffers, limited only by the availability of analog logic blocks available). ____________ Buffer Input ______| |_________ : ____________ Buffer Output __________| : |_____ : . __________ . : ./ : \. Analog Output : / : \ _________/. : .\____ 2) If the digital signal is being driven by any single block (i.e., it's not a multi-input bus driven with tristates), the delay of that block can be reduced by half of the risetime so that the delayed form suggested in the original letter can be used without incurring the time delay: ____________ Original Digital Signal ________| |_____ ____________ . Modified Block Signal ______| . |_______ : . __________ . : ./ :\. Analog Output : / : \ _________/ ; .\____ 3) If the digital signal is also driving other digital cells besides the analog output, than one of two cases must be chosen: A) Ignore analog loading, preserve the original digital block to drive the other digital cells, and just use a modified copy of the digital cell with the reduced delay time as in (2) to drive the analog output. B) To include analog loading effects, apply the same construct as in (2), and then use an A/D converter to drive the remaining digital nodes (this is the most accurate solution). 4) If you can't get any information out of the digital simulator other than "a transition has occured", then the analog simulator must resort to allowing an up-to-half-risetime delay to occur, by starting the analog output waveform at either the transition point or the last transient timepoint before the transion, which is more accurate but less consistant. Generally, backstepping by more than one transient timepoint isn't attempted, as this could conceivably change the course of the interim simulation, possibly to the point of generating a logical flaw (paradox) between the operation of the analog and digital simulations, as well as waste a lot of computer time when several digital signals change in succession. ____________ Digital Signal ______| |_______ : __________: : / \ Analog Output :/ :\ ________/ : \_____ --------------------------------------------------------------------------- Also, a general postscript about the presence of 'Spikes' due to transition glitches: Wouldn't you expect to see some change on the output if the input signal did change in between t1 and ta in the figure? I don't really see their presence on the analog side as a significant problem in the model -- I'd expect there to be some form of spike showing up there anyway. In this example, the spike wouldn't pass 2.5 volts, so it shouldn't propagate at any rate. ............................................................................ Ron Vogelsong (ron.vogelsong@harris.com) 407-729-5188 Harris Semiconductor ........ P.O. Box 883, MS 62B-022, Melbourne, FL 32902 From 1076-1-request@sicmail.epfl.ch Mon Nov 14 11:40:29 1994 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Mon, 14 Nov 94 11:40:25 -0500 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Mon, 14 Nov 94 11:40:18 -0500 Received: from psi.com by sicmail.epfl.ch with SMTP (PP) id <10028-0@sicmail.epfl.ch>; Mon, 14 Nov 1994 17:02:03 +0100 Received: from analogy.com (analogy.analogy.com) by psi.com (4.1/2.1-PSI/PSINet) id AA26052; Mon, 14 Nov 94 11:01:44 EST Received: from miller.analogy.com ([149.117.72.253]) by analogy.com (4.1/Shared_Spool_1.3) id AA20593; Mon, 14 Nov 94 07:51:28 PST Received: from satyr.analogy.com by miller.analogy.com (4.1/SMI-3.2) id AA26102; Mon, 14 Nov 94 08:03:08 PST Received: by satyr.analogy.com (5.0/SMI-SVR4) id AA20202; Mon, 14 Nov 1994 08:02:04 +0800 Date: Mon, 14 Nov 1994 08:02:04 +0800 From: christen@analogy.com (Ernst Christen) Message-Id: <9411141602.AA20202@satyr.analogy.com> To: 1076-1@epfl.ch Subject: Re: (lang) D/A Conversion Content-Length: 5231 I received the following response from Jeam Mermet, Ernst ------------------------------------------------------------------------ >From Jean.Mermet@imag.fr Mon Nov 14 05:05:16 1994 To: christen@analogy.com (Ernst Christen) >From: Jean.Mermet@imag.fr (Jean Mermet) Subject: Re: (lang) D/A Conversion >D/A Conversion Issues >===================== >The purpose of this message is to start a new discussion thread related to >D/A conversions. To introduce the problem, let us assume we have the >following relationship between voltages on the analog side and the values >of a logic signal S: > A/D signal D/A > voltage value voltage > > 2.5 V '1' 4.5 V > <= 2.5 V '0' 0.5 V >where D/A voltage describes the voltage to be driven by the logic values of S. >Let us also assume that a change of the value of S should be propagated to >the analog side as a smooth trajectory between the two voltage levels with >a non-zero rise or fall time. The following is a picture showing the D/A >interface as it ideally should be. > > > '1' --------+ +--------- > | | > | | > '0' +---------------+ > > > 4.5 ------\ /------- > \ / > 2.5 \ / > \ / > 0.5 \-----------/ > > --------------+-+-+-----------+-+-+------> time > t1 ta t2 t3 tb t4 > >i.e. at the time ta or tb of the change in logic value (the time of the event >on S) the analog value should already have changed to the half way point >between the two voltage levels. This would make A/D and D/A conversion >symmetrical with respect to the threshold at 2.5 V. > >Now to the problem. To provide a D/A conversion capability as just described >it would be required to look into the future of the driver of S and start >the trajectory of the analog waveform BEFORE the event on S is processed, >at t1 or t3, respectively. This is dangerous, as the relationship between the >change in the analog waveform and the event on S is potentially non-causal. >Consider the case where the driver of S changes between t1 and ta or between >t3 and tb, thereby cancelling the event at ta or tb. In this scenario spikes >would be created on the analog waveform which are not present in real life. >Rather, they are introduced as artefacts of modeling, specifically the modeling >of the A/D and D/A interface. > >One way to avoid this problem is to start the trajectory on the analog side >at the time of the event, as follows. > > '1' --------+ +--------- > | | > | | > '0' +---------------+ > > > 4.5 --------\ /----- > \ / > 2.5 \ / > \ / > 0.5 \-----------/ > > ----------------+---+-----------+---+-----> time > ta tb > t1 t2 t3 t4 > >This would restore causality in the D/A conversion and avoid any spikes, >as the analog value only starts to change when the event on S is processed >(and therefore is known to be there). However, there is an error in timing >which is in the order of 0.5 times the rise or fall time of the analog >waveform. > >I'd like to start a focused discussion about this issue. To clearly distinguish >these two cases let them be labeled case A and case B: > - case A: potentially non-causal, but symmetrical > - case B: always causal, but small timing error >The purpose of the discussion is to identify all the issues related to this >problem, along the lines of (but not restricted to) > - why either case is preferable > - why either case is acceptable or not acceptable > - why one case is a must and the other won't work > - what other problems exist with either of the two cases > - are there other possibilities $$$$$$$ I THINK SO. WHY DON'T YOU APPLY CASE B: THEN WHEN REACHING T4 SHIFT EVERYTHING BACK (T4-TB)/2 AND RESTART AT TB+(T4-TB)/2 $$$$$ >The Language Architecture Team will then use the results of this discussion >as input for its design of the semantics of the D/A interface. I don't want >to set a time limit for the discussion right now, but it will have a clear >termination, and the discussion results will be summarized to the reflector. > >Ernst Christen >Chair LAT ----------------------------------------------------------------------------- Jean Mermet e-mail : mermet@imag.fr Artemis, University J. Fourier Phone : 33/ 76 51 44 99 BP 53X Fax : 33/ 76 42 87 87 GRENOBLE CEDEX 38041, FRANCE ---------------------------------------------------------------------------- -- From 1076-1-request@sicmail.epfl.ch Mon Nov 14 15:21:11 1994 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Mon, 14 Nov 94 15:21:08 -0500 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Mon, 14 Nov 94 15:21:04 -0500 Received: from psi.com by sicmail.epfl.ch with SMTP (PP) id <15669-0@sicmail.epfl.ch>; Mon, 14 Nov 1994 20:57:35 +0100 Received: from analogy.com (analogy.analogy.com) by psi.com (4.1/2.1-PSI/PSINet) id AA05870; Mon, 14 Nov 94 14:57:20 EST Received: from miller.analogy.com ([149.117.72.253]) by analogy.com (4.1/Shared_Spool_1.3) id AA21806; Mon, 14 Nov 94 11:47:04 PST Received: from satyr.analogy.com by miller.analogy.com (4.1/SMI-3.2) id AA26649; Mon, 14 Nov 94 11:58:44 PST Received: by satyr.analogy.com (5.0/SMI-SVR4) id AA20676; Mon, 14 Nov 1994 11:57:40 +0800 Date: Mon, 14 Nov 1994 11:57:40 +0800 From: christen@analogy.com (Ernst Christen) Message-Id: <9411141957.AA20676@satyr.analogy.com> To: 1076-1@epfl.ch Subject: RE: (lang) D/A Conversion Content-Length: 2953 I received this from Ken Bakalar. It provides more information about the language design issues than my original posting. Ernst ------------------------------------------------------------------------- >From kenb@compass-da.com Mon Nov 14 10:38:41 1994 To: christen@analogy.com >From: kenb@compass-da.com (Kenneth Bakalar) Subject: RE: (lang) D/A Conversion Roughly speaking and in the general case, an event on a signal at time T is intended to represent a physical change that began before T, reaches a critical threshold at T, and will continue to a more or less stable final value. So a signal whose value will change after some inter-digital-transaction interval [Tc,Tn] (for example, S in "S <= not S after Tn-now+delta", executed at now=Tc,delta non-negative) may need to be modeled as a quantity whose value begins to change within [Tc,Tn]. To do that, we need to be able to "look into the digital future" in some sense. What does this mean in the context of the VHDL simulation cycle? Let us suppose that we can define the "effective driver" of a signal. The simple case is a signal with a single driver as its only source; then the "effective driver" is the current value of the signal and a queue of future time/value pairs -- just the canonical driver of a signal as defined in the LRM. In the general case (when the signal has multiple sources and/or an interface signal source) we will need to define a kind of "prospective network evaluation" based on the current language regarding the advance of time and the evaluation of signals. Suppose we drive the simulation cycle forward, suppressing all process executions as we do so, and accumulating the time and value of each event on each interesting signal. The time-value pairs so accumulated are the effective driver of the signal. Then the effective driver is something we can know about the digital future. If it is made available to the designer of the digital to analog converter by a language extension, then an implementation of class B is possible. Whether it is desirable is another matter, which I will leave to you analog experts out there. Can we know anything more apriori (without soliciting additional information from the designer not already encoded in the digital VHDL text) about the designer's intention? It has been suggested that the separate reject and delay times used in signal assignments might provide some useful hints. In the current definition of VHDL that information is lost, only leaving its traces in the edited driver. Should we retain this information? What would the designer do with it? __________________________________________________________________ Kenneth Bakalar voice +1 410 992 5700 ext. 1204 COMPASS Design Automation fax +1 410 992 3536 5457 Twin Knolls Road email kenb@compass-da.com Columbia MD 20845 USA __________________________________________________________________ From 1076-1-request@sicmail.epfl.ch Mon Nov 21 01:28:20 1994 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Mon, 21 Nov 94 01:28:05 -0500 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Mon, 21 Nov 94 01:28:01 -0500 Received: from inet-tsb.toshiba.co.jp by sicmail.epfl.ch with SMTP (PP) id <19916-0@sicmail.epfl.ch>; Mon, 21 Nov 1994 05:44:58 +0100 Received: from tis2.tis.toshiba.co.jp (tis2) by inet-tsb.toshiba.co.jp (5.67+1.6W/2.8Wb) id AA23375; Mon, 21 Nov 94 13:39:04 JST Received: from tis10.tis.toshiba.co.jp (tis10) by tis2.tis.toshiba.co.jp (5.67+1.6W/6.4J.6-R05) id AA19752; Mon, 21 Nov 94 13:39:30 JST Received: from eecisa.eec.toshiba.co.jp (eecisa) by tis10.tis.toshiba.co.jp (5.67+1.6W/6.4J.6-MHS-CNTML-R1) id AA24673; Mon, 21 Nov 94 13:39:35 JST Received: from roku.eec.toshiba.co.jp (eecjsf) by eecisa.eec.toshiba.co.jp (4.1/6.4J.6-R1) id AA22044; Mon, 21 Nov 94 13:34:03 JST Return-Path: Received: by roku.eec.toshiba.co.jp (8.6.9+2.4Wb3/3.3W-roku_Master) with ESMTP id NAA22154; Mon, 21 Nov 1994 13:38:58 +0900 From: "VHDL analog mail by (CA1)H.Sasaki 94.1.18" Message-Id: <199411210438.NAA22154@roku.eec.toshiba.co.jp> Date: Mon, 21 Nov 1994 13:38:13 +0900 To: 1076-1@epfl.ch, haase@eas.iis.fhg.de Subject: (VHDL-A) pi/4-shift QPSK by HDL-A Cc: jvlwg@nttica.ntt.jp, rendering@anacad.com Dear all, I have wrote my 3rd description: pi/4 shift QPSK (Quadarure Phase Shift Keying). I feel reset of integration is rather difficult to understand. integ() seems to be too denotational to fit equational semantics when one writes reset in "PROCEDURAL section". I think many beginners will be misunderstand that the reset of integration of ii := integ(i4); can be implemented by ii:= 0.0; statement. So, I hope language designer will add example how to reset integ in LRM explicitly. Best regards, ----------------------------------------------------------- -- Hisashi Sasaki, Ph.D. Specialist -- -- BIPOLAR ANALOG DESIGN AUTOMATION, TOSHIBA CORPORATION -- -- 580-1, HORIKAWA-CHO, SAIWAI-KU, KAWASAKI 210, JAPAN -- -- PHONE: +81-44-548-2604 FAX: +81-44-548-8970 -- -- E-MAIL: 000092040542@tg-mail.toshiba.co.jp (office) -- -- PXI04522@niftyserve.or.jp (home) -- ----------------------------------------------------------- --------------------qpsk.cir------------------------------------------------ * pi/4-shift QPSK (Quadrature Phase Shift Keying) #com H. Sasaki, 14.11.1994, for HDL-A #endcom .HDLALIB /local/eecrip/usr3/sasaki/eldo/v4.3.3/examples/hdla/sasaki-lib .model qpsk_in1(d1) macro lang=hdla .model qpsk_in2(d1) macro lang=hdla .model qpsk_clk(d1) macro lang=hdla .model qpsk_mod(m1) macro lang=hdla .model qpsk_demod(a1) macro lang=hdla .model qpsk_out(m1) macro lang=hdla y1 qpsk_in1(d1) + port: in1 y12 qpsk_in2(d1) + port: in2 y13 qpsk_clk(d1) + port: clk y2 qpsk_mod(m1) + generic: omega1=0.795774715e8 mag=5.0 + pin: m_out + port: in1 in2 clk y3 qpsk_demod(a1) + generic: omega1=0.795774715e8 vhigh=5.0 vlow=0.0 tslope=1.0e-9 + pin: m_out d_out1 d_out2 + port: clk y4 qpsk_out(m1) + generic: vth=2.5 + pin: d_out1 d_out2 ! + port: out1 out2 r1 m_out 0 10K r2 d_out1 0 10K r3 d_out2 0 10K .tran 1n 1.0u .plot tran v(in1) v(in2) v(clk) ! ! .plot tran v(m_out) .plot tran v(y3->i4) .plot tran v(y3->ii) .plot tran v(y3->q4) .plot tran v(y3->qq) .plot tran v(d_out1) .plot tran v(d_out2) .option noascii .end ------------------------qpsk.hdla----------------------------------------- -- TITLE: pi/4-shift QPSK (Quadrature Phase Shift Keying) -- AUTHOR: Hisashi Sasaki, TOSHIBA -- e-mail: 000092040542@tg-mail.toshiba.co.jp -- sasaki@roku.eec.toshiba.co.jp -- DATE: 15.11.94 -- LASTUPDATE: 15.11.94 -- LANGUAGEVERSION: HDL-A v1.1.3a for sun4c -- CODESTATE: [INVALID] VALID -- HISTORY: -- Initial 06.10.94 -- 07.10.94 [INVALID] -- 31.10.94 [INVALID] for HDL-A -- 02.11.94, 10.11.94, 14.11.94, -- 15.11.94 for reset-problem -- 21.11.94 [VALID] -- DESCRIPTION: -- QPSK o:odd \ downwards -- e:even / upwards -- Q -- in1,in2 angle 5.0*cos() -- | 11 o | pi/8 | 4.6 \ -- | 11 e | pi*3/8 | 1.9 \ -- 01 | 11 01 o | pi*5/8 | -1.9 \ -- o | e 01 e | pi*7/8 | -4.6 \ -- e | o 00 o | pi*9/8 | -4.6 / -- | 00 e | pi*11/9 | -1.9 / -- ------+------ I 10 o | pi*13/8 | 1.9 / -- | 10 e | pi*15/8 | 4.6 / -- o | e -- e | o -- 00 | 10 -- | -- | -- -- (note) output: 1st cycle is not valid, because the outputs -- are delayed by one-cycle. -- -- SCHEMATIC: -- -- CODE: -- HDL-A Version v1.1.3a for sun4c -- STIMULI: -- -- EXPECTED_RESULTS: -- Text, Formulas, Curves : Format PROPSAL EPS -- RESULTS: -- SIMULATION_ENGINE: VESIM V2.1.2d -- DATE: 21.11.94 -- RESULT_STATE: INVALID [VALID] -- ... -- PROBLEM_LOG: -- 02.11.94: [OPEN] -- -- At maximum one relation block can be put in an -- architecture description: HDL-A v1.1.3a, VESIM V2.1.2d -- -- (Request) "Reset of integration" must be explicitly -- illustrated by example: I spend much time to find -- out how to reset it by sample-and-hold. -- --------------------------------------------------------------------- -- Generator of inputs and Clock for testing --------------------------------------------------------------------- ENTITY qpsk_in1 IS PORT(in1 : OUT BIT); END ENTITY qpsk_in1; ARCHITECTURE d1 OF qpsk_in1 IS SIGNAL in1q : BIT; BEGIN PROCESS BEGIN -- assume symbol interval T is 100ns in1q <= '0', '0' AFTER 100ns, '1' AFTER 200ns, '1' AFTER 300ns, '0' AFTER 400ns, '0' AFTER 500ns, '0' AFTER 600ns, '1' AFTER 700ns, '1' AFTER 800ns, '0' AFTER 900ns, '0' AFTER 1000ns, '1' AFTER 1100ns; in1 <= in1q; L1: LOOP WAIT FOR 100ns; in1 <= in1q; END LOOP; END PROCESS; END ARCHITECTURE d1; ENTITY qpsk_in2 IS PORT(in2 : OUT BIT); END ENTITY qpsk_in2; ARCHITECTURE d1 OF qpsk_in2 IS SIGNAL in2q : BIT; BEGIN PROCESS BEGIN -- assume symbol interval T is 100ns in2q <= '0', '1' AFTER 100ns, '0' AFTER 200ns, '1' AFTER 300ns, '0' AFTER 400ns, '0' AFTER 500ns, '1' AFTER 600ns, '0' AFTER 700ns, '1' AFTER 800ns, '0' AFTER 900ns, '1' AFTER 1000ns, '0' AFTER 1100ns; in2 <= in2q; L1: LOOP WAIT FOR 100ns; in2 <= in2q; END LOOP; END PROCESS; END ARCHITECTURE d1; ENTITY qpsk_clk IS PORT(clk : OUT BIT); END ENTITY qpsk_clk; ARCHITECTURE d1 OF qpsk_clk IS SIGNAL clkq : BIT; BEGIN PROCESS BEGIN -- assume symbol interval T is 100ns clk <= '0', '1' AFTER 50ns, '0' AFTER 100ns; clkq <= '0', '1' AFTER 50ns, '0' AFTER 100ns; L1: LOOP WAIT FOR 50ns; clkq <= not clkq; clk <= clkq; END LOOP; END PROCESS; END ARCHITECTURE d1; --------------------------------------------------------------------- -- QPSK Modulator --------------------------------------------------------------------- ENTITY qpsk_mod IS GENERIC ( omega1, -- local osc. mag -- amplitude : REAL); PORT(in1, in2, clk: IN BIT); PIN(m_out : ELECTRICAL); END ENTITY qpsk_mod; ARCHITECTURE m1 OF qpsk_mod IS VARIABLE symbol_start_time, -- time when symbol starts phi, -- rotation by even/odd phi1 : REAL; -- signal constelation VARIABLE even_odd : INTEGER; -- 0/1 for even/odd BEGIN RELATION PROCEDURAL FOR INIT => even_odd := 1; phi := pi/8.0; phi1 := phi; symbol_start_time := 0.0; m_out.v %= mag*cos(phi); PROCEDURAL FOR DC => m_out.v %= mag*cos(phi1); PROCEDURAL FOR TRANSIENT => IF event(clk) AND clk='1' THEN symbol_start_time := current_time; IF even_odd=0 THEN -- odd phi := pi*3.0/8.0; even_odd := 1; -- for next ELSE -- =1: even phi := pi/8.0; even_odd := 0; -- for next END IF; IF (in1='1' AND in2='1') THEN phi1 := 0.0 +phi; -- cos END IF; IF (in1='1' AND in2='0') THEN phi1 := -(pi/2.0) + phi; -- -sin END IF; IF (in1='0' AND in2='1') THEN phi1 := pi/2.0 + phi; -- sin END IF; IF (in1='0' AND in2='0') THEN phi1 := pi + phi; -- -cos END IF; END IF; -- END OF "event(clk) AND clk='1'" m_out.v %= mag*cos(omega1*(current_time-symbol_start_time)+phi1); END RELATION; END ARCHITECTURE m1; -- qpsk_mod ------------------------------------------------------------------- -- QPSK Demodulator ------------------------------------------------------------------- ENTITY qpsk_demod IS GENERIC( omega1, -- equals to "omega1" of the above modulator vhigh, -- voltage level for "high" vlow, -- voltage level for "low" tslope -- time slope for driving output : REAL); PORT( clk : IN BIT); PIN(m_out, d_out1, d_out2 : ELECTRICAL); -- modulated input, demodulated outputs END ENTITY qpsk_demod; ARCHITECTURE a1 OF qpsk_demod IS VARIABLE even_odd : INTEGER; VARIABLE symbol_start_time, -- phi -- : REAL; STATE i, q, -- i1, q1, -- i4, q4, -- rotated i & q ii, qq -- In-phase/Quadrature Integral : ANALOG; BEGIN RELATION PROCEDURAL FOR INIT => even_odd := 1; phi := pi/8.0; symbol_start_time := 0.0; i := 0.0; q := 0.0; i1:= 0.0; q1:= 0.0; ii:= 0.0; -- initial for In-phase integral qq:= 0.0; -- initial for Quadrant integral d_out1.v %= 0.0; d_out2.v %= 0.0; PROCEDURAL FOR DC => NULL; PROCEDURAL FOR TRANSIENT => i := m_out.v * cos(omega1*(current_time-symbol_start_time) + phi); q := m_out.v * cos(omega1*(current_time-symbol_start_time) + phi + pi/2.0); i4 := i-q; -- rotate by pi/8 q4 := i+q; -- rotate by pi/8 IF event(clk) AND clk='1' THEN symbol_start_time := current_time; IF even_odd = 0 THEN phi := pi*3.0/8.0; even_odd := 1; ELSE phi := pi/8.0; even_odd := 0; END IF; IF ii > 0.0 AND qq > 0.0 THEN slope(d_out1.v, vhigh, 0.0, tslope); slope(d_out2.v, vhigh, 0.0, tslope); ELSIF ii < 0.0 AND qq > 0.0 THEN slope(d_out1.v, vlow, 0.0, tslope); slope(d_out2.v, vhigh, 0.0, tslope); ELSIF ii < 0.0 AND qq < 0.0 THEN slope(d_out1.v, vlow, 0.0, tslope); slope(d_out2.v, vlow, 0.0, tslope); ELSIF ii > 0.0 AND qq < 0.0 THEN slope(d_out1.v, vhigh, 0.0, tslope); slope(d_out2.v, vlow, 0.0, tslope); END IF; i1 := integ(i4); -- sample and hold q1 := integ(q4); -- sample and hold END IF; ii := integ(i4)-i1; -- reset integ(i4) by -i1 qq := integ(q4)-q1; -- reset integ(q4) by -q1 END RELATION; END ARCHITECTURE a1; ------------------------------------------------------------------ -- QPSK demodulated output as digital signal ------------------------------------------------------------------ ENTITY qpsk_out IS GENERIC( vth -- threshold for a2d :REAL); -- PORT( out1, out2 : OUT BIT); PIN( d_out1, d_out2 : ELECTRICAL); END ENTITY qpsk_out; ARCHITECTURE m1 OF qpsk_out IS SIGNAL out1q, out2q : BIT; BEGIN PROCESS BEGIN IF d_out1.v >= vth THEN out1q <= '1'; -- out1 <= out1q; ELSE out1q <= '0'; -- out1 <= out1q; END IF; IF d_out2.v >= vth THEN out2q <= '1'; -- out2 <= out2q; ELSE out2q <= '0'; -- out2 <= out2q; END IF; L3: LOOP WAIT ON rising(d_out1.v,vth),falling(d_out1.v,vth), rising(d_out2.v,vth),falling(d_out2.v,vth); IF d_out1.v >= vth THEN out1q <= '1'; -- rising -- out1 <= out1q; ELSE out1q <= '0'; -- falling -- out1 <= out1q; END IF; IF d_out2.v >= vth THEN out2q <= '1'; -- rising -- out2 <= out2q; ELSE out2q <= '0'; -- falling -- out2 <= out2q; END IF; END LOOP; -- L3 END PROCESS; END ARCHITECTURE m1; From 1076-1-request@sicmail.epfl.ch Tue Nov 22 09:50:56 1994 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Tue, 22 Nov 94 09:50:48 -0500 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Tue, 22 Nov 94 09:50:45 -0500 Received: from etdl839.arl.army.mil by sicmail.epfl.ch with SMTP (PP) id <07758-0@sicmail.epfl.ch>; Tue, 22 Nov 1994 15:20:57 +0100 Received: by etdl839 (5.0/SMI-SVR4) id AA09105; Tue, 22 Nov 1994 09:22:06 +0500 Date: Tue, 22 Nov 1994 09:22:06 +0500 From: rhodes@arl.army.mil Message-Id: <9411221422.AA09105@etdl839> To: 1076-1@epfl.ch, mhdl@halibut.nosc.mil Subject: MHDL announcement Content-Length: 419 Dear MHDL & VHDL-A folks: In case you are not aware, a "Broad Agency Announcement (BAA)", basically a call for abstracts/proposals, has been published in the Commerce Business Daily (CBD) on November 18, 1994 to solicit new MHDL work. Rather than clog the Internet arteries by sending the full text to all, I can send an e-mail version on your request to those who do not have access to the CBD. Regards, Dave Rhodes From 1076-1-request@sicmail.epfl.ch Wed Nov 23 19:14:59 1994 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Wed, 23 Nov 94 19:14:57 -0500 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Wed, 23 Nov 94 19:14:53 -0500 Received: from psi.com by sicmail.epfl.ch with SMTP (PP) id <09634-0@sicmail.epfl.ch>; Thu, 24 Nov 1994 00:40:15 +0100 Received: from analogy.com (analogy.analogy.com) by psi.com (4.1/2.1-PSI/PSINet) id AA03202; Wed, 23 Nov 94 18:38:47 EST Received: from miller.analogy.com ([149.117.72.253]) by analogy.com (4.1/Shared_Spool_1.3) id AA12092; Wed, 23 Nov 94 15:27:49 PST Received: from satyr.analogy.com by miller.analogy.com (4.1/SMI-3.2) id AA21337; Wed, 23 Nov 94 15:40:15 PST Received: by satyr.analogy.com (5.0/SMI-SVR4) id AA10308; Wed, 23 Nov 1994 15:39:10 +0800 Date: Wed, 23 Nov 1994 15:39:10 +0800 From: christen@analogy.com (Ernst Christen) Message-Id: <9411232339.AA10308@satyr.analogy.com> To: 1076-1@epfl.ch Subject: LAT meeting Content-Length: 2238 As announced previously, the 4th meeting of the 1076.1 Language Architecture Team took place last week in Columbia MD. It was attended by about 10 people from various organizations. I would like to thank all attendees for their participation, and Compass Design Automation for their hospitality. The following is a brief summary of the progress that was made at the meeting, more detailed minutes will follow. After reviewing the minutes of the 3rd meeting we discussed and established guidelines for the technical aspects of our work, based on similar guidelines used by the VHDL'93 restandardization. We then discussed extensively a white paper by Ken Bakalar on "Semantics of Nodes, Quantities and Branches for VHDL 1076.1". The paper presents much of the material covered by LESs A, B, F, G, H, O in a unified way, providing definitions in a language that is close to LRM language, and a rationale. Although the paper does not currently handle composite terminals (e.g. arrays) we adopted the proposal as a basis for future work. Moving on to relations, we agreed that the description of analog behavior mainly consists of specifying differential and algebraic equations. Since there are established methods to solve simultaneous DAEs, we don't have to document solution methods, but we have to describe how these equations are formed from the behavior specified in all component instances and the topo- logical constraints like KCL/KVL. The semantic meaning of the statements in a relation will be the topic of a white paper to be prepared for the next LAT meeting. Ken Bakalar then presented some of his ideas about the simulation cycle, A/D and D/A interaction. This is unfinished work, which will be discussed further at the next LAT meeting. We also identified several other topics on which white papers will be prepared for the next meeting. These white papers will allow the LAT to work more efficiently. The next LAT meeting will be held from January 31, 1995 to February 3, 1995, in Lausanne, Switzerland. Alain Vachoux is in charge of local arrangements (hotel, meeting place). Please let him know by January 16, 1995 if you will attend. His email is alain.vachoux@leg.de.epfl.ch. Ernst Christen LAT chair From 1076-1-request@sicmail.epfl.ch Tue Nov 29 12:02:49 1994 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Tue, 29 Nov 94 12:02:45 -0500 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Tue, 29 Nov 94 12:02:39 -0500 Received: from c3imac12.epfl.ch by sicmail.epfl.ch with SMTP (PP) id <11537-0@sicmail.epfl.ch>; Tue, 29 Nov 1994 17:32:52 +0100 X-Sender: vachoux@c3i9.epfl.ch Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 29 Nov 1994 17:35:46 +0100 To: 1076-1@epfl.ch From: alain.vachoux@leg.de.epfl.ch (Alain Vachoux EPFL-LEG/C3i) Subject: Minutes of the DASC meeting in Tysons VA Minutes of IEEE VHDL 1076.1 working group IEEE CS DASC working group meetings, November 17, 1994 Tysons Corner, Virginia Submitted by Alain Vachoux Reviewed by Jean-Michel Berge and Ernst Christen Attendees (20): Kenneth Bakalar kenb@compass-da.com Jean-Michel Berge berge@cns.cnet.fr Hal Carter hal.carter@uc.edu Ernst Chisten christen@analogy.com Dan Damon dan_damon@mentorg.com Steven Drager dragers@rl.af.mil Joerg-Oliver Fischer-Binder fischer@dic.k8.rt.bosch.de Christopher Flynn flynnc@rl.af.mil Jim Hanna hanna@rl.af.mil Robert Hillman hillman@rl.af.mil Sylvie Hurat hurat@sctf.thomson.fr Howard Ko howard_ko@mentorg.com Peter Liebmann peterl@compass-da.com Joe Mitchell joe@mtl.com Dominique Rodriguez domino@anacad.de Jacques Rouillard rouillard@acm.org Ken Simone ksimone@mtl.com Dennis Soderberg dennis@telelab.fp.fmv.se Richard Trihy trihy@cadence.com Alain Vachoux vachoux@leg.de.epfl.ch Agenda: - Status of the work (Jean-Michel Berge) - Presentation of Design Objective Rationale 1.1 (Alain Vachoux) - Status of Language Architecture Team (Ernst Christen) - Status of Validation task (Oliver Fischer-Binder) - Status of Documentation task (Peter Liebmann) - Miscellaneous (Jean-Michel Berge): - communication mechanisms, email reflector(s) - meetings: kinds, goals - general 1076.1 schedule The meeting started at 8.30am and finished at 4.30pm. 1. Status of the work (Jean-Michel) Note: A postscript version of the slides presented here are available in the 1076.1 ftp archive site in the file: incoming/vhdl/analog/ref/minutes/DASC_17nov94/status_slides.ps Jean-Michel introduced the meeting with the current status of the work done so far within the working group. The main effort is currently put on the definition of the architecture of the VHDL-A language. Jean-Michel recalled how the different teams in the working group are working. He also gave again some practical information about the available communication channels (i.e. the reflector and the ftp archive sites). 2. Presentation of Design Objective Rationale 1.1 (Alain Vachoux) Note: A postscript version of the slides presented here are available in the 1076.1 ftp archive site in the file: incoming/vhdl/analog/ref/minutes/DASC_17nov94/dor1.1_slides.ps A draft version of the DOR 1.1 is available in the file: incoming/vhdl/analog/working/DOD/DOD_rationale_V1.1_draft Alain presented the new version 1.1 of the Design Objective Rationale (DOR) document. The DOR is thightly coupled with the Design Objective Document (DOD). More specifically, DOR 1.1 is related to DOD 2.1. Copies of these two documents were distributed to the attendees as draft documents. The presentation of the DOR raised many comments and questions: - The term "IC" used in the DOR is misleading because integrated circuits are a specific kind of electrical circuits. The terms "electrical" and "non-electrical" should be used instead. However, DO1 and its rationale are clear enough about this point. - The objective to support lumped-element systems and the objective to support ODEs are equivalent. The former is related to the structure aspect, while the latter is related to the behavior aspect. - The assumption about two different simulation kernels, i.e. one digital and one analog, is only used to formalize the semantics of analog objects and of the interactions between analog and digital objects. It does not enforce any particular implementation. - The use of VHDL terminology in design objectives and rationales is questionable. A typical example is the support of "static" and "dynamic" parameters. In the DOD and the DOR, "static" means "constant", while "dynamic" means "varying during simulation". In VHDL LRM, the term "static" carries a different meaning. The DOD and DOR must be more explicit about the terminology they are using. - It may be useful to make a distinction between objectives that will have impact on the language (e.g. analog behavior) and the objectives that will not (e.g. predefined analog environment). - The initialization phase of the (mixed-mode) simulation cycle is critical for the analog part. A mechanism that reports an inconsistent state at the interface between digital and analog should be devised as an objective. Hal Carter proposed to post a message on the reflector to discuss this point. - Simulation control, as understood in the DOD and the DOR, encompasses a bidirectional interaction between the model and the simulator. Some people in the audience felt that simulation control is more like a shell around the model and hence something outside the language. The rationale must be more precise about language-related and tool-related aspects, although this may be clearly defined during language design only. Both DOD and DOR documents have yet to be reviewed in a first step by the Design Requirement team, and in a second step by the whole working group for internal acceptation. The second step will involve the publication of DOD 2.1 and DOR 1.1 on the reflector. A period of 2 weeks will be provided for feedbacks. Then, the internal vote will start and another period of 2 weeks will be provided to get the ballot results (Christmas period may imply some additional small delay). See the action items section below for a complete schedule of this process. 3. Language Architecture Team (Ernst Christen) Note: A postscript version of the slides presented here are available in the 1076.1 ftp archive site in the file: incoming/vhdl/analog/ref/minutes/DASC_24sep94/langdes_slides.ps Ernst presented the outline of the VHDL-A architecture the LAT (Language Architecture Team) is currently setting up. The main goal is to define concepts, leaving syntax design to the LES groups and ultimately to the Documentation team. Several comments or questions were issued: - Many issues were identified and related to the existing set of LESs. Many issues are also still open as they are currently discussed within the LAT. Some priority should be given to open issues to distinguish between issues that must be solved for the first version of VHDL-A, and issues that may be solved for subsequent revisions. The separate LAT minutes provide more details about that. - What are the main differences between VHDL-A and MHDL capabilities? MHDL is a description language for pure analog (microwave) systems and does not define any simulation semantics. An attempt is made to develop an interface with VHDL. VHDL-A is clearly oriented towards mixed-mode description and simulation. Some good ideas from MHDL (e.g. how dimensional analysis is handled) could be used as examples to provide the same capabilities in VHDL-A. - The LAT needs 5-6 more meetings to achieve a first consistent version of the VHDL-A architecture. New open issues may be raised in the future, but a firmer ground will be also available. - Preserving causality is one of the VHDL-A guidelines Ernst presented. This point concerns mainly the interface between analog and digital parts of the model. A new thread of discussion was already set up on the reflector the week before the DASC meeting. There is a need to get more feedback from designers about which model of the behavior between analog and digital parts is suitable to take into account in VHDL-A. 4. Validation task (Oliver Fischer-Binder) Work in the context of the European JESSI project AC3 on developing models is going on at the Technical University of Chemnitz. It includes the modeling on non-electrical systems. Also, several examples of models from Hisashi Sasaki were posted on the reflector. A question was raised about how these examples actually cover the new concepts introduced by VHDL-A. It was answered that it is difficult to measure the coverage since the architecture and the LES are not stable yet. Oliver proposed to post on the reflector the updated list of examples he collected so far. The complete examples will be also stored in the ftp archive site. Note that a first list of examples was posted on the reflector on June 16, 1994, along with the procedure to follow for validation. Another point that was raised is it would be more valuable to let every interested working group member to access the full model in order to review it and to discuss it. By "full model" it is meant either complete code or a complete description of the specifications the model is intended to met. Oliver stressed the fact that volunteers for validation are still welcome. 3. Documentation task (Peter Liebmann) Note: A postscript version of the slides presented here are available in the 1076.1 ftp archive site in the file: incoming/vhdl/analog/ref/minutes/DASC_24sep94/doc_slides.ps The Documentation team collected the list of IEEE members that committed to the 1076.1 balloting process. 139 people are on this list so far. The collect is now closed, but, since the exact date of the ballot is not yet fixed (around end of July 95), another collect phase is possible. No decision was taken, however, during the meeting to open a new collect phase. 5. Miscellaneous One-day DASC meetings are considered enough to transmit information about the work done and to collect feedback. Most of the discussion should occur on the reflector and during specific meetings such as the LAT meetings. A point was raised about the opportunity to present and to discuss specific modeling examples during DASC meetings. This would help to clarify the new concepts introduced in VHDL-A. It was also recognized that it would be better to discuss the intention behind the model rather than a specific syntax. The DASC steering committee decided to have the next DASC meetings during the next VIUF conference in San Diego, CA (April 3-6, 1995). The date and the agenda of the next 1076.1 meeting will be posted on the reflector ASAP. 6. Summary of action items What Who When DOD 2.1 / DOR 1.1: - First review Design Req. team finished by mid December - Working group review Design Req. team beginning by mid December - Internal vote Design Req. team beginning January 95 finished by mid January 95 Agenda of next DASC 1076.1 meeting Jean-Michel ASAP Updated list of examples Oliver beginning of December From 1076-1-request@sicmail.epfl.ch Tue Nov 29 15:50:02 1994 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Tue, 29 Nov 94 15:49:55 -0500 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Tue, 29 Nov 94 15:49:49 -0500 Received: from psi.com by sicmail.epfl.ch with SMTP (PP) id <15903-0@sicmail.epfl.ch>; Tue, 29 Nov 1994 21:06:15 +0100 Received: from analogy.com (analogy.analogy.com) by psi.com (4.1/2.1-PSI/PSINet) id AA12874; Tue, 29 Nov 94 15:05:27 EST Received: from miller.analogy.com ([149.117.72.253]) by analogy.com (4.1/Shared_Spool_1.3) id AA02791; Tue, 29 Nov 94 11:54:13 PST Received: from satyr.analogy.com by miller.analogy.com (4.1/SMI-3.2) id AA29795; Tue, 29 Nov 94 12:07:06 PST Received: by satyr.analogy.com (5.0/SMI-SVR4) id AA01937; Tue, 29 Nov 1994 12:05:59 +0800 Date: Tue, 29 Nov 1994 12:05:59 +0800 From: christen@analogy.com (Ernst Christen) Message-Id: <9411292005.AA01937@satyr.analogy.com> To: 1076-1@epfl.ch Subject: Dimensional analysis literature Content-Length: 6529 The following list of references about dimensional analysis was recently sent to the MHDL reflector. It may be relevant to our effort as well. Xref: news comp.lang.ada:13832 Path: news!newshub.nosc.mil!dog.ee.lbl.gov!agate!howland.reston.ans.net!EU.net!uknet!doc.ic.ac.uk!yama.mcc.ac.uk!cs.man.ac.uk!newshost!bevan >From: bevan@cs.man.ac.uk (Stephen J Bevan) Newsgroups: comp.lang.ada Subject: Re: Types with physical dimension Date: 05 Oct 1994 10:35:09 GMT Organization: Department of Computer Science; University of Manchester Lines: 177 Message-ID: References: <36tole$j5e@cyclope.enst.fr> NNTP-Posting-Host: lemur.cs.man.ac.uk In-reply-to: rosen@enst.fr's message of 5 Oct 1994 09:38:05 +0100 In article <36tole$j5e@cyclope.enst.fr> rosen@enst.fr (Jean-Pierre Rosen) writes: ... I saw this idea in a paper long ago. As far as I recall, it was by N. Cohen. Norm, are you listening? This sounds like the method discussed in [Hilfinger:acm:toplas:1988], I don't remember if Hilfinger referenced/acknowledged Norman though. For interested parties, I've also included some references to other work on adding dimensions to programming languages :- @article { Biedl:acm:sigplan:1977 , author= "Albrecht Biedl" , title= "An Extension of Programming Languages for Clerical Computation in Science and Engineering With Special Reference to PASCAL" , journal= acm:sigplan , volume= 12 , number= 4 , pages= "31--33" , month= apr , year= 1977 , checked= 19940516 , keywords= "Pascal, dimensional types" , sjb= "Proposes an extension to Pascal that allows dimensional information to be added to declarations." } @article { Karr:Lovemann:cacm:1978 , author= "Michael Kaar and Lovemann, III, David B." , title= "Incorporation of units into programming languages" , journal= cacm , volume= 21 , number= 5 , pages= "385--391" , month= may , year= 1978 , keywords= "dimensional types" , reffrom= Horning:pc:1978c , reffrom= Hilfinger:acm:toplas:1988 } @article { House:bcscj:1983 , author= "R. T. House" , title= "A proposal for an extended form of type checking of expressions" , journal= bcscj , volume= 26 , number= 4 , pages= "366--374" , month= nov , year= 1983 , cr= "8610-0116 (uncomplementary)" , cr= "8704-0276 (rebuttal+response)" , cr= "8705-0377 by Luca Cardelli - complementary" , keywords= "dimensional types" , sjb= "describes adding physical ``dimensions'' and ``units'' in a strongly typed language (Pascal in used)." , reffrom= Hilfinger:acm:toplas:1988 } @article { Gehani:spe:1985 , author= "N. H. Gehani" , title= "Ada's Derived Types and Units of Measure" , journal= spe , volume= 15 , year= 1985 , pages= "555--569" , keywords= "Ada, dimensional types" , reffrom= Dreiheller:Moerschbacher:Mohr:acm:sigplan:1986 , reffrom= Hilfinger:acm:toplas:1988 } @article { Manner:acm:sigplan:1986 , author= "R. M{\"a}nner" , title= "Strong Typing and Physical Units" , journal= acm:sigplan , volume= 21 , number= 3 , pages= "11--20" , month= mar , year= 1986 , keywords= "dimensional types" , reffrom= Dreiheller:Moerschbacher:Mohr:acm:sigplan:1986 } @article { Dreiheller:Moerschbacher:Mohr:acm:sigplan:1986 , author= "A. Dreiheller and M. Moerschbacher and B. Mohr" , title= "Programming Pascal with Physical Units" , journal= acm:sigplan , volume= 21 , number= 12 , pages= "114--123" , month= dec , year= 1986 , refs= 7 , checked= 19940617 , source= "Dept. Library" , keywords= "Pascal, dimensional types" , abstract= "In~\cite{Manner:acm:sigplan:1986} (SIGPLAN Notices 3/1986) M\"anner proposes an extension of Pascal permitting the use of physical units in programs. We discuss his issues in this paper and describe our own somewhat different approach. Our language extension PHYSCAL of Pascal not merely satisfies the requirements suggested by~\cite{Manner:acm:sigplan:1986}, but also supports predfined units (International Standard), thorough realisation of the concept of scale factors, input/output facilities for number with units. The new concepts are motivated, and the language description is given formally and by examples. Finally we discuss some details of the realised language implementation by a PHYSCAL-to-Pascal preprocessor in an UNIX environment." } @article { Jones:ddj:pp:1987 , author= "Do-While Jones" , title= "Dimensional Data Types" , journal= ddj:pp , volume= 12 , number= 127 , pages= "50--54" , month= may , year= 1987 , refs= 3 , checked= 19940513 , keywords= "Ada, dimensional types" , abstract= "Using dimensional units as data types can facilitate the writing of clearer, more easily maintained code. Do-While presents example programs in Ada." , xref= Ludquist:ddj:pp:1987 } @article { Hilfinger:acm:toplas:1988 , author= "Paul N. Hilfinger" , title= "An Ada Package for Dimensional Analysis" , journal= acm:toplas , volume= 10 , number= 2 , pages= "189--203" , month= apr , year= 1987 , refs= 8 , checked= 19940623 , source= "Dept. Library" , keywords= "dimensional analysis, language design, units, dimentional types" , abstract= "This paper illustrates the use of Ada's abstraction facilities -- notably, operator overloading and type parameterization -- to define an oft-requested feature: a way to attribute units of measure to variables and values. The definition given allows the programmer to specify units of measure for variables, constants, and parameters; checks uses of these entities for dimensional consistency; allows arithmetic between them, where legal; and provides scale conversions between commensurate units. It is not constrained to a particular system of measurement (such as the metric or English systems). Although the definition is in standard Ada and requires nothing special of the compiler, certain reasonable design choices in the compiler, discussed here at some length, can make its implementation particularly efficient." , sjb= "Proposes the use of a UNITS package which exports a QUANT type which encodes the various dimensions and which can be checked at runtime. Logically each variable/constant becomes a record with 5 integers representing the dimensions and a single float representing the scalar value. It is noted that With a naive compiler, this is very inefficient!" } From 1076-1-request@sicmail.epfl.ch Wed Nov 30 07:20:38 1994 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Wed, 30 Nov 94 07:20:35 -0500 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Wed, 30 Nov 94 07:20:31 -0500 X400-Received: by mta sicmail.epfl.ch in /PRMD=switch/ADMD=arCom/C=ch/; Relayed; Wed, 30 Nov 1994 13:04:31 +0100 Date: Wed, 30 Nov 1994 13:04:31 +0100 X400-Originator: 1076-1-request@sicmail.epfl.ch X400-Recipients: non-disclosure:; X400-Mts-Identifier: [/PRMD=switch/ADMD=arCom/C=ch/;sicmail.ep.078:30.10.94.12.04.31] Priority: Non-Urgent Dl-Expansion-History: 1076-1@epfl.ch ; Wed, 30 Nov 1994 13:04:31 +0100; From: " (Mark Zwolinski)" Message-Id: <28022.9411301205@louis.ecs.soton.ac.uk> To: 1076-1@epfl.ch Subject: Examples 1/3 X-Sender: mz@louis.ecs.soton.ac.uk Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailer: Back in the summer I made some comments about trying to model a MOS transistor in VHDL-A. I have made some changes in the light of various LES modifications. Following is my MOS model code. I have also rewritten the Anacad VCO/PLL example. Again that follows. I would welcome any comments. I have used at least one illegal construct and may have inadvertantly used more! Mark ================================================================== Mark Zwolinski mz@ecs.soton.ac.uk Dept. of Electronics & Computer Science, University of Southampton Southampton SO17 1BJ Tel. (0)1703 593528 Fax. (0)1703 592901 From 1076-1-request@sicmail.epfl.ch Wed Nov 30 07:20:45 1994 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Wed, 30 Nov 94 07:20:43 -0500 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Wed, 30 Nov 94 07:20:38 -0500 X400-Received: by mta sicmail.epfl.ch in /PRMD=switch/ADMD=arCom/C=ch/; Relayed; Wed, 30 Nov 1994 13:06:44 +0100 Date: Wed, 30 Nov 1994 13:06:44 +0100 X400-Originator: 1076-1-request@sicmail.epfl.ch X400-Recipients: non-disclosure:; X400-Mts-Identifier: [/PRMD=switch/ADMD=arCom/C=ch/;sicmail.ep.145:30.10.94.12.06.44] Priority: Non-Urgent Dl-Expansion-History: 1076-1@epfl.ch ; Wed, 30 Nov 1994 13:06:44 +0100; From: " (Mark Zwolinski)" Message-Id: <28037.9411301207@louis.ecs.soton.ac.uk> To: 1076-1@epfl.ch Subject: Examples 3/3 X-Sender: mz@louis.ecs.soton.ac.uk Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailer: ------------------------------------------------------------------------------- -- -- VHDL-A (1076.1) Simple PLL Model -- -- (c) University of Southampton, 1994 -- -- Version 0.1 18th October 1994 -- -- Author: Dr Mark Zwolinski -- Department of Electronics and Computer Science -- University of Southampton -- Southampton SO17 2BJ, UK -- Tel +44 (0) 1703 593528 -- Fax +44 (0) 1703 593045 -- Email mz@ecs.soton.ac.uk -- -- Description: -- VHDL-A model of a simple PLL, including the vco, a2d and d2a converters. -- VCO based on ANACAD HDL-A VCO example. -- -- -- N.B. This version (0.1) has not been tested with any VHDL compiler. -- ------------------------------------------------------------------------------- ENTITY vco IS GENERIC ( f0: FLOAT := 1E6; kf: FLOAT := 1E6; magmax: FLOAT := 1.0; phase: FLOAT := 0.0; holdrange:FLOAT := 4E5; tdelay: FLOAT := 2E-5; trise: FLOAT := 3E-5; maxderiv: FLOAT := 100.0); PIN (inp, outp : ELECTRICAL); END ENTITY vco; ARCHITECTURE behavioural OF vco IS CONSTANT twopi : FLOAT := 2.0*3.14159; QUANTITY omega, phi : FLOAT; BEGIN RELATION VARIABLE delta_omega, mag : FLOAT; PROCEDURAL => IF (inp.v > holdrange / (2.0 * kf)) OR (inp.v < -holdrange / (2.0 * kf)) THEN omega := twopi * f0; ELSE omega := twopi * (f0 * kf * inp.v); END IF; delta_omega := (NOW - time_step) * (omega'last_value - omega); phi := delta_omega + phi'last_value; IF NOW > (tdelay+trise) THEN mag := magmax; ELSE IF NOW < tdelay THEN mag := 0.0; ELSE mag := magmax * (NOW - tdelay) / trise; END IF; END IF; IF (ABS(delta_omega) > maxderiv) THEN outp.v := mag * sin(twopi * f0 * NOW + phi + (phase/360.0 * twopi)); ELSE outp.v := mag * sin(omega * NOW + phi + (phase / 360.0 * twopi)); END IF; END RELATION; END ARCHITECTURE behavioural; ------------------------------------------------------------------------- ENTITY a2d IS GENERIC (vthreshold: FLOAT := 2.5); PIN (ina, inb: electrical); PORT (outp: std_logic); END ENTITY a2d; ARCHITECTURE interface OF a2d IS BEGIN PROCESS((ina,inb).v'CROSSING(vthreshold)) IF (ina,inb).v'RISING(vthreshold) THEN outp <= '1'; ELSE outp <= '0'; END IF; END PROCESS; END ARCHITECTURE interface; ------------------------------------------------------------------------- ENTITY d2a IS GENERIC (v1: FLOAT := 5.0; v0: FLOAT := 0.0); PORT (inp: IN std_logic); PIN (outp: electrical); END ENTITY d2a; ARCHITECTURE interface OF d2a IS BEGIN IF (inp = '1') THEN outp.v := v1; ELSE outp.v := v0; END IF; END ARCHITECTURE interface; ------------------------------------------------------------------------- ENTITY pll IS PORT (ind: IN std_logic; outd: OUT std_logic); END ENTITY pll; ARCHITECTURE structural OF pll IS -- COMPONENT declarations and configuration statements might go here! NODE upa, downa, vcontrol: electrical; NODE vdd: electrical := (5.0); SIGNAL upd, downd: std_logic; BEGIN pd: phase_detect PORT MAP(ind,outd,upd,downd); da1: d2a PORT MAP (downd) PIN MAP (downa); da2: d2a PORT MAP (upd) PIN MAP (upa); lf: filter PIN MAP (upa, downa, vcontrol, vdd); vc: vco PIN MAP (vcontrol,outa); ad: a2d PIN MAP (outa) PORT MAP (outd); END ARCHITECTURE structural; ================================================================== Mark Zwolinski mz@ecs.soton.ac.uk Dept. of Electronics & Computer Science, University of Southampton Southampton SO17 1BJ Tel. (0)1703 593528 Fax. (0)1703 592901 From 1076-1-request@sicmail.epfl.ch Wed Nov 30 07:20:55 1994 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Wed, 30 Nov 94 07:20:53 -0500 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Wed, 30 Nov 94 07:20:47 -0500 X400-Received: by mta sicmail.epfl.ch in /PRMD=switch/ADMD=arCom/C=ch/; Relayed; Wed, 30 Nov 1994 13:04:51 +0100 Date: Wed, 30 Nov 1994 13:04:51 +0100 X400-Originator: 1076-1-request@sicmail.epfl.ch X400-Recipients: non-disclosure:; X400-Mts-Identifier: [/PRMD=switch/ADMD=arCom/C=ch/;sicmail.ep.093:30.10.94.12.04.51] Priority: Non-Urgent Dl-Expansion-History: 1076-1@epfl.ch ; Wed, 30 Nov 1994 13:04:51 +0100; From: " (Mark Zwolinski)" Message-Id: <28026.9411301205@louis.ecs.soton.ac.uk> To: 1076-1@epfl.ch Subject: Examples 2/3 X-Sender: mz@louis.ecs.soton.ac.uk Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailer: ------------------------------------------------------------------------------- -- -- VHDL-A (1076.1) SPICE Level 3 MOS Model -- -- (c) University of Southampton, 1994 -- -- Version 0.1 18th October 1994 -- -- Author: Dr Mark Zwolinski -- Department of Electronics and Computer Science -- University of Southampton -- Southampton SO17 2BJ, UK -- Tel +44 (0) 1703 593528 -- Fax +44 (0) 1703 593045 -- Email mz@ecs.soton.ac.uk -- -- Description: -- VHDL-A model of intrinsic part of SPICE level 3 MOS model (source, drain -- resistances, overlap capacitances and drain-bulk, source-bulk diodes are -- all omitted.) -- There are some differences with the SPICE model. -- Based on SPICE 2G6/3E2 source and Southampton University MOS model -- and converted from Pascal. -- -- -- N.B. This version (0.1) has not been tested with any VHDL compiler. -- ------------------------------------------------------------------------------- TYPE electrical IS NATURE ACROSS v; THROUGH i; REFERENCE gnd; END NATURE electrical; TYPE mosmodel IS RECORD vt0 : FLOAT; kp : FLOAT; gamma : FLOAT; phi : FLOAT; tox : FLOAT; nsub : FLOAT; nss : FLOAT; nfs : FLOAT; tpg : FLOAT; xj : FLOAT; ld : FLOAT; u0 : FLOAT; vmax : FLOAT; xqc : FLOAT; kf : FLOAT; af : FLOAT; fc : FLOAT; delta : FLOAT; theta : FLOAT; eta : FLOAT; kappa : FLOAT; END RECORD mosmodel; CONSTANT mymos: mosmodel := ( vt0 => open, kp => 2.0E-5, gamma => open, phi => open, tox => 1.0E-7, nsub => 0.0, nss => 0.0, nfs => 0.0, tpg => 1.0, xj => 0.0, ld => 0.0, u0 => 600.0, vmax => 0.0, xqc => 1.0, kf => 0.0, af => 1.0, fc => 0.5, delta => 0.0, theta => 0.0, eta => 0.0, kappa => 0.2 ); ENTITY mos IS GENERIC ( -- instance parameters width : FLOAT :=1.0E-4; -- should be global constant DEFW! length : FLOAT :=1.0E-4; -- DEFL channel: FLOAT :=1.0; -- +1 for NMOS, -1 for PMOS -- model parameters model: mosmodel:= ( vt0 => open, kp => 2.0E-5, gamma => open, phi => open, tox => 1.0E-7, nsub => 0.0, nss => 0.0, nfs => 0.0, tpg => 1.0, xj => 0.0, ld => 0.0, u0 => 600.0, vmax => 0.0, xqc => 1.0, kf => 0.0, af => 1.0, fc => 0.5, delta => 0.0, theta => 0.0, eta => 0.0, kappa => 0.2; ); -- environment parameters Temperature : FLOAT :=300.0; -- Should be global ); PIN( drain, gate, source, bulk : electrical); END ENTITY mos; ARCHITECTURE mos3 OF mos IS CONSTANT eps0 : FLOAT :=8.85418e-12; CONSTANT Ni : FLOAT :=1.45e16; CONSTANT Boltzmann : FLOAT :=1.380662e-23; CONSTANT echarge: FLOAT :=1.6021892e-19; CONSTANT epsSiO2 : FLOAT :=3.9*eps0; CONSTANT epsSi : FLOAT :=11.7*eps0; CONSTANT kTQ : FLOAT :=Boltzmann*temperature/echarge; CONSTANT pi: FLOAT := 3.14159; QUANTITY Qc, Qb, Qg : FLOAT; BEGIN RELATION -- We can't put VARIABLEs is ARCHITECTUREs and we don't want this lot to be QUANTITIES. -- So, although it's not stated in the LES, we must be able to put VARIABLE declarations -- inside REALATIONs. VARIABLE cox,beta,vt,sigma,nsub,Phi,Gamma,nss,ngate,A,B,C,D,Vfb,fshort, wp,wc,sqwpxj,vbulk,delv,vth,Vgstos, Vgst, Ueff,Tau,Vsat,Vpp,fdrain, stfct,leff,xd,qnfscox,fn,dcrit,deltal,It,Ids,R,Vds,Vgs,Vbs, channel,forward : FLOAT; PROCEDURAL FOR init => IF model.tox<=0.0 THEN cox:=epsSiO2/1e-7; ELSE cox:=epsSiO2/model.tox; ENDIF; IF model.kp = 0.0 THEN beta:=cox*model.u0; ELSE beta:=model.kp; END IF; nsub := model.nsub * 1e6; -- scale nsub to SI units -- The following is not legal by the VHDL 1076 standard. -- All "OPEN" GENERICs must be assigned legal values by the -- configuration. SPICE, however, allows parameters to be -- undefined, and calculates appropriate values. Could test for -- zero value, but there is possible confusion if the value has -- deliberately been set to zero! IF (model.phi = open) THEN IF (nsub > 0) THEN Phi:=max(0.1,2.0*kTQ*ln(nsub/Ni)); ELSE Phi:=0.6; END IF; ELSE Phi:=model.phi; END IF; -- Again, this is illegal! IF (model.gamma = open) THEN IF (nsub > 0) THEN Gamma:=sqrt(2.0*epsSi*echarge*nsub)/cox; ELSE Gamma:=0.0; END IF; ELSE Gamma:=model.gamma; END IF; nss:=model.nss*1e4; -- Scale to SI ngate:=model.gate*1e4; -- Scale to SI -- Again, illegal! IF (model.vt0 = open) THEN egfet:=1.16-(7.02e-4*Temperature*Temperature)/(Temperature+1108.0); IF model.tpg=0.0 THEN fermig:=0.05+egfet/2.0; ELSE IF ngate>0.0 THEN fermig:=model.tpg*channel*kTQ*ln(ngate/Ni) ELSE fermig:=model.tpg*channel*egfet/2; END IF; vt:=-fermig+channel*(Phi*0.5+Gamma*sqrt(Phi))-nss*echarge/cox; END IF; ELSE vt:=model.vt0; END IF; leff:=length-2.0*model.ld; IF leff>0.0 THEN Sigma:=model.eta*8.15e-22/(cox*leff*leff*leff); ELSE Sigma:=0.0; END IF; IF nsub>0.0 THEN -- N.B. nsub was scaled, above. xd:=sqrt(2.0*epsSi/(echarge*nsub)); ELSE xd:=0.0; END IF; IF (model.nfs>0.0) AND (cox>0.0) THEN qnfscox:=echarge*model.nfs/cox; ELSE qnfscox:=0.0; END IF; IF cox>0.0 THEN fn:=model.delta*pi*epsSi*0.5/(cox*width); ELSE fn:=model.delta*pi*epsSi*0.5*model.tox/epsSiO2; END IF; --Scale beta and convert cox from Fm^-2 to F beta:=beta*width/leff; cox:=cox*width*leff; -- END PROCEDURAL FOR init => PROCEDURAL => -- for all domains Vds:=channel*(drain,source).v; IF Vds>=0.0 THEN Vgs:=channel*(gate,source).v; Vbs:=channel*(bulk,source).v; forward:=1.0; ELSE Vds:=-Vds; Vgs:=channel*(gate,drain).v; Vbs:=channel*(bulk,drain).v; forward:=-1.0; END IF; IF Vbs<=0.0 THEN A:=Phi-Vbs; D:=sqrt(A); ELSE D:=2.0*sqrt(Phi)*Phi/(2.0*Phi+Vbs); A:=D*D; END IF; Vfb:=Vt-Gamma*sqrt(Phi)-Sigma*Vds; IF (xd=0.0) OR (model.xj=0.0) THEN fshort:=1.0; ELSE wp:=xd*D; wc:=0.0631353*model.xj+0.8013292*wp-0.01110777*wp*wp/model.xj; sqwpxj:=sqrt(1.0-(wp*wp/((wp+model.xj)*(wp+model.xj)))); fshort:=1.0-((model.ld+wc)*sqwpxj-model.ld)/leff; END IF; vbulk:=Gamma*fshort*D+fn*A; IF model.nfs=0.0 THEN delv:=0.0; ELSE delv:=kTQ*(1.0+qnfscox+vbulk*0.5/A); END IF; vth:=Vfb+vbulk; Vgstos:=Vgs-Vfb; Vgst:=max(Vgs-vth,delv); IF (vgs>=vth) OR (delv<>0.0) THEN IF (Vbs<=0.0) OR (Phi /= 0.0) THEN B:=0.5*Gamma/D+fn; ELSE B:=fn; END IF; mobdeg:=1.0/(1.0+theta*Vgst); IF (model.vmax /=0.0) THEN Ueff:=model.u0*mobdeg; Tau:=Ueff/Leff*model.vmax; ELSE Tau:=0.0; END IF; Vsat:=Vgst/(1.0+B); Vsat:=Vsat*(1.0-0.5*Tau*Vsat); -- not quite the same as SPICE Vpp:=min(Vds,Vsat); fdrain:=1.0/(1.0+Tau*Vpp); IF (Vgs0.0) THEN stfct:=exp((Vgs-vth-delv)/delv); ELSE stfct:=1.0; END IF; IF Vds>=Vsat THEN IF (model.kappa>0.0) and (xd>0.0) THEN IF model.vmax=0.0 THEN deltal:=sqrt(model.kappa*xd*xd*(Vds-Vsat)); ELSE dcrit:=(xd*xd*model.vmax*0.5)/(Ueff*(1.0-fdrain)); deltal:=sqrt(model.kappa*xd*xd*(Vds-Vsat)+dcrit*dcrit)-dcrit; END IF; IF deltal<=0.5*Leff THEN C:=Leff/(Leff-deltal); ELSE C:=4.0*deltal/Leff; END IF; ELSE --kappa=0.0 or xd=0.0 C:=1.0; END IF; ELSE C:=1.0; END IF; It:=Vgst-Vpp*(1.0+B)*0.5; Beta:=Beta*mobdeg; Ids:=Beta*Vpp*It*C*fdrain*stfct; ELSE -- Cutoff Ids:=0.0; END IF; IF Cox /= 0.0 THEN --Charges IF Vgs<=vth THEN IF Gamma /= 0.0 THEN IF Vgstos < -A THEN Qg:=Cox*(Vgstos+A); -- Accumulation ELSE Qg:=0.5*Gamma*Cox*(sqrt(4.0*(Vgstos+A)+sqr(Gamma))-Gamma); END IF; ELSE -- Gamma = 0.0 Qg:=0.0; END IF; Qb:=-Qg; Qc:=0.0; ELSE -- depletion mode: R:=(1.0+B)*Vpp*Vpp/(12.0*It); Qg:=Cox*(Vgstos-Vpp*0.5+R); Qc:=-Cox*(Vgst+(1.0+B)*(R-Vpp*0.5)); Qb:=-(Qc+Qg); ELSE Qg:=0.0; Qc:=0.0; Qb:=0.0; END IF; EQUATION (drain.i) => -- EQUATIONs set up for all domains channel*forward*Ids+channel*xqc*ddt(Qc) == drain.i; EQUATION (gate.i) => channel*ddt(Qg) == gate.i; EQUATION (bulk.i) => channel*ddt(Qb) == bulk.i; EQUATION (source.i) => - drain.i - gate.i - bulk.i == source.i; END RELATION; END ARCHITECTURE mos3; ================================================================== Mark Zwolinski mz@ecs.soton.ac.uk Dept. of Electronics & Computer Science, University of Southampton Southampton SO17 1BJ Tel. (0)1703 593528 Fax. (0)1703 592901 From 1076-1-request@sicmail.epfl.ch Tue Dec 6 14:21:12 1994 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Tue, 6 Dec 94 14:21:05 -0500 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Tue, 6 Dec 94 14:20:51 -0500 Received: from sol.compass-da.com by sicmail.epfl.ch with SMTP (PP) id <04278-0@sicmail.epfl.ch>; Tue, 6 Dec 1994 18:35:49 +0100 Received: from adhara.columbia.compass-da.com (adhara.columbia.compass-da.com [162.17.30.14]) by clsi.columbia.compass-da.com (8.6.9/8.6.9) with ESMTP id MAA06552 for <1076-1@epfl.ch>; Tue, 6 Dec 1994 12:35:06 -0500 From: Peter Liebmann Reply-To: peterl@compass-da.com Received: (peterl@localhost) by adhara.columbia.compass-da.com (8.6.9/8.6.9) id MAA04890 for 1076-1@epfl.ch; Tue, 6 Dec 1994 12:38:43 -0500 Date: Tue, 6 Dec 1994 12:38:43 -0500 Message-Id: <199412061738.MAA04890@adhara.columbia.compass-da.com> To: 1076-1@epfl.ch Subject: Minutes of the 4th LAT meeting Minutes of the 1076.1 Language Architectural Team Meeting Columbia, MD November 16 - 19, 1994 I. The meeting The fourth meeting of the Language Architectural Team (LAT) was held at Compass in Columbia, MD. The attendees were: NAME Company E-MAIL Dan Damon (Wed, Fri) Mentor dan_damon@mentorg.com Ernst Christen Analogy christen@analogy.com Alain Vachoux EPFL vachoux@leg.de.epfl.ch Dominique Rodriguez Anacad domino@anacad.de Jacques Rouillard (Wed) ESIM rouillard@acm.org Richard Trihy Cadence trihy@cadence.com Howard Ko Mentor howard_ko@mentorg.com Jean-Michel Berge (Wed, Sat) CNET berge@cns.cnet.fr Peter Liebmann Compass peterl@compass-da.com Ken Bakalar Compass kenb@compass-da.com Oliver Fischer-Binder (Fri,Sat) Bosch Olli.Fischer@rt.bosch.de The notes were compiled by S. Peter Liebmann. II. Day one November 16 We began with a review of the last minutes (Sept. 23, 1994) in order to identify errors and list open issues. Below is a list of issues. In the list I make reference to the various sections of the previous minutes in quotes (eg. "III.2a" is section III, subsection 2a of those minutes). 1 - LIST OF ISSUES FROM LAST MINUTES: "II.1": Open issues We agreed on the need to have a separate list of open issues. They should not serve as a base for the discussion, but rather serve as checkpoints to validate when the ongoing discussion resolve them. "II.3": Working guideline for this and future meetings - Ken: We need to discuss the relevance of the VHDL'93 guidelines to our effort. "III.2a": Semantics of Procedurals - Variables - Ken and Richard: Discuss SpectreHDL's descriptions in terms of variables, equations etc. - Implicit equations in procedural "III.2b": Semantics of Procedurals - Quantities - Ken: Restructure set of rewrite rules - Ken: Propose using a constructive definition for procedurals rather than one which states that we somehow find a solution then show that it is correct. - Ernst: over/under specification with IF statements "IV.1": How to define the system of equations we wish to solve - Jean-Michel: Concept of the number of equations must be solved - Alain: The mention of the Jacobian here assumes implicitly an iteration based simulator. Solvability conditions for non-linear DAEs should not depend on this. - Ernst: Dynamic loop has problems - Do we need them? "IV.2": Analog drivers - Ernst: This is an issue - Observation by Ken: Do we need a new way to define them? "IV.4": Contributions and branches - Dan: Conservation in a model - Observation by Ken: We should not write syntax and then say what it means. - The whole issue of contribution - Jean-Michel: we need a glossary to define terminology. General comments: - Howard: We need a compiled list of open issues. This was given as an action item to Ernst. - Ernst: The minutes should have a summary list of action items at the end. 2 - CORRECTION AND COMMENTS - FOR LAST MINUTES: "III.2b": Semantics of Procedurals - Quantities - Who are "a lot of people" who complain about restrictions in procedurals? - I used "case" in the example and "cond" in the explanation!! "IV.1": How to define the system of equations we wish to solve - Jacobians should not be a necessary condition (some simulators may not use them) 3 - KEN'S TALK on quantities, types, nature, terminals and nodes Ken's talk generated six issues and a request which are listed below. The discussion of the issues follows. A) REQUEST: Jean-Michel: Please put version numbers on all documents of this type since they are working documents. B) ISSUES: 1) Jean-Michel: Compatibility of the 2 subtypes of nature - is there a possibility of different floating point types. 2) Dan, Howard: Did not like the terminology of left and right quantities. - Also, how can one access total current contribution to a terminal? 3) Dan: Are all quantities unknowns in the DAEs 4) Jean-Michel: Since branch was used in the definition, should it be defined. 5) Dan: Are quantities polymorphic or floating point 6) Jacques: Quantity as an object may have consequences on subprograms. C) DISCUSSION: 1) Compatibility of nature subtypes Three cases were discussed: Case 1: Both real - compatible Case 2: different subtypes of same base type - a range check will be needed. Case 3: different base types: - It won't be possible to multiply (for example) voltage and current. - Dimensional analysis? Monitor MHDL effort STATUS: issue resolved except for an action item for Ernst about MHDL - He will post information about MHDL's dimensional analysis on the reflector. 2) Should we replace left and right through and across quantities with positive and negative? - Ernst: care must be taken when direction is added because of common practice (SPICE etc.) - Agreed: Change left and right to plus and minus - What about total contribution of a through quantities to a terminal: Ken: along with t'ref we could add t'con which is the sum of all "plus" through quantities minus the sum of all "minus" through quantities contained in terminal t. - Dan: can one get t'con from outside the design entity? - Ken: We can probably construct a mechanism, for example, the ability to provide interface quantities solves the problem functionally. - Ernst: Where would t'con be needed in a model? It is clear that it is of interest to the designer, but does the modeler need it? We must distinguish between language and tool issues. - Dan: Does not like the idea of carrying another quantity so the interface can pass this parameter. - Agreed: If one probes a value, it is up to the tool. If another model needs this information, it has language implication (ie. how to pass total contribution to a higher level). STATUS: "plus" and "minus" agreed upon, probe still an open issue. 3) Quantities vs. unknowns - Is Q an unknown in the equation Q == 3;? - Alain: what about sources? - Ken: They are unknowns - one equation with one unknown. STATUS: Resolved. - A tool can optimize the set of equations to solve, i.e. it can extract quantities whose values are known without computation (e.g. Q == 3) in order to minimize the size of the set of equations to solve during simulation. From the LRM perspective, however, all quantities are unknowns to solve for. 4) Do we need a branch definition? - Should we have a glossary rather than semantic definition? - Ken: branch is explanatory rather than a definition and should be in a glossary or a tutorial. STATUS: no further discussion, so resolved (for now). 5) Polymorphism? - Richard: Too much emphasis is placed on complex quantities. - Ernst: This must be considered together with interpretation domain. - Two minor uses: - specify a source in the freq. domain - linear manipulation STATUS: This discussion depends on the interpretation domain. We should discuss semantics first without an ID then with one, so this is deferred. 6) Subprogram Jean-Michel: - we would need attributes of quantities in an analog subprogram. - We also need a new way to encapsulate a relation since we have simultaneous equations (analog subprograms are encapsulated differently than digital subprograms). Ernst: We may need quantities with mode in and out STATUS: deferred 4 - Guidelines - How do they apply to analog. We went through the list of VHDL '93 guidelines to see how they apply to AHDL. NOTE: These are only guidelines which one should aim for. They are not rules (Jean-Michel). 1) Upward Compatibility - The exceptions are the new keywords - Investigation is under way about changes to package standard 2) Preserve Strong Typing - There was no special consideration for analog - Ken: We cannot violate this rule in our extensions! 3) Separate Declaration and Functionality - Unknowns explicitly declared (this is sometimes violated as in S'event) - Do not infer functionality from a declaration (eg. to assign semantics to a name - VCC and VEE have a meaning to a designer but they should not have any meaning in the language). - declaration before use 4) Unification of Timing Semantics - Must convert analog to digital time at a/d and d/a interface (this is an open issue). 5) Preserve Determinism - run twice with same description, get same results: - may be a problem in analog (bi-stable circuits, polynomials, etc.). - multiple solutions possible (0, 1, many, infinite). - Richard - one solution is to have a test set. - May need a quality of conformance factor to measure errors. - This is outside our scope. 6) Preserve Generality - Technology/methodology independent - Make what you add as general as possible but not more general (do not add a new feature for each little problem) 7) Preserve Scope of VHDL (Gate to System) 8) Preserve intermixed abstraction levels - analog/digital behavioral/structural in same design unit. 9) Preserve Concurrency - simultaneous equation - this is stronger that concurrency This guideline is satisfied since VHDL-A will contain all the digital stuff from VHDL'93. 10) Preserve and Improve Consistency - User should be able to guess syntax - make the syntax and semantics as understandable as possible (we should try to damage this guideline as little as possible). 11) Preserve and Improve Portability - Quality of conformance 12) No Application-specific Packages - Not put analog constants in the LRM - We should organize what to put in analog packages - There was a discussion on our relation with package standard ... should we have a library ASTD? 13,14) Minimize Implementation Impact, Maximize Implementation Efficiency - Keep implementation in mind (VHDL people put too much off on implementation) NEW GUIDELINES FOR ANALOG: ------------------------- 15) Distinguish between the language, modeling and tool issues/aspects. Let users make choices - don't limit modeling capability: - inconsistent behavior is a modeling issue (eg. a pole in the right hand plane) 16) Ease of usability - make the language as obvious as possible - minimize modeling complexity 17) Constructive rather than propositional definitions - define how to build something, not just that it is. III. Day two November 18 Ernst followed up on an action item of the first day and presented a preliminary list of open issues compiled from previous meeting minutes. - Ken: (paraphrased by Ken) The list is a check list of items that need to be covered, but not an outline for discussion. The outline for discussion has to be organized along other lines. Because it is just a check list, we should not spend too much time explicating the list items. - We should update the list by adding items and checking items off. However, a detailed analysis of each item in the list is a waist of time. - We will keep the list as an internal document but it is available for anyone to look at. AGENDA: - Go over action items - We should keep in mind: we are working for a constructive rather than propositional description of semantics. - constructive description are building blocks ... they describe underlining machinery and how pieces work together. 1. Further discussions on Ken's talk: a) Dan presented slides on a terminal rather than a branch approach to AHDL. His concerns were: - Modeling non-conservative systems. It was stated that physical systems are conservative, and that branches to ground could be used to represent non-conservativism. - Do we need to observe currents from outside a model as well as inside. This is an action item for Dan. b) Explicit declaration of quantities Dominique had concern about composite terminals. For example, if one has an entity where the number of terminals is determined by a generic, how does one declare the through and across quantities using Ken's notation. entity e is generic(n : integer); port(Terminal x : electrical_array(1 to n)); end; Ken proposed a solution claiming this is just a naming convention problem. For example, if one has through quantities x(I) through x(I+1) I = 1 ... n-1 one could write: quantity q through x(1 to n-1) to x(2 to n); Extension of the Nodes and Quantities paper to cover composites is an action item for Ken. c) Further clarification of nodes and terminals: If a terminal is declared in an architecture, it is a node with the sum of all its positive through quantities minus the negative ones equal 0. It a terminal is an interface, the sum need not be zero. Clarification by Alain: a node is not a new object in VHDL-A, it is only a terminal in disguise. d) Formally adopt Ken's definitions We should adopted Ken's formalism provisionally. If a better set comes along they will be substituted. 2. Relation discussion. We next decided to discuss relations. The discussion mainly focused on what a relation is and how to describe the various forms in the LRM. a) What is a relation: - To define a set of DAEs. - Richard: also to describe sampled data systems - we agreed to leave out this use. - To report and monitor a system. b) Use of a relation: two possibilities - A way to code DAEs - A set of instructions c) How to describe a relation: - Do we take an iterative (algorithmic) approach - Ken suggested: stop at level of DAEs - we should assume we can find a solution so let us not try to explain how. - We may use a translation step which maps to some intermediate form with semantic meaning. (see concurrent conditionals in the LRM). - Use a constructive approach to define the concepts. - Ernst: use the word "constraint" instead of "equation" for the pieces defined in a relation, use "equation" for the DAEs solved for by the simulator, to avoid confusion. No conclusion was reached. d) where do we agree? - The whole AHDL world is a set of DAEs - ie. there is no other way to describe an analog system in AHDL. - We need implicit equations at least in fixed point form ( x = f(x) ) - We need functions - DAEs are constructed from the constraints defined in the relations, together with the topological constraints - There are three representations that can be distinguished: - the representation of constraints at the user level - the intermediate representation to which all user written code is rewritten (in order to define the semantic meaning of the statements in the language) - the representation needed by a tool for simulation The first two are independent of a formulation method. They are the ones we must be concerned with. e) Attempt at relation definitions - Set of rules which transform into simultaneous DAEs We looked at the following example which generated a general discussion which exemplifies the different opinions in how to write an LRM description of sequential assignments: - Conditional constraints: describe semantic equivalent: if (cond) use constraint1 == 0; else constraint2 == 0; endif; Ernst says this should translate into the single expression: constraint1 * cond + constraint2 * (!cond) == 0 -- this is an equation to stay consistent with the distinction between constraint and equation. Richard asked what was wrong with the if-then-else description which we know how to implement. Why translate? QUESTIONS: - what level should the language aim at tool builders? - Do we consider an iterative simulator? - Should certain bad models like the sqrt of a negative number be a modeling problem or simulator problem - could this cause portability problems? - Do we build ALL the equations at elaboration? - Can procedurals create equations? - Alain: Maybe we should consider no quantity assignments in a procedural (only variable assignments) - may need a time derivative of a variable. RESOLUTION: These are all open issues and the best way to proceed is to reach a common ground. IV. Day three November 19 1. Documents LAT Documents will be provided over E-Mail. Alain raised the following point: LAT documents are primarily intended to people involved in their writing and people intended to attend LAT meetings where such documents are discussed. Once a version is frozen, i.e. agreed by the LAT to be complete, it can be provided to any 1076.1 member for comments or information. We may choose to store working (non-frozen) LAT documents in the ftp archive site. We discussed the several documents which are in preparation: - Quantities (some changes needed) - Simulation cycle and issues (analog-digital, d/a, time) - Relations - interpretation domain - packages (what is in LRM and Math package) - we should contact Hal Carter, he could possibly provide info. - Predefined language environment - TYPE electrical - ANOW - Constants 2. White papers We decided that with all the open issues, the most efficient way to proceed is through white papers similar to the one presented by Ken. There are two kinds of white papers: - Synthesis papers that provide formal definitions close to what we could find in the LRM. - Analysis papers that provide investigation on a specific subject in order to determine possible solutions. a) The following will be written for the next meeting: - Synthesis papers: - Relations and interpretation domains - Dominique, Serge, Alain and Richard - Quantities, natures and nodes - Ken - Simulation Cycle, A/D & D/A interactions, unified model of time - Ken - Analysis papers: - DC analysis and initialization - Ernst - Number of equations vs. number of quantities - Ernst - SPICE compatibility issues - Peter - statistical analysis - deferred - Both synthesis and analysis papers: - Predefined language environment - Jean-Michel and Alain b) Guidelines: - Semantics should be defined consistently and without reference to syntax. - Examples may be used to illustrate the definition but should not be part of the definition. The examples should be understood in terms of the semantics in the definition. - An outline should be sent to chair of LAT to determine if one is going in the wrong direction or if their is overlap. c) Contents of white papers 1) relations and quantities (some overlap) - systems with multiple solutions - quantity - one value? - composite quantity - Richard: Why we could not simply extend variables "to have a past", thereby by voiding the need for another object that Ken called "Free Quantities". - Jean-Michel: Variables may be thus extended, but we will also have to provide variables without a past. - In general, different objects get values in different ways variable - sequential quantity - simultaneous signal - delayed 2) DC analysis - What designers do and why - implications of what they do and why 3) Number of equations - conditions to solve quantities - determined during analysis or at elaboration (we would like to catch errors as soon as possible) 4) Predefined language environment - What is the current environment - What is possible and not possible to extend to STD. - What goes into package - composition of different packages 5) SPICE - .MODEL - How to accomplish similar effects in AHDL - unspecified parameters - Structure semantics - Netlist - Link to external models (Built into SPICE) - control: .DC, .OPTIONS ... - Distinguish between types of control - behavioral aspects (.IC, hints to help convergence). - Node collapsing - Issues with models in SPICE - Transmission lines - K model 6) Simulation cycle - Need DC operating point - reset - possibility part of digital process - The reset statement is overloaded with two aspects, it has both declarative and executable semantics. i.e. it violates guideline 3. - D/A conversion - explore possible D to A forms - A/D conversion - unified model of time? (may need a new white paper) - process execute with respect to changes in analog - event generator - how many: is the only one we need is when a quantity crosses zero? (f(qi) == 0) - Jean-Michel: call analog process analog block since it is not sequential - Ernst: do not let user define algorithms (ie. let analog event mechanism do it) - user need not have access to last time point - do not add features to the language for the sole purpose of user defined event generators d) Deadlines on white papers: - Formal outline Dec. 16. To be communicated to Ernst. - First draft (or a report) by January 2. To be communicated to Ernst. - Pass on to someone else if you are not making progress. - Paper by Jan. 16. To be communicated to all attendees of the next meeting. 3. Next meeting The next LAT meeting will be held from January 31, 1995 to February 3, 1995, in Lausanne, Switzerland. Alain Vachoux is in charge of local arrangements (hotel, meeting place). Please let him know by January 16, 1995 if you will attend. His email is alain.vachoux@leg.de.epfl.ch. 4. Summary of action items: a) Ernst: compiled list of open issues(II.1) - partially accomplished on day 2. b) Ernst: post information about MHDL's dimensional analysis on the reflector (II.3.c.1). - Done c) Dan: Do we need to observe currents from outside a model as well as inside (III.1.a) d) Ken: composite terminals (III.1.b). e) Dominique, Serge, Alain, Richard, Ken, Peter, Ernst, Jean-Michel: White papers (IV.2.a) From 1076-1-request@sicmail.epfl.ch Tue Dec 6 16:23:10 1994 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Tue, 6 Dec 94 16:23:01 -0500 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Tue, 6 Dec 94 16:22:40 -0500 Received: from sol.compass-da.com by sicmail.epfl.ch with SMTP (PP) id <07635-0@sicmail.epfl.ch>; Tue, 6 Dec 1994 21:30:08 +0100 Received: from [162.17.30.151] ([162.17.30.151]) by clsi.columbia.compass-da.com (8.6.9/8.6.9) with SMTP id PAA07698 for <1076-1@epfl.ch>; Tue, 6 Dec 1994 15:29:24 -0500 Date: Tue, 6 Dec 1994 15:29:24 -0500 Message-Id: <199412062029.PAA07698@clsi.columbia.compass-da.com> Reply-To: kenb@compass-da.com X-Sender: kennyb@clsi Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: 1076-1@epfl.ch From: kenb@compass-da.com (Kenneth Bakalar) Subject: Semantics of Quantities, Terminals and Nodes Semantics of Quantities, Terminals and Nodes -------------------------------------------- 0. REVISION HISTORY Revision 1.0 29 Nov 94 As approved by LAT on 19 November 1994 1. DEFINITIONS 1.1 Quantity; Quantity Equivalence Set A quantity is an object that takes on values of a floating point subtype. It represents an unknown in a set of simultaneous differential-algebraic equations (DAEs) with time or frequency as the independent variable. A set of DAEs is denoted by some combination of statements involving the names of quantities. A quantity equivalence set is a set of two or more quantities. A quantity may belong to at most one quantity equivalence set. 1.2 Nature; Across Subtype and Through Subtype (of a Nature); Terminal; Branch Quantity; Reference Terminal A nature is a pair of subtypes of floating point types. The subtypes are called the across subtype and through subtype of the nature. A quantity may be a branch quantity. A terminal is a set of branch quantities. Each terminal has a nature. The across subtype and through subtype of a terminal are those of its nature. Each nature is associated with a unique terminal called the reference terminal of that nature. The nature of the reference terminal of a nature is the nature itself. 1.3 Plus Terminal and Minus Terminal (of a Branch Quantity) Each branch quantity is a member of two terminals of the same nature called the plus terminal and the minus terminal of the branch quantity. Each branch quantity is either an across quantity or a through quantity. The subtype of an across quantity is the across subtype of the two terminals to which it belongs. The subtype of a through quantity is the through subtype of the two terminals to which it belongs. 1.4 Reference Quantity (of a Terminal); Contributing Quantity (of a Terminal) Each terminal includes a reference quantity. The reference quantity of a given terminal is an across quantity whose minus terminal is the reference terminal of the nature of the given terminal. The reference quantities of the terminals of a node (1.6) are the members of a quantity equivalence set. 1.5 Plus Contribution, Minus Contribution and Contribution Expression (of a Terminal) The plus contribution of a terminal is the set of through quantities whose plus terminal is the given terminal. The minus contribution of a terminal is the set of through quantities whose minus terminal is the given terminal. The expression representing the sum of the members of the plus contribution, minus the sum of the members of the minus contribution is the contribution expression of that terminal. 1.6 Node; Conservation Expression (of a Node); Reference Node; Free Node A node is a set of terminals of a single nature. A reference node is a node containing a reference terminal. A free node is a node not containing a reference terminal. Each terminal is a member of exactly one node. The conservation expression of a node is the sum of the contribution expressions of the terminals of the node. 1.7 Additional Constraints The DAEs denoted in the text are extended with additional equations before the system is solved. These are: 1) an equation for each across quantity constraining it to be equal to the reference quantity of its plus terminal minus the reference quantity of its minus terminal, 2) an equation for each free node constraining the conservation expression of the free node to zero, and 3) equations constraining the members of each quantity equivalence set to be equal to each other. 2. RATIONALE Section 1 defines the interrelationships within a collection of semantic categories. The definitions impose a constraint on the rest of the definition of VHDL-A, but do not dictate the syntax, naming and declaration conventions, scope rules, static semantics, elaboration semantics, the dynamic semantics of equation definition and so on. We use the semantic categories "object" "type" and "subtype" from VHDL 1076, and add the semantic categories "quantity", "terminal", "node" and "nature". We have tried to lay the ground work for meeting the design objectives in a pleasing way while changing VHDL 1076 as little as possible. We did not discover any important case in which these two aims were irreconcilable. We believe that a language meeting all of the design objectives can be designed on the basis of these definitions. The work reflects ideas from the LESs, the DOD, the reflector mail archive and from many helpful discussions with members of the committee. We have not cited particular sources. If you recognize your ideas, remember that the most sincere form of flattery is imitation. This paper covers almost all of the ground (except for the concrete syntax!) of LESs A, B, F, G, H, O and OO, as I hope will become apparent from the rationale. We have not defined "analog drivers" (LES B) nor the static semantics of LES G (there are some suggestions about static semantics in this rationale). The definition is intended to be self-contained and unambiguous. The rationale explains the definition and draws out some interesting consequences, but it is _not part of the definition_. We discuss in detail arguments and definitions from the existing LESs at some points to highlight the differences between this approach and previous approaches. We also make some suggestions with regard to the solution of language design problems that lie outside of the scope of the definitions. 2.1 Nomenclature The meanings ascribed to certain names are different from the meanings in the LESs for the same names. Use the following map with great caution, because the equivalencies are only approximate. Remember that the definition is self-contained and does not rely on these approximations: NAME USED IN DEFINITIONS ~= LES NAME quantity ~= quantity, field of node, field of pin (?) terminal ~= node, pin, terminal node ~= set of "formal-actual associations", sometimes node quantity equivalence set ~= combination of "couplings" 2.2 Equations The definitions assume that a set of DAEs is denoted by some combination of statements involving the names of quantities and other conventional VHDL objects. The definitions do not require these statements to denote the same equations at all values of the independent variable nor do they constrain the number of equations. It follows for these (and other) reasons that the system may not have exactly one solution. The definitions here work only when a unique solution exists because a quantity is assumed to have exactly one value. We should choose a notation for DAEs that makes it as easy as possible for the simulator to report this error condition to the user. We want to catch as many cases as possible by local static analysis; and failing that, by global static analysis (after elaboration); and failing that at simulation time. I think there will be cases that are left over even if we do a good job at this -- those that aren't anticipated by the language definition, possibly including implementation dependent cases. It would be desirable if the error report allowed the designer to quickly localize the problem to a particular area of his code. The unstated principle behind section 1 is to describe the whole VHDL-A world in terms of building a set of DAEs for evaluation. Some equations are denoted by the coder, some are a consequence of the design unit topology the coder has created and some are a consequence of the conservation laws. An implementation is free to use some compact formulation technique (and maybe more than one, depending on circumstances) to increase the time/space efficiency of evaluation. 2.2 Quantities Quantities are the unknowns in the DAEs. The definitions above unify the informal notions of "quantity" on the one hand, and "node" or "pin" on the other, used in previous discussions in the mail archive and the existing LESs. Quantities are defined with the intent that the name of a quantity can be used in any expression where a value of the type of the quantity is allowed in VHDL 1076. No other new value-bearing object is required. It may be helpful for some readers to think of a terminal as a composite object whose elements are quantities. However, this notion is not needed for the purposes of definition. Quantities can be viewed as continuous functions of the independent variable ("waveforms") that are observable within VHDL-A, and by the human user of the simulator, only at discrete values of that variable. The specification of which times (or frequencies) are among the discrete values is a complicated business, depending on the desires of the designer, the exigencies of the solution algorithm selected by the tool builder, and additional information embedded in the text by the model writer to increase the probability that the solution algorithm will "behave well" as quantities achieve critical boundary values. This topic will be dealt with in a subsequent paper. The reference quantity for a terminal is, in electrical systems, the voltage at the terminal with respect to ground. The current contribution of the terminal (to the node in which it is interconnected with other terminals) is defined as the difference of certain sums of quantity-members of the terminal. Those members are the individual current sources. We may wish to give the reference quantity and the contribution expression names in the concrete syntax; for example, given a node n1, then, in an equation, "n1" or "n1'ref" might denote the reference quantity and "n1'con" the contribution expression. In each case, however, it is the underlying quantities that are value-bearing, not the terminals. The notion of quantity also satisfies the requirements for a non-conservative "coupling" between components that is parallel to but separate from terminal-to-terminal connections. Assume that the structural semantics of VHDL are extended in VHDL-A with definitions of "interface quantity" and "quantity association" paralleling the existing definitions of "interface signal" (port) and "signal association". Then each quantity is a member of the quantity equivalence set that includes all quantities with which it participates (as formal part or actual part) in a quantity association. In effect, the formal and actual parts act as if they are different names for the same quantity. Membership in a quantity equivalence set can be viewed as an equivalence relation, and so is transitive; if A is a member of the same quantity equivalence set as B, and B is a member of the same quantity equivalence set as C, then A is a member of the same quantity equivalence set as C. We may decide to give modes to interface quantities (for example, in, out, inout, read-only). In VHDL, modes restrict (statically) where the name of an object can be used; for example, in an expression, on the left hand side of an assignment, at the place of the actual in certain element associations. Whether this sort of restriction is useful will become more apparent when we decide how DAEs are formulated (the "relation" in LES parlance). We could add modes to help the modeler avoid mistakes. Adding modes adds no new functional power to the language -- it only adds restrictions on what formulas are allowed. 2.3 Types and Quantities The definition allows the designer to declare subtypes voltage, current, flux and so on of floating point types and use these to declare quantities. A pair of such subtypes -- a nature -- is part of the definition of a terminal. Branch quantities get their subtypes from terminals. In VHDL, operations are defined on types, not subtypes, so the designer can write meaningful expressions that multiply, divide, add and subtract quantities of different subtypes of the same type. To put it another way, objects of the same type (but possibly different subtypes) are interoperable. A subtype imposes one additional constraint; before a value of the type is assigned to an object of the subtype, the constraint is checked and an error message is issued if the value fails the test. Subtypes divide a collection of interoperable quantities into named subsets to which the designer can add additional user-defined (or VHDL-A defined?) attributes. This is analogous to the use of the subtype to bear the signal resolution function. It would be natural to attribute a subtype with the name of the unit for the physical values it represents in a form suitable for the waveform display of the simulator: attribute unit of subtype is string; attribute unit of current: subtype is "amp"; The attribute declaration and attribute specification could appear in the package declaring the natures and types used in the model. Since a quantity may be any floating point type, the universe of quantities can be divided at the designer's option into non-interoperable subsets; the designer will be prevented from adding (for example) a quantity of one type to a quantity of another type without explicit type conversion or a new, overloaded addition operator. He could define, for example, a type "kirchhoff" with subtypes "voltage" and "current", and a type "newton" with subtypes "force" and "displacement". Finally, the designer may choose the subtypes of a nature from different types. In that case, the across quantities and through quantities of terminals of that nature are not interoperable. He could define, for example, a type "voltage", a type "current" and a type "resistance". He could then use subtypes of "voltage" and "current" to define a nature "electrical". Now expressions involving both the across and through branches of a terminal of nature "electrical" will require overloaded operators or explicit type conversions. Here is the declaration of such an overloaded operator: function "/" (I: current; E: voltage) return resistance; The definition of quantity and nature must be extended to take into account the design objectives that lead to the requirement for composite quantities, terminals and nodes. This has not net been done. With regard to scalars, the preceding paragraphs have demonstrated that the existing type system of VHDL (as trivially extended with "nature") will provide the flexibility needed by VHDL-A until and unless a complete dimensional analysis system is defined. 2.4 Numerical Precision and Initial Values In VHDL 1076-1993, the precision of any floating point type and in particular of type real (the only predefined member of the class) is implementation defined, with a set lower limit (6 digits). The type class floating point in a VHDL-A implementation will need higher minimum precision to prevent numerical problems. We have several options for making higher precision floating point types available: 1) Give all floats the maximum precision (including type real) 2) Leave type real at 6 digits and make all other floats maximum precision 3) Leave type real at 6 digits, introduce type double at 16 (or whatever) digits, and make all others 6 digits. 4) Introduce syntax to specify precision: e.g., "TYPE KIRCHHOFF IS DIGITS 16 RANGE...;" Option 1 is the simplest and requires no change to VHDL 1076-1993 except the increase in minimum precision of the floating point class. If we really need control, lets go all the way to option 4; we can steal the syntax and semantics and rationale straight out of ADA (well, almost...). The default initial value of an object of kind quantity, in the absence of an explicit value supplied in its declaration , should be zero. This will make a large subset of models work even if explicit initialization is neglected. I mention in passing that we have not yet a complete definition of what the simulator is supposed to do with the initial values of quantities, nor what to do about initial conditions. 2.5 Quantities in the Frequency Domain Frequency domain analysis (in which quantities take on complex rather than real values) can be taken into account in the following way. Extend the definition of the VHDL class of floating point types to be mathematical real numbers in the time domain but mathematical complex numbers in the frequency domain. This will always yield a consistent interpretation without the additional apparatus required by explicit dimorphism. In digital VHDL, which always executes in the time domain, floating point numbers represent mathematical reals as they do now. If complex arithmetic is required in the time domain a package (such as the new IEEE math package) containing the appropriate types, operators and functions may be used. We could, alternatively, define a new class of types "dimorphic floating-point" (DFP) and say that they are closely related to types of class "floating-point" (FP). This is probably where the discussion in the LESs is headed towards when it talks about type "analog". Now we can define DFP types (for example, "analog", "newton", "kirchhoff"). But what do we do about closely-relatedness in the frequency domain? The natural thing to do would be to treat FPs as if they are extended with an imaginary part when operating in the frequency domain. But that would make them indistinguishable for DFPs in either domain. So why introduce the second class at all? I understand that the small signal frequency domain analysis requires that all the operators in expressions be interpreted in a peculiar way; this subject remains something of a mystery to me, and I look forward to an exposition of the topic from one our analog simulation experts. It has been argued that this specification will lead to inefficient implementations, because space must be allocated for complex numbers when only the real part is used. It is hard to imagine a model in which the most inefficient implementation of this scheme (that, say, doubles the amount of storage required for quantities) would have any practical consequences. In such a giant, other considerations (for example, the size of the solution matrixes) would dominate. 2.6 Nature Nature as defined here is quite different from "nature" as defined in the existing LESs. A nature is not a type. It is a composite of two floating point subtypes. Only terminals have a nature, and only in order to transmit the subtypes to the branch quantities of the nature. A branch quantity has a floating point subtype determined by the nature of its terminals. A branch quantity does not have a nature. Think of a nature as the key to an interlocking structure of static semantic constraints on the subtypes of quantities. The definitions provide the basis for a concrete syntax in which it is not possible to make inadvertent errors in specifying the types of branch quantities. A terminal "has" a nature, but a terminal is not an object; it is a collection of (quantity) objects. Those objects are of one of two subtypes -- either the across or the through subtype of the nature. The subtype of a branch quantity must "agree "(in the sense defined) with the types of the natures of its terminals. The definition requires a reference terminal -- a ground -- for each nature. The declaration of the nature will specify what terminal is the reference terminal. The name of the reference terminal must be visible anywhere a terminal of the given nature is visible. The ability to declare terminals in packages combined with existing rules concerning scope and visibility will suffice. No special provision for creating "reference nodes" is therefore required. 2.7 Branch Quantities, Terminals, Nodes and Kirchhoff's Current Law Nodes are created when terminals are connected with other terminals in a structural description (an unconnected terminal is also a node). The extensions to the syntax and structural semantics of VHDL to include these connections should closely parallel the similar definitions for signals. One important difference is that terminals have no "directional" mode -- they are not in, out or inout. But the original designers of VHDL, in their prescient wisdom, have left us a forth mode -- linkage -- specifically to serve analog connections! We can use the mode designation linkage to mean "no mode at all". Probably type conversion functions won't be allowed. Assume that "interface terminal" and "terminal association" are defined by analogy with interface signal (called "port" at some places in the LRM) and signal association. Then each terminal is a member of the node that includes all terminals with which it participates (as formal part or actual part) in a terminal association. The definition of terminal does not restrict its use to the interface between components. It will prove useful to declare terminals in any place where signals may be declared. Each through quantity implicitly defines a topological branch of the circuit being modeled. There is no restriction on the number of through quantities that may span a given pair of terminals, and hence no restriction on the number of parallel branches connecting two terminals. In VHDL, objects, types and the like come into existence when their declarations are elaborated. We can therefore say that a branch comes into existence when the declaration of a through quantity is elaborated. There is no restriction on the number of across quantities that may span a given pair of nodes. All such across quantities are constrained to be equal (or to be equal and of opposite sign) by definition 7-2, which states that an across quantity is simply the difference of the reference quantities of its terminals. The reference across quantity of a terminal comes into existence when the declaration of the terminal is elaborated. The definitions provide a framework in which conservation semantics can be statically enforced. It is easy to envision a syntax in which, for example, it is not possible to inadvertently notate a current contribution to only one node when the intention is to make equal and opposite contributions to two different nodes. The implicit equations of 1.7 are necessary and sufficient to define the conservation of charge semantics imposed by Kirchhoff's law or its analogy in other conservative physical models. __________________________________________________________________ Kenneth Bakalar voice +1 410 992 5700 ext. 1204 COMPASS Design Automation fax +1 410 992 3536 5457 Twin Knolls Road email kenb@compass-da.com Columbia MD 20845 USA __________________________________________________________________ From 1076-1-request@sicmail.epfl.ch Tue Dec 6 17:47:09 1994 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Tue, 6 Dec 94 17:47:05 -0500 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Tue, 6 Dec 94 17:47:00 -0500 Received: from psi.com by sicmail.epfl.ch with SMTP (PP) id <09031-0@sicmail.epfl.ch>; Tue, 6 Dec 1994 23:21:58 +0100 Received: from analogy.com (analogy.analogy.com) by psi.com (4.1/2.1-PSI/PSINet) id AA22121; Tue, 6 Dec 94 17:21:46 EST Received: from miller.analogy.com ([149.117.72.253]) by analogy.com (4.1/Shared_Spool_1.3) id AA11737; Tue, 6 Dec 94 14:09:39 PST Received: from satyr.analogy.com by miller.analogy.com (4.1/SMI-3.2) id AA12548; Tue, 6 Dec 94 14:22:45 PST Received: by satyr.analogy.com (5.0/SMI-SVR4) id AA17151; Tue, 6 Dec 1994 14:21:36 +0800 Date: Tue, 6 Dec 1994 14:21:36 +0800 From: christen@analogy.com (Ernst Christen) Message-Id: <9412062221.AA17151@satyr.analogy.com> To: 1076-1@epfl.ch Subject: LAT documents Content-Length: 1708 As you know, one of the Language Architecture Team's responsibilities is to address open issues in language design. This includes getting consistency into the language design, which was difficult to obtain with 4 different LES groups. In order to document this aspect of its work the LAT has decided on a series of white papers. These white papers address various aspects of the language architecture in formal and concise language. A fundamental characteristic of these white papers is that they intend to provide information (results of analyzing a problem, semantic definitions etc.) without referring to syntax. This makes it possible, in a separate step, to find syntax that is adequate to express the semantics. The first example of a white paper was submitted earlier today by Ken Bakalar: "Quantities, Terminals and Nodes". This paper was adopted at the last LAT meeting as a basis for future work. The minutes of the last LAT meeting (also submitted today) also provide information on the series of white papers that are planned. Note that white papers do not replace LESs, but they provide a consistent framework within which the LESs can exist. The Language Architecture Committee summarizes its results also in other ways. You all have seen LAT meeting minutes, which describe the discussions undertaken and the decisions made during LAT meetings. So far we had four meetings, and the minutes of each meeting have been published. Further, the LAT maintains a Language Architecture Document and a Glossary. Both these documents are currently under revision, based on the work done by the LAT so far. They will be sent to the reflector once they are more stable. Ernst Christen Chair LAT From 1076-1-request@sicmail.epfl.ch Thu Dec 8 05:56:56 1994 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Thu, 8 Dec 94 05:56:45 -0500 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Thu, 8 Dec 94 05:56:40 -0500 Received: from inet-tsb.toshiba.co.jp by sicmail.epfl.ch with SMTP (PP) id <01273-0@sicmail.epfl.ch>; Thu, 8 Dec 1994 11:19:08 +0100 Received: from tis2.tis.toshiba.co.jp (tis2) by inet-tsb.toshiba.co.jp (5.67+1.6W/2.8Wb) id AA22649; Thu, 8 Dec 94 19:12:32 JST Received: from tis10.tis.toshiba.co.jp (tis10) by tis2.tis.toshiba.co.jp (5.67+1.6W/6.4J.6-R05) id AA11422; Thu, 8 Dec 94 19:12:59 JST Received: from eecisa.eec.toshiba.co.jp (eecisa) by tis10.tis.toshiba.co.jp (5.67+1.6W/6.4J.6-MHS-CNTML-R1) id AA18407; Thu, 8 Dec 94 19:13:08 JST Received: from roku.eec.toshiba.co.jp (eecjsf) by eecisa.eec.toshiba.co.jp (4.1/6.4J.6-R1) id AA18551; Thu, 8 Dec 94 19:05:43 JST Return-Path: Received: by roku.eec.toshiba.co.jp (8.6.9+2.4Wb3/3.3W-roku_Master) with ESMTP id TAA04805; Thu, 8 Dec 1994 19:12:11 +0900 From: "VHDL analog mail by (CA1)H.Sasaki 94.1.18" Message-Id: <199412081012.TAA04805@roku.eec.toshiba.co.jp> Date: Thu, 8 Dec 1994 19:25:40 +0900 To: 1076-1@epfl.ch, fischer@dic.k8.rt.bosch.de Subject: (Validation) Help me to write "Trellis Code Modulation" Cc: jvlwg@nttica.ntt.jp Dear all, I am now writing my 4th example: Trellis Code Modulation (without decoder). I feel that analog behaviour controlled by digital behaviour is interesting from descriptional point of view: "digital state" may be refered in analog process in future. (In this example, signal is refered.) I would like to confirm wether behavioral-level interaction of analog/digital will be (or is) allowed or not under current proposal. If possible, I will re-write my description soon: replace in1,in2,c3 signals by digital states. Best regards, ----------------------------------------------------------- -- Hisashi Sasaki, Ph.D. Specialist -- -- BIPOLAR ANALOG DESIGN AUTOMATION, TOSHIBA CORPORATION -- -- 580-1, HORIKAWA-CHO, SAIWAI-KU, KAWASAKI 210, JAPAN -- -- PHONE: +81-44-548-2604 FAX: +81-44-548-8970 -- -- E-MAIL: 000092040542@tg-mail.toshiba.co.jp (office) -- -- PXI04522@niftyserve.or.jp (home) -- ----------------------------------------------------------- ============== TCM description under writing ============== -- TITLE: TCM (Trellis-coded Modulation) -- a rate 2/3 convolutional coded 8PSK scheme -- without demodulator (Viterbi decoder) -- AUTHOR: Hisashi Sasaki, TOSHIBA -- e-mail: 000092040542@tg-mail.toshiba.co.jp -- sasaki@roku.eec.toshiba.co.jp -- DATE: 08.12.94 -- LASTUPDATE: 08.12.94 -- LANGUAGEVERSION: HDL-A v1.1.3a for sun4c, VHDL-A -- CODESTATE: [INVALID] VALID -- HISTORY: -- Initial 21.11.94 [INVALID] HDL-A v1.1.3a for sun4c -- 08.12.94 [INVALID] VHDL-A by "digital state" -- NOTE: As VHDL-A part is not complied yet, it may contain -- syntactical errors... -- -- DESCRIPTION: -- (1) a rate 2/3 convolutional encoder: structual view -- -- +-------+ -- | | -- in1>----------------------------->+c1 | -- | | -- in2>-------------+--------------->+c2 +---> -- | | | -- +-->(T)-->(+)-->(T)---+---->+c3 | -- | t1 t2 | | | -- +---------------------+ | 8PSK | -- +-------+ -- (T)=Flip-flop, (+)=XOR -- -- -- (2) 8PSK signal set: set partitioning as follows -- -- A: 8PSK -- -- @ -- @ @ -- @ @ -- @ @ -- @ -- -- c3=0 c3=1 -- -- A0 A1 -- -- @ O -- O O @ @ -- @ @ O O -- O O @ @ -- @ O -- -- c2=0 c2=1 c2=0 c2=1 -- -- A00 A10 A01 A11 -- -- O @ O O -- O O O O O @ @ O -- @ @ O O O O O O -- O O O O @ O O @ -- O @ O O -- -- c1=0 c1=1 c1=0 c1=1 c1=0 c1=1 c1=0 c1=1 -- -- A000 A100 A010 A110 A001 A101 A011 A111 -- -- O O @ O O O O O -- O O O O O O O O O @ O O @ O O O -- O @ @ O O O O O O O O O O O O O -- O O O O O O O O O O @ O O O O @ -- O O O @ O O O O -- -- -- -- c1,c2,c3 angle -- 000 0 -- 100 pi -- 010 pi/2 -- 110 pi*3/2 -- 001 pi/4 -- 101 pi*5/4 -- 011 pi*3/4 -- 111 pi*7/4 -- -- -- SCHEMATIC: -- -- CODE: -- HDL-A Version v1.1.3a for sun4c -- STIMULI: -- -- EXPECTED_RESULTS: -- Text, Formulas, Curves : Format PROPSAL EPS -- RESULTS: -- SIMULATION_ENGINE: VESIM V2.1.2d -- DATE: 21.11.94 -- RESULT_STATE: INVALID [VALID] -- ... -- PROBLEM_LOG: -- --------------------------------------------------------------------- -- Generator of inputs and Clock for testing --------------------------------------------------------------------- ENTITY tcm_in1 IS PORT(in1 : OUT BIT); END ENTITY tcm_in1; ARCHITECTURE d1 OF tcm_in1 IS SIGNAL in1q : BIT; BEGIN PROCESS BEGIN -- assume symbol interval T is 100ns in1q <= '0', '0' AFTER 100ns, '1' AFTER 200ns, '1' AFTER 300ns, '0' AFTER 400ns, '0' AFTER 500ns, '0' AFTER 600ns, '1' AFTER 700ns, '1' AFTER 800ns, '0' AFTER 900ns, '0' AFTER 1000ns, '1' AFTER 1100ns; in1 <= in1q; L1: LOOP WAIT FOR 100ns; in1 <= in1q; END LOOP; END PROCESS; END ARCHITECTURE d1; ENTITY tcm_in2 IS PORT(in2 : OUT BIT); END ENTITY tcm_in2; ARCHITECTURE d1 OF tcm_in2 IS SIGNAL in2q : BIT; BEGIN PROCESS BEGIN -- assume symbol interval T is 100ns in2q <= '0', '1' AFTER 100ns, '0' AFTER 200ns, '1' AFTER 300ns, '0' AFTER 400ns, '0' AFTER 500ns, '1' AFTER 600ns, '0' AFTER 700ns, '1' AFTER 800ns, '0' AFTER 900ns, '1' AFTER 1000ns, '0' AFTER 1100ns; in2 <= in2q; L1: LOOP WAIT FOR 100ns; in2 <= in2q; END LOOP; END PROCESS; END ARCHITECTURE d1; ENTITY tcm_clk IS PORT(clk : OUT BIT); END ENTITY tcm_clk; ARCHITECTURE d1 OF tcm_clk IS SIGNAL clkq : BIT; BEGIN PROCESS BEGIN -- assume symbol interval T is 100ns clk <= '0', '1' AFTER 50ns, '0' AFTER 100ns; clkq <= '0', '1' AFTER 50ns, '0' AFTER 100ns; L1: LOOP WAIT FOR 50ns; clkq <= not clkq; clk <= clkq; END LOOP; END PROCESS; END ARCHITECTURE d1; --------------------------------------------------------------------- -- TCM Modulator --------------------------------------------------------------------- -- -- 21.11.94 HDL-A version: rather structual description -- ENTITY tcm_mod IS GENERIC ( omega1, -- local osc. mag -- amplitude : REAL); PORT(in1, in2, clk: IN BIT); PIN(m_out : ELECTRICAL); END ENTITY tcm_mod; ARCHITECTURE m1 OF tcm_mod IS SIGNAL t1,t2,t1q,t2q,c1,c2,c3: BIT; -- VARIABLE symbol_start_time, -- time when symbol starts phi, -- bias of pi/8.0 phi1 : REAL; -- signal constelation BEGIN PROCESS BEGIN c1 <= in1; c2 <= in2; t2 <= in2 xor '0'; -- initial c3 <= '0'; -- initial t1 <= '0'; -- initial t1q <= t1; t2q <= t2; L1: LOOP WAIT FOR 100ns; t2 <= in2 xor t1q; c3 <= t2q; t1 <= t2q; t1q <= t1; t2q <= t2; NULL; END LOOP; END PROCESS; RELATION PROCEDURAL FOR INIT => phi := 0.0; phi1 := phi; symbol_start_time := 0.0; m_out.v %= mag*cos(phi); PROCEDURAL FOR DC => m_out.v %= mag*cos(phi1); PROCEDURAL FOR TRANSIENT => IF event(clk) AND clk='1' THEN symbol_start_time := current_time; IF (in1='0' AND in2='0' AND c3='0') THEN phi1 := 0.0 +phi; -- END IF; IF (in1='1' AND in2='0' AND c3='0') THEN phi1 := pi + phi; -- END IF; IF (in1='0' AND in2='1' AND c3='0') THEN phi1 := pi/2.0 + phi; -- END IF; IF (in1='1' AND in2='1' AND c3='0') THEN phi1 := -(pi/2.0) + phi; -- END IF; IF (in1='0' AND in2='0' AND c3='1') THEN phi1 := pi/4.0 +phi; -- END IF; IF (in1='1' AND in2='0' AND c3='1') THEN phi1 := -(pi*3.0/4.0) + phi; -- END IF; IF (in1='0' AND in2='1' AND c3='1') THEN phi1 := pi*3.0/4.0 + phi; -- END IF; IF (in1='1' AND in2='1' AND c3='1') THEN phi1 := -(pi/4.0) + phi; -- END IF; END IF; -- END OF "event(clk) AND clk='1'" m_out.v %= mag*cos(omega1*(current_time-symbol_start_time)+phi1); END RELATION; END ARCHITECTURE m1; -- tcm_mod -- -- 08.12.94 VHDL-A version: -- analog behavior by "DIGITAL state transition" -- -- -- -- -- input / output ==> in2 / c3 (signal set) -- -- -- --------- -- / \ -- | | 0/0 (A00) -- V | -- -- -- STATE:s0 +------+ -- | | -- in1>-------------------->+c1 | -- | | -- in2>-------+------------>+c2 +--> -- | | | -- +-->(0)-->(+)-->(0)--+-->+c3 | -- | t1 t2 | | | -- +--------------------+ | 8PSK | -- +------+ -- -- | ^ -- | 1/0 (A10) | -- | | 1/0 (A10) -- V | -- -- STATE:s1 +------+ (A00) STATE:s3 +------+ -- | | 0/0 | | -- in1>--------------->+c1 | <--- in1>--------------->+c1 | -- | | | | -- in2>-----+--------->+c2 +--> in2>--------------->+c2 +--> -- | | | | | -- +->(0)->(+)->(1)-+->+c3 | ---> +->(1)->(+)->(0)-+->+c3 | -- | t1 t2 | | | 0/1 | t1 t2 | | | -- +----------------+ | 8PSK | (A01) +----------------+ | 8PSK | -- +------+ +------+ -- -- | ^ -- | 1/1 (A11) | -- | | 1/1 (A11) -- V | -- -- STATE:s2 +------+ -- | | -- in1>-------------------->+c1 | -- | | -- in2>-------+------------>+c2 +--> -- | | | -- +-->(1)-->(+)-->(1)--+-->+c3 | -- | t1 t2 | | | -- +--------------------+ | 8PSK | -- +------+ -- ^ -- | | -- | | -- \ / 0/1 (A01) -- --------- -- ARCHITECTURE m2 OF tcm_mod IS TYPE state_type IS (s0, s1, s2, s3); SIGNAL current_state, next_state: state_type; VARIABLE phi, phi1, phi2, phi3 : REAL; BEGIN -- Process to hold synchrous elements (Flip-Flops) synch: PROCESS BEGIN WAIT UNTIL clk'event AND clk='1'; current_state <= next_state; END PROCESS; -- Process to hold combinational logic combi: PROCESS BEGIN CASE current_state IS WHEN s0 => IF in2='0' THEN next_state <= s0; ELSE next_state <= s1 END IF; c3 <= '0'; WHEN s1 => IF in2='0' THEN next_state <= s3; ELSE next_state <= s2; END IF; c3 <= '1'; WHEN s2 => IF in2='0' THEN next_state <= s2; ELSE next_state <= s3; END IF; c3 <= '1' WHEN s3 => IF in2='0' THEN next_state <= s1; ELSE next_state <= s0; END IF; c3 <='0'; END CASE; END PROCESS; RELATION PROCEDURAL FOR INIT => phi := 0.0; symbol_start_time := 0.0; m_out.v %= mag*cos(phi); PROCEDURAL FOR DC => m_out.v %= mag*cos(phi); PROCEDURAL FOR TRANSIENT => -- "natural mapping" for signal patitioning IF clk'event AND clk='1' THEN -- DIGITAL event reference in ANALOG symbol_start_time := NOW; -- A(in1,in2,c3) IF c3='0' THEN phi3 := 0.0; -- A0 ELSE phi3 := pi; -- A1 END IF; IF in2='0' THEN phi2 := 0.0; -- A00, A01 ELSE phi2 := pi/2.0; -- A10, A11 END IF; IF in1='0' THEN phi1 := 0.0; -- A000, A001, A010, A011 ELSE phi1 := pi/4.0; -- A100, A101, A110, A111 END IF; phi := phi1 + phi2 + phi3; END IF; -- END OF " clk'event AND clk='1' " m_out.v %= mag*cos(omega1*(NOW-symbol_start_time)+phi); END RELATION; END ARCHITECTURE m2; -- tcm_mod ------------------------------------------------------------------- -- TCM Demodulator ------------------------------------------------------------------- -- -- Viterbi decoder not yet available for me ... -- It is still difficult to write soon. -- I hope someone will help me ... -- ------------------------------------------------------------------ -- TCM demodulated output as digital signal ------------------------------------------------------------------ ENTITY tcm_out IS GENERIC( vth -- threshold for a2d :REAL); -- PORT( out1, out2 : OUT BIT); PIN( d_out1, d_out2 : ELECTRICAL); END ENTITY tcm_out; ARCHITECTURE m1 OF tcm_out IS --- HDL-A version --- SIGNAL out1q, out2q : BIT; BEGIN PROCESS BEGIN IF d_out1.v >= vth THEN out1q <= '1'; -- out1 <= out1q; ELSE out1q <= '0'; -- out1 <= out1q; END IF; IF d_out2.v >= vth THEN out2q <= '1'; -- out2 <= out2q; ELSE out2q <= '0'; -- out2 <= out2q; END IF; L3: LOOP WAIT ON rising(d_out1.v,vth),falling(d_out1.v,vth), rising(d_out2.v,vth),falling(d_out2.v,vth); IF d_out1.v >= vth THEN out1q <= '1'; -- rising -- out1 <= out1q; ELSE out1q <= '0'; -- falling -- out1 <= out1q; END IF; IF d_out2.v >= vth THEN out2q <= '1'; -- rising -- out2 <= out2q; ELSE out2q <= '0'; -- falling -- out2 <= out2q; END IF; END LOOP; -- L3 END PROCESS; END ARCHITECTURE m1; ARCHITECTURE m2 OF tcm_out IS --- VHDL-A version --- SIGNAL out1q, out2q : BIT; BEGIN PROCESS BEGIN IF d_out1.v >= vth THEN out1q <= '1'; -- out1 <= out1q; ELSE out1q <= '0'; -- out1 <= out1q; END IF; IF d_out2.v >= vth THEN out2q <= '1'; -- out2 <= out2q; ELSE out2q <= '0'; -- out2 <= out2q; END IF; L3: LOOP WAIT ON d_out1.v'RISING(vth),d_out1.v'FALLING(vth), d_out2.v'RISING(vth),d_out2.v'FALLING(vth); IF d_out1.v >= vth THEN out1q <= '1'; -- rising -- out1 <= out1q; ELSE out1q <= '0'; -- falling -- out1 <= out1q; END IF; IF d_out2.v >= vth THEN out2q <= '1'; -- rising -- out2 <= out2q; ELSE out2q <= '0'; -- falling -- out2 <= out2q; END IF; END LOOP; -- L3 END PROCESS; END ARCHITECTURE m2; From 1076-1-request@sicmail.epfl.ch Fri Dec 9 13:34:42 1994 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Fri, 9 Dec 94 13:34:33 -0500 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Fri, 9 Dec 94 13:34:30 -0500 Received: from newsgw.mentorg.com by sicmail.epfl.ch with SMTP (PP) id <03329-0@sicmail.epfl.ch>; Fri, 9 Dec 1994 19:05:54 +0100 Received: from wv.wv.mentorg.com by newsgw.mentorg.com (8.6.4/CF5.22R) id NAA12955; Fri, 9 Dec 1994 13:04:35 -0500 Received: from em-wv03.wv.mentorg.com by wv.wv.mentorg.com (8.6.8.1/CF5.22R) id KAA18200; Fri, 9 Dec 1994 10:05:48 -0800 Received: from telly.MENTORG.COM by em-wv03.wv.mentorg.com (8.6.8.1/CF5.23H) id KAA00268; Fri, 9 Dec 1994 10:06:42 -0800 From: dand@wv.MENTORG.COM (Dan Damon) Received: by telly.MENTORG.COM (1.37.109.4/CF3.4) id AA02727; Fri, 9 Dec 94 10:02:22 -0800 Message-Id: <9412091802.AA02727@telly.MENTORG.COM> Subject: validation model: simple pendulum To: 1076-1@epfl.ch Date: Fri, 9 Dec 94 10:02:21 PST Mailer: Elm [revision: 70.85] ENTITY pendulum IS GENERIC (gravity, ox, oy, len, mass, initphi, airres: analog); --Written by Dan Damon of Mentor Graphics. 7Dec94 --gravity is 9.75 meters/sec*sec (one earth gravity) --ox and oy are cartesian coordinates of the swing point (fixed) --len in the length of the pendulum --mass is the mass of the pendulum --initphi is the initial starting angle in degrees, + to the left --airres is the pendulum air resistance PIN (px, py : mechanical2); --in mechanical2, the across variable is displacement,d. --The through variable is force, f. --px and py are the x and y axis positions of the pendulum END ENTITY; ARCHITECTURE c OF pendulum IS STATE phi,dphi : analog; --phi is the angle of the pendulum with 0 = the x axis and pi/2 the y axis. --with no initial conditions except gravity, the pendulum should start at the x --axis, or 0 degrees, and swing around the -y axis. --dphi is the derivitive of phi, or the rotational velocity BEGIN RELATION PROCEDURAL FOR INIT => gravity := 9.75; --meters/(sec**2) ox := 0.0; oy := 0.0; len := 1.0; mass := 1.0; initphi := 0.0; airres := 0.02; PROCEDURAL FOR DC => px.d %= cos(initphi/57.29578)*len; py.d %= sin(initphi/57.29578)*len; dphi := 0.0; EQUATION (phi) FOR DC => phi == initphi/57.29578; PROCEDURAL FOR transient, ac => px.d %= cos(phi)*len; py.d %= sin(phi)*len; dphi := ddt(phi); EQUATION (phi) FOR transient, ac => -------------------------------- --The next equation is the sum of forces at the pendulum. They are --external forces px.i and py.i, gravity*mass, acceleration*mass, --and airres*velocity. --------------------------------- -cos(phi)*gravity*mass + sin(phi)*px.f - cos(phi)*py.f==mass*ddt(dphi)*len+airres*dphi*len; END RELATION; END ARCHITECTURE; From 1076-1-request@sicmail.epfl.ch Fri Dec 9 16:22:33 1994 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Fri, 9 Dec 94 16:22:29 -0500 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Fri, 9 Dec 94 16:22:26 -0500 Received: from sol.compass-da.com by sicmail.epfl.ch with SMTP (PP) id <06070-0@sicmail.epfl.ch>; Fri, 9 Dec 1994 21:48:55 +0100 Received: from [162.17.30.152] ([162.17.30.152]) by clsi.columbia.compass-da.com (8.6.9/8.6.9) with SMTP id PAA19057 for <1076-1@epfl.ch>; Fri, 9 Dec 1994 15:47:55 -0500 Date: Fri, 9 Dec 1994 15:47:55 -0500 Message-Id: <199412092047.PAA19057@clsi.columbia.compass-da.com> Reply-To: kenb@compass-da.com X-Sender: kennyb@clsi Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: 1076-1@epfl.ch From: kenb@compass-da.com (Kenneth Bakalar) Subject: Examples for "Quantities, Terminals and Nodes" These examples were presented at the last meeting of LAT in Baltimore. Ernst has asked me to post them to the reflector as an aid to understanding the white paper I posted earlier in the week. Please note that the definitions of the white paper do not depend on these examples. The examples are only illustrations. ---------------------------------------------------------------------- -- Examples for "Quantities, Terminals and Nodes" -- K. Bakalar 12/9/94 -- The following examples use (without formally defining) a syntax that -- complies with all of the definitions in the white paper on quantities -- terminals and nodes. The examples are intended to illustrate some -- of the ideas in the definition. It is by no means the only syntax -- that could be devised, many of which would look radically different! -- Of course, it does express my personal preferences.... -- -- A nature is pair of subtypes... -- package electrical_system is type kirchhoff is digits 15 range -1E+100 to +1E+100; subtype voltage is kirchhoff; subtype current is kirchhoff; subtype charge is kirchhoff; subtype inductance is kirchhoff; subtype capacitance is kirchhoff; nature electrical is across voltage through current reference ground; end electrical_system; -- -- A very simple syntax for DAEs is choosen for these examples. -- They are defined by a collection of "==" statements. -- "==" statements can be used in the statement part of a block. -- Following VHDL convention, most things are declared before they are -- used (implicit declaration is kept to a minimum). -- use electrical_system.all; entity inductor is generic (L: inductance); -- The port interface list is allowed to have terminals and quantities -- as well as signals port (terminal n1, n2: electrical); end inductor; -- architecture take_one of inductor is -- declare two branch quantities (and, implicitly, one branch) quantity branch_voltage across branch_current through n1 to n2; begin -- The 'dot attribute of a quantity is its derivative wrt time. branch_voltage == L* branch_current'dot; end take_one; -- -- Here's a simple resistor model with two interface terminals -- use electrical_system.all; entity resistor is generic (resistance: kirchhoff); port (terminal n1, n2: electrical); end resistor; -- architecture one of resistor is quantity resistor_e across resistor_i through n1 to n2; begin resistor_i == resistor_e/resistance; end one; -- -- This is identical to the previous architecture. -- Note that quantites n1_gnd_e and n2_gnd_e are not -- reference quantities themselves, they are ordinary across quantities -- architecture two of resistor is quantity resistor_i through n1 to n2; quantity n1_gnd_e across n1 to ground; quantity n2_gnd_e across n2 to ground; begin resistor_i == n1_gnd_e/resistance - n2_gnd_e/resistance; end two; -- -- Suppose that the 'ref attribute of a terminal denotes -- the reference quantity of that terminal: -- architecture three of resistor is quantity resistor_i through n1 to n2; begin resistor_i == (n1'ref -n2'ref)/resistance; end three; -- -- This inductor has a quantity interface element to "report out" -- the current -- use electrical_system.all; entity inductor1 is generic (L: inductance); port (terminal n1, n2: electrical; quantity q1: current); end inductor; architecture take_one of inductor1 is quantity branch_voltage across branch_current through n1 to n2; begin branch_voltage == L* branch_current'dot; q1 == branch_current; end take_one; -- -- An ideal operational amplifier. -- The input voltage and current are identically zero, by definition. -- The output current is declared, creating a branch, but is -- unconstrained by any equation. -- entity ideal_opamp is port (terminal inplus, inminus, output: electrical); end ideal_opamp; architecture one of ideal_opamp is quantity voltage_input across curent_input through inplus to inminus; quantity current_output through output to ground; begin voltage_input == 0.0; current_input == 0.0; end one; -- -- Let's try to use the opamp in a VVT with -- positive gain 1+igr/fbr (igr and fbr are resistances). -- entity op_amp_testbench is use electrical.all; end op_amp_testbench; architecture one of op_amp_testbench is terminal test_inminus, test_inplus, test_output: electrical; quantity feed_back_v across feed_back_i through test_inminus to test_output; quantity inminus_gnd_v across inminus_gnd_i through test_inplus across ground; constant fbr: resistance := 1.0e3; constant igr: resistance := 1.0e6; constant trial: voltage := 0.001; begin U1:entity ideal_opamp port map (test_inplus, test_inminus, test_output); feed_back_i == feed_back_v/fbr; inminus_gnd_i == inminus_gnd_v/igr; test_voltage == trial; end one; -- -- Now use the resistor component instead of the CE for the feedback. -- architecture two of op_amp_testbench is terminal test_inminus, test_inplus, test_output: electrical; quantity feed_back_v across feed_back_i through test_inminus to test_output; quantity inminus_gnd_v across inminus_gnd_i through test_inplus across ground; constant fbr: kirchhoff := 1.0e3; constant igr: kirchhoff := 1.0e6; constant trial: kirchoff := 0.001; begin U1:entity ideal_opamp port map (test_inplus, test_inminus, test_output); U2:entity resistor generic map (resistance => fbr) port map (test_inminus, test_output); inminus_gnd_i == inminus_gnd_v/igr; test_voltage == trial; end two; -- -- A parameterized diode, after a paper by FitzPatrick and Kundert. -- entity diode generic (Is,n,Vt,tau,Cj0,Phi: real); port (terminal a,c: electrical; total_current: current); end diode; architecture one of diode is quantity vdiode across idiode,icap through a to c; quantity charge: coulomb; begin idiode == A*Is*(exp((vdiode-Rs*idiode)/(n*Vt)) -1); charge == tau*idiode-2.0*Cj0*sqrt(Phi**2-Phi*vdiode); icap == charge'dot; total_current == icap+idiode; end one; __________________________________________________________________ Kenneth Bakalar voice +1 410 992 5700 ext. 1204 COMPASS Design Automation fax +1 410 992 3536 5457 Twin Knolls Road email kenb@compass-da.com Columbia MD 20845 USA __________________________________________________________________ From 1076-1-request@sicmail.epfl.ch Sat Dec 10 15:12:56 1994 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Sat, 10 Dec 94 15:12:48 -0500 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Sat, 10 Dec 94 15:12:42 -0500 Received: from mailgate.Cadence.COM by sicmail.epfl.ch with SMTP (PP) id <04890-0@sicmail.epfl.ch>; Sat, 10 Dec 1994 21:04:10 +0100 Received: (from smap@localhost) by mailgate.Cadence.COM (8.6.8/8.6.8) id MAA25176 for <1076-1@epfl.ch>; Sat, 10 Dec 1994 12:04:03 -0800 Received: from cds2072.cadence.com(158.140.24.54) by mailgate.cadence.com via smap (V1.0mjr) id sma025155; Sat Dec 10 12:03:51 1994 Received: from mailgate.Cadence.COM (mailgate.cadence.com [158.140.2.1]) by cds2072.Cadence.COM (8.6.8/8.6.8) with ESMTP id MAA13874 for ; Sat, 10 Dec 1994 12:03:48 -0800 Received: (from smap@localhost) by mailgate.Cadence.COM (8.6.8/8.6.8) id MAA25144 for ; Sat, 10 Dec 1994 12:03:45 -0800 Received: from fhg.de(153.96.1.1) by mailgate.cadence.com via smap (V1.0mjr) id sma025132; Sat Dec 10 12:03:32 1994 Received: by fhg.de (mail-gw.fhg.de) with PRESMTP; Sat, 10 Dec 94 21:03:19 +0100 from FHG-GATEWAY Received: by fhg.de (mail-gw.fhg.de) with SMTP; Sat, 10 Dec 94 21:03:11 +0100 from dresden.dresden.fhg.de Received: by dresden.fhg.de; Sat, 10 Dec 94 21:03:09 +0100 Received: by eas.iis.fhg.de; Sat, 10 Dec 94 21:02:56 +0100 From: Joachim Haase Date: Sat, 10 Dec 94 21:02:55 +0100 Received: by sp2.eas.iis.fhg.de; Sat, 10 Dec 94 21:02:55 +0100 Message-Id: <9412102002.AA03069@sp2.eas.iis.fhg.de> To: ahdl1076@cds2072.Cadence.COM Subject: validation example "Lithium - Cluster Dynamics" Dear interested people in VHDL-A, I send you a proposal concerning the validation example EUROSIM Comparison 1 (Lithium - Cluster Dynamics Model). File eurosim1.ps with results can be mailed on request. I would like to try the other examples (published in the List_of_Test_Cases) with HDL-A too, but I often don't know where a description can be found. Does there exist a list of references ? Regards, Joachim Haase + ------------------------------------------------------ + FhG IIS/EAS Dresden, Zeunerstr. 38, D-01069 Dresden + + Tel.: +49 - 351 - 4640 736 + Fax : +49 - 351 - 4640 703 + e-mail: haase@eas.iis.fhg.de -------------------------------------------------------- ============= file: eurosim1.hdla ====================================== -- TITLE: EUROSIM Comparison 1 -- AUTHOR: Joachim Haase (FhG IIS/EAS Dresden) -- DATE: 12. 12. 94 -- LASTUPDATE: 12. 12. 94 -- LANGUAGEVERSION: HDL-A (from ANACAD) -- CODESTATE: VALID -- HISTORY: Initial 12. 12. 94 -- Finished 12. 12. 94 -- DESCRIPTION: Lithium - Cluster Dynamics Model -- SCHEMATIC: does not exist. -- eurosim1.cir was used as netlist. -- CODE: HDL-A (file: eurosim1.hdla) -- STIMULI: initial value problem -- EXPECTED_RESULTS: see for instance EUROSIM Nr. 3 (November 1991) -- p. 32 (results from Herman Mann with DYNAST) -- RESULTS: -- SIMULATION_ENGINE: ELDO Version 4.3.3 on SUN -- DATE: 9.94 -- RESULT_STATE: VALID -- Results are stored in the Postscript-file eurosim1.ps -- It was generated by the Postprocessor Xelga 2.7.4 and -- could be printed with: lpr eurosim1.ps -- -- PROBLEM_LOG: 0. Original description of the problem was not -- available. The used system of differential -- equations was derived from H. Mann's contribution. -- 1. LF couldn't be used as name for a generic parameter. -- 2. The reference node 0 had to occur in the netlist. -- 3. HDL-A Model had to be compiled for debug mode instead to -- plot internal states f, m, r. Use therefore -- amc -g eurosim1.hdla -------------------------------------------------------------------------------- -- File: eurosim.hdla -------------------------------------------------------------------------------- ENTITY eurosim1 IS GENERIC ( kr, kf, lff, dr, dm, p : REAL; -- parameters init_f, init_m, init_r : REAL) ; -- initial conditions END eurosim1; ARCHITECTURE dgl OF eurosim1 IS STATE f, m, r : ANALOG; BEGIN RELATION PROCEDURAL FOR INIT => kr := 1.0; kf := 0.1; lff := 1000.0; dr := 0.1; dm := 1.0; p := 0.0; init_f := 9.975; init_m := 1.674; init_r := 84.99; EQUATION (f, m, r) FOR DC => 0.0 == f - init_f; 0.0 == m - init_m; 0.0 == r - init_r; EQUATION (r, m, f) FOR TRANSIENT => 0.0 == -ddt(r) - dr*r + kr*m*f; 0.0 == -ddt(m) + dr*r - dm*m + kf*f**2 - kr*m*f; 0.0 == -ddt(f) + dr*r + 2.0*dm*m - kr*m*f - 2.0*kf*f**2 -lff*f + p; END RELATION; END ARCHITECTURE dgl; ============= file: eurosim1.cir ======================================= EUROSIM comparison 1 .model eurosim1(dgl) macro lang=hdla y1 eurosim1(dgl) + generic: Lff=100.0 * The reference node 0 is needed in the network description. * To fulfil this condition a voltage source v1 was introduced. * This "dummy" voltage source has no influence on the result * of the system of differential equations. v1 1 0 1.0 .tran 1m 10 1.0e-4 .plot tran v(y1->f) v(y1->r) v(y1->m) .option eps=1.0e-8 noascii .ALTER y1 eurosim1(dgl) + generic: Lff=1000.0 .ALTER y1 eurosim1(dgl) + generic: Lff=1.0E4 .end From 1076-1-request@sicmail.epfl.ch Sat Dec 10 15:14:00 1994 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Sat, 10 Dec 94 15:13:51 -0500 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Sat, 10 Dec 94 15:13:44 -0500 Received: from fhg.de by sicmail.epfl.ch with SMTP (PP) id <04873-0@sicmail.epfl.ch>; Sat, 10 Dec 1994 20:55:42 +0100 Received: by fhg.de (mail-gw.fhg.de) with PRESMTP; Sat, 10 Dec 94 20:55:38 +0100 from FHG-GATEWAY Received: by fhg.de (mail-gw.fhg.de) with SMTP; Sat, 10 Dec 94 20:55:34 +0100 from dresden.dresden.fhg.de Received: by dresden.fhg.de; Sat, 10 Dec 94 20:55:32 +0100 Received: by eas.iis.fhg.de; Sat, 10 Dec 94 20:55:18 +0100 From: Joachim Haase Date: Sat, 10 Dec 94 20:55:17 +0100 Received: by sp2.eas.iis.fhg.de; Sat, 10 Dec 94 20:55:17 +0100 Message-Id: <9412101955.AA03058@sp2.eas.iis.fhg.de> To: 1076-1@epfl.ch Subject: validation example "Lithium - Cluster Dynamics" Dear interested people in VHDL-A, I send you a proposal concerning the validation example EUROSIM Comparison 1 (Lithium - Cluster Dynamics Model). File eurosim1.ps with results can be mailed on request. I would like to try the other examples (published in the List_of_Test_Cases) with HDL-A too, but I often don't know where a description can be found. Does there exist a list of references ? Regards, Joachim Haase + ------------------------------------------------------ + FhG IIS/EAS Dresden, Zeunerstr. 38, D-01069 Dresden + + Tel.: +49 - 351 - 4640 736 + Fax : +49 - 351 - 4640 703 + e-mail: haase@eas.iis.fhg.de -------------------------------------------------------- ============= file: eurosim1.hdla ====================================== -- TITLE: EUROSIM Comparison 1 -- AUTHOR: Joachim Haase (FhG IIS/EAS Dresden) -- DATE: 12. 12. 94 -- LASTUPDATE: 12. 12. 94 -- LANGUAGEVERSION: HDL-A (from ANACAD) -- CODESTATE: VALID -- HISTORY: Initial 12. 12. 94 -- Finished 12. 12. 94 -- DESCRIPTION: Lithium - Cluster Dynamics Model -- SCHEMATIC: does not exist. -- eurosim1.cir was used as netlist. -- CODE: HDL-A (file: eurosim1.hdla) -- STIMULI: initial value problem -- EXPECTED_RESULTS: see for instance EUROSIM Nr. 3 (November 1991) -- p. 32 (results from Herman Mann with DYNAST) -- RESULTS: -- SIMULATION_ENGINE: ELDO Version 4.3.3 on SUN -- DATE: 9.94 -- RESULT_STATE: VALID -- Results are stored in the Postscript-file eurosim1.ps -- It was generated by the Postprocessor Xelga 2.7.4 and -- could be printed with: lpr eurosim1.ps -- -- PROBLEM_LOG: 0. Original description of the problem was not -- available. The used system of differential -- equations was derived from H. Mann's contribution. -- 1. LF couldn't be used as name for a generic parameter. -- 2. The reference node 0 had to occur in the netlist. -- 3. HDL-A Model had to be compiled for debug mode instead to -- plot internal states f, m, r. Use therefore -- amc -g eurosim1.hdla -------------------------------------------------------------------------------- -- File: eurosim.hdla -------------------------------------------------------------------------------- ENTITY eurosim1 IS GENERIC ( kr, kf, lff, dr, dm, p : REAL; -- parameters init_f, init_m, init_r : REAL) ; -- initial conditions END eurosim1; ARCHITECTURE dgl OF eurosim1 IS STATE f, m, r : ANALOG; BEGIN RELATION PROCEDURAL FOR INIT => kr := 1.0; kf := 0.1; lff := 1000.0; dr := 0.1; dm := 1.0; p := 0.0; init_f := 9.975; init_m := 1.674; init_r := 84.99; EQUATION (f, m, r) FOR DC => 0.0 == f - init_f; 0.0 == m - init_m; 0.0 == r - init_r; EQUATION (r, m, f) FOR TRANSIENT => 0.0 == -ddt(r) - dr*r + kr*m*f; 0.0 == -ddt(m) + dr*r - dm*m + kf*f**2 - kr*m*f; 0.0 == -ddt(f) + dr*r + 2.0*dm*m - kr*m*f - 2.0*kf*f**2 -lff*f + p; END RELATION; END ARCHITECTURE dgl; ============= file: eurosim1.cir ======================================= EUROSIM comparison 1 .model eurosim1(dgl) macro lang=hdla y1 eurosim1(dgl) + generic: Lff=100.0 * The reference node 0 is needed in the network description. * To fulfil this condition a voltage source v1 was introduced. * This "dummy" voltage source has no influence on the result * of the system of differential equations. v1 1 0 1.0 .tran 1m 10 1.0e-4 .plot tran v(y1->f) v(y1->r) v(y1->m) .option eps=1.0e-8 noascii .ALTER y1 eurosim1(dgl) + generic: Lff=1000.0 .ALTER y1 eurosim1(dgl) + generic: Lff=1.0E4 .end From 1076-1-request@sicmail.epfl.ch Mon Dec 12 18:53:52 1994 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Mon, 12 Dec 94 18:53:47 -0500 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Mon, 12 Dec 94 18:53:43 -0500 Received: from sol.compass-da.com by sicmail.epfl.ch with SMTP (PP) id <08396-0@sicmail.epfl.ch>; Tue, 13 Dec 1994 00:33:41 +0100 Received: from [162.17.30.155] ([162.17.30.155]) by clsi.columbia.compass-da.com (8.6.9/8.6.9) with SMTP id SAA17611 for <1076-1@epfl.ch>; Mon, 12 Dec 1994 18:33:20 -0500 Date: Mon, 12 Dec 1994 18:33:20 -0500 Message-Id: <199412122333.SAA17611@clsi.columbia.compass-da.com> Reply-To: kenb@compass-da.com X-Sender: kennyb@clsi Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: 1076-1@epfl.ch From: kenb@compass-da.com (Kenneth Bakalar) Subject: Example for "Quantites, Terminals and Nodes" -- Here is another illustration for the Quantities, Terminals and Nodes paper. -- It is somewhat more substantial than any of the previous ones, and is -- intended to raise the level of confort of the analog designers among the -- reflector subscribers. I am indebted to Ernst Christen for his help in -- reviewing and correcting the draft version of the model. -- after Coston, W. Terry, "A Status Report on Analog HDLs", -- _ASIC and EDA_ ,November 1994, p. 32. library VHDL_A; use VHDL_A.electrical_system.all; entity amplifier is generic (gain, ugf, rin, iin, imax, sr , ro, soft: real); port (terminal vout, refer, vin, vinb, vp, vn: electrical); end amplifier; library IEEE; architecture basic2 of amplifier is -- Here is a local terminal declaration. It has exactly the same status as a -- terminal declared in the interface. terminal cout: electrical; constant c1: real := imax/(sr*1.0e6); constant gmnom: real := 2.0 * IEEE.math_real.math_pi * ugf * c1; constant r1: real := gain/gmnom; constant dvmax: real := imax/gmnom; -- The reader will find that diagraming these quantities as the edges of a -- directed graph on the terminals will aid in understanding the design. quantity Iinput through Vinput across vin to vinb; quantity Ivin through refer to vin; quantity Ivinb through refer to vinb; quantity Icout through Vcout across refer to cout; quantity Icout_vout through Vcout_vout across cout to vout; quantity Vvout_vp across vout to vp; quantity Vvout_vn across vout to vn; -- These non-branch quantities are used as temporaries in building up the -- equation for Icout quantity gain_current, dp_current, outstage_current: current; begin -- local terminal cout Icout == gain_current + dp_current - outstage_current; Icout_vout == Vcout_vout/r0; -- input stage Iinput == Vinput/rin; Ivin == iin; Ivinb == iin; -- A new piece of syntax is introduced; this is the "IF..USE" statement. -- It is a "simultaneous statment" like the "==" statement. Its effect is to -- select a particular set of equations from the alternatives in the statement -- parts. The parts that are not selected are ignored. -- gain stage if Vinput > dvmax use gain_current == imax; elsif Vinput < -dvmax use gain_current == -imax; else gain_current == gmnom * Vinput; end use; -- dominant pole dp_current == c1 * Vcout'ddt + Vcout/r1; -- output stage limiting if Vvout_vp > -soft use outstage_current == gmnom * (Vvout_vp+soft); elsif Vvout_vn < soft use outstage_current == gmnom * (Vvout_vn-soft); else outstage_current == 0.0; end use; end basic2; __________________________________________________________________ Kenneth Bakalar voice +1 410 992 5700 ext. 1204 COMPASS Design Automation fax +1 410 992 3536 5457 Twin Knolls Road email kenb@compass-da.com Columbia MD 20845 USA __________________________________________________________________ From 1076-1-request@sicmail.epfl.ch Tue Dec 13 04:30:29 1994 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Tue, 13 Dec 94 04:30:26 -0500 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Tue, 13 Dec 94 04:30:22 -0500 X400-Received: by mta sicmail.epfl.ch in /PRMD=switch/ADMD=arCom/C=ch/; Relayed; Tue, 13 Dec 1994 10:07:36 +0100 Date: Tue, 13 Dec 1994 10:07:36 +0100 X400-Originator: 1076-1-request@sicmail.epfl.ch X400-Recipients: non-disclosure:; X400-Mts-Identifier: [/PRMD=switch/ADMD=arCom/C=ch/;sicmail.ep.078:13.11.94.09.07.36] Priority: Non-Urgent Dl-Expansion-History: 1076-1@epfl.ch ; Tue, 13 Dec 1994 10:07:36 +0100; From: "Jean-michel.Berge" Message-Id: To: analog_reflector <1076-1@epfl.ch> Subject: DASC Membership X-Mailer: Mail*Link SMTP/MS 3.0.0 WG & SG Chairs: I'd appreciate it if you would pass this message along to your mailing lists. Thanks, --Paul ----- Begin Included Message ----- Ladies and Gentlemen, Your 1994 membership in the DASC has now expired. Unless you paid at the November Meeting (in Tyson's Corner), it's now time to pay again. For your convenience, attached please find a form which you can print out, fill in, and mail or fax to CMS to renew your membership. (Fax can only be used for credit card transations.) Please let me know if you have any questions. --Paul Menchini DASC Chair -- Paul Menchini |email: mench@mench.com |********************************* Menchini & Associates|voice: 919-990-9506 |* PLEASE NOTE MY NEW EMAIL * 2 Davis Dr./POB 13036|pager: 800-306-8494 |* ADDRESS! * RTP, NC 27709-3036 |fax: 919-990-9507 |********************************* ----- End Included Message ----- ---------- X-Sun-Data-Type: default X-Sun-Data-Description: default X-Sun-Data-Name: 95-app-form X-Sun-Content-Lines: 82 DASC APPLICATION FOR MEMBERSHIP The Design Automation Standards Committee is moving into its second year under its new charter. This group is responsible for the standardization of work related to design automation in the electronics industry, one of the fastest growing technology areas of the 1990s. The group began with the successful development of the VHDL standard and is now working on related standards in the logic synthesis, analog simulation, timing verification, and mathematical areas for deisgn verification. The group has also undertaken the standardization of Verilog. Membership in the DASC is the fundamental way in which to support these activities. In 1995 and going forward, membership is a requirement for voting privileges in any of the working or study groups under the DASC. Highlights of the DASC Membership Membership is on a subscription basis with yearly dues currently set at $150. In 1995 the DASC is changing its fiscal year to begin on January 1. Therefore, this year only the membership fee includes membership until the end of 1995 rather than until November 1995. Minutes/ All members will regularly received all meeting minutes, Mailing technical publications, and informational announcements from the DASC Working and Wtudy Groups. Elections All DASC officers, including the DASC Chair and Working and Study Group Chairs are elected by the DASC membership. Administration of the DASC is handled by Conference Management Services of Menlo Park, CA. If you have any questions or would like a copy of the Bylaws please contact CMS at 415-329-0510 or merryb@vhdl.org. Complete and Return to CMS with your Dues of $150.00US (checks must be payable on a US bank): Name: _______________________________________________________________ Affiliation: _______________________________________________________________ Address: _______________________________________________________________ _______________________________________________________________ City: ______________________________________________ State: ________ Postal Code: _____________________ Country: ______________________________ Telephone: _____________________ Fax: ______________________________ EMail: _______________________________________________________________ For Credit Card Orders Only: Name on Card: _______________________________________________________________ Type of Card: _________________ (Visa, MasterCard, Discover only) Card Number: _______________________________________________________________ Expiration: ______ Signature: ____________________________________________ Optinal Information: IEEE Member Number: _______________________________________ Other Professional Affiliations: _______________________________________ RETURN TO: DASC 407 Chester Street Menlo Park, CA 94025 USA 415-324-3150 (Fax--Credit Cards only) From 1076-1-request@sicmail.epfl.ch Thu Dec 15 13:06:45 1994 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Thu, 15 Dec 94 13:06:08 -0500 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Thu, 15 Dec 94 13:06:04 -0500 Received: from hq.seicom.de by sicmail.epfl.ch with SMTP (PP) id <12585-0@sicmail.epfl.ch>; Thu, 15 Dec 1994 18:39:47 +0100 Received: from boschqi by hq.seicom.de with uucp (/\==/\ Smail3.1.28.1 #2) id m0rIJVu-0004XHC; Thu, 15 Dec 94 17:58 MEZ Received: from dic.k8.rt.bosch.de (dicgt) by rt.bosch.de (4.1/boschqi.cf_2.0-6/30/94) id AA14036; Thu, 15 Dec 94 17:46:56 +0100 Received: from seth by dic.k8.rt.bosch.de (4.1/k8.rt.bosch.de_1.1-11/20/92) id AA16740; Thu, 15 Dec 94 17:46:56 +0100 Message-Id: <9412151646.AA16740@dic.k8.rt.bosch.de> Date: Thu, 15 Dec 94 17:46:55 +0100 From: Oliver "J." Fischer K8/DIC "Tel." 1608 To: 1076-1@epfl.ch Subject: (Validation) Rules for examples Cc: olli.fischer@rt.bosch.de Dear friends, there are some comments I would like to make on the process of gathering examples for validation purposes. First I do not want to interrupt the production and the publishing of validation examples but I have serious concers about the form in which they arise. I have to state that neither HDL-A nor any other tool proprietary language is VHDL-A 1076.1. This must be said because the mass of examples running over the world through our reflector are written in HDL-A. My corcerns are as follows: Coding an example in any language, even the natural!!, forces us to eximine and rewrite this example with respect to the semantics and syntax of 1076.1 which are the outcome of our LA-Team. This will be the major task of our group. To do this task we need to understand the problem addressed in the example. So, I propose following refinements on our work in the group: 1. Please describe the problem addressed in your example in natural language with the help of mathematical formulas (if applies). Try to describe the problem as careful as possible. 2. Please describe the stimulies and the expected results 3. If possible do not use existing modelling languages for describing the problem, because in formulating such code there are hidden informations (semantics) and all validation guys are excluded to rewrite the code who are not familiar with this tool language. I can see the wish to code algorithms and so on in a formalised language, this is what our VHDL-A will stand for. If it is completely neccessary to use an existing modelling language the example would be only acceptable for further use, when enough comments in the code is available, otherwise it is useless for our purpose. So please, ease our validation work. Best regards, Olli ********************************************************************** * Joerg-Oliver Fischer-Binder * * Robert Bosch GmbH phone: ++49-(0)7121-35-1608 * * K8/DIC fax: ++49-(0)7121-35-2687 * * P.O. Box 1342 email: Olli.Fischer@rt.bosch.de * * 72703 Reutlingen * ********************************************************************** From 1076-1-request@sicmail.epfl.ch Thu Dec 15 17:59:24 1994 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Thu, 15 Dec 94 17:59:19 -0500 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Thu, 15 Dec 94 17:59:15 -0500 Received: from etdl839.arl.army.mil by sicmail.epfl.ch with SMTP (PP) id <17137-0@sicmail.epfl.ch>; Thu, 15 Dec 1994 22:58:19 +0100 Received: by etdl839 (5.0/SMI-SVR4) id AA06064; Thu, 15 Dec 1994 16:59:07 +0500 Date: Thu, 15 Dec 1994 16:59:07 +0500 From: rhodes@arl.army.mil Message-Id: <9412152159.AA06064@etdl839> To: 1076-1@epfl.ch, mhdl@halibut.nosc.mil Subject: NRC post-doc for HDL work Content-Length: 2317 MHDL/VHDL-A mailing list members: We have a possible opportunity for a National Research Council (NRC) candidate here in the area of HDLs (along with other areas). For those not familiar with the NRC program, its purpose is to support _recent_ graduates (PhD level) with a fellowship to work at various (US) labs. A candidate must basically be either a US citizen or holder of a "green card", apologies to non-US readers :-) Note that this is a bit oriented towards MHDL work, but includes other possibilities too. If anyone knows of someone who would be interested, please have them contact me (not Barry as indicated below). Dave ------------------------------------------------------------------------------ Hardware Description Language Theory BS Perlman 76.23.15.07 Varied-level computer languages for representing analog, microwave and digital hardware are becoming of increased import. This is due in part to a need to predict correct operation of increasingly complex and integrated IC and MCM parts. The problem is especially acute in circuits and systems with mixed-signal functionality. A significant problem area exists in the capturing of the information, where the carrier of such information is called a hardware description language (HDL). Development of HDL theory and techniques which support the entire product development cycle including: specification, synthesis, test, formal verification, manufacturing data support, as well as the traditional modeling and simulation arenas, is sought. Coupling of HDL developments to CAE and CAD tools and backplanes should also be considered. Special emphasis is given to the mixed-signal (analog/microwave/digital) area. Although current emphasis is on the traditional text-based HDLs (i.e., VHDL, MHDL), a wide-variety of approaches will be considered including: graphical methods; mathematics-based approaches; languages based on functional or operational semantics; HDLs based on abstract machines/compilers, etc. EPSD has a full complement of computer systems, including up-to-date workstations from Sun, Hewlett-Packard and Digital Equipment Corporation, as well as a full suite of commercial and in-house application and development software. Access to off-site super-computers and massively parallel machines is also readily available. From 1076-1-request@sicmail.epfl.ch Wed Jan 4 12:42:42 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Wed, 4 Jan 95 12:42:38 -0500 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Wed, 4 Jan 95 12:42:34 -0500 Received: from psi.com by sicmail.epfl.ch with SMTP (PP) id <02323-0@sicmail.epfl.ch>; Wed, 4 Jan 1995 18:17:23 +0100 Received: from analogy.com (analogy.analogy.com) by psi.com (4.1/2.1-PSI/PSINet) id AA16717; Wed, 4 Jan 95 12:17:15 EST Received: from miller.analogy.com ([149.117.72.253]) by analogy.com (4.1/Shared_Spool_1.3) id AA22965; Wed, 4 Jan 95 09:16:48 PST Received: from satyr.analogy.com by miller.analogy.com (4.1/SMI-3.2) id AA12271; Wed, 4 Jan 95 09:16:46 PST Received: by satyr.analogy.com (5.0/SMI-SVR4) id AA00472; Wed, 4 Jan 1995 09:16:46 -0800 Date: Wed, 4 Jan 1995 09:16:46 -0800 From: christen@analogy.com (Ernst Christen) Message-Id: <9501041716.AA00472@satyr.analogy.com> To: 1076-1@epfl.ch Subject: Next LAT meeting Content-Length: 1051 As previously announced, the next meeting of the Language Architecture Team will be held from January 31, 1995 to February 3, 1995, in Lausanne, Switzerland. Central to the meeting will be discussions about the following topics: - quantities, nodes and natures - relations - simulation cycle, A/D and D/A interaction - DC analysis and initialization - number of equations vs. number of quantities - SPICE compatibility issues - predefined language environment Issues related to these topics are currently being addressed by various people and documented in white papers. These white papers will be made available to meeting attendees prior to the meeting. They will be sent to the reflector once they have been adopted by the LAT. Alain Vachoux is in charge of local arrangements for this meeting (hotel, meeting place etc.). Please let him know by January 16, 1995 if you will attend. His email is alain.vachoux@leg.de.epfl.ch. Registration is required for getting the white papers prior to the meeting. Thanks. Ernst Christen Chair LAT From 1076-1-request@sicmail.epfl.ch Fri Jan 6 09:46:50 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Fri, 6 Jan 95 09:46:48 -0500 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Fri, 6 Jan 95 09:46:45 -0500 X400-Received: by mta sicmail.epfl.ch in /PRMD=switch/ADMD=arCom/C=ch/; Relayed; Fri, 6 Jan 1995 15:42:58 +0100 Date: Fri, 6 Jan 1995 15:42:58 +0100 X400-Originator: 1076-1-request@sicmail.epfl.ch X400-Recipients: non-disclosure:; X400-Mts-Identifier: [/PRMD=switch/ADMD=arCom/C=ch/;sicmail.ep.174:06.00.95.14.42.58] Priority: Non-Urgent Dl-Expansion-History: 1076-1@epfl.ch ; Fri, 6 Jan 1995 15:42:58 +0100; From: "Jean-michel.Berge" Message-Id: To: analog_reflector <1076-1@epfl.ch> Subject: Forwarded from Jean Mermet X-Mailer: Mail*Link SMTP/MS 3.0.0 We are still lacking good papers for EuroVHDL95 in the field of "SIMULATION" in general ( digital, analog, mixed....) I am sure some of you, or some of your colleagues could contribute original presentations. The deadline is: 20 th of January To the Working Group chairs: "PLEASE DISTRIBUTE THIS CALL TO YOUR GROUP". THANK YOU VERY MUCH ----------------------------------------------------------------------------- Jean Mermet e-mail : jean.mermet@imag.fr Artemis, University J. Fourier Phone : 33/ 76 51 44 99 BP 53X Fax : 33/ 76 42 87 87 GRENOBLE CEDEX 38041, FRANCE ---------------------------------------------------------------------------- -- From 1076-1-request@sicmail.epfl.ch Fri Jan 6 12:17:47 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Fri, 6 Jan 95 12:17:44 -0500 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Fri, 6 Jan 95 12:17:40 -0500 Received: from c3imac12.epfl.ch by sicmail.epfl.ch with SMTP (PP) id <22645-0@sicmail.epfl.ch>; Fri, 6 Jan 1995 18:01:42 +0100 X-Sender: vachoux@c3i9.epfl.ch Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 6 Jan 1995 18:04:54 +0100 To: 1076-1@epfl.ch From: alain.vachoux@leg.de.epfl.ch (Alain Vachoux EPFL-LEG/C3i) Subject: Re: New 1076.1 ftp organization Steeve Greenberg writes: >I found nestor.epfl.ch/pub/vhdl, but ftp.uu.net/pub/vhdl does not exist. >I found ftp.uu.net/pub, but vhdl was not there. He's perfectly right. This is due to a temporary difference between directory organizations in nestor.epfl.ch and in ftp.uu.net. I recommend to access only nestor.epfl.ch until everything stabilizes. Eventually, the mirror site ftp.uu.net will have the same organization as nestor.epfl.ch. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Alain Vachoux Swiss Federal Institute of Technology (EPFL) Dept. of Electrical Engineering Integrated Systems Center (C3i) e-mail: alain.vachoux@leg.de.epfl.ch EL-Ecublens Phone: (+41) 21 693 69 84 CH-1015 Lausanne, Switzerland Fax: (+41) 21 693 46 63 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From 1076-1-request@sicmail.epfl.ch Mon Jan 16 05:18:17 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Mon, 16 Jan 95 05:18:14 -0500 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Mon, 16 Jan 95 05:18:10 -0500 Received: from c3imac12.epfl.ch by sicmail.epfl.ch with SMTP (PP) id <15583-0@sicmail.epfl.ch>; Fri, 6 Jan 1995 12:24:45 +0100 X-Sender: vachoux@c3i9.epfl.ch Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 6 Jan 1995 12:27:58 +0100 To: 1076-1@epfl.ch From: alain.vachoux@leg.de.epfl.ch (Alain Vachoux EPFL-LEG/C3i) Subject: New 1076.1 ftp organization All, First of all, please have my best wishes for 1995. The IEEE DASC 1076.1 Working Group archive site has moved to another location in the nestor.epfl.ch machine. There are now two entries: pub/vhdl/standards/ieee/1076.1 to get to the read-only archive site. Read the file 00.README. incoming/vhdl to upload files. In this case, please send me an email first so I can move the files to the proper read-only location. The former directory incoming/vhdl/analog now contains only the file 00.README which indicates the new location of the archive site. The old directories ref and working will remain there until the new organization is stable. It is not recommended, however, to access them anymore since new files will be put from now on in the new read-only entry pub/vhdl/standards/ieee/1076.1. References to files in old documents such as minutes are also obsolete, but it should not be so difficult to find them again in the new directory structure. See the document below for more information. Note also that I'm currently working with VI to set up a second mirror repository on the vhdl.org machine. More details on this soon. I hope this will ease the finding of information about the work performed by the 1076.1 working group. Do not hesitate to contact me if you have any comment, request, etc. Regards, Alain Vachoux 1076.1 secretary -------------------------------------------------------------------------------- IEEE DASC 1076.1 Working Group FTP Archive Site Organization ----------------------------- -- History: 23 dec 94 Read-only entry moved from 'incoming' to 'pub' Upload-only entry in 'incoming' New directory structure 31 mar 94 Mail archive in working directory 6 dec 93 New subdirectory incoming/vhdl/analog/ref/admin 25 feb 93 New subdirectories incoming/vhdl/VASG/minutes incoming/vhdl/analog/ref/glossary incoming/vhdl/analog/ref/rationale incoming/vhdl/analog/working/glossary incoming/vhdl/analog/working/rationale 25 feb 93 Creation. -- FTP addresses: nestor.epfl.ch (128.178.50.20) Main repository ftp.uu.net (192.48.96.9) Mirror of main repository Connect yourself with username 'anonymous' and with your email address as password. -- General repository structure: incoming Only used to upload files pub Root of the read-only area vhdl VHDL related stuff standards ieee 1076.1 Analog extensions admin Administrative documents documentation Documentation documents individual_mails Archive for individual mails lang_design Language design documents requirements Requirements documents topic_mails Archive with mails grouped by topics validation Validation documents wg_meetings Working group meeting minutes These last level directories may contain in turn subdirectories. -- File extensions: The following file extensions are used: .ps PostScript file .txt pure ASCII file .rtf document in Word Rich Text Format (for both PC and Mac) .Z compressed file -- Requests: Any request related to the ftp archive site should be sent to 1076-1-request@epfl.ch. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Alain Vachoux Swiss Federal Institute of Technology (EPFL) Dept. of Electrical Engineering Integrated Systems Center (C3i) e-mail: alain.vachoux@leg.de.epfl.ch EL-Ecublens Phone: (+41) 21 693 69 84 CH-1015 Lausanne, Switzerland Fax: (+41) 21 693 46 63 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From 1076-1-request@sicmail.epfl.ch Fri Jan 20 01:08:35 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Fri, 20 Jan 95 01:08:13 -0500 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Fri, 20 Jan 95 01:08:02 -0500 Received: from inet-tsb.toshiba.co.jp by sicmail.epfl.ch with SMTP (PP) id <24578-0@sicmail.epfl.ch>; Fri, 20 Jan 1995 06:45:16 +0100 Received: from tis2.tis.toshiba.co.jp (tis2) by inet-tsb.toshiba.co.jp (5.67+1.6W/2.8Wb) id AA27139; Fri, 20 Jan 95 14:23:15 JST Received: from tis10.tis.toshiba.co.jp (tis10) by tis2.tis.toshiba.co.jp (5.67+1.6W/6.4J.6-R05) id AA19501; Fri, 20 Jan 95 14:23:42 JST Received: from eecisa.eec.toshiba.co.jp (eecisa) by tis10.tis.toshiba.co.jp (5.67+1.6W/6.4J.6-MHS-CNTML-R1) id AA05872; Fri, 20 Jan 95 14:23:41 JST Received: from roku.eec.toshiba.co.jp (eecjsf) by eecisa.eec.toshiba.co.jp (4.1/6.4J.6-R1) id AA26234; Fri, 20 Jan 95 14:11:33 JST Return-Path: Received: by roku.eec.toshiba.co.jp (8.6.9+2.4Wb3/3.3W-roku_Master) with ESMTP id OAA06389; Fri, 20 Jan 1995 14:12:08 +0900 From: "VHDL analog mail by (CA1)H.Sasaki 94.1.18" Message-Id: <199501200512.OAA06389@roku.eec.toshiba.co.jp> Date: Fri, 20 Jan 1995 14:21:52 +0900 To: 1076-1@epfl.ch, Olli.Fischer@rt.bosch.de, jvl-analog@nttica.ntt.jp, jvlwg@nttica.ntt.jp Subject: (validation) DMSK -- rimoldi1.ps.uuencoded Cc: renderings@anacad.com, vhdlbpeldo@anacad.de, vhdlbpeldo@anacad.fr begin 777 rimoldi1.ps.uuencoded M)2%04RU!9&]B92TR+C *)254:71L93H@1&]C=6UE;G0*)25#7)I9VAT(#$Y.3 @6%94(%-O9G1W87)E($EN8RX@06QL(')I9VAT M2!B>2!A<'!L:6-A=&EO;G,@=W)I='1E;B!W:71H(&%N(%A65"!T;V]L:VET M('-U<'!L:65D(&)Y"B4@6%94(%-O9G1W87)E($EN8RX*)0HE(%!R;V)L96US M.@HE(%1E>'0Z"B4)+2!O<&%Q=65?=&5X="!N;W0@:&]N;W)E9#L@86QW87ES M($9!3%-%("AT:&5R969O65T.@HE"2T@9')A=U]A;&EN92!;;%X@9F-N(&ES(&AE M7)A9"!X7V-E M;G1E"!M871R:7@@8W5R"!D968*"71R86YS;&%T90H)"!A"B4@06QS;RP@8V]O&-H(&%T86X@"!Y(&%R"B O;%X@>R E9&5F(" @("4@;&EN971O+6%R"!P2!C86-H90HE(&1E9FEN97!A='1E"!D968*"0D)+VAE:6=H="!E M>&-H(&1E9@H)"0DO=VED=&@@97AC:"!D968*"0D)+V-T;2!M871R:7@@8W5R M"!D968*"0D)+W!T;2!M871R:7@@:61E;G1M871R:7@@9&5F M"@D)"2]S='(*"0D)*#$R,S0U-C"!&;VYT1&EC=" O;71X(&=E="!D968*"0DO16YC M;V1I;F<@4W1A;F1AR E:69E;'-E"@D)"0D)," P('=I M9'1H(&AE:6=H="!S971C86-H961E=FEC90H)"0D)?7L@)65L7!E(&5Q M('L@)6EF96QS90H)"6)E9VEN($9O;G1$:6-T("]C=&T@9V5T('-E=&UA=')I M> H)?7L@)65L&-H(&)E9VEN($9O;G1$:6-T("]C=&T@9V5T('-E M=&UA=')I> H)"6-O;F-A= H)?2!I9F5L"!C;VYC870*"0EW:61T M:" P(&1T"!P;W *"0E[("5R97!E870*"0D)9W-A=F4*"0D)"7!T;2!C;VYC870*"0D) M"61U<"!S='(@;&5N9W1H(&ED:78@>R ER E9F]R86QL"@D),B!C;W!Y(# @ M97AC:"!P=70@<&]P(&1U< H)"69A;'-E(&-H87)P871H( H)"6-UR E96QS90H)"0DV(&EN9&5X(#8@ M:6YD97@@<&%T=&5R;F9I;&P*"0E](&EF96QS90H)"6UO=F5T;PH)"3,@8V]P M>2!P;W @R!P;W @?2!I9B!P;W *?2!B:6YD(&1E9@H*)2!D M:6-T('-T&-H(# @ M97AC:"!P871T97)N87-H;W<*?2!B:6YD(&1E9@H*+V]P87%U97!A='1E0H)9FEL; H)9W)E&-H(')L:6YE M=&\*"0EN96<@,"!R;&EN971O"@D)8VQOR E9&5F:6YE<&%T=&5R;@H),B!S971L:6YE8V%P"@DW+C4@,"!M;W9E=&\@ M,34@-RXU(&QI;F5T;PH)," W+C4@;6]V971O(#R E9&5F:6YE<&%T=&5R;@H) M,B R('-C86QE"@DR('-E=&QI;F5C87 *"32!-2E(@=&\@9FQEB!TPH)8F%C:U]R9V(@86QO860@<&]P('-E=')G8F-O;&]R"GT@ M8FEN9"!D968*"B4@0V]N9&ET:6]N86P@PH)+V1O7V9I;&P@=')U92!D968* M"2]BR!F:6QL('T@8FEN9"!D968*?0IB:6YD(&1E9@HO8G)U MPH)+V1O7V9I;&P@=')U92!D968*"2]BR O M3$5&5&1I86=O;F%L(&9I;F1F;VYT('!A='1EPH)+V1O7V9I;&P@=')U92!D968* M"2]BR O4DE'2%1D:6%G;VYA;"!F:6YD9F]N="!P871T97)N M9FEL;"!](&)I;F0@9&5F"GT*8FEN9"!D968*+V)R=7-H7V1I86=CB!["@DO9&]?9FEL;"!TPH)+V1O7V9I;&P@=')U92!D968* M"2]BR O8W)OR!BR!N97=P871H('T*"6EF96QS90I](&)I;F0@9&5F"@HE(%A65"=S(&UO M=F5?=&\*)2!5"!Y(&UV"B]M=B!["@EM;W9E=&\*?2!B:6YD(&1E M9@H*)2!85E0G"!Y(&1L"B]D;"!["@EL M:6YE=&\@8W5R6QI;F5S(&%N9"!P;VQY9V]N"!Y(&(*)0D)"7@@>2!L"B4)"0DN+BX@2!D;"!;9F]R('!O;'EL:6YE70HE"0D)>"!Y(&1G(%MF;W(@<&]L M>6=O;ET*+V(@>PH);6]V971O"GT@8FEN9"!D968*+VP@>PH);&EN971O"GT@ M8FEN9"!D968*+V1G('L*"6QI;F5T;PH)8VQO"!,3'D@9')R"B]DPH))2!#86XG="!U"!D968*"71R M86YS;&%T90H),B!I;F1E>" Q(&EN9&5X('-C86QE"@ED:78@+V@@97AC:"!D M968*"61I=B O=R!E>&-H(&1E9@H),2 P(&UO=F5T;PH)=R P('<@,2 Q(&%R M8W1O(#0@>R!P;W @?2!R97!E870*"7<@:"!W(#$@R!P;W @?2!R97!E870* M"6-L;W-E<&%T: H)"!S971M871R:7@*"6=S879E(&-F:6QL M(&=R97-T;W)E(&-S=')O:V4*?2!B:6YD(&1E9@H*)2!85E0G')A9"!Y" U M(&EN9&5X(&5L;&EP')A9"!YPH)+WDR(&5X M8V@@9&5F"@DO>#(@97AC:"!D968*"2]Y,2!E>&-H(&1E9@H)+W@Q(&5X8V@@ M9&5F"@DO>3 @97AC:"!D968*"2]X,"!E>&-H(&1E9@H)+WER(&5X8V@@9&5F M"@DO>'(@97AC:"!D968*"7DQ('DP('-U8B!X#$@># @'(@;75L('@R('@P('-U8B!Y')A9"!Y')A9"!Y2!D= HE($QI;6ET871I;VYS.B!I9VYO71E71E+B!4:&5R92!S:&]U;&0@8F4@87,@;6%N>2!G MR!C=7)R96YT9FEL92!$871A M4W1R:6YG(')E861H97AS=')I;F<@<&]P('T*"6)I;F0@:6UA9V4*"6=R97-T M;W)E"GT@8FEN9"!D968*"B4@1F-N('1O('-E="!P96X@=VED=&@*)2!5PH)9'5P"@DO9&]?"!N96<@," P(%T@;6%K969O;G0@; Fri, 20 Jan 95 01:08:02 -0500 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Fri, 20 Jan 95 01:07:54 -0500 Received: from inet-tsb.toshiba.co.jp by sicmail.epfl.ch with SMTP (PP) id <24455-0@sicmail.epfl.ch>; Fri, 20 Jan 1995 06:32:13 +0100 Received: from tis2.tis.toshiba.co.jp (tis2) by inet-tsb.toshiba.co.jp (5.67+1.6W/2.8Wb) id AA27275; Fri, 20 Jan 95 14:25:16 JST Received: from tis10.tis.toshiba.co.jp (tis10) by tis2.tis.toshiba.co.jp (5.67+1.6W/6.4J.6-R05) id AA19692; Fri, 20 Jan 95 14:25:48 JST Received: from eecisa.eec.toshiba.co.jp (eecisa) by tis10.tis.toshiba.co.jp (5.67+1.6W/6.4J.6-MHS-CNTML-R1) id AA06524; Fri, 20 Jan 95 14:26:10 JST Received: from roku.eec.toshiba.co.jp (eecjsf) by eecisa.eec.toshiba.co.jp (4.1/6.4J.6-R1) id AA26307; Fri, 20 Jan 95 14:14:04 JST Return-Path: Received: by roku.eec.toshiba.co.jp (8.6.9+2.4Wb3/3.3W-roku_Master) with ESMTP id OAA06394; Fri, 20 Jan 1995 14:14:41 +0900 From: "VHDL analog mail by (CA1)H.Sasaki 94.1.18" Message-Id: <199501200514.OAA06394@roku.eec.toshiba.co.jp> Date: Fri, 20 Jan 1995 14:24:24 +0900 To: 1076-1@epfl.ch, Olli.Fischer@rt.bosch.de, jvl-analog@nttica.ntt.jp, jvlwg@nttica.ntt.jp Subject: (validation) DMSK -- rimoldi2.ps.uuencoded Cc: renderings@anacad.com, vhdlbpeldo@anacad.de, vhdlbpeldo@anacad.fr begin 777 rimoldi2.ps.uuencoded M)2%04RU!9&]B92TR+C *)254:71L93H@1&]C=6UE;G0*)25#7)I9VAT(#$Y.3 @6%94(%-O9G1W87)E($EN8RX@06QL(')I9VAT M2!B>2!A<'!L:6-A=&EO;G,@=W)I='1E;B!W:71H(&%N(%A65"!T;V]L:VET M('-U<'!L:65D(&)Y"B4@6%94(%-O9G1W87)E($EN8RX*)0HE(%!R;V)L96US M.@HE(%1E>'0Z"B4)+2!O<&%Q=65?=&5X="!N;W0@:&]N;W)E9#L@86QW87ES M($9!3%-%("AT:&5R969O65T.@HE"2T@9')A=U]A;&EN92!;;%X@9F-N(&ES(&AE M7)A9"!X7V-E M;G1E"!M871R:7@@8W5R"!D968*"71R86YS;&%T90H)"!A"B4@06QS;RP@8V]O&-H(&%T86X@"!Y(&%R"B O;%X@>R E9&5F(" @("4@;&EN971O+6%R"!P2!C86-H90HE(&1E9FEN97!A='1E"!D968*"0D)+VAE:6=H="!E M>&-H(&1E9@H)"0DO=VED=&@@97AC:"!D968*"0D)+V-T;2!M871R:7@@8W5R M"!D968*"0D)+W!T;2!M871R:7@@:61E;G1M871R:7@@9&5F M"@D)"2]S='(*"0D)*#$R,S0U-C"!&;VYT1&EC=" O;71X(&=E="!D968*"0DO16YC M;V1I;F<@4W1A;F1AR E:69E;'-E"@D)"0D)," P('=I M9'1H(&AE:6=H="!S971C86-H961E=FEC90H)"0D)?7L@)65L7!E(&5Q M('L@)6EF96QS90H)"6)E9VEN($9O;G1$:6-T("]C=&T@9V5T('-E=&UA=')I M> H)?7L@)65L&-H(&)E9VEN($9O;G1$:6-T("]C=&T@9V5T('-E M=&UA=')I> H)"6-O;F-A= H)?2!I9F5L"!C;VYC870*"0EW:61T M:" P(&1T"!P;W *"0E[("5R97!E870*"0D)9W-A=F4*"0D)"7!T;2!C;VYC870*"0D) M"61U<"!S='(@;&5N9W1H(&ED:78@>R ER E9F]R86QL"@D),B!C;W!Y(# @ M97AC:"!P=70@<&]P(&1U< H)"69A;'-E(&-H87)P871H( H)"6-UR E96QS90H)"0DV(&EN9&5X(#8@ M:6YD97@@<&%T=&5R;F9I;&P*"0E](&EF96QS90H)"6UO=F5T;PH)"3,@8V]P M>2!P;W @R!P;W @?2!I9B!P;W *?2!B:6YD(&1E9@H*)2!D M:6-T('-T&-H(# @ M97AC:"!P871T97)N87-H;W<*?2!B:6YD(&1E9@H*+V]P87%U97!A='1E0H)9FEL; H)9W)E&-H(')L:6YE M=&\*"0EN96<@,"!R;&EN971O"@D)8VQOR E9&5F:6YE<&%T=&5R;@H),B!S971L:6YE8V%P"@DW+C4@,"!M;W9E=&\@ M,34@-RXU(&QI;F5T;PH)," W+C4@;6]V971O(#R E9&5F:6YE<&%T=&5R;@H) M,B R('-C86QE"@DR('-E=&QI;F5C87 *"32!-2E(@=&\@9FQEB!TPH)8F%C:U]R9V(@86QO860@<&]P('-E=')G8F-O;&]R"GT@ M8FEN9"!D968*"B4@0V]N9&ET:6]N86P@PH)+V1O7V9I;&P@=')U92!D968* M"2]BR!F:6QL('T@8FEN9"!D968*?0IB:6YD(&1E9@HO8G)U MPH)+V1O7V9I;&P@=')U92!D968*"2]BR O M3$5&5&1I86=O;F%L(&9I;F1F;VYT('!A='1EPH)+V1O7V9I;&P@=')U92!D968* M"2]BR O4DE'2%1D:6%G;VYA;"!F:6YD9F]N="!P871T97)N M9FEL;"!](&)I;F0@9&5F"GT*8FEN9"!D968*+V)R=7-H7V1I86=CB!["@DO9&]?9FEL;"!TPH)+V1O7V9I;&P@=')U92!D968* M"2]BR O8W)OR!BR!N97=P871H('T*"6EF96QS90I](&)I;F0@9&5F"@HE(%A65"=S(&UO M=F5?=&\*)2!5"!Y(&UV"B]M=B!["@EM;W9E=&\*?2!B:6YD(&1E M9@H*)2!85E0G"!Y(&1L"B]D;"!["@EL M:6YE=&\@8W5R6QI;F5S(&%N9"!P;VQY9V]N"!Y(&(*)0D)"7@@>2!L"B4)"0DN+BX@2!D;"!;9F]R('!O;'EL:6YE70HE"0D)>"!Y(&1G(%MF;W(@<&]L M>6=O;ET*+V(@>PH);6]V971O"GT@8FEN9"!D968*+VP@>PH);&EN971O"GT@ M8FEN9"!D968*+V1G('L*"6QI;F5T;PH)8VQO"!,3'D@9')R"B]DPH))2!#86XG="!U"!D968*"71R M86YS;&%T90H),B!I;F1E>" Q(&EN9&5X('-C86QE"@ED:78@+V@@97AC:"!D M968*"61I=B O=R!E>&-H(&1E9@H),2 P(&UO=F5T;PH)=R P('<@,2 Q(&%R M8W1O(#0@>R!P;W @?2!R97!E870*"7<@:"!W(#$@R!P;W @?2!R97!E870* M"6-L;W-E<&%T: H)"!S971M871R:7@*"6=S879E(&-F:6QL M(&=R97-T;W)E(&-S=')O:V4*?2!B:6YD(&1E9@H*)2!85E0G')A9"!Y" U M(&EN9&5X(&5L;&EP')A9"!YPH)+WDR(&5X M8V@@9&5F"@DO>#(@97AC:"!D968*"2]Y,2!E>&-H(&1E9@H)+W@Q(&5X8V@@ M9&5F"@DO>3 @97AC:"!D968*"2]X,"!E>&-H(&1E9@H)+WER(&5X8V@@9&5F M"@DO>'(@97AC:"!D968*"7DQ('DP('-U8B!X#$@># @'(@;75L('@R('@P('-U8B!Y')A9"!Y')A9"!Y2!D= HE($QI;6ET871I;VYS.B!I9VYO71E71E+B!4:&5R92!S:&]U;&0@8F4@87,@;6%N>2!G MR!C=7)R96YT9FEL92!$871A M4W1R:6YG(')E861H97AS=')I;F<@<&]P('T*"6)I;F0@:6UA9V4*"6=R97-T M;W)E"GT@8FEN9"!D968*"B4@1F-N('1O('-E="!P96X@=VED=&@*)2!5PH)9'5P"@DO9&]?"!N96<@," P(%T@;6%K969O;G0@; Fri, 20 Jan 95 01:08:26 -0500 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Fri, 20 Jan 95 01:08:13 -0500 Received: from inet-tsb.toshiba.co.jp by sicmail.epfl.ch with SMTP (PP) id <24631-0@sicmail.epfl.ch>; Fri, 20 Jan 1995 06:52:58 +0100 Received: from tis2.tis.toshiba.co.jp (tis2) by inet-tsb.toshiba.co.jp (5.67+1.6W/2.8Wb) id AA28692; Fri, 20 Jan 95 14:51:43 JST Received: from tis10.tis.toshiba.co.jp (tis10) by tis2.tis.toshiba.co.jp (5.67+1.6W/6.4J.6-R05) id AA22430; Fri, 20 Jan 95 14:52:13 JST Received: by tis10.tis.toshiba.co.jp (5.67+1.6W/6.4J.6-MHS-CNTML-R1) id AA09906; Fri, 20 Jan 95 14:52:34 JST Date: Fri, 20 Jan 95 14:04:00 JST From: 000092040542@tg-mail.toshiba.co.jp Return-Path: <000092040542@tg-mail.toshiba.co.jp> Message-Id: <9501200552.AA09906@tis10.tis.toshiba.co.jp> To: Olli.Fischer@rt.bosch.de To: 1076-1@epfl.ch Cc: vhdlbpeldo@anacad.de Cc: vhdlbpeldo@anacad.fr Cc: 100210.620@compuserve.com Cc: renderings@anacad.com Cc: jvlwg@nttica.ntt.jp Cc: jvl-analog@nttica.ntt.jp Subject: (Validation) Differential MSK X-Suppress-Info: On X-Recv-Id: Dear VHDL-A validation members, I will send Differential MSK description by "HDL-A". Following the "rules for examples" proposed by Mr. Oliver, I give comments on DMSK modeling as much as possible, and will send the stimula and expected results (uuencoeded post script file) by other mails at the same time. I hope my example will promote validation work: my intension is to give the test description of "analog behaviour selection" which has multiple ARCHITECTURE (Massey's, Rimoldi's, de Buda's) for single ENTITY. Current usage of HDL-A comes from the fact that I am not so familier with the sematics of currently proposed LES. Writing is easy, but conviction of modeling is difficult. I found the "list of validation examples" in repository /incoming/vhdl/analog/validation..., but none of descriptions. If possible, could you send your examples to me, or open them by showing in repository? I'm sorry for that I can understand/learn only "operational sematics" by available and executable description not by LES, a denotational semantics (whose denotation is still not clear for me). Surely, your examples will grately help many people who wish to join your work. Anyway, after reading "white papers", I would like to write VHDL-A. Best regards, ------------------------------------------------------ Hisashi Sasaki, Ph.D. Specialist BIPOLAR ANALOG DESIGN AUTOMATION, TOSHIBA CORPORATION 580-1, HORIKAWA-CHO, SAIWAI-KU, KAWASAKI 210, JAPAN PHONE: +81-44-548-2604 FAX: +81-44-548-8305 E-MAIL: 000092040542@tg-mail.toshiba.co.jp (office) sasaki@roku.eec.toshiba.co.jp (computer room) PXI04522@niftyserve.or.jp (home) ------------------------------------------------------ ------------------------dmsk.hdla----------------------------------------- -- TITLE: Differential MSK(Minimum Shift Keying) -- AUTHOR: Hisashi Sasaki, TOSHIBA -- e-mail: 000092040542@tg-mail.toshiba.co.jp -- sasaki@roku.eec.toshiba.co.jp -- DATE: 19.01.95 -- LASTUPDATE: 19.01.95 -- LANGUAGEVERSION: HDL-A v1.1.3a for sun4c -- CODESTATE: INVALID [VALID] -- HISTORY: -- Initial 12.12.94 [INVALID] -- learning DMSK and writing comments: -- 13.12.94, 14.12.94, 15.12.94, 16.12.94, -- 19.12.94, 20.12.94,(Christmas&NewYear holidays) -- 10.01.95, 11.01.95, -- debugging description: -- 11.01.95, 12.01.95, 13.01.95, 17.01.95, -- 18.01.95, 19.01.95, -- VALID for massey,rimoldi,de_buda -- need to learn "amoroso & kivetti"... -- esp. matched filter. -- -- DESCRIPTION: -- From: Bixio Rimoldi, "Five Views of Differential MSK: -- A Unified Approach", pp. 333-342. -- COMMUNICATIONS AND CRYPTOGRAPHY, Two Sides of One -- Tapestry, Blahut/Costello/Maurer/Mittelholzer, -- Kluwer Academic Publishers, 1994. -- ISBN: 0-7923-9469-0. -- -- DMSK is an outstanding modulation scheme since it has -- qualities that makes it important for practical applications -- as well as for theoretical study. It is of interest for study -- because it can be examined from (at least) five points of view, -- each one giving different insight and suggesting alternative -- implementations. Briefly, these five points of view can be -- summarized as follows: (1) DMSK is a continous-phase -- frequency shift keying (CPFSK) modulation scheme; (2) (Massey) -- DMSK is a special case of a set of encoded modulation scheme -- that has an optimum demodulator that needs to process the -- received signal over only two symbol intervals; (3) (Rimoldi) -- DMSK is a form of diversity modulation; (4) (de Buda) DMSK -- is a special form of offset quadrature phase shift keying -- (OQPSK) modulation; (5) (Amoroso and Kivett) DMSK is a -- special case of antipodal modulation. -- -- (1) CPFSK approach: the concept of DMSK ============================= -- The MSK signal can be described by -- s(t, U) := root(2*E/T) * cos(twopi*f0*t + phi(t,U)), t>=0, -- where -- phi(t,U) := pi*Vn + pi* (t-n*T)*Un/T, 0<=t-n*T| | -- | | memoryless |--->s(t) -- | +---+ V n | modulator | -- U n+1 >---+--(+)-->| T |--+---->| | -- ^ +---+ | +------------+ -- | | -- +-----------+ -- [Fig. 1: MSK transmitter] -- -- transfer function of Fig.1 encoder is [1, D/(1-D)]: -- -- [U n] = [1, D/(1-D)] [U n+1] -- [V n] [U n+1] -- -- Precode MSK by (1-D); i.e., U n+1 == (1-D) * V n+1, -- -- [U n] = [1-D, D] [U n+1 /(1-D)] -- [V n] [U n+1 /(1-D)] -- -- = [1-D, D] [V n+1] -- [V n+1] -- -- = [1+D, D] [V n+1] because D+D==0 -- [V n+1] -- -- The resulting modulation is denoted differential minimum shift -- keying (DMSK) and it can be implemented in Figure 2: -- -- U n +------------+ -- +--------->(+)------->| | -- | ^ | memoryless |--->s(t) -- | +---+ | V n | modulator | -- V n+1 >---+--| T |----+-------->| | -- +---+ +------------+ -- [Fig. 2: (D)MSK transmitter] -- -- +--------------+----------------------------------------+------------+ -- | V n+1 V n | OUTPUT | W n+1 W n | -- +--------------+----------------------------------------+------------+ -- | S0: 0 0 | S0(tau):=root(2*E/T)*cos(twopi*f0*tau) | 1 1 | -- | S1: 1 0 | S1(tau):=root(2*E/T)*cos(twopi*f1*tau) | -1 1 | -- | S2: 1 1 | S2(tau):= -S0(tau) | -1 -1 | -- | S3: 0 1 | S3(tau):= -S1(tau) | 1 -1 | -- +--------------+----------------------------------------+------------+ -- [ Table Input/Output relationship ] -- f0 * T == integer for simplification -- f1 := f0 + 1/(2*T) -- tau := t - n*T -- -- -- -- V n-1 V n V n+1 -- -- S2 S2 S2 -- 1 +--------+--------+--------+ -- \ / \ / \ / -- \ / \ / \ / -- S3 \ / S3 \ / S3 \ / -- \/ \/ \/ -- /\ /\ /\ -- S1 / \ S1 / \ S1 / \ -- / \ / \ / \ -- / \ / \ / \ -- 0 +--------+--------+--------+ -- S0 S0 S0 -- State Trellis diagram (State Sequence diagram) -- -- Receiver: Viterbi decoder by the metric "lambda" -- -- The maximum-likelihood estimator for the state sequence is -- achieved by the Viterbi decoder. -- -- The branch metric -- / n*T+T -- lambda(n, Si) == | r(t)*Si(t-n*T) dt, i=0,1,2,3 -- / n*T -- -- is the correlation between the received signal r(t) and -- Si(t-n*T). -- -- -- -- (2) Massey's Implementation ========================================= -- -- -- V n-1 V n V n+1 -- -- S2 S2 S2 -- d e f -- 1 +--------+--------+--------+ -- \ / \ / \ / -- \ / \ / \ / -- S3 \ / S3 \ / S3 \ / -- \/ \/ \/ -- /\ /\ /\ -- S1 / \ S1 / \ S1 / \ -- / \ / \ / \ -- / \ / \ / \ -- 0 +--------+--------+--------+ -- a b c -- S0 S0 S0 -- -- We show the metrices associated with each path: -- V n-1 == 0 --> V n+1 == 0 (a->c) : -- V n == 0: a->b->c lambda(n-1, S0)+lambda(n, S0) -- V n == 1: a->e->c lambda(n-1, S1)+lambda(n, S3) -- =lambda(n-1, S1)-lambda(n, S1) by S3=-S1 -- V n-1 == 0 --> V n+1 == 1 (a->f) : -- V n == 0: a->b->f lambda(n-1, S0)+lambda(n, S1) -- V n == 1: a->e->f lambda(n-1, S1)+lambda(n, S2) -- =lambda(n-1, S1)-lambda(n, S0) by S2=-S0 -- V n-1 == 1 --> V n+1 == 0 (d->c) : -- V n == 0: d->b->c lambda(n-1, S3)+lambda(n, S0) -- =-lambda(n-1, S1)+labmda(n, S0) by S3=-S1 -- V n == 1: d->e->c lambda(n-1, S2)+lambda(n, S3) -- =-lambda(n-1, S0)-lambda(n, S1) by S3=-S1,S2=-S0 -- V n-1 == 1 --> V n+1 == 1 (d->f) : -- V n == 0: d->b->f lambda(n-1, S2)+lambda(n, S2) -- =-lambda(n-1, S0)-labmda(n, S0) by S2=-S0 -- V n == 1: d->e->f lambda(n-1, S3)+lambda(n, S1) -- =-lambda(n-1, S1)+lambda(n, S1) by S3=-S1 -- -- For V n == 0 estimation, the metric of (Vn==0) must be grater than -- the metric of (Vn==1), i.e., -- path metric of (V n == 0) metric of (V n ==1) -- ---- --------------------------- ---------------------------- -- a->c: lambda(n-1,S0)+lambda(n,S0) > lambda(n-1,S1)-lanmda(n,S1) -- a->f: lambda(n-1,S0)+lambda(n,S1) > lambda(n-1,S1)-lambda(n,S0) -- d->c: -lambda(n-1,S1)+lambda(n,S0) > -lambda(n-1,S0)-lambda(n,S1) -- d->f: -lambda(n-1,S0)-lambda(n,S1) > -lambda(n-1,S1)+lambda(n,S1) -- -- In fact, all these "decisions" are eventually equivalent to -- -- +--------------------- Massey's test ---------------------------+ -- | V n == 0 ( W n == 1 ) iff | -- | lambda(n-1,S0)+lambda(n,S0)+lambda(n,S1)-lambda(n-1,S1) > 0 | -- +---------------------------------------------------------------+ -- -- -- -- Then we have: -- -- S1(t-n*T) -- | +----------+ -- V | | -- +--------+ | +---+ v+ +lambda(n,S1) -- +-->(x)-->| integ1 |-+->| T |->(+)--+ +-----+ -- | +--------+ +---+ - | | +- | -- | -lambda(n-1,S1) v | | | ^ -- r(t) >--+ (+)-->| -+- |--> W n -- | +lambda(n-1,S0) ^ | | | -- | +--------+ +---+ + | | -+ | -- +-->(x)-->| integ1 |-+->| T |->(+)--+ +-----+ -- +--------+ | +---+ ^+ +lambda(n,S0) -- ^ | | -- | +----------+ -- S0(t-n*T) -- integ1:= integ(from n*T to (n+1)*T) -- -- [Fig. 3-a Massey's Receiver] -- -- -- The above receiver suggests the following transmitter: -- -- S1(t-n*T)/2 -- | -- - v -- +------>(+)------>(x)--+ -- | ^ + | -- | +---+ | v -- W n >-->+-| T |--+ (+)---> s(t) -- | +---+ | ^ -- | v + | -- +------>(+)------>(x)--+ -- + ^ -- | -- S0(t-n*T)/2 -- -- [Fig. 3-b Massey's Transmitter] -- -- -- -- (3) Rimoldi's diversity Implementation ============================== -- -- [ The above "Massey's test": ] -- [ lambda(n-1,S0)+lambda(n,S0)+lambda(n,S1)-lambda(n-1,S1) > 0 ] -- -- "Front end" correlator in Massey's receiver determines -- lambda(n,S0) and lambda(n,S1) -- Another possiblity is to have correlators that outputs -- lambda(n,S0)+lambda(n,S1) and lambda(n,S0)-lambda(n,S1) -- suggesting following receiver: -- -- -- S0(t-n*T) - S1(t-n*T) -- | -- | lambda(n,S0)-lambda(n,S1) -- V lambda(n-1,S0)-lambda(n-1,S1) -- +--------+ +---+ -- +-->(x)-->| integ1 |--->| T |-------+ +-----+ -- | +--------+ +---+ | | +- | -- | v | | | ^ -- r(t) >--+ (+)-->| -+- |--> W n -- | ^ | | | -- | +--------+ | | -+ | -- +-->(x)-->| integ1 |----------------+ +-----+ -- +--------+ -- ^ lambda(n,S0)+lambda(n,S1) -- | -- S0(t-n*T) + S1(t-n*T) -- integ1:= integ(from n*T to (n+1)*T) -- -- [Fig. 4-a Rimoldi's diversity Receiver] -- -- An intersting interpretation of this implementation is that -- DMSK is a form of diversity transmission. Indeed, the -- infomation symbol Wn is transmitted twice: -- S0(tau)-S1(tau) -- S0(tau)+S1(tau) -- two are orthogonal over intervals; i.e., -- {S0(tau)-S1(tau)} * {S0(tau)+S1(tau)} -- = S0(tau)**2 - S1(tau)**2 -- gives -- / T -- | {S0(tau)-S1(tau)}*{S0(tau)+S1(tau)} d(tau) = 0 -- / 0 -- (by equality of signals energy) -- -- -- -- {S0(t-n*T) - S1(t-n*T)} / 2 -- | -- v -- +-------------->(x)-----+ -- | | -- | +---+ v -- W n >-->+-| T |-------->(x)--->(+)---> s(t) -- +---+ ^ -- | -- {S0(t-n*T) + S1(t-n*T)} / 2 -- -- [Fig. 4-b Rimoldi's diversity Transmitter] -- -- -- -- (4) de Buda's parallel Implementation =============================== -- -- A third way to implement "Massey's test" is to compute the -- exprerssioin by means of a single integral, i.e., -- -- lambda(n-1,S0)+lambda(n,S0)-lambda(n-1,S1)+lambda(n,S1) -- -- / (n+1)*T -- = | r(t)*S(t-(n-1)*T) dt -- / (n-1)*T -- -- where -- S(t) := S0(t) - S1(t) + S0(t-T) + S1(t-T). -- -- +-----------------------------------------------------------+ -- | Assuming f:= f0 + 1/(4*T) and n is even, | -- | S(t-(n-1)*T) == root(8*E/T)*cos(twopi*f*T)*cos(pi*t/2/T) | -- | for (n-1)*T<=t<(n+1)*T | -- | S(t-n*T) == root(8*E/T)*sin(twopi*f*T)*sin(pi*t/2/T) | -- | for n*T<=t<(n+2)*T | -- +-----------------------------------------------------------+ -- [Proof] -- For n*T<=t<(n+1)*T, -- S1(t-n*T) = root(2*E/T)*cos(twopi*f1*(t-n*T)) -- = +/- root(2*E/T)*cos(twopi*f1*t) +/-: n is even/odd, -- S0(t-n*T) = root(2*E/T)*cos(twopi*f0*(t-n*T)) -- = root(2*E/T)*cos(twopi*f0*t) -- -- Using these, ( A:=root(2*E/T) ) -- For (n-1)*T<=t<(n+1)*T, -- S(t-(n-1)*T) -- = S0(t-(n-1)*T) - S1(t-(n-1)*T) -- + S0(t-n*T) + S1(t-n*T) -- = A * { cos(twopi*f0*t) - (-/+)*cos(twopi*f1*t) -- +cos(twopi*f0*t) + (+/-)*cos(twopi*f1*t) } -- = 2*A * { cos(twopi*f0*t) + cos(twopi*f1*t) } -- = 4*A*cos(twopi*(f0+f1)*t/2)*cos(twopi*(f0-f1)*t/2) -- = 4*A*cos(twopi*f*t)*cos(pi*t/2/T)) -- by f0+f1=f0+f0+1/(2*T)=2*(f0+1/(4*T))=2*f -- f1-f0=1/(4*T) -- = root(8*E/T)*cos(twopi*f*t)*cos(pi*t/T/2) -- -- For n*T<=t<(n+2)*T, -- S(t-n*T) -- = S0(t-n*T) - S1(t-n*T) + S0(t-(n+1)*T) + S1(t-(n+1)*T) -- = A * { cos(twopi*f0*t) - (+/-)*cos(twopi*f1*t) -- +cos(twopi*f0*t) + (-/+)*cos(twopi*f1*t) } -- = 2*A * { cos(twopi*f0*t) - cos(twopi*f1*t) } -- = 4*A*(-1)*sin(twopi*(f0+f1)*t/2)*sin(twopi*(f0-f1)*t/2) -- = 4*A*sin(twopi*f*t)*sin(pi*t/2/T)) -- = root(8*E/T)*sin(twopi*f*t)*sin(pi*t/T/2) -- [End of Proof] -- -- Then, we have: -- -- S(t-(n-1)*T) = root(8*E/T)*cos(pi*t/2/T)*cos(twopi*f*t) -- | -- V -- +--------+ +-------+ ^ -- +-->(x)-->| integ2 |----->| det |-----> W n -- | +--------+ +-------+ -- | -- r(t) >--+ -- | -- | +--------+ +-------+ ^ -- +-->(x)-->| integ3 |----->| det |-----> W n+1 -- +--------+ +-------+ -- ^ -- | -- S(t-n*T) = root(8*E/T)*sin(pi*t/2/T)*sin(twopi*f*t) -- -- integ2:= integ(from (n-1)*T to (n+1)*T) -- integ3:= integ(from n*T to (n+2)*T) -- det:= if x>0 then 1 else -1 (below) -- -- +-----+ -- | +- | -- +--------+ | | | -- --->| det |---> == --->| -+- |---> -- +--------+ | | | -- | -+ | -- +-----+ -- -- [Fig. 5-a. de Buda's receiver] -- -- -- Now we will review de Buda's implementation as an "offset QPSK": -- -- cos(twopi*f0*tau) = cos(twopi*f0*(t-n*T)) -- = +/- cos(twopi*f0*t) n: even/odd -- cos(twopi*f1*tau) = cos(twopi*(f+1/4/T)*(t-n*T)) -- = +/- cos(twopi*(f+1/4/T)*t) n: even/odd -- = +/- {cos(twopi*(f-1/4/T)*t)*cos(pi/2) -- +sin(twopi*(f-1/4/T)*t)*sin(pi/2) } -- = +/- sin(twopi*(f-1/4/T)*t) -- = +/- sin(twopi*f0*t) -- -- +-----------------------------------------------+------------+ -- | OUTPUT | W n+1 W n | -- +-----------------------------------------------+------------+ -- | S0(tau):= (+/-) root(2*E/T)*cos(twopi*f0*t) | 1 1 | -- | S1(tau):= (+/-) root(2*E/T)*sin(twopi*f0*t) | -1 1 | -- | S2(tau):= -S0(tau) | -1 -1 | -- | S3(tau):= -S1(tau) | 1 -1 | -- +-----------------------------------------------+------------+ -- [ Table Input/Output relationship ] -- -- Q V n+1, V n W n+1, W n -- ^ odd even ^ -- | S1 | -- X S1 | S0 -- S2 | S0 | -- --O---+---O--> I -------+-------> -- | cos(twopi*f0*t) | -- X S2 | S3 -- | S3 | -- -- [Fig. constellation for n==even] -- -- Q V n+1, V n W n+1, W n -- ^ even odd ^ -- | S3 | -- X S3 | S2 -- S0 | S2 | -- --O---+---O--> I -------+-------> -- | cos(twopi*f0*t) | -- X S0 | S1 -- | S1 | -- -- [Fig. constellation for n==odd] -- -- Thus, DMSK can be seen as a special case of OQPSK: -- W n+1 and W n make QPSK configration, -- W n+1 and W n has offset. -- (The rotation means that QPSK has an offset by pi(=T).) -- -- -- {S(t-(n-1)*T)}/2 = root(2*E/T)*cos(pi*t/2/T)*cos(twopi*f*t) -- | -- W n | -- +-------+ v -- | | ---->(x)-----+ -- ---+---+---+---+---> | -- (n-1)*T (n+1)*T v -- (+)---> s(t) -- W n+1 ^ -- +-------+ | -- | | ---->(x)-----+ -- ---+---+---+---+---> ^ -- n*T (n+2)*T | -- | -- {S(t-n*T)}/2 = root(2*E/T)*sin(pi*t/2/T)*sin(twopi*f*t) -- -- [ Fig.5-b. de Buda's transmitter] -- -- -- -- (5) Amoroso and Kivett's serial implementation ====================== -- -- The expression of Massey's test can be computed by means of a -- matched filter with impluse response h(t). -- -- -- +-------+ \ -- | | \ +-----+ ^ -- r(t) ---->| h(t) |---- ----| det |----> W n -- | | (n+1)*T +-----+ -- +-------+ -- -- h(t) := S( Td-t ), Td-2*T<= t <=Td -- 0, otherwise -- -- where Td is some delay such that Td >= 2*T -- -- [Fig. 6-a Amoroso and Kivetti's Receiver; assumed Td==2*T] -- -- -- waveform is NOT faithful -- ^ ^ -- | | -- 1 - +---+ +---+ | .-. .-. -- + | | | | + / \ / \ -- -1 +--+ +---+ +----------- |--' `-' `----+---+--- -- | -- ^ ^ ^ ^ ^ ^ ^ -- | | | | | | | -- sampling by "det" -- 0 1 0 1 0 0 0... 0 1 0 1 0 0 0... -- -- -- INPUT BIT STREAM: OUTPUT BIT STREAM: h(t) -- -- [ Fig. Response of filter h(t) ] -- -- DMSK can be seen as a special form of antipodal modulation. -- It is special in that S(tau) has duration 2*T and, therfore -- pulse translates overlap. However, this has no effects on -- the performance of the matched filter receiver since S(tau) -- is orthogonal to S(tau-T): -- -- S(tau)*S(tau-T) = [S0(t-T)+S1(t-T)]*[S0(t-T)-S1(t-T)] -- = S0(t-T)**2 - S1(t-T)**2 -- and S0(t-T) and S1(t-T) are equal energy pulses, -- / T -- | S(tau)*S(tau-T) d(tau) = 0 -- / 0 -- -- -- W n+1 W n -- ^ ^ -- | | +------------+ -- | | | | -- ---+-----+----->| S(t)/2 |-----> s(t) -- <-----> | | -- T +------------+ -- [Fig. 6-b Amoroso and Kivett's Transmitter] -- -- -- -- SCHEMATIC: -- None -- CODE: -- HDL-A Version v1.1.3a for sun4c -- STIMULI: -- See "dmsk_in1" and "dmsk_clk" below. -- they are generator of stimuli. -- EXPECTED_RESULTS: -- Uuencoded PostScript: -- massey1.ps.uue, massey2.ps.uue -- rimoldi1.ps.uue, rimoldi2.ps.uue -- de_buda1.ps.uue, de_buda2.ps.uue -- RESULTS: -- SIMULATION_ENGINE: VESIM V2.1.2d -- DATE: 20.01.95 -- RESULT_STATE: INVALID [VALID] -- ... -- PROBLEM_LOG: -- --------------------------------------------------------------------- -- Generator of inputs and Clock for testing: STIMULI --------------------------------------------------------------------- ENTITY dmsk_in1 IS PORT(in1 : OUT BIT); END ENTITY dmsk_in1; ARCHITECTURE d1 OF dmsk_in1 IS SIGNAL in1q : BIT; BEGIN PROCESS BEGIN -- assume symbol interval T is 100ns in1q <= '0', '1' AFTER 100ns, '1' AFTER 200ns, '1' AFTER 300ns, '0' AFTER 400ns, '1' AFTER 500ns, '0' AFTER 600ns, '1' AFTER 700ns, '0' AFTER 800ns, '0' AFTER 900ns, '1' AFTER 1000ns, '0' AFTER 1100ns; in1 <= in1q; L1: LOOP WAIT FOR 100ns; in1 <= in1q; END LOOP; END PROCESS; END ARCHITECTURE d1; ENTITY dmsk_clk IS PORT(clk : OUT BIT); END ENTITY dmsk_clk; ARCHITECTURE d1 OF dmsk_clk IS SIGNAL clkq : BIT; BEGIN PROCESS BEGIN -- assume symbol interval T is 100ns clk <= '1', '0' AFTER 50ns; clkq <= '1', '0' AFTER 50ns; L1: LOOP WAIT FOR 50ns; clkq <= not clkq; clk <= clkq; END LOOP; END PROCESS; END ARCHITECTURE d1; --------------------------------------------------------------------- -- W n generator: 19.12.94, 12.01.95 --------------------------------------------------------------------- ENTITY wn_gen IS GENERIC( mag : REAL ); PORT( in1, clk : IN BIT); PIN( wn : ELECTRICAL); END ENTITY wn_gen; ARCHITECTURE m1 OF wn_gen IS SIGNAL vn_previous, -- privious "vn" vn : BIT; -- differential input of "in1" BEGIN PROCESS BEGIN vn <='0'; L1: LOOP WAIT FOR 100ns; -- WAIT ON clk: currently not supported yet vn <= in1 XOR vn; -- by HDL-A END LOOP; -- L1 END PROCESS; RELATION PROCEDURAL FOR INIT=> wn.v %= mag; PROCEDURAL FOR TRANSIENT => IF vn='1' THEN wn.v %= mag; ELSE -- vn='0' wn.v %= - mag; END IF; END RELATION; END ARCHITECTURE m1; --------------------------------------------------------------------- -- Differential MSK Modulator: 19.12.94 - 19.01.95, --------------------------------------------------------------------- ENTITY dmsk_mod IS GENERIC ( omega0, -- lower osc. omega1, -- higher osc. mag -- amplitude : REAL); PORT(clk : IN BIT); PIN(wn, m_out : ELECTRICAL); -- wn: INPUT, m_out: OUTPUT END ENTITY dmsk_mod; ------------------------ -- 19.12.94, 13.01.95 -- ------------------------ -- S1(t-n*T)/2==cos(omega1*t)/2.0 -- | -- - qq v q_out -- +------>(+)-------->(x)-------+ -- | ^ + | -- | +---+ | v -- wn >-->+-| T |--+ wn_previous (+)---> m_out -- | +---+ | ^ -- | v + | -- +------>(+)-------->(x)-------+ -- + ii ^ i_out -- | -- S0(t-n*T)/2==cos(omega0*t)/2.0 -- -- [Fig. 3-b Massey's Transmitter] -- ARCHITECTURE massey OF dmsk_mod IS VARIABLE symbol_start_time, -- time when symbol starts delta_time -- current_time-symbol_start_time : REAL; -- VARIABLE even_odd : INTEGER; -- 0/1 for even/odd STATE wn_previous, -- previous value of wn wn_current, -- to save wn_previous for clk duration ii, qq, i_out, q_out -- intermidiate quantities : ANALOG; -- described above. BEGIN RELATION PROCEDURAL FOR INIT => symbol_start_time := 0.0; delta_time := 0.0; wn_previous := wn.v; PROCEDURAL FOR DC => NULL; PROCEDURAL FOR TRANSIENT => IF event(clk) AND clk='1' THEN symbol_start_time := current_time; wn_previous := wn_current; wn_current := wn.v; END IF; -- END OF "event(clk) AND clk='1'" delta_time := current_time - symbol_start_time; ii := wn_previous + wn.v; -- ASSERT (ii==2.0 XOR ii==0.0 XOR ii==-2.0) qq := wn_previous - wn.v; -- ASSERT (qq==2.0 XOR qq==0.0 XOR qq==-2.0) -- ASSERT (ii==0.0 XOR qq==0.0) i_out := ii*cos(omega0*delta_time)/2.0; q_out := qq*cos(omega1*delta_time)/2.0; m_out.v %= mag * (i_out + q_out); END RELATION; END ARCHITECTURE massey; -- dmsk_mod ------------------------ -- 10.01.95, 17.01.95 -- ------------------------ -- {S0(t-n*T) - S1(t-n*T)} / 2 == (S0 - S1)/2.0 -- | -- v q_out -- +-------------------->(x)---------+ -- | | -- | +---+ wn_previous v -- wn >-->+-| T |-------------->(x)------->(+)---> m_out -- +---+ ^ i_out -- | -- {S0(t-n*T) + S1(t-n*T)} / 2 == (S0 + S1)/2.0 -- -- [Fig. 4-b Rimoldi's diversity Transmitter] -- ARCHITECTURE rimoldi OF dmsk_mod IS VARIABLE symbol_start_time, -- time when symbol starts delta_time -- current_time-symbol_start_time : REAL; STATE wn_previous, -- previous value of wn wn_current, -- to save previous value ii, qq, -- intermidiate quantities as above S0, S1, -- i_out, q_out -- : ANALOG; BEGIN RELATION PROCEDURAL FOR INIT => symbol_start_time := 0.0; delta_time := 0.0; wn_previous := 0.0; PROCEDURAL FOR DC => NULL; PROCEDURAL FOR TRANSIENT => IF event(clk) AND clk='1' THEN symbol_start_time := current_time; delta_time := 0.0; wn_previous := wn_current; wn_current := wn.v; END IF; -- END OF "event(clk) AND clk='1'" S0 := cos(omega0*(current_time-symbol_start_time)); S1 := cos(omega1*(current_time-symbol_start_time)); i_out := wn_previous * (S0 + S1)/2.0; q_out := wn.v * (S0 - S1)/2.0; m_out.v %= mag * (i_out + q_out); END RELATION; END ARCHITECTURE rimoldi; -- dmsk_mod ---------------------------------- -- 10.01.95, 17.01.95, 19.01.95 -- ---------------------------------- -- {S(t-(n-1)*T)}/2 = root(2*E/T)*cos(pi*t/2/T)*cos(twopi*f*t) -- | -- W 2: wn_even | -- ---+---+---+---+--- v q_out -- 0 | 2 | 2 | 4 | 4 ---->(x)-----+ -- ---+---+---+---+---> | -- T 3*T v -- (+)---> s(t) -- W 3: wn_odd ^ -- ---+---+---+---+--- | -- 1 | 1 | 3 | 3 | 5 ---->(x)-----+ -- ---+---+---+---+---> ^ i_out -- 2*T 4*T | -- | -- {S(t-n*T)}/2 = root(2*E/T)*sin(pi*t/2/T)*sin(twopi*f*t) -- -- [ Fig.5-b. de Buda's transmitter] -- ARCHITECTURE de_buda OF dmsk_mod IS VARIABLE omegac, -- time when symbol starts omegat, -- current_time-symbol_start_time n -- number of freqency ratio : REAL; STATE even_odd, -- wn_odd, -- previous value of wn wn_even, -- to save previous value ii, qq, -- intermidiate quantities as above Ccos, Ssin, -- i_out, q_out -- : ANALOG; BEGIN RELATION PROCEDURAL FOR INIT => omegac := (omega1 + omega0) / 2.0 ; -- f1+f0==2*f omegat := (omega1 - omega0) / 2.0 ; -- n==2.0 even_odd := 0.0; wn_even:= -1.0; wn_odd := -1.0; PROCEDURAL FOR DC => NULL; PROCEDURAL FOR TRANSIENT => IF event(clk) AND clk='1' THEN IF even_odd = 1.0 THEN wn_even := wn.v; -- wn_odd not changed even_odd := 0.0; ELSE wn_odd := wn.v; -- wn_even not changed even_odd := 1.0; END IF; END IF; -- event(clk) AND clk='1' Ccos := cos(omegat*current_time)* cos(omegac*current_time); Ssin := sin(omegat*current_time)* sin(omegac*current_time); q_out := wn_even * Ccos; i_out := wn_odd * Ssin; m_out.v %= mag * (i_out + q_out); END RELATION; END ARCHITECTURE de_buda; -- dmsk_mod --------------- -- 17.01.95, -- [INVALID] --------------- -- W n+1 W n -- ^ ^ -- | | +------------+ -- | | | | -- ---+-----+----->| S(t)/2 |-----> s(t) -- <-----> | | -- T +------------+ -- [Fig. 6-b Amoroso and Kivett's Transmitter] -- -- -- -- Oversampling ratio: 4, -- -- delayed1 delayed2 delayed3 -- wn>-------+--------+--------+--------+ -- | | | | -- | | | | -- v v v v -- *<- a0 *<- a1 *<- a2 *<- a3 -- | | | | -- v v v v -- +--------------------------------+ -- | + | -- +--------------------------------+ -- | -- +--------------------->s(t) -- ARCHITECTURE amo_kiv OF dmsk_mod IS SIGNAL over_samp_clk, over_samp_clkq : BIT; -- oversampling clk VARIABLE start_symbol_time, delta_time, omegat, omegac, a0, a1, a2, a3 -- coeficient for matched filter h(t) : REAL; VARIABLE over_samp_time: REAL; -- oversampling time VARIABLE delayed1, delayed2, delayed3 : ANALOG; STATE wn_previous, wn_current, Csin, Ssin, m_current, m_previous : ANALOG; BEGIN -- PROCESS ------ MUST BE IMPLEMENED BY "ROMs" not by filter!!!! -- BEGIN -- over_samp_clk <= '0'; -- over_samp_clkq <= '1'; -- L1: LOOP -- WAIT FOR time(over_samp_time); -- over_samp_clkq <= not over_samp_clkq; -- over_samp_clk <= over_samp_clkq; -- END LOOP; -- END PROCESS; RELATION PROCEDURAL FOR INIT => delayed1 := 0.0; delayed2 := 0.0; delayed3 := 0.0; a0 := 1.0; -- a1 := 1.0; -- a2 := 1.0; -- a3 := 1.0; -- start_symbol_time := 0.0; delta_time := 0.0; wn_previous := 0.0; omegac := (omega1 + omega0) / 2.0; omegat := (omega1 - omega0) / 2.0; -- n==2.0 PROCEDURAL FOR DC => NULL; PROCEDURAL FOR TRANSIENT => -- to be considered more !!! -- S(t) is to be implemnented by transversal filter. Is it right ? -- oversampling rate: 3 -- filter coefficients: a0, a1, a2, a3, -- delta_time := current_time-start_symbol_time; IF event(clk) AND clk='1' THEN start_symbol_time := current_time; wn_previous := wn_current; wn_current := wn.v; END IF; Csin := cos(omegat*current_time)*sin(omega1*current_time); Ssin := sin(omegat*current_time)*sin(omega1*current_time); m_current := wn_current*Csin; m_previous := wn_previous*Ssin; m_out.v %= m_previous + m_current; END RELATION; END ARCHITECTURE amo_kiv; ------------------------------------------------------------------- -- Differential MSK Demodulator: 19-20.12.94, 11-19.01.95 ------------------------------------------------------------------- ENTITY dmsk_demod IS GENERIC( omega0, -- equals to "omega0" of the above modulator omega1, -- "omega1" mag, -- amplitude of estimated "wn" det_thres -- threshold to decide : REAL); PORT( clk : IN BIT); -- clock PIN( m_out, -- modulated input d_out -- demodulated output : ELECTRICAL); END ENTITY dmsk_demod; ------------------------- -- 19.12.94, 12.01.95, -- ------------------------- -- S1(t-n*T)==cos(omega1*t) -- | qq -- | +----------+ -- V | | -- +--------+ | +---+ v+ -- +->(x)-q->| integ1 |-+->| T |->(+)--+ qq-qq_old -- | +--------+ +---+ - | -- | qq_old v +-----+ ^ -- r(t) >--+ (+)-->| det |--> W n -- | ii_old ^ +-----+ -- | +--------+ +---+ + | -- +->(x)-i->| integ1 |-+->| T |->(+)--+ ii+ii_old -- +--------+ | +---+ ^+ -- ^ | | -- | +----------+ -- | ii -- S0(t-n*T)==cos(omega0*t) -- integ1:= integ(from n*T to (n+1)*T) -- -- [Fig. 3-a Massey's Receiver] -- ARCHITECTURE massey OF dmsk_demod IS VARIABLE symbol_start_time, -- delta_time -- : REAL; STATE i, q, -- i1, q1, -- for reset (work-around) ii, qq, -- In-phase/Quadrature Integral ii_old, qq_old, -- privoues value of ii and qq ii_current, qq_current, -- to save previous sum -- ii_old+ii_current+qq-qq_current : ANALOG; BEGIN RELATION PROCEDURAL FOR INIT => symbol_start_time := 0.0; delta_time := 0.0; i := 0.0; q := 0.0; i1 := 0.0; q1 := 0.0; ii := 0.0; -- initial for In-phase integral qq := 0.0; -- initial for Quadrant integral ii_old := 0.0; qq_old := 0.0; d_out.v %= 0.0; PROCEDURAL FOR DC => NULL; PROCEDURAL FOR TRANSIENT => delta_time := current_time - symbol_start_time; i := m_out.v * cos(omega0*(delta_time)); q := m_out.v * cos(omega1*(delta_time)); IF event(clk) AND clk='1' THEN symbol_start_time := current_time; delta_time := 0.0; sum := ii_current+ii_old+qq_current-qq_old; IF sum > det_thres THEN d_out.v %= mag; -- estimate wn==1 (vn==0) ELSE IF sum < -det_thres THEN d_out.v %= -mag; ELSE d_out.v %= 0.0; END IF; END IF; i1 := integ(i); -- sample and hold for work-around q1 := integ(q); -- sample and hold for work-around ii_old := ii_current; -- save for next clock ii_current := ii; qq_old := qq_current; -- save for next clock qq_current := qq; END IF; ii := integ(i)-i1; -- reset integ(i) by -i1 qq := integ(q)-q1; -- reset integ(q) by -q1 END RELATION; END ARCHITECTURE massey; ---------------------------------- -- 20.12.94, 17.01.95, 19.01.95 -- ---------------------------------- -- S0(t-n*T) - S1(t-n*T) == (S0 - S1) -- | -- V -- q +--------+ qq +---+ qq_old -- +-->(x)---->| integ1 |---->| T |----+ -- | +--------+ +---+ | -- | v +-----+ ^ -- r(t) >--+ (+)-->| det |--> W n -- | ^ +-----+ -- | +--------+ | -- +-->(x)---->| integ1 |--------------+ -- i +--------+ ii -- ^ -- | -- S0(t-n*T) + S1(t-n*T) == (S0 + S1) -- -- integ1:= integ(from n*T to (n+1)*T) -- -- [Fig. 4-a Rimoldi's diversity Receiver] -- ARCHITECTURE rimoldi OF dmsk_demod IS VARIABLE symbol_start_time, -- delta_time -- : REAL; STATE i, q, -- i1, q1, -- for reset use (work-around) S0, S1, -- cos(omega0*t) and sin(omega1*t) ii, qq, -- In-phase/Quadrature Integral qq_old, -- previous value of qq sum -- ii+qq_old : ANALOG; BEGIN RELATION PROCEDURAL FOR INIT => symbol_start_time := 0.0; delta_time := 0.0; i := 0.0; q := 0.0; i1:= 0.0; q1:= 0.0; ii:= 0.0; -- initial for In-phase integral qq:= 0.0; -- initial for Quadrant integral qq_old:=0.0; -- d_out.v %= 0.0; PROCEDURAL FOR DC => NULL; PROCEDURAL FOR TRANSIENT => delta_time := current_time - symbol_start_time; S0 := cos(omega0*delta_time); S1 := cos(omega1*delta_time); i := m_out.v * (S0 + S1); q := m_out.v * (S0 - S1); IF event(clk) AND clk='1' THEN symbol_start_time := current_time; delta_time := 0.0; sum := ii + qq_old; IF sum > det_thres THEN d_out.v %= mag; ELSE d_out.v %= -mag; END IF; i1 := integ(i); -- sample and hold q1 := integ(q); -- sample and hold qq_old:=qq; -- save for next clock END IF; ii := integ(i)-i1; -- reset integ(i) by -i1 qq := integ(q)-q1; -- reset integ(q) by -q1 END RELATION; END ARCHITECTURE rimoldi; ---------------------------------- -- 21.12.94, 17.01.95, 19.01.95 -- ---------------------------------- -- S(t-(n-1)*T) = root(8*E/T)*cos(twopi*t/4/T)*cos(twopi*f*t) -- | -- V -- q +--------+ qq +-------+ ^ -- +-->(x)----->| integ2 |------>| det |-----> W n -- | +--------+ +-------+ -- | d_out -- r(t) >--+ m_out -- | intentionally removing: d_out2 -- | (but not perfect functionality) -- | i +--------+ ii +-------+ ^ -- +-->(x)----->| integ3 |------>| det |-----> W n+1 -- +--------+ +-------+ -- ^ -- | -- S(t-n*T) = root(8*E/T)*sin(twopi*t/4/T)*sin(twopi*f*t) -- -- [Fig. 5-a. de Buda's receiver] -- ARCHITECTURE de_buda OF dmsk_demod IS -- VARIABLE even_odd: INTEGER; -- flag for even/odd: 0/1 VARIABLE omegac, -- center frequency omegat, -- pi/2/T n -- number of frequency ration : REAL; STATE i, q, -- i1, q1, -- for reset ii, qq, -- Integrals even_odd, Ssin, -- sin*sin Ccos -- cos*cos : ANALOG; BEGIN RELATION PROCEDURAL FOR INIT => omegac := (omega0 + omega1) / 2.0; -- f1+f0==2*f omegat := (omega1 - omega0) / 2.0 ; -- n==2.0 even_odd:= 0.0; i := 0.0; q := 0.0; i1:= 0.0; q1:= 0.0; ii:= 0.0; -- initial for In-phase integral qq:= 0.0; -- initial for Quadrant integral d_out.v %= 0.0; PROCEDURAL FOR DC => NULL; PROCEDURAL FOR TRANSIENT => Ssin := sin(omegat*current_time)* sin(omegac*current_time); Ccos := cos(omegat*current_time)* cos(omegac*current_time); i := m_out.v * Ssin; q := m_out.v * Ccos; IF event(clk) AND clk='1' THEN IF even_odd=1.0 THEN -- odd q1 := integ(q); -- sample and hold IF qq > det_thres THEN d_out.v %= mag; ELSE -- < det_thres d_out.v %= -mag; END IF; -- qq > det_thres even_odd := 0.0; ELSE -- even i1 := integ(i); -- sample and hold IF ii > det_thres THEN d_out.v %= mag; ELSE -- < det_thres d_out.v %= -mag; END IF; -- ii > det_thres even_odd := 1.0; END IF; -- even_odd END IF; -- event(clk) AND clk='1' -- reset integral for work-around: -- lack of "RESET" in HDL-A... ii := integ(i)-i1; -- reset integ(i) by -i1 qq := integ(q)-q1; -- reset integ(q) by -q1 END RELATION; END ARCHITECTURE de_buda; -------------- -- xx.yy.zz -- [INVALID] -------------- -- +-------+ \ -- | | s \ +-----+ ^ -- m_out ---->| h(t) |-------- ----| det |----> W n -- | | (n+1)*T +-----+ -- +-------+ -- -- [Fig. 6-a Amoroso and Kivetti's Receiver; assumed Td==2*T] -- ARCHITECTURE amo_kiv OF dmsk_demod IS SIGNAL over_samp_clk, over_samp_clkq : BIT; VARIABLE a0, a1, a2, a3 -- coeficient for matched filter h(t) : REAL; VARIABLE over_samp_time: REAL; -- oversampling time VARIABLE delayed1, delayed2, delayed3, s -- equalized output : ANALOG; BEGIN PROCESS BEGIN over_samp_clk <= '0'; over_samp_clkq <= '1'; L1: LOOP WAIT FOR time(over_samp_time); over_samp_clkq <= not over_samp_clkq; over_samp_clk <= over_samp_clkq; END LOOP; END PROCESS; RELATION PROCEDURAL FOR INIT => delayed1 := 0.0; delayed2 := 0.0; delayed3 := 0.0; a0 := 1.0; -- not adjusted yet a1 := 1.0; -- a2 := 1.0; -- a3 := 1.0; -- PROCEDURAL FOR DC => NULL; PROCEDURAL FOR TRANSIENT => -- to be considered !!! -- h(t) is to be implemnented by transversal filter: -- oversampling rate: 3 -- filter coefficients: a0, a1, a2, a3, -- IF event(over_samp_clk) AND over_samp_clk='1' THEN delayed1 := m_out.v; delayed2 := delayed1; delayed3 := delayed2; END IF; s := a0*m_out.v + a1*delayed1 + a2*delayed2 + a3*delayed3; IF event(clk) AND clk='1' THEN IF s < 0.0 THEN -- sample and decide d_out.v %= mag; ELSE d_out.v %= -mag; END IF; END IF; -- event(clk) AND clk='1' END RELATION; END ARCHITECTURE amo_kiv; ------------------------------------------------------------------- -- DMSK demodulated output as digital signal: 13.01.95, 18-19.01.95, ------------------------------------------------------------------- ENTITY dmsk_out IS GENERIC( vth -- threshold for wn: 0.2 :REAL); PORT( clk : IN BIT; out1 : OUT BIT -- differentially decoded output ); PIN( d_out : ELECTRICAL); -- estimated wn (demodulated input) END ENTITY dmsk_out; ARCHITECTURE m1 OF dmsk_out IS STATE wn_previous, -- privious value of wn==d_out.v wn_xored, -- out1a : ANALOG; -- analog value of previous wn XOR wn BEGIN PROCESS BEGIN out1 <= '0'; -- initial L3: LOOP WAIT ON rising(out1a, 2.5),falling(out1a, 2.5); IF rising(out1a, 2.5) THEN -- rising case out1 <= '1'; ELSE -- falling case out1 <= '0'; END IF; END LOOP; -- L3 END PROCESS; RELATION PROCEDURAL FOR INIT => out1a := 1.0; -- wn==-1.0 <==> vn=='1' wn_previous := 1.0; -- wn==+1.0 <==> vn=='0' PROCEDURAL FOR DC => NULL; PROCEDURAL FOR TRANSIENT => wn_xored := wn_previous * d_out.v; -- analog "*" means digital "XOR" IF event(clk) AND clk='1' THEN wn_previous := d_out.v; -- save wn for next clk IF wn_xored > 0.0 THEN slope(out1a, 0.0, 0.0, 2.0e-8); ELSE slope(out1a, 5.0, 0.0, 2.0e-8); END IF; END IF; END RELATION; END ARCHITECTURE m1; ----------------------- dmsk.massey.cir --------------------------- * DMSK (Massey) #com Hisashi Sasaki, 18.01.1995, for HDL-A #endcom .HDLALIB /local/eecrip/usr3/sasaki/eldo/v4.3.3/examples/hdla/sasaki-lib .model dmsk_in1(d1) macro lang=hdla .model dmsk_clk(d1) macro lang=hdla .model wn_gen(m1) macro lang=hdla .model dmsk_mod(massey) macro lang=hdla .model dmsk_demod(massey) macro lang=hdla .model dmsk_out(m1) macro lang=hdla y1 dmsk_in1(d1) + port: in1 y13 dmsk_clk(d1) + port: clk y12 wn_gen(m1) + generic: mag=1.0 + pin: wn + port: in1 clk y2 dmsk_mod(massey) + generic: omega0=6.283185307e7 omega1=9.424777961e7 mag=1.0 ! omega0 = twopi/T, omega1 = 3*pi/T where T=100ns + pin: wn m_out + port: clk y3 dmsk_demod(massey) + generic: omega0=6.283185307e7 omega1=9.424777961e7 + mag=1.0 det_thres=0.5e-7 + pin: m_out d_out + port: clk y4 dmsk_out(m1) + generic: vth=0.2 + pin: d_out + port: clk out1 r1 m_out 0 10M r2 d_out 0 10M .tran 1.2n 1.0u .plot tran V(clk) V(in1) SG(y12->vn) V(out1) .plot tran v(wn) .plot tran v(y2->wn_previous) .plot tran v(y2->ii) .plot tran v(y2->i_out) .plot tran v(y2->qq) .plot tran v(y2->q_out) .plot tran v(m_out) .plot tran v(y3->i) ! .plot tran v(y3->i1) ! v(y3->q1) .plot tran v(y3->ii) .plot tran v(y3->ii_current) v(y3->ii_old) .plot tran v(y3->q) .plot tran v(y3->qq) .plot tran v(y3->qq_current) v(y3->qq_old) .plot tran v(y3->sum) .plot tran v(d_out) .plot tran V(out1) .option noascii .end ---------------------- dmsk.rimoldi.cir --------------------------- * DMSK (Rimoldi) #com Hisashi Sasaki, 19.01.1995, for HDL-A #endcom .HDLALIB /local/eecrip/usr3/sasaki/eldo/v4.3.3/examples/hdla/sasaki-lib .model dmsk_in1(d1) macro lang=hdla .model dmsk_clk(d1) macro lang=hdla .model wn_gen(m1) macro lang=hdla .model dmsk_mod(rimoldi) macro lang=hdla .model dmsk_demod(rimoldi) macro lang=hdla .model dmsk_out(m1) macro lang=hdla y1 dmsk_in1(d1) + port: in1 y13 dmsk_clk(d1) + port: clk y12 wn_gen(m1) + generic: mag=1.0 + pin: wn + port: in1 clk y2 dmsk_mod(rimoldi) + generic: omega0=6.283185307e7 omega1=9.424777961e7 mag=1.0 ! omega0 = twopi/T, omega1 = 3*pi/T where T=100ns + pin: wn m_out + port: clk y3 dmsk_demod(rimoldi) + generic: omega0=6.283185307e7 omega1=9.424777961e7 + mag=1.0 det_thres=0.1e-8 + pin: m_out d_out + port: clk y33 dmsk_out(m1) + generic: vth=0.2 + pin: d_out + port: clk out1 r1 m_out 0 10M r2 d_out 0 10M .tran 1.2n 1.0u .plot tran V(clk) V(in1) SG(y12->vn) V(out1) .plot tran v(wn) .plot tran v(y2->wn_previous) .plot tran v(y2->S0) .plot tran v(y2->S1) .plot tran v(y2->i_out) .plot tran v(y2->q_out) .plot tran v(m_out) .plot tran v(y3->i) ! .plot tran v(y3->i1) ! v(y3->q1) .plot tran v(y3->ii) .plot tran v(y3->qq) .plot tran v(y3->qq_old) .plot tran v(y3->sum) .plot tran v(d_out) ! .plot tran SG(y33->vn) ! .plot tran SG(y33->vnq) .plot tran V(out1) .option noascii .end ---------------------- dmsk.de_buda.cir ------------------------- * DMSK (De Buda) #com Hisashi Sasaki, 19.01.1995, for HDL-A #endcom .HDLALIB /local/eecrip/usr3/sasaki/eldo/v4.3.3/examples/hdla/sasaki-lib .model dmsk_in1(d1) macro lang=hdla .model dmsk_clk(d1) macro lang=hdla .model wn_gen(m1) macro lang=hdla .model dmsk_mod(de_buda) macro lang=hdla .model dmsk_demod(de_buda) macro lang=hdla .model dmsk_out(m1) macro lang=hdla y1 dmsk_in1(d1) + port: in1 y13 dmsk_clk(d1) + port: clk y12 wn_gen(m1) + generic: mag=1.0 + pin: wn + port: in1 clk y2 dmsk_mod(de_buda) + generic: omega0=6.283185307e7 omega1=9.424777961e7 mag=1.0 ! omega0 = twopi/T, omega1 = 3*pi/T where T=100ns ! pi/2/T==(omega1-omega0)/2.0 + pin: wn m_out + port: clk y3 dmsk_demod(de_buda) + generic: omega0=6.283185307e7 omega1=9.424777961e7 + mag=1.0 det_thres=0.1e-9 + pin: m_out d_out + port: clk y33 dmsk_out(m1) + generic: vth=0.2 + pin: d_out + port: clk out1 r1 m_out 0 10M r2 d_out 0 10M .tran 1.2n 1.0u .plot tran V(clk) V(in1) SG(y12->vn) V(out1) .plot tran v(wn) .plot tran v(y2->even_odd) .plot tran v(y2->wn_even) .plot tran v(y2->Ccos) .plot tran v(y2->q_out) .plot tran v(y2->wn_odd) .plot tran v(y2->Ssin) .plot tran v(y2->i_out) .plot tran v(m_out) .plot tran v(y3->Ssin) .plot tran v(y3->i) .plot tran v(y3->ii) .plot tran v(y3->Ccos) .plot tran v(y3->q) .plot tran v(y3->qq) .plot tran v(d_out) .plot tran V(out1) .option noascii .end From 1076-1-request@sicmail.epfl.ch Fri Jan 20 01:09:01 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Fri, 20 Jan 95 01:08:46 -0500 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Fri, 20 Jan 95 01:08:27 -0500 Received: from inet-tsb.toshiba.co.jp by sicmail.epfl.ch with SMTP (PP) id <24672-0@sicmail.epfl.ch>; Fri, 20 Jan 1995 06:59:11 +0100 Received: from tis2.tis.toshiba.co.jp (tis2) by inet-tsb.toshiba.co.jp (5.67+1.6W/2.8Wb) id AA27446; Fri, 20 Jan 95 14:28:16 JST Received: from tis10.tis.toshiba.co.jp (tis10) by tis2.tis.toshiba.co.jp (5.67+1.6W/6.4J.6-R05) id AA19954; Fri, 20 Jan 95 14:28:45 JST Received: from eecisa.eec.toshiba.co.jp (eecisa) by tis10.tis.toshiba.co.jp (5.67+1.6W/6.4J.6-MHS-CNTML-R1) id AA06847; Fri, 20 Jan 95 14:29:04 JST Received: from roku.eec.toshiba.co.jp (eecjsf) by eecisa.eec.toshiba.co.jp (4.1/6.4J.6-R1) id AA26345; Fri, 20 Jan 95 14:16:57 JST Return-Path: Received: by roku.eec.toshiba.co.jp (8.6.9+2.4Wb3/3.3W-roku_Master) with ESMTP id OAA06398; Fri, 20 Jan 1995 14:17:33 +0900 From: "VHDL analog mail by (CA1)H.Sasaki 94.1.18" Message-Id: <199501200517.OAA06398@roku.eec.toshiba.co.jp> Date: Fri, 20 Jan 1995 14:27:15 +0900 To: 1076-1@epfl.ch, Olli.Fischer@rt.bosch.de, jvl-analog@nttica.ntt.jp, jvlwg@nttica.ntt.jp Subject: (validation) DMSK -- de_buda1.ps.uuencoded Cc: renderings@anacad.com, vhdlbpeldo@anacad.de, vhdlbpeldo@anacad.fr begin 777 de_buda1.ps.uuencoded M)2%04RU!9&]B92TR+C *)254:71L93H@1&]C=6UE;G0*)25#7)I9VAT(#$Y.3 @6%94(%-O9G1W87)E($EN8RX@06QL(')I9VAT M2!B>2!A<'!L:6-A=&EO;G,@=W)I='1E;B!W:71H(&%N(%A65"!T;V]L:VET M('-U<'!L:65D(&)Y"B4@6%94(%-O9G1W87)E($EN8RX*)0HE(%!R;V)L96US M.@HE(%1E>'0Z"B4)+2!O<&%Q=65?=&5X="!N;W0@:&]N;W)E9#L@86QW87ES M($9!3%-%("AT:&5R969O65T.@HE"2T@9')A=U]A;&EN92!;;%X@9F-N(&ES(&AE M7)A9"!X7V-E M;G1E"!M871R:7@@8W5R"!D968*"71R86YS;&%T90H)"!A"B4@06QS;RP@8V]O&-H(&%T86X@"!Y(&%R"B O;%X@>R E9&5F(" @("4@;&EN971O+6%R"!P2!C86-H90HE(&1E9FEN97!A='1E"!D968*"0D)+VAE:6=H="!E M>&-H(&1E9@H)"0DO=VED=&@@97AC:"!D968*"0D)+V-T;2!M871R:7@@8W5R M"!D968*"0D)+W!T;2!M871R:7@@:61E;G1M871R:7@@9&5F M"@D)"2]S='(*"0D)*#$R,S0U-C"!&;VYT1&EC=" O;71X(&=E="!D968*"0DO16YC M;V1I;F<@4W1A;F1AR E:69E;'-E"@D)"0D)," P('=I M9'1H(&AE:6=H="!S971C86-H961E=FEC90H)"0D)?7L@)65L7!E(&5Q M('L@)6EF96QS90H)"6)E9VEN($9O;G1$:6-T("]C=&T@9V5T('-E=&UA=')I M> H)?7L@)65L&-H(&)E9VEN($9O;G1$:6-T("]C=&T@9V5T('-E M=&UA=')I> H)"6-O;F-A= H)?2!I9F5L"!C;VYC870*"0EW:61T M:" P(&1T"!P;W *"0E[("5R97!E870*"0D)9W-A=F4*"0D)"7!T;2!C;VYC870*"0D) M"61U<"!S='(@;&5N9W1H(&ED:78@>R ER E9F]R86QL"@D),B!C;W!Y(# @ M97AC:"!P=70@<&]P(&1U< H)"69A;'-E(&-H87)P871H( H)"6-UR E96QS90H)"0DV(&EN9&5X(#8@ M:6YD97@@<&%T=&5R;F9I;&P*"0E](&EF96QS90H)"6UO=F5T;PH)"3,@8V]P M>2!P;W @R!P;W @?2!I9B!P;W *?2!B:6YD(&1E9@H*)2!D M:6-T('-T&-H(# @ M97AC:"!P871T97)N87-H;W<*?2!B:6YD(&1E9@H*+V]P87%U97!A='1E0H)9FEL; H)9W)E&-H(')L:6YE M=&\*"0EN96<@,"!R;&EN971O"@D)8VQOR E9&5F:6YE<&%T=&5R;@H),B!S971L:6YE8V%P"@DW+C4@,"!M;W9E=&\@ M,34@-RXU(&QI;F5T;PH)," W+C4@;6]V971O(#R E9&5F:6YE<&%T=&5R;@H) M,B R('-C86QE"@DR('-E=&QI;F5C87 *"32!-2E(@=&\@9FQEB!TPH)8F%C:U]R9V(@86QO860@<&]P('-E=')G8F-O;&]R"GT@ M8FEN9"!D968*"B4@0V]N9&ET:6]N86P@PH)+V1O7V9I;&P@=')U92!D968* M"2]BR!F:6QL('T@8FEN9"!D968*?0IB:6YD(&1E9@HO8G)U MPH)+V1O7V9I;&P@=')U92!D968*"2]BR O M3$5&5&1I86=O;F%L(&9I;F1F;VYT('!A='1EPH)+V1O7V9I;&P@=')U92!D968* M"2]BR O4DE'2%1D:6%G;VYA;"!F:6YD9F]N="!P871T97)N M9FEL;"!](&)I;F0@9&5F"GT*8FEN9"!D968*+V)R=7-H7V1I86=CB!["@DO9&]?9FEL;"!TPH)+V1O7V9I;&P@=')U92!D968* M"2]BR O8W)OR!BR!N97=P871H('T*"6EF96QS90I](&)I;F0@9&5F"@HE(%A65"=S(&UO M=F5?=&\*)2!5"!Y(&UV"B]M=B!["@EM;W9E=&\*?2!B:6YD(&1E M9@H*)2!85E0G"!Y(&1L"B]D;"!["@EL M:6YE=&\@8W5R6QI;F5S(&%N9"!P;VQY9V]N"!Y(&(*)0D)"7@@>2!L"B4)"0DN+BX@2!D;"!;9F]R('!O;'EL:6YE70HE"0D)>"!Y(&1G(%MF;W(@<&]L M>6=O;ET*+V(@>PH);6]V971O"GT@8FEN9"!D968*+VP@>PH);&EN971O"GT@ M8FEN9"!D968*+V1G('L*"6QI;F5T;PH)8VQO"!,3'D@9')R"B]DPH))2!#86XG="!U"!D968*"71R M86YS;&%T90H),B!I;F1E>" Q(&EN9&5X('-C86QE"@ED:78@+V@@97AC:"!D M968*"61I=B O=R!E>&-H(&1E9@H),2 P(&UO=F5T;PH)=R P('<@,2 Q(&%R M8W1O(#0@>R!P;W @?2!R97!E870*"7<@:"!W(#$@R!P;W @?2!R97!E870* M"6-L;W-E<&%T: H)"!S971M871R:7@*"6=S879E(&-F:6QL M(&=R97-T;W)E(&-S=')O:V4*?2!B:6YD(&1E9@H*)2!85E0G')A9"!Y" U M(&EN9&5X(&5L;&EP')A9"!YPH)+WDR(&5X M8V@@9&5F"@DO>#(@97AC:"!D968*"2]Y,2!E>&-H(&1E9@H)+W@Q(&5X8V@@ M9&5F"@DO>3 @97AC:"!D968*"2]X,"!E>&-H(&1E9@H)+WER(&5X8V@@9&5F M"@DO>'(@97AC:"!D968*"7DQ('DP('-U8B!X#$@># @'(@;75L('@R('@P('-U8B!Y')A9"!Y')A9"!Y2!D= HE($QI;6ET871I;VYS.B!I9VYO71E71E+B!4:&5R92!S:&]U;&0@8F4@87,@;6%N>2!G MR!C=7)R96YT9FEL92!$871A M4W1R:6YG(')E861H97AS=')I;F<@<&]P('T*"6)I;F0@:6UA9V4*"6=R97-T M;W)E"GT@8FEN9"!D968*"B4@1F-N('1O('-E="!P96X@=VED=&@*)2!5PH)9'5P"@DO9&]?"!N96<@," P(%T@;6%K969O;G0@; Fri, 20 Jan 95 01:09:02 -0500 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Fri, 20 Jan 95 01:08:47 -0500 Received: from inet-tsb.toshiba.co.jp by sicmail.epfl.ch with SMTP (PP) id <24586-0@sicmail.epfl.ch>; Fri, 20 Jan 1995 06:46:33 +0100 Received: from tis2.tis.toshiba.co.jp (tis2) by inet-tsb.toshiba.co.jp (5.67+1.6W/2.8Wb) id AA26817; Fri, 20 Jan 95 14:17:13 JST Received: from tis10.tis.toshiba.co.jp (tis10) by tis2.tis.toshiba.co.jp (5.67+1.6W/6.4J.6-R05) id AA18677; Fri, 20 Jan 95 14:17:35 JST Received: from eecisa.eec.toshiba.co.jp (eecisa) by tis10.tis.toshiba.co.jp (5.67+1.6W/6.4J.6-MHS-CNTML-R1) id AA04795; Fri, 20 Jan 95 14:17:50 JST Received: from roku.eec.toshiba.co.jp (eecjsf) by eecisa.eec.toshiba.co.jp (4.1/6.4J.6-R1) id AA26083; Fri, 20 Jan 95 14:05:42 JST Return-Path: Received: by roku.eec.toshiba.co.jp (8.6.9+2.4Wb3/3.3W-roku_Master) with ESMTP id OAA06356; Fri, 20 Jan 1995 14:06:18 +0900 From: "VHDL analog mail by (CA1)H.Sasaki 94.1.18" Message-Id: <199501200506.OAA06356@roku.eec.toshiba.co.jp> Date: Fri, 20 Jan 1995 14:16:01 +0900 To: 1076-1@epfl.ch, Olli.Fischer@rt.bosch.de, jvl-analog@nttica.ntt.jp, jvlwg@nttica.ntt.jp Subject: (validation) DMSK -- massey1.ps.uuencoded Cc: renderings@anacad.com, vhdlbpeldo@anacad.de, vhdlbpeldo@anacad.fr begin 777 massey1.ps.uuencoded M)2%04RU!9&]B92TR+C *)254:71L93H@1&]C=6UE;G0*)25#7)I9VAT(#$Y.3 @6%94(%-O9G1W87)E($EN8RX@06QL(')I9VAT M2!B>2!A<'!L:6-A=&EO;G,@=W)I='1E;B!W:71H(&%N(%A65"!T;V]L:VET M('-U<'!L:65D(&)Y"B4@6%94(%-O9G1W87)E($EN8RX*)0HE(%!R;V)L96US M.@HE(%1E>'0Z"B4)+2!O<&%Q=65?=&5X="!N;W0@:&]N;W)E9#L@86QW87ES M($9!3%-%("AT:&5R969O65T.@HE"2T@9')A=U]A;&EN92!;;%X@9F-N(&ES(&AE M7)A9"!X7V-E M;G1E"!M871R:7@@8W5R"!D968*"71R86YS;&%T90H)"!A"B4@06QS;RP@8V]O&-H(&%T86X@"!Y(&%R"B O;%X@>R E9&5F(" @("4@;&EN971O+6%R"!P2!C86-H90HE(&1E9FEN97!A='1E"!D968*"0D)+VAE:6=H="!E M>&-H(&1E9@H)"0DO=VED=&@@97AC:"!D968*"0D)+V-T;2!M871R:7@@8W5R M"!D968*"0D)+W!T;2!M871R:7@@:61E;G1M871R:7@@9&5F M"@D)"2]S='(*"0D)*#$R,S0U-C"!&;VYT1&EC=" O;71X(&=E="!D968*"0DO16YC M;V1I;F<@4W1A;F1AR E:69E;'-E"@D)"0D)," P('=I M9'1H(&AE:6=H="!S971C86-H961E=FEC90H)"0D)?7L@)65L7!E(&5Q M('L@)6EF96QS90H)"6)E9VEN($9O;G1$:6-T("]C=&T@9V5T('-E=&UA=')I M> H)?7L@)65L&-H(&)E9VEN($9O;G1$:6-T("]C=&T@9V5T('-E M=&UA=')I> H)"6-O;F-A= H)?2!I9F5L"!C;VYC870*"0EW:61T M:" P(&1T"!P;W *"0E[("5R97!E870*"0D)9W-A=F4*"0D)"7!T;2!C;VYC870*"0D) M"61U<"!S='(@;&5N9W1H(&ED:78@>R ER E9F]R86QL"@D),B!C;W!Y(# @ M97AC:"!P=70@<&]P(&1U< H)"69A;'-E(&-H87)P871H( H)"6-UR E96QS90H)"0DV(&EN9&5X(#8@ M:6YD97@@<&%T=&5R;F9I;&P*"0E](&EF96QS90H)"6UO=F5T;PH)"3,@8V]P M>2!P;W @R!P;W @?2!I9B!P;W *?2!B:6YD(&1E9@H*)2!D M:6-T('-T&-H(# @ M97AC:"!P871T97)N87-H;W<*?2!B:6YD(&1E9@H*+V]P87%U97!A='1E0H)9FEL; H)9W)E&-H(')L:6YE M=&\*"0EN96<@,"!R;&EN971O"@D)8VQOR E9&5F:6YE<&%T=&5R;@H),B!S971L:6YE8V%P"@DW+C4@,"!M;W9E=&\@ M,34@-RXU(&QI;F5T;PH)," W+C4@;6]V971O(#R E9&5F:6YE<&%T=&5R;@H) M,B R('-C86QE"@DR('-E=&QI;F5C87 *"32!-2E(@=&\@9FQEB!TPH)8F%C:U]R9V(@86QO860@<&]P('-E=')G8F-O;&]R"GT@ M8FEN9"!D968*"B4@0V]N9&ET:6]N86P@PH)+V1O7V9I;&P@=')U92!D968* M"2]BR!F:6QL('T@8FEN9"!D968*?0IB:6YD(&1E9@HO8G)U MPH)+V1O7V9I;&P@=')U92!D968*"2]BR O M3$5&5&1I86=O;F%L(&9I;F1F;VYT('!A='1EPH)+V1O7V9I;&P@=')U92!D968* M"2]BR O4DE'2%1D:6%G;VYA;"!F:6YD9F]N="!P871T97)N M9FEL;"!](&)I;F0@9&5F"GT*8FEN9"!D968*+V)R=7-H7V1I86=CB!["@DO9&]?9FEL;"!TPH)+V1O7V9I;&P@=')U92!D968* M"2]BR O8W)OR!BR!N97=P871H('T*"6EF96QS90I](&)I;F0@9&5F"@HE(%A65"=S(&UO M=F5?=&\*)2!5"!Y(&UV"B]M=B!["@EM;W9E=&\*?2!B:6YD(&1E M9@H*)2!85E0G"!Y(&1L"B]D;"!["@EL M:6YE=&\@8W5R6QI;F5S(&%N9"!P;VQY9V]N"!Y(&(*)0D)"7@@>2!L"B4)"0DN+BX@2!D;"!;9F]R('!O;'EL:6YE70HE"0D)>"!Y(&1G(%MF;W(@<&]L M>6=O;ET*+V(@>PH);6]V971O"GT@8FEN9"!D968*+VP@>PH);&EN971O"GT@ M8FEN9"!D968*+V1G('L*"6QI;F5T;PH)8VQO"!,3'D@9')R"B]DPH))2!#86XG="!U"!D968*"71R M86YS;&%T90H),B!I;F1E>" Q(&EN9&5X('-C86QE"@ED:78@+V@@97AC:"!D M968*"61I=B O=R!E>&-H(&1E9@H),2 P(&UO=F5T;PH)=R P('<@,2 Q(&%R M8W1O(#0@>R!P;W @?2!R97!E870*"7<@:"!W(#$@R!P;W @?2!R97!E870* M"6-L;W-E<&%T: H)"!S971M871R:7@*"6=S879E(&-F:6QL M(&=R97-T;W)E(&-S=')O:V4*?2!B:6YD(&1E9@H*)2!85E0G')A9"!Y" U M(&EN9&5X(&5L;&EP')A9"!YPH)+WDR(&5X M8V@@9&5F"@DO>#(@97AC:"!D968*"2]Y,2!E>&-H(&1E9@H)+W@Q(&5X8V@@ M9&5F"@DO>3 @97AC:"!D968*"2]X,"!E>&-H(&1E9@H)+WER(&5X8V@@9&5F M"@DO>'(@97AC:"!D968*"7DQ('DP('-U8B!X#$@># @'(@;75L('@R('@P('-U8B!Y')A9"!Y')A9"!Y2!D= HE($QI;6ET871I;VYS.B!I9VYO71E71E+B!4:&5R92!S:&]U;&0@8F4@87,@;6%N>2!G MR!C=7)R96YT9FEL92!$871A M4W1R:6YG(')E861H97AS=')I;F<@<&]P('T*"6)I;F0@:6UA9V4*"6=R97-T M;W)E"GT@8FEN9"!D968*"B4@1F-N('1O('-E="!P96X@=VED=&@*)2!5PH)9'5P"@DO9&]?"!N96<@," P(%T@;6%K969O;G0@; Fri, 20 Jan 95 01:09:17 -0500 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Fri, 20 Jan 95 01:09:03 -0500 Received: from inet-tsb.toshiba.co.jp by sicmail.epfl.ch with SMTP (PP) id <24646-0@sicmail.epfl.ch>; Fri, 20 Jan 1995 06:56:39 +0100 Received: from tis2.tis.toshiba.co.jp (tis2) by inet-tsb.toshiba.co.jp (5.67+1.6W/2.8Wb) id AA27600; Fri, 20 Jan 95 14:30:43 JST Received: from tis10.tis.toshiba.co.jp (tis10) by tis2.tis.toshiba.co.jp (5.67+1.6W/6.4J.6-R05) id AA20216; Fri, 20 Jan 95 14:31:13 JST Received: from eecisa.eec.toshiba.co.jp (eecisa) by tis10.tis.toshiba.co.jp (5.67+1.6W/6.4J.6-MHS-CNTML-R1) id AA07322; Fri, 20 Jan 95 14:31:33 JST Received: from roku.eec.toshiba.co.jp (eecjsf) by eecisa.eec.toshiba.co.jp (4.1/6.4J.6-R1) id AA26401; Fri, 20 Jan 95 14:19:25 JST Return-Path: Received: by roku.eec.toshiba.co.jp (8.6.9+2.4Wb3/3.3W-roku_Master) with ESMTP id OAA06413; Fri, 20 Jan 1995 14:20:01 +0900 From: "VHDL analog mail by (CA1)H.Sasaki 94.1.18" Message-Id: <199501200520.OAA06413@roku.eec.toshiba.co.jp> Date: Fri, 20 Jan 1995 14:29:44 +0900 To: 1076-1@epfl.ch, Olli.Fischer@rt.bosch.de, jvl-analog@nttica.ntt.jp, jvlwg@nttica.ntt.jp Subject: (validation) DMSK -- de_buda2.ps.uuencoded Cc: renderings@anacad.com, vhdlbpeldo@anacad.de, vhdlbpeldo@anacad.fr begin 777 de_buda2.ps.uuencoded M)2%04RU!9&]B92TR+C *)254:71L93H@1&]C=6UE;G0*)25#7)I9VAT(#$Y.3 @6%94(%-O9G1W87)E($EN8RX@06QL(')I9VAT M2!B>2!A<'!L:6-A=&EO;G,@=W)I='1E;B!W:71H(&%N(%A65"!T;V]L:VET M('-U<'!L:65D(&)Y"B4@6%94(%-O9G1W87)E($EN8RX*)0HE(%!R;V)L96US M.@HE(%1E>'0Z"B4)+2!O<&%Q=65?=&5X="!N;W0@:&]N;W)E9#L@86QW87ES M($9!3%-%("AT:&5R969O65T.@HE"2T@9')A=U]A;&EN92!;;%X@9F-N(&ES(&AE M7)A9"!X7V-E M;G1E"!M871R:7@@8W5R"!D968*"71R86YS;&%T90H)"!A"B4@06QS;RP@8V]O&-H(&%T86X@"!Y(&%R"B O;%X@>R E9&5F(" @("4@;&EN971O+6%R"!P2!C86-H90HE(&1E9FEN97!A='1E"!D968*"0D)+VAE:6=H="!E M>&-H(&1E9@H)"0DO=VED=&@@97AC:"!D968*"0D)+V-T;2!M871R:7@@8W5R M"!D968*"0D)+W!T;2!M871R:7@@:61E;G1M871R:7@@9&5F M"@D)"2]S='(*"0D)*#$R,S0U-C"!&;VYT1&EC=" O;71X(&=E="!D968*"0DO16YC M;V1I;F<@4W1A;F1AR E:69E;'-E"@D)"0D)," P('=I M9'1H(&AE:6=H="!S971C86-H961E=FEC90H)"0D)?7L@)65L7!E(&5Q M('L@)6EF96QS90H)"6)E9VEN($9O;G1$:6-T("]C=&T@9V5T('-E=&UA=')I M> H)?7L@)65L&-H(&)E9VEN($9O;G1$:6-T("]C=&T@9V5T('-E M=&UA=')I> H)"6-O;F-A= H)?2!I9F5L"!C;VYC870*"0EW:61T M:" P(&1T"!P;W *"0E[("5R97!E870*"0D)9W-A=F4*"0D)"7!T;2!C;VYC870*"0D) M"61U<"!S='(@;&5N9W1H(&ED:78@>R ER E9F]R86QL"@D),B!C;W!Y(# @ M97AC:"!P=70@<&]P(&1U< H)"69A;'-E(&-H87)P871H( H)"6-UR E96QS90H)"0DV(&EN9&5X(#8@ M:6YD97@@<&%T=&5R;F9I;&P*"0E](&EF96QS90H)"6UO=F5T;PH)"3,@8V]P M>2!P;W @R!P;W @?2!I9B!P;W *?2!B:6YD(&1E9@H*)2!D M:6-T('-T&-H(# @ M97AC:"!P871T97)N87-H;W<*?2!B:6YD(&1E9@H*+V]P87%U97!A='1E0H)9FEL; H)9W)E&-H(')L:6YE M=&\*"0EN96<@,"!R;&EN971O"@D)8VQOR E9&5F:6YE<&%T=&5R;@H),B!S971L:6YE8V%P"@DW+C4@,"!M;W9E=&\@ M,34@-RXU(&QI;F5T;PH)," W+C4@;6]V971O(#R E9&5F:6YE<&%T=&5R;@H) M,B R('-C86QE"@DR('-E=&QI;F5C87 *"32!-2E(@=&\@9FQEB!TPH)8F%C:U]R9V(@86QO860@<&]P('-E=')G8F-O;&]R"GT@ M8FEN9"!D968*"B4@0V]N9&ET:6]N86P@PH)+V1O7V9I;&P@=')U92!D968* M"2]BR!F:6QL('T@8FEN9"!D968*?0IB:6YD(&1E9@HO8G)U MPH)+V1O7V9I;&P@=')U92!D968*"2]BR O M3$5&5&1I86=O;F%L(&9I;F1F;VYT('!A='1EPH)+V1O7V9I;&P@=')U92!D968* M"2]BR O4DE'2%1D:6%G;VYA;"!F:6YD9F]N="!P871T97)N M9FEL;"!](&)I;F0@9&5F"GT*8FEN9"!D968*+V)R=7-H7V1I86=CB!["@DO9&]?9FEL;"!TPH)+V1O7V9I;&P@=')U92!D968* M"2]BR O8W)OR!BR!N97=P871H('T*"6EF96QS90I](&)I;F0@9&5F"@HE(%A65"=S(&UO M=F5?=&\*)2!5"!Y(&UV"B]M=B!["@EM;W9E=&\*?2!B:6YD(&1E M9@H*)2!85E0G"!Y(&1L"B]D;"!["@EL M:6YE=&\@8W5R6QI;F5S(&%N9"!P;VQY9V]N"!Y(&(*)0D)"7@@>2!L"B4)"0DN+BX@2!D;"!;9F]R('!O;'EL:6YE70HE"0D)>"!Y(&1G(%MF;W(@<&]L M>6=O;ET*+V(@>PH);6]V971O"GT@8FEN9"!D968*+VP@>PH);&EN971O"GT@ M8FEN9"!D968*+V1G('L*"6QI;F5T;PH)8VQO"!,3'D@9')R"B]DPH))2!#86XG="!U"!D968*"71R M86YS;&%T90H),B!I;F1E>" Q(&EN9&5X('-C86QE"@ED:78@+V@@97AC:"!D M968*"61I=B O=R!E>&-H(&1E9@H),2 P(&UO=F5T;PH)=R P('<@,2 Q(&%R M8W1O(#0@>R!P;W @?2!R97!E870*"7<@:"!W(#$@R!P;W @?2!R97!E870* M"6-L;W-E<&%T: H)"!S971M871R:7@*"6=S879E(&-F:6QL M(&=R97-T;W)E(&-S=')O:V4*?2!B:6YD(&1E9@H*)2!85E0G')A9"!Y" U M(&EN9&5X(&5L;&EP')A9"!YPH)+WDR(&5X M8V@@9&5F"@DO>#(@97AC:"!D968*"2]Y,2!E>&-H(&1E9@H)+W@Q(&5X8V@@ M9&5F"@DO>3 @97AC:"!D968*"2]X,"!E>&-H(&1E9@H)+WER(&5X8V@@9&5F M"@DO>'(@97AC:"!D968*"7DQ('DP('-U8B!X#$@># @'(@;75L('@R('@P('-U8B!Y')A9"!Y')A9"!Y2!D= HE($QI;6ET871I;VYS.B!I9VYO71E71E+B!4:&5R92!S:&]U;&0@8F4@87,@;6%N>2!G MR!C=7)R96YT9FEL92!$871A M4W1R:6YG(')E861H97AS=')I;F<@<&]P('T*"6)I;F0@:6UA9V4*"6=R97-T M;W)E"GT@8FEN9"!D968*"B4@1F-N('1O('-E="!P96X@=VED=&@*)2!5PH)9'5P"@DO9&]?"!N96<@," P(%T@;6%K969O;G0@; Fri, 20 Jan 95 01:35:34 -0500 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Fri, 20 Jan 95 01:35:24 -0500 Received: from inet-tsb.toshiba.co.jp by sicmail.epfl.ch with SMTP (PP) id <24702-0@sicmail.epfl.ch>; Fri, 20 Jan 1995 07:00:44 +0100 Received: from tis2.tis.toshiba.co.jp (tis2) by inet-tsb.toshiba.co.jp (5.67+1.6W/2.8Wb) id AA26957; Fri, 20 Jan 95 14:20:02 JST Received: from tis10.tis.toshiba.co.jp (tis10) by tis2.tis.toshiba.co.jp (5.67+1.6W/6.4J.6-R05) id AA19280; Fri, 20 Jan 95 14:20:30 JST Received: from eecisa.eec.toshiba.co.jp (eecisa) by tis10.tis.toshiba.co.jp (5.67+1.6W/6.4J.6-MHS-CNTML-R1) id AA05292; Fri, 20 Jan 95 14:20:49 JST Received: from roku.eec.toshiba.co.jp (eecjsf) by eecisa.eec.toshiba.co.jp (4.1/6.4J.6-R1) id AA26191; Fri, 20 Jan 95 14:08:39 JST Return-Path: Received: by roku.eec.toshiba.co.jp (8.6.9+2.4Wb3/3.3W-roku_Master) with ESMTP id OAA06374; Fri, 20 Jan 1995 14:09:15 +0900 From: "VHDL analog mail by (CA1)H.Sasaki 94.1.18" Message-Id: <199501200509.OAA06374@roku.eec.toshiba.co.jp> Date: Fri, 20 Jan 1995 14:18:58 +0900 To: 1076-1@epfl.ch, Olli.Fischer@rt.bosch.de, jvl-analog@nttica.ntt.jp, jvlwg@nttica.ntt.jp Subject: (validation) DMSK -- massey2.ps.uuencoded Cc: renderings@anacad.com, vhdlbpeldo@anacad.de, vhdlbpeldo@anacad.fr begin 777 massey2.ps.uuencoded M)2%04RU!9&]B92TR+C *)254:71L93H@1&]C=6UE;G0*)25#7)I9VAT(#$Y.3 @6%94(%-O9G1W87)E($EN8RX@06QL(')I9VAT M2!B>2!A<'!L:6-A=&EO;G,@=W)I='1E;B!W:71H(&%N(%A65"!T;V]L:VET M('-U<'!L:65D(&)Y"B4@6%94(%-O9G1W87)E($EN8RX*)0HE(%!R;V)L96US M.@HE(%1E>'0Z"B4)+2!O<&%Q=65?=&5X="!N;W0@:&]N;W)E9#L@86QW87ES M($9!3%-%("AT:&5R969O65T.@HE"2T@9')A=U]A;&EN92!;;%X@9F-N(&ES(&AE M7)A9"!X7V-E M;G1E"!M871R:7@@8W5R"!D968*"71R86YS;&%T90H)"!A"B4@06QS;RP@8V]O&-H(&%T86X@"!Y(&%R"B O;%X@>R E9&5F(" @("4@;&EN971O+6%R"!P2!C86-H90HE(&1E9FEN97!A='1E"!D968*"0D)+VAE:6=H="!E M>&-H(&1E9@H)"0DO=VED=&@@97AC:"!D968*"0D)+V-T;2!M871R:7@@8W5R M"!D968*"0D)+W!T;2!M871R:7@@:61E;G1M871R:7@@9&5F M"@D)"2]S='(*"0D)*#$R,S0U-C"!&;VYT1&EC=" O;71X(&=E="!D968*"0DO16YC M;V1I;F<@4W1A;F1AR E:69E;'-E"@D)"0D)," P('=I M9'1H(&AE:6=H="!S971C86-H961E=FEC90H)"0D)?7L@)65L7!E(&5Q M('L@)6EF96QS90H)"6)E9VEN($9O;G1$:6-T("]C=&T@9V5T('-E=&UA=')I M> H)?7L@)65L&-H(&)E9VEN($9O;G1$:6-T("]C=&T@9V5T('-E M=&UA=')I> H)"6-O;F-A= H)?2!I9F5L"!C;VYC870*"0EW:61T M:" P(&1T"!P;W *"0E[("5R97!E870*"0D)9W-A=F4*"0D)"7!T;2!C;VYC870*"0D) M"61U<"!S='(@;&5N9W1H(&ED:78@>R ER E9F]R86QL"@D),B!C;W!Y(# @ M97AC:"!P=70@<&]P(&1U< H)"69A;'-E(&-H87)P871H( H)"6-UR E96QS90H)"0DV(&EN9&5X(#8@ M:6YD97@@<&%T=&5R;F9I;&P*"0E](&EF96QS90H)"6UO=F5T;PH)"3,@8V]P M>2!P;W @R!P;W @?2!I9B!P;W *?2!B:6YD(&1E9@H*)2!D M:6-T('-T&-H(# @ M97AC:"!P871T97)N87-H;W<*?2!B:6YD(&1E9@H*+V]P87%U97!A='1E0H)9FEL; H)9W)E&-H(')L:6YE M=&\*"0EN96<@,"!R;&EN971O"@D)8VQOR E9&5F:6YE<&%T=&5R;@H),B!S971L:6YE8V%P"@DW+C4@,"!M;W9E=&\@ M,34@-RXU(&QI;F5T;PH)," W+C4@;6]V971O(#R E9&5F:6YE<&%T=&5R;@H) M,B R('-C86QE"@DR('-E=&QI;F5C87 *"32!-2E(@=&\@9FQEB!TPH)8F%C:U]R9V(@86QO860@<&]P('-E=')G8F-O;&]R"GT@ M8FEN9"!D968*"B4@0V]N9&ET:6]N86P@PH)+V1O7V9I;&P@=')U92!D968* M"2]BR!F:6QL('T@8FEN9"!D968*?0IB:6YD(&1E9@HO8G)U MPH)+V1O7V9I;&P@=')U92!D968*"2]BR O M3$5&5&1I86=O;F%L(&9I;F1F;VYT('!A='1EPH)+V1O7V9I;&P@=')U92!D968* M"2]BR O4DE'2%1D:6%G;VYA;"!F:6YD9F]N="!P871T97)N M9FEL;"!](&)I;F0@9&5F"GT*8FEN9"!D968*+V)R=7-H7V1I86=CB!["@DO9&]?9FEL;"!TPH)+V1O7V9I;&P@=')U92!D968* M"2]BR O8W)OR!BR!N97=P871H('T*"6EF96QS90I](&)I;F0@9&5F"@HE(%A65"=S(&UO M=F5?=&\*)2!5"!Y(&UV"B]M=B!["@EM;W9E=&\*?2!B:6YD(&1E M9@H*)2!85E0G"!Y(&1L"B]D;"!["@EL M:6YE=&\@8W5R6QI;F5S(&%N9"!P;VQY9V]N"!Y(&(*)0D)"7@@>2!L"B4)"0DN+BX@2!D;"!;9F]R('!O;'EL:6YE70HE"0D)>"!Y(&1G(%MF;W(@<&]L M>6=O;ET*+V(@>PH);6]V971O"GT@8FEN9"!D968*+VP@>PH);&EN971O"GT@ M8FEN9"!D968*+V1G('L*"6QI;F5T;PH)8VQO"!,3'D@9')R"B]DPH))2!#86XG="!U"!D968*"71R M86YS;&%T90H),B!I;F1E>" Q(&EN9&5X('-C86QE"@ED:78@+V@@97AC:"!D M968*"61I=B O=R!E>&-H(&1E9@H),2 P(&UO=F5T;PH)=R P('<@,2 Q(&%R M8W1O(#0@>R!P;W @?2!R97!E870*"7<@:"!W(#$@R!P;W @?2!R97!E870* M"6-L;W-E<&%T: H)"!S971M871R:7@*"6=S879E(&-F:6QL M(&=R97-T;W)E(&-S=')O:V4*?2!B:6YD(&1E9@H*)2!85E0G')A9"!Y" U M(&EN9&5X(&5L;&EP')A9"!YPH)+WDR(&5X M8V@@9&5F"@DO>#(@97AC:"!D968*"2]Y,2!E>&-H(&1E9@H)+W@Q(&5X8V@@ M9&5F"@DO>3 @97AC:"!D968*"2]X,"!E>&-H(&1E9@H)+WER(&5X8V@@9&5F M"@DO>'(@97AC:"!D968*"7DQ('DP('-U8B!X#$@># @'(@;75L('@R('@P('-U8B!Y')A9"!Y')A9"!Y2!D= HE($QI;6ET871I;VYS.B!I9VYO71E71E+B!4:&5R92!S:&]U;&0@8F4@87,@;6%N>2!G MR!C=7)R96YT9FEL92!$871A M4W1R:6YG(')E861H97AS=')I;F<@<&]P('T*"6)I;F0@:6UA9V4*"6=R97-T M;W)E"GT@8FEN9"!D968*"B4@1F-N('1O('-E="!P96X@=VED=&@*)2!5PH)9'5P"@DO9&]?"!N96<@," P(%T@;6%K969O;G0@; Tue, 7 Feb 95 18:09:40 -0500 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Tue, 7 Feb 95 18:09:34 -0500 Received: from psi.com by sicmail.epfl.ch with SMTP (PP) id <15794-0@sicmail.epfl.ch>; Tue, 7 Feb 1995 23:22:28 +0100 Received: from analogy.com (analogy.analogy.com) by psi.com (4.1/2.1-PSI/PSINet) id AA00693; Tue, 7 Feb 95 17:22:21 EST Received: from miller.analogy.com ([149.117.72.253]) by analogy.com (4.1/Shared_Spool_1.3) id AA27233; Tue, 7 Feb 95 14:22:21 PST Received: from satyr.analogy.com by miller.analogy.com (4.1/SMI-3.2) id AA28191; Tue, 7 Feb 95 14:22:21 PST Received: by satyr.analogy.com (5.0/SMI-SVR4) id AA22263; Tue, 7 Feb 1995 14:22:20 -0800 Date: Tue, 7 Feb 1995 14:22:20 -0800 From: christen@analogy.com (Ernst Christen) Message-Id: <9502072222.AA22263@satyr.analogy.com> To: 1076-1@epfl.ch Subject: LAT meeting summary Content-Length: 3014 The 5th meeting of the 1076.1 Language Architecture Team was held from January 31 till February 3, 1995, in Lausanne, Switzerland. This is a brief summary of the meeting, detailed minutes will follow. The meeting was attended by 11 people. The main topic of the meeting was the discussion and adoption of the 7 white papers addressing various language design issues that were prepared by 5 different authors. The white papers had been distributed to the meeting attendees prior to the meeting. A new version of the paper on quantities, nodes and natures that includes composite terminals and quantities was discussed and adopted as a working basis for future work. However, there was a strong feeling that it should be possible to declare branches implicitly, and that pin currents should be accessible outside of a design entity. Both these issues require further investigations. We then discussed a white paper on the simulation cycle, including A/D and D/A issues. Basic to the paper is a tight interaction between analog and digital kernels, in order to support writing efficient mixed signal models. The paper was also adopted, subject to some modifications, as a basis for future work. The paper on initialization and DC analysis was discussed next. This paper is not yet as advanced as the previous two, as it identified several possible solutions at a conceptual level. The discussion provided valuable feedback where to go next with this issue. The paper on the predefined language environment proposed guidelines for what to include in package Standard and in other packages, but additional work is required as language design in other areas proceeds. Finally, the white paper on Relations was discussed. This one, too, is currently at a conceptual level and needs more work. Much of the discussion focused on the question whether the RELATION as a separate declarative region is required, or whether it adds unnecessary complexity to the language. We did not reach consensus on this issue, and 2 white papers will explore and document the topic for further discussion. There was no time left to discuss the 2 remaining white papers on SPICE issues and Number of equations. In this respect we did not reach the goal set for this meeting. I believe, however, that we made much progress in understanding and appreciating new ideas, including adopting some papers as a working basis. On the other hand there is still a lot of work left to be done. We therefore identified, before we adjourned, 5 more white papers that address various language design issues, and assigned them to different authors. They will be the main topic for the next LAT meeting, which will be held around VIUF in early April 1995. On behalf of the 1076.1 Working Group I would like to thank all attendees for their contributions, both before and during the meeting. Special thanks go to Alain Vachoux for his superb organization of the meeting, and to EPFL for offering their facilities. Ernst Christen Chair LAT From 1076-1-request@sicmail.epfl.ch Tue Feb 7 18:10:37 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Tue, 7 Feb 95 18:10:34 -0500 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Tue, 7 Feb 95 18:10:27 -0500 Received: from mailgate.Cadence.COM by sicmail.epfl.ch with SMTP (PP) id <16126-0@sicmail.epfl.ch>; Tue, 7 Feb 1995 23:53:13 +0100 Received: (from smap@localhost) by mailgate.Cadence.COM (8.6.8/8.6.8) id OAA13013 for <1076-1@epfl.ch>; Tue, 7 Feb 1995 14:53:05 -0800 Received: from cds2072.cadence.com(158.140.24.54) by mailgate.cadence.com via smap (V1.0mjr) id sma012965; Tue Feb 7 14:52:45 1995 Received: from mailgate.Cadence.COM (mailgate.cadence.com [158.140.2.1]) by cds2072.Cadence.COM (8.6.8/8.6.8) with ESMTP id OAA29647 for ; Tue, 7 Feb 1995 14:52:35 -0800 Received: (from smap@localhost) by mailgate.Cadence.COM (8.6.8/8.6.8) id OAA12947 for ; Tue, 7 Feb 1995 14:52:33 -0800 Received: from vhdl.vhdl.org(198.31.14.3) by mailgate.cadence.com via smap (V1.0mjr) id sma012875; Tue Feb 7 14:52:01 1995 Received: from VM.CC.OLEMISS.EDU by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA20145; Tue, 7 Feb 95 14:52:06 PST Message-Id: <9502072252.AA20145@vhdl.vhdl.org> Received: from VM.CC.OLEMISS.EDU by VM.CC.OLEMISS.EDU (IBM VM SMTP V2R2) with BSMTP id 5446; Tue, 07 Feb 95 16:46:25 CST Received: by UMSVM (Mailer R2.10 ptf000) id 2725; Tue, 07 Feb 95 16:46:24 CST Date: Tue, 07 Feb 95 16:45:22 CST From: Don Hanson Subject: Comments on FAXed Document To: Math Package Folks Cc: Jose Comments on FAXed IEEE VHDL Math Package - draft Under 2.1 Math_Real line 20 trascendental -> transcendental (sp) page 12 function "**" (X: integer; Y: real ) return real; --X**Y function "**" (X: real; Y: real ) return real; --X**Y We have (X: integer; Y: real ) and (X: real; Y: real ) do we need (X: integer; Y: integer ) and (X: real; Y: integer ) ?? or are these recommended to use the integer (Y) function explicitly. Page 13 previous functions have had error lines Do we need error lines for LOG, TAN, etc functions?? function LOG( X: real) return real; --returns natural logarithm of X; X>0 --error if X<=0 <<---?? Page 13 Should PI be MATH_PI in comments?? Page 13 function ASINH(X:real) return real; -- returns ln(x + sqrt( x**2 + 1 )) Should this comment be in the VHDL Math package style or otherwise?? -- return LOG(X + SQRT( X**2 + 1 )) NOTE: X**2 is not defined currently... we need a function-->> function "**" (X: real; Y: integer ) return real; --X**Y same for ACOSH and ATANH ?? Page 15 function CABS(Z: in complex) return real; -- return absolute value (magnitude) of Z Should we give the formula SQRT( Z.re**2 + Z.im**2 ) in another comment?? function CARG(Z: in complex) return real; -- returns argument (angle) in radians of a complex number Should we say: returns ATAN2(Z.re, Z.im) We have two functions with complex_polar returned... These are "-" and CONJ. As far as I can tell, these are the only functions with complex_polar returned besides the explicit COMPLEX_TO_POLAR function. Since all arithmetic operators return only complex and never complex_polar, it isn't clear why these are needed?? All arithmetic operations end up with a complex result. Why use complex_polar at all except for final output results?? Page 18.. A.4 Precision and convergence of functions in Math_Real The iterative nature of the algorithms is undesirable, and unneeded. The usual approach is to study the algorithm analytically for an upper bound to the error and take a FIXED number of terms. However, I have used the same basic algorithms that you are using with good success. Given the maximum error, one can find the maximum argument that can be used to within that error. So there is a tradeoff. Do you want to have maximum speed for small to medium arguments, or do you want maximum accuracy for all arguments. With a little analytical work, the values of the "counters" that stop the iteration can be found. I would prefer to see this work done--it is probably already done somewhere in the literature--than to imply that the functions are inaccurate. Further optimization of speed of the functions would require storing arrays of numbers, so that they would not have to be computed every time they are used, which is the algorithm you are using. The bodies that I am looking at were the last e-mailed to me:: The series for exp(x) that is used is exp(x) = 1+x+x**2/2!+x**3/3!+... x >0 This approach is asking for trouble. It is better to use that fact that: exp(x+y) = exp(x)*exp(y) There are many ways this can be used. For example, if y is made an integer value, then x is non-integral (in general) and this limits the range of the arguments exp(x) = 1+x+x**2/2!+... for 1<=x <=2 or some such thing. Then limits on the accuracy of this part of the function can be found. Then it is just necessary to take e to an integral power. There are many references that I could find that use this approach. Since all of the hyperbolic functions are based on EXP, it is important to get the EXP efficient. Also, your hyperbolic functions may be error prone for certain arguments and you are also recomputing the EXP function twice, when it only needs to be done once. This needs to be fixed. Your use of eps in the SIN function in some cases seems overly harsh. For example, If ( abs(x) <= eps ) then return 0.0; There are many times when we want the SIN ( 1.0E-30 ) and want significant digits. Your approach gives 0.0 instead of 1.0E-30. It gives 0.0 instead of significant digits as long as x <= 1.E-06. Most people don't want this. One problem that I have is that the only VHDL I have right now is several years old, from MCC. This limits my ability to test the package body. However, I am trying to get an updated version of VHDL. This makes it impossible for me to test any of these functions. However, they could be done much better in light of the SIN issue above. Let me know if I can help in any way. _______ / | ====/ * |=============================================================== | / Oxford | Dr. Donald F. Hanson Department of | | / | Associate Professor Electrical Engineering | | \ | Fax: (601)232-7231 University of Mississippi | | | | Phone: (601)232-5389 University, MS | | / | eehanson@vm.cc.olemiss.edu 38677 | ===/ |=============================================================== |______ | / | \____| From 1076-1-request@sicmail.epfl.ch Fri Feb 10 04:49:52 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Fri, 10 Feb 95 04:49:50 -0500 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Fri, 10 Feb 95 04:49:46 -0500 Received: from mailgate.Cadence.COM by sicmail.epfl.ch with SMTP (PP) id <11323-0@sicmail.epfl.ch>; Fri, 10 Feb 1995 10:09:37 +0100 Received: (from smap@localhost) by mailgate.Cadence.COM (8.6.8/8.6.8) id BAA13047 for <1076-1@epfl.ch>; Fri, 10 Feb 1995 01:09:26 -0800 Received: from cds2072.cadence.com(158.140.24.54) by mailgate.cadence.com via smap (V1.0mjr) id sma013028; Fri Feb 10 01:09:10 1995 Received: from mailgate.Cadence.COM (mailgate.cadence.com [158.140.2.1]) by cds2072.Cadence.COM (8.6.8/8.6.8) with ESMTP id BAA07220 for ; Fri, 10 Feb 1995 01:09:06 -0800 Received: (from smap@localhost) by mailgate.Cadence.COM (8.6.8/8.6.8) id BAA13014 for ; Fri, 10 Feb 1995 01:09:05 -0800 Received: from vhdl.vhdl.org(198.31.14.3) by mailgate.cadence.com via smap (V1.0mjr) id sma012987; Fri Feb 10 01:08:48 1995 Received: by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA21312; Fri, 10 Feb 95 01:06:24 PST Date: Fri, 10 Feb 95 01:06:24 PST From: jose@vhdl.org (Jose Torres) Message-Id: <9502100906.AA21312@vhdl.vhdl.org> To: math@vhdl.org Subject: vhdl math package status The purpose of this message is to let you know where we are at regarding the math package. A balloting group has been approved by IEEE and a draft of the documentation is currently under review by the working group and IEEE. We hope to be able to send the documentation out for general distribution and balloting by March. ***************************** HELP ******************************** > We NEED VOLUNTEERS to help finish a test suite for the whole package. > We have a template for the test bench with some data points for > the functions which can be used as a guideline. If you are interested, please > send a message to jose@vhdl.org ************************************************************************ As part of the process of balloting the package, I am working on putting together a tutorial to disseminate information on the package, its purpose, usage, and applications. ***************************** HELP ******************************** > I would appreciate any feedback/comments on applications that you are planning > to use this functionality for or are currently using it, as well as > any warnings you may have for other people. I would like to include > this information in the tutorial, since one of the objectives is to spread > knowledge on where and how you can use this functionality and also provide > an insight on things to watch for when using it. ************************************************************************ I am also planning to talk with some people in the technical press, and it very likely that they would be interested in talking with users of the package or this type of functionality. ***************************** HELP ******************************** > If you are a user and would be interested in participate in a telephone > conference call with the press for this purpose, please let me know as soon > as possible (no later than Tuesday 2/15). ************************************************************************ We are in the process of running additional checks and fixing reported problems. As soon as a new version is available for general consumption I will let you know. Thanks for your interest. Regards, Jose A. Torres (jose@vhdl.org) From 1076-1-request@sicmail.epfl.ch Thu Feb 23 18:01:18 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Thu, 23 Feb 95 18:01:16 -0500 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Thu, 23 Feb 95 18:01:09 -0500 Received: from alexandra.mtl.com by sicmail.epfl.ch with SMTP (PP) id <14978-0@sicmail.epfl.ch>; Thu, 23 Feb 1995 23:25:10 +0100 Received: (from pchawla@localhost) by alexandra.mtl.com (8.6.9/8.6.6) id RAA17514; Thu, 23 Feb 1995 17:25:32 -0500 Date: Thu, 23 Feb 1995 17:25:32 -0500 From: Praveen Chawla Message-Id: <199502232225.RAA17514@alexandra.mtl.com> To: 1076-1@epfl.ch Subject: Grammer Rules for 1076.1 Please pardon my ignorance. Is there a publicly available set of grammer rules for 1076.1? a public domain analyzer? Thanks in advance. ------------------------------------------------------------------ Praveen Chawla Email: pchawla@mtl.com Electronic Design Center (EDC) WWW: http://mtl.com/public/pchawla MTL Systems, Inc. Phone: (513) 426-3111 ext. 319 3481 Dayton-Xenia Rd. Fax: (513) 426-8301 Dayton, OH 45432 -------------------------------------------------------- EDC: A Design Automation Tools and Services Center -------------------------------------------------------- From 1076-1-request@sicmail.epfl.ch Tue Feb 28 13:44:59 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Tue, 28 Feb 95 13:44:47 -0500 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Tue, 28 Feb 95 13:43:44 -0500 Received: from psi.com by sicmail.epfl.ch with SMTP (PP) id <07364-0@sicmail.epfl.ch>; Tue, 28 Feb 1995 18:09:42 +0100 Received: from analogy.com (analogy.analogy.com) by psi.com (4.1/2.1-PSI/PSINet) id AA00293; Tue, 28 Feb 95 12:08:27 EST Received: from miller.analogy.com ([149.117.72.253]) by analogy.com (4.1/Shared_Spool_1.3) id AA23741; Tue, 28 Feb 95 09:08:44 PST Received: from satyr.analogy.com by miller.analogy.com (4.1/SMI-3.2) id AA12452; Tue, 28 Feb 95 09:08:43 PST Received: by satyr.analogy.com (5.0/SMI-SVR4) id AA00506; Tue, 28 Feb 1995 09:08:41 -0800 Date: Tue, 28 Feb 1995 09:08:41 -0800 From: christen@analogy.com (Ernst Christen) Message-Id: <9502281708.AA00506@satyr.analogy.com> To: 1076-1@epfl.ch Subject: LAT Meeting Minutes Content-Length: 85362 Minutes of the 1076.1 Language Architecture Team Meeting ======================================================== The 5th meeting of the 1076.1 Language Architecture Team was held from January 31 till February 3, 1995, in Lausanne, Switzerland. Attendees were: Ken Bakalar (kenb@compass-da.com) Jean-Michele Berge (berge@cns.cnet.fr) Ernst Christen (christen@analogy.com) Dan Damon (Dan_Damon@mentorg.com) Rapheal Dorado (raf@anacad.fr) Dan FitzPatrick (fitz@cadence.com) Howard Ko (Howard_Ko@mentorg.com) Jean-Jose Mayol (jj@anacad.fr) Siep Onneweer (onneweer@prl.philips.nl) David Smith (dws@miller.analogy.com) Alain Vachoux (alain.vachoux@leg.de.epfl.ch) Minutes were taken by David Smith and Dan FitzPatrick. Contents: -- Discussion -- New White Papers & Owners -- Action Items **************************** Discussion: Tuesday - 1/31/95. Agenda - Review Minutes Review Action Items Create naming conventions plus revision conventions Review Quantities papers I. Review Minutes Reviewed section by section Ernst: takes action item to create a standing list of open issues. David: Section 4.16 - comment on ease of use. As stated it is inspecific as to who it will be easy for. Ken: Should use "ease of use" as a general statement of purpose. David - What is the difference about 4.1 and 4.2? Ken/Ernst it is that 4.1 is a format issue and 4.2 is a content issue of some of the documents which will be created. Minutes approved. II. Review action items 1. Review of open issues by Ernst: Deferred compilation of action items until after all white papers presented (planned until end of Feb.). Ernst will work on refining the list of open issues and send them out before the next meeting. Ken: The items on the list are check-list items as opposed to points of discussion. 2. Dimensional analysis papers put on reflector by Ernst. Ken provided a new reference for dimensional analysis in the language "Simul_r". Ernst commented that this is one of the products which responded to the Euro-Sim benchmarks. It is not clear where to get the papers referred to in the paper. 3. Need to observe currents from outside a model as well as inside - Dan Damon - needed by the simulator not the language. The language does not need them. 4. Composite terminals - Ken has updated white paper using it. 5. Completion of white papers - All of the papers which have been proposed have been delivered. Jean-Michel comments on missing names of authors and version numbers. III. Naming of Documents. 1. Proposed format: 0. Revision History 1. Introduction 2. Definitions 3. Syntax and Semantics 4. Rationale Ken: Discussion included that the tracability to requirements / objectives needs to be done on the entire design at the end of the design to make sure that all requirements/objectives are met. 2. Type of documents: LESs - (names and numbers) New proposal for architecture document - book format 1. Chapter One - Overview of architecture 2. N Chapters representing each white paper 3. Numbering - David: Propose to use name and number convention to ease communication - shortened title. Alain: Need to distinguish between synthesis and analysis papers. Do not need the purpose in the title. Ernst: Need version number and revision history. 4. Purpose of the papers Dan D. What are the purpose of the papers - are they individual views or team results? Ernst: These become the representation of the Architecture teams work. They get presented as such to the working group and reviewed as the teams work. They are not just personal opinions. Jean-Michel - before the meetings which review the document they are individual. After review of the team they become approved. David - do they get approved by review or voted on? Ernst - after all changes (significant ones - editing does not count) have been made then it is accepted. Vote will be taken to approve the content. Dan F.: Need version numbers before any approval. Ken - we need to reach consensus not take votes. Votes are only needed when disagreement exists. Consensus is determined by the chairman. Jean-Michel - when we send on the reflector then it is not a good idea to vote on it since it is not clear who will read and interpret. Jean-Jose - there is an alternative view using nodal not branch formulation. Ernst - we are repeating the same issues as the last meeting. Dan F. - it appears that we are addressing things at a low level view. The high level view or architecture view. Ernst - the charter was to finish the language design. Not just the high level view. We have been working 6 months. A lot of progress has been acheived. Ken - fundamentally disagree that you can design a language talking at a high level. The next step is to clear up the fundamentally logical basis for the language. Without a sound logical foundation no progress can occur. Much of the lack of progress has been due to the lack of agreement on the fundamental basis. Much of the semantics in the "Quantities" document is detailed design. But that was done due to the request from the committee. Dan D. - Dan, what did you mean by high level? Dan F. - One high level design aspect is the issue of formulation method as seen by the user. The use of a quantity object implies one such formulation. Tradeoffs cannot be determined on language impact by developing from the bottom-up. Ernst - high level view has existed for a while in the design rationale. What has not existed is a consistent view of the language. Dan F. - What is missing is the way that quantities are used in formulation, procedures, etc. Ernst - That is true. The white paper on relations will contain this as will other white papers. Ken - committee started with top-down view. LES's are pieces of detailed design. Definitions of Quantities comes from LESs and abstracted to fundamental ideas in such a way that it is precise enough to be wrong; so that people can object. The formality allows/encourages a pointed discussion. Question of bottom-up or top-down is related to the fact that all of this work is derived work and not new work. Dan F. - objects since he does not have time in the current development rush. Feels that he has made many concrete proposals have gone ignored. Ken - Is the requirements document a good view. Dan F. - no there are not. Ken - then we need to back off since they were approved by the overall working group. Dan F. - consistency is not defined. how can you define quantities until you know how they are used and if they are needed. Ken - we need to start somewhere in order to make progress on an engineering project. Can not continue to question fundamentals forever. Ernst - we have a high level view which is defined in the "VHDL-A rational". As to formulation methods it was decided not to use a specific formulation. At the last meeting the question was asked if "the fundamental piece is a set of coupled simultaneous DAEs" and the answer was unanimous that it is the fundamental piece. Based on that there was a clear incentive to look at quantities as a new object which is different than VHDL and to work out the definition. This is the fundamental formulation. Jean-Jose - is it possible to define simultaneous DAEs with this? Ernst - yes, that is the basic requirement that is trying to be met. Dan D. - since there are at least 3 commercial versions here it is important that we have a way to voice objections. Ernst - we are not here to represent commercial interests. It seems that you are asking why are we here? Dan D. - we need to be able to voice opinions without being overridden. Ernst - Is that happening? Dan D. - yes, all the time. We need a formal process so that this can be avoided. Personally, I want to see a language developed. Ernst - questions are being raised as to the charter, previous decisions that have been made, etc. We cannot redefine our charter. I would like to stop that effort. We need to decide on how we are going to work in the future? David - the problem seems to be one of communication and the process to work through conflict. Ernst - communication is being handled through email reflector and the working group meetings. At the meetings we need to be prepared. David - conflict is the problem in the communication not the different channels. Jean-jose - building consensus is at the heart of the problem and it it is an old problem. Ernst - problem of suppressed opinion. As far as the quantities paper: the formalism by Ken was provisionally approved, it did not ignore the objections. We need to proceed to get something done. We need to be all willing to accept other peoples opinions, not necessarily agree but agree to move on using an accepted model. Raphael - last opinion re: "silent consensus" seems to be in disagreement. Ernst - we are trying to use all of the ideas and synthesis the best. Jean-Michel - conflicts are something using. It is not always just communication mechanism, some people use conflict as part of their communication, we need to respect that. The fact that so many papers were created using volunteer effort is a good result. Not making a statement does not mean agreement, making a statement does not mean disagreement. We need to have an explicit way of stating agreement. Enrst - Summarizing: we need a formal approval process. Ernst takes the action. Second issue is that the concern has been raised that opinions have been suppressed. One mechanism is to ask specifically if there are any objects/opinions. Affirm that consensus is the basis for our work. Concern on not having enough time to review the work. The premise is that we will review the papers before meeting. Everyone was informed that it would be only a week and they should make adjustments accordingly. With regard to the white paper naming convetion, use the convention suggested by David - shortened names and version numbers. Close the discussion on process issues. 5. White Paper Structure (Summary): * -> Title and short title * -> Introduction / Abstract / Overview -> Definitions -> Rationale * -> Revision History -> Alternatives -> References -> Examples -> Traceability * -> Body * sections required. IV. Review of Quantities white paper. Ken - With respect to version 1.0 (sent out to reflector). Introduced concept of a basic type to structure description. Separate concerns of basic type from composite types. All notion of type (nature) was removed from discussion of "quantities, terminals, and nodes). Deliberately removed concept of independent contribution to a node. Conservation semantics are preserved. Due to removal of nature, how is a group of terminals that can be connected together implied. Implied, every terminal has exactly one reference terminal, a nature is implied by the set of reference terminals which are shared. A node is a group of terminals which have been associated in an association list. Not described here. Analogous to a net in 1076. Before going on can we decide that definitions are appropriate. Form of definition and way described are appropriate form for use with the LRM. The definition of a term in the LRM is the sum of its uses. The LRM has no tutorial aspect. The glossary is not always correct. Alain - do we need syntax in white papers. Ken - was a little hesitant of the task of creating composites. Determined that it was necessary to free the basic definitions of type. Then can construct any system of composites on these definitions. Could have stopped there. The "Syntax and Static Semantics" is necessary to show that it is possible to construct a composites from the definitions. The values of quantities must have VHDL types because they have values that are used in expressions or else the VHDL expression semantics will fall apart. Ernst - The definition requires an explicit declaration of each quantity. Ken - explicit types are much simplier. Implicit types take much more effort than explicit types. Implicit types in 1076 are limited in number and stereotyped with respect to form. Else quantities must be determined by context and that will require rules for implicit declaration. Dan D. - confusion on what is explicit or implicit. Ken - explicit comes from declaration. Confusion on the definition of a port. Interface signals are used in an association list. An interface signal declared in the port interface list is sometimes referred to as a port. In every place it can be expanded to be an interface signal declared in the port interface list. An association is defined in terms of formal and actual. There is no definition of a formal object or actual object. The thing referred to as formal and actual change due to the association. Using the name of a formal you are referring to the actual itself instead of another signal. The interface signal in a port interface list is an explicit declaration. Dan D. - if the quantity is declared in port interface list is it explicit or does it require another declaration. David - How are implicit signals defined in VHDL? Ken - It is an explicit declaration and does not require another declaration. Each form of an implicit declaration is stereotyped and can be determined by investigation as to which think it is. s'delay in two different places refers to the same signal s. The signal s'delay is a reference to an implicitly signal. In general it is defined by the form of the attributes. Jean-jose - use implictely declared to refer to an implicit declaration. Ken - Guard works as if there were an implicit declaration. s'delay has no place were the declaration exists. This is an issue of the scoping. Guard is scoped. s'delay's scope is that of signal s. A lot of these considerations are left out since there is a strong prejudice that all things are explicitly declared. In the "syntax and static semantics" there is a notion that both quantities and terminals are both declared. Since branch quantities get most of their characteristics from the terminals, it could be argued that branch quantities do not need separate declarations and that they get their type from the use. Suppose name: Q(I).V(K,J).A quantity q is array (...) of s1; type s1 is record ... v:s2 end record type s2 is array (...,...) of s3; type s3 is a record A:s4 end recorD What is the rule to find out what Q is? Dan D. - declaration of Terminal results in some quantities being declared. i.e., once terminals are defined, everything else is derivable (possible exception of branch through quantities). Ken - proposal from Dan is that an explicition declaration of terminal defines some names which are then quantities. Cannot describe multiple branches between two terminals that way if the extra quantities are not explictly declared. David - Must explictly declare new ones but some can be derived from terminals. Dan D. - Does not want to declare syntax. Ken - Then there is a fundamental problem with definitions. Dan D. - No. They are fine. Ken - when discussing declarations then defining syntax. Dan D. - No need to redefine the reference current and voltage. Ken - In the concrete syntax proposed they are given names and they do not have declarations. t'ref and t'con exist on the terminal. Ernst - terminal does not say anything about topology, graph of edges in design. Want to be able to refer to edges that are important. In two-port have an input branch and an output branch. There are 6 or 8 possible branches. Ken - just because an entity has terminals it does not mean that every possible branch exists. Dan D. - in all of the examples - explicitly declaring branch accross voltages and currents. The branch across declarations are redundant. Also, in terminal declarations, reference current is also specified. Ken - I need to know all the branch currents to determine the reference currents. Explicit proposal using Ken's syntax: quantity a through T1 to T2; alternative is: Side tour on referencing a voltage at a terminal: explicit: quantity V across T1 to N'reference implicit: s <= T1'reference s <= V Is T1'reference appropriate, maybe not, could use just T1. The current is the sum of the contributions to the terminal (from inside the model) and can be referred to by: T1'contribution The thing referred to is a value (a function which returns a value). The function is the sum of the plus contributions minus the minus contributions. This is interesting since the logical and physical decomposition are not always the same. The contribution is interesting due to the physical decomposition. It is a fundamental assumption that current flows from somewhere to somewhere. Alain - user decides which branch currents are defined. Some may some may be undefined. Ken - Disagree. Need all constitutive relations or there is not a solution. The fundamental requirement that is being met is support for conservative systems. If that is not the requirement then these definitions must be thrown out. If support for non-conservative systems is not required we need to decide. The issue of implicit declarations is a separate issue. Stereotyped things may not be so different. Allowing conservations violations does not affect declarations. Design decisions stuck in the context of VHDL and how variables are used; objects solved in DAEs have to be different from variables. Ernst - Example of added a quantity from nowhere to a terminal. The interpretation might be that it is implicitely connected to the reference quantity. Lunch Ernst - reopen discussion on question of use. Example from Dan D. was a signal flow block driving a conservative block. i.e., is non-conservative systems handled within or outside the language. Ken - can you write a pure netlist, a hierarchy of design units which has behavior at its leaf level only, that includes both conservative and non-conservative entities connected together using conservative and non-conservative interface elements. Must add behavioral code or interface elements to cause interface to happen. Question: Why do we not add the ability to connect terminal to quantity associations? Must define the sense of this. What sense is it? Possibility is that an implicit equation equating the quantity with the across quantity. Just as valid for through. Dan D. Associate two quantities with the terminal. Ken - What is the through association? A free contribution? Ernst - problem of associating quantity with terminal is that a non-conservative description has the concept of direction while the terminals do not. Ken - can the contribution attribute be a quantity instead of a function. Dan D. - It is an absolutely natural way to consider voltages at a pin with currents going in. Ernst - Inside view is used to describe behavior instead of using and outside view. Siep - reference collector current to drive a source. Ernst - issues are: 1. association of conservative and non-conservative; 2. modification of contribution. (1 - associating a quantity with an interface terminal, and 2 - being able to further constrain a contribution equation). Jean-Mayol - the LES notation gives all of the capabilities of the proposed approach. Ernst - not all, parallel branches are not supported. Ken - (T1,T2)'through could be used. Composite objects introduce problems. Using the type name might not produce a problem. So, introduces a textual mapping which is not available in current VHDL. (T1,T2)'current. The problem with this is that this is the name of a sub-type. Which are legal, how can they tell. Ken - There seems that there is an alternative proposal being discussed. Chairman, how do we proceed? Ernst - We need to finish the discussion of the current proposal and see where it has merit or problems. Ken - The existence of the relation provides severe restrictions due to the need for extra levels of hierarchies. The question of declaration before use. There is not question at all that identifiers be declared before use. The claim that the use of (T1,T2)'current is not a declaration is incorrect since it creates objects. VHDL is a language where all identifiers are declared before use (with some specific exceptions such as implicit signals). Falling on a strong implicit declaration violates VHDL. The last 40 years of programming languages has resulted in strong typing and explicit declaration. Implicit declaration leads to maintenance problems and use problems. A method is required for explicit declaration in any case. Dan D. - Which is different from requiring it. Ernst - At last meeting we adopted guidelines from 1993 standarizations. At the top of that list is the separation of declaration from functionality. These are guidelines and we need to have strong reasons to change. Ken - On a two port device then the terminal currents and voltages exist but the branch currents do not exist. Ken - the fundamental issue is one of the use of implicit declarations. Jean-Michel - Counter proposal can solve modeling issues but create language issues. the implications are not clearly worked out. Return to describing the proposal by Ken. Dan F. - Why not composite nature versus nature of composites? Ken - Shape paralles a type. An array of an element type is a different type. The same types in VHDL occur through declaration (and not form). Want to create free and branch quantity of the same type. Paper is probably a lot more capability that will be used, however these constructs are necessary for maitaining convention. Jean-Michel - Watn to have function-like notation for derivative. Ken - Derivative is not a quantity. Dan F. - Everything seems to be a quantity - used for variables and system unknowns. Ken - Simulator can tell the difference and optimize. Dan F. - Quantities in subprograms can be trouble - Q'delay would be troublesome. Ernst - Q'ddt is similar to a signal attribute and would not be allowed within a subprogram. Ken - Variables in the architecture can be shared variables and subject to other problems. Open issues on this paper. 1. Jean-Jose feels that this work can be extended using implicit constructions. Ken suggests/asked if the definition will consist of for implicit form showing the explicit form. 2. Jean-Jose will look at dynamic analysis. ************************************************************************** Wednesday - 2/1/95. 1. Quantity Definition Extensions proposal from Dan D. Dan changed result of his action item to now requiring the ability to access currents within an entity interface from another architecture. Ernst claims the code present can be written using the proposal in "quantities". ENTITY resistor IS GENERIC(r:REAL); PORT (TERMINAL t1, t2: electrical; QUANTITY io:current); END ENTITY resistor; ARCHITECTURE QUANTITY v ACROSS i THROUGH t1, t2; BEGIN i == v/r; io == i; END ARCHITECTURE; ARCHITECTURE COMONPNENT ... QUANTITY ir:REAL; BEGIN r:resistor GENERIC MAP (...) PORT MAP (...); iout == gain*is; END ARCHITECTURE; Howard/Dan F./Siep: If you create a library of components, you do not know which terminal currents are required using this method. David - Quantities other than terminal currents are sometimes wanted. Ernst's presentation is general but must be defined apriori. This problem has existed in MAST and would be a good advantage if it could be done in VHDL w/o destroying the language. Howard - The syntax is not important but seems like a possibility to explore. Jean-Jose - discussion on visibility and try to draw parallel with existing VHDL usage to show that the use of r.ip does not break a visibility rule. Ken - Can't get inside a block. Dan D. - But these are external terminal currents. Siep - And this access will be limited to terminal currents. Ernst/Ken - Formal is not visible at this level. Dan D. - Terminal current is outside of device and should be visible outside of the device. Ernst - The formal is not visible - this is a language issue. Jean-Jose - If necessary, should propose extensions that will make it useful. Ernst - If we create something new, why not then create something that is more general, that allows access to any quantity declared in a design entity. This would be useful for things like hierarchical summing of power. David - The general case may be interesting but the claim is that accessing the pin current is very important and merits special considerations. Ken - Can't break VHDL. To do this we need to definea new type of selected name and determine if there is a way to declare this. Jean-Jose - However, these visibility rules have already been broken. Ken - the problem with accessing the terminal contributions to a node is that it is currently not supported using the existing VHDL visibility rules. Someone needs to take on the task of defining the changes to the selected visibility rules within the VHDL LRM. There is not a selected name in VHDL such as r.ip. Jean-Jose - Will take an action item to write down visibility and selected names for terminal currents. COMPONENT resistor IS PORT (... t1, t2 : electrical); COMPONENT; FOR r1 : resistor USE ENTITY MyResistor PORTMAP(t1=>...); QUANTITY ir: through r1.t1; BEGIN r1 : resistor PORT MAP (ip1, ip2); RELATION ... iout = gain * ir; END RELATION; END; t1 is visible is due to it following a special selected visibility rule. Claim that this rule is easy. Ken - someone needs to write this visibility rule. See the chapter on names in the LRM (Section 10.3 pg. 143) - visibility by selection. Need to add another rule to the list. It is not clear that it can be written. If so then things work. Jean-Jose - need this rule for the access to work. Ken - be careful when defining the visibility rule that you consider the hierarchy of blocks and consider the various levels of map that can go on; the elaborated nest of blocks. Ernst - problem from Siep - ENTITY foo IS PORT (TERMINAL t1, t2,t0:electrical); END ENTITY foo; ARCHITECTURE bar OF foo IS TERMINAL n1: electical; QUANTITY v1 ACROSS i1 THROUGH t1 TO n1; QUANTITY v2 ACROSS i2 THROUGH n1 TO t0; BEGIN R1: ENTITY resistor(linear) PORT MAP (n1,t2); C1: ENTIRY capacitor (linear) PORTMAP (t2, t0); t1: i1 == f(v1); t2: i2 == f(v2); END ARCHITECTURE bar; This shows the use of structure and behavior intermixed. Raphael - what is the difference between a node and a terminal, why is the terminal needed? Ken - the node is after elaboration while the terminal is what gets elaborated. Ernst - The node is the set of terminals in fully-elaborated designs associated through port maps. Dan F. - What is the distinction between terminals and nodes? Ken - Similar to the distinction between signals and nets in VHDL. Siep - what happens if there is a parallel branch to b2? Ernst - Add the following: QUANTITY v2 ACROSS i3 THROUGH n1 TO t0; b3: i3 == f(v2); Dan D. - I think this meets my need. 2. Other questions on "quantity" papers. Jean-Jose - Add an example with both through and across in the paper to show the use of a branch definition. Alain (rephrased) - Since both types are associated with the terminal, then both current and voltage should be of the same type. Ken - this is described in the "unwinding". quantity across through gets unwound into a declaration for each element of the list. Alain - an example of this was sent out in the email after the Columbia meeting. Jean-Jose - the question of compatible form in the non-simple nature between the across and through. Is there a more natural way to write this? Ken - Is there a question about any particular rule in the "quantity" paper? Jean-Jose - The basic type must be the same for the through and across. Ken - not in the way it is defined in the paper. Why does? Jean-Jose - it is the same object, a value, a type? Ken - they both have to be floating-point types. Why the same type? Jean-Jose - There is a link. Ken - You are talking about dimensional analysis. If done then it must be done within the definition of a single type. Jean-Jose - The choice of describing nature will imply dimensional analysis requirements. Ken - The example is just syntax. There are many places this good be added. What does syntax have to do with it? Jean-Jose - that is correct. It is just syntax. I would like to have dimensional analysis considered as part of the definition of quantities. DIMENSION voltage Ernst - I disagree. You are restricting the adding of dimension to just nature. Jean-Jose - For quantities add it to the declaration of quantity. Ernst - This disallows having dimensions on free quantities and signals. This discussion should end and be taken up as an action item and/or proposal. New topic: Ken - the terminal'contribution (contribution expression) that is a first class quantity in section 2. Which meets parts of Dan D.'s requirement since it allows t'contribution in a constraint. Enrst - need to further restrict t'contribution to a contribution expression but not to a conservation expression. Ken - it refers to the right side of the conservation expression. Ernst - I have concerns about that aspect. Ken - there is no syntax to refer to the conservation expression. Therefore there is no problem. Jean-Jose - t'contribtution is? Ken - it is equal to the sum of the contributions on the terminal. In Ernst's example you can print out the value. Ken - selected visibility will not work for Jean-Jose's action item. Selected visibility works within scope. It is a need to extend the scope. There are rules for extending scope. The scope extension rules all deal with parallel level. There are none that change level. It is not like a configuration specification. You need the signal in the nested declarative region. Ken - t'ref is a quantity also. No more discussion on the quantity paper. Ernst - can we adopt this with the discussed modifications? Take this as a working basis for the rest of the discussion. Dan F. - Abstain from voting on it. Useful discussion in which I learned a lot. However, I am not ready to accept the paper as is because without an idea of where it is going I cannot understand the implications. There is also an issue concerning the definition of acceptance. Ernst - Definition of acceptance: Take the vocabulary as a basis for the future discussion at this meeting. This includes the definitions and everything of the "quantity" paper. Ernst vote on acceptance of quantities paper as defined: yes - 6, abstain - 2, absentees - 2, no - 0 3. Simulation Cycle paper - Ken Follows definition in LES-N. This should not be contraversial. Digital simulation cycle - time increments which proceed based on next event. Job of the analog kernel is to catch up in the time intervening between two analog events. One occurs first during initialization. There is a cycle during which both kernels run. Every time there is a digital event there is an opportunity for an analog evaluation. The evaluation may be null. At the beginning of a simulation cycle (end of last). tn - next time at which a digital event will occur tc - current time At tc, current time, a new time is calculated, tn. It is the job of the analog kernel to evaluate and then move time to tn. Howard - will the digital step backward? Ken - no. David - the analog kernel may generate a tn < tn before execution but greater than tc? i.e., what happens if analog side generates an event. Ken - the complication ensues when a threshold crossing occurs. The effect of a threshold crossing is to schedule an event on the implicit analog signals (q'crossing, q'rising, q'falling). The analog kernel is responsible for determining this time and shortening the interval between tc and tn so that it can be evaluate. Dan - characteristic equations, can you expand on the explanation at the appropriate time? Ken - What remains is to define how the threshold is calculated. Alain - why implicit analog signal? Ken - to refer to the class of signals which are used with analog. The model is differential algebraic equations. A conforming simulation approximates a solution to these equations. The problem is that approximate is inspecific while the designer considers an exact solution. For the purpose of the definition of the cycle it is assumed that equations are analytical (use limit processes to describe them). Ernst - Description arranged in order of LRM which is not casual. Howard - Viewing it as function of time. Are we going to address what happens when we extend beyond just time? This is an issue that needs to be addressed. How to extend section 12.6.4 to other than time. Ken - want to make the notion of crossing specific. For example: q'crossing: Q(t) = E (E is the threshold value) At certain times there is a solution to this equation. For q'rising and q'falling the issue is the direction it was going not just the crossing, this adds another equation: q'rising (dQ(t)/dt > 0) for both the left and right derivatives. q'falling (dQ(t)/dt < 0) for both the left and right derivatives. There may be some problems with the exact equations but this is the method to use to define the signals. Once the characteristic equations are defined then they are used to define the boolean value of the signals. Howard - Do we need to extend this beyond just time representations? Ken - This is just an extension of the mixed-mode sim cycle. Howard - Shoulw we extend or have something to cover the analog simulation cycle? David - We will need to address frequency domain simulation in 12.6.4 and 12.6.5. Ken - Want to make specific the notion of crossing by reformulating it in terms of the others. For rising and falling, add an additional constraint. Dan D. What are the left and right derivatives. Ken/David - As approached by either side around t. Ken - Once you have the characteristic equation, you set the characteristic function. Dan F. - What is the impact of this within subprograms? Ken - there is a problem with accessing signal valued attributes within a function. This is a restriction. Dan D. - what happens when the signal stays at the threshold? Ken - we could define a signal attribute called q'at which held that value for as long as the quantity is at that value (within some threshold). This requires a new rule on the update for this signal. Each implicit signal requires a new rule which may be shared (the three defined here use the same update rule). The implicit analog signal as a set of characteristic equations which have a root which is true. If the q(t) is not continuous then we still need to define the charactistic function. This is done be looking at both sides of the discontinuity instead of the derivative. Siep - Does the E have to be a constant. Ken - Depends upon how the attributes are defined. Current definition is not adequate. Siep - Take the derivative of Q(t)-E? Ken - The value E has been defined to be globally static. AK executest at tc and advances time to tn. The new tn is the same as tn if there are no crossings else it is the lesser of tn and the time of the crossings. Siep - should the accuracy of the determination of tn be discussed? David - Defining issues of accuracy usually lead right into definitions of kernels. Dan D. - Could be an issue for the validation suite (for tools). Ken - I am assuming that the values are exact even though we know that it is approximate. Do we need to define more of what approximation means. Define everything in terms of the ideal and then discuss where the ideal is not met. Prefer to describe ideal and then how real cases approximate ideal. Raphael - is there a way to define the maximum time step? (limiting the time step). Alain - Analog Kernel determines its own time steps within the bounds of tc and tn. Ken - the analog solution at tn is the only one that matters. Siep - do you force the AK to find a solution at tn? Ken - I only say that the solution exists not that it has to be calculated. This is an optimization step that can be handled by the kernel. This is a modified lock-step algorithm. Siep - So interpolation can be used to define the analog solution at tn? Ken - yes. Siep - you can only reference the quantities through the analog signals? Ken - no, an analog quantity can be used in a process. Howard - is there a synchronization mechanism that needs to be defined? I assume that there is an event management that is being handled outside the analog kernel. Ken - the synchronization is being handled by the analog signals firing. The requirements on the AK are those in 12.6.x. It has to calculate the values tn' and solve the equations at a series of points. This is the only burden placed on the kernel. The AK may do other things. Dan D. - The events become the synchronization method so we are not really defining the method. Howard - What is the method for communicating between the two kernels? i.e., how does the analog kernel update the digital kernel? Ken - Don't know the consequences of implementations working in separate address spaces. Howard - how are the analog events inserted in the digital kernel? Ken - this is dependent on where these paragraphs are inserted into the digital kernel. It is done in the intervening paragraphs. 12.6.3 - describes need and how to update the analog signals within the digital kernel. Howard - what happens if the analog event can be processed only within the analog kernel does it require it to be scheduled within the digital kernel? Ken - yes Dan D. - this could be optimized out? Ken - we need to define what legal optimizations are. Support for execution of this algorithm in multiple processes would be expensive. Language on update of analog signals in 12.6.3-602 is convoluted but an exact copy of the language for the digital signal udpate. The result is that it is true for one simulation cycle and then reset. Ernst - would it be possible to combine this with the description for s'stable? Ken - not quite there are a few differences. It is surprising how little apparatus is here. It is not clear that it works. Aside on English language for all of the native english speakers: reify - to make real On Breaks: Ken - modeler must inform ASK of discontinuity. A model which is going to generate a discontinuity? The modeler must inform the kernal that the discontinuity is going to occur and be dealt with. Dan D. - does the analog kernel issue a break? David - Two options, explicit breaks or make the ASK smart enough to know when discontinuities occur. Ken - Not sure that the modeler can know when a break occurs. The implications of this will be clear when looking at more examples. Ken - the break is a sequential statement. This is the same as in LESs. It cannot be called from a subprogram called from an analog portion. It can be called from subprograms within the digital processes. When a break statement is executed it sets an event on a signal. This signal has no scope so it is not visible. break <=1 after 0 seconds; The sequential process waits, all processes evaluated. New cycle. The analog kernel executes. If it executes with the signal break active then it has to restart at this point in time. The other things in the break statement are: when condition - test on value and is true/or false based on the value. This is not the same as q'crossing. break_list - when the analog kernel finds that the break is active it will look at the brake_set for the current cycle which is built up by execution of break statements. These are a set of quantity-value pairs which force the quantity to a value when the break occurs. It will probably be nice to have a concurrent break statement. Examples: Bouncing ball: architecture ball of bouncer is quantity v: velocity := 0.0; quantity s: displacement := 0.0; constant g: real := 9.81; constant air_res: real := 0.1; begin break v => -v when s'crossing(0.0); s'dot == v; if v > 0.0 use v'dot == -g - v**2*air_res; else use v'dot == -g + v**2*aire_res; end use; end ball; If the crossing of v is important then add: break when v'crossing(0.0); Other examples from handouts. There is an assumption of unified time in these examples. That is that the digital and analog time are the same. Another assumption is that there is an intimiate cross referencing of signals and quantities. The use of the break statement to perform initialization of a quantity at the break needs further investigation. The way it is currently defined adds an addition constraint which results in over specification of the system. Ernst claims that this results in a problem in the solution of the system. Ernst will investigate. The issue of creating breaks for the purpose of simulation and the ability to create a smooth waveform (sinusoid) for display are separate issues. The second issue has not been addressed. Siep - Interesting how to define how these models behave with numerical inaccuracies. Ken - Haven't defined how models behave w/inaccuracies. Ernst - Converted models to MAST and it worked which would assume that it will work with inaccuracies. Ken - Requires looking at defining a unified system of time that allows tight coupling between analog and digital kernel. Jean-Jose - When will the ASK receive the output from the break; Ken - When break evaluates, new value of quantity is stored. At that point the analog kernel is executed and the AK knows it needs to update the initial conditions and find a solution - if no solution then something is wrong with the model. Dan D. - Can this be done without a break statement? Ernst - Can probably do this but not efficient. Dan F. - Can be done, but not necessarily within the current design/ framework. Siep - How do initial conditions specified within the architecture be resolved w/external specification (as in pendulum testbench). Ken/Ernst - Initial conditions have not been worked fully thru. Ken - Can result in an over-defined system and there better be a solution. Ernst - Reset specifies the IC as the simulation proceeds. However still requires as many equations as there are unknowns. As additional constraints are added, the system is only solvable in a least-squares sense. Simply adding new constraints for ICs will not do. Ernst - open discussion for issues/problems on simulation cycle. Alain - the material on the definitions are not definitions they are modifications to the LRM. Ken - the quantity paper definitions could have been done as a set of LRM modifications. The definitions/syntax/semantics were done to separate the basics from the exposition. The papers are divided into two parts. First is a definition or statement for the LRM. The second section is the discussion or the rationale. Open: What does approximate mean and what apparatus is needed? What new implicit analog signals are needed/wanted? Analog signal definitions Initialization - not defined Initial Conditions - relation between reset and initial condition. Alain - What about Q'at(T)? Other attributes such as Q'last_value(). Dan F. - Q'last_value() encourages bad modeling practices because dependent upon simulation environment. Ernst/David - Also dependent on issues w/error estimation. Raphael - For Q'delayed(T), T should be variable. Ernst/David - If T is static, then you know what to throw away. This is important when storage is an issue. Siep - Q'delayed(T) should return quantity type due to time-step relations to T. This must be included for consistency. Ken - If Q'delayed(T) returns a quantity, then user can set that value. Dan D. - need to clarify that an analog signal can be generated during a single invocation of the analog kernel. Ken - Open issues (rehash) 1) additional signal-valued attributes, 2) additional function-valued attributes. Ernst - takes action item to provide semantic definitions of ddt() and integ() to ken (personal action item). Ken - function valued attributes are mentioned, thinking of delay attribute, what others are required? Possibility of providing a function which returns a value of a quantity at a point in time where that point in time might be globally static or dynamic (two different issues). Marginal utility. Recommendation to not being able to access q'last_value. Other possible signal valued attributes is an open issue. Jean-Jose - issue of connecting a terminal to a signal is an issue of D/A conversion. Ken - the information that is covered is the only information that can be used to deal with the D/A problem regardless of the syntax used to connect the signals and quantities. A/D requires the ability to use the name of quantities and a mechanism whereby processes are forced to execute in response to events on quantities. These are covered in this document. Dan D. - A minor error, paragraph on when Q(t) is not continuous in section 12.6.x the equal sign is on the wrong side. David - Must look at all nine cases about a point and which one requires an attribute. Dan D. - However, the treatement for continuous and discontinuos cases are different (as presented). David - Yes, appears that the definitions are different and should be the same. Seems to be inconsistent in how derivatives are treated with on both sides. The definition should be looked at later. ************************************************************************** Thursday - 2/2/95. I. Adoption of work on Mixed Mode paper. Adopt paper as base for continuing the work? Open issues on the work. Ken - unclear on 12.6.x philosophy in context of ideal simulator. - what implicit analog signals do we want and how are they defined. Imprecise calculation needs to be considered, 'at which says that q is indistinguishable from E. - this presentation must be integrated with the Quantities paper in the respect that all of the definitions are based on basic quantities - all semantics defined on basic quantities (scalar subelements and not composites). Basically requires just a language cleanup. - whether breaks are necessary - whole set of issues arise because calculations are inprecise. Dan D. What about "if-then" statements? Ken - "If-then" statements is not precise enough. May need a Q'at(). Ken - example of problem is a waveform which reaches a threshold from below and then oscillates around the threshold and finally leaving the threshold. How many crossings does this represent? Dan F. - in the Cadence language provides a way of defining a tolerance (absolute and relative) on a voltage (similar to the spice tolerances) which are then used to define the crossing. Ernst - unclear whether the accuracy is a tool or a language issue. This is a high-level architecture issue brought up by Ken Kundert. Dan F. - The accuracy constrants were defined on the nature to account for largely varying signal magnitudes (relative accuracy). Ernst. - Specification of behavior should be done in an ideal way. The solution may have an inbalance. Ken - Behavior can depend on tolerance if we look at Q'crossing(). The question in general comes from portability. David - Tolerances might not be the same between different simulators. Dan D. - Package for controlling different types of simulators. Ken - For static tolerances - can use user-defined attributes and the subject can now be closed. David - If accuracy is a modeling probelm it should be dealt with in the language if not simulator. Ernst - Can be defined in the model with two threshold functions on both sides of the band. Ken - proposes Q'crossing(E1, E2), Q'crossing(E), Q'enter(E1, E2), Q'exit(E1, E2). David - This can be used to hide the accuracy issue. This problem can be solved without affecting the language. Ken - If this is acceptable to customers, it would be OK with me to deal with the ideal simulator. David/Ernst - Dynamic range problem is not limited to mixed-technology problem. So tolerances on units do not solve this problem. David - Cases where modeler knows where the model is designed for but user will know how it is being used. Raphael - Designers and model writers would not likely be able to use VHDL-A if the tolerance capability is not there. Howard/David - Spice users will tend to try and use it like Spice. David - Can't just put this there without doing anything with it as it would be misleading. Ken - An easy spot to put tolerance information would be in the subtype classifications. This follows along with ranges. Subtypes is type with constraint where the tolerance would be an additional constraint along with the range. Siep - I think it improves portability (there is a positive impact). Ken/Ernst - Specifying tolerances specifies the algorithms. David - Can we use subtype range to develop error criteria? Ken - In addition ot value range, the simulator cannot expect numbers outside of that range (??). Ernst - How is the range tied to tolerances. Ken/David - Scale it to the range (by the global tolerances). Ernst - However, there are other mechanisms such as the assert statement that are used to do this (ranges). A model writer will be unlikely to use the range mechanism. Jean-Jose - Passive processes can be used to determine whether a model exceeds it expected values. David - Summarizing. Issues are 1) tolerances on quantities and 2) additional implicit analog signals. Ken - 2) is just syntatic sugar with the same functionality that can be provided just in terms of the ideal simulator. Ken/Ernst - Action Item - Go back and address these issues. Howard - accuracy or close approximation, it is important to know where it is applied. Ken - how do we resolve the question of whether a break is needed. Siep - all spices have this concept. Ernst - the question is whether an implementation can reliably find this automatically and what impact is this on performance. Siep - no it cannot. Dan F. - I do not agree entirely that breaks are needed and would like to go back and discuss this. Ken - do we agree that the problem statement on 12.6.x is ok. Agreements voiced. Dan D. - We need to not loss the issue of error tolerances. Dan D. will own it. Ernst - can we approve this document as a working bases for future work. Ken - this implies broadcast to the committe at large after some updates. Ernst - This means it goes to the reflector. Can we adopt this? Vote - For - 10 , Abstain - 1, No - 0 Abstain based on dependencies with the Quantities paper. Break. II. Initialization white paper. Presentation by Ernst. Siep - value of integral at time zero (DC?) is not necessarily zero. issue - initialization of integrals. "Need to be solved for". Sumary: The definition of stimulus appears to be a problem. issues - how to determine which solution to find in multiple solutions, is this part of the language or part of the implementation? Spice tries to solve this with initial conditions and nodeset. Ken - System ends up at some legal DC operating point but not necessarily correct. Ernst - For consistencey -> Analog pieces have a concept of DC solution for the quantities. -> Signals have values after evaluating all delta cycles. Ken - In other words, time is ready to advance. All quantities are known. Ernst - DC consistency ios very system dependent (no more events at time zero plus analog solution at the t=0 given these signal values). DC consistency is useful to mimic startup process. David - Without DC consistencey, don;t have basis for doing frequency analysis based on Ernst's presentation. Ken - What DC consistency does is consider signals for determing the state of the analog system. Ernst - Typically in logic simulators, if stimulus is not part of the language, an equilibrium condition is defined. However, for VHDL in which stimulus is part of the language there is no concept of an equilibrium condition. David - Multiple simulation cycles depende on what is being done. i.e., define two different simulation cycles. Ernst - These two cases can acutally lead to four proposals (represented as three ways to DC operation point solution and one without - same as LRM now). David - What is default for analog and if digital is brought in what happens? Ernst - need case consistency with LRM and one case for DCOP. Re: Time domain initial point and initial conditions. Ernst - Nodeset is spice cludge that will work. If there are multiple solutions, then it is outside of the language on how to specify them. Siep - Consequence is that tool builders will add what is necessary. Ernst - Could extend the concept of interpretation domain to digital.` Ken - DC initialization could answer some global questions of digital requirements. Dan D. - Need to have DC (similar to Now) and a transient. consider the problem of capacitor in parallel with a source which results in an infinite large time. This results in a problem of inconsistent constraints which needs to be considered. Ernst - Can resolve these through delta pulse to "adjust" the ICs to be consistent (but not the same as specified). Ken - Are initial conditions global or local - can the decision be made jsut looking at locals and generics. Ernst - Spice can allow IC on instance as well as .IC command for setting the node. From global perspective, nodes in nested hierarchy should be visible in the design. This brings ups the concept of IC for a signal as well. Ernst - which one of the three DC approaches should be pursued. Ernst believes that only one of them should be pursued due to: a user of a tool does not want to have to worry about which DC solution should be used; he wants a predictable result. The consistent DC solution seems like the most beneficial. The others are subsets which do not have interesting characteristics but are short cuts if the consistent DC solution cannot be used. Nomenclature: 0 - no dc simulation (no DC) 1 - handle only analog DC solution with digital initialization 2 - execute all delta cycles at time 0 with dc model (consistent solution) 3 - dc operating point (consistent DC) 0 is required. 3 is desirable. 1 is a subset of 2 so ignore it. 2 is a fallback if 3 is not acheivable or fails. 2A is the case where case 3 is performed with the DC model for the interation. This may result in case 3 in the limit. Ken - case 1) is a special case of 2). 0) and 3) are required and 2) is a fallback if 3) is not possible. Ernst - Two uses of ideal sources 1) power supply and 2) stimulus as either waveform or spectrum. Can derive DC from time-domain except in the case of stimulus (as defined in the glossary). Alain - If we choose 3) there are problems between models that work in a 1076.1 compilant simulator. The results will be different (even for pure digital model). Ken - what is a DC digital model. Ernst - that is only an issue in case 3. The assumption in the other cases is that stimulus has no effect in delta time at time 0. David - there is a potential problem with the number 3 that digital models (which are pure digital) which have been created to work in a mixed-mode simulation may not be able to be used in a pure 1076-1993 implementation due to constructs for handling DC modeling. Raphael - Initial values can cause propagation of values via delta-delay that can lead to oscillation under 2) and 3) (e.g., ring oscillator). Ernst - Re: oscillators - is it part of model or stimulus. Theoretically, it should not have a DC solution althought one will typically be found. Ernst - consensus on case 3 and case 0. Case 2 should be an alternative. Environment white paper. Presented by Jean-Michel Reviewed the 6 different levels of packages and classified the different capabilities into these levels. Jean-Micheal - Level 4) requires package written in VHDL which implies attributes are constants (and cannot return function). Ken - This should be a level 4) package if it has an intimate contact with the kernel. Jean-Micheal - Level 4) implies it can run on every platform because it is written in VHDL. e.g., Math package will go in level 4 to become coordinated with 1076.2. Ken - alternative taxonomy 1 - language extensions 2 - analog standard library 2.1 Standard package 2.2 other package or design entities 3 - other libraries 1 and 2 are in the LRM. 3 is outside of the scope of the LRM. Cannot use implicit library or use clause. Make the additions to package standard since the analog standard makes no difference. The library name will never be use if it is implicitly loaded. ************************************************************************** Friday - 2/3/95. I. Continue with discussion on Environment Ernst - send thoughts on what needs to be in the various packages and other things to include to Jean-Michel through email. Jean-Jose - issue of complex support for Frequency and its impact on the math package need to be considered. Jean-Michel - does the Environment paper do the complete definition of things like q'ddt, q'crossing, etc? Ken - attributes are document in the text and in the list at the end of the LRM. Ernst - the definitions of the attributes will be done in the white papers most appropriate such as the Quantities paper and the Mixed-Mode paper. Ken - there are problems with how they are defined in the current LRM that will have to continue to use. Jean-Micheal will rework the paper. Paper on Relations. Presented by Alain V. Alain - This paper does not include a synthesis of the previous discussion. Would like to get some feedback on the correct directions to take. General goal is to encapsulate behavior. Explicit constraints are given by the user. Implicit constraints are derived from the topology and connection semantics. Ernst - implicit and explicit constraints can be used to generate a tableau formulation which could be solved or optimized into a specific formulation (as sparse tableau can be optimized to MNA). Dan D. - use of explicit and implicit make this unclear. Ken - we need to use these as used in the LRM: explicit means it is written down and implicit means it is not. Jean-Michel - replace explicit form with closed form and implicit form with root form and fixed-point form. Agreed. Ernst - from Ken's earlier examples it appears that is required to have a real tight interaction between constraints and digital sections. Relations must be consistent with concurrent statements. Ken - we have a name here for a block of code. This allows us to discuss this so that we can contrast it with other sections such as blocks. In my mind a block and a relation are the same. Blocks are a declarative region and not just structural. Alain - added the general form to the paper which all the other forms are subsets of: f(qm,...qn) == g(qi,...qj) Ken - the closed form has the property that an equation in this form can be eliminated due to substitution. Alain - Semantic of == is that f(qm,...qn) - g(qi,...qj) == 0 will be ensured by the ASK (Analog Simulation Kernel). Removed the "quantity assignment" since it is not an assignment. Siep - the fact that the closed form has a special property is not that relevant. It would be possible to optimize with this but it is not different than the general form. Howard - the definitions of the form do not include the derivatives, integrals, time, etc. This makes the use as substitution even more complicated. Alain - Constraint involves numerical expressions with: quantities solved branch and free q's variables read only numerical type, shared possible signals read only numerical type constants read only numerical type literals read only numeric literals functions return numeric values, pure/impure predefined and user defined variables should not be affected by the constraint. quantities do not have read and write, they are solved for. Examples - variable x:real; x == 2*sin(x) This should not be done with a variable since it is changing the definition of a variable. This can be done with quantities with no loss of capability. Jean-Jose - why not read and write on quantities? Ken - this is only in the constraint, the meaning and use of variables is unchanged. Jean-Jose - why limit them to pure? Ken - I do not think we can limit them to pure. Ernst - this is the same problem as shared variables. We do not have to consider an iterative process. If it is a well-behaved impure function then there is no problem. If not then it causes problems. Ken - there are cases where we have to be able to use impure functions such as the function now. Dan D. - can you do q'ddt'ddt? Ken - yes Ernst - Analog subprogram purpose was to solve small unconnected systems such as roots of equations and assign to a coefficient. David - Want to be able to solve things constant in value that are outside of the solution set. Jean-Jose - Why can't variables be written? Ken - can be shared. Ken - why do we need a new mechanism to create a local scope? The reasons would be to change the set of things in the declarative part or the set of statements in the statement part. Alain - cannot declare local quantities. Ken - why not? if all the use of quantities are in the relation then why not use a local quantity to declare the scope. This would indicate modeling intent as well as provide for an optimization. Ken - the statement that this is only handled by the ASK is not relevant since this is an implementation issue. Jean-Jose - this is to "highlight" or exteriorize an idea about how this is used. Ken - is there an example of where this is done in the current VHDL? The reason for creating declarative regions is as I stated above. That notion is more textual than an idealized thing. There is nothing else there except for those two reasons. Ernst - why is it necessary to encapsulate the constraints instead of just encapsulating the procedural part? If there is a procedural part why is it not sufficient to just encapsulate this part. Ken - the use of these constraints within this declarative region will result in the ability to declare variables locally (which are really shared variables which are declared as such). Need to use relation begin ... end. Need to separate declarative part from the statement part is the reason to require the begin. Siep - why is the equation (ir) used? Ernst - Deemed important by some people who thought it was necessary when there was a tight coupling between procedural and equational sections. Dan F. - the use of the branch declaration specifies information about vr and ir in the resistor example. This did not exist in the previous approach. Siep - it should go away (specification of ir). Jean-Jose - the real issue is how to go from the relation form to the non-relation form. Discussion on procedural part: Alain - optional used to setup parameters for the equational part (constraints) a constraint in the procedural section would consist of only local quantities. It can then be solved independently. Suggests that there can be independent subsystems where local quantities can be solved. David - User could provide information to optimize this process but highly unlikely. Need to consider the coupling that typically exists. For partitioning for relaxation methods, this might be possible but then the language would be driven by a particular implementation. Any optimization other than this is discoverable anyway. Ken - Assuming we define the time at which the procedural part is evaluated it is odd that only part of a declarative region is elaborated. Alain - Don't provide any solution becuase this is part of ASK. Ken - how does this correspond with the sequential formulation notion of the procedural part? Jean-Jose - since the local variables are "re-elaborated" for each evaluation of this block these are not shared variables. Ken - re-elaboration of the declarative part of relation, it is not clear what the time is when this occurs, makes this a very strange region. Are everything re-elaborated (constants, local quantities)? Are some of the things re-elaborated? Alain - this will determined by how these things are used during the simulation. Siep - so go on and describe the handling the relation and the procedural part. Alain - I do not have any information on this, this is part of the simulation cycle. Ernst - there are two ways of doing this. One is to define an algorithm such as a simulation cycle and the the other is to define clearly the semantics of these pieces in which case the interaction falls out and the algorithm is not required. The result of this could be that one of these is not needed. The only unique piece of the relation is the ability to create a constraint which is only defined in terms of local quantities. If that is the case is it important enough case to introduce this or is it sufficient to allow the implementation to do the optimization. Alain - in an early meeting it was expressed that the support for a procedural part can always be reduced to constraints. We need a section of code where we need to express sequential behavior. Ken - we have a couple already such as functions and procedures. We are introducing a new way of formulating sequential code and what are the reasons for creating a new one. Alain - in the mos example the charges can be declared locally to the relation. The use of the charges as the result of a function of the voltages. Ken - if the := was replaced with == it is identical. So this is not a reason for having a relation. Alain - this could all be moved from the relation to the architecture body. Ken - it would be useful to avoid making mistakes. Is this sufficient to distinguish from the block. Dan D. - what is the cost? Ken - it is just increasing the complexity due to new constructs. Ernst - Paper at DAC'94 about cost/benefit of new features so that tradeoffs can be performed. This was applied to some of the existing features which showed that the benefit was far less than the cost for some of these. Ken - the partial re-elaboration rule is a new concept. The statement was made that the variables declared in the procedural within the relation are re-elaborated. Can there be multiple procedural parts in the relation? Alain - only one Jean-Michel - in a block you can have processes so if used in a relation then the interaction must be defined. Ken - no we don't this is already defined. Can you use generate statements within a relation? If so then you must be able to use blocks. Alain - what could be generated? constraints? Ken - that could be interesting. Jean-Michel - the scoping is different in the relation so that processes are not visible within the relation. Ken - need to focus on what the new declarative region brings to the language. This suggests that the purpose of the relation is to exclude processes. This is not useful. There has to be a more basic reason. Alain - need to ask the question of whether a constraint can be in a process. Ernst - if we can get the questions down then Alain can use it as part of his work on the paper. Question - why do we need a new declarative region? Question - what restrictions exist or are excluded? Question - what delcarations exist or are excluded? Issue - the partial re-elaboration Question - notion of procedural not clear, may not be consistent with previous discussion Question - need to define the statement class called simultaneous Ken - we need a coherent development of the subject. Discrete questions are used to make sure the developed position result in answers as opposed to the developed position being just answering these question. A foolish consistency is the hobloblin of little minds. Quote from Emerson. There has to be a synthesis that expresses the complete idea of what needs to be accomplished. Not just the past discussions. Ken - has proposal for what procedural is. (incomplete) Jean-Michel - we need to define what is meant by a simultaneous domain. Ken - this includes what are the members of the statement class Is a procedural a statement or a declarative region or ??? It would be a statement. Alain - I will continue to work with Ken and Jean-Jose to develop this work. Ken: some ideas on the relation/procedural Extended sequential statements by break statements Extended concurrent statements by break statements New class of statements called simultaneous. Concurrent statements - solved one after another with no order dependency Simultaneous statements - are solved simultaneously Class of simultaneous statements (can be used in a block): Name: Example of syntax: ===== ================== simple simultaneous constraint(==) simultaneous conditional if ... use ... simultaneous case case ... use ... simultaneous (procedural/process/ sequentional formulation)? simultaneous conditional: if use {simultaneous statements} else {simultaneous statements} end use; may have some things that can be tested for with this. block statements will be extended to contain simultaneous statements. Jean-Michel - cannot have simultaneous statements in a sequential context. Ken - consider it a hierarchy with sequential statements at the bottom. simultaneous case: case use when -> {simultaneous statements} end case; simple simultaneous: using symbolic notation want to write: f(q_vector) == g(q_vector); where f and g are expressions with constants, functions, quantities, variables, etc. This represents a set of algebraic differential equations. The claim is that there is little analysis of the form of these equations that is possible since the functions may be foriegn. Another form of this: f(q_vector) - g(q_vector) == 0.0; Propose not to introduce any concept of algebraic manipultation into the language. Introduce concept that if f and g are evaluated then they are close. Proposed semantics of statement are: when the analog kernel finds the qs then the constraint holds. The mathematical operators and functions can then be assumed to have there meaning. For example a function which is not a build-in can have any meaning. Could bring up issues related to using sine. Math package uses a fairly coarse representation. David - it is a minimally compilaint sine implementation (6 digits). Ernst - Two options. 1) Make our own math package or 2) The header will be the only part of the math package that is actually balloted. The body will be supplied only with an implementation. Issue - there is no point in the simulation cycle where it is stated that f and g are evaluated. The reason is that the constraint is defined in terms of a test and not given as an algorithm. Want to call this hypothetical execution. It never happens in terms of the language. No signal assignment, shared variables cannot be changed. The conditional in the simultaneous conditional is: a boolean expression with primaries which include: signals, shared variables, constants, and quantities The definition is that each of the conditionals test true. This has a concept of a hypothetical testing. The simultaneous procedural: suppose the following definition: analog process variables, constants, functions (not signals, quantity) begin {sequential statements} q := 3; end; The sequential statements can refer to quantities as if they were variables. Similar definition for analog process using hypothetical execution. The process when executed results in the qs being invariant. The qs do not change. Using the values found (q0s) to execute the statements then the values of q do not change. The hypothetical exection for this statement is the same as for the simple simultaneous. Ken - Jean-Jose, does this meet your need? Jean-Jose - concurrent statements block (neutral) process (digital) concurrent PROCEDURE call --- concurrent assertion | Syntactic sugar to the process concurrent signal assignment --- component instantiation (neutral) generate (neutral) Analog statements - relation (analog) supporting analog syntactic sugar (analog) Ken - your statement is that the relation is a fundamental concept like a process and is not a block. Ken - what is the underlying formalism that encompasses all of the statements that have been described? Jean-Jose - neutral Analog Kernel Digital Kernel Division is clear. Simultaneous statement will contain all of the analog write mechanism. Ken - the simulation cycle states who is responsible for updating signals and quantities. Jean-Jose - break is part of the analog statements. Ken - no. It generates a signal and provides a list of quantities to the analog kernel. Raphael - why is break a signal since it cannot read it? Ken - there are lots of signals which cannot be read. Ken - What are the essential forms and the derived forms? The fundamental thing is the simple simultaneous statement. Jean-Michel - we need to provide counter examples if they exist. Ken - the issue of which is syntactic sugar is not important it is what are the basics that the guts of the LRM are based on. Ken - Summarizing. Relation is equivalent ot process and hence all other statements have equivalents in the analog process. Raphael/Alain - Digital process can read analog but only assign digital and vice versus. Ken - Parallelism is a useful concept but that is a usability concept that is very subjective. Example of a logical mapping of the simultaneous conditional to the simple simultaneous statement: function ib(x:boolean) return real is begin if x then return 1.0; else return 0.0; end if; end function; if cond1 use expr1 == expr2; elseif cond2 use expr3 == expr4; else expr5 == expr4; end use; expr1*ib(cond1) + expr3*ib(not cond1 and cond2) + expr5*ib(not cond1 and not cond2) == expr2*ib(cond1) + expr4*ib(not cond1 and cond2) + expr6*ib(not cond1 and not cond2); Siep - these are not identical since all of the expressions are executed in the second case and not the first case. Dan F. - This is especially important if the if-use formulation is required to model within regions where a model is numerically valid. Ken - assumptions are that the expressions have values. Ernst - we are not defining an execution but a specification. The implementation may choose to execute this code. Ken - there may be circumstances where the expressions do not return an indeterminate value or an exception. Jean-Michel - I agree that they are equivalent. There is a problem of the execution symantics. Ernst - the problem that is being discussed is that there is no short circuit evaluation. This is an equivalence at the language level. The implementation will have to consider these cases when implemented. Ken - the language does not define expressions which are undeterminable. We are trying to show that there is a logical equivalence and not that the text can be transformed. It may also be possible to reformulate the expressions so that they perform the short circuit operation if there is a ternary operator introduced. Jean-Michel - is there an equivalence for the loop. Ken - there is no simultaneous loop statement defined so it is not possible to define an equivalence. The equivalent form for the analog process is a function which has the same arguments as the analog process and the body is from the process. procedural declarations begin sequential statements end maps to: f(list of q) == q parameter interface list of f function f (list of quantities from sequential statements) return type of vector q; begin return list of q; end; The point of these exercises is that the simple simultaneous statement is a basic form. BUT, this is not essential. If there are four statements which are fundamental then that is ok to. Whether the transformations exist or do not it is not important to the argument. There is no need to decide what the basic element is. Jean-Michel - if we define four then we need to define the relationship between them. Ken - this is not true since the definitions of each statement is clearly defined. Jean-Jose - in the context of the relation then local quantities local variables procedural reset equation end; The reset statement cannot be used in the procedural. Ken - what are the symantics of the reset statement? They appear that you believe that it is superior. Alain - how do we resolve the two different views for the white paper? Ken - one possibility is to fully develop both and then compare them. Ernst - suggest that we create two view and have them discussed in a future meeting. I do not think that it is possible to develop a common preception of what is important. We need to let people come to their conclusions. IV. Meeting administration Ernst - owners of white papers remain owners. For papers which were not discussed please read the papers and send feedback to the authors. Paper on interpretation domains which will handle the issues of frequency domain etc. Paper on how quantities can be used and effect subprograms. Alain - the analog subprogram? Ernst - this was a mechanism to specify a system of simultaneous equations independently of the rest. Alain - not really Ernst - regardless the working group decided to not address this now. Time is an issue. Working group meeting at VIUF meeting in San Diego on Monday April 3rd through Thursday. DASC meetings are Friday and Saturday. We will report to the working group the progress of the architecture team. A LAT meeting will be held Tuesday through Saturday. Location needs to be determined. White papers need to be done and distributed two weeks before the meeting. All papers need to be sent to Ernst by 17 March. He will then distribute them. The authors need to send outlines of new white papers to Ernst by 17 February (Friday) so that he can distribute them to the group for comments. All need to read and contact the authors for clarification. The authors need to have informal discussions so that coordination of ideas can occur. Review of this meeting. 1. evaluation of what worked and needs improvement. What worked agenda material available clear formalism in papers helped to focus discussion duration of meeting ok meeting arrangements were superb continuity in attendance is improving attempt made to include people in discussions paraphrasing statements helped to understand everybody wants to create good solution What can be done to improve the meeting polling for closing discussions white papers need to be distributed earlier preparation for meetings by attendees (reading material) expectations need to discussed at beginning and end of meeting objectives for the meeting need to be set at the beginning of meeting Ernst needs to lower his expectations break meeting when emotions run high need to expand upon decisions made in white papers and presentations use alternative facilitators during the meeting who is not involved in the presentation learn to listen - facilitator works on facilitating unrelated conversations need to be done outside of the meeting 2. update action items V. Time Ken - simulation cycle discussion assumes that there is only one time. time in analog is typically a double precision floating point. time in digital is defined to be at least 32 bit integer. There is a requirement for true simultanaity for the digital. Introducing floating point time to digital would violate this requirement and break VHDL. Double precision - gives 9 seconds of time with fixed precision. Time constants - semiconductor models have very short time constants with respect to digital. There is a difference in the requirements for dynamic range. Discussion around 128 bit time. ******************* New White Papers and Owners: Simultaneous statements Ken Bakalar Unified model of time Ken Bakalar Quantities and subprograms J.-J. Mayol Interpretation domain Raphael Dorado Statistical analyses Ernst Christen ******************* Action Item Summary: Update list of references in repository Alain 2/10 Email to Peter L. about checking examples J.-J. 2/10 Minutes for review Dan F.,David 2/13 Minutes review response all 2/17 Review remaining white papers, respond to authors all 2/17 Are breaks necessary? Dan F. 2/17 New white papers outline authors 2/17 Minutes distributed Ernst 2/24 Writeup on tolerances Dan D. 2/24 List of open issues Ernst 2/28 LAT approval process (minutes, papers) Ernst 2/28 SIMUL_R paper Alain 2/28 Investigate various LRM issues David 2/28 Extend Quantities paper with implicit declarations J.-J. 3/6 Access to terminal currents J.-J. 3/6 Consider dimensional analysis J.-J. 3/6 Initial conditions and break Ernst 3/17 Definition/list of implicit analog signals Ernst, Ken 3/17 Definitions for Q'ddt and Q'integ Ernst 3/17 Update white papers that were discussed authors 3/17 New white papers for distribution authors 3/17 From 1076-1-request@sicmail.epfl.ch Wed Mar 1 07:33:36 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Wed, 1 Mar 95 07:33:27 -0500 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Wed, 1 Mar 95 07:33:23 -0500 X400-Received: by mta sicmail.epfl.ch in /PRMD=switch/ADMD=arCom/C=ch/; Relayed; Wed, 1 Mar 1995 13:14:18 +0100 Date: Wed, 1 Mar 1995 13:14:18 +0100 X400-Originator: 1076-1-request@sicmail.epfl.ch X400-Recipients: non-disclosure:; X400-Mts-Identifier: [/PRMD=switch/ADMD=arCom/C=ch/;sicmail.ep.354:01.02.95.12.14.18] Priority: Non-Urgent Dl-Expansion-History: 1076-1@epfl.ch ; Wed, 1 Mar 1995 13:14:18 +0100; From: "Jean-michel.Berge" Message-Id: To: analog_reflector <1076-1@epfl.ch> Subject: Elections X-Mailer: Mail*Link SMTP/MS 3.0.0 I would like to proceed with the election to two different positions in our group: Validation Vice-Chair Position: Ed Cheng, who was the previous vice-chair, has changed his field of activity. It is time now to replace him. Working closely with Oliver Fischer-Binder, the new vice-chair will have to help to group together all the energy required to validate our extensions. Language Design co-chair: Together with Alain Vachoux and Ernst Christen, I was co-chair of this task. I am resigning from this position. My reason should be made clear: I will still be working in the language design group and nothing will change from that point of view. The point is that I would like people who are currently doing important and high quality work in language design to be more "officially" represented in our structure. I am thinking here of Ken Bakalar. I sincerely hope that Ken will be candidate for this position. Candidates for one of these two positions, could you please send a mesage to our secretary (Alain Vachoux) with an optional short statement (5 to 10 lines) by Tuesday 7th of March. We will run the ballot from the 8th to the 14th. By the way, the DASC will proceed soon (during the VIUF meeting ?) with the election of the VHDL-A group chair. This election is required by the new IEEE DASC by-laws. As current chair, I will be standing as candidate. If anyone else would like to be chair of this group, please send an email to the DASC Chair, Paul Menchini (mench@mench.com) for more information. Thanks, Jean-Michel From 1076-1-request@sicmail.epfl.ch Thu Mar 9 12:12:29 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Thu, 9 Mar 95 12:11:52 -0500 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Thu, 9 Mar 95 12:11:39 -0500 X400-Received: by mta sicmail.epfl.ch in /PRMD=switch/ADMD=arCom/C=ch/; Relayed; Thu, 9 Mar 1995 17:17:48 +0100 Date: Thu, 9 Mar 1995 17:17:48 +0100 X400-Originator: 1076-1-request@sicmail.epfl.ch X400-Recipients: non-disclosure:; X400-Mts-Identifier: [/PRMD=switch/ADMD=arCom/C=ch/;sicmail.ep.248:09.02.95.16.17.48] Priority: Non-Urgent Dl-Expansion-History: 1076-1@epfl.ch ; Thu, 9 Mar 1995 17:17:48 +0100; From: "Jean-michel.Berge" Message-Id: To: analog_reflector <1076-1@epfl.ch> Subject: VHDL-A elections X-Mailer: Mail*Link SMTP/MS 3.0.0 It is now time to proceed to the election to the validation vice-chair and the Language Design co-chair positions. Please send your vote for each position to our secretary Alain Vachoux (NOT to me*) at alain.vachoux@leg.de.epfl.ch. Alain will check if you are or not voting member. Thanks, Jean-Michel * I will be on hollidays before the end of the ballot, March 16th, and therefore you could lost your mail. o Language Design co-chair Position We have one candidate: -Ken Bakalar (COMPASS Design Automation) "If elected, I will serve as Co-chair of the Language Design Task. I think that the Language Architecture Team, of which I am a member, has made good progress in the past 6 months. I can see the light at the end of the tunnel, and I am willing to take a leadership role in completing the technical work and the ballot". o Validation Vice-Chair Position We have three candidates. I list below their names and statements in alphabetical order. Please vote for ONLY one candidate. - Dan Damon (Mentor Graphics) "In my position as technical marketing engineering, I am in constant contact with various end users and can accurately reflect their needs. I also have experience with several behavioral modeling languages; each of which has different strengths and weaknesses. As a design community, we should be able to put together a language that has few if any weak points. It's the Validation committee's task to provide test cases to insure this happens. Furthermore, it is important to have either the Chair or Vice chair easily accessable on the internet. Although Oliver has put in a lot of good work as the Validation Chair, he has not been easily accessable. Unlike Oliver, I access my email quite often - even when traveling on company business." - Peter Liebmann (Compass Design Automation) I have worked since 1980 on problems related to analog and IC circuit simulation and modeling. Projects of particular interest to the 1076.1 validation team include the implementation and development of devices models in SPICE and SPICE type simulators, the enhancement of a SPICE simulator so that a user can easily link their own model into the simulator, and the development of a SPICE netlist C type behavioral code (the DIABLO language at Intergraph). I have worked closely with both circuit designers and macro model developers and have a very firm understanding of the problems and needs relevant to simulation. - Andrew Patterson (Analogy) Current position : Technical Director, Analogy Europe and SE Asia Work includes coordinating detailed applications support for users of the Saber MAST modelling language, covering Mixed-Signal and Mixed-Systems applications. Currently heavily involved in the Analogy Inc. programme to develop a 1076.1 language simulator. Previously with Gateway Design Automation supporting the introduction of Verilog HDL in Europe, and with Cadence Europe supporting both VHDL and Verilog. Extensive experience giving training classes and modelling in Verilog and VHDL. Graduate of Cambridge Univeristy with a double-first class degree in Engineering and Electrical Sciences (1980). From 1076-1-request@sicmail.epfl.ch Thu Mar 9 13:31:34 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Thu, 9 Mar 95 13:31:27 -0500 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Thu, 9 Mar 95 13:31:22 -0500 X400-Received: by mta sicmail.epfl.ch in /PRMD=switch/ADMD=arCom/C=ch/; Relayed; Thu, 9 Mar 1995 18:22:03 +0100 Date: Thu, 9 Mar 1995 18:22:03 +0100 X400-Originator: 1076-1-request@sicmail.epfl.ch X400-Recipients: non-disclosure:; X400-Mts-Identifier: [/PRMD=switch/ADMD=arCom/C=ch/;sicmail.ep.085:09.02.95.17.22.03] Priority: Non-Urgent Dl-Expansion-History: 1076-1@epfl.ch ; Thu, 9 Mar 1995 18:22:03 +0100; From: "Jean-michel.Berge" Message-Id: To: analog_reflector <1076-1@epfl.ch> Subject: VHDL-A elections: ooops X-Mailer: Mail*Link SMTP/MS 3.0.0 Two points: o There is a deadline for this election. According to our Policies section 4.3. the voting period must be at least 3 weeks, which put it right to the end of March (31th). o For the validation chair election, our Policy document says, in section 4.2., that election is by the "approval" method where a voter may vote for any number of candidates and the one with the most votes wins. Please vote for any number of candidates... Jean-Michel From 1076-1-request@sicmail.epfl.ch Thu Mar 9 18:47:50 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Thu, 9 Mar 95 18:47:47 -0500 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Thu, 9 Mar 95 18:47:42 -0500 Received: from psi.com by sicmail.epfl.ch with SMTP (PP) id <17092-0@sicmail.epfl.ch>; Fri, 10 Mar 1995 00:10:03 +0100 Received: from analogy.com (analogy.analogy.com) by psi.com (4.1/2.1-PSI/PSINet) id AA24322; Thu, 9 Mar 95 18:09:42 EST Received: from miller.analogy.com ([149.117.72.253]) by analogy.com (4.1/Shared_Spool_1.3) id AA28945; Thu, 9 Mar 95 15:10:19 PST Received: from satyr.analogy.com by miller.analogy.com (4.1/SMI-3.2) id AA07184; Thu, 9 Mar 95 15:10:18 PST Received: by satyr.analogy.com (5.0/SMI-SVR4) id AA05858; Thu, 9 Mar 1995 15:10:18 -0800 Date: Thu, 9 Mar 1995 15:10:18 -0800 From: christen@analogy.com (Ernst Christen) Message-Id: <9503092310.AA05858@satyr.analogy.com> To: 1076-1@epfl.ch Subject: Next LAT meeting Content-Length: 1442 The next meeting of the 1076.1 Language Architecture Team will be held from Tuesday, April 4 through Friday, April 7, in San Diego, in parallel with VIUF. It will be interrupted Thursday morning for a workshop held at VIUF, exposing the material that we have developed so far to the VHDL community to get some feedback from that side. The 1076.1 Working Group meeting will then be held on Saturday, April 8. The issues that will be discussed at the meeting are based on the white papers that are currently being prepared by various people. Here is the list: - quantities, nodes and natures - quantities and subprograms - relations, simultaneous statements - simulation cycle, A/D and D/A interaction - time - DC analysis and initialization - predefined language environment - interpretation domain - number of equations vs. number of quantities - SPICE compatibility issues - statistical analyses If you plan to attend the LAT meeting, please send me a message by March 17. Note however, that continuity is important, e.g. attending only parts of the meeting may not be beneficial to you or the team. Also, meeting attendees are expected to have studied the white papers; they will be sent to them prior to the meeting. I have not yet been able to get final confirmation about the location for the meeting, I will forward this information to those planning to attend the meeting as soon as I have it. Thanks. Ernst Christen Chair LAT From 1076-1-request@sicmail.epfl.ch Fri Mar 10 12:14:58 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Fri, 10 Mar 95 12:14:52 -0500 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Fri, 10 Mar 95 12:14:48 -0500 Received: from mailgate.ericsson.se by sicmail.epfl.ch with SMTP (PP) id <05867-0@sicmail.epfl.ch>; Fri, 10 Mar 1995 16:28:07 +0100 Received: from dirac.ericsson.se (dirac.ericsson.se [147.214.90.10]) by mailgate.ericsson.se (8.6.10/1.0) with SMTP id QAA19546 for <1076-1@epfl.ch>; Fri, 10 Mar 1995 16:28:03 +0100 Received: from hel.ericsson.se by dirac.ericsson.se (4.1/LME-2.2+) id AA16448; Fri, 10 Mar 95 16:28:02 +0100 From: olle.Lundgren@ki.ericsson.se (Olle Lundgren) Received: by hel.ericsson.se (4.1/client-1.3) id AA11082; Fri, 10 Mar 95 16:28:02 +0100 Date: Fri, 10 Mar 95 16:28:02 +0100 Message-Id: <9503101528.AA11082@hel.ericsson.se> To: 1076-1@epfl.ch Subject: asic development methodology This letter is from a group user studying ASIC design methodology. We ask the receivers of this letter to include this mail address to their mailing lists regarding the subject of study. Thank You. From 1076-1-request@sicmail.epfl.ch Fri Mar 10 22:20:11 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Fri, 10 Mar 95 22:19:58 -0500 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Fri, 10 Mar 95 22:19:51 -0500 Received: from psi.com by sicmail.epfl.ch with SMTP (PP) id <06026-0@sicmail.epfl.ch>; Sat, 11 Mar 1995 03:23:47 +0100 Received: from analogy.com (analogy.analogy.com) by psi.com (4.1/2.1-PSI/PSINet) id AA12606; Fri, 10 Mar 95 21:23:03 EST Received: from miller.analogy.com ([149.117.72.253]) by analogy.com (4.1/Shared_Spool_1.3) id AA02013; Fri, 10 Mar 95 18:23:41 PST Received: from satyr.analogy.com by miller.analogy.com (4.1/SMI-3.2) id AA05406; Fri, 10 Mar 95 18:23:40 PST Received: by satyr.analogy.com (5.0/SMI-SVR4) id AA06525; Fri, 10 Mar 1995 18:23:40 -0800 Date: Fri, 10 Mar 1995 18:23:40 -0800 From: christen@analogy.com (Ernst Christen) Message-Id: <9503110223.AA06525@satyr.analogy.com> To: 1076-1@epfl.ch Subject: VHDL-A Language Architecture Content-Length: 32556 Since its conception as a tiger team in June 1994, the 1076.1 Language Architecture Team has made a lot of progress toward its goal to resolve open issues in language design. As you have seen in the minutes from the 5 LAT meetings held so far, various people have worked hard to find answers to open issues and to define a uniform language environment for VHDL-A. The result of these efforts has been documented in a series of white papers that were discussed at LAT meetings. First versions of two of these papers were also sent to the reflector in December, together with a promise to distribute a document describing the VHDL-A language architecture. Here is a first version of this document. It summarizes the work of the 1076.1 Language Architecture Team without going into semantic and syntactic details. It also documents the current status of the LAT work, indicating current areas of investigations and open issues. The document, which will be updated as the LAT work progresses, should provide you with the context necessary to understand the LAT white papers. Note that the document in this form has not been approved by the LAT. In the future you will see more and more white papers distributed, addressing specific language design issues and presenting them in a unified framework. In many cases these papers use a language that is close in style to the language used in the VHDL LRM. This is intentional: the white papers will serve as a basis for annotating the LRM, so the semantics are best expressed in a language that requires little change when incorporated in the LRM. You will also see exmples distributed, which will help to clarify the use of the proposed language constructs. We will report on our progress at the upcoming 1076.1 WG meeting in San Diego, but we also want to hear from those who will not be able to attend the meeting. I therefore encourage everyone to review the material distributed by the LAT and to respond with your comments. Ernst Christen Chair LAT ---------------------------------------------------------------------- VHDL-A Language Architecture ============================ 0.1 Feb.24, 1995 Original version 0.2 Mar.10, 1995 Included comments from Ken Bakalar and Alain Vachoux Streamlined sections on initialization and diagnostics 1. Fundaments for VHDL-A ------------------------ 1.1. What is VHDL-A VHDL-A is the language currently being defined by the IEEE 1076.1 Working Group, one of the working groups of the VHDL Analysis and Standardization Group (VASG) of the Design Automation Standards Committee (DASC) of the Computer Society of the IEEE. VHDL-A intends to extend the VHDL language to support the description and simulation of continuous time behavior (commonly called analog) and mixed continuous/discrete time behavior (commonly called analog/digital). 1.2. The VHDL Heritage Due to the fact that VHDL-A is not a new language, but an extension of an existing one, the development and definition of VHDL-A can build on the syntax and semantics of its parent VHDL (LRM). This is an advantage because VHDL already contains an extensive collection of features that are essential in a hardware description language, such as (incomplete list): - structural decomposition to support hierarchical description of designs (components, blocks) - functional decomposition (subprograms, processes, concurrent statements) - organizational decomposition (design units such as packages, entities, architectures) - encapsulation of behavior (entity/architectures/processes) - a well defined type system with strong typing However, the VHDL inheritance has also disadvantages because it constrains certain things to be done in a particular way. For instance, it is not possible to declare an array object of some type: the VHDL way is to define an array type first and then an object of this array type. It is clear that it is virtually impossible to change undesirable characteristics of VHDL because of backward compatibility. Additionally, special care has to be taken when defining language extensions, in order to maintain the integrity of the VHDL language. 1.3. Design Objectives The requirements for VHDL-A are described in the VHDL-A Design Objective Document (DOD). This document has been compiled from the raw requirements submitted to the 1076.1 Working Group by a group of interested people. The DOD, together with the Design Objective Rationale (DOR), also defines the scope of VHDL-A, and it drives the the language extensions because these extensions must ultimately support the design objectives. The DOD classifies the design objectives to be either "must have", "should have", or "desirable". Design objectives in the "must have" category are fundamental and cannot be compromised. "Should have" objectives describe useful functionality that provide significant benefits if met. Finally, "desirable" objectives enhance the usability and/or performance but are not essential. The goal of language design is then to meet all "must have" objectives, as many of the "should have" objectives as possible provided they are not too expensive, and as many of the "desirable" objectives as possible provided they come at little cost. 1.4. Guidelines for Language Design In order to get a common understanding of how the language extensions should be designed, the 1076.1 Working Group established, based on the recommendation of the 1076.1 Language Architecture Team (LAT), a set of guidelines derived from those used for the VHDL'93 restandardization. The following is a complete list of these guidelines, some of them including explanatory comments. - Upward Compatibility Exceptions: the new keywords - Preserve Strong Typing - Separate Declaration and Functionality Declaration before use Do not infer functionality from a declaration - Unification of Timing Semantics - Preserve Determinism - Preserve Generality Technology/methodology independence - Preserve Scope of VHDL (Gate to System) - Preserve intermixed abstraction levels Analog/digital behavioral/structural in same design unit. - Preserve Concurrency Simultaneous equations: stronger that concurrency - Preserve and Improve Consistency Define syntax and semantics as understandable as possible - Preserve and Improve Portability Quality of conformance to standard - No Application-specific Packages - Minimize Implementation Impact - Maximize Implementation Efficiency - Distinguish between the language, modeling and tool issues/aspects. - Ease of use - Constructive rather than propositional definitions 1.5. Differential and Algebraic Equations Continuous time behavior is described by differential and algebraic equations (DAEs) which are solved simultaneously by an analog solver. Due to the scope of VHDL-A to only address lumped systems, the differential equations are all ordinary differential equations with time as the independent variable. It is therefore essential that VHDL-A be capable of describing behavior in the form of simultaneous differential and algebraic equations. Conversely, the only way to describe continuous time behavior is by means of simultaneous DAEs. This implies that in order to cover any continuous time behavior, it is sufficient for VHDL-A to provide support for DAEs, and no other mechanism is needed. Note that this statement does not include or exclude any particular form in which DAEs could or should be expressed. 2. Basic Language Architecture ------------------------------ 2.1. Quantities As discussed in section 1.5., continuous time behavior is described by a set of simultaneous DAEs. The unknowns in this set of equations are called quantities. Quantities are analytical functions of time, i.e. they are piecewise continuous with a finite number of discontinuities. The analog solver solves for the values of all quantities over time, by applying suitable algorithms to the system of simultaneous DAEs. In other words, quantities get their values not by assignment, but as a result of solving simultaneous DAEs. There is currently no VHDL object that uses a similar mechanism to get its value. Therefore, the quantity is a new value bearing object introduced into the language. Quantities must be of a floating point type, which is the closest to getting a truly continuous value range. Specifically, it is not possible to describe DAEs with unknowns of a discrete type, because discrete functions of time are not analytical functions. There are two kinds of explicit quantities: free quantities and branch quantities. Here we only deal with free quantities; branch quantities will be described in section 2.2. Free quantities are declared in the declarative part of an entity or block or among the interface declarations of a block. Interface quantities are called quantity ports, by analogy with signal ports. Interface quantities have a mode (see section 2.6.), similar to the mode of an interface signal. Quantities declared in a block can be used locally in DAEs (see section 2.3.) to represent waveforms that are of local importance, for instance intermediate values used to build up a complicated expression, or the power dissipated in a resistor. Interface quantities can be used as interface objects of signal flow models, which include SPICE like current controlled sources. For instance, a signal flow model of a two-input adder has an entity with two interface quantities with mode IN and one interface quantity with mode OUT. A quantity association has the effect of constraining the two quantities to be equal. In addition to explicit quantities the language includes a collection of implicit quantities. The derivative of any quantity with respect to time is an implicit quantity, and so is the integral over time of a quantity, from time zero to the current time. The language also defines an implicit quantity whose value is that of a given quantity at a fixed interval in the past (ideal delay). Other implicit quantities are described in section 2.2. 2.2. Conservative systems Although it is possible to describe the behavior of any physical system using just free quantities, the large class of systems with conservation semantics (e.g. KCL/KVL) merits special treatment for such systems, i.e. the definition of language semantics specifically for conservative systems. The benefit of this is a considerable simplification for writing models describing such systems, thereby increasing productivity and reducing the risk of errors. The model used to describe conservative systems uses a nodal perspective. Specifically, a conservative system is considered to be represented as a (undirected) graph where the vertices in the graph are the nodes and the edges are the physical branches in the design, i.e. the branches where (in an electrical network) current is flowing. This model is close to the way designers think about their system. Note that there is no implication that an implementation use a nodal based formulation, i.e. the formulation method used to implement conservative system semantics can be different from the formulation that defines the semantics for conservative systems in VHDL-A. The value bearing objects in conservative systems are branch quantities. They have all the characteristics of free quantities, except that they are declared differently. Branch quantities come in two flavors: across quantities and through quantities. Across quantities represent effort like effects such as voltage, temperature, or angular velocity. Through quantities represent flow like effects such as current, heat flow, or torque. Typically the constitutive equations of conservative devices are expressed by relating across and through quantities of one or several branches. For example, a resistor has a single branch, and its constitutive equation (Ohm's law) relates the voltage across (the across quantity) and the current through the resistor (the through quantity). Branch quantities are defined between two terminals, the plus terminal and the minus terminal of the branch quantity. Plus and minus terminals define a direction for the branch, which is useful, for instance, to understand in which direction a positive current flows. The terminal is the second new object introduced into the language. It can be declared in a block declarative part or among the interface declarations of a block. In the later case it is a terminal port. Terminals differ from other VHDL objects because they do not themselves have values. However, there is a particular implicit quantity associated with each terminal, called the reference quantity of the terminal. In electrical systems that quantity is the voltage of the terminal with respect to ground. The value of an explicit branch across quantity is given by the difference of the reference quantities of its plus and minus terminals, which in electrical systems is an aspect of Kirchhoff's Voltage Law. Each terminal also has a contribution expression, which is another implicit quantity that is defined as the sum of all through quantities (with appropriate sign) that have the terminal as either the plus or minus terminal, plus the contribution expression of any terminal of a component or nested block that the given terminal is connected to. Terminals don't have types, but they have a nature, which is a composite of types. Specifically, a nature contains an across type and a through type. Natures can be defined for different disciplines, for instance electrical, thermal, rotational. There can be a whole collection of natures, all derived from the same simple nature, that allow to describe composite terminals. Natures derived from the same simple nature share the same reference terminal, which makes them compatible. However, natures for different disciplines are incompatible because they have different reference terminals. The plus and minus terminals of a branch quantity must have compatible natures, and the across and through quantities get the across and through types, respectively, from the nature. A set of terminals is called a node. The set is created through terminal associations, and it includes at most one reference terminal. All terminals in a node must have compatible natures, and the values of their reference quantities are constrained to be equal. In electrical systems this is a consequence of Kirchhoff's Voltage Law. The conservation expression of the node is the sum of the contribution expressions of all terminal in the node, and the semantics of the node constrain the value of the conservation expression to be zero. In electrical systems this corresponds to Kirchhoff's Current Law. 2.3. Simultaneous statements As described in sections 1.5. and 2.1., continuous time behavior is described by a set of simultaneous differential and algebraic equations, with the quantities as the unknowns. The DAEs are composed from explicit constraints described in the text of a model, and implicit constraints described by the semantics of the language. Examples of implicit constraints are the constraint on the value of the conservation expression of each node, or the constraint defining the value of across quantities described in section 2.2. Explicit constraints are mathematically of the form expression1 = expression2 where each expression is composed of unknowns (i.e. quantities) and knowns (e.g. constants, literals, signal values) and can include function calls. The quantities in the expressions can be explicit or implicit quantities. The semantics of the constraint define that the values of both expressions be made equal, i.e. constraints are exact specifications. However, the solution of the simultaneous DAEs may yield values for the quantities that only approximate the exact specification. Examples for explicit constraints are the constitutive equations for a capacitor: charge = c*v i = dcharge/dt where charge, i and v are explicit quantities and dcharge/dt is an implicit quantity. Each mathematical constraint is represented in the language by one or more statements, using either an equational or a procedural style. Such statements can be effective conditionally, based on the outcome of a test. This allows to implement continuous time behavior differently in different regions of operation of a device. The language supports two kinds of simultaneous conditional statements, the simultaneous if statement and the simultaneous case statement. Their semantics are analogous to the semantics of the corresponding sequential statements, taking into consideration the simultaneous context. The detailed semantics of simultaneous statements are currently being investigated. 2.4. Simulation cycle The VHDL simulation cycle defines the order in which different parts of the canonical simulator defined in the LRM are executed. It is the definition of a time domain simulation and contains, as one of its major parts, the algorithm defining how time advances during simulation. The VHDL-A simulation cycle assumes the existence of a unified model for time. The LRM defines time as a physical type, i.e. an integer multiple of 1 fs. While providing a constant absolute resolution, this is not sufficient for VHDL-A because in continuous time simulation, the relative accuracy of time is more important than the absolute accuracy. The details of the unified model for time are currently being investigated. The VHDL-A simulation cycle consists of the VHDL simulation cycle modified to include the execution of the analog solver. If the system model has no continuous time part the VHDL-A simulation cycle reduces to the VHDL simulation cycle. If there is no discrete time part it reduces to executing just the analog solver unless discontinuities are involved. Within the simulation cycle the analog solver advances time from Tc to Tn, the next time of a digital event or process resumption. It does this by solving (integrating) the set of simultaneous DAEs that define the continuous time part of the system model at a sequence of time points between Tc and Tn. At any particular time a set of values for the quantities is considered a solution if it closely approximates the exact mathematical solution of the DAEs. This can be tested by a hypothetical evaluation of all explicit and implicit constraints in the system of DAEs: the values of the expressions on the left and right hand side of all constraints must be close. The analog solver may terminate prematurely (i.e. before Tn) if one of the quantities crosses a threshold between Tc and Tn. In this case the analog solver returns at the earliest time of any threshold crossing between Tc and Tn. Threshold crossing is specified using the concept of implicit analog signals. There are three implicit analog signals: to detect a general crossing, a crossing in rising direction and a crossing in falling direction. Implicit analog signals have characteristics similar to S'STABLE, except that their driver is controlled by the analog solver. Implicit analog signals are integral to the issue of A/D conversion, or more specifically, a conversion of a continuous time quantity to a discrete time signal. In addition to implicit analog signals the values of quantities may be read in processes and concurrent statements, and the simulation cycle guarantees that they always have the correct value. Conversely, the values of signals used in the formulation of DAEs are guaranteed to always be correct. The break statement is a new sequential statement. Its purpose is to tell the analog solver when any discontinuities have occurred in the model, which require a re-evaluation of the DAEs at that time. Discontinuities can occur, for instance, if a quantity is equated to a signal and the signal changes. The break statement also allows to specify new initial conditions for selected quantities, in order to set up a new state of the system after the discontinuity. 2.5. Initialization, DC Simulation Before a time domain simulation as described in section 2.4. can start, all value bearing objects must be initialized. For some of them this happens during elaboration (see LRM and section 2.6.), but others get their initial value during a phase called the initialization phase. This phase is well defined in the LRM for VHDL, but it must be extended to address the needs of continuous time and mixed continuous/discrete time systems. It has to be noted that at this time the details of the modifications to the initialization phase have not been worked out completely. Unlike digital systems, where the simulation is only meaningful in the time domain, continuous time systems exhibit interesting characteristics in other domains as well. Frequency domain simulation is described in section 2.7., here we focus on the DC aspects of a system, in addition to the initialization aspects. The initial point is a set of values for all signals, drivers of signals, variables, and quantities, and the resumption points of all processes. Any set of values and resumption points that can be used at the beginning of a time domain simulation is an initial point. Specifically, the state of the system after initialization has the characteristics of an initial point. One initial point of particular importance is the DC operating point. It is an equilibrium point of the system, corresponding to the asymptotic solution over time of the system model, with stimulus held constant. For continuous/discrete time systems with combinational discrete time part, the DC operating point can be defined to have the following characteristics: - all dynamic effects have settled, i.e. time derivatives are zero - the values of all quantities satisfy the DAEs - all processes have been executed until the drivers of all signals that are not stimulus signals are empty. This definition will have to be modified to include synchronous systems. Note that some systems, for instance oscillators, do not have a DC operating point. It is apparent that this definition requires the identification of stimulus, a concept that does not currently exist in VHDL. There are several issues related to this concept. First, the concept must be defined. Then, stimulus must be identified; most likely this will be done by the person writing a stimulus model. Finally, a mechanism to control stimulus must be designed. VHDL-A initialization and DC simulation are designed such that DC simulation can be run optionally. If DC simulation is missing, the initialization steps correspond to the current VHDL initialization, suitably extended to also deal with the new VHDL-A objects. If it is there, DC simulation replaces the initial point defined by the initialization with a DC operating point. The detailed semantics of initialization and DC simulation, including support for initial conditions, are still being investigated. 2.6. VHDL-A Diagnostics >From the perspective of user friendliness it is important to be able to diagnose as many problems in a design as early as possible. Furthermore, these diagostics should be as specific as possible, pointing to the exact location of the problem (if possible). The investigations in this area are incomplete, but some results are available. A necessary condition for the existence of a solution of the system of simultaneous DAEs is that its Jacobian be non-singular. A weaker statement is that a system of simultaneous DAEs has no solution if its Jacobian is structurally singular (i.e. singular regardless of the values of the elements of the Jacobian). Both these statements imply that there must be an equal number of DAEs and unknowns. The number of explicit constraints that is required in a block to guarantee an equal number of constraints and quantities in the fully elaborated design depends on the number of through quantities and free quantities declared in the block and its interface. By giving interface quantities a mode (IN or OUT) a set of unambiguous rules can be derived. Depending on whether the number of through quantities, free quantities and constraints in a block is static or dynamic, these rules can be applied at the time a design entity is analyzed, or at elaboration time, or dynamically at simulation time. The question whether the DAEs describing a system have a solution can be answered only at simulation time. However, if the number of constraints in each block is static, a test for structural singularity can be applied at elaboration time. Current investigations try to address the question what consequences these findings have on the language design. 2.7. Support for Frequency Domain A frequency domain simulation consists of computing the spectrum at selected locations in a design as a function of frequency, given an input spectrum. Several algorithms are available for frequency domain simulation. The most important ones are: - time domain simulation, followed by FFT - harmonic balance - small signal AC simulation (like SPICE) While the first algorithm requires no special language support, it is also the most restrictive in the sense that it is difficult to define the input spectrum for the design in the time domain such that meaningful simulation results can be obtained. Harmonic balance and specifically small signal AC simulation are more flexible in this respect, but they require a small signal model and are therefore restricted to the continuous time part of the design. With the exception of stimulus, the small signal model of a design can be derived from the large signal (time domain) model of the system by linearizing the large signal model about the DC operating point. This process is similar to a Jacobian evaluation, but special treatment is given to time derivatives, integrals, and ideal delays. Furthermore, the small signal model is complex, yielding complex values for the spectrum, which means that in the frequency domain quantities have complex values! Support for frequency domain simulation is currently being investigated. In order to define frequency domain stimulus two concepts are being considered. First, the concept of the interpretation domain allows to define different behavior for time domain, DC domain and frequency domain. Second, in order to support frequency dependent behavior an impure function returning the current simulation frequency must be defined. 3. Open issues -------------- Although the language architecture described in section 2. appears quite complete, there are a number of issues that have been identified but not yet resolved or integrated into the architecture. The following is a list of these issues, with brief descriptions. 3.1. Math Package Support The IEEE 1076.2 effort is currently defining a package of mathematical functions for real and complex types. There are some open questions about how these functions are defined, for instance is the sin function implementing the mathematical sine function, or is it defined by the package body provided by the 1076.2 effort, which only yields 6 digits of accuracy. The information obtained from reading the 1076.2 documents and from talking to the people involved is contradictory. This question is important in determining the Jacobian or the small signal model of the system: what is the derivative of the 1076.2 sin function? 3.2. Dimensional Analysis The DOD contains a desirable objective to support dimensional analysis. Given the complexity of the issue, the 1076.1 Working Group decided to postpone such support, and to only design a mechanism that allows to annotate objects with units for display purposes. With new information becoming available, this decision has been contested, and an investigation has started to see whether it is possible to satisfy this design objective with little cost. If so, this would have implications on the type system in VHDL. 3.3. Statistical Analysis Support Support for statistical analysis (i.e. Monte Carlo) is mentioned in the DOD in the context of interaction between tool and language. An investigation has just started into this issue, based on work that has been reported previously (STAT). It appears that such support can be provided with little cost, so it may be worthwile to include it in VHDL-A. 3.4. Algorithm Band-Aids Unlike digital simulation, which is mostly based on integer arithmetic, continuous time simulation involves the solution of simultaneous DAEs over time. The algorithms used for this purpose usually include the iterative solution of nonlinear equations. Due to the finite dynamic range of floating point numbers on computers, these algorithms may cause overflows to occur during iterations, although the final solution is well within the supported dynamic range, unless special precautions are taken to limit the amount of change of an unknown from one iteration to the next. It is unclear at this time how such limiting can be supported by VHDL-A, because the language does not specify any particular algorithm to be used. Further investigations are required that will also have to answer the question whether other algorithm band-aids should be supported. 3.5. Analog Simulation Points for Display Purposes The VHDL-A simulation cycle does not specify when and how the analog solver has to solve the simultaneous DAEs. All it says is that at any time a hypothetical evaluation of the constraints has to demonstrate that they are closely satisfied. State of the art codes for solving DAEs step through time using a variable step size, depending on some error criterion, and they make assumptions about the smoothness of the solution between any two time points. If the error criterion is always satisfied at the selected time points, these codes will take larger and larger time steps, which causes the smoothness assumption to be violated. It may therefore be advisable to provide some mechanism in the language to control time steps, in order for a tool to be able to display the simulation results correctly. 3.6. Complete Support for SPICE Concepts One of the VHDL-A design objectives is to provide a migration path for the large number of SPICE based designs and libraries currently in use. The issues resulting from this objective have been analyzed and documented, but their consequences have not yet been incorporated in the language design. Specific issues that may need language support are: - references to a .model in ahierarchical SPICE design - node collapsing - special values undefined, infinite 3.7. Tolerances As described in section 2.4. the analog solver is required to closely approximate the exact solution of the simultaneous DAEs. This is a rather vague statement, and it requires a redefinition of the guideline of portability that includes the inexact nature of continuous time solutions. The question is whether this redefinition requires the concept of tolerances to be included in the language. The concern is that this concept may be tightly linked to a particular class of algorithm, which would violate one of the design objectives. 4. Issues not addressed ----------------------- The 1076.1 effort does not address the following issues. VHDL-A will not include any application specific packages such as packages defining the basic infrastructure (e.g. types, natures) for disciplines like electrical or thermal, nor will it include a package defining a set of basic electrical parts (e.g. the SPICE set of parts). The 1076.1 effort focuses on the language extensions; such packages will have to be provided through other means. VHDL-A will not include support for the concept of the analog subprograms, a concept that has been discussed in one of the Language Extension Specifications (LES) but that has been postponed through a decision of the 1076.1 Working Group. The analog subprogram would have provided some macro like capability and support for solving a disconnected set of simultaneous equations, which could sometimes be useful to determine the values of constants. 5. References ------------- DOD 1076.1 Design Objective Document DOR 1076.1 Design Objective Rationale LRM IEEE Standard VHDL Language Reference Manual 1076-1993 STAT E.Christen, M.Vlach: "Description of Statistical Behavior in an Analog Hardware Description Language: A Case Study", Proc. ICSHDL'94. White papers discussed at Language Architecture Team meetings From 1076-1-request@sicmail.epfl.ch Mon Mar 13 13:06:50 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Mon, 13 Mar 95 13:06:45 -0500 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Mon, 13 Mar 95 13:06:36 -0500 X400-Received: by mta sicmail.epfl.ch in /PRMD=switch/ADMD=arCom/C=ch/; Relayed; Mon, 13 Mar 1995 18:16:03 +0100 Date: Mon, 13 Mar 1995 18:16:03 +0100 X400-Originator: 1076-1-request@sicmail.epfl.ch X400-Recipients: non-disclosure:; X400-Mts-Identifier: [/PRMD=switch/ADMD=arCom/C=ch/;sicmail.ep.786:13.02.95.17.16.03] Priority: Non-Urgent Dl-Expansion-History: 1076-1@epfl.ch ; Mon, 13 Mar 1995 18:16:03 +0100; From: "Jean-michel.Berge" Message-Id: To: analog_reflector <1076-1@epfl.ch> Subject: Validation Chair new email X-Mailer: Mail*Link SMTP/MS 3.0.0 For those of you who are willing to participate to the validation process, Oliver (validation chair) has sent to me his new email address (and affiliation). Please do not use the old one anymore. The new one is: Joerg-Oliver Fischer-Binder Anacad EES Helmholtzstr. 20 89081 Ulm Phone: ++49-731-95454-0 Fax: ++49-731-95454-50 email: olli@anacad.de Thanks, Jean-Michel From 1076-1-request@sicmail.epfl.ch Mon Mar 13 17:40:36 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Mon, 13 Mar 95 17:40:02 -0500 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Mon, 13 Mar 95 17:39:54 -0500 Received: from gatekeeper.ray.com by sicmail.epfl.ch with SMTP (PP) id <26906-0@sicmail.epfl.ch>; Mon, 13 Mar 1995 23:13:53 +0100 Received: from localhost (mailer@localhost) by gatekeeper.ray.com (8.6.4/8.6.5) id RAA12963 for <1076-1@epfl.ch>; Mon, 13 Mar 1995 17:09:25 -0500 Received: from sud2.ed.ray.com by gatekeeper.ray.com; Mon Mar 13 17:05:46 1995 Received: from SUD2.ED.RAY.COM by SUD2.ED.RAY.COM (PMDF V4.2-10 #4335) id <01HO3CCR34LW8X34A0@SUD2.ED.RAY.COM>; Mon, 13 Mar 1995 17:11:12 EST Date: Mon, 13 Mar 1995 17:11:12 -0500 (EST) From: "Joe Gwinn, 508-440-3330" Subject: Comments on VHDL-A Language Architecture To: 1076-1@epfl.ch Message-Id: <01HO3CCR34LY8X34A0@SUD2.ED.RAY.COM> X-Envelope-To: 1076-1@epfl.ch X-Vms-To: IN%"1076-1@epfl.ch" X-Vms-Cc: GWINN Mime-Version: 1.0 Content-Transfer-Encoding: 7BIT Let me say right off that the architecture as described so far seems to me to be very solid. However, I do have a few comments to offer. 1. Section 1.4 - typo: Under "Preserve Concurrency", it should be "Simultaneous equations: stronger than concurrency", where "that" becomes "than". 2. Section 2.1, last sentence of first paragraph could read: "In other words, quantities get their values not by assignment, but as a result of solving simultaneous DAEs, or from initial conditions." 3. Section 2.1, 4th paragraph: Does "quantity association" support only equality? "Association" seems much broader. A sentence or two of explanation may be in order. (This is a comment about names and language, not a technical comment.) 4. Section 2.1, general: A few hyphens would prevent garden-path sentences: "value-bearing objects", "SPICE-like current-controlled". In the first sentence of the last paragraph, add a comma after "quantities". 5. Section 2.2, 3rd paragraph: At first blush, many readers would think that torque is an effort, and angular velocity is a flow. A sentence or two of explanation would put the readers at ease that this counter-intuitive mapping is correct. 6. Section 2.4, first paragraph, second sentence: To what does "It" refer? By English grammer, it refers to LRM, but one assumes that the simulation cycle is the intended reference. Suggest replacing "it" with a repeat of the intended noun. 7. Section 2.4, second paragraph, second sentence: It's the VHDL LRM, not the VHDL-A LRM, that's mentioned as defining a physical type, isn't it? Suggest adding the clarifying word "VHDL" before "LRM". 8. Section 2.4, general: Is it possible for user code to dynamically compute when the discontinuity will happen, based on knowledge of the physical system being modeled, or is general threshold crossing the only trigger available? 9. Section 2.5, paragraphs 4-6: What about systems having multiple stable DC operating points? Regardless of the operational validity of these stable points, the simulator will find them. Many circuits have multiple valid DC operating points. There must be a way for the user to bias the simulator's choice of DC operating point, or, by Murphy's Law, the simulator will always choose the wrong DC operating point. It's not enough to say that the circuit must itself always have a unique DC operating point -- life isn't always that simple. 10. Section 2.6, first paragraph: On the matter of diagnostic tools, one such tool monitors the Euclidean norm of the state vector for unexpected discontinuities, defined as places where the analog kernel detects a greater then threshold derivative of this norm. Upon threshold exceedance, the kernel would stop and complain, with the system caught in the act, with any luck. Necessary supporting tools are those allowing the user to figure out exactly who was where and what they were doing at the moment the unexpected jump was detected. (I stole this idea from one of Jeff Deutsch's papers.) 11. Section 2.6, paragraphs 2-4: What if the Jacobian is near-singular? Detection of true mathematical singularity is numerically impossible on a finite-precision computer, and near-singularity causes just as much numerical trouble as true singularity. Simple variable and equation counting may not detect equations that are not independent. So, I would suspect is that one language consequence is the need to specify some kind of singularity tolerance band for runtime detection of practical singualrity. 12. Section 3.3: Support for Monte-Carlo analyses sounds like a very good idea, and is one of the standard enhancements that commercial simulators soon grow. 13. Section 3.4: One can specify that quantities that attempt to change faster than some specified rate will either be clamped to a specified value, or that the simulation will stop, complain, and wait for the user to debug the model. (See Item 10, above.) One need not say much about how this will be done; the idea of rate-of-change is well-defined and independent of the details of the analog kernel design. Great precision is not generally required, either. 14. Section 3.5: Limits on both maximum and minimum timestep are required, for a number of reasons. First, there needs to be a way for the user to rein in an overeager analog solver, and also to prevent undesired heroic and often numerically unstable efforts to follow sharp features in the quantities. Second, many plotting packages require uniform point spacing, or at least cannot handle too many points without undue slowness. To these ends, the stoptime of the current analog kernel run is set to the soonest of any of the following: time of predicted discontinuity, end of maximum step size, time of next plot datapoint to be generated, and so on. If the resulting stop-point would result in too small a step, then the minimum step size is instead used. (This is the approach used by ACSL for decades.) 15. Section 5: I suspect that all this talk of conservation, through and across variables, et al, may mystify many working engineers. A few tutorial references may be in order. Joe Gwinn From 1076-1-request@sicmail.epfl.ch Tue Mar 14 05:44:03 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Tue, 14 Mar 95 05:44:01 -0500 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Tue, 14 Mar 95 05:43:57 -0500 X400-Received: by mta sicmail.epfl.ch in /PRMD=switch/ADMD=arCom/C=ch/; Relayed; Tue, 14 Mar 1995 11:15:13 +0100 Date: Tue, 14 Mar 1995 11:15:13 +0100 X400-Originator: 1076-1-request@sicmail.epfl.ch X400-Recipients: non-disclosure:; X400-Mts-Identifier: [/PRMD=switch/ADMD=arCom/C=ch/;sicmail.ep.140:14.02.95.10.15.13] Priority: Non-Urgent Dl-Expansion-History: 1076-1@epfl.ch ; Tue, 14 Mar 1995 11:15:13 +0100; From: "Jean-michel.Berge" Message-Id: To: analog_reflector <1076-1@epfl.ch> Subject: Next VHDL-A working group meeting X-Mailer: Mail*Link SMTP/MS 3.0.0 Next VHDL-A working group will be help in San-Diego on Saturday (April 8th). The exact location of the DASC meetings has to be confirmed. Beginning of the sessions is supposed to be 8h00 in the VIUF program (8h-17h). I propose a more realistic beginning at 8h30. This full-day meeting will consists into two parts: - Presentation of the LAT results - Plans to complete our standardization The current proposal for an agenda is: 8h30 General information (Jean-Michel) new chairs, status, miscellaneous news 8h45 Results of the LAT (5 hours) o LAT status (Ernst): ISAC meeting, VHDL-A architecture document o Quantities&Terminal (Ken) o Simultaneous Statements (Alain) o Simulation Cycle (Ken) o Initialization (Ernst) o Spice compatibility (Peter) o Environment (Jean-Michel) 15h15 future plan o What to do now with the LESs? (Alain will bring this issue up - 2 transparencies) o How and when start the documentation task? Working plan. (Dave, to be confirmed) o How be more efficient for validation? Working plan. (Oliver) o Open issues If you think something else has to be addressed, please contact Ernst Christen, I will be on holidays next weeks. Jean-Michel From 1076-1-request@sicmail.epfl.ch Wed Mar 15 01:55:20 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Wed, 15 Mar 95 01:55:17 -0500 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Wed, 15 Mar 95 01:55:13 -0500 X400-Received: by mta sicmail.epfl.ch in /PRMD=switch/ADMD=arCom/C=ch/; Relayed; Wed, 15 Mar 1995 07:40:42 +0100 Date: Wed, 15 Mar 1995 07:40:42 +0100 X400-Originator: 1076-1-request@sicmail.epfl.ch X400-Recipients: non-disclosure:; X400-Mts-Identifier: [/PRMD=switch/ADMD=arCom/C=ch/;sicmail.ep.786:15.02.95.06.40.42] Priority: Non-Urgent Dl-Expansion-History: 1076-1@epfl.ch ; Wed, 15 Mar 1995 07:40:42 +0100; From: "Jean-michel.Berge" Message-Id: To: analog_reflector <1076-1@epfl.ch> Subject: TR: CORRECTED DASC Meeting Schedule 7-8 April 1995 X-Mailer: Mail*Link SMTP/MS 3.0.0 IEEE COMPUTER SOCIETY DESIGN AUTOMATION STANDARDS COMMITTEE MEETINGS IN CONJUNCTION WITH THE SPRING 1995 VHDL INTERNATIONAL USERS' FORUM THE PRINCESS RESORT SAN DIEGO, CALIFORNIA 7-8 APRIL 1995 (CORRECTED SCHEDULE) FRIDAY, 7 APRIL 8:00 AM-12:00 N DASC PLENARY SESSION Contact: Paul Menchini, Chair 919-990-9506 Menchini & Associates 919-990-9507 [Fax] 2 Davis Drive mench@mench.com P.O. Box 13036 Research Triangle Park, NC 27709-3036 This meeting will take place in Sunset Ballroom 3 and 4. 1:00 PM-5:00 PM WAVEFORM AND VECTOR EXCHANGE SPEC. WORKING GROUP--1029.1 Contact: Bob Hillman, Chair 315-330-2813 Rome Laboratory/ERG 315-330-2885 [Fax] 525 Brooks Road hillmanr@ernet.af.mil Griffiss AFB, NY 13441-4505 This meeting will take place in Executive Suite 712. 1:00 PM-5:00 PM VHDL TIMING METHODOLOGY WORKING GROUP--P1076.4 Contact: Victor Berman, Chair 508-446-6276 Cadence Design Systems, Inc. 508-262-6777 [Fax] 270 Billerica Road berman@cadence.com Chelmsford, MA 01824 This meeting will take place in Sunset Ballroom 4. 1:00 PM-5:00 PM VHDL PARALLEL SIMULATION STUDY GROUP Contact: John Willis, Chair 507-253-8403 IBM Corporation willis@vnet.ibm.com 3605 Hwy. 52 North Rochester, MN 55901-7829 This meeting will take place in Executive Suite 708. 1:00 PM-5:00 PM SYSTEM DESIGN & DESCRIPTION LANGUAGE STUDY GROUP Contact: Dave Barton, Chair 703-827-2606 Intermetrics, Inc. 703-827-2609 [Fax] 7918 Jones Branch Drive, Suite 710 dlb@hudson.wash.inmet.com McLean, VA 22102 This meeting will take place in Executive Suite 710. 1:00 PM-3:00 PM VERILOG ANALYSIS AND STANDARDIZATION GROUP--P1364 Contact: Maq Mannan National Semiconductor, Inc. mannan@galaxy.nsc.com This meeting will take place in Sunset Ballroom 3. 3:00 PM-5:00 PM VHDL-EDIF INTEROPERABILITY WORKING GROUP--P1165 Contact: J. Bhasker, Chair 215-770-3983 AT&T Bell Labs 215-770-2773 [Fax] 1247 South Cedar Crest Boulevard, 2R242 jb7@mhcnet.att.com Allentown, PA 18103 This meeting will take place in Sunset Ballroom 3. 5:30 PM-7:30 PM DASC STEERING COMMITTEE MEETING Contact: Paul Menchini, Chair This meeting will take place in Sunset Ballroom 3. SATURDAY, 8 APRIL 8:00 AM-5:00 PM VHDL ANALOG EXTENSIONS WORKING GROUP--P1076.1 Contact: Jean-Michel Berge, Chair +33 76 76 43 35 CNS-CCI +33 76 90 34 43 Chemin Du Vieux Chene--BP 98 berge@cns.cnet.fr MEYLAN CEDEX F-38243 FRANCE This meeting will take place in Executive Suite 714. 8:00 AM-5:00 PM VHDL SYNTHESIS PACKAGE WORKING GROUP--P1076.3 Contact: Alex Zamfirescu 415-691-6426 Intergraph Electronics 415-691-6061 [Fax] 381 East Evelyn Avenue azamfire@edaca.ingr.com Mountain View, CA 94041 a.zamfirescu@ieee.org This meeting will take place in Executive Suite 716. 8:00 AM-12:00 N VHDL ANALYSIS AND STANDARDIZATION GROUP--P1076 Contact: Clive Charlwood, Chair 415-694-4307 Synopsys, Inc. 415-965-8637 [Fax] 700 East Middlefield Road crc@synopsys.com Mountain View, CA 94043-4033 This meeting will take place in Executive Suite 706. 8:00 AM-12:00 N OBJECT-ORIENTED EXTENSIONS TO VHDL STUDY GROUP Contact: Doug Dunlop, Chair 703-827-2606 Intermetrics, Inc. 703-827-2609 [Fax] 7918 Jones Branch Drive, Suite 710 dunlop@wash.inmet.com McLean, VA 22102 This meeting will take place in Executive Suite 708. 1:00 PM-5:00 PM VHDL UTILITY LIBRARY WORKING GROUP--P1076.5 Contact: Gabe Moretti, Chair 415-691-6434 Intergraph Electronics 415-691-9016 [Fax] 381 East Evelyn Avenue gabe@dazixca.ingr.com Mountain View, CA 94041 This meeting will take place in Executive Suite 706. 1:00 PM-5:00 PM VHDL SHARED VARIABLES WORKING GROUP--P1076A Contact: Steve Bailey 510-659-0901, x227 Vantage Analysis Systems, Inc. 510-659-0129 [Fax] 47211 Lakeview Boulevard sab@vas.com Fremont, CA 94538 This meeting will take place in Executive Suite 708. ----- End Included Message ----- ------------------ RFC822 Header Follows ------------------ Received: by msmail with SMTP;14 Mar 1995 22:55:19 -0100 X400-Received: by /PRMD=cnet/ADMD=atlas/C=FR/; Relayed; 14 Mar 95 22:54:13+0100 X400-Received: by /PRMD=inria/ADMD=atlas/C=FR/; Relayed; 14 Mar 95 22:54:03+0100 X400-Received: by /PRMD=Internet/ADMD= /C=us/; Relayed; 14 Mar 95 16:44:24-0500 Date: 14 Mar 95 16:44:24-0500 From: Paul J. Menchini Message-ID: <199503142144.QAA14363@mench.mench.com> To: dasc@mench.mench.com Subject: CORRECTED DASC Meeting Schedule 7-8 April 1995 cc: mench@mench.mench.com, jacobs@mench.mench.com From 1076-1-request@sicmail.epfl.ch Wed Mar 15 14:41:44 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Wed, 15 Mar 95 14:41:40 -0500 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Wed, 15 Mar 95 14:41:30 -0500 Received: from psi.com by sicmail.epfl.ch with SMTP (PP) id <14335-0@sicmail.epfl.ch>; Wed, 15 Mar 1995 20:12:16 +0100 Received: from analogy.com (analogy.analogy.com) by psi.com (4.1/2.1-PSI/PSINet) id AA05137; Wed, 15 Mar 95 14:11:48 EST Received: from miller.analogy.com ([149.117.72.253]) by analogy.com (4.1/Shared_Spool_1.3) id AA25592; Wed, 15 Mar 95 11:12:33 PST Received: from satyr.analogy.com by miller.analogy.com (4.1/SMI-3.2) id AA12892; Wed, 15 Mar 95 11:12:33 PST Received: by satyr.analogy.com (5.0/SMI-SVR4) id AA03315; Wed, 15 Mar 1995 11:12:32 -0800 Date: Wed, 15 Mar 1995 11:12:32 -0800 From: christen@analogy.com (Ernst Christen) Message-Id: <9503151912.AA03315@satyr.analogy.com> To: 1076-1@epfl.ch Subject: Re: Comments on VHDL-A Language Architecture Content-Length: 3773 Forwarded message: >From GWINN@SUD2.ED.RAY.COM Tue Mar 14 11:53:52 1995 >From: "Joe Gwinn, 508-440-3330" Subject: Re: Comments on VHDL-A Language Architecture To: christen@analogy.com X-Envelope-To: christen@analogy.com X-Vms-To: IN%"christen@analogy.com" X-Vms-Cc: GWINN Ernst, Thanks for your comments on my comments. I will answer your questions: >>8. Section 2.4, general: Is it possible for user code to dynamically compute >>when the discontinuity will happen, based on knowledge of the physical system >>being modeled, or is general threshold crossing the only trigger available? >> >I don't quite understand this question because the threshold crossing and >discontinuities are not related (although a threshold crossing may cause >a discontinuity and vice versa). This issue here is the prediction of discontinuity, such as that caused by the bouncing ball hitting the floorplate. The exact time of impact is required for accurate simulation, and cannot be predicted in advance. One approach -- not a good one -- is to threshold on ball altitude above the floorplate. The problem is that the solver will tend to take large steps in this very smooth part of the ball's trajectory, and the actual moment of impact will be somewhere in the middle of a long step. The usual approach is to dynamically compute estimated time of arrival as the ball approaches the floorplate. Even a simple first-order (linear) approximation computation results in a great improvement in simulation accuracy. >>9. Section 2.5, paragraphs 4-6: What about systems having multiple stable DC >>operating points? Regardless of the operational validity of these stable >>points, the simulator will find them. Many circuits have multiple valid DC >>operating points. There must be a way for the user to bias the simulator's >>choice of DC operating point, or, by Murphy's Law, the simulator will always >>choose the wrong DC operating point. It's not enough to say that the circuit >>must itself always have a unique DC operating point -- life isn't always that >>simple. >> >We had some discussions about this issue, but it has not been resolved. It >is not even clear whether the language should address this issue or whether >it should be left to the tool. This must be in the language, or the models won't be portable. A command to bias the DC operating point search is very simple. >>13. Section 3.4: One can specify that quantities that attempt to change >>faster than some specified rate will either be clamped to a specified value, >>or that the simulation will stop, complain, and wait for the user to debug >>the model. (See Item 10, above.) One need not say much about how this will >>be done; the idea of rate-of-change is well-defined and independent of the >>details of the analog kernel design. Great precision is not generally >>required, either. >> >We don't consider this a language issue. On the contrary, this would disallow >discontinuities. Not quite. Many simulations are improved by a clamp, for numerical reasons. Discontinuities per se aren't the whole story. And, there is the issue of how sharp a feature has to be to be a discontinuity to the analog solver. Saying that discontinuities aren't allowed doesn't quite answer the mail. >>15. Section 5: I suspect that all this talk of conservation, through and >>across variables, et al, may mystify many working engineers. A few tutorial >>references may be in order. >> >Any suggestions? I'll think about it. The relevant references I know of are really on Bond Graphs, whatever the title of the book. Some of these books are quite good, however. Does anyone else have some ideas? More is better, up to a point. Joe Gwinn From 1076-1-request@sicmail.epfl.ch Wed Mar 15 15:12:05 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Wed, 15 Mar 95 15:11:56 -0500 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Wed, 15 Mar 95 15:11:01 -0500 Received: from psi.com by sicmail.epfl.ch with SMTP (PP) id <14319-0@sicmail.epfl.ch>; Wed, 15 Mar 1995 20:10:44 +0100 Received: from analogy.com (analogy.analogy.com) by psi.com (4.1/2.1-PSI/PSINet) id AA04938; Wed, 15 Mar 95 14:10:10 EST Received: from miller.analogy.com ([149.117.72.253]) by analogy.com (4.1/Shared_Spool_1.3) id AA25573; Wed, 15 Mar 95 11:10:55 PST Received: from satyr.analogy.com by miller.analogy.com (4.1/SMI-3.2) id AA12885; Wed, 15 Mar 95 11:10:56 PST Received: by satyr.analogy.com (5.0/SMI-SVR4) id AA03311; Wed, 15 Mar 1995 11:10:54 -0800 Date: Wed, 15 Mar 1995 11:10:54 -0800 From: christen@analogy.com (Ernst Christen) Message-Id: <9503151910.AA03311@satyr.analogy.com> To: 1076-1@epfl.ch Subject: Re: Comments on VHDL-A Language Architecture Content-Length: 6728 Joe, Thank you very much for your comments on this document. This kind of feedback is important for us because however much we think we know there is always something else... Before I respond to some of your issues let me point out that this document is intended to give an overview of the 1076.1 work. As such it does not claim to be complete and address every tiny detail. These will be explored in the white papers and documented thoroughly there. The idea behind this document is to provide the framework to help with understanding the details. This is necessary because the white papers are not tutorial in nature. Rather, they follow LRM style and terminology and require some understanding of an overall architecture. Here is now my response to some of your issues. >3. Section 2.1, 4th paragraph: Does "quantity association" support only >equality? "Association" seems much broader. A sentence or two of explanation >may be in order. (This is a comment about names and language, not a technical >comment.) > In VHDL the term "association" is quite clear and narrow. We are making the assumption that people are familiar with this terminology. In fact we have to, because the white papers use language that is very close to LRM language, and this terminology must be used. >8. Section 2.4, general: Is it possible for user code to dynamically compute >when the discontinuity will happen, based on knowledge of the physical system >being modeled, or is general threshold crossing the only trigger available? > I don't quite understand this question because the threshold crossing and discontinuities are not related (although a threshold crossing may cause a discontinuity and vice versa). >9. Section 2.5, paragraphs 4-6: What about systems having multiple stable DC >operating points? Regardless of the operational validity of these stable >points, the simulator will find them. Many circuits have multiple valid DC >operating points. There must be a way for the user to bias the simulator's >choice of DC operating point, or, by Murphy's Law, the simulator will always >choose the wrong DC operating point. It's not enough to say that the circuit >must itself always have a unique DC operating point -- life isn't always that >simple. > We had some discussions about this issue, but it has not been resolved. It is not even clear whether the language should address this issue or whether it should be left to the tool. >10. Section 2.6, first paragraph: On the matter of diagnostic tools, one >such tool monitors the Euclidean norm of the state vector for unexpected >discontinuities, defined as places where the analog kernel detects a greater >then threshold derivative of this norm. Upon threshold exceedance, the kernel >would stop and complain, with the system caught in the act, with any luck. >Necessary supporting tools are those allowing the user to figure out exactly >who was where and what they were doing at the moment the unexpected jump was >detected. (I stole this idea from one of Jeff Deutsch's papers.) > There are many diagnostics that seem useful to a designer. Our efforts will stop at the point where they go beyond the language. Specifically, the purpose of the diagnostics described in the paper is to provide a basis for identifying problems that in the VHDL LRM are classified as erroneous or errors. >11. Section 2.6, paragraphs 2-4: What if the Jacobian is near-singular? >Detection of true mathematical singularity is numerically impossible on a >finite-precision computer, and near-singularity causes just as much numerical >trouble as true singularity. Simple variable and equation counting may not >detect equations that are not independent. So, I would suspect is that one >language consequence is the need to specify some kind of singularity tolerance >band for runtime detection of practical singualrity. > We believe that this is an implementation issue because we are not prescribing any specific formulation method, much less an algorithm. Even if we did, the question of reaching near singularity depends on the pivoting strategy provided the Jacobian is even used to solve the system of DAEs. Anyway, tolerances are on the list of open issues. >13. Section 3.4: One can specify that quantities that attempt to change >faster than some specified rate will either be clamped to a specified value, >or that the simulation will stop, complain, and wait for the user to debug >the model. (See Item 10, above.) One need not say much about how this will >be done; the idea of rate-of-change is well-defined and independent of the >details of the analog kernel design. Great precision is not generally >required, either. > We don't consider this a language issue. On the contrary, this would disallow discontinuities. >14. Section 3.5: Limits on both maximum and minimum timestep are required, >for a number of reasons. First, there needs to be a way for the user to rein >in an overeager analog solver, and also to prevent undesired heroic and often >numerically unstable efforts to follow sharp features in the quantities. >Second, many plotting packages require uniform point spacing, or at least >cannot handle too many points without undue slowness. To these ends, the >stoptime of the current analog kernel run is set to the soonest of any of the >following: time of predicted discontinuity, end of maximum step size, time >of next plot datapoint to be generated, and so on. If the resulting stop-point >would result in too small a step, then the minimum step size is instead used. >(This is the approach used by ACSL for decades.) > There are two aspects for time step control. The first one has to do with correctness, i.e. that whenever a result is needed in the language it is available and correct (withing some error). We have covered this in the simulation cycle, and the definition goes so far as to support discontinuities without much overhead in the general case. The second aspect has to do with displaying results. It could be argued that nothing is required here, because a tool could make all its information kept internally to support the first aspect also available to a display tool. We have not reached a conclusion on this yet. Commenting on the cases that you list, they all appear to have to do with properties of algorithms and tools. This is clearly outside of our scope, but I agree that an implementation will have to deal with these issues somehow. >15. Section 5: I suspect that all this talk of conservation, through and >across variables, et al, may mystify many working engineers. A few tutorial >references may be in order. > Any suggestions? Thanks. Ernst Christen From 1076-1-request@sicmail.epfl.ch Wed Mar 15 15:14:14 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Wed, 15 Mar 95 15:14:05 -0500 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Wed, 15 Mar 95 15:13:59 -0500 Received: from sol.compass-da.com by sicmail.epfl.ch with SMTP (PP) id <14776-0@sicmail.epfl.ch>; Wed, 15 Mar 1995 20:52:17 +0100 Received: from adhara.columbia.compass-da.com (adhara.columbia.compass-da.com [162.17.30.14]) by clsi.columbia.compass-da.com (8.6.9/8.6.9) with ESMTP id OAA09303 for <1076-1@epfl.ch>; Wed, 15 Mar 1995 14:51:25 -0500 From: Peter Liebmann Reply-To: peterl@compass-da.com Received: (peterl@localhost) by adhara.columbia.compass-da.com (8.6.9/8.6.9) id OAA03409 for 1076-1@epfl.ch; Wed, 15 Mar 1995 14:51:27 -0500 Date: Wed, 15 Mar 1995 14:51:27 -0500 Message-Id: <199503151951.OAA03409@adhara.columbia.compass-da.com> To: 1076-1@epfl.ch Subject: RE: Ernst's responce to Joe's comments to ... A good reference in responce to Joe Gwinn's comment "15. Section 5: I suspect that all this talk of conservation, through and across variables, et al, may mystify many working engineers. A few tutorial references may be in order." is: D'Azzo and Houpis, "Feedback Control for Analysis and Synthesis" John Wiley & Sons, 1967. From 1076-1-request@sicmail.epfl.ch Wed Mar 15 15:15:28 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Wed, 15 Mar 95 15:14:26 -0500 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Wed, 15 Mar 95 15:14:14 -0500 Received: from psi.com by sicmail.epfl.ch with SMTP (PP) id <14934-0@sicmail.epfl.ch>; Wed, 15 Mar 1995 21:09:15 +0100 Received: from analogy.com (analogy.analogy.com) by psi.com (4.1/2.1-PSI/PSINet) id AA08516; Wed, 15 Mar 95 15:08:57 EST Received: from miller.analogy.com ([149.117.72.253]) by analogy.com (4.1/Shared_Spool_1.3) id AA25932; Wed, 15 Mar 95 12:09:17 PST Received: from satyr.analogy.com by miller.analogy.com (4.1/SMI-3.2) id AA12994; Wed, 15 Mar 95 12:09:17 PST Received: by satyr.analogy.com (5.0/SMI-SVR4) id AA03328; Wed, 15 Mar 1995 12:09:16 -0800 Date: Wed, 15 Mar 1995 12:09:16 -0800 From: christen@analogy.com (Ernst Christen) Message-Id: <9503152009.AA03328@satyr.analogy.com> To: GWINN@sud2.ed.ray.com Subject: Re: Comments on VHDL-A Language Architecture Cc: 1076-1@epfl.ch Content-Length: 5145 Joe, some more comments. >>>8. Section 2.4, general: Is it possible for user code to dynamically compute >>>when the discontinuity will happen, based on knowledge of the physical system >>>being modeled, or is general threshold crossing the only trigger available? >>> >>I don't quite understand this question because the threshold crossing and >>discontinuities are not related (although a threshold crossing may cause >>a discontinuity and vice versa). > >This issue here is the prediction of discontinuity, such as that caused by >the bouncing ball hitting the floorplate. The exact time of impact is >required for accurate simulation, and cannot be predicted in advance. One >approach -- not a good one -- is to threshold on ball altitude above the >floorplate. The problem is that the solver will tend to take large steps >in this very smooth part of the ball's trajectory, and the actual moment of >impact will be somewhere in the middle of a long step. The usual approach is >to dynamically compute estimated time of arrival as the ball approaches the >floorplate. Even a simple first-order (linear) approximation computation >results in a great improvement in simulation accuracy. > The implementation of the threshold is not specified in the language although its qualities are. This is because its implementation has to be tightly coupled with the integration algorithm, and we are not specifying algorithms. The simulation cycle limits the time steps such that any time a sample is taken from the analog waveform, this sample is close to the exact value (e.g. closer than a user specified tolerance). Threshold evaluation can yield an accurate root of a waveform that is close to the exact one, which translates to a small timing error w.r.t. the exact solution. I believe what you describe as the usual approach amounts to an extrapolation of the trajectory of the ball. Still you end up with a threshold crossing for the extrapolated waveform unless I miss something. >>>9. Section 2.5, paragraphs 4-6: What about systems having multiple stable DC >>>operating points? Regardless of the operational validity of these stable >>>points, the simulator will find them. Many circuits have multiple valid DC >>>operating points. There must be a way for the user to bias the simulator's >>>choice of DC operating point, or, by Murphy's Law, the simulator will always >>>choose the wrong DC operating point. It's not enough to say that the circuit >>>must itself always have a unique DC operating point -- life isn't always that >>>simple. >>> >>We had some discussions about this issue, but it has not been resolved. It >>is not even clear whether the language should address this issue or whether >>it should be left to the tool. > >This must be in the language, or the models won't be portable. A command to >bias the DC operating point search is very simple. > As I said, we have not reached an agreement on this, so your input will be considered. > >>>13. Section 3.4: One can specify that quantities that attempt to change >>>faster than some specified rate will either be clamped to a specified value, >>>or that the simulation will stop, complain, and wait for the user to debug >>>the model. (See Item 10, above.) One need not say much about how this will >>>be done; the idea of rate-of-change is well-defined and independent of the >>>details of the analog kernel design. Great precision is not generally >>>required, either. >>> >>We don't consider this a language issue. On the contrary, this would disallow >>discontinuities. > >Not quite. Many simulations are improved by a clamp, for numerical reasons. >Discontinuities per se aren't the whole story. And, there is the issue of >how sharp a feature has to be to be a discontinuity to the analog solver. >Saying that discontinuities aren't allowed doesn't quite answer the mail. > A discontinuity is just that, i.e. it is "infinitely sharp", and it is supported by the proposed simulation cycle. What I meant is that if there were a clamping mechanism, discontinuities might have to be clamped, too, or the mechanism would apply only sometimes. But I understand where your concern is coming from. Integration algorithms tend to have problems stepping from a region with little change into another with steep changes. That is, unless the time steps are properly selected. Therefore, I still believe your concern is algorithm specific and outside the language. Here is my justification: Let's consider two implementations A and B. A does not need a clamp, B does. Four issues come up: - The results obtained by B are likely to be incorrect, because they may not satisfy the closeness requirement. - How will I write a portable model if all I have is implementation A? - Assuming I include a clamp to support B, either I get wrong results in A, or I have to ignore the clamp. A language feature that may be ignored does not seem desirable. - Assume a new implementation C becomes available, requiring a more severe clamp than B. This would make all the previously existing models obsolete. Thanks. Ernst Christen From 1076-1-request@sicmail.epfl.ch Thu Mar 16 11:46:36 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Thu, 16 Mar 95 11:46:22 -0500 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Thu, 16 Mar 95 11:45:58 -0500 Received: from psi.com by sicmail.epfl.ch with SMTP (PP) id <26865-0@sicmail.epfl.ch>; Thu, 16 Mar 1995 17:45:09 +0100 Received: from analogy.com (analogy.analogy.com) by psi.com (4.1/2.1-PSI/PSINet) id AA12596; Thu, 16 Mar 95 11:44:26 EST Received: from miller.analogy.com ([149.117.72.253]) by analogy.com (4.1/Shared_Spool_1.3) id AA00753; Thu, 16 Mar 95 08:44:47 PST Received: from satyr.analogy.com by miller.analogy.com (4.1/SMI-3.2) id AA14714; Thu, 16 Mar 95 08:44:47 PST Received: by satyr.analogy.com (5.0/SMI-SVR4) id AA03680; Thu, 16 Mar 1995 08:44:46 -0800 Date: Thu, 16 Mar 1995 08:44:46 -0800 From: christen@analogy.com (Ernst Christen) Message-Id: <9503161644.AA03680@satyr.analogy.com> To: moser@fli.sh.bosch.de Subject: Re: VHDL-A Language Architecture Cc: 1076-1@epfl.ch Content-Length: 3034 >Concerning 1.5 Differential and Algebraic Equations > hear: over-determined DAE's: > >>From my knowledge of electrical simulators they usually do not allow >over-determined DAE's. Many mechanical problems require over- >determined DAE's for stable numerical solutions: > >1. The following description defines a pendulum as an index-3 > problem. The pendulum swings in the x-y plane, with lsq is > the square of the lenght of the pendulum (g = -9.81, gravity): > > ddt(x) == vx; > ddt(y) == vy; > ddt(vx) == -x * fak; > ddt(vy) == -y * fak - g; > lsq == x * x + y * y; (1) > > The description is correct, due to numerical problems the description > above can not be simulated correctly. The best solution is to > add another (or two) constraint, which reduces the index: > > 0.0 == x * vx + y * vy; (2) > > Is this possible with VHDL-A ? > > Today, the designer has to eleminate constraint (1) and the > simulator will simulate the pendulum. But that will cause a > slow change of the lenght over time, due to finite resolution. > >2. Modelling multi-body-systems: Bond graph method tells us to use > "velocity" as across variable and "force" as through variable. > > Lets assume 1-dim. geometry and two connected bodies, some force > is applied on the coupled bodies. > The description of each body would look like: > > ddt(v) == f/m; > ddt(x) == v; > > At the start of the simulation both bodies start at some point, > let say x0 = 0, x1 = 0. After some time (due to finite resolution), > x0 will be different from x1. > > One could choose the position as across variable, but that will > cause other trouble. Best of all would be to use both (velocity and > position) as across variables. Again, we have a over-determined > DAE. > > Is that possible with VHDL-A ? > >For my understanding, the described issues are no language issues, >they should not be restricted because of some tools. Some >simulators today might not solve such description, but that >should not guide the language design. > >Solver for over-determined DAE's are available. > The general issue raised in your message is whether the language will allow the specification of overdetermined systems. This has not been completely resolved, but current thinking would disallow it. The problem with over- determined systems is that in general it is difficult for a user to get the constraints consistent: with your pendulum example it's relatively easy, but consider a system with several thousand unknowns. I agree with your conclusion that these issues are not language issues, but have to do with an implementation. Some implementations will solve high index problems poorly, others which use index reduction algorithms and suitable DAE solvers will perform better. Such algorithms augment the original system with additional constraints while guaranteeing consistency regardless of the size of the system. Ernst Christen From 1076-1-request@sicmail.epfl.ch Thu Mar 16 11:46:53 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Thu, 16 Mar 95 11:46:46 -0500 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Thu, 16 Mar 95 11:46:34 -0500 Received: from gatekeeper.bosch.de by sicmail.epfl.ch with SMTP (PP) id <24696-0@sicmail.epfl.ch>; Thu, 16 Mar 1995 16:28:36 +0100 Received: by gatekeeper.bosch.de (5.65/rg-150294); id AA10585; Thu, 16 Mar 95 16:28:26 +0100 Received: by si4640.si.bosch.de (5.65/fma-120691); id AA05015; Thu, 16 Mar 1995 16:32:30 GMT Received: by sh.bosch.de (5.65/DEC-Ultrix/4.3) id AA23935; Thu, 16 Mar 1995 16:30:14 GMT Received: from triton by fli.sh.bosch.de (5.0/SMI-SVR4-DNI-8.0) id AA07156; Thu, 16 Mar 1995 16:28:19 --100 Received: by triton (5.0/SMI-SVR4) id AA00334; Thu, 16 Mar 1995 16:28:03 --100 Date: Thu, 16 Mar 1995 16:28:03 --100 From: moser@fli.sh.bosch.de (Eduard Moser) Message-Id: <9503161528.AA00334@triton> To: christen@analogy.com Cc: 1076-1@epfl.ch Subject: Re: VHDL-A Language Architecture Reply-To: moser Content-Length: 2138 Concerning 1.5 Differential and Algebraic Equations hear: over-determined DAE's: >From my knowledge of electrical simulators they usually do not allow over-determined DAE's. Many mechanical problems require over- determined DAE's for stable numerical solutions: 1. The following description defines a pendulum as an index-3 problem. The pendulum swings in the x-y plane, with lsq is the square of the lenght of the pendulum (g = -9.81, gravity): ddt(x) == vx; ddt(y) == vy; ddt(vx) == -x * fak; ddt(vy) == -y * fak - g; lsq == x * x + y * y; (1) The description is correct, due to numerical problems the description above can not be simulated correctly. The best solution is to add another (or two) constraint, which reduces the index: 0.0 == x * vx + y * vy; (2) Is this possible with VHDL-A ? Today, the designer has to eleminate constraint (1) and the simulator will simulate the pendulum. But that will cause a slow change of the lenght over time, due to finite resolution. 2. Modelling multi-body-systems: Bond graph method tells us to use "velocity" as across variable and "force" as through variable. Lets assume 1-dim. geometry and two connected bodies, some force is applied on the coupled bodies. The description of each body would look like: ddt(v) == f/m; ddt(x) == v; At the start of the simulation both bodies start at some point, let say x0 = 0, x1 = 0. After some time (due to finite resolution), x0 will be different from x1. One could choose the position as across variable, but that will cause other trouble. Best of all would be to use both (velocity and position) as across variables. Again, we have a over-determined DAE. Is that possible with VHDL-A ? For my understanding, the described issues are no language issues, they should not be restricted because of some tools. Some simulators today might not solve such description, but that should not guide the language design. Solver for over-determined DAE's are available. Eduard Moser From 1076-1-request@sicmail.epfl.ch Fri Mar 17 06:43:58 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Fri, 17 Mar 95 06:43:47 -0500 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Fri, 17 Mar 95 06:43:42 -0500 Received: from gatekeeper.bosch.de by sicmail.epfl.ch with SMTP (PP) id <03891-0@sicmail.epfl.ch>; Fri, 17 Mar 1995 12:14:36 +0100 Received: by gatekeeper.bosch.de (5.65/rg-150294); id AA16727; Fri, 17 Mar 95 12:14:23 +0100 Received: by si4640.si.bosch.de (5.65/fma-120691); id AA16116; Fri, 17 Mar 1995 12:18:28 GMT Received: by sh.bosch.de (5.65/DEC-Ultrix/4.3) id AA00306; Fri, 17 Mar 1995 12:15:55 GMT Received: from triton by fli.sh.bosch.de (5.0/SMI-SVR4-DNI-8.0) id AA02104; Fri, 17 Mar 1995 12:14:20 --100 Received: by triton (5.0/SMI-SVR4) id AA00335; Fri, 17 Mar 1995 12:14:03 --100 Date: Fri, 17 Mar 1995 12:14:03 --100 From: moser@fli.sh.bosch.de (Eduard Moser) Message-Id: <9503171114.AA00335@triton> To: christen@analogy.com Subject: Re: VHDL-A Language Architecture Cc: 1076-1@epfl.ch Reply-To: moser Content-Length: 1556 >>Concerning 1.5 Differential and Algebraic Equations >> hear: over-determined DAE's: > >The general issue raised in your message is whether the language will allow >the specification of overdetermined systems. This has not been completely >resolved, but current thinking would disallow it. The problem with over- >determined systems is that in general it is difficult for a user to get >the constraints consistent: with your pendulum example it's relatively easy, >but consider a system with several thousand unknowns. > >I agree with your conclusion that these issues are not language issues, but >have to do with an implementation. Some implementations will solve high >index problems poorly, others which use index reduction algorithms and >suitable DAE solvers will perform better. Such algorithms augment the >original system with additional constraints while guaranteeing consistency >regardless of the size of the system. If its not a language issue, that you can allow the overdetermined DAE's on the language level, leave it to the simulator to accept it or not. In any case (with or without restriction) the simulator will perform on some descriptions and will not on other descriptions (syntacticly correct and with a unique mathematical solution). A good simulator might check the description and will predict its possible performance (inconsistency check, index problems). The restriction will prohibit or will reduce its capablilities for some application areas. (e.g. multi-body-systems, as explained). Eduard Moser. From 1076-1-request@sicmail.epfl.ch Mon Mar 20 13:29:45 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Mon, 20 Mar 95 13:29:08 -0500 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Mon, 20 Mar 95 13:28:08 -0500 Received: from imag.imag.fr by sicmail.epfl.ch with SMTP (PP) id <11838-0@sicmail.epfl.ch>; Mon, 20 Mar 1995 18:24:43 +0100 Received: from droopy.imag.fr (droopy.imag.fr [129.88.40.11]) by imag.imag.fr (8.6.11/8.6.9) with ESMTP id RAA26684; Mon, 20 Mar 1995 17:44:18 +0100 Received: from aguamarina.imag.fr (aguamarina.imag.fr [129.88.40.15]) by droopy.imag.fr (8.6.10/8.6.9) with ESMTP id RAA08468; Mon, 20 Mar 1995 17:44:05 +0100 From: Adam Pawlak Received: (pawlak@localhost) by aguamarina.imag.fr (8.6.10/8.6.9) id RAA13766; Mon, 20 Mar 1995 17:41:18 +0100 Message-Id: <199503201641.RAA13766@aguamarina.imag.fr> Subject: Program of the IFIP Workshop on Libraries, and of VFE To: comp.lsi.cad@cs.indiana.edu, gt-cao@mimosa.unice.fr, difftima@verdon.imag.fr, 1076-1@epfl.ch, vhdlsynth@vhdl.org Date: Mon, 20 Mar 1995 17:41:18 +0100 (MET) X-Mailer: ELM [version 2.4 PL13] Content-Type: text Content-Length: 32313 VHDL-FORUM for CAD in EUROPE Spring '95 Working Conference and ESPRIT Project 8370-ESIP WORKSHOP ON LIBRARIES, COMPONENT MODELING, AND QUALITY ASSURANCE IRESTE - IHT, NANTES, France April 24 - 27, 1995 Program & Invitation ==================== Main Sponsor: SIG-VHDL, IFIP WG 10.5/ECSI Co-Sponsors: ATLANTECH, IRESTE, TEMIC/MATRA MHS VHDL-Forum for CAD in Europe Spring '95 Working Conference IRESTE, NANTES, France The VHDL-Forum for CAD in Europe (VFE) is the European users' group active in VHDL-related topics & standardization efforts and was founded at the International Federation for Information Processing (IFIP) conference VLSI '89 in Munich by IFIP WG 10.5. Since the founding of the IFIP/ECSI Special Interest Group on VHDL (SIG-VHDL) in spring '94 the VFE is supported by this group. The VFE members belong to an international range of companies, institutes, and universities. The VFE is open to all interested participants. The motivation and history of the group was the diverse European experiences in the field of hardware description languages and related topics. During the first two years, the main emphases of the VFE were the promotion and education of VHDL in Europe and the establishment of relationships to international VHDL users' groups (USA, Japan) and standardization groups. The VFE and the EuroVHDL conferences, as complementary, more research-oriented events, have built the European VHDL network with international connections. Both events, the EuroVHDL and the VFE, are going to be coordinated and organized under the umbrella of SIG-VHDL. The Spring '95 working conference focuses on user-oriented topics, because more and more European users are in the migration phase towards VHDL and have collected experiences in practise. Exchange of design experience is required, although the link between research and industrial application of VHDL is an important issue as well. Additionally, accompanying standards and standardized practises around VHDL have emerged during the previous year(s). VHDL-based tools, graphical entry, simulator backplane, cycle-based simulator, animator, standard modeling techniques for sign-off descriptions, synthesis with link to layout, hardware/software co-design promise better solutions for the users. What are the real benefits? These are topics to be addressed at the Spring '95 working conference. VFE-Board: D. Borrione, France, A. Hohl, Germany, J. Mermet, France, G. Musgrave, U.K., W. Nebel, Germany, S. Olcoz, Spain, F. Rammig, Germany, E. Villar, Spain. Program Committee: P. Bakowski, IRESTE, France, A. Balboni, Italtel, Italy, D. Borrione, Artemis/IMAG, France, J.P. Caisso, Matra-MHS, France, N. Dutt, University of California, USA, H. Hegny, Bosch Telecom ANT, Germany, A. Hohl, Siemens, Germany, S. Krolikoski, Compass Design Automation, USA, S. Maerz-Roessel, Siemens, Germany, J. Mermet, ECSI Office, Artemis, France, P. Miller, University of Portsmouth, U.K., G. Musgrave, Brunel University, U.K., W. Nebel, University of Oldenburg, Germany, S. Olcoz, TGI, Spain, A. Pawlak, Artemis/IMAG, France, P. Prinetto, Politecnico di Torino, Italy, F. Rammig, University of Paderborn, Germany, D. Sciuto, Politecnico di Milano, Italy, E. Villar, University of Cantabria, Spain. Local Organization: F. Bouchard, J. P. Caisso, J. F. Diouris, G. Ramstein Program Chairperson: Przemyslaw Bakowski, IRESTE/SEI, University of Nantes, France Conference Secretary: IRESTE, La Chantrerie, CP 3003, 44087 Nantes cedex 03, France Phone: 33-40.68.30.79 Fax: 33-40.68.30.66 e-mail: pbakowsk@ireste.fr Monday, April 24, 1995 8.00-14.00 Registration 9.00 Tutorial Sessions Introduction to ASIC Cells Modeling With VITAL O. Levia, Synopsys, USA VITAL is an IEEE Standard draft (par 1076.4). The goal of VITAL is to standardize a modeling approach for ASIC Cells in VHDL. VITAL aims to satisfy modeling needs with accuracy and detail that will allow Sign-Off simulation. VHDL is a complex and powerful language with many facilities allowing accurate and detailed modeling. VITAL is designed such that it will be possible to take advantage of the power of VHDL while at the same time allow optimization and efficient simulation. VITAL does so by limiting the VHDL feature-set used for ASIC Cell modeling and by requiring a specific style and modeling template to be used. In this tutorial I will introduce VITAL from a requirements and use point of view. This tutorial is targeted at ASIC designers, ASIC vendors, EDA tool builders and others interested in learning about VITAL from a practical point of view. Oz Levia is a section manager in Synopsys. His direct responsibility is ASIC and Sign-Off simulation. Oz has been active in the definition and development of VITAL for the last two years. Currently Oz is the Chair of the Technical Sub-Committee (TAG) tasked with the technical resolution of VITAL issues, and the design of VITAL specifications. Oz has extensive experience in working with numerous ASIC vendors on joint projects targeted at making VHDL, and VHDL tools, Sign-Off strong. Oz has also been very active in defining and propagating the requirements and needs of a VHDL Sign-Off environment. Oz is the Editor (with Jean-Michel Berge, and Jacques Rouillard) of a series of publications titled: "Current Issues In Electronic Modeling" published by Kluwer Academic. Introduction to VHDL 1993 and Shared Variables Stanley J. Krolikoski, COMPASS Design Automation, USA This tutorial is a practical introduction to IEEE VHDL 1076-1993. We shall focus on (a) the important features that have changed from the 1987 version of the language, (b) what problems the changes were addressing and (c) how to use the new features. Numerous "before and after" examples will be presented to clarify the new parts of the language and how they relate to the old way of doing things. One of the most visible parts of the development of VHDL 1993 was the shared variable saga. As a result of the controversy that the "final" version of shared variables caused, a new IEEE working group (1076.a) was formed to develop a supplement to VHDL. The output of this group, placed in the context of the original problem they were attempting to solve, will be examined in some depth during this tutorial. This tutorial assumes a familiarity with VHDL-87. It is suitable for both management and technical people who are conversant with the earlier versions of VHDL and are interested in learning more about the new language. Stanley Krolikoski received four advanced degrees in Philosophy culminating with a Ph.D. from Illinois at Urbana-Champaign. He taught Philosophy at several universities, and later received a second Ph.D. from Illinois in Computer Science. Dr. Krolikoski has worked for Honeywell, IBM and, most recently, for CLSI, where he was Vice President. He is currently Chief Technologist at COMPASS Design Automation. Dr. Krolikoski was chair of the IEEE VASG from 1988 until 1994, and is currently head of the Technical Boards of both VHDL International and the IEC TC 93 WG 2 on HDLs. He has published over twenty refereed papers in areas ranging from Philosophy to Mathematics to Electronic Design. VHDL and Associated Methods Jean-Michel Berge, France Telecom-CNET, France No previous knowledge of VHDL is necessary for this tutorial. This tutorial is aimed at people who are discovering VHDL, VHDL beginners and people who will not use VHDL directly for modeling (due to their position or their domain of work). The goal is to provide them with an overview of the VHDL world (scope, tools, extensions, methodologies). This is definitely NOT a course on the VHDL language. The tutorial will answer the following questions: o What is a Hardware Description Language? o What are the advantageous features of VHDL and what are its limitations? o What will be the evolution around VHDL? o What is a VHDL Based methodology? What are Specification, Modeling, Synthesis, Formal Proof? o How can VHDL tools be chosen? o What is the trend in this methodology? What will the next steps be? Jean-Michel Berge is in charge of the "Specification and standardization" group at CNET, Research center of FRANCE TELECOM. He has co-authored four books on VHDL and is co-editor of a series of books on Modeling: "Current Issues in Electronic Modeling", KLUWER Academic Publishers. Jean-Michel Berge is active in several VHDL standardization working groups and is the chairman of the IEEE 1076.1 working group (Analog extensions to the VHDL Hardware Description Language, VHDL-A). Synthesis applications of VHDL Eugenio Villar, Microelectronics Group of the University of Cantabria, Spain VHDL was developed as a language for modeling applications, namely, digital system modeling. As a consequence, its use for synthesis applications is not straightforward. Nevertheless, synthesis from VHDL is one of the most important applications of the language today with high user demand. In this tutorial, the use of VHDL in synthesis applications will be covered. The synthesis methodologies used by current commercial synthesis tools will be described. VHDL description of combinational, synchronous sequential, and asynchronous sequential logic, FSMs and FSMDs will be covered and several examples provided. Behavioral synthesis will be introduced. The tutorial is targeted for those students, teachers, design engineers and managers interested in the state of the art of todays VHDL synthesis technology. The tutorial can also be of interest for professionals with experience in a specific synthesis tool but interested in the general VHDL synthesis methodology used by current commercial synthesis tools. Dr. Eugenio Villar received the BSc in Science (Electronics) in 1979 and the Ph.D. in Science (Electronics) in 1984, both from the University of Cantabria. Since 1984 he is Titular Professor at this University. He has been involved in several national and international research projects founded by different companies and public organizations. His research interests include sequential circuits testing and system-level synthesis with the publication of several papers. Since 1990 is actively involved in the standardization process of VHDL as member of the EVASG, the DASC and Chair of the European VHDL Synthesis Working Group. He is member of the Program Committee of several Conferences like the VHDL Forum for CAD in Europe, EuroVHDL and the VIUF. Formal Methods for Hardware Verification: Overview and Application to VHDL, Carlos Delgado Kloos and Peter T. Breuer, Universidad Politecnica de Madrid (UPM), Spain It is recognized that formal design and verification methods are an important requirement for the attainment of high quality system designs. The field has evolved enormously during the last few years, resulting in the fact that formal design and verification methods are nowadays supported by several tools, both commercial and academic. In this tutorial, we will present on the one hand the basic concepts and the state of the art in the field, covering different approaches to formal hardware verification (including theorem proving and model checking). On the other hand, we will show how to go about formal verification in the standard hardware description language VHDL using a semantic logic model. Carlos Delgado Kloos has the degree of Dr. Ing. Telecom. from the UPM and of Dr. rer. nat. in Computer Science from the Tech Univ of Munich. He is presently Professor at the UPM. His research interests include formal methods for hardware design. He is vice-chair of IFIP TC 10 and secretary of IFIP WG 10.5. He is a member of the editorial board of the Springer Journal "Formal Aspects of Computing" and of several Programme Committees. Peter T. Breuer is visiting the UPM under the auspices of the Euroform project. His PhD is from Cambridge, 1985. He has held appointments as Fellow at the Univ of Kent, Research Assoc at the Univ of Cambridge, has been a member of the PRG of the Univ of Oxford, Visiting Fellow in Software Engineering at British Telecom, and Visiting Assoc Professor at Florida Institute of Technology. His current interests include hardware specification language semantics and formal methods in software engineering. Both have recently edited a book published in March 1995 by Kluwer entitled "Formal Semantics for VHDL". 14.00 Opening Session Opening Remarks: P. Bakowski Welcoming: B. Remaud, Y. Thomas, A. Dantec, J. Mermet, W. Nebel Keynote Address: Ron Waxman "The Union of Specification Modeling with the Design Process." The talk will address the motivation for integrating specification modeling into the design process, how it may be accomplished, and the benefits derived from the process. 15.30 Coffee Break 16.00 Specification and System Design Session Chair: C. Delgado Kloos, Univ. Politecnica de Madrid, Spain System Performance Modeling and Analysis with VHDL: Benefits and Limitations J-P. Calvez, D. Heller, O. Pasquier, IRESTE, France Modeling Shared Variables in VHDL - a Pragmatic Approach J. Wytrebowicz, Institut National des Telecommunications, France An Environment for Electronic Systems Simulation based on VHDL G. Lehmann, M. Wolff, B. Wunder, K. D. Mueller-Glaser, Univ. Karlsruhe, Germany 17.30-19.00 Vendors presentation Tuesday, April 25, 1995 9.00 Synthesis Session Chair: F. Rammig, Univ. Paderborn/CadLab Validating Subroutines of the VHDL Synthesis Packages W. Ecker, Siemens AG, Germany Resource Constrained VHDL Synthesis from Algorithmic Description K. Djigande, S. Crand, P. Bakowski, J-F. Diouris, D. Jeuland, IRESTE, France VHDL Synthesis Description Portability: The Need for Level-x Synthesis Subsets E. Villar, ETSI Industriales y de Telecomunicacion, Spain, W. Ecker, Siemens AG, M. Selz, Univ. Erlangen-Nurnberg, Germany 10.30 Coffee Break 11.00 FPGA Modeling and Synthesis Session Chair: E. Villar, Univ. Cantabria, Spain Experiences with VHDL and FPGAs L. Lindh, J. Furunas, J. Starner, Malardalens Univ., Sweden VHDL-based Rapid Hardware Prototyping Using FPGA Technology M. Khosravipour, H. Gruenbacher, Vienna Univ. of Technology, Austria 12.00 Break 13.00 Lunch 14.30 Test Session Chair: J-P. Caisso, MATRA MHS, France Assessment of Functional Testability Properties from VHDL Descriptions C. Bolchini, Politecnico di Milano, M. Bombana, Italtel SIT, G. Buonanno, Politecnico di Milano, P. Cavalloro, Italtel SIT, F. Ferrandi, D. Sciuto, Politecnico di Milano, G. Zaza, Italtel SIT, Italy An Approach to Checking the Completeness of Stimuli (short paper) T. Gabler, Siemens AG, Germany A Complete Test Methodology for Validating ASIC Workstation Libraries (short paper) Ph. Leclair, J-F. Rousseleau, MATRA MHS, France 15.40 Coffee Break 16.00 Tools Session Chair: A. Balboni, Italtel SIT, Italy Specific Image Processing Designed with an Original VHDL Front-End Tool O. Deforges, G. Ramstein, P. Bakowski, IRESTE, France Unified ASIC Library Development Suite R. Bedi, P. Deshmukh, Viewlogic Systems, USA 17.00 Panel: Does Synthesis Need Simulation ? Panel Chair: S. Krolikoski, Compass DA, USA 19.30 Conference Dinner Boat trip on the river Erdre 10.00-18.00 Exhibition Wednesday April 26, 1995 9.00-16.00 Exhibition ESPRIT Project 8370-ESIP Workshop on Libraries, Component Modeling, and Quality Assurance in cooperation with IFIP WG 10.5 and ECSI System designers need libraries of component models. Current libraries of models are in most cases neither portable nor compatible. This is caused by the lack of generally accepted rules for the development of models. The VITAL initiative is a big step towards changing this scenario for ASIC models. High model development costs for complex components and difficulty to protect proprietary rights of model developers constitute further obstacles. The objective of this workshop is to gather engineers developing models and responsible for libraries of components, designers using models in a board-level simulation, vendors developing tools, and academic people to discuss the state-of-the-art problems and solutions related to building libraries of sign-off, accurate, fast, portable, compatible and correct models of digital, analogue and mixed components. 9.00 Opening 9.15 Models of Complex Components Session chair: D. Borrione, ARTEMIS/IMAG, France Model Availability, Portability and Accuracy - An IC Vendor's Perspective, Efforts and Vision for the Future W. Hobbs, Intel Corporation, USA Prototyping: the Bottom Line of VHDL System Simulation S. Olcoz, L. Entrena, L. Berrojo, J. Goicolea, TGI, Spain Aspects of Modeling a Library of Complex and Highly Flexible Components in VHDL V. Preis, Corporate Research and Development, Siemens AG, Germany 10.45 Coffee break 11.15 Model Generation Tools Session chair: R. Waxman, Univ. of Virginia, USA An Expert Assistant for Hardware Systems Specifications L. Chaouat, Ch. Munk, A. Vachoux, D. Mlynek, EPFL-DE-LEG/C3i, Switzerland MELODY: An Efficient Layout-Based Models Generator F. Delguste, F. Igier, F. Lepine, MATRA-MHS, France Implementing VITAL: The COMPASS Model Generator S. Krolikoski, M. Grossman, Compass Design Automation, USA 12.45-14.30 Lunch 14.30 Quality Concepts Session chair: %%To be decided%% Modern Concepts of Quality and Their Relations to Model Libraries L. Jozwiak, Eindhoven Univ. of Technology, The Netherlands Quality Measures and Analysis: a way to improve VHDL models M. Mastretti, ITALTEL SIT, M. Sturlesi, S. Tomasello, Univ. degli Studi di Milano, Italy 15.30 Coffee break 16.00 Industrial Requirements and Modelling Standards Session chair: M. Laurent, MATRA MHS, France Standards for Interoperability and Portability S. Hurat, Thomson-CSF/SCTF, France The Usage of VHDL in the European Space Agency P. Sinander, ESA/ESTEC, The Netherlands 17.00 Short coffee break 17.15-18.15 Experiments with Analog HDLs Session chair: J-M. Berge, France Telecom-CNET, France Analog and Mixed Modeling with HDL-A - An Evaluation F. Lemery, J.P. Morin, E. Nercessian, SGS-THOMSON Microelectronics, France Modelling and Simulation of Microsystems - An Experience with HDL-A B. Romanowicz, Ph. Lerch, Ph. Renaud, Inst. de Microtechnique, A. Vachoux, Centre de Conception de Circuits Integres, Switzerland Thursday, 27 April 1995 9.00 VITAL Modelling Session chair: Oz Levia, Synopsys, USA Issues in Efficient Modeling and Acceleration of VITAL Modules S. Nayak, A. Roy, CADENCE Design Systems, India Fault Modelling in VITAL J.L. Barreda, P. Sanchez, E. Villar, Univ. of Cantabria, Spain 10.00 Short coffee break 10.15 Status of VITAL standardization Session chair: Victor Berman, Chair IEEE DASC WG on VHDL Timing Methodology, USA - Status for IEEE standardization and short term objectives - Longer term objectives with discussion - Implications for sign-off - In-depth discussion of changes to 2.2b and some detailed examples of complex cell designs 11.45 Discussion Workshop Session chair: Adam Pawlak, ARTEMIS/IMAG, France This discussion session will focus on two topics: a database format for library information exchange, which can be used among others to generate ASIC libraries and store data for timing calculation, and the next VITAL-like effort required to stimulate further growth of VHDL. ALEX - A Database Tool to Automate the Support of Multiple ASIC Library Format R. Bedi, ViewLogic, USA The Next VHDL Time Bomb S. J. Krolikoski, Chair VHDL International Technical Activity Committee 13.00 Closing of the Workshop General Chair: General Vice-Chair: Program Chair: Adam Pawlak Sylvie Hurat Dominique Borrione ARTEMIS/IMAG Thomson-CSF/SCTF ARTEMIS/IMAG Grenoble, France Orsay, France Grenoble, France Demonstration Chair: Local Arrangements: Jean-Michel Berge Przemyslaw Bakowski France-Telecom CNET, Meylan, France IRESTE/Univ. of Nantes, France Program Committee: E. Abel, GMD, Germany, J. Armstrong, Virginia Tech, USA, P. Bakowski, IRESTE/Univ. of Nantes, France, A. Balboni, Italtel, Italy, J-M. Berge, France-Telecom CNET, France, V. Berman, Cadence, USA, D. Borrione, ARTEMIS/IMAG, France, N. Dutt, Univ. of California Irvine, USA, H. Gruenbacher, TU Vienna, Austria, S. Hurat, Thomson-CSF/SCTF, France, M. Laurent, Matra MHS, France, O. Levia, Synopsys, USA, S. Krolikoski, Compass DA, USA, P. Menchini, Menchini & Ass, USA, J. Mermet, ECSI and Univ. Fourier, France, G. Moretti, Intergraph Electronics, USA, Z. Navabi, Univ. Tehran, Iran, W. Nebel, Univ. Oldenburg, Germany, S. Olcoz, TGI, Spain, A. Pawlak, ARTEMIS/IMAG, France, F. Rammig, Univ. of Paderborn, Germany, J. Rouillard, ESIM, France, S. Schulz, TI, USA, E. Schutz, Alcatel Mietec, Belgium, R. Stewart, SGS-Thomson, France, A. Vachoux, EPFL, Switzerland, E. Villar, Univ. of Cantabria, Spain, R. Waxman, Univ. of Virginia, USA, R. Werner, Motorola, USA, T. Yamaguchi, NEC Corp., Japan, A. Zamfirescu, Intergraph Electronics, USA CAE Exhibition accompanying VHDL-Forum and the Workshop Location: The exhibition will take place in the central "street" of IRESTE. Opening Hours: Tuesday, 25 April 1995 from 10:00 till 18:00 Wednesday, 26 April 1995 from 9:00 till 16:00 The exhibition is open to all registered participants of VHDL-Forum and of the Workshop. Exhibitors: Leading CAE tool vendors have been invited to present their latest products. Contact Person: Jean-Paul Caisso tel: (33) 40 18 18 75 MATRA MHS fax: (33) 40 18 18 00 Route de Gachet e-mail: jean-paul.caisso@matramhs.fr CP 3008 F-44087 NANTES cedex 03 A copy of the progam as well as useful information is available on WWW at http://www.ireste.fr, choose "Les seminaires et colloques organises a l'IRESTE" ------------------------------------------------------------ REGISTRATION FORM VHDL-Forum for CAD in Europe, Spring '95 Working Conference and Workshop on Libraries, Component Modeling, and Quality Assurance April 24 - 27, 1995, Nantes, France There is one common registration procedure for both VHDL-Forum and the Workshop. By registering to the event, a participant is entitled to take part in VHDL-Forum and the Workshop, and to visit the exhibition. He will receive both volumes of proceedings. (In order to confirm your registration, this form should be returned before March 25, 1995) Last Name: ..................................................... First Name: ..................................................... Affiliation: ..................................................... Address: ..................................................... City: ..................................................... ZIP Code: ..................................................... Country: ..................................................... Phone/Fax: ..................................................... Membership No.(*): ................................................. Tutorials: (Limited number of attendees, book in time. Please tick one) 1. Tutorial: Introduction to ASIC Cells Modeling With VITAL ... 2. Tutorial: Introduction to VHDL 1993 and Shared Variables ... 3. Tutorial: VHDL and Associated Methods ... 4. Tutorial: Synthesis applications of VHDL ... 5. Tutorial: Formal Methods for Hardware Verification: Overview and Application to VHDL ... VHDL-Forum and Workshop Received before Received after Registration Fees: March 25, 1995 March 25, 1995 or On-Site Member ECSI, IFIP or affiliated Organization(*) 1900 FF 2100 FF Non-member 2000 FF 2200 FF Student (enclose a copy of your Univ. ID-card) 400 FF 500 FF Tutorials: (The fee is for one tutorial) 600 FF 700 FF Payment: (Please tick fees above and choose the tutorial you want to attend.) ... Payment by personal cheque drawn on a French Bank or international cheque (Traveller's cheque, EuroCheque, etc) in French Francs payable to IRESTE-A. ... Payment by International Bank Transfer in French Francs to account No. 0000022421Z, key 54 at bank No. 30047, desk 00019 (C.I.O. Carquefou). A copy of the remittance slip must be attached to the registration form. It must clearly state 'VHDL Forum' and the participant's name and company. ... Payment on-site by cheque (see conditions on the first method of payment) or by international credit card: VISA, EUROCARD, or MASTERCARD. Date: ................. Signature: After completing all sections, mail this form to: Frederique Bouchard, VHDL-Forum Spring'95, IRESTE, La Chantrerie, CP 3003, F-44087 Nantes cedex 03, France Phones: 33-40.68.30.49, 33-40.68.30.79 Fax: 33-40.68.30.66 e-mail: fbouchar@ireste.fr (*) IEEE, ACM, IEE, BCS, SEE, AFCET The above registration fee includes -except for students- admission to all technical sessions of VHDL-Forum and the Workshop, to the exhibition, the banquet, morning and afternoon refreshments, lunches, and a copy of the proceedings of VHDL-Forum and the Workshop. For students, the banquet, the lunches and the copies of the proceedings are not included. CANCELLATION. No refunds will be made unless a written request for cancellation received prior to March 25, 1995. All refunds are subject to a 10% processing fee. Substitutions will be accepted at any stay. ------------------------------------------------------------------- HOTEL RESERVATION FORM VHDL-FORUM for CAD in EUROPE, Spring'95 and Workshop on Libraries, Component Modeling, and Quality Assurance NANTES, APRIL 24-27, 1995 IMPORTANT: Mail completed form directly to the chosen hotel. Last Name .......................................................... First Name ......................................................... Affiliation ....................................................... Mailing Address .................................................... Country ............................................................ Phone Number ...................................................... Fax Number ......................................................... Please reserve: ... a single room ... a double room for .... nights Expected date and time of arrival: ................................. Departure date: .................................................... -------------------------------------------------------------------- SPECIAL RATES HAVE BEEN NEGOTIATED IN THE HOTELS LISTED BELOW (Price given breakfast included) *** Hotel de Bourgogne 9, allee du Cdt Charcot, F-44000 Nantes Ph : (33) 40.74.03.34 Fax: (33) 40.14.03.86 Single Room: 290 FF Double Room: 310 FF 330 FF (2 Twin beds) *** Hotel de Vendee 8, allee du Cdt Charcot, F-44000 Nantes Ph : (33) 40.74.14.54 Fax: (33) 40.74.77.68 Single Room: 300 FF Double Room: 320 FF *** Hotel de France 24, rue Crebillon, F-44000 Nantes Ph : (33) 40.73.57.91 Fax: (33) 40.69.75.75 Single Room: From 350 FF Double Room: From 392 FF *** Hotel Le Jules Verne Square Fleuriot de l'Angle, F-44000 Nantes Ph : (33) 40.35.74.50 Fax : (33) 40.20.09.35 Single Room: From 339 FF *** Hotel La Perouse 3 Allee Duquesne, F-44000 Nantes Ph : (33) 40.89.75.00 Fax: (33) 40.89.76.00 Single Room: From 390 FF *** Hotel Adagio 4, rue de Couedic, F-44000 Nantes Ph : (33) 51.82.10.00 Fax: (33) 51.82.10.10 Single Room: 605 FF Double Room: 670 FF A deposit covering the charge for one night must be enclosed. It will be deducted from the hotel bill. If no deposit is enclosed, requests for hotel reservation will not be guaranteed. Should you wish to cancel your reservation, please do so by mail, fax or telegram at least 2 weeks prior to the anticipated date of arrival. Otherwise, the hotel will retain your deposit and no refund will be made. Hotel reservations will be handled on a first come first served basis. It is therefore in your interest to mail your hotel reservation form together with your deposit as soon as possible. All prices are given in French Francs so kindly make your payment in that currency. _______________________ General Information Location: IRESTE (Institut de Recherche et d'Enseignement Superieur aux Techniques de l'Electronique) IHT (Institut des Hommes et de la Technologie) Nantes, France Dates: Tutorial Sessions* VHDL-Forum Europe April 24, 1995 General Sessions (morning) April 24-25, 1995 CAE Exhibition Workshop on Libraries, Component April 25-26, 1995 Modeling, and Quality Assurance April 26-27, 1995 *Hot topics are presented in the tutorials for a reasonable fee. Number of attendees is limited, book in time. Access to Nantes: By plane: Nantes-Atlantique international airport is about 15 km South West of the town centre, which may be reached by taxi or shuttle service to the railway station. By train: The S.N.C.F. railway station is close to the town centre. The connection Paris-Nantes by TGV (High Speed Train) takes only two hours. There are between one and two TGVs every hour. A reservation is necessary. Access to IRESTE: By car: Turn off the northern ring road at La Beaujoire, and follow Atlanpole direction by the route of Saint-Joseph de Porterie, OR on the motorway A821 (A11) -no tollgate on this part-, take the exit Atlanpole and follow the signs Atlanpole - La Chantrerie till IRESTE. By bus: IRESTE can be reached from the city centre via Tramway line 1 (terminus: La Beaujoire) and then bus No. 72. A shuttle bus will be available for transportation between hotels and IRESTE in the morning and after evening sessions. Weather: In April, the weather in Western France is mild (15 C-18 C, but mornings can be fresh). Showers are still possible, therefore it is advisable to bring a raincoat or umbrella. Interesting Places in Nantes: Chateau of the Dukes of Brittany, with museums or temporary exhibitions inside. Museums: Jules Verne Museum Doll and Toy Museum Museum of Fine Arts Natural History Museum Thomas Dobree Museum Planetarium Archaeological Museum Loire Regional Postal Museum Parks and Gardens: Jardin des Plantes Parc de la Chantrerie Parc de Proce Parc de La Beaujoire Ile de Versailles Outside Nantes: La Baule: 70 kms (direction Saint-Nazaire). One of the most famous beaches in Europe. Ile de Noirmoutier: 80 kms. Nice island with a medieval castle. Carnac: 120 kms. Celtic site. and many others... Useful Address: Further information on local attractions can be obtained by contacting the Nantes Tourist Office: Maison du Tourisme, Place du Commerce, 44000 Nantes. Ph: (33) 40 47 04 51. Car Rental: Prices (approx.): Category I: between 425 FF for 1 day and 1330 FF for 5 days Category II: between 565 FF for 1 day and 1600 FF for 5 days Payment by credit-card At the railway station: Budget, Ph: (33) 40 35 75 75 Hertz, Ph: (33) 40 89 64 04 At the airport: Budget, Ph: (33) 40 84 81 07 From 1076-1-request@sicmail.epfl.ch Wed Mar 22 13:18:49 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Wed, 22 Mar 95 13:17:39 -0500 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Wed, 22 Mar 95 13:17:31 -0500 Received: from gatekeeper.ray.com by sicmail.epfl.ch with SMTP (PP) id <15766-0@sicmail.epfl.ch>; Wed, 22 Mar 1995 18:21:50 +0100 Received: from localhost (mailer@localhost) by gatekeeper.ray.com (8.6.4/8.6.5) id MAA17703 for <1076-1@epfl.ch>; Wed, 22 Mar 1995 12:22:14 -0500 Received: from sud2.ed.ray.com by gatekeeper.ray.com; Wed Mar 22 12:21:05 1995 Received: from SUD2.ED.RAY.COM by SUD2.ED.RAY.COM (PMDF V4.2-10 #4335) id <01HOFNS9F2EU8XDB7C@SUD2.ED.RAY.COM>; Wed, 22 Mar 1995 12:15:56 EST Date: Wed, 22 Mar 1995 12:15:56 -0500 (EST) From: "Joe Gwinn, 508-440-3330" Subject: Comments on Comments on VHDL-A Language Architecture To: 1076-1@epfl.ch Message-Id: <01HOFNS9F2EW8XDB7C@SUD2.ED.RAY.COM> X-Envelope-To: 1076-1@epfl.ch X-Vms-To: IN%"1076-1@epfl.ch" X-Vms-Cc: GWINN Mime-Version: 1.0 Content-Transfer-Encoding: 7BIT Folks, I have some more comments to offer after seeing the back-and-forth generated by my original set of comments. Section 1.5: Eduard Moser is correct in his point about mechanical systems generally or at least often yielding overdetermined systems of DAEs, plus added constraints. VHDL-A should at least be able to express such a system, even if not all solvers can currently handle such. This sounds like just the sort of system where we should help the poor users, with their models with thousands of variables. It might help if Eduard summarized the interfaces of the existing solvers for such systems. Just how much trouble will these interfaces cause VHDL-A? Section 2.4: >The implementation of the threshold is not specified in the language although >its qualities are. This is because its implementation has to be tightly >coupled with the integration algorithm, and we are not specifying algorithms. >The simulation cycle limits the time steps such that any time a sample is >taken from the analog waveform, this sample is close to the exact value >(e.g. closer than a user specified tolerance). Threshold evaluation can yield >an accurate root of a waveform that is close to the exact one, which translates >to a small timing error w.r.t. the exact solution. It is not the case that one needs to understand every detail of the solver to know that one needs threshold triggers (which will cause control to pass from analog kernel to digital kernel), and to specify the syntax and semantics of such triggers. The issue is if the current approach of taking the timestep that caused the variable in question to just pass the threshold can yield sufficient accuracy in practice. I claim that for many applications, it cannot. I mentioned the bouncing ball example, a simple but representative problem. The classic problem is that for simulation speed one would like the solver to take large steps in smooth parts of the trajectory, yet the simple take-the- step-that-just-crossed-threshold approach forces one to take very small steps to get sufficient accuracy. This tradeoff/problem is widely discussed in the continuous system simulation literature, and there is a standard solution. This specific example appears in the ACSL manual, with at least one other example, all to address this very common problem. >I believe what you describe as the usual approach amounts to an extrapolation >of the trajectory of the ball. Still you end up with a threshold crossing >for the extrapolated waveform unless I miss something. Exactly, but it doesn't amount to the same thing. One does extrapolate the trajectory; this is the standard solution mentioned above. The extrapoation need not be complex; all that's required is to predict at the previous timestep that threshold will be crossed in the next timestep, compute by linear interpolation when crossing will occur, mark this as the last step before transition to the digital kernel, and issue a short step that ends at the predicted time of crossing. The remaining error is generally ignored; although one can do a little fixup in the digital kernel if needed. Shortening the last step allows the solver to approach at maximum speed, and yet land precisely on the discontinuity. As a matter of user interface, a common approach is to allow the user to supply a function to be called by the solver at each timestep. This function implements the above prediction, and returns the current prediction of endtime, and a boolean saying that the end is neigh. The advantage of such an approach is that the user knows the physics of his system, and so knows where the essential discontinuities are, such as the steel ball hitting the steel floorplate, and so can arrange for precisely timed transitions from analog to digital and back. In the case of bouncing balls, there are two sets of analog equations (free-flight and in-contact), and two transitions (make-contact and break-contact); the digital kernel must gain control at these transition timepoints and make the needed analog variable fixups to maintain/break continuity as indicated by the physics of the problem. Section 3.4: One can predict physical discontinuities and handle them as described above in the section 2.4 discussion. However, there are other things that cause trouble. First, model mistakes are not uncommon, and can cause unexpected jumps or even discontinuities. Clamping reduces the error and spread of error caused by such model problems. In a complex model, it may be difficult to achieve perfection; robustness is a real advantage. Second, a sufficiently sharp feature will cause the solver to suffer numerical problems, even if the feature doesn't satisfy the mathematical definition of a discontinuity. Clamping can reduce the problems caused by such sharp features. Third is that real systems often exhibit rate limiting and saturation, and in any case one generally knows from the physics of the system being modelled just what the likely limits of rate and range are. It would be nice to be able to express all of these in a standard fashion, so there is a portable way to inform the solver. Joe Gwinn From 1076-1-request@sicmail.epfl.ch Sat Mar 25 04:02:32 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Sat, 25 Mar 95 04:02:29 -0500 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Sat, 25 Mar 95 04:02:23 -0500 Received: from mailgate.Cadence.COM by sicmail.epfl.ch with SMTP (PP) id <22286-0@sicmail.epfl.ch>; Sat, 25 Mar 1995 09:37:05 +0100 Received: (from smap@localhost) by mailgate.Cadence.COM (8.6.8/8.6.8) id AAA29370 for <1076-1@epfl.ch>; Sat, 25 Mar 1995 00:37:02 -0800 Received: from cds2072.cadence.com(158.140.24.54) by mailgate.cadence.com via smap (V1.0mjr) id sma029350; Sat Mar 25 00:36:46 1995 Received: from mailgate.Cadence.COM (mailgate.cadence.com [158.140.2.1]) by cds2072.Cadence.COM (8.6.8/8.6.8) with ESMTP id AAA29195 for ; Sat, 25 Mar 1995 00:36:43 -0800 Received: (from smap@localhost) by mailgate.Cadence.COM (8.6.8/8.6.8) id AAA29347 for ; Sat, 25 Mar 1995 00:36:42 -0800 Received: from vhdl.vhdl.org(198.31.14.3) by mailgate.cadence.com via smap (V1.0mjr) id sma029339; Sat Mar 25 00:36:33 1995 Received: by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA04790; Sat, 25 Mar 95 00:26:34 PST Date: Sat, 25 Mar 95 00:26:34 PST From: jose@vhdl.org (Jose Torres) Message-Id: <9503250826.AA04790@vhdl.vhdl.org> To: math@vhdl.org Subject: new version of the math package Cc: jose@vhdl.org Hello everyone, There is a new version of the package that incorporates several of the suggestions and feedback that we received through the reflector, as well as feedback generated during the creation of the template for the test bench. The new version of the package is located in the following directory (server machine: vhdl.org): /vi/math/package under the following file names: math_head.3.24.95.vhd -- contains the package declaration math_body.3.24.95.vhd -- contains the package body math.3.24.95.tar.Z -- compacted tar file that contains the previous two. If you do not have access to ftp and would like to receive a copy through e-mail, please let me know. This new version of the package has several changes with respect the previous broadcasted version. In summary, the changes in the package include: - fixes to the algorithms in functions that were generating incorrect results, - changes in the order of arguments in some functions for consistency with usage of equivalent functionality in other languages - changes in the name of some functions for clarity and consistency with names in ADA and to take advantage of the overloading capabilities of VHDL - addition of new functions that were considered necessary as part of the basic building blocks - deletion of the foreign functions in order to have a package that is VHDL only - enhancements in comments to include valid ranges and domains for the functions, as well as error conditions. We would appreciate your feedback on this new version as soon as possible, since we are planning to send the ballots out around the middle of next month. We are still in the process of finishing the template for the test bench. For those of you who have volunteered to help on the completion of the test bench, we will let you know pretty soon how you can help us to finish this task. A detailed list of all the major changes follows: 1) For most of the functions, the comments after their declaration were modified to include the purpose of the function, the domain of its arguments, the range of its return value, error conditions, and predefined results for special cases. 2) Changed the usage of LOG(BASE, X) to be LOG(X, BASE) for consistency with ADA, and as per request of some users 3) Removed the definition of COMPLEX_VECTOR in math-complex for consistency with math_real 4) Renamed the following functions for consistency with ADA and to take advantage of VHDL overloading facilities: CABS -> ABS CARG -> ARG CSQRT -> SQRT CEXP -> EXP ASIN -> ARCSIN ACOS -> ARCCOS ATAN -> ARCTAN ATAN2 -> ARCTAN ASINH -> ARCSINH ACOSH -> ARCCOSH ATANH -> ARCTANH 5) Changed CSQRT (now SQRT) to return only one value; the one with positive real part. 6) Added the following constants: MATH_HALF_PI MATH_Q_PI MATH_3_HALF_PI MATH_TWO_PI 7) Modified CEIL and FLOOR to fix error 8) Modified FMAX and FMIN to return X when X = Y 9) Modified convergence criteria in SQRT and CBRT 10) Modified MATH_EPS to represent 5 fractional decimal digits for consistency with minimum LRM requirements. 11) Modified all trigonometric functions to return predefined values for special cases such as 0, pi, pi/2, 3pi/2, and 2pi 12) Modified SINH, COSH, and TANH to fix computation for special cases 13) Modified "**" check for error condition and value computation 14) Modified EXP to make use of the relation EXP(x+y) = EXP(x)*EXP(y) for better accuracy 15) Modified EXP and LOG to check for illegal ranges and to compute predefined values for special cases 16) Modified SIN, COS, TAN for greater accuracy 17) Modified ASINH, ACOSH, and ATANH for special cases 18) Added the following functions in math_real: TRUNC(X) MOD(X,Y) 19) Added the following function in math_complex: LOG(Z) 20) Modified the order of arguments in ARCTAN() from ARCTAN(X,Y) to ARCTAN(Y,X) for consistency with usage in other languages 21) Added complete support for the type COMPLEX_POLAR in MATH_COMPLEX. The new version now supports the same functions for both COMPLEX and COMPLEX_POLAR. Some people feel that complex_polar should be part of a different package, I would like to hear your position regarding this matter. 22) Removed the complex arithmetic operators that had a combination of COMPLEX and COMPLEX_POLAR argument types, as part of the process of providing same functionality for both types. 23) Removed all the foreign functions, so that the package has no dependencies on non-VHDL functions. The deleted functions are SRAND RAND GET_RAND_MAX 24) Modified package banners to fit IEEE requirements. 25) The draft of the documentation has been revised by IEEE and the corresponding changes have been incorporated. From 1076-1-request@sicmail.epfl.ch Thu Mar 30 10:53:54 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Thu, 30 Mar 95 10:53:27 -0500 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Thu, 30 Mar 95 10:53:21 -0500 Received: from mailgate.ericsson.se by sicmail.epfl.ch with SMTP (PP) id <08265-0@sicmail.epfl.ch>; Thu, 30 Mar 1995 16:52:27 +0200 Received: from swindon.ericsson.se (swi055.ericsson.se [164.48.29.55]) by mailgate.ericsson.se (8.6.11/1.0) with SMTP id QAA29468 for <1076-1@epfl.ch>; Thu, 30 Mar 1995 16:52:22 +0200 Message-Id: <199503301452.QAA29468@mailgate.ericsson.se> Received: by swindon.ericsson.se (4.1/EKA-S-UW-P1A) id AA20955; Thu, 30 Mar 95 15:53:34 BST (GMT) Date: Thu, 30 Mar 95 15:53:34 BST From: ekadys@swi055.ericsson.se (Dyson Wilkes) To: 1076-1@epfl.ch Subject: VCO example please I am trying to gain an understanding of how the proposed Language has changed over the last six months. To this end I have in front of me a simple model of a VCO in "1076.1 June 94" care of a Cadence presentation I attended back then. I would like an equivalent in the current state of the language. This way feel I can get up to speed with the latest developments. Maybe it is the case that there are a set of evolving examples of models of typical analog/mixed signal functions. Then again the old hands may tell me its too early as yet to have such a set of examples. I think such a set could aid in "testing" the language and am sure that, as in other fields of design, it is good to test as you go along. If necessary I can reproduce the "1076.1 June 94" example VCO model or supply an English description to work from. In the ideal, there is an example out there already that someone can point me to. - Dyson Wilkes Ericsson Components Swindon England ekadys@swindon.ericsson.se From 1076-1-request@sicmail.epfl.ch Thu Mar 30 11:55:29 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Thu, 30 Mar 95 11:55:04 -0500 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Thu, 30 Mar 95 11:54:57 -0500 Received: from psi.com by sicmail.epfl.ch with SMTP (PP) id <10843-0@sicmail.epfl.ch>; Thu, 30 Mar 1995 18:26:35 +0200 Received: from analogy.com (analogy.analogy.com) by psi.com (4.1/2.1-PSI/PSINet) id AA17125; Thu, 30 Mar 95 11:26:11 EST Received: from miller.analogy.com ([149.117.72.253]) by analogy.com (4.1/Shared_Spool_1.3) id AA17933; Thu, 30 Mar 95 08:26:49 PST Received: from satyr.analogy.com by miller.analogy.com (4.1/SMI-3.2) id AA06841; Thu, 30 Mar 95 08:26:48 PST Received: by satyr.analogy.com (5.0/SMI-SVR4) id AA09981; Thu, 30 Mar 1995 08:26:48 -0800 Date: Thu, 30 Mar 1995 08:26:48 -0800 From: christen@analogy.com (Ernst Christen) Message-Id: <9503301626.AA09981@satyr.analogy.com> To: ekadys@swi055.ericsson.se Subject: Re: VCO example please Cc: 1076-1@epfl.ch Content-Length: 1681 > >I am trying to gain an understanding of how the proposed Language has >changed over the last six months. To this end I have in front of me a >simple model of a VCO in "1076.1 June 94" care of a Cadence presentation >I attended back then. I would like an equivalent in the current state of >the language. This way feel I can get up to speed with the latest developments. > I don't know about the VCO that you saw in that Cadence presentation. Here is a simple one, linear with clipping, that I have used. USE math_real.all; ENTITY vco IS -- vco interface GENERIC (f_ref : REAL; -- reference frequency (Hz) slope : REAL; -- VCO gain (Hz/V)) v_ref : REAL; -- reference voltage (V) v_max : REAL := REAL'RIGHT); -- clipping voltage (V) PORT (TERMINAL cp, cm : electrical; -- input pins TERMINAL p, m : electrical); -- output pins END ENTITY vco; ARCHITECTURE clipped OF vco IS -- vco implementation QUANTITY verr ACROSS cp TO cm; -- input branch QUANTITY vout ACROSS iout THROUGH p TO m; -- output branch QUANTITY vcontrol, freq, phase : REAL := 0.0; BEGIN IF verr > v_max USE -- clipping of input voltage vcontrol == v_max; ELSIF verr < -v_max USE vcontrol == -v_max; ELSE vcontrol == verr; END IF; freq == f_ref + slope * (vcontrol - v_ref); -- frequency phase == 2.0 * MATH_PI * freq'INTEG; -- phase vout == sin(phase); END ARCHITECTURE clipped; Thanks. Ernst Christen From 1076-1-request@sicmail.epfl.ch Thu Mar 30 12:45:05 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Thu, 30 Mar 95 12:44:57 -0500 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Thu, 30 Mar 95 12:44:48 -0500 Received: from psi.com by sicmail.epfl.ch with SMTP (PP) id <11580-0@sicmail.epfl.ch>; Thu, 30 Mar 1995 19:04:48 +0200 Received: from analogy.com (analogy.analogy.com) by psi.com (4.1/2.1-PSI/PSINet) id AA21645; Thu, 30 Mar 95 12:04:42 EST Received: from miller.analogy.com ([149.117.72.253]) by analogy.com (4.1/Shared_Spool_1.3) id AA18267; Thu, 30 Mar 95 09:05:21 PST Received: from satyr.analogy.com by miller.analogy.com (4.1/SMI-3.2) id AA06948; Thu, 30 Mar 95 09:05:20 PST Received: by satyr.analogy.com (5.0/SMI-SVR4) id AA10030; Thu, 30 Mar 1995 09:05:19 -0800 Date: Thu, 30 Mar 1995 09:05:19 -0800 From: christen@analogy.com (Ernst Christen) Message-Id: <9503301705.AA10030@satyr.analogy.com> To: 1076-1@epfl.ch Subject: Re: VCO example please Content-Length: 109 Sorry, I made one mistake in this example: instead of END IF it should read END USE. Thanks. Ernst Christen From 1076-1-request@sicmail.epfl.ch Fri Mar 31 10:07:29 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Fri, 31 Mar 95 10:06:46 -0500 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Fri, 31 Mar 95 10:06:35 -0500 Received: from c3imac12.epfl.ch by sicmail.epfl.ch with SMTP (PP) id <27640-0@sicmail.epfl.ch>; Fri, 31 Mar 1995 16:27:05 +0200 X-Sender: vachoux@c3i9.epfl.ch Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 31 Mar 1995 16:27:53 +0100 To: ekadys@swi055.ericsson.se From: alain.vachoux@leg.de.epfl.ch (Alain Vachoux EPFL-LEG/C3i) Subject: Re: VCO example please Cc: 1076-1@epfl.ch >> >>I am trying to gain an understanding of how the proposed Language has >>changed over the last six months. To this end I have in front of me a >>simple model of a VCO in "1076.1 June 94" care of a Cadence presentation >>I attended back then. I would like an equivalent in the current state of >>the language. This way feel I can get up to speed with the latest >>developments. >> >I don't know about the VCO that you saw in that Cadence presentation. Here >is a simple one, linear with clipping, that I have used. > >USE math_real.all; >ENTITY vco IS -- vco interface > GENERIC (f_ref : REAL; -- reference frequency (Hz) > slope : REAL; -- VCO gain (Hz/V)) > v_ref : REAL; -- reference voltage (V) > v_max : REAL := REAL'RIGHT); -- clipping voltage (V) > PORT (TERMINAL cp, cm : electrical; -- input pins > TERMINAL p, m : electrical); -- output pins >END ENTITY vco; > >ARCHITECTURE clipped OF vco IS -- vco implementation > QUANTITY verr ACROSS cp TO cm; -- input branch > QUANTITY vout ACROSS iout THROUGH p TO m; -- output branch > QUANTITY vcontrol, freq, phase : REAL := 0.0; >BEGIN > IF verr > v_max USE -- clipping of input voltage > vcontrol == v_max; > ELSIF verr < -v_max USE > vcontrol == -v_max; > ELSE > vcontrol == verr; > END IF; > freq == f_ref + slope * (vcontrol - v_ref); -- frequency > phase == 2.0 * MATH_PI * freq'INTEG; -- phase > vout == sin(phase); >END ARCHITECTURE clipped; Please consider the syntax here as provisional. The VHDL-A language design is still under development within the 1076.1 LAT group and has not yet made widely available within the whole 1076.1 working group. Many examples like this were already given in various tutorials and seminars so far, basically following two different forms: one from the LESs (Language Extension Specification) and one from the White Papers produced by the LAT (Language Architecture Team). The example above follows LAT work. It was always explicitly stated, however, that the syntax used in examples is subject to change. One point that will be discussed during the next 1076.1 working group meeting in San Diego (April 8) will precisely address this issue, i.e. how to reconcile both approaches. Regards, Alain Vachoux ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Alain Vachoux Swiss Federal Institute of Technology (EPFL) Dept. of Electrical Engineering Integrated Systems Center (C3i) e-mail: alain.vachoux@leg.de.epfl.ch EL-Ecublens Phone: (+41) 21 693 69 84 CH-1015 Lausanne, Switzerland Fax: (+41) 21 693 46 63 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From 1076-1-request@sicmail.epfl.ch Fri Mar 31 11:20:51 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Fri, 31 Mar 95 11:20:07 -0500 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Fri, 31 Mar 95 11:19:59 -0500 Received: from NS.OLEANE.NET by sicmail.epfl.ch with SMTP (PP) id <00392-0@sicmail.epfl.ch>; Fri, 31 Mar 1995 18:10:02 +0200 Received: from droopy.UUCP (uuanacad@localhost) by relay1.oleane.net (8.6.10/8.6.9) with UUCP id SAA08038 for 1076-1@epfl.ch; Fri, 31 Mar 1995 18:09:38 +0200 Received: from milady. by anacad.fr (5.0/SMI-SVR4) id AA02721; Fri, 31 Mar 1995 17:58:58 --100 Received: from perrier.anacad.fr by milady. (5.0/SMI-SVR4) id AA18636; Fri, 31 Mar 1995 17:58:58 --100 Date: Fri, 31 Mar 1995 17:58:58 --100 From: vhdldo@anacad.fr (Jean-Jose MAYOL) Message-Id: <9503311558.AA18636@milady.> Received: by perrier.anacad.fr (4.1/SMI-4.1) id AA12877; Fri, 31 Mar 95 17:58:56 +0200 To: 1076-1@epfl.ch Subject: Re: VCO example please Content-Length: 2858 Dear all, Ernst Christien has put on the reflector an example of a VCO This syntax has neither been approved or voted by the 1076.1 Working Group. In fact at the current time, two semantic and syntax approaches exist. One syntax is based on the LES and is based on the result of a public IEEE vote. This syntax has as yet not been examined in detail by the LAT group. A second syntax has been entirely elaborated by some members of the LAT group. Both syntax approaches need to be examined by the LAT group and eventually voted on. We write below the same example, using the second syntax. I believe that the syntax proposed by the LES group is more adaptated in this example because the set of equations is defined as a sequential set of equations. It is not wrong to write them concurrently, but if it is done like this, analog objects are required instead of simple variables in a sequential code. In this example, only the frequency has to be an analog quantity, since it has to be integrated. Here then is the example using the alternative syntax! USE math_real.all; ENTITY vco IS -- vco interface GENERIC (f_ref : analog; -- reference frequency (Hz) slope : analog; -- VCO gain (Hz/V)) v_ref : analog; -- reference voltage (V) v_max : analog := 0.0); -- clipping voltage (V) PIN (cp, cm : electrical; -- input pins p, m : electrical); -- output pins END ENTITY vco; ARCHITECTURE clipped_relation OF vco IS -- vco implementation QUANTITY freq : analog := 0.0; BEGIN RELATION VARIABLE vcontrol, phase : analog; PROCEDURAL => IF (cp, cm).v > v_max THEN -- clipping of input voltage vcontrol := v_max; ELSIF (cp, cm).v < -v_max THEN vcontrol := -v_max; ELSE vcontrol := (cp, cm).v; END IF; freq := f_ref + slope * (vcontrol - v_ref); -- frequency phase := 2.0 * MATH_PI * freq'INTEG; -- phase (p, m).v := sin(phase); END RELATION; END ARCHITECTURE clipped_relation; Best regard[s]*. Jean jose, core member of the LAT +-------------------------------------------------+---------------------------+ | |\_/| ANACAD Electrical Engineering Software | Les Jardins de Maupertuis | | |^.^| Grenoble Center | 11 A, Chemin de la Dhuy | |=(___)= Software Modeling & Simulation Team | 38240 Meylan (FRANCE) | | U Jean-Jose Mayol | | +-------------------------------------------------+ Tel : (33) 76 90 83 50 | | The opposite of a profound truth may well be | Fax : (33) 76 90 07 24 | | another profound truth -- Bohr | email : vhdldo@anacad.fr | +-------------------------------------------------+---------------------------+ From 1076-1-request@sicmail.epfl.ch Fri Mar 31 14:21:24 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Fri, 31 Mar 95 14:21:09 -0500 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Fri, 31 Mar 95 14:21:03 -0500 Received: from psi.com by sicmail.epfl.ch with SMTP (PP) id <02759-0@sicmail.epfl.ch>; Fri, 31 Mar 1995 20:55:40 +0200 Received: from analogy.com (analogy.analogy.com) by psi.com (4.1/2.1-PSI/PSINet) id AA12250; Fri, 31 Mar 95 13:55:32 EST Received: from miller.analogy.com ([149.117.72.253]) by analogy.com (4.1/Shared_Spool_1.3) id AA25472; Fri, 31 Mar 95 10:56:11 PST Received: from satyr.analogy.com by miller.analogy.com (4.1/SMI-3.2) id AA09183; Fri, 31 Mar 95 10:56:11 PST Received: by satyr.analogy.com (5.0/SMI-SVR4) id AA10465; Fri, 31 Mar 1995 10:56:10 -0800 Date: Fri, 31 Mar 1995 10:56:10 -0800 From: christen@analogy.com (Ernst Christen) Message-Id: <9503311856.AA10465@satyr.analogy.com> To: 1076-1@epfl.ch Subject: Re: VCO example please Content-Length: 1262 Alain Vachoux and Jean-Jose Mayol are quite right that the syntax used in my version of the VCO is not final, nor has it been approved by anybody. I should have mentioned this in my response to the original request, as well as that there are many different ways to describe a VCO, including a version that looks like Jean-Jose's. Jean-Jose is wrong, though, to say that his version is based on material that was publicly voted on. There has never been a vote on the content of the LESs, neither by email nor at a WG meeting. This means that there is no "official" syntax, and there will not be one until we have completed the balloting process. The important thing to remember here is not to get hung up on syntax. The LAT will discuss next week two different semantic approaches to formulate the behavior of continuous time systems, one which I have used as a basis for my version, the other one more along Jean-Jose's version. We will have to discuss these alternatives based on their technical merit, completeness and compliance with our language design guidelines. This is the process that the LAT has agreed to follow. It is premature to fight battles over syntax if the semantics have not been firmly established and accepted. Thanks. Ernst Christen From 1076-1-request@sicmail.epfl.ch Tue Apr 4 05:34:46 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Tue, 4 Apr 95 05:34:36 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Tue, 4 Apr 95 05:34:31 -0400 Received: from err.ethz.ch by sicmail.epfl.ch with SMTP (PP) id <13525-0@sicmail.epfl.ch>; Tue, 4 Apr 1995 10:58:46 +0200 Received: from moleson.ethz.ch by err.ethz.ch with SMTP id AA24563 (5.65c/IIS-2.7 for <1076-1@epfl.ch>); Tue, 4 Apr 1995 10:58:44 +0200 Received: (litsios@localhost) by moleson.ethz.ch (8.6.11/IISnullclient-1.0) id KAA12388; Tue, 4 Apr 1995 10:58:42 +0200 Message-Id: <199504040858.KAA12388@moleson.ethz.ch> To: 1076-1@epfl.ch Subject: Looking for references implementation of simulation languages Date: Tue, 04 Apr 1995 10:58:41 +0200 From: James Litsios I would like to find bibliographical references to the different techniques that go into implementing simulation languages such as VHDL-A. I'll make a summary of the responses I get and mail it back on the reflector. I am interested in the following "domains": Syntax-semantic issues. Compiler/interpreter issues. Differentiation issues (automatic, symbolic, etc.). Time discretization issues (what to do with ddt operator). Other language related algorithmic issues (mixed mode, ...) Simulator core issues (design, algorithms, ...). Many thanks, James Litsios __________________________________________________________________ James Litsios Phone: +41 1/632 60 92 Integrated Systems Laboratory Fax: +41 1/252 09 94 ETH Zurich E-Mail:litsios@iis.ee.ethz.ch CH-8092 Zurich, Switzerland From 1076-1-request@sicmail.epfl.ch Wed Apr 12 15:19:19 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Wed, 12 Apr 95 15:19:12 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Wed, 12 Apr 95 15:19:06 -0400 Received: from psi.com by sicmail.epfl.ch with SMTP (PP) id <02244-0@sicmail.epfl.ch>; Wed, 12 Apr 1995 20:51:25 +0200 Received: from analogy.com (analogy.analogy.com) by psi.com (4.1/2.1-PSI/PSINet) id AA13993; Wed, 12 Apr 95 14:51:18 EDT Received: from miller.analogy.com ([149.117.72.253]) by analogy.com (4.1/Shared_Spool_1.3) id AA27025; Wed, 12 Apr 95 11:52:07 PDT Received: from satyr.analogy.com by miller.analogy.com (4.1/SMI-3.2) id AA29847; Wed, 12 Apr 95 11:52:06 PDT Received: by satyr.analogy.com (5.0/SMI-SVR4) id AA21930; Wed, 12 Apr 1995 11:52:04 -0700 Date: Wed, 12 Apr 1995 11:52:04 -0700 From: christen@analogy.com (Ernst Christen) Message-Id: <9504121852.AA21930@satyr.analogy.com> To: 1076-1@epfl.ch Subject: LAT Meeting Summary Content-Length: 4006 The 6th meeting of the 1076.1 Language Architecture Team was held on April 4, 5, and 7, in San Diego, in parallel with VIUF. This is a brief summary of the meeting, detailed minutes will follow. The meeting was attended by 11 people. The main topic of the meeting was the discussion and adoption of white papers addressing various language design issues. The papers were prepared by 7 different authors. They had been distributed to the meeting attendees prior to the meeting. We first discussed a brief document describing the LAT process of approving documents. Some minor changes were suggested which are currently being incorporated in the document. We agreed to the policy that all papers that have been approved be sent to the reflector and made available at the ftp repository. A new version of the paper on quantities and terminals was discussed and approved provisionally, i.e. as a working basis for future work. The paper had been revised after the previous material had been presented to the ISAC (Issues Screening and Analysis Committee), a committee of VHDL language experts, who had some concerns about the previous form of the definitions for composite natures and terminals. The new formalism for composite natures now parallels the existing formalism for types in VHDL. We then discussed the changes in the white paper on the simulation cycle, which includes A/D and D/A issues. The essential changes are a new definition for the implicit signals that allow the detection of threshold crossing, and a definition of the break statement for managing discontinuities, which comes in a sequential and a concurrent form. The paper was provisionally approved, but some concerns were raised about the break statement: some people feel that the need for a break could be detected automatically in many cases. This requires further investigations. Next, an update on initialization and DC analysis was given. Much time has been spent on establishing a theoretical foundation for this issue, but much work is still required to develop the consequences of this study on the VHDL-A language definition. Two approaches to express continuous time behavior in VHDL-A were discussed next. They both propose three simultaneous statements that can be used wherever concurrent statements can be used in a block, in order to support an equational modeling style. The proposals differ in their treatment of procedural code: one uses the relation as a declarative region and provides a framework which allows interaction of procedural and equational code, the other proposes a declarative region which supports procedural statements only. In both cases the semantics for this part have yet to be formally defined. The LAT provisionally approved the part of this topic where the two proposals agree and sent the rest back to the authors. One LAT member expressed interest to work out yet another proposal which is more procedurally oriented. This proposal should be available at the next meeting. The final topic discussed at the meeting was solvability. This paper addresses various topics related to the formulation of constraints, existence of a solution, implementability etc. Most of the discussion centered around the question whether the assumptions made to develop solvability criteria are correct. This topic needs further work. There was no time left to discuss the remaining white papers. Still, we did make progress in various areas, but there is a lot of work left to be done. Specifically, besides the already existing papers we identified 4 more topics and assigned them to different authors. We expect to discuss some of these at the next meeting, which is planned around DAC, which will be held in June in San Francisco. On behalf of the 1076.1 Working Group I would like to thank all attendees for their contributions, both before and during the meeting. Special thanks go to Compass Design Automation for providing the meeting facilities. Ernst Christen Chair LAT From 1076-1-request@sicmail.epfl.ch Thu Apr 13 07:30:56 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Thu, 13 Apr 95 07:30:44 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Thu, 13 Apr 95 07:30:40 -0400 X400-Received: by mta sicmail.epfl.ch in /PRMD=switch/ADMD=arCom/C=ch/; Relayed; Thu, 13 Apr 1995 13:08:21 +0200 Date: Thu, 13 Apr 1995 13:08:21 +0200 X400-Originator: 1076-1-request@sicmail.epfl.ch X400-Recipients: non-disclosure:; X400-Mts-Identifier: [/PRMD=switch/ADMD=arCom/C=ch/;sicmail.ep.987:13.03.95.11.08.21] Priority: Non-Urgent Dl-Expansion-History: 1076-1@epfl.ch ; Thu, 13 Apr 1995 13:08:19 +0200; From: "Jean-michel.Berge" Message-Id: To: analog_reflector <1076-1@epfl.ch> Subject: Results of VHDL-A elections X-Mailer: Mail*Link SMTP/MS 3.0.0 As announced during our last meeting (last Saturday) in San-Diego, 35 people voted, of which 4 did not have yet explicitly asked to be voting members. Ken Bakalar is the new co-chair of the language design subcommittee (22 yes, 5 no, 4 abstentions). Dan Damon is the new vice-chair of the validation subcommittee (14 yes, 1 no). One people abstained to vote for this position. Other candidates for this position were: Andrew Patterson (8 yes, 0 no), and Peter Liebmann (10 yes, 1 no). Good luck in their tasks to the new chairs and sorry for those who have not been elected. Thanks, Jean-Michel From 1076-1-request@sicmail.epfl.ch Tue Apr 18 05:50:47 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Tue, 18 Apr 95 05:50:42 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Tue, 18 Apr 95 05:50:34 -0400 Received: from c3imac12.epfl.ch by sicmail.epfl.ch with SMTP (PP) id <25172-0@sicmail.epfl.ch>; Tue, 18 Apr 1995 11:14:03 +0200 X-Sender: vachoux@c3i9.epfl.ch Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 18 Apr 1995 11:14:59 +0100 To: 1076-1@epfl.ch From: alain.vachoux@leg.de.epfl.ch (Alain Vachoux EPFL-LEG/C3i) Subject: 1076.1 meeting minutes (April 8) Minutes of IEEE VHDL 1076.1 working group IEEE CS DASC working group meetings, April 8, 1995 Princess Resort, San Diego, CA Submitted by Alain Vachoux Reviewed by Jean-Michel Berge and Ernst Christen Attendees (23): Kenneth Bakalar kenb@compass-da.com Dave Barton dlb@hudson.wash.inmet.com Jean-Michel Berge berge@cns.cnet.fr Victor Berman berman@cadence.com Ernst Christen christen@analogy.com David Crabbs dcrabbs@microsim.com Dan Damon dan_damon@mentorg.com Steven Drager dragers@rl.af.mil Oliver Fischer-Binder olli@anacad.de Jim Hanna hanna@rl.af.mil Chong Hoc Hao chh@aluxpo.att.com Robert Hillman hillman@rl.af.mil Sylvie Hurat hurat@sctf.thomson.fr Stan Krolikoski stank@compass-da.com Joannis Papanuskas joannis@dic.k8.rt.bosch.de Tray Read bread@el.wpafb.af.mil Jacques Rouillard rouillard@acm.org Eric Sax sax@fzi.de Ken Simone ksimone@mtl.com David Thornhill david_thornhill@gmail4.sp.trw.com Alain Vachoux vachoux@leg.de.epfl.ch Kevin Walsh kevin@anacad.com Ron Waxman rw6x@virginia.edu Agenda: General information (Jean-Michel Berge) - New vice-chairs - 1076.1 status - Miscellaneous news LAT results - LAT work status (Ernst Christen) - Quantities & terminals (Ken Bakalar) - Simultaneous statements (Alain Vachoux) - Simulation cycle (Ken Bakalar) - Initialization (Ernst Christen) - SPICE compatibility (Ernst Christen) - Environment (Jean-Michel Berge) Future plans - LESs and White Papers (Alain Vachoux) - Documentation task (Kevin Walsh) - Validation task (Oliver Fischer-Binder) Open issues The meeting started at 8.30am and finished at 4.30pm. A postscript version of the slides presented during the meeting are available in the 1076.1 ftp archive site in the directory: pub/vhdl/standards/ieee/1076.1/wg_meetings/DASC_apr95 1. General information (Jean-Michel Berge) Jean-Michel presented the results of the election for two free co/vice-chair seats within the working group. 35 people voted, 4 of which were not voting members at the time of the election. Ken Bakalar is the new co-chair of the language design subcommittee (22 yes, 5 no, 4 abstentions). Dan Damon is the new vice-chair of the validation subcommittee (14 yes, 1 no). One people abstained to vote for this position. Other candidates for this position were: Andrew Patterson (8 yes, 0 no), and Peter Liebmann (10 yes, 1 no). Jean-Michel congratulated the new co/vice-chairs. Jean-Michel then presented the status of the work in the working group. The main effort is still in the language design for which the LAT is making much progress. Language validation and documentation are running in parallel. People from these teams are also participating in the LAT activities, establishing close links with language design. Jean-Michel stressed the multiple aspects of the validation task: validation from the users' perspective (designers), validation from the tool builders' perspective, validation from the VHDL "gurus" (ISAC) perspective, and formal semantics validation (information model). As miscellaneous information, Jean-Michel recalled the last ISAC meeting in February where Ken Bakalar and Ernst Christen presented basic pieces of the VHDL-A architecture. Jean-Michel also mentioned the intent from Christian Giumale and Hillary Kahn to develop an information model of VHDL-A in the Express language. Christian Giumale will contact Ernst Christen to get as much information as possible about the VHDL-A architecture to be able to start this work. He is also waiting for some funding. 2. LAT Report 2.1. LAT Status (Ernst Christen) [A postscript version of the slides presented here is available in the file latstatus_slides.ps] Ernst presented the status of the work in the Language Architecture Team: language design tasks, language design guidelines, LAT process, progress since the last LAT meeting, current status, and future plans. A 3 days LAT meeting was just held in Compass facilities at La Jolla (April 4, 5, and 7). Separate minutes will be available on the reflector. The LAT meeting attendees provisionally approved two white papers ("Quantities & Terminals" and "Simulation Cycle") and the first part of a third one ("Simultaneous Statements") providing minor corrections are done. A package consisting of the VHDL-A architecture document and these 3 WPs will be published on the reflector as soon as the corrected versions are available. Another set of 10 white papers are currently elaborated within the LAT. Ernst mentioned that several reviews of the current shape of the VHDL-A language occured recently: conference tutorials (ICEHDL'95, EDTC'95, VIUF Spring'95), ISAC meeting, AVI Board presentation, VIUF workshop). He stressed the importance to get as much as possible feedback from the community. Main comments/questions from the audience: - Q: How to ensure portability since simulators may use different (numerical) methods? A: The LAT is currently investigating a way to define either a "universal" convergence criteria or a kind of quality factor to specify some tolerance band any tool should satisfy. - Q: How many people are currently involved in the LAT? A: Attendence is slightly varying, but there is a core of about 7 or 8 people. 2.2. VHDL-A Language Architecture (Ernst Christen) [A postscript version of the slides presented here is available in the file langarch_slides.ps] Ernst presented an overview of the VHDL-A language architecture. A first version of the VHDL-A architecture document was already published on the reflector. Ernst covered the following aspects: quantities, conservation semantics, simulation cycle, initialization and DC operating point computation, solvability of DAEs, frequency domain, open issues. Main comments/questions from the audience: - Q: Will VHDL-A support partial derivatives? This would be useful to write semiconductor models at the process level, using doping profiles. A: Partial derivatives are not supported in VHDL-A, in accordance with the DOD. A workaround is to explicitly discretize the PDEs and use the resulting ODEs in a model. Only derivative w.r.t. time are provided in VHDL-A. - C: (On the fact that quantities and signals have well-defined values when used in a process or a simultaneous statement) It is better to say that there is a time synchronization between digital events and analog time steps. Agreed. - Q: How to ensure/help convergence during simulation? A: VHDL-A is algorithm independent, but the LAT is studying this issue. - Q: Are user-defined initial conditions supported? A: Yes, but how to do it is still under investigation in the LAT. - Q: Availability of white papers? A: A first package is currently reviewed by the LAT. Once done, it will be put on the reflector and in the ftp archive site. 2.3. Quantities & Terminals (Ken Bakalar) [A postscript version of the slides presented here is available in the file: kenb_slides.ps] Ken presented the semantics and a proposed syntax of the new objects called quantities and terminals, and the new simple simultaneous statement. Many examples were given as illustration. Main comments/questions from the audience: - C: In the definition of the simple simultaneous statement, the term "real variable" has a mathematical meaning. From an implementation perspective, this means that the expressions involved have a floating-point type. Agreed. - Q: Why may record natures not have fields of different natures? A: It's true that it is more restrictive than standard VHDL rules, but following VHDL rules would imply a much more complex set of rules for composite terminal association. In addition, the meaning of N'Reference (N being a nature) is more complex to define. - Q: Is it possible to have several different N'Reference terminals (N being a nature)? A: Although it might be useful to declare and use several references (e.g. VDD, VSS, etc.), this is more a modeling aspect than a language aspect. For any nature N there exists only one reference terminal N'Reference which has a reference value always equal to zero. - C: If N is a nature and T a terminal, N'Reference is a different thing than T'Reference. The former is a the reference terminal of the nature, while the latter is the value of the across aspect of the terminal T w.r.t. the nature reference terminal (e.g. voltage to ground). The use of the same attribute name for different meanings is not new to VHDL (e.g. 'Left). Agreed. - C: It is better to change the adjective "natural" to the name "nature" in the nature syntax definition. "natural" is more linked to integer numbers. Agreed. - Q: Why not putting the interface quantity declaration in the generic interface list? A: Generic parameters are static, while interface quantities are dynamic. Port interface list is then more appropriate. Interface quantities may be considered as abstract connection points. - Q: Why an inout mode for a terminal? A: Terminals don't have indeed any mode, but this optional keyword does not put any harm. It is proposed to keep a symmetry with interface signal and interface quantity declarations, which do have a mode. Note that mode on interface quantities has a specific role in the checking of the model solvability. For them, only mode in or mode out should be used. - Q: Why not using the existing mode linkage for interface terminals and quantities? A: Mode linkage was initially defined to allow a semantics free topology. The analog connection points are obviously not semantics free. - Q: Is a nature conversion mechanism provided, symmetrical to the VHDL type conversion mechanism? This would allow the connection of terminals of different natures. A: Usually, such conversion happens in an explicit component (e.g. a transducer) in a real-world model, but we will study this issue. - Q: How to enforce nature interoperability? A: With the definition of standard guidelines and possibly a standard package. The LAT is currently investigating what should be put into a VHDL-A standard environment, possibly by extending the existing 1076 standard package. It is also suggested that the validation effort may produce a set of "standard" natures, at least in the form of guidelines. - Q: In a branch quantity declaration, does the through aspect declare an implicit branch? A: Yes, it does, although the associated through quantity is explicitly declared. It is something similar to a net in VHDL which is derived from the model topology. 2.4. Simultaneous Statements (Alain Vachoux) [A postscript version of the slides presented here are available in the file: simulstmt_slides.ps] Alain presented the conditional and selected simultaneous statement forms the LAT agreed upon so far. The remaining issue not yet solved is how to describe continuous behavior in a sequential way (also called procedural style). Since these extensions are quiet straightforward, no specific questions or comments were issued. 2.5. Simulation Cycle (Ken Bakalar) [A postscript version of the slides presented here are available in the file: kenb_slides.ps] Ken presented the new mixed-mode simulation cycle and related topics (i.e. execution of the analog solver, A/D-D/A interactions, support of discontinuities). Main comments/questions from the audience: - Q: How to define the "closeness" to a solution? A: This is certainly something a user may want to specify. It's yet not clear whether it is a language issue or a tool issue. Different algorithms need different kinds of tolerances. The LAT is currently investigating how possible it is to define a kind of generic or universal tolerance which might be put in the language. - Q: How to deal with different time definitions in digital and analog descriptions? A: It would be sufficient to require for the digital type TIME to be coded on, say, 128 bits. A unified model of time based on this resolution, even integer based, should work. Still an open issue in the LAT. - Q: How to deal with A/D and D/A conversions at the netlist level? A: Associating a terminal (signal) to an interface signal (terminal) is not directly possible due to strong type checking. Also, this would need a specific conversion mechanism, something like a conversion component (a function cannot retain state). This issue is currently being investigated in the LAT. Note that everything necessary to describe an explicit interface A/D or D/A component already exists in VHDL-A. - Q: Is discontinuous behavior detectable by the simulator? A: It is usually not possible for the analog solver to detect discontinuities automatically, mainly for reliability and efficiency reasons. - Q: May the use of "if..use" or "case..use" simultaneous statements allow for the detection and the correct handling of discontinuities? A: In many cases such statements do not require a break statement because the user has carefully paid attention to ensure a smooth transition between regions of operation. - Q: Any way to define discontinuities in the language? A: There cannot be any notion of discontinuity in the language since it is intended for the description of continuous systems. We are talking about model discontinuities, not algorithm discontinuities. 2.6. Initialization (Ernst Christen) SPICE Compatibility (Ernst Christen) Environment (Jean-Michel Berge) These parts have not been presented because all the intended time schedule was used for the other LAT reports. There is already a lot of work done for them and they will be investigated further in the next LAT meeting. 3. Future Plans 3.1. LESs and White Papers (Alain Vachoux) [A postscript version of the slides presented here is available in the file leswp_slides.ps] Alain presented the current situation of the language design phase regarding the documents it has already produced, namely the Language Extension Specifications (LES) and the White Papers (WP). The objective was to propose a way to continue the language design, the validation, and the documentation phases with an agreed set of language definitions. It was recognized that LESs were very useful to define new concepts and to start the language design. However, they are too much focused on syntactic categories and hence do not provide a consistent view of the language architecture. WPs intend to provide such a view. They include all the new concepts from the LESs and they go closer to the future 1076.1 LRM. Therefore, the following statement was adopted by the audience (16 yes, 0 no, 1 abstention, the remaining people deciding not to vote): "The validation and the documentation teams will use the White Papers approved (provisionaly or finally) by the LAT as a base for their work." This statement will be the subject of a vote within the working group as soon as the first package of White Papers is made available to the whole working group. 3.2. Documentation Task (Kevin Walsh) Kevin presented the work to be done by the documentation team: - Review the documents issued by the LAT for consistency. - Highlight the impact on VHDL 1076-1993 LRM. Definition of changes, new sections, etc. A first report will be available by the next working group meeting (probably during next DAC in June). - "Write" 1076.1 LRM. - Prepare the IEEE balloting package. Main comments/questions from the audience: C: The documentation team should not wait for a working group approval of all White Papers to work. Agreed. C: Action item for Jean-Michel. To proceed to a working group vote when: 1) all WPs are completed, and 2) when a draft 1076.1 LRM is available. Agreed. C: The documentation team should study two forms of documentation and select the best one: 1) a 1076.1 LRM as an annotation to 1076 LRM, and 2) a full 1076.1 LRM. Agreed. C: How to proceed to the IEEE ballot for 1076.1 brings a new issue to IEEE, i.e. the material to vote on (see the two possible forms above). It is suggested to propose a "full solution" (i.e. solution 2) to IEEE and to wait for a reaction. If no reaction from IEEE, the working group will then stress the issues regarding both approaches (solution 1 and 2). Agreed. C: An additional rationale or tutorial document would help to understand the voting material, although not part of the ballot. Agreed. 3.3. Validation Task (Oliver Fischer-Binder) Oliver presented first the status of the validation task: - Validation task was not fully operational due to the inaccessibility of the chair and vice-chair since June 1994. - Validation examples gathered so far are not really useful because: - they used existing languages more or less close to VHDL-A - they sometimes evaluated an existing implementation (simulator) - they have been distributed to the working group without review from the validation team - they lacked descriptions of the issues or problems raised - they were not based on the current (but yet unfinished) VHDL-A architecture. Oliver then presented a set of improvements for the validation task: - Validation chair and vice-chair are now easily accessible by e-mail. - Require people to formulate the issues raised in the examples. - Extract the purpose of examples and make a classification. - Extract a formulation of the examples at an abstracted level. - Keep track of examples and issues raised by other groups. - Use of a consistent set of semantics. Main comments/questions from the audience: C: Validation guidelines should be broadcasted to the working group. Agreed as an action item for Oliver. C: A requirement trace from the design objectives is needed. Agreed as an action item for Oliver. C: Specific examples may be useful to validate the design objectives. Agreed. C: Need for a VHDL-A parser. Victor Berman proposed to investigate means to provide a prototype parser. 4. Open Issues The Design Objective Document (DOD) and the associated Design Objective Rationale (DOR) are not yet formally approved by the working group. Alain admitted that this approval was an action item from the last working group meeting in November 1994, but nothing yet occured. Draft versions are available in the ftp site (DOD version 2.1 and DOR version 1.1) in the directory pub/vhdl/standards/ieee/1076.1/requirements. A working group vote should occur ASAP. It should be completed by next working group meeting (probably DAC). 5. Summary of action items What Who Comment Names of new vice-chairs Jean-Michel by week 15 on the reflector White Papers package Ernst ASAP Vote DOD 2.1 / DOR 1.1 Alain ASAP, finished by week 21 Vote on the statement Jean-Michel as soon as the first WPs package about WPs is out Agenda of next Jean-Michel by week 21 at the latest DASC 1076.1 meeting Validation guidelines Oliver ASAP Requirement trace Oliver work to be started Prototype VHDL-A parser Victor investigation only, no deadline ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Alain Vachoux Swiss Federal Institute of Technology (EPFL) Dept. of Electrical Engineering Integrated Systems Center (C3i) e-mail: alain.vachoux@leg.de.epfl.ch EL-Ecublens Phone: (+41) 21 693 69 84 CH-1015 Lausanne, Switzerland Fax: (+41) 21 693 46 63 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From 1076-1-request@sicmail.epfl.ch Thu Apr 20 20:03:04 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Thu, 20 Apr 95 20:03:01 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Thu, 20 Apr 95 20:02:56 -0400 Received: from psi.com by sicmail.epfl.ch with SMTP (PP) id <18955-0@sicmail.epfl.ch>; Fri, 21 Apr 1995 01:34:18 +0200 Received: from analogy.com (analogy.analogy.com) by psi.com (4.1/2.1-PSI/PSINet) id AA10081; Thu, 20 Apr 95 19:34:04 EDT Received: from miller.analogy.com ([149.117.72.253]) by analogy.com (4.1/Shared_Spool_1.3) id AA09696; Thu, 20 Apr 95 16:34:58 PDT Received: from satyr.analogy.com by miller.analogy.com (4.1/SMI-3.2) id AA14241; Thu, 20 Apr 95 16:34:58 PDT Received: by satyr.analogy.com (5.0/SMI-SVR4) id AA25588; Thu, 20 Apr 1995 16:34:58 -0700 Date: Thu, 20 Apr 1995 16:34:58 -0700 From: christen@analogy.com (Ernst Christen) Message-Id: <9504202334.AA25588@satyr.analogy.com> To: 1076-1@epfl.ch Subject: LAT Policies Content-Length: 3880 At its meeting two weeks ago the 1076,1 Language Architecture Team approved the following policies about how documents get approved in the LAT. The policies are not new, they simply were not documented before. The most important part for the Working Group is section 3. about white papers. We use the documented process of approving white papers before they get distributed to the Working Group in order to avoid creating confusion by publishing untested ideas. The process guarantees that the material described in the papers has been reviewed by a group of people, and that it is consistent with their beliefs of how the language should look like. At the LAT meeting we also adopted 3 papers provisionally. They will be sent to the reflector shortly, together with an updated version of the language architecture document. Ernst Christen LAT chair ---------------------------------------------------------------------- 1076.1 LAT Document Approval ============================ The 1076.1 Language Architecture Team (LAT) maintains a variety of documents. This note describes how such documents get approved. 1. The 1076.1 Reflector ----------------------- The reflector of the 1076.1 Working Group can be used by sending email to 1076-1@epfl.ch. 2. Meeting Minutes ------------------ The following process is used to approve minutes of LAT meetings a) The minutes taker sends a draft of the minutes to all meeting attendees for review. b) Meeting attendees respond to the minutes taker and to the LAT chair with comments, corrections etc. to the minutes. c) The minutes taker incorporates the review comments as (s)he sees fit. d) If no major objections have been raised by the review process the minutes are sent to the 1076.1 reflector. Otherwise, back to point a). In case of disagreement the LAT chair decides and the disagreement is noted. e) The minutes are reviewed at the beginning of the next LAT meeting, and further corrections etc. are recorded in the minutes of this next meeting. The minutes are considered approved after this review. 3. White Papers --------------- White papers are the means by which the LAT documents its language design decisions. White papers present related issues in a uniform framework, using a language that is close to the LRM language (where applicable) and a working syntax. White papers are prepared and maintained by an author and reviewed, discussed and approved by the LAT. There are two levels of approval for white papers. a) Provisional Approval A white paper can be provisionally approved if it is advanced in its treatment of a topic. Provisional approval can be given subject to the incorporation of some clearly identified changes. A provisionally approved white paper can serve as a basis for work on other topics. b) Final Approval A white paper can get final approval if it is deemed complete in its treatment of a topic. White papers get approved by the LAT at LAT meetings. The approval process is identical for both levels and is by consensus as judged by the LAT chair. Straw polls can be taken to get a sense of the meeting. Serious minority positions can be presented along with (but not necessarily at the same time as) the majority document. In such case it is up to the minority to write down their position. Approval of a white paper can be revoked using the same process. After LAT meetings, or at other appropriate times, the LAT chair sends a package containing all white papers that have been approved at either level to the 1076.1 reflector, to make them available to the whole working group. Each white paper so broadcast includes as part of its revision history its approval status. 4. Other documents ------------------ Procedures will be worked out on an "as needed" basis, and they will likely follow the process for white papers. From 1076-1-request@sicmail.epfl.ch Mon Apr 24 20:47:22 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Mon, 24 Apr 95 20:46:48 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Mon, 24 Apr 95 20:46:29 -0400 Received: from newsgw.mentorg.com by sicmail.epfl.ch with SMTP (PP) id <14251-1@sicmail.epfl.ch>; Tue, 25 Apr 1995 02:28:13 +0200 Received: from wv.wv.mentorg.com by newsgw.mentorg.com (8.6.4/CF5.22R) id UAA02670; Mon, 24 Apr 1995 20:27:06 -0400 Received: from pdxml1.mentorg.com by wv.wv.mentorg.com (8.6.8.1/CF5.22R) id RAA14697; Mon, 24 Apr 1995 17:28:08 -0700 Message-Id: Date: 24 Apr 1995 17:19:19 -0800 From: Dan Damon Subject: LAT minutes, part 1 To: "1076.1 reflector" <1076-1@epfl.ch> X-Mailer: Mail*Link SMTP/QM 3.0.0 Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; Name="Message Body" Content-Transfer-Encoding: quoted-printable LAT minutes, part 1 4/24/95 17:18 VHDL-A Language Architecture Team meeting 4/4 - 4/7 The following members were present for the LAT meeting: Ernst Christen, Jean Michel Berge, Alain Vachoux, Chonh Hoc Hau, Dan = Damon, Oliver Fischer-Binder, Richard Trihy, Kevin Walsh, Lun Ye, Ken = Bakalar, Howard Ko. Ernst proposed the following schedule: Tuesday Approval of Minutes Quantities paper (Ken) Mixed mode paper (Ken) Initialization paper (Ernst) Environment (Jean Michel) Wednesday Relation (Alain) Simultaneous Statements (Ken) Thursday VHDL mini workshop in AM Spice Compatibility Solvability (Ernst) Friday Interpretation Domain Statistical Analysis Dimensional Analysis New issues: time, simulation controls, tolerances Review & schedule new meeting Dan Damon volunteered to take minutes, then minutes for the last meeting = were approved. (NOTE: The discussion of topics throughout the rest of the week are much = more detailed than can be reflected in these notes. I have summarized = many comments and identify the speaker by his initials, i.e., KB refers to = Ken Bakalar, while EC refers to Ernst Christen. New topics are identified = with >>>>>. Notes that I have added to clarify a point are in parenthesis = (). Also, please note that all members do not agree with the last thing = anyone said. In general, assume there was not a consensus unless = specifically written in these notes.) >>>>> Review of Action Items: The following action items from the last meeting were reviewed: Action Item Name Status Update list of references AV done Send list of Examples to Peter Liebmann JJ Mayol unknown Minutes of last meeting Dan Fitzpatrick done Circulate papers for review EC done Define new white papers EC done Write up tolerances suggestions DD not done List of open issues EC done Document LAT approval process EC will review here Collect information on Simul R (dimension) AV done Investigate LRM issues David Smith unknown Document implicit analog signals EC in mixed mode = paper Extend Quantities paper with implicit declaration of quantities JJ Mayol not done Document Q'delayed and other implicit quantities EC not done Update white papers done (SUMMARY: Most open action items have been done, but there are still = several that are still open) >>>>>Approval of LAT Documents process: (NOTE: discussion refers to white paper approval process) DD: Disagreement on white papers should be noted in the minutes, the term = consensus is not well enough defined. EC: We will leave it to the minutes-taker to document decisions in = whatever style he chooses. Certainly, anything we agree on should be = noted. DD: "Consensus as judged by the LAT chair" leaves too much leeway for the = LAT chair. We must note who approved something and who did not. EC: (After some discussion) OK, plus minority position can be documented = in a separate white paper. Provisionally approved papers will be on the = FTP site. KW: We should collect approved white papers in a single package after each = LAT meeting and send them to the reflector. AV: Everything that is put on the reflector is also stored in the ftp = site. JMB: Agree, plus these papers can be a basis for the validation group. = Also, we should make sure that any syntax used is "working" as opposed to = "final" syntax. KB: Sometimes you can't separate syntax from semantics. EC: Yes, you can generally separate them. KB: We would like to define a syntax that forces a model developer write = flawless models. Unfortunately you can't do that so you constrain it = first by semantic constraints, then static semantic constraints, then = dynamic semantic constraints. JMB: Writing syntax overlaps with the charter of the Documentation Team. KB: The documentation team can make transformations in syntax as long as = it doesn't violate the spirit of what the LAT develops. KB: Don't send the entire white paper to the reflector, just a table of = contents. Let anyone interested look them up on the FTP site. ??: Many don't have ftp access, we have to send out entire package. EC: Three alternatives are: 1. Don't send out any white papers to reflector 2. Send out complete package to the reflector & put it also on the = ftp site. 3. Send table of contents & put the rest on FTP site. Group: Hand vote consensus agreement on #2. EC: Other issues? AV: White papers are becoming official documents while LESs are becoming = obsolete. EC: That's just a consequence of the process. (SUMMARY: The white paper approval process will continue to operate on = consensus as judged by the LAT chair. Papers with consensus approval = shall be published to the working group.) >>>>>Quantities paper (Ken Bakalar) (Information presented by Ken Bakalar) DD: If we decide to have a single port interface list, we need to have the = working group reconsider the issue. EC: Working group only said that they couldn't be one list until we had = thought through all the details. DD: If there is one list, perhaps we can define implicit conversion = between signals and quantities so you can swap digital and analog = architecture's. KB: It's an attractive idea, but there are too many details to work out. = It probably won't make the cut list. KW: What do you mean by scalar vs. vector? KB: A vector in VHDL parlance has a different meaning than a vector in = math or physics. The VHDL vector is an array, it does not have any = direction. KB: discussion of composite terminals DD: Why do all parts of a record have to be the same nature? EC: So when you connect to a scalar, all can be connected OK. AV: Records should be allowed to be different types as in current VHDL. KB: Will investigate this. RT: Why is ddt an attribute rather than a function? A function is better. = Also, initial conditions are not well specified. Functions return values, not objects. q'ddt must be a quantity object. EC: Initialization, including initial conditions, is unfinished. RT: By declaring a branch, you are implicitly declaring a current path, = and all other paths not declared are zero. This is not obvious, don't = like it. I'd like all the assumptions and constraints in one place. DD: Agree with RT. This should at least be clarified in the white paper. KB: Continued white paper discussion DD: Can T'reference and T'contribution be constrained? KB: Yes, but you're apt to create problems for yourself if you do that. ----Break for lunch-----12:15 AV: Interface terminal should not have a mode. It is not really INOUT KB: It's harmless, let's just leave it there. IN and OUT are disallowed. RT: Why have terminals at all? Can't we use signals? KB: The semantics of terminals are quite different from the semantics of = signals. EC: Vote on getting rid of INOUT in section 3.3 of paper? (Section 3.3 is = titled "Terminal and Quantity Ports) Group: Hand vote consensus to get rid of INOUT in paper. KB: Mode on interface quantity is incomplete. He will put a note in the = paper to this effect. JMB: Section 4.4 describes existing VHDL syntax, not new syntax. KB: Agree JMB: How do we define the default or initial value of the complex part of = a number if we just extend the concept of real during frequency analysis. EC: We'll address this problem later. DD: T'reference and T'contribution can be basic quantities? (basic quantities are quantities used as unknowns by the DAEs. KB: Yes. HK: What is the scope of a quantity? DD: The port interface list describes the scope. AV: What about examples? KB: They should be part of the rationale. DD: The last three paragraphs of section 3.2 are very confusing & unclear. KB & RT: Discussion of basic approach this paper describes. RT: Will try to write an alternate white paper if time permits. Not = satisfied with the way declaration causes current branches to come into = existence. EC & KB: Will examine this. Improvements may be possible. EC: Can we get provisional approval? DD: Most basic constructs are there, but they are awkward to use. More = wordy than other possible implementations. Hand consensus tally on provisional approval of Quantities paper with = changes discussed: Approval: JMB, AV, DD, OFB, HK, LY, KB, EC Against: RT Abstain: KW, CHH (SUMMARY: There was considerable discussion about this white paper, but = the basic terminology and constructs seem to be acceptable to the group. = Numerous details need to be ironed out before this paper can achieve more = than provisional approval. RT and other members want to see an = alternative proposal) >>>>>Mixed Mode simulation cycle (Ken Bakalar) KB: Only one implicit signal of a quantity is needed: Q'cross(E). = Q'rising and Q'falling are not needed. Q'cross is a bit value that is '0' = when Q - E < 0.0 and '1' when Q - E is > 0.0. (The previous version of = this paper defined Q'rising, Q' falling and Q'crossing.) CHH: What is the tolerance of the crossing? RT: If we look at V =3D=3D I * R, do we use the tolerance on V or on I? = In Spectre, if we write V <=3D I * R, the tolerance on V is used. Always = the tolerance on the left hand side is used. EC: This is still an open issue. It is tightly linked to the simulation = algorithm. DD: RT is correct. We must specify a tolerance. (more discussion on various topics) KB: Maybe we should substitute resume for execute when referring to the = analog kernel. DD: Just to make this clear: Does q'cross force an analog simulation = point? KB: Q'cross forces an analog simulation point. RT: Q'cross only is not as convenient as Q'rise and Q'fall since you need = to test the value of Q'cross as well as look for an event to determine the = direction of the crossing. --------Break 3:45 KB: Every discontinuity requires a break statement. Any model without a = break at the discontinuity is erroneous. RT: Don't need to make the modeler write break statements so often if you = just do a time point whenever a digital signal crosses into an analog = model. DD: We don't want to require the model writer to have to use break = statement unless there is a significant benefit. KB: The analog solver can't look into the future to see what digital = changes will impact the analog solution point. KB: Discontinuities can be caused by: 1. Signals in a simultaneous statement 2. Conditional tests on quantities 3. Function calls in simultaneous statements 4. Re initialization of quantities caused by a break statement. KB: How do we handle discontinuities without a break. It is not possible = to efficiently discover all discontinuities. The model writer must tell = the simulator. RT: Disagree. Also, there is a problem with re initialization of = quantities at a break statement. (KB then reviewed a number of mixed mode examples using this terminology. ------End of Tuesday session ------Wednesday session, start at 8:45, same attendees. (Continuation with mixed mode paper by KB) AV: We need information on the VHDL simulation cycle from the LRM inserted = into this white paper. EC: There are still the following open issues: 1. What does a break set mean? 2. Initialization or re-initialization of quantities after a break. DD: Also open is the question: Is a break mandatory for all = discontinuities? EC: A breakpoint is mandatory for Implementability, solvability and = portability. The question is whether it can be detected reliably and = efficiently, or whether an explicit break statement is needed. DD: If the break statement can be avoided, let's not require it. EC: Need break to efficiently find discontinuities. RT: Break works well in bouncing ball situation. EC: Can we all agree that breaks are needed sometime? (General agreement) KB: It's an open issue to determine if breaks are required for efficient = operation. RT: There are some issues with Q'cross and interpolation. LY: There will be an error depending on tolerances. RT: An ASP is needed at Q'cross KB: The language says we need a time point at Q'Cross, but a smart = simulator may decide not to calculate an actual ASP here. DD: So a break is not needed at Q'cross? LY: Break is like a wait-on statement. You can detect a (digital) signal = in your equation set, so maybe you don't need a break statement in this = case. (Discontinuity caused by a digital signal) KB: Q'cross causes a time point, but ordinary signal transitions don't = cause ASPs. RT: Every signal that is used in the analog section should cause an ASP. AV: Agree with RT. Is the break statement an explicit or implicit signal? KB: Based on feedback from VHDL gurus, Q'cross has been changed to an = implicit signal. LY: We should reserve a place in this white paper for automatic A/D and = D/A conversion when signals and terminals are cross-connected. KB: This is a very difficult task, I don't think it will be done in time; = it won't make the cut list. EC: Can we provisionally approve this paper with an open issue on the = break statement? Approval: JMB, DD, HK, AV, LY, KB, KW, EC Against: RT No Vote: HCC (SUMMARY: The mixed mode paper was generally acceptable to all committee = members with the exception of the break statement. Considerable = discussion centered around when it should be used. The only common point = on the break statement was that all agreed that it was sometimes needed = for efficient modeling.) ----------------Break 10:30 >>>>>Initialization paper Ernst Christen EC: Let's go on to initialization paper and cover Relation this afternoon. = The white paper on initialization (DCOP) that we reviewed at the last LAT = meeting has not been updated because there are too many new issues that = have emerged. Outline: * Solvability of DAEs * Initialization of DAEs * DC Operation * Initialization of mixed systems * Open issues (EC continued with a discussion of the index of a system of DAEs and the = solvability of that system: Current technology can solve index 0 and 1, = but have difficulty with higher order index systems.) OFB: Synchronous systems can be treated the same way as asynchronous = systems, and a solution found. EC & KB: Disagree, still don't know what to do with synchronous systems. (Continued discussion, still unresolved) RT: Use tree-link analysis to identify any problem. KB: This issue is probably on the critical path, EC: Agree, must be solved ASAP. EC: This presentation is not a white paper, we are just presenting some = new ideas to tool builders and exploring options. (SUMMARY: This was only a presentation of the research done to date. = Ernst presented many good ideas, but he has not updated his white paper to = bring these ideas together.) ---------------Lunch, return at 1:35 >>>>>Relations white paper Alain Vachoux; Simultaneous Statements = Ken Bakalar (Same group, without KW) Relation white paper - Alain Vachoux (Discussion of functions and limitations) KB: If you screw up with impure functions, it's your own problem. (continued discussion) RT: Why do you need both a procedural and an equational part in the = relation block? EC: The relation block could conceptually be replaced with a function = call. (continued discussion including a short discussion on why variables are = cheaper to use than quantities) LY: It may be expensive to evaluate the relation code every time the = analog kernel resumes. ---------------Break Simultaneous statement white paper (Ken Bakalar) EC: On Thursday, we will be presenting papers at the VUIF conference in = the morning, and will resume after lunch. On Friday, we will meet in the = other building in the lobby at 8:30. (Discussion of pure vs. impure functions, and when to disallow impure = functions.) ---------------End of day (The entire day on Thursday was dedicated to presentations at VUIF, = originally scheduled in the morning, but later rescheduled for the = afternoon) From 1076-1-request@sicmail.epfl.ch Mon Apr 24 20:48:10 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Mon, 24 Apr 95 20:48:00 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Mon, 24 Apr 95 20:47:53 -0400 Received: from newsgw.mentorg.com by sicmail.epfl.ch with SMTP (PP) id <14248-0@sicmail.epfl.ch>; Tue, 25 Apr 1995 02:28:07 +0200 Received: from wv.wv.mentorg.com by newsgw.mentorg.com (8.6.4/CF5.22R) id UAA02664; Mon, 24 Apr 1995 20:26:58 -0400 Received: from pdxml1.mentorg.com by wv.wv.mentorg.com (8.6.8.1/CF5.22R) id RAA14686; Mon, 24 Apr 1995 17:27:59 -0700 Message-Id: Date: 24 Apr 1995 17:20:56 -0800 From: Dan Damon Subject: LAT minutes, part 2 To: "1076.1 reflector" <1076-1@epfl.ch> X-Mailer: Mail*Link SMTP/QM 3.0.0 Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; Name="Message Body" Content-Transfer-Encoding: quoted-printable LAT minutes, part 2 4/24/95 17:20 ---------------Friday 4/7 (same participants as list on Tuesday, except JMB who arrived later in the = day. He was at the DASC plenary session.) EC: Continue with discussion on Simultaneous statement vs. Relations white = papers. Would like to wrap up this discussion today. The SPICE and = solvability papers are also on the agenda, but we may not have time to get = to them. KB: Summarize the difference between the two proposals: - The Relation/procedural complex is the difference. The other = three constructs (simple simultaneous statement, if-use simultaneous = statement, and case-use simultaneous statements are the same. - Relation creates a declarative structure where variables can be = shared. - Sequential code cannot result in a quantity-like assignment (like = SpectreHDL), while KB's proposal allows this, but not a normal constraint = statement. AV: The use of variables in my proposal must be clarified. RT: Why can't constraints be included in the sequential part? They can be = easily identified by the =3D=3D operator in the equation. AV: The Equation part separates out the equations that go in the system = matrix. It is written this way for clarity. LY: A simultaneous statement is not a concurrent statement. Even though = concurrent statements are not allowed in a process, there is no reason = this rule should be the same for disallowing simultaneous equations in the = relation block. KB: We could implement a Relation, but aesthetically, I don't like it. EC: With a procedural and equational part in a Relation, the variable is = defined in the procedural and used in the equational part. This is not = parallel to processes since the variable is defined outside the procedural = part. KB: No, the declarative region is the Relation, so the variable doesn't go = outside it's declarative region - it's like a shared variable between = Procedural and Equational part. However, there is another problem; since = the procedural must be evaluated before the equation part, there must be a = rule outlining what is the sequence of evaluation. AV: If function calls are used in any simple constraint, you have exactly = the same problem: The function must be evaluated before the equation can = be evaluated. EC: KB's proposal is a self-contained set of equations. Assignments to = quantities are allowed, but not simultaneous constraints. KB: A user can always write a set of equations that does not converge. = This is not a good rule to evaluate the language. Caveat Emptor. DD: There is actually a relatively close parallel between KB's and AV's = proposals. KB: We can translate between a procedural representation and a = simultaneous representation, but it is not a straightforward translation. = It's easier to outline the procedure to do the translation rather than = actually writing the translation. (more discussion) KB: SpectreHDL, MAST, and HDL-A all have sequential execution sections, so = it must be something that is useful. EC: Agree that there is a strong incentive for a sequential execution = section, although it may not be strictly necessary. DD: A quantity assignment shows cause and effect. As such, it can be used = to make the simulation more efficient, similar to relaxation techniques. EC: This may be true for a particular implementation, but you cannot say = this in general. RT: SpectreHDL has a class of quantities that do not go into the matrix. = These are called variables in our language. Their initial values are the = value they had at the last time point. KB: This is somewhat like a process variable; the variable stays there = when the process suspends, and uses it's old value when the process = resumes. LY: We don't need to talk about iterations in the language. All that = needs to be said in the LRM is that a constraint must be true -- = regardless of how that happens. KB: Any model that depends on the number of iterations is a bad model. RT: Why can't we say that a Relation suspends and resumes just like a = process? KB: That might work. It would be a cleaner implementation. Might use a = wait statement to suspend execution. Is it possible or desirable to use = this paradigm? EC: About 7 years ago we implemented something similar, where variables = could be set to the value at the last time point. It looked like a good = solution, but it did not work because the models became dependent on the = time points selected by the algorithm. We still have a back-door = mechanism, and some models use it, but it can potentially cause problems. = Here is an example to illustrate the problem: Relation variable v: real; quantity input, output : real: output :=3D v; v:=3D input; end; RT: There is no dependency there that can cause a problem. HK: Yes there is. The equation evaluates the state of Q at time t-1 = (i.e.: delayed by one time step, not by a fixed amount of time) RT: I see there might be a problem. CHH: Consider an accumulator model: Vout =3D X; X =3D Vin + Vout; In this case, the answer depends on how often the model is evaluated. KB: The sample/hold example works well in my proposal. EC: Sh example: entity sh is port( terminal imp, inm: electrical; signal clock: in bit, signal out = real;) end entity; architecture one of sh is quantity vin across inp to inm; begin output <=3D vin when clock =3D '1'; end architecture; KB: Lightweight variables (no history) might be a better solution than = heavyweight variables (value based on last iteration). RT: Prefers heavyweight variables. -----------break 10:15 KB: I'm looking for guidance on the procedural part of my simultaneous = statements paper. Don't think that heavyweight variables are appropriate. = However in SpectreHDL, assignment statements are used, so that is some = guidance. If we use %=3D for assignment, the user may be confused when to = use it rather than :=3D, but if we use :=3D, the statement will look just = like a variable assignment statement. EC: %=3D does not add anything of value. Let's just use :=3D for quantity = assignment. KB: The sequential section must have stand alone capability, we can write = language that says the solver must make evaluation of this code equal to = zero. I can modify the simulation cycle language to say that the solver = can evaluate this code 0 or more times, but the solution must not be = dependent on the number of times the section is evaluated. Variables = should be lightweight variables and reinitialized each time. Here is the problem: the sequential section may have undesirable side = effects for each evaluation (like opening files). So we might have to = restrict the things that can be done in this section to eliminate = problems. The alternate is to say "Caveat Emptor" and put the onus on the = model writer to make the model work correctly. This may result in = potentially non-portable models -- and we can note this in the LRM. KB: Perhaps we can get consensus on this point by Email? (no conclusion) EC: People have asked me if the language will support the specification of = partial derivatives. This is not one of the design objectives. As long = as we can support the stuff SPICE can do (and partial derivatives are not = needed for this), we don't need partial derivatives. HK & RT: Agree (no disagreements on this point) EC: Can we summarize conclusions? RT: Would like to submit another white paper. HK: We should continue to work on both AV's and KB's papers. EC & KB: Want a decision, this is a critical path and there is significant = effort involved. Can we decide now? (overwhelming consensus to postpone decision till later) DD: Try phone conference to come to a consensus. EC: We need to come to a conclusion soon. DAC is only 9 weeks away. = Suggest we try to work it out with Email. What is a reasonable time = frame? AV: Suggest we combine my paper with KB's paper. EC: Do we at least have a consensus on the use of simple and conditional = simultaneous constraints used in the same place as concurrent statements? Agree: DD, KB, EC, LY, OFB, AV, CHH Abstain: HK, RT Absent: KW & JMB EC: This is a consensus since there are no 'no' votes. DD: Motion that AV and KB work out the details of combining these two = papers. (This motion was approved, and most participants want to see the result = before sending it out to the general 1076.1 reflector) ACTION ITEM: KB & AV will consolidate two proposals and submit for review = within 2 weeks. One week will be allocated for review. EC: Try to not make objections for minor details since this needs to be = approved as soon as possible so we can send a complete package to the = 1076.1 reflector. ACTION ITEM: Paper authors to update their slides to reflect changes we = discussed. (SUMMARY: The committee generally agrees on the need for simple = simultaneous statements as well as conditional simultaneous statements at = the same level as concurrent statements. The discussion focused on how to = implement sequential code: in a new declarative region called a Relation = as proposed by Alain, or in a block as proposed by Ken. Richard Trihy = also expressed a desire to write another white paper presenting a third = alternative. The committee approved a motion to have Ken and Alain publish a paper = based on the common points of their two papers.) ----------------12:05 Lunch >>>>>Next meeting schedule and current status of white papers RT: Can we discuss the details of the next meeting? EC: Plan on having a meeting during DAC. There will probably be a working = group meeting. Can we meet the entire week with one day off for the show? DD: One day is not enough time for the show. Many have other commitments = at DAC. How about an overlapping daily schedule? EC: Will work out arrangements and let us know. RT: Will Serge or JJ from Anacad come? KW: Undoubtedly at least one will come to DAC. (1:40, JMB returns from DASC plenary session.) EC: Issues that need to be addressed in white papers: Time - KB Quantities and subprograms - JJ Tolerances - DD Mixed netlist - EC Elaboration - KB Quantity interface elements to a subprogram - KB Implicit quantities (Q'integ, ddt, delayed) - KB Alternative formulation - RT Update solvability (input set, output set, implementability) - EC KB: please explain input/output set. EC: It's a question of optimization. Can a system identify output = variables vs. things that are constants during evaluation - this is just a = proof of implementability. If not possible, we may need variables to = allow users to optimize which things are not in the system matrix. RT: We may not need "free quantities" if we can use variables as I = discussed. EC: Disagree. KB: If we use RT's implementation, it puts a significant burden on the = user to distinguish variables from quantities. RT: Disagree. KB: What is the priority of all these issues? How about Interpretation = Domain? KB: Let's change the Interpretation Domain to Frequency Domain since = transient and DC are already discussed in other places. No need to be too = generic. OFB: A separate code section to define behavior during different analysis = runs is needed in this modeling language. For example, the frequency = behavior of a digital component could be easily modeled using this = concept. Also, if we make this behavior broad enough, it can be used to = support other analysis types in the future that we cannot imagine now. = Perhaps it should even be user defined. KB: Sounds like a configuration document. However AC may require some = kludging -- let's not get stuck in the details right now. EC: Switching architecture's from analog to digital is NOT one of the = design objectives, but let's make sure we don't block the capability. OFB: I don't want to change topology. It's just a different analysis, so = a configuration document is not the right place to address the problem. = Unfortunately, my original proposal from a year or two ago has already = been significantly altered from what I wanted. KB: We can already do what you want with a conditional configuration = document. Just specify what it is that you want to accomplish. JMB: If you want to switch from one representation to another dynamically, = using a configuration document is not possible. AV: HDL-A can dynamically switch from the transient representation if the = AC representation is not available. EC: Argues that configuration document is already sufficient, don't need = to add other mechanisms. (Post meeting note added for clarity: Ernst does = not think that a configuration document is sufficient to deal with the = frequency domain issues, and thinks that the issue may need further = investigation.) AV: We need to investigate the problem. EC: Let's prioritize the white papers. Quantities 1 A * Time 1 * Solvability 1 * Quantities in subprograms 1 Mixed mode 1 A Elaboration 1 Frequency domain 2 Tolerances / sim ctrl 2 Initialization 1 * Environment 1 Statistical 3 Mixed netlist 1 Relation / Simult stmt 1 A * SPICE issues 2 * Dimensions 4 Analog subprogram (Serge) 4 1 =3D Highest Priority A =3D Provisionally approved * =3D Work needed/ critical AV: Mixed netlist should be a high priority EC: Yes, but not currently in the language. How can we support it? OFB: When all the 1's except for solvability and environment are done, = validation effort can begin. (General discussion of tolerance) LY: Suggest attaching a tolerance to each quantity rather than to each = nature. EC: Would like to see theoretical work on tolerances mapped to a white = paper. KB: Can use attributes to hang stuff like tolerance on to. An ad hoc = implementation would be to allow each implementation to hang different = stuff on to help define convergence and tolerances. EC: What about limiting issues: Example is a diode; too large a step can = cause the current to exceed limits. KW: This is a problem related to the design objective of being able to do = anything that SPICE does. KB: These issues are a kind of validation of the language. RT: Spectre has step limiting built in - Nagel's thesis - works for = exponential. DD: Frequency analysis is a must - should be higher than a 2. EC: Level 2 is not a cut line. CHH: Also DCOP is very important. EC: That's covered in the initialization paper. (SUMMARY: The next meeting will be associated with DAC. Committee = members expressed a concern that they will have commitments at DAC that = will cause them to miss segments of the next LAT meeting. Ernst will = investigate meeting options and propose a schedule. Several papers were identified as priority 1. Validation chair = Oliver Fischer-Binder said that if all priority 1 white papers were done, = the validation committee could begin work in earnest.) -----------Break 3:15 >>>>>Solvability paper Ernst Christen EC: Spice issues or solvability still left on the table. DD & KB: want to go over solvability paper. EC: Mode of interface quantity can be in or out. * Mode "in" indicates that the block does not provide additional = constraints * Mode "out" indicates that the block provides an additional constraint = for the quantity set * Initial values can only go in "in" modes * Only Interface quantities with "out" & initial values can be left = unconnected. * Formal out requires an actual out or local declared quantity. EC: needs to work on these rules. EC: The number of constraints in each hierarchical collection must be = equal to: + the number of free quantities in any block + the number of basic through quantities. + The number of basic interface quantities with mode out - The number of basic quantity associations where the formal has mode out. JMB: Need to be able to support model development where all constraints = are not yet developed. May have declared things that are not used. Can't = disallow the simulator from working. KB: There must be a set of rules that can be developed that define this = set of dynamic matrix changing. JMB: The proposal by EC also violates VHDL usage which allows us to = declare things and not use them. KB: Declaring branch quantities that are not used doesn't make sense. LY: Agrees with JMB that you must be able to declare things and not use = them. (SUMMARY: Considerable disagreement with Ernst from the committee. A = formulation for static checking of the number of equations vs. the number = of quantities will probably have to be significantly rewritten to obtain = approval from the committee.) -----------end of discussion due to imminent closure of conference room. >>>>>Review of Meeting EC: Let's review what we did well this time, and what could be improved: Positive items: + Less emotional arguments than in previous meetings + White papers done on time. + Finished each day at 5:00 + Calling for closing discussion & polling of each member + Discussion of alternatives Items that could be improved: - Check other commitments early to avoid schedule conflicts - Minimize other commitments during these sessions - Allocate more time to discuss papers - Use alternate facilitators when presenter is the LAT chair - Set meeting objectives & priority better. (SUMMARY: Most committee members felt that the meeting was productive, = and that we had accomplished many of the goals from the last LAT review = session. The main negative item was the loss of an entire day due to a = schedule snafu with VIUF) From 1076-1-request@sicmail.epfl.ch Thu Apr 27 11:00:47 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Thu, 27 Apr 95 11:00:35 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Thu, 27 Apr 95 11:00:30 -0400 Received: from c3imac12.epfl.ch by sicmail.epfl.ch with SMTP (PP) id <15729-0@sicmail.epfl.ch>; Thu, 27 Apr 1995 15:50:59 +0200 X-Sender: vachoux@c3i9.epfl.ch Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 27 Apr 1995 15:52:02 +0100 To: 1076-1@epfl.ch From: alain.vachoux@leg.de.epfl.ch (Alain Vachoux EPFL-LEG/C3i) Subject: Vote on DOD 2.1 All, As decided during the last 1076.1 working group meeting in San Diego, I would like to request you to vote on the Design Objective Document (DOD version 2.1 dated Nov 8 1994). The DOD was completely reorganized in early of 1994. Version 2.1 takes into consideration the comments made by the working group, both on the reflector and at working group meetings (San Diego, June 1994, Grenoble Sept. 1994, Washington DC, Nov. 1994). Since no major objections have been made, it is now time to proceed to a formal approval step, to have a stable base for the language design, validation and documentation tasks. Another supporting document, the Design Objective Rationale (DOR) document, was also written in parallel. It does not bring anything new to the objectives, but it rather describes and justifies the design objectives in more details than the DOD actually does. It is then not proposed to vote on the DOR document, since the DOD is the essential one. Draft versions of these documents are available in our ftp repository (nestor.epfl.ch, 128.178.50.20) in the directory pub/vhdl/standards/ieee/1076.1/requirements in the files DOD_v2.1_draft.txt and DOR_v1.1_draft.txt respectively. I can send these documents through e-mail upon request for those with no ftp access. The question is then: Do you approve of the Design Objective Document (DOD), version 2.1, 8 nov 1994, as the basis for the first release of VHDL-A? The deadline for the vote is Friday, May 19. Please send your vote to me (alain.vachoux@leg.de.epfl.ch). Alain Vachoux From 1076-1-request@sicmail.epfl.ch Fri Apr 28 13:14:46 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Fri, 28 Apr 95 13:14:32 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Fri, 28 Apr 95 13:14:19 -0400 Received: from psi.com by sicmail.epfl.ch with SMTP (PP) id <14061-0@sicmail.epfl.ch>; Fri, 28 Apr 1995 17:46:19 +0200 Received: from analogy.com by psi.com (8.6.10/2.1-PSI/PSINet) id LAA12205; Fri, 28 Apr 1995 11:46:02 -0400 Received: from miller.analogy.com by analogy.com (4.1/Shared_Spool_1.3) id AA04395; Fri, 28 Apr 95 08:45:02 PDT Received: from satyr.analogy.com by miller.analogy.com (4.1/SMI-3.2) id AA25609; Fri, 28 Apr 95 08:45:02 PDT Received: by satyr.analogy.com (5.0/SMI-SVR4) id AA29655; Fri, 28 Apr 1995 08:45:01 -0700 Date: Fri, 28 Apr 1995 08:45:01 -0700 From: christen@analogy.com (Ernst Christen) Message-Id: <9504281545.AA29655@satyr.analogy.com> To: 1076-1@epfl.ch Subject: LAT Progress Report Content-Length: 2490 Language Architecture Team Progress Report ========================================== The 1076.1 Language Architecture Team (LAT) has made substantial progress towards the definition of the VHDL extensions to support the description and simulation of continuous time (commonly referred to as analog) and mixed continuous/discrete time (mixed analog/digital) systems. The work of the LAT is documented in a series of white papers. Each white paper addresses one aspect of the 1076.1 language architecture. A white paper may include the results of an analysis of an issue, together with conclusions and recommendations, or it may document semantics, provisional syntax and rationale specific to its topic. In this latter case the paper will use a formal and concise language that eventually can be used almost verbatim to update the LRM. White papers are reviewed at LAT meetings and revised by the author before approval by the LAT. The process of approval is documented in a separate LAT policy document which was sent to the reflector earlier and is now available in the ftp archive. Approved papers are released for circulation to the Working Group at large. The LAT has identified 16 topics that require analysis. 11 white papers exist in various states of completion, covering 10 of the topics. Of these, 7 have been discussed at LAT meetings, and 3 have been provisionally approved. A summary and synthesis of the issues covered in the white papers is contained in the paper entitled VHDL-A language architecture, which serves as a tutorial introduction to the work as a whole. This package includes the following papers: VHDL-A Language Architecture Quantities and Terminals Mixed-Mode Simulation Simultaneous Statements I will send them in separate messages. Two of the white papers include examples whose purpose is to illustrate (not to define!) the semantics defined in the white papers. The examples use provisional syntax which is consistent with the defined semantics. Please note that this syntax is not final, nor are the semantics: the material reflects the current LAT thinking in the areas where consensus has been reached. The same material as included below was presented at the WG meeting in San Diego 3 weeks ago, which resulted in some good discussions. We expect that the publication of the LAT approved documents will also start a discussion on the reflector, and we are interested in getting your feedback. Ernst Christen LAT chair From 1076-1-request@sicmail.epfl.ch Fri Apr 28 13:21:40 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Fri, 28 Apr 95 13:21:22 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Fri, 28 Apr 95 13:15:54 -0400 Received: from psi.com by sicmail.epfl.ch with SMTP (PP) id <14206-0@sicmail.epfl.ch>; Fri, 28 Apr 1995 17:55:18 +0200 Received: from analogy.com by psi.com (8.6.10/2.1-PSI/PSINet) id LAA12302; Fri, 28 Apr 1995 11:47:35 -0400 Received: from miller.analogy.com by analogy.com (4.1/Shared_Spool_1.3) id AA04408; Fri, 28 Apr 95 08:46:35 PDT Received: from satyr.analogy.com by miller.analogy.com (4.1/SMI-3.2) id AA25621; Fri, 28 Apr 95 08:46:34 PDT Received: by satyr.analogy.com (5.0/SMI-SVR4) id AA29675; Fri, 28 Apr 1995 08:46:34 -0700 Date: Fri, 28 Apr 1995 08:46:34 -0700 From: christen@analogy.com (Ernst Christen) Message-Id: <9504281546.AA29675@satyr.analogy.com> To: 1076-1@epfl.ch Subject: Simultaneous Statements Content-Length: 11255 Simultaneous Statements ======================= 0. Revision History 1.3 18 Apr 95 Ken Bakalar Change definition of null statement; small clarifications to rationale and introduction; add open issues section. 1.2 12 Apr 95 Alain Vachoux Minor corrections on syntax from LAT review; add null_statement to case alternative. 1.1 8 Apr 95 Ken Bakalar, Alain Vachoux Consolidated with only simple, conditional and selected simultaneous statements. 1.0 28 Mar 95 Does not include syntax and static semantics of procedural statement. 1. Introduction This paper defines the members of a new class of VHDL behavioral statement, the simultaneous statements. The simultaneous statements include at least three forms; the simple simultaneous statement and the conditional and selected simultaneous statements ("if" and "case" forms). A forth form, the "relation" or "simultaneous procedural statement" is under discussion and will be added in a later draft of this document. Simultaneous statements are allowed in the statement part of a block, just like concurrent statements. Each simultaneous statement represents an hypothesis that can be tested by conventional VHDL execution and expression evaluation. If the solver has successfully established an analog solution point then each such hypothesis is true. The order of testing, and so the order of the simultaneous statements, has no effect on the result. An analog solution point must also pass tests derived from the implicit constraints due to conservation semantics and quantity and port associations. These constraints are dealt with elsewhere. 2. Definitions 2.0 Simultaneous Statements [modify 1.2.1-240 to add simultaneous statements to the things allowed in an architecture statement part] architecture_statement ::= simultaneous_statement | concurrent_statement architecture_statement_part ::= { architecture_statement } [modify 9.1-43 similarly, for block statements] block_statement_part ::= { architecture_statement } [modify 9.7-641 similarly, for generate statements] generate_statement ::= generate_label : generation_scheme "generate" [ { block_declarative_item } "begin" ] { architecture_statement } "end" "generate" [ generate_label ] ";" [Simultaneous statements go in a new section, perhaps section 9A] Simultaneous statements are used to express explicit differential and algebraic equations that constrain the values of the quantities of a model. simultaneous_statement_part ::= { simultaneous_statement } simultaneous_statement ::= simple_simultaneous_statement | simultaneous_if_statement | simultaneous_case_statement | simultaneous_null_statement The evaluation of a simultaneous statement generates a collection of characteristic values that are associated with that statement. If the analog solver has successfully choosen an analog solution point then each characteristic value will be close to zero when the statement is evaluated. The evaluation of a simultaneous statement part consists of the evaluation of its simultaneous statements. 2.1 Simple Simultaneous Statement The evaluation of a simple simultaneous statement creates a collection of characteristic values. simple_simultaneous_statement ::= [ label ":" ] expression "==" expression ";" For the evaluation of a simple simultaneous statement the expressions are first evaluated. The base type of each expression must be the same natural type. If the type of the expressions is a scalar type then the statement has a single characteristic value which is the difference between the value of the right-hand expression and the value of the left-hand expression. If the type of the expresssions is composite, then there must be a matching scalar subelement of the right-hand value for each scalar subelement of the left-hand value, and the characteristic values are the differences of the matching scalar subelements of the expression values. 2.2 Simultaneous If Statement A simultaneous if statement selects for evaluation one or more of the enclosed sequences of simultaneous statements depending on the value of one or more conditions. simultaneous_if_statement ::= [ if_label ":" ] "if" condition "use" simultaneous_statement_part { "elsif" condition "use" simultaneous_statement_part } [ "else" simultaneous_statement_part ] "end" "use" [ if_label ] ";" For the evaluation of a simultaneous if statement, the condition specified after if and any conditions specified after elsif are evaluated in succession (treating a final else as elsif TRUE use) until one evaluates to TRUE or all conditions are evaluated and yield FALSE. If one condition evaluates to TRUE, then the corresponding simultaneous statement part is evaluated; otherwise, none of the simultaneous statement parts is evaluated. 2.3 Simultaneous Case Statement A simultaneous case statement selects for evaluation one of a number of alternative simultaneous statement lists; the choosen alternative is defined by the value of an expression. simultaneous_case_statement ::= [ case_label ":" ] "case" expression "use" simultaneous_alternative { simultaneous_alternative } "end" "use" [ case_label ] ";" simultaneous_alternative ::= "when" choices => simultaneous_statement_part The expression of the simultaneous case statement, the expressions of the choices of the simultaneous alternatives and the case label must follow the rules of Section 8.8 for the corresponding parts of the sequential case statement. The evaluation of a simultaneous case statement consists of the evaluation of the expression followed by the evaluation of the choosen simultaneous statement part. 2.4 Simultaneous Null Statement The evaluation of a simultaneous null statement creates no characteristic values. simple_simultaneous_statement ::= [ label ":" ] "null" ";" 3. Rationale The description of continuous-time (or continuous-frequency) behavior in VHDL-A consists in the formulation of differential algebraic equations (DAEs) involving the names of quantities and other conventional VHDL objects. Some equations are denoted by the simultaneous statements of the source code, some are a consequence of the structural composition of design units the coder has created, and some are a consequence of the conservation laws defined on terminals. All these equations are ultimately merged in some way to build the system of equations the analog solver will use to perform the requested analysis. A straightforward implementation might choose to enter the equations of the text one-for-one into the rows of a tableau formulation. More efficient algorithms (formulation methods) optimize the sparse system of equations so described and create an equivalent system of smaller size. In that case, the quantities of the user's model will not correspond one-for-one to the state variables of the formulation, and some quantities will be calculated in either a pre- or post-processing step rather than by iterative solution. No particular formulation method is assumed in the definition of VHDL-A. 3.1 Characteristics of Simultaneous Statements Consider the simple simultaneous statements of the form f(qm,..qn)==g(qi,..qj) [the same q can appear on both sides] In general, f and g can be arbitrary VHDL expressions of the same natural type (a natural type is either a floating-point type or it is a composite with scalar subelements of a floating-point type). The meaning of the expressions is described by the existing expression evaluation and sequential execution semantics of VHDL. The result of an evaluation is a single value for each expression. If the expressions are composite we ask that the values have a matching scalar subelement on the left for each scalar subelement on the right. Then the statement is equivalent to a sequence of statements equating those scalar elements individually. We know that the quantities have only a finite number of discontinuities. In general, we can know nothing else about these expressions, and in all other respects we must treat them like black boxes. There is no point during the mixed-mode simulation cycle which calls for the evaluation of the expressions of a simultaneous statement. The omission was deliberate; we do not want to restrict the class of simulator algorithms that might be used in a VHDL-A implementation by specifying when or how often the expressions must be evaluated. This is in distinct contrast to digital processes. The execution of the statements of a digital process is explicitly called for as part of the simulation cycle. Even though we don't specify how or when the solver processes the simultaneous statements, we must still say in the LRM how to tell if the solver has succeeded in interpreting the statements correctly. 3.2 The Hypothetical Evaluation Test In general we can say no more than this about simultaneous statements; that the values of the quantities have been successfully established by the solver when, for each such statement, the difference of the values resulting from the evaluations of the expressions (the characteristic value or values) _would be_ close to zero if the expressions were evaluated. Call this a "hypothetical evaluation test" since it confirms the hypothesis that the solver has successfully determined the analog solution point. The semantics of simultaneous statements is thus defined in terms of a necessary condition on the resulting analog solution point -- the hypothetical evalution test of each simultaneous statement. 3.3 An Alternative Semantics One alternative way to establish the meaning of simultaneous statements is to provide a set of rewrite rules specifying how to translate each combination of statements into another language with well defined semantics. In the case of the analog extensions to VHDL, the obvious choice for the target language is the mathematical language of differential and algebraic equations. But we run into problems when trying to specify the rewrite rule for an arbitrary VHDL expression that includes user defined function calls or operators on values of user-defined types. It is only in special cases that we can do that successfully, e.g., "calls to VHDL function IEEE.VHDL_A.SIN(X) are to be rewritten as mathematical references to the sine function", "references to STD.STANDARD."+"(A,B) with A,B of type STD.STANDARD.REAL are to be rewritten as mathematical references to addition". The fact that we cannot identify all of the parts of the expressions f and g with well-understood mathematical entities ("+" and "sin", for example) means that we cannot perform the required translation in the general case. 4. Open Issues The description of continuous behavior as an ordered set of sequential statements (the procedural part of a "relation" or the "simultaneous procedural statement") is a design objective that has still to be satisfied. A complete solution is currently under investigation and will be eventually included in this white paper. From 1076-1-request@sicmail.epfl.ch Fri Apr 28 13:34:20 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Fri, 28 Apr 95 13:34:05 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Fri, 28 Apr 95 13:26:46 -0400 Received: from psi.com by sicmail.epfl.ch with SMTP (PP) id <14495-0@sicmail.epfl.ch>; Fri, 28 Apr 1995 18:07:01 +0200 Received: from analogy.com by psi.com (8.6.10/2.1-PSI/PSINet) id LAA12200; Fri, 28 Apr 1995 11:45:51 -0400 Received: from miller.analogy.com by analogy.com (4.1/Shared_Spool_1.3) id AA04404; Fri, 28 Apr 95 08:46:15 PDT Received: from satyr.analogy.com by miller.analogy.com (4.1/SMI-3.2) id AA25618; Fri, 28 Apr 95 08:46:14 PDT Received: by satyr.analogy.com (5.0/SMI-SVR4) id AA29670; Fri, 28 Apr 1995 08:46:13 -0700 Date: Fri, 28 Apr 1995 08:46:13 -0700 From: christen@analogy.com (Ernst Christen) Message-Id: <9504281546.AA29670@satyr.analogy.com> To: 1076-1@epfl.ch Subject: Mixed-Mode Simulation Content-Length: 39676 Mixed-Mode Simulation ===================== 0. Revision History 1.0 As presented to LAT, February 1995 2.0 Revised to reflect comments of LAT. Redefined implicit signals. Add concurrent break statement. Add language concerning use of break set. 3.0 4/20/95 Minor corrections to defintion. Major reformulation of rationale. Include examples. 1. Introduction The analog solver is the conceptual agent that finds solutions for the differential-algebraic equations of a VHDL-A model. This paper describes what the solver is required to do and how the execution of the solver is synchronized with the execution of ordinary VHDL processes. TABLE OF CONTENTS: 1. Introduction 2. Definitions 2.1 Break statements 2.2 Execution of a Mixed-Mode Model 2.3 Execution of the Analog Solver 2.4 Mixed-Mode Initialization 2.5 Mixed-Mode Simulation Cycle 3. Rationale 3.1 The Mixed-Mode Simulation Cycle 3.2 Initialization 3.3 Potential Optimization of the Simulation Cycle 3.4 The Implicit Signals Q'Cross(E) 3.5 D/A Conversion 3.5.1. Prospective Examination of Signals? 3.6 A/D Conversion 3.7 Breaks 3.7.1 The Break Statement 3.7.2 Detecting Discontinuities 3.7.3 Break Sets 4. Examples 2. Definitions The definitions are written in the form of text to be inserted into the VHDL 1076-1993 LRM. Paragraphs enclosed in brackets set the context and are not part of the definition itself. A reference in the form 12.6-435 is to the IEEE 1076-1993 Language Reference Manual, Section 12.6 at line 435. 2.1 Break statements [at 8-5 -- add break statement to the list of sequential statements] sequential_statement ::= ... | break_statement [at 8.1-59 -- add the concurrent break statement to the list of users of the rules of section 8.1] ...and concurrent break statements. [after 8.13-442 -- add the definition of the break statement in a new section 8.14] A break statement indicates that a break in continuity of some quantity has occurred. It may also specify reset values for quantities. The effect is conditional if the statement includes a condition. break_statement ::= [label":"] "break" [break_list] ["when" condition] break_list ::= break_element {"," break_element} break_element ::= quantity_name "=>"expression In each break element, the name must denote a quantity and the named quantity must be of the same base type as the expression. For the execution of a break statement the condition, if present, is first evaluated. A break is indicated if the value of the condition is TRUE or if there is no condition. If a break is indicated, the driver of the implicit break signal is assigned the waveform TRUE after 0 sec and then each break element is evaluated in the order in which the elements appear. For the evaluation of a break element, the quantity name and the expression are first evaluated. A design is erroneous if it depends on the order of this evaluation. Then the the named quantity and the associated value are added to the break set for the current simulation cycle (see 12.6.x). A model that exhibits a discontinuity in a quantity at some time T and does not execute a break statement at T is erroneous. [after 9. 7-672 -- add the concurrent break statement in a new section 9.8] The concurrent break statement represents a process containing a break statement. concurrent_break_statement ::= [label ":"] "break" [break_list] ["on" sensitivity_clause] ["when" condition] For any concurrent break statement there is an equivalent process statement. The equivalent process statement has a label if and only if the concurrent break statement has a label; if the equivalent process statement has a label it is the same as that of the concurrent break statement. The equivalent process statement also does not include the reserved word postponed, has no sensitivity list, an empty declarative part, and a statement part that consists of a break statement followed by a wait statement. If the concurrent break statement includes a condition then the break statement of the equivalent process statement contains a when clause with the same condition as the concurrent break statement; otherwise the break statement does not contain a when clause. If the concurrent break statement includes a break list then the break statement contains the same break list; otherwise the break statement does not contain a break list. If the concurrent break statement has a sensitivity clause then the wait statement of the equivalent process statement contains the same sensitivity clause; otherwise, if there exists a name that denotes a signal in the Boolean expression that defines the condition of the break, then the wait statement includes a senstivity clause that is constructed by applying the rule of section 8.1 to that expression; otherwise the wait statement contains no sensitivity clause. The wait statement does not contain a condition clause or a timeout clause. 2.2 Execution of a Mixed-Mode Model [ after 12.6-439 -- add new things to the list of signals maintained by the kernel process] ... and likewise for any prefix Q and value E, any signal Q'Cross(E), and for the implicit break signal. [add description of analog solver; define analog solution point] The analog solver is a conceptual representation of the agent that updates the values of the quantities of a model. The analog solver also updates the drivers of the implicit signals Q'Cross(E) of the model. The analog solver is said to determine an analog solution point at time T when it determines these values for time T. 2.3 Execution of the Analog Solver [before 12.6.4 -- define execution of the analog solver in a new section 12.6.x] The analog solver has successfully determined an analog solution point at time T when it has determined the value of each quantity such that the evaluation at time T of each simultaneous statement and implicit constraint would yield characteristic values close to zero. [Account for the processing of the break set. We have the ASP at Tc (it was calculated before the digital processes executed in the last cycle). Now we want to create a new initial point by combining the break set and the last ASP. This problem is closely related to the initialization problem, which remains unresolved in detail. The subtype check for the values in the breakset occurs here as well.] When the analog solver resumes at time Tc, if the driver of the implicit break signal is active .... Otherwise, when the analog solver resumes at time Tc it simultaneously resets Tn to a new value Tn' and determines a sequence of analog solution points for times Ti in the interval [Tc,Tn']. An implicit signal Q'Cross(E) is said to have toggled when Q-E>0.0 and Q'Cross(E)='0', or when Q-E<0.0 and Q'Cross(E)='1'. Tn' is the lesser of Tn and the least value in the interval [Tc,Tn] at which any signal Q'Cross(E) toggles. The times Ti must include Tn'. Next, the analog solver assigns the waveform not Q'Cross(E) after 0 sec to the driver of each signal Q'Cross(E) which has toggled. Finally, the analog solver suspends. Any evaluation of a name denoting a quantity at time T retrieves the corresponding value from the analog solution point at T. [after 12.6.3-581 -- add the implicit break signal, the signals Q'Cross(E) and their drivers to the things updated] In addition, the kernel process updates the values of each signal Q'Cross(E), and the value of the implicit break signal. [after 12.6.3-581 -- tell how to update the signals Q'Cross(E) and the implicit break signal] If the driver of any implicit signal Q'Cross(E) is active, then Q'Cross(E) is updated by assigning the current value of the driver to the variable representing the current value of Q'Cross(E) . If the driver of the implicit break signal is active, then the implicit break signal is updated by assigning the current value of the driver to the variable representing the current value of the implicit break signal. 2.4 Mixed-Mode Initialization [near 12.6.4 -- define mixed analog-digital initialization. This section is incomplete] 2.5 Mixed-Mode Simulation Cycle [before 12.6.4-646: The VHDL simulation cycle is modified to include executions of the analog solver before step a)] x) The analog solver is executed. (Tn may be reset as a result.) 3. Rationale In determining an analog solution point, we would like a VHDL-A simulator to closely approximate the results that would be obtained by an exact solution at each time to the differential-algebraic equations the modeler had in mind when he constructed the model. Some equations are denoted by the simultaneous statements of the source code. The rest, denoted by quantity and terminal associations, are a consequence of the structural composition of design units and the conservation laws defined on terminals. A rule for calculating certain characteristic values is provided for each denotation. The solver is required to determined the values of the quantities of the model such that the calculation of each of the characteristic values yields a result close to zero. The rules for calculating the characteristic values of a statement are in the white paper on simultaneous statements. The rules for calculating the characteristic values of implicit constraints arising from branch quantity declarations and from quantity and terminal associations are in the white paper on quantities and terminals. 3.1 The Mixed-Mode Simulation Cycle The analog solver executes at the beginning of each simulation cycle. Starting at Tc (where the last cycle ended), it advances time to Tn (where the next cycle will begin) while generating a sequence of analog solution points (ASPs) along the way. The solver must truncate the interval when some quantity Q crosses a threshhold E defined by a signal Q'cross(E). In that case, Tn is reset to a lower value Tn'. The ASP at Tn is the one that is visible to the processes that run in the simulation cycle that follows execution of the solver. ASPs at times other than Tn may be calculated for the purpose of displaying data to the end-user, but their number and times are not specified by the definition. No signal (not even a signal Q'Cross(E)) can change value between any two ASPs generated during a single invocation of the analog solver. If the solver resumes with Tc=Tn then the next simulation cycle will be a delta cycle and the solver needs to generate only a single ASP. In most cases no computation is necessary because the values of the ASP are identical to the ones generated at Tn the last time the solver ran. Recalculation is necessary if, for example, the DAEs required for solution have changed consequent to a change in the value of a signal, or if a new initial condition must be specified. A process indicates such a condition by executing a break statement, which has the effect of making the implicit break signal active. This topic is discussed at greater length later (see Breaks, below). We have excluded from the language the ability to make references to preceding ASPs; for example, there is no "Q'last_value" function. The value of such a function will vary from implementation to implementation, and perhaps between executions of the same implementation using different tuning parameters. The consequences of such references on modeling style and model portability prohibit their use. The modification required to the simulation cycle is modest. The analog solver may be viewed as a process that resumes at the beginning of each simulation cycle only if signal break is active or if Tc) of electrical; alias ground is electrical'reference; alias voltage_vector is electrical_array'across; alias current_vector is electrical_array'through; type real_vector is array (integer range <>) of real; end electrical_system; -- after Coston, W. Terry, "A Status Report on Analog HDLs", -- _ASIC and EDA_ (Nov 1994), p. 32. -- use work.electrical_system.all; entity amplifier is generic (gain, ugf, rin, iin, imax, sr , r0, soft: real); port (terminal vout, refer, vin, vinb, vp, vn: electrical); end amplifier; -- -- This model contains simultaneous conditional use statements, but -- the conditions are such that all quantities are continuous over the -- switch between equations; thus no "break" is required. -- library IEEE; architecture basic of amplifier is terminal Cout: electrical; constant c1: real := imax/(sr*1.0e6); constant gmnom: real := 2.0 * IEEE.math_real.math_pi * ugf * c1; constant r1: real := gain/gmnom; constant dvmax: real := imax/gmnom; -- -- The reader will find that diagraming these quantities as the edges of -- a directed graph on the terminals will aid in understanding the -- design. -- quantity Iinput through Vinput across vin to vinb; quantity Ivin through refer to vin; quantity Ivinb through refer to vinb; quantity Icout through Vcout across refer to cout; quantity Icout_vout through Vcout_vout across cout to vout; quantity Vvout_vp across vout to vp; quantity Vvout_vn across vout to vn; -- -- These non-branch quantities are used as temporaries in building up -- the equation for Icout -- quantity gain_current, dp_current, outstage_current: current; begin -- -- local terminal Cout Icout == gain_current + dp_current - outstage_current; Icout_vout == Vcout_vout/r0; -- -- input stage. Iinput == Vinput/rin; Ivin == iin; Ivinb == iin; -- -- gain stage. -- The following relationship must hold between gmnon,dvmax and imax -- to prevent a discontinuity in gain_current assert abs(gmnon*dvmax) = abs(imax); if Vinput > dvmax use gain_current == imax; elsif Vinput < -dvmax use gain_current == -imax; else gain_current == gmnom * Vinput; end use; -- -- dominant pole. dp_current == c1 * Vcout'dot + Vcout/r1; -- -- output stage limiting. -- outstage_current is zero when Vvout_vp=-soft or Vvout_vn=+soft -- so there is no discontinuity at the transition points if Vvout_vp > -soft use outstage_current == gmnom * (Vvout_vp+soft); elsif Vvout_vn < soft use outstage_current == gmnom * (Vvout_vn-soft); else outstage_current == 0.0; end use; end basic; library VHDL_A; use VHDL_A.mechanical.all; entity bouncer is end bouncer; -- -- The bouncing ball. When the ball hits displacement 0.0, the -- velocity instantaneously changes to the negative of its -- previous value. The break statement notifies the AK of this -- state of affairs. Air resistance is a force opposing the -- direction of motion. The pair of equations in the -- simultaneous use statement define a value for v'dot that is -- continuous at the cross over point v=0.0, so no break is -- required at that time and we can use the quantity v itself in -- the conditional without introducing any problems. -- (Package mechanical contains the missing types.) -- architecture ball of bouncer is quantity v: velocity := 0.0; quantity s: displacement := 10.0; constant g: real := 9.81; constant air_res: real := 0.1; begin break v => -v on s'cross(0.0)='0'; s'dot == v; if v >0.0 use v'dot == -g - v**2*air_res; else use v'dot == -g + v**2*air_res; end use; end ball; entity slipper is generic (mass: real := 1.0, slip: real := 0.001, stick: real := .01); port (quantity external_force, position: real); begin assert mass /= 0.0 report mass'instance_name & " must not be zero."; end slipper; -- -- A model for a block on a rough surface (after Eduard Moser, -- 8 dec 93). The block is stopped at time zero. It experiences -- the force external_force. If abs(external_force) becomes -- greater than "stick" the block begins to move. A force slip -- (due to kinetic friction) opposes the direction of motion while -- the block is in motion. If the velocity crosses 0.0 with -- abs(external_force) < stick then the block stops again. -- -- The conditional statement looks at signal stopped and quantity -- velocity. The cross-over condition on velocity does not -- introduce any discontinuity, but stopped does; hence, we break -- when stopped changes value. -- architecture brick of slipper is quantity effective_force, acceleration, velocity: real := 0.0; signal stopped: boolean; begin process begin state1: stopped <= true; wait on external_force'cross(stick), external_force'cross(-stick); state2: stopped <= false; wait on velocity'cross(0.0) until abs(external_force) < stick; end process; position'dot == velocity; velocity'dot == acceleration; acceleration == effective_force/mass; break on stopped; if stopped use effective_force == 0.0; elsif velocity>0.0 use effective_force == external_force - slip; else effective_force == external_force + slip; end use; end brick; entity ppendulum is generic ( M, L, D: real; -- mass, length and damping factor phip: real; -- angular position of pin LP: real; -- distance from origin of pin linear: boolean); -- use linear approximation? port (quantity phi:real); -- angle of pendulum end ppendulum; -- -- After Bretienecker, F. "Comparison 7: Constrained Pendulum", -- EUROSIM Simulation News Europe, No. 7 (Mar 1993), p. 29 -- -- The generic "linear" controls whether the motion of the -- pendulum is computed by an equation in linear or non-linear -- form. phi denotes the angle measured in radians counter- -- clockwise from the vertical position. The parameters M and L -- characterize the pendulum with mass M and length L. D is -- a damping factor. -- -- Assume the pendulum is swinging free to start. It may hit a -- pin positioned at angle phip with distance LP from the point -- of suspension. In this case the pendulum swings on with the -- position of the pin as the point of rotation and the -- shortened length LS=L-LP. The angular displacement phi -- is now defined with respect to the new point of rotation; -- therefore the angular velocity phi'dot is changed at position -- phip. architecture E of ppendulum is constant G: real := 9.81; constant LS: real := L-LP; quantity Lnow, phim: real; begin if linear use phim == phi; else phim == sin(phi); end use; if phi > phip use Lnow == LS; else use Lnow == L; end use; M*Lnow*phi'dot'dot == - M*G*phim - D*Lnow*phi'dot; break phi'dot => phi'dot * L/LS when phi'cross(phip)='1'; break phi'dot => phi'dot * LS/L when phi'cross(phip)='0'; end architecture E; -- -- An alternative architecture for the pendulum with precisely -- the same behavior. -- architecture H of ppendulum is constant G: real := 9.81; constant LS: real := L-LP; begin if phi'cross(phip)='0' and not linear use M*L*phi'dot'dot == - M*G*sin(phi) - D*L*phi'dot; elsif phi'cross(phip)='1' and not linear use M*LS*phi'dot'dot == - M*G*sin(phi) - D*LS*phi'dot; elsif phi'cross(phip)='0' and linear use M*L*phi'dot'dot == - M*G*phim - D*L*phi'dot; else M*LS*phi'dot'dot == - M*G*phim - D*LS*phi'dot; end use; -- process (phi'cross(phip)) begin if phi'cross(phip)='0' then break phi'dot => phi'dot * LS/L; else break phi'dot => phi'dot * L/LS; end if; end process; end architecture H; entity two_state is end two_state; -- -- After Houbak, Neils "Comparison 5: Two State Model", -- EUROSIM Simulation News Europe, No. 5 (Jul 1992), p. 31 -- -- In this model, signals of type real are used directly in the -- formulation of the system of equations. They look like -- constants to the analog solver. -- architecture simple of two_state is quantity y1, y2: real; constant c1: real := 2.7E6; constant c3: real := 3.5651205; signal c2,c4: real; begin y1'dot == c1*(y2+c2-y1); y2'dot == c3*(c4-y2); break on c2,c4; process begin s1: c2 <= 0.4; c4 <= 5.5; wait on y1'cross(5.8); s2: c2 <= -0.3; c4 <= 2.73; wait on y1'cross(2.5); end process; end simple; use work.electrical_system.all; entity siginteg is generic (vout_init: real := 0.0); port (signal dvdt: in real; terminal o1, o2: electrical); end entity siginteg ; -- -- Given a signal dvdt that is successive values of vout'dot, create a -- voltage across o1 to o2 equal to vout_init plus the integral of dvdt -- over time. -- -- architecture simple1 of siginteg is quantity vout:= vout_init across iout through o1 to o2; begin vout'dot == dvdt; break on dvdt; end simple1; -- architecture simple2 of siginteg is quantity vout across iout through o1 to o2; signal startv: voltage := vout_init; function RT(T: time) return real is begin return real(time'pos(T))/real(time'pos(sec)); end RT; begin -- dvdt must be initialized to zero to prevent a spike at time 0. -- dvdt'delayed changes in the same cycle as startv, thus avoiding -- the race condition on vout (which would produce a delta spike) -- that would occur if dvdt where used in place of dvdt'delayed. -- (dvdt changes in the cycle before startv). startv <= vout when dvdt'event; vout == startv + dvdt'delayed*RT(startv'last_event); break on startv; end simple2; use work.electrical_system.all; entity piecewise is generic (values: voltage_vector; times: real_vector); port (terminal o1, o2: electrical); -- Normalize directions and bounds of input arrays subtype tvrange is 0 to values'length - 1; alias V(tvrange) := values; alias T(tvrange) := times; end entity piecewise; -- -- Create a piece-wise linear voltage waveform across o1 to o2. -- V(i) are the end points of the line segments, and -- T(i) is the time that value is achieved. The waveform -- begins at time zero with V(0). T(0) is ignored. -- architecture simple of piecewise is quantity vout across iout through o1 to o2; signal dvdt: voltage := 0.0; begin vout'dot == dvdt; break on dvdt; process begin dvdt <= (V(1)-V(0))/T(1); for i in 1 to tvrange'right-1 loop dvdt <= transport (V(i+1)-V(i))/(T(i+1)-T(i)) after T(i)*sec; end loop; wait; end process; end architecture simple; use work.electrical_system.all; entity pieced_periodic is generic (values: voltage_vector; times: real_vector); port (terminal o1, o2: electrical); alias V(0 to values'length - 1) := values; alias T(0 to times'length - 1) := times; end pieced_cyclic ; -- -- Creates a piece-wise linear voltage waveform across o1 to o2. -- V(i) to V(i+1) are the end points of a line segment and -- T(i) are segment durations. The waveform -- begins at time zero with the segment V(0) to V(1) of duration T(0) -- and repeats starting with the segment V(V'right) to V(0). -- Durations are used in index order until they run out, then they are -- reused starting with T(0). -- architecture simple of pieced_periodic is quantity vout across iout through o1 to o2; signal dvdt: voltage := 0.0; constant imax := V'right; begin vout'dot == dvdt; break on dvdt; process variable delay: real := 0.0; variable j: integer := 0; begin for i in 0 to imax-1 loop dvdt <= transport (V(i+1)-V(i))/T(j) after delay*sec; delay := delay + T(j); j := j+1 mod T'length; end loop; dvdt <= transport (V(0)-V(imax))/T(j) after delay*sec; wait for delay*sec; delay := T(j); j := j+1 mod T'length; end process; end simple; From 1076-1-request@sicmail.epfl.ch Fri Apr 28 15:52:15 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Fri, 28 Apr 95 15:51:51 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Fri, 28 Apr 95 15:51:12 -0400 Received: from psi.com by sicmail.epfl.ch with SMTP (PP) id <16691-0@sicmail.epfl.ch>; Fri, 28 Apr 1995 20:55:59 +0200 Received: from analogy.com by psi.com (8.6.10/2.1-PSI/PSINet) id OAA21610; Fri, 28 Apr 1995 14:55:30 -0400 Received: from miller.analogy.com by analogy.com (4.1/Shared_Spool_1.3) id AA04398; Fri, 28 Apr 95 08:45:30 PDT Received: from satyr.analogy.com by miller.analogy.com (4.1/SMI-3.2) id AA25612; Fri, 28 Apr 95 08:45:30 PDT Received: by satyr.analogy.com (5.0/SMI-SVR4) id AA29660; Fri, 28 Apr 1995 08:45:29 -0700 Date: Fri, 28 Apr 1995 08:45:29 -0700 From: christen@analogy.com (Ernst Christen) Message-Id: <9504281545.AA29660@satyr.analogy.com> To: 1076-1@epfl.ch Subject: VHDL-A Language Architecture Content-Length: 31469 VHDL-A Language Architecture ============================ Revision History 0.1 Feb.24, 1995 Original version 0.2 March 10, 1995 Included comments from Ken Bakalar and Alain Vachoux 1.0 April 12, 1995 Modified sections 2.4. through 2.6. to reflect new results from 6th meeting of the 1076.1 Language Archi- tecture Team. Various minor modifications in other sec- tions. 1.0 Fundaments for VHDL-A --------------------------- 1.1 What is VHDL-A VHDL-A is the language currently being defined by the IEEE 1076.1 Working Group, one of the working groups of the VHDL Analysis and Standardization Group (VASG) of the Design Automation Standards Committee (DASC) of the Computer Society of the IEEE. VHDL-A intends to extend the VHDL language to support the description and simulation of continuous time behavior (commonly called analog) and mixed continuous/discrete time behavior (commonly called analog/digi- tal). 1.2 The VHDL Heritage Due to the fact that VHDL-A is not a new language, but an extension of an existing one, the development and definition of VHDL-A can build on the syntax and semantics of its parent VHDL (LRM). This is an advantage because VHDL already contains an extensive collection of features that are essential in a hardware description language, such as (incomplete list): o structural decomposition to support hierarchical description of designs (components, blocks) o functional decomposition (subprograms, processes, concurrent statements) o organizational decomposition (design units such as packages, entities, architectures) o encapsulation of behavior (entity/architectures/processes) o a well defined type system with strong typing However, the VHDL inheritance has also disadvantages because it con- strains certain things to be done in a particular way. For instance, it is not possible to declare an array object of some type: the VHDL way is to define an array type first and then an object of this array type. It is clear that it is virtually impossible to change undesirable character- istics of VHDL because of backward compatibility. Additionally, spe- cial care has to be taken when defining language extensions, in order to maintain the integrity of the VHDL language. 1.3 Design Objectives The requirements for VHDL-A are described in the VHDL-A Design Objective Document (DOD). This document has been compiled from the raw requirements submitted to the 1076.1 Working Group by a group of interested people. The DOD, together with the Design Objec- tive Rationale (DOR), also defines the scope of VHDL-A, and it drives the language extensions because these extensions must ultimately sup- port the design objectives. The DOD classifies the design objectives to be either "must have", "should have", or "desirable". Design objectives in the "must have" cat- egory are fundamental and cannot be compromised. "Should have" objectives describe useful functionality that provide significant benefits if met. Finally, "desirable" objectives enhance the usability and/or per- formance but are not essential. The goal of language design is then to meet all "must have" objectives, as many of the "should have" objec- tives as possible provided they are not too expensive, and as many of the "desirable" objectives as possible provided they come at little cost. 1.4 Guidelines for Language Design In order to get a common understanding of how the language extensions should be designed, the 1076.1 Working Group established, based on the recommendation of the 1076.1 Language Architecture Team (LAT), a set of guidelines derived from those used for the VHDL'93 restandard- ization. The following is a complete list of these guidelines, some of them including explanatory comments. o Upward Compatibility Exceptions: the new keywords o Preserve Strong Typing o Separate Declaration and Functionality Declaration before use Do not infer functionality from a declaration o Unification of Timing Semantics o Preserve Determinism o Preserve Generality Technology/methodology independence o Preserve Scope of VHDL (Gate to System) o Preserve intermixed abstraction levels Analog/digital behavioral/structural in same design unit. o Preserve Concurrency Simultaneous equations: stronger than concurrency o Preserve and Improve Consistency Define syntax and semantics as understandable as possible o Preserve and Improve Portability Quality of conformance to standard o No Application-specific Packages o Minimize Implementation Impact o Maximize Implementation Efficiency o Distinguish between the language, modeling and tool issues/aspects o Ease of use o Constructive rather than propositional definitions 1.5 Differential and Algebraic Equations Continuous time behavior is described by differential and algebraic equations (DAEs) which are solved simultaneously by an analog solver. Due to the scope of VHDL-A to only address lumped systems, the dif- ferential equations are all ordinary differential equations with time as the independent variable. It is therefore essential that VHDL-A be capa- ble of describing behavior in the form of simultaneous differential and algebraic equations. Conversely, the only way to describe continuous time behavior is by means of simultaneous DAEs. This implies that in order to cover any continuous time behavior, it is sufficient for VHDL-A to provide sup- port for DAEs, and no other mechanism is needed. Note that this state- ment does not include or exclude any particular form in which DAEs could or should be expressed. 2.0 Basic Language Architecture -------------------------------- 2.1 Quantities As discussed in section 1.5., continuous time behavior is described by a set of simultaneous DAEs. The unknowns in this set of equations are called quantities. Quantities are analytical functions of time, i.e. they are piecewise continuous with a finite number of discontinuities. The ana- log solver solves for the values of all quantities over time, by applying suitable algorithms to the system of simultaneous DAEs. In other words, quantities get their values not by assignment, but as a result of solving simultaneous DAEs. There is currently no VHDL object that uses a similar mechanism to get its value. Therefore, the quantity is a new value-bearing object intro- duced into the language. Quantities must be of a floating point type, which is the closest to getting a truly continuous value range. Specifi- cally, it is not possible to describe DAEs with unknowns of a discrete type, because discrete functions of time are not analytical functions. There are two kinds of explicit quantities: free quantities and branch quantities. Here we deal only with free quantities; branch quantities will be described in section 2.2. Free quantities are declared in the declara- tive part of an entity or block or among the interface declarations of a block. Interface quantities are called quantity ports, by analogy with sig- nal ports. Interface quantities have a mode, similar to the mode of an interface signal. Quantities declared in a block can be used locally in DAEs (see section 2.3.) to represent waveforms that are of local importance, for instance intermediate values used to build up a complicated expression, or the power dissipated in a resistor. Interface quantities can be used as inter- face objects of signal flow models, which include SPICE-like current- controlled sources. For instance, a signal flow model of a two-input adder has an entity with two interface quantities with mode IN and one interface quantity with mode OUT. A quantity association has the effect of constraining the two quantities to be equal. In addition to explicit quantities, the language includes a collection of implicit quantities. The derivative of any quantity with respect to time is an implicit quantity, and so is the integral over time of a quantity, from time zero to the current time. The language also defines an implicit quantity whose value is that of a given quantity at a fixed interval in the past (ideal delay). Other implicit quantities are described in section 2.2. 2.2 Conservative systems Although it is possible to describe the behavior of any physical system using just free quantities, the large class of systems with conservation semantics (e.g. KCL/KVL) merits special treatment for such systems, i.e. the definition of language semantics specifically for conservative systems. The benefit of this is a considerable simplification for writing models describing such systems, thereby increasing productivity and reducing the risk of errors. The model used to describe conservative systems uses a nodal perspec- tive. Specifically, a conservative system is considered to be represented as a (undirected) graph where the vertices in the graph are the nodes and the edges are the physical branches in the design, i.e. the branches where (in an electrical network) current is flowing. This model is close to the way designers think about their system. Note that there is no implication that an implementation use a nodal based formulation, i.e. the formulation method used to implement conservative system seman- tics can be different from the formulation that defines the semantics for conservative systems in VHDL-A. The value bearing-objects in conservative systems are branch quantities. They have all the characteristics of free quantities, except that they are declared differently. Branch quantities come in two flavors: across quan- tities and through quantities. Across quantities represent effort like effects such as voltage, temperature, or pressure. Through quantities represent flow like effects such as current, heat flow rate, or fluid flow rate. Typically, the constitutive equations of conservative devices are expressed by relating across and through quantities of one or several branches. For example, a resistor has a single branch, and its constitu- tive equation (Ohm's law) relates the voltage across (the across quan- tity) and the current through the resistor (the through quantity). Branch quantities are defined between two terminals, the plus terminal and the minus terminal of the branch quantity. Plus and minus terminals define a direction for the branch, which is useful, for instance, to under- stand in which direction a positive current flows. The terminal is the second new object introduced into the language. It can be declared in a block declarative part or among the interface declarations of a block. In the later case it is a terminal port. Terminals differ from other VHDL objects because they do not themselves have values. However, there is a particular implicit quantity associated with each terminal, called the ref- erence quantity of the terminal. In electrical systems that quantity is the voltage of the terminal with respect to ground. The value of an explicit branch across quantity is given by the difference of the reference quanti- ties of its plus and minus terminals, which in electrical systems is an aspect of Kirchhoff's Voltage Law. Each terminal also has a contribu- tion expression, which is another implicit quantity that is defined as the sum of all through quantities (with appropriate sign) that have the termi- nal as either the plus or minus terminal, plus the contribution expression of any terminal of a component or nested block that the given terminal is connected to. Terminals don't have types, but they have a nature, which is a composite of types. Specifically, a nature contains an across type and a through type. Natures can be defined for different disciplines, for instance elec- trical, thermal, hydraulic. There can be a whole collection of natures, all derived from the same simple nature, that allow to describe composite terminals. Natures derived from the same simple nature share the same reference terminal, which makes them compatible. However, natures for different disciplines are incompatible because they have different refer- ence terminals. The plus and minus terminals of a branch quantity must have compatible natures, and the across and through quantities get the across and through types, respectively, from the nature. A set of terminals is called a node. The set is created through terminal associations, and it includes at most one reference terminal. All termi- nals in a node must have compatible natures, and the values of their ref- erence quantities are constrained to be equal. In electrical systems this is a consequence of Kirchhoff's Voltage Law. The conservation expression of the node is the sum of the contribution expressions of all terminal in the node, and the semantics of the node constrain the value of the con- servation expression to be zero. In electrical systems this corresponds to Kirchhoff's Current Law. 2.3 Simultaneous statements As described in sections 1.5. and 2.1., continuous time behavior is described by a set of simultaneous differential and algebraic equations, with the quantities as the unknowns. The DAEs are composed from explicit constraints described in the text of a model, and implicit con- straints described by the semantics of the language. Examples of implicit constraints are the constraint on the value of the conservation expression of each node, or the constraint defining the value of across quantities, both described in section 2.2. Explicit constraints are mathematically of the form expression1 = expression2 where each expression is composed of unknowns (i.e. quantities) and knowns (e.g. constants, literals, signal values) and can include function calls. The quantities in the expressions can be explicit or implicit quanti- ties. The semantics of the constraint define that the values of both expressions be made equal, i.e. constraints are exact specifications. However, the solution of the simultaneous DAEs may yield values for the quantities that only approximate the exact specification, due to the inability to mu,erically solve nonlinear equations exactly. Examples for explicit constraints are the constitutive equations for a capacitor: charge = c*v i = dcharge/dt where charge, i and v are explicit quantities and dcharge/dt is an implicit quantity. Each mathematical constraint is represented in the language by one or more statements, using either an equational or a procedural style. Such statements can be effective conditionally, based on the outcome of a test. This allows to implement continuous time behavior differently in different regions of operation of a device. The language supports two kinds of simultaneous conditional statements, the simultaneous if state- ment and the simultaneous case statement. Their semantics are analo- gous to the semantics of the corresponding sequential statements, taking into consideration the simultaneous context. 2.4 Simulation cycle The VHDL simulation cycle defines the order in which different parts of the canonical simulator defined in the VHDL LRM are executed. The simulation cycle is the definition of a time domain simulation and con- tains, as one of its major parts, the algorithm defining how time advances during simulation. The VHDL-A simulation cycle assumes the existence of a unified model for time. The VHDL LRM defines time as a physical type, i.e. an integer multiple of 1 fs. While providing a constant absolute resolution, this is not sufficient for VHDL-A because in continuous time simula- tion, the relative accuracy of time is more important than the absolute accuracy. The details of the unified model for time are currently being investigated. The VHDL-A simulation cycle consists of the VHDL simulation cycle modified to include the execution of the analog solver. If the system model has no continuous time part the VHDL-A simulation cycle reduces to the VHDL simulation cycle. If there is no discrete time part it reduces to executing just the analog solver, unless discontinuities are involved. Within the simulation cycle the analog solver advances time from Tc to Tn, the next time of a digital event or process resumption. It does this by solving (integrating) the set of simultaneous DAEs that define the con- tinuous time part of the system model, at a sequence of time points between Tc and Tn. At any particular time a set of values for the quanti- ties is considered a solution if it closely approximates the exact mathe- matical solution of the DAEs. This can be tested by a hypothetical evaluation of all explicit and implicit constraints in the system of DAEs: the values of the expressions on the left and right hand side of all con- straints must be close. The analog solver may terminate prematurely (i.e. before Tn) if one of the quantities crosses a threshold between Tc and Tn. In this case the analog solver returns at the exact time of the earliest of any threshold crossing between Tc and Tn. The threshold crossing is reported as an event on an implicit signal: the signal changes its value at the time of the threshold crossing. Such signals have characteristics that are similar to those of S'TRANSACTION, except that their drivers are controlled by the analog solver. They are integral to the issue of A/D conversion, or more specifically, the conversion of a continuous time quantity to a dis- crete time signal. In addition to these implicit signals, the values of quantities may be read in processes and concurrent statements, and the simulation cycle guarantees that they always have the correct value. Conversely, the values of signals used in the formulation of DAEs are guaranteed to always be correct. The break statement is a new sequential statement which also comes in a concurrent form. Its purpose is to tell the analog solver when any dis- continuities have occurred in the model, which require a re-evaluation of the DAEs at that time. Discontinuities can occur, for instance, if a quantity is equated to a signal and the signal changes. The break state- ment also allows to specify new initial conditions for selected quanti- ties, in order to set up a new state of the system after the discontinuity. 2.5 Initialization, DC Simulation Before a time domain simulation as described in section 2.4. can start, all value bearing objects must be initialized. For some of them this hap- pens during elaboration (see LRM and section 2.6.), but others get their initial value during a phase called the initialization phase. This phase is well defined in the LRM for VHDL, but it must be extended to address the needs of continuous time and mixed continuous/discrete time sys- tems. The literature about the numerical solution of DAEs is based on the assumption that a consistent set of initial values for all unknowns (i.e. quantities) is available. These values must themselves satisfy the system of DAEs describing the system, and possibly other equations derived from the original set of DAEs [INIT]. For the continuous time part of a system the purpose of initialization is then to find a consistent set of val- ues for the quantities. Since for the purpose of initialization there are usually more unknowns than equations (a quantity and its time deriva- tive count as separate unknowns in this context), there are an infinite number of consistent value sets, unless initial conditions are used to restrict the solution space. One set of initial conditions of particular importance is that all time derivatives in the system be zero. In electrical systems the solution to this problem is called the DC operating point. It corresponds to the asymptotic solution over time of the system model, with stimulus held constant. The DC operating point is important to the designer because it can provide, among other things, biasing information and information about the average power dissipation in the system. It is also used as a linearization point for small signal frequency domain simulation (see section 2.7.). To provide equal utility, the DC operating point for continuous/discrete time systems with combinational discrete time part, can be defined to have the following characteristics: o the values of all quantities satisfy the DAEs o all dynamic effects have settled, i.e. time derivatives are zero o all processes have been executed until the drivers of all signals that are not stimulus signals are empty This definition will have to be modified to include synchronous systems. Note that some systems, for instance oscillators, do not have a DC oper- ating point. It is apparent that this definition requires the identification of stimulus, a concept that does not currently exist in VHDL. There are several issues related to this concept. First, the concept must be defined. Then, stimu- lus must be identified; most likely this will be done by the person writ- ing a stimulus model. Finally, a mechanism to control stimulus must be designed. The detailed semantics of initialization and DC simulation, including support for initial conditions, are currently under investiga- tion. 2.6 Solvability of VHDL-A Models The power and flexibility of VHDL-A opens the question under what conditions a solution to the system of simultaneous DAEs exists, and whether the solution is unique. In general it is important from the per- spective of user friendliness to be able to diagnose as many problems in a design as early as possible. Furthermore, these diagostics should be as specific as possible, pointing to the exact location of the problem (if possible). The investigations in this area are incomplete, but some results are available. A necessary condition for the existence of a solution of the system of simultaneous DAEs is that its Jacobian be non-singular. A weaker state- ment is that a system of simultaneous DAEs has no solution if its Jaco- bian is structurally singular (i.e. singular regardless of the values of the elements of the Jacobian). Both these statements imply that there must be an equal number of DAEs and unknowns. The number of explicit constraints that is required in a block hierarchy to guarantee an equal number of constraints and quantities in the fully elaborated design depends on the number of through quantities and free quantities declared in the block hierarchy and its interface. In general these rules can be applied at simulation time only, although in many interesting cases the detection of an insufficient number of constraints can happen earlier. The question whether the DAEs describing a system have a numerical solution can be answered only at simulation time. One aspect of (numerical) solvability has already been addressed in sec- tion 2.5., the issue of consistent initialization of the unknowns. Another issue is the index of the system of DAEs, which is a measure how "far" the DAEs are from a system of ODEs (whose index is 0). The results from the literature on the numerical solution of DAEs indicate that robust numerical solutions exist only for index 1 systems, and although many integration methods perform reasonably well for higher index sys- tems the results become more and more questionable as the index of the DAEs increases. Fortunately there are algorithms that allow to reduce the index of a system of DAEs [INIT]. 2.7 Support for Frequency Domain A frequency domain simulation consists of computing the spectrum at selected locations in a design as a function of frequency, given an input spectrum. Several algorithms are available for frequency domain simu- lation. The most important ones are: o time domain simulation, followed by FFT o harmonic balance o small signal AC simulation (like SPICE) While the first algorithm requires no special language support, it is also the most restrictive in the sense that it is difficult to define the input spectrum for the design in the time domain such that meaningful simu- lation results can be obtained. Harmonic balance and specifically small signal AC simulation are more flexible in this respect, but they require a small signal model and are therefore restricted to the continuous time part of the design. With the exception of stimulus, the small signal model of a design can be derived from the large signal (time domain) model of the system by linearizing the large signal model about the DC operating point. This process is similar to a Jacobian evaluation, but special treatment is given to time derivatives, integrals, and ideal delays. Furthermore, the small signal model is complex, yielding complex values for the spectrum, which means that in the frequency domain quantities have complex val- ues! Support for frequency domain simulation is currently being investi- gated. In order to define frequency domain stimulus two concepts are being considered. First, the concept of the interpretation domain allows to define different behavior for time domain, DC domain and frequency domain. Second, in order to support frequency dependent behavior an impure function returning the current simulation frequency must be defined. 3.0 Open issues ---------------- Although the language architecture described in section 2. appears quite complete, there are a number of issues that have been identified but not yet resolved or integrated into the architecture. The following is a list of these issues, with brief descriptions. 3.1 Math Package Support The IEEE 1076.2 effort is currently defining a package of mathematical functions for real and complex types. There are some open questions about how these functions are defined, for instance is the sin function implementing the mathematical sine function, or is it defined by the package body provided by the 1076.2 effort, which only yields 6 digits of accuracy. The information obtained from reading the 1076.2 docu- ments and from talking to the people involved is contradictory. This question is important in determining the Jacobian or the small signal model of the system: what is the derivative of the 1076.2 sin function? 3.2 Dimensional Analysis The DOD contains a desirable objective to support dimensional analy- sis. Given the complexity of the issue, the 1076.1 Working Group decided to postpone such support, and to only provide a mechanism that allows to annotate objects with units for display purposes. With new information becoming available, this decision has been contested, and an investigation has started to see whether it is possible to satisfy this design objective with little cost. If so, this would have implications on the type system in VHDL. 3.3 Statistical Modeling Support Support for statistical modeling (i.e. for Monte Carlo simulation and time series) is mentioned in the DOD in the context of interaction between tool and language. A preliminary investigation has shown that it may be possible to provide support for Monte Carlo simulation with the existing language features. Further investigations will have to verify that this is true and address the issue of support for time series. 3.4 Algorithm Band-Aids Unlike digital simulation, which is mostly based on integer arithmetic, continuous time simulation involves the solution of simultaneous DAEs over time. The algorithms used for this purpose usually include the iter- ative solution of nonlinear equations. Due to the finite dynamic range of floating point numbers on computers, these algorithms may cause over- flows to occur during iterations, although the final solution is well within the supported dynamic range, unless special precautions are taken to limit the amount of change of an unknown from one iteration to the next. It is unclear at this time how such limiting can be supported by VHDL- A, because the language does not specify any particular algorithm to be used. Further investigations are required that will also have to answer the question whether other algorithm band-aids should be supported. 3.5 Analog Simulation Points for Display Purposes The VHDL-A simulation cycle does not specify when and how the ana- log solver has to solve the simultaneous DAEs. All it says is that at any time a hypothetical evaluation of the constraints has to demonstrate that they are closely satisfied. State of the art codes for solving DAEs step through time using a variable step size, depending on some error crite- rion, and they make assumptions about the smoothness of the solution between any two time points. If the error criterion is always satisfied at the selected time points, these codes will take larger and larger time steps, which causes the smoothness assumption to be violated. It may therefore be advisable to provide some mechanism in the language to control time steps, in order for a tool to be able to display the simulation results correctly. 3.6 Complete Support for SPICE Concepts One of the VHDL-A design objectives is to provide a migration path for the large number of SPICE based designs and libraries currently in use. The issues resulting from this objective have been analyzed and docu- mented, but their consequences have not yet been incorporated in the language design. Specific issues that may need language support are: o references to a .MODEL in a hierarchical SPICE design o node collapsing o special values undefined, infinite 3.7 Tolerances As described in section 2.4. the analog solver is required to closely approximate the exact solution of the simultaneous DAEs. This is a rather vague statement, and it requires a redefinition of the guideline of portability that includes the inexact nature of continuous time solutions. The question is whether this redefinition requires the concept of toler- ances to be included in the language. The concern is that this concept may be tightly linked to a particular class of algorithm, which would violate one of the design objectives. 4.0 Issues not addressed ------------------------- The 1076.1 effort does not address the following issues. VHDL-A will not include any application specific packages such as packages defining the basic infrastructure (e.g. types, natures) for disci- plines like electrical or thermal, nor will it include a package defining a set of basic electrical parts (e.g. the SPICE set of parts). The 1076.1 effort focuses on the language extensions; such packages will have to be provided through other means. VHDL-A will not include support for the concept of the analog subpro- grams, a concept that has been discussed in one of the Language Exten- sion Specifications (LES) but that has been postponed through a decision of the 1076.1 Working Group. The analog subprogram would have provided some macro like capability and support for solving a dis- connected set of simultaneous equations, which could sometimes be useful to determine the values of constants. References DOD 1076.1 Design Objective Document DOR 1076.1 Design Objective Rationale LRM IEEE Standard VHDL Language Reference Manual 1076-1993 INIT C.C.Pantelides: "The Consistent Initialization of Differential- Algebraic Systems", SIAM J.Sci.Stat.Comput., vol.9, no.2, March 1988, pp 213-231 White papers discussed at Language Architecture Team meetings From 1076-1-request@sicmail.epfl.ch Fri Apr 28 15:56:33 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Fri, 28 Apr 95 15:56:25 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Fri, 28 Apr 95 15:54:50 -0400 Received: from psi.com by sicmail.epfl.ch with SMTP (PP) id <16711-0@sicmail.epfl.ch>; Fri, 28 Apr 1995 20:57:11 +0200 Received: from analogy.com by psi.com (8.6.10/2.1-PSI/PSINet) id OAA21653; Fri, 28 Apr 1995 14:56:29 -0400 Received: from miller.analogy.com by analogy.com (4.1/Shared_Spool_1.3) id AA04401; Fri, 28 Apr 95 08:45:49 PDT Received: from satyr.analogy.com by miller.analogy.com (4.1/SMI-3.2) id AA25615; Fri, 28 Apr 95 08:45:48 PDT Received: by satyr.analogy.com (5.0/SMI-SVR4) id AA29665; Fri, 28 Apr 1995 08:45:47 -0700 Date: Fri, 28 Apr 1995 08:45:47 -0700 From: christen@analogy.com (Ernst Christen) Message-Id: <9504281545.AA29665@satyr.analogy.com> To: 1076-1@epfl.ch Subject: Quantities and Terminals Content-Length: 43485 Quantities and Terminals ======================== 0. Revision History 1.0 As presented at LAT meeting 1/31/95 2.0 Revised to reflect LAT format rules. Revised to reflect new syntax and static semantics for quantity declarations following suggestions from ISAC. Rationale updated to reflect syntax and static semantics section. 3.0 Revised notion of contribution expression to include formal sources. Added interface terminals and quantities. Revised rationale to reflect changes to date. 4.0 "nature" replaces "natural"; quantity and terminal examples included. 1. Introduction This paper introduces definitions, syntax and static semantics for the quantity and the terminal, two new fundamental objects required for the extension of VHDL 1076-1993 to the analog and mixed-signal domain. TABLE OF CONTENTS: 1. Introduction 2. Definitions 3. Syntax and Static Semantics 3.1 Natures 3.1.1 Scalar Natures 3.1.2 Composite Natures 3.1.2.1 Array Natures 3.1.2.2 Record Natures 3.2 Declarations 3.2.1 Nature Declaration 3.2.2 Terminal Declaration 3.2.3 Quantity Declaration 3.3 Terminal and Quantity Ports 4. Rationale 4.1 Equations 4.2 Quantities 4.3 Types and Natures 4.4 Quantities and Dimension 4.5 Numerical Precision and Initial Values 4.6 Quantities in the Frequency Domain 4.7 Static Structural Semantics and Conservation 5. Examples 2. Definitions [New terms of art defined are, with regard to quantities: basic quantity, branch quantity, across quantity, through quantity, plus terminal and minus terminal, and quantity association; with regard to terminals: basic terminal, reference terminal, reference quantity, and contribution expression; and with regard to terminal associations: terminal association, formal terminal, actual terminal, free terminal.] A basic quantity represents a real variable in the set of simultaneous differential-algebraic equations denoted or implied by the text of a model. Some basic quantities are branch quantities. Each branch quantity is either an across quantity or a through quantity. A basic terminal is a set of branch quantities. Each branch quantity is a member of exactly two basic terminals called the plus terminal and the minus terminal of the branch quantity. Some basic terminals are reference terminals. Each basic terminal is associated with a single reference terminal. The reference terminal of a reference terminal is the terminal itself. Each basic terminal includes a reference quantity, which is an across quantity whose plus terminal is the given basic terminal and whose minus terminal is the reference terminal of the given basic terminal. Two basic terminals that share a reference terminal may enter into a terminal association. The basic terminals of a terminal association are distinguished as the formal terminal and the actual terminal. A terminal is a free terminal if it is not a reference terminal and does not participate as a formal in any terminal association. The plus contribution of a basic terminal is the sum of the through quantities whose plus terminal is the given basic terminal. The minus contribution of a basic terminal is the negative of the sum of the through quantities whose minus terminal is the given basic terminal. The expression representing the sum of the plus contribution of a given basic terminal, the minus contribution of that basic terminal, and the contribution expression of each formal terminal with which the given terminal participates as an actual terminal in a terminal association is the contribution expression of that basic terminal. Two basic quantities may enter into a quantity association. The following equations are implied by the text of the model: 1) an equation for each across quantity constraining it to be equal to the reference quantity of its plus terminal minus the reference quantity of its minus terminal, 2) an equation for each free terminal constraining the contribution expression of the free terminal to zero, 3) an equation constraining the reference quantities of the basic terminals of each terminal association to be equal to each other, and 4) an equation constraining the basic quantities of each quantity association to be equal to each other. 3. Syntax and Static Semantics {In section 4.3, we need to free the notion of object from the requirement to have a value (a terminal needs to be a non-value-bearing object) and expand the definition in 4.3.1 of "multiple-object declaration" to account for the multiple identifier lists of a branch quantity declaration. } 3.1 Natures A nature defines the structure of a terminal and its compatibility with other terminals. A nature also defines an across type and a through type (together, the branch types of the nature) which are used indirectly to define the types of branch quantities. Free quantities and other objects may also be declared to be of a branch type of a nature. 3.1.1 Scalar Natures A scalar nature definition defines a scalar nature and the branch types of the scalar nature. scalar_nature_definition ::= type_mark "across" type_mark "through" The two type marks are, respectively, the across type and through type defined by the scalar nature. The type marks must denote floating-point types. The simple nature of a scalar nature is the nature itself. 3.1.2 Composite Natures A composite nature definition defines an array or record nature and the branch types of the nature. composite_nature_definition ::= array_nature_definition | record_nature_definition A terminal of a composite nature represents a collection of basic terminals, one for each scalar subelement of the composite nature. The simple nature of a composite nature is the nature of each scalar subelement of the composite nature. 3.1.2.1 Array Natures An array nature is a composite nature. Terminal objects of an array nature consist of identical elements, each associated with some index value. The branch types defined by an array nature are array types. array_nature_definition ::= unconstrained_nature_definition | constrained_nature_definition unconstrained_nature_definition ::= "array" ( index_subtype_definition { , index_subtype_definition } ) "of" subnature_indication constrained_nature_definition ::= "array" index_constraint "of" subnature_indication The branch types defined by an unconstrained nature definition are types in which the list of index subtype definitions is that of the unconstrained nature. The element subtype indication of the across type (respectively, through type) defined by an array nature definition is the across (respectively, through) type defined by the nature of the subnature indication, together with the index constraint of the subnature indication. 3.1.2.2 Record Natures A record nature is a composite nature. Terminal objects of a record nature consist of named elements. The branch types defined by a record nature are record types. record_nature_definition ::= "record" nature_element_declaration {nature_element_declaration} "end record" [record_nature_simple_name] nature_element_declaration ::= identifier_list: element_subnature_definition element_subnature_definition ::= subnature_indication Each nature element declaration declares an element of the record nature. All elements must have the same simple nature. The identifiers of all elements of a record nature must be distinct. The use of a name that denotes a record element is not allowed within the record nature definition itself. A nature element declaration with several identifiers is equivalent to a sequence of single element declarations. Each single nature element declaration declares a record element whose subnature is specified by the element subnature definition. The across type declared by a record nature is a type defined by a record definition in which there is a matching element declaration for each nature element declaration. The element subtype indication of each such nature element declaration is the across type implied by the nature of the subnature indication of the nature element declaration, together with the index constraint of the subnature indication of the nature element declaration. The through type declared by a record nature is determined by the rule created when "through" is substituted for "across" at each occurence of the later in the preceding paragraph. 3.2 Declarations 3.2.1 Nature Declaration A nature declaration declares a nature and also declares the across and through types of the nature. nature_declaration ::= "nature" identifer "is" nature_definition ";" nature_definition ::= scalar_nature_definition | composite_nature_definition subnature_declaration ::= "subnature" identifier "is" subnature_indication; nature_mark ::= nature_name|subnature_name subnature_indication ::= nature_mark [index_constraint] For any nature name N an attribute name of the form N'Across denotes the across type of the nature denoted by N and an attribute name of the form N'Through denotes the through type of the nature denoted by N. For any nature name N an attribute name of the form N'Reference denotes the reference terminal of each terminal of nature N if N denotes a scalar nature, and otherwise the reference terminal of each scalar subelement of each terminal of nature N. It is a consequence of this rule that N'Reference denotes a scalar terminal. A subnature declaration declares a subnature. A subnature is a nature together with an index constraint. A condition imposed by an index constraint is said to be compatible with a nature if it is compatible with the across and through types of the nature. The condition of the index constraint of a subnature indication must be compatible with the nature denoted by the nature mark. 3.2.2 Terminal Declaration (at 4.3.1.5) A terminal declaration declares a terminal. terminal_declaration ::= "terminal" identifier_list ":" subnature_indication ";" Each terminal of a simple nature and each scalar subelement of a terminal of composite nature is a basic terminal. The across type implied by a terminal name is determined as follows. The across type implied by a name that denotes a terminal is the across type of the nature of the terminal. The across type implied by a terminal name that is a slice name is the base type of the across type of the nature of the terminal together with a constraint that is the range of the slice name. The across type implied by a terminal name that is a selected name denoting an element of a record or by a terminal name that is an indexed name is the across type of the nature of the denoted element. The through type implied by a terminal name is determined by the rule created when "through" is substituted for "across" at each occurence of the later in the preceding paragraph. The name T'Reference, where T is a terminal name, is a quantity of the across type implied by T. If T is scalar then T'Reference is equivalent to the reference quantity of T; otherwise each scalar subelement of T'Reference is equivalent to the reference quantity of the matching scalar subelement of T. The name T'Contribution, where T is a terminal name, is a quantity of the through type implied by T. If T is scalar then T'Contribution is equivalent to the contribution expression of T; otherwise each scalar subelement of T'Contribution is equivalent to the contribution expression of the matching scalar subelement of T. 3.2.3 Quantity Declaration (at 4.3.1.6) A quantity declaration declares a quantity. quantity_declaration ::= free_quantity_declaration | branch_quantity_declaration free_quantity_declaration ::= "quantity" identifier ":" subtype_indication [":=" expression]";" branch_quantity_declaration ::= "quantity" [across_aspect] [through_aspect] terminal_aspect ";" across_aspect ::= identifier_list [":=" expression] "across" through_aspect ::= identifier_list [":=" expression] "through" terminal_aspect ::= plus_terminal_name "to" minus_terminal_name Each quantity of a scalar type and each scalar subelement of a quantity of composite type is a basic quantity. A free quantity declaration declares a quantity of the specified type. A nature type is a floating-point type or a composite type with elements of a nature type. The type of a quantity must be a nature type. It is an error if a branch quantity declaration includes neither an across aspect nor a through aspect. If the terminals denoted by the terminal names of a terminal aspect are both of composite natures then they must be of the same nature, and for each element of the plus terminal there must be a matching element of the minus terminal. If one terminal is a terminal of a composite nature and the other of a scalar nature, then the scalar nature must be the nature of the scalar subelements of the composite terminal. If both terminals are of a simple nature then they must be of the same simple nature. The type of a quantity declared in a branch quantity declaration containing an across aspect is determined as follows. If both terminals denoted by the terminal aspect are of a simple nature, then the type is the across type implied by the terminal names. If only one terminal denoted by the terminal aspect is of a composite nature, then the type is the across type implied by that terminal name. If both terminals denoted by the terminal aspect are of composite natures, then the type is the across type implied by the plus terminal name. The type of a quantity declared in a branch quantity declaration containing a through aspect is determined by the rule created when "through" is substituted for "across" at each occurence of the later in the preceding paragraph. The plus terminal of a simple quantity created by a branch quantity declaration is determined as follows. If the quantity is scalar then the plus terminal of the terminal aspect is the plus terminal of the quantity. If the quantity is composite then the plus terminal of a given scalar subelement of the quantity is the matching subelement of the plus terminal of the terminal aspect. The minus terminal of a simple quantity created by a branch quantity declaration is determined as follows. If the quantity is scalar then the minus terminal of the terminal aspect is the minus terminal of the quantity. If the quantity is composite and the minus terminal of the terminal aspect is composite then the minus terminal of a given scalar subelement of the quantity is the matching subelement of the minus terminal of the terminal aspect. If the quantity is composite and then minus terminal is scalar then the minus terminal of each scalar subelement of the quantity is the minus terminal of the terminal aspect. If the quantity declaration includes the assignment symbol followed by an expression, the expression is said to be an initial value expression. The expression specifies an initial value for the declared quantity. The type of the expression must be that of the quantity. The initial value of the quantity is determined by the expression when the quantity is elaborated. In the absense of an initial value expression, a default initial value applies. The default initial value for a quantity of a scalar type T is the value of the expression T(0.0). The default initial value of a quantity of composite type is the aggregate of the initial value of its elements. 3.3 Terminal and Quantity Ports (at 1.1.1.2 line 86) The ports of a block are defined by a port interface list; interface lists are described in 4.3.2.1. Each interface element in the port interface list declares a formal port. A formal port may be a signal port, a quantity port or a terminal port. (after 1.1.1.2 line 115) To communicate with other blocks, the terminal ports of a block can be associated with terminals in the environment in which the block is used. A terminal port is itself a terminal (see 4.3.1.5); thus a formal terminal port of a block may be associated as an actual with a formal terminal port of an inner block. The terminal port or terminal associated with a given formal terminal port is called the actual corresponding to the formal terminal port (see 4.3.2.2.). The actual must be denoted by a static name (see 6.1). After a given description is completely elaborated (see Section 12), if a formal terminal port is associated with an actual then the formal terminal port is said to be connected. If a formal terminal port is instead associated with the reserved word "open" or is left unassociated, then the formal is said to be unconnected. Similiarly, the quantity ports of a block can be associated with quantities in the environment in which the block is used. A quantity port is itself a quantity (see 4.3.1.6); thus a formal quantity port of a block may be associated as an actual with a formal quantity port of an inner block. The quantity port or quantity associated with a given formal quantity port is called the actual corresponding to the formal quantity port (see 4.3.2.2.). The actual must be denoted by a static name (see 6.1). After a given description is completely elaborated (see Section 12), if a formal quantity port is associated with an actual then the formal quantity port is said to be connected. If a formal quantity port is instead associated with the reserved word "open" or is left unassociated, then the formal is said to be unconnected. (in 4.3.2) Interface objects also include interface terminals and interface quantities that appear as ports of a design entity, component, or block. interface_declaration ::= ... | interface_terminal_declaration | interface_quantity_declaration interface_terminal declaration ::= "terminal" identifier_list ":" subnature_indication interface_quantity_declaration ::= "quantity" identifier_list ":" ["in" | "out"] subtype_indication [":=" static_expression] For an interface quantity declaration, the subtype indication must define a nature subtype. (in 4.3.2.2) formal_designator ::= ... | terminal_port_name | quantity_port_name actual_designator ::= ... |terminal_name |quantity_name (after 4.3.2.2. line 491) If the formal designator of a formal part is a terminal name then the formal part must be the formal designator itself (neither a type conversion function nor a type conversion is allowed). Similiarly, if the actual designator of an actual part is a terminal name then the actual part must be the actual designator itself. The association of terminals is allowed only if the formal and actual are of the same nature or if the actual is "open". The association of a formal of a given composite nature with an actual of the same nature is equivalent to the association of the each scalar subelement of the formal with the matching scalar subelement of the actual. For the association of quantities with corresponding formal quantity ports, association of a formal of a given composite type with an actual of the same type is equivalent to the association of each scalar subelement of the formal with the matching subelement of the actual. If a quantity interface element in an interface list includes a default expression, then any corresponding association list need not include an association element for that interface element. If the association element is not included in the association list, or if the actual is "open", then the value of the default expression is used as the actual expression in an implicit assocation element for that interface element. 4. Rationale 4.1 Equations A set of explicit DAEs is denoted in a VHDL-A model by some combination of "simultaneous statements" involving the names of quantities and other conventional VHDL objects. The definitions do not require these statements to denote the same equations at all values of the independent variable nor do they constrain the number of equations. It follows for these (and other) reasons that the system may not have exactly one solution. The definitions here work only when a single solution is selected because a quantity is assumed to have exactly one value. We should choose a notation for DAEs that makes it as easy as possible for the simulator to report the inability to arrive at a single solution to the user. We want to catch as many cases as possible by local static analysis; and failing that, by global static analysis (after elaboration); and failing that at simulation time. There may be cases that are left over even if we do a good job at this -- those that aren't anticipated by the language definition, possibly including implementation dependent cases. It would be desirable if the error report allowed the designer to quickly localize the problem to a particular area of his code. The unstated principle is to describe the whole VHDL-A world in terms of building a set of DAEs for evaluation. Some equations are denoted by the coder, some are a consequence of the design unit topology the coder has created and some are a consequence of the conservation laws. An implementation is free to use some compact formulation technique (and maybe more than one, depending on circumstances) to increase the time/space efficiency of evaluation. 4.2 Quantities Basic quantities are the unknowns in the DAEs. The definitions above unify the informal notions of "quantity" on the one hand, and "node" or "pin" on the other, used in previous discussions in the mail archive and the existing LESs. Basic quantities are defined with the intent that a name designating a quantity be meaningful in any expression where a value of the type of the quantity is allowed in VHDL 1076. The definitions keep a careful distinction between a basic quantity, in terms of which the dynamic semantics is defined, and quantity objects in the extended language, which may be composite and whose primitive elements are defined to be basic quantities. In this rationale, however, the word quantity is often used in place of basic quantity where no confusion can result. Quantities can be viewed as continuous functions of the independent variable ("waveforms") that are observable within VHDL-A, and by the human user of the simulator, only at discrete values of that variable. The specification of which times (or frequencies) are among the discrete values is a complicated business, depending on the desires of the designer, the exigencies of the solution algorithm selected by the tool builder, and additional information embedded in the text by the model writer to increase the probability that the solution algorithm will "behave well" as quantities achieve critical boundary values. This topic will be dealt with elsewhere. The reference quantity for a terminal is, in electrical systems, the voltage at the terminal with respect to ground. The current contribution of the terminal (to the node in which it is interconnected with other terminals) is the sum (paying attention to the signs) of the through quantities of the terminal. The through quantities are the individual current sources. The definitions provide names for the voltage at a terminal T with respect to ground (T'Reference) and for the current flowing out of a terminal into the enclosing block (T'Contribution). In each case, however, it is the underlying quantities that are value-bearing, not the terminals themselves. The notion of quantity satisfies the requirements for modeling of non-conservative systems, including "coupling" between components that is parallel to but separate from terminal-to-terminal connections. The structural semantics of VHDL are extended in VHDL-A with definitions of "interface quantity" and "quantity association" paralleling the existing definitions of "interface signal" (port) and "interface association". 4.3 Types and Natures The designer can declare subtypes voltage, current, flux and so on of floating point types and use these to declare quantities. Free quantities are given types directly in their declarations. Branch quantities get their types indirectly from the nature of their terminals. A pair of floating point subtypes make up a scalar nature. A nature may also be a composite structure whose leaf-level subelements are scalar natures. A nature declaration creates an across type and a through type as well as a nature. The types have the same "shape" as the nature, but they are ordinary VHDL types. These have names that can be used anywhere a type name is allowed; N'Across is the name of the across type, and N'Through is the name of the through type. The across and through types can be used to declare free quantities, signals, constants and variables. A portion of a terminal is named using the same form of selected, index and slice names as other objects. The scalar subelements of a terminal are the simple terminals on which the dynamic semantics is defined. The constellation of terminals all declared with elements of the same simple nature belong to the same physical system -- electrical, mechanical, thermal and so on. The all have the same "ground reference" which is denoted by N'Reference, where N is the nature. Note that nature as defined here is quite different from "nature" as defined in the existing LESs. A nature is not a type. It is a composite of two types. Only terminals have a nature. The nature transmits the types to the branch quantities of the terminal. A branch quantity has an ordinary VHDL type determined by the nature of its terminals. A branch quantity does not have a nature. The definitions provide the basis for a concrete syntax in which it is not possible to make inadvertent errors in specifying the types of branch quantities. 4.4 Quantities and Dimension In this section, the word quantity and terminal are used to mean, respectively, the scalar subelements of quantities and terminals. The types discussed are the types of those elements. In VHDL, operations are defined on types, not subtypes, so the designer can write meaningful expressions that multiply, divide, add and subtract quantities of different subtypes of the same type. To put it another way, objects of the same type (but possibly different subtypes) are interoperable. A subtype imposes one additional constraint; before a value of the type is assigned to an object of the subtype, the constraint is checked and an error message is issued if the value fails the test. Subtypes divide a collection of quantities of a given type into named subsets to which the designer can add additional user-defined attributes. Using subtypes in this way is analogous to the use of the subtype to bear the signal resolution function. It would be natural to attribute a subtype with the name of the unit for the physical values it represents in a form suitable for the waveform display of the simulator: attribute unit of subtype is string; attribute unit of current: subtype is "amp"; The attribute declaration and attribute specification could appear in the package declaring the natures and types used in the model. Since a quantity may be any floating point type, the universe of quantities can be divided at the designer's option into non-interoperable subsets; the designer will be prevented from adding (for example) a quantity of one type to a quantity of another type without explicit type conversion or a new, overloaded addition operator. He could define, for example, a type "kirchhoff" with subtypes "voltage" and "current", and a type "newton" with subtypes "force" and "displacement". The designer may choose the subtypes of a simple nature from different types. In that case, the across quantities and through quantities of terminals of that nature are not interoperable. He could define, for example, a type "voltage", a type "current" and a type "resistance". He could then use "voltage" and "current" to define a nature "electrical". Now expressions involving both the across and through branches of terminals of nature "electrical" will require overloaded operators or explicit type conversions. Here is the declaration of such an overloaded operator: function "/" (I: current; E: voltage) return resistance; The preceding paragraphs demonstrate that the existing type system of VHDL (as trivially extended with "nature") will provide the flexibility needed by VHDL-A until and unless a complete dimensional analysis system is defined. 4.5 Numerical Precision and Initial Values In VHDL 1076-1993, the precision of any floating point type and in particular of type real (the only predefined member of the class) is implementation defined, with a set lower limit (6 digits). The type class floating point in a VHDL-A implementation will need higher minimum precision to prevent numerical problems. We have several options for making higher precision floating point types available: 1) Give all types of the floating point class the maximum precision (including type real) 2) Introduce class "double" at 16 (or whatever) digits.Use it for scalar quantity types. 4) Introduce syntax to specify precision: e.g., "TYPE KIRCHHOFF IS DIGITS 16 RANGE...;" Option 1 is the simplest and requires no change to VHDL 1076-1993 except the increase in minimum precision of the floating point class. This option has been adopted. The default initial value of a quantity object , in the absence of an explicit value supplied in its declaration, is zero. This will make a large subset of models work even if explicit initialization is neglected. We mention in passing that we have not yet a complete definition of what the simulator is supposed to do with the initial values of quantities, nor what to do about initial conditions. 4.6 Quantities in the Frequency Domain Frequency domain analysis (in which quantities take on complex rather than real values) can be taken into account in the following way. Extend the definition of the VHDL class of floating point types to be mathematical real numbers in the time domain but mathematical complex numbers in the frequency domain. This will always yield a consistent interpretation without the additional apparatus required by explicit dimorphism. In digital VHDL, which always executes in the time domain, floating point numbers represent mathematical reals as they do now. f complex arithmetic is required in the time domain a package (such as the new IEEE math package) containing the appropriate types, operators and functions may be used. We could, alternatively, define a new class of types "dimorphic floating-point" (DFP) and say that they are closely related to types of class "floating-point" (FP). This is probably where the discussion in the LESs is headed towards when it talks about type "analog". Now we can define DFP types (for example, "analog", "newton", "kirchhoff"). But what do we do about closely-relatedness in the frequency domain? The natural thing to do would be to treat FPs as if they are extended with an imaginary part when operating in the frequency domain. But that would make them indistinguishable for DFPs in either domain. So why introduce the second class at all? It has been argued that this specification will lead to inefficient implementations, because space must be allocated for complex numbers when only the real part is used. It is hard to imagine a model in which the most inefficient implementation of this scheme (that, say, doubles the amount of storage required for quantities) would have any practical consequences. In such a giant, other considerations (for example, the size of the solution matrixes) would dominate. 4.7 Static Structural Semantics and Conservation Terminal and quantity declarations are defined in such away that they can be allowed anywhere a signal declaration is allowed. A terminal is little more than the set of branch quantities declared using the name of that terminal in a branch quantity declaration. Each such branch quantity belongs to one other terminal as well; the one on the "other end" of the branch. Electrical nodes (or their analogy in other physical systems) are created when terminals are connected with other terminals in a structural description (an unconnected terminal is also a node). The words "port" is defined in the LRM as a short-hand for "interface signal declared in a port declaration list". If we are to include interface quantities and interface terminals in a port declaration list then this short-hand is no longer appropriate. We will need to replace each occurance of "port" used in this sense with "signal port", to differentiate a signal port clearly from a terminal port or quantity port. The extensions required to include interface terminals and quantities closely parallel the similar definitions for signals. One important difference is that neither terminal nor quantity has a "directional" mode. Since terminals do not have values no type conversion or function is allowed in an terminal association element. A quantity association adds a formula equating the actual and formal parts of the association to the set of DAEs that must be solved. In effect, the formal and actual parts act as if they are different names for the same quantity. We may eventually decide to give modes to interface quantities (for example, in, out, inout, read-only) but not terminals. In VHDL, modes restrict (statically) where the name of an object can be used; for example, in an expression, on the left hand side of an assignment, at the place of the actual in certain element associations. Whether this sort of restriction is useful will become more apparent when we decide what simulataneous statements look like. We could add modes to help the modeler avoid mistakes. Adding modes adds no new functional power to the language -- it only adds restrictions on what formulas are allowed. The contribution expression of a basic terminal is, in electrical systems, the sum of the currents flowing out of the terminal. Those currents come from two kinds of sources; locally declared through quantities and the terminals of subcomponents with which a given terminal is associated. The terms that enter into the sum are completely determined when the declared terminal is elaborated -- that is, before simulation begins. Consider the tree of terminals descending from a given terminal through the structural hierarchy of the design. The tree is formed by terminal associations in the interfaces of enclosing blocks (or component instances, which are the same thing), the association of those blocks' formal terminals with formals of yet other nested blocks, and so on down to the leaf blocks. Now climb the tree again from a given leaf, following the linked terminals. The rules cause the repeated summing of contribution expressions as we ascend through the hierarchy from the leaves, so when we get to the root, all of the contributions to the electrical node represented by the tree have been summed in the contribution expression of the root. The conservation constraint -- in electrical systems, that the currents at a node sum to zero -- is imposed by definition on that final sum. Each basic through quantity implicitly defines a topological branch of the circuit being modeled. There is no restriction on the number of through quantities that may span a given pair of basic terminals, and hence no restriction on the number of parallel branches connecting two basic terminals. The topological branches come into existence when the declaration of a through quantity is elaborated. There is no restriction on the number of basic across quantities that may span a given pair of basic terminals, but all such across quantities are constrained to be equal (or to be equal and of opposite sign) because each is equal to the difference of the reference quantities of its basic terminals. The reference across quantity of a terminal come into existence when the declaration of the terminal is elaborated. The definitions provide a framework in which conservation semantics can be statically enforced. It is not possible to inadvertently notate a current contribution to only one node when the intention is to make equal and opposite contributions to two different nodes. Care must be taken, however in the use of the implicit quantities T'Contribution. Careless use can result in the addition of unintended circuit branches from T to ground. The implicit equations of the definitions are necessary and sufficient to define the conservation of charge semantics imposed by Kirchhoff's law or its analogy in other conservative physical models. 5. Examples -- Examples for "Quantities and Terminals" -- K. Bakalar 12/9/94 -- K. Bakalar revised 2/7/95 -- K. Bakalar revised 3/16/95 Some examples added. Typos corrected. -- -- package electrical_system is type kirchhoff is range -1.0E+100 to +1.0E+100; subtype voltage is kirchhoff; subtype current is kirchhoff; subtype charge is kirchhoff; subtype inductance is kirchhoff; subtype capacitance is kirchhoff; nature electrical is voltage across current through; alias ground is electrical'reference; nature elec_array is array (integer range <>) of electrical; subnature elec10 is elec_array(1 to 10); nature elec_matrix is ARRAY(1 TO 10_000, 1 TO 10_000) of electrical; end electrical_system; -- Here are some examples of terminal and quantity declarations you -- could create using the package above: -- terminal T1: elec_array(1 to 10); -- terminal T2: elec10; -- quantity QA1 across T1 to T2; -- quantity QA2 through T1(1 to 9) to T2(2 to 10); -- quantity QF1: elec_array'across (1 to 10); -- terminal T5,T6: electrical; -- terminal T3, T4: electrical; -- quantity QA5 across T3 to T1; -- quantity QA6 across T1(1 to 4) to T3; -- An explicit DAE is coded using a simple simultaneous statement -- containing the equivalence symbol "==". Simultaneous statements may -- appear in the statement part of a block. See the paper "Simultaneous -- Statements" for more information. use electrical_system.all; entity inductor is generic (L: inductance); -- The port interface list is allowed to have terminals and quantities -- as well as signals port (terminal n1, n2: electrical); end inductor; -- architecture take_one of inductor is -- declare two branch quantities (and, implicitly, one branch) quantity branch_voltage across branch_current through n1 to n2; begin -- Q'dot is an implicit quantity whose value is constrained -- to the derivative w.r.t. time of Q branch_voltage == L* branch_current'dot; end take_one; -- -- Here's a simple resistor model with two interface terminals -- use electrical_system.all; entity resistor is generic (resistance: kirchhoff); port (terminal n1, n2: electrical); end resistor; -- architecture one of resistor is quantity resistor_e across resistor_i through n1 to n2; begin resistor_i == resistor_e/resistance; end one; -- -- This is identical to the previous architecture. -- Note that quantites n1_gnd_e and n2_gnd_e are not -- reference quantities themselves, they are ordinary across quantities -- architecture two of resistor is quantity resistor_i through n1 to n2; quantity n1_gnd_e across n1 to ground; quantity n2_gnd_e across n2 to ground; begin resistor_i == n1_gnd_e/resistance - n2_gnd_e/resistance; end two; -- -- T'reference of a terminal T denotes the reference quantity -- of that terminal. -- architecture three of resistor is quantity resistor_i through n1 to n2; begin resistor_i == (n1'reference -n2'reference)/resistance; end three; -- -- A rather unusual but correct description -- architecture four of resistor is quantity resistor_e across resistor_i through n1 to n2; begin resistor_e/resistor_i == resistance; end four; -- -- This inductor has a quantity interface element to "report out" -- the current -- use electrical_system.all; entity inductor1 is generic (L: inductance); port (terminal n1, n2: electrical; quantity q1: current); end inductor; -- architecture take_one of inductor1 is quantity branch_voltage across branch_current through n1 to n2; begin branch_voltage == L* branch_current'dot; q1 == branch_current; end take_one; -- -- An ideal operational amplifier. -- The input voltage and current are identically zero, by definition. -- The output current is declared, creating a branch, but it is -- unconstrained by any equation. -- entity ideal_opamp is port (terminal inplus, inminus, output: electrical); end ideal_opamp; -- -- Notice that current_output is declared but does not appear -- in any simultaneous statement! -- architecture one of ideal_opamp is quantity voltage_input across curent_input through inplus to inminus; quantity current_output through output to ground; begin voltage_input == 0.0; current_input == 0.0; end one; -- -- A branch constrained to zero current is the same as no branch -- architecture two of ideal_opamp is quantity voltage_input across inplus to inminus; quantity current_output through output to ground; begin voltage_input == 0.0; end two; -- -- Use the opamp in a VVT with positive gain (fbr+igr)/igr. -- entity op_amp_testbench is use electrical.all; end op_amp_testbench; architecture one of op_amp_testbench is terminal test_inminus, test_inplus, test_output: electrical; quantity feed_back_v across feed_back_i through test_inminus to test_output; quantity inminus_gnd_v across inminus_gnd_i through test_inminus to ground; quantity test_voltage across test_current through test_inplus to ground; constant igr: kirchhoff := 1.0e3; constant fbr: kirchhoff := 1.0e6-igr; constant trial: voltage := 0.001; begin U1:entity ideal_opamp port map (test_inplus, test_inminus, test_output); feed_back_i == feed_back_v/fbr; inminus_gnd_i == inminus_gnd_v/igr; test_voltage == trial; end one; =0C-- -- Now use the resistor component instead of the CE for the feedback. -- architecture two of op_amp_testbench is terminal test_inminus, test_inplus, test_output: electrical; quantity feed_back_v across feed_back_i through test_inminus to test_output; quantity inminus_gnd_v across inminus_gnd_i through test_inplus across ground; constant igr: kirchhoff := 1.0e3; constant fbr: kirchhoff := 1.0e6-igr; constant trial: kirchoff := 0.001; begin U1:entity ideal_opamp port map (test_inplus, test_inminus, test_output); U2:entity resistor generic map (resistance => fbr) port map (test_inminus, test_output); inminus_gnd_i == inminus_gnd_v/igr; test_voltage == trial; end two; -- -- A parameterized diode, after a paper by FitzPatrick and Kundert. -- entity diode generic (Iss,n,Vt,tau,Cj0,Phi: real); port (terminal a,c: electrical; quantity total_current: current); end diode; architecture one of diode is quantity vdiode across idiode,icap through a to c; quantity charge: coulomb; begin idiode == A*Iss*(exp((vdiode-Rs*idiode)/(n*Vt)) -1); charge == tau*idiode-2.0*Cj0*sqrt(Phi**2-Phi*vdiode); icap == charge'dot; total_current == icap+idiode; end one; From 1076-1-request@sicmail.epfl.ch Wed May 10 03:07:27 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Wed, 10 May 95 03:07:23 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Wed, 10 May 95 03:07:19 -0400 X400-Received: by mta sicmail.epfl.ch in /PRMD=switch/ADMD=arCom/C=ch/; Relayed; Wed, 10 May 1995 08:43:19 +0200 Date: Wed, 10 May 1995 08:43:19 +0200 X400-Originator: 1076-1-request@sicmail.epfl.ch X400-Recipients: non-disclosure:; X400-Mts-Identifier: [/PRMD=switch/ADMD=arCom/C=ch/;sicmail.ep.496:10.04.95.06.43.19] Priority: Non-Urgent Dl-Expansion-History: 1076-1@epfl.ch ; Wed, 10 May 1995 08:43:16 +0200; From: "Jean-michel.Berge" Message-Id: To: analog_reflector <1076-1@epfl.ch> Subject: TR: Please Redistribute Through Your Reflectors X-Mailer: Mail*Link SMTP/MS 3.0.0 _______________________________________________________________________________ De: (David Kopca) le Mar 9 Mai 1995 22:55 Objet: Please Redistribute Through Your Reflectors A: stds.dasc-sc@ieee.org I would greatly appreciate it if you would redistribute the following message through your e-mail reflectors. Thanks, Dave Kopca Member, Group Technical Staff ASP Support Group E-Mail: kopca@ti.com Texas Instruments, Inc. Phone: 214/997-5825 M/S 8316, PO Box 655303 Fax: 214/997-3846 Dallas, TX 75265 --------------------------------------------------------------- Announcing the formation of the Standard Simulation Control Language Study Group of the IEEE DASC A new Study Group has been approved by IEEE Computer Society Design Automation Standards Committee. The purpose of the Study Group is the following: Standardize a simulation control language that is portable across simulation environments. The Study Group is asking for participation from members of the Verilog and VHDL community who are willing to work on this *HDL- INDEPENDENT* effort. We would like to have participation from the EDA vendors as well as the user community. To view the Study Group's home page, view: http://vhdl.org/vi/scl/Welcome.html To find out more info about a group, send an email request to: scl-info@vhdl.org To get added to an email exploder and be made aware of the groups activities, send your email address to: scl-request@vhdl.org To submit a message to an email exploder, email the message to: scl@vhdl.org (Please do not send maintenance requests to this address!!) ------------------ RFC822 Header Follows ------------------ Received: by msmail with SMTP;9 May 1995 22:54:47 -0100 X400-Received: by /PRMD=cnet/ADMD=atlas/C=FR/; Relayed; 09 May 95 23:53:16+0200 X400-Received: by /ADMD=ATLAS/C=FR/; Relayed; 09 May 95 21:53:01 GMT X400-Received: by /PRMD=INTERNET/ADMD=ATLAS/C=FR/; Relayed; 09 May 95 21:52:41 GMT X400-Received: by /PRMD=INTERNET/ADMD=ATLAS/C=FR/; Relayed; 09 May 95 21:49:23 GMT X400-Received: by /PRMD=INTERNET/ADMD=ATLAS/C=FR/; Relayed; 09 May 95 21:36:40 GMT X400-Received: by /PRMD=INTERNET/ADMD=ATLAS/C=FR/; Relayed; 09 May 95 21:19:44 GMT X400-Received: by /PRMD=INTERNET/ADMD=ATLAS/C=FR/; Relayed; 09 May 95 21:19:43 GMT X400-Received: by /PRMD=INTERNET/ADMD=ATLAS/C=FR/; Relayed; 09 May 95 21:20:24 GMT X400-Received: by /PRMD=INTERNET/ADMD=ATLAS/C=FR/; Relayed; 09 May 95 21:20:24 GMT X400-Received: by /PRMD=INTERNET/ADMD=ATLAS/C=FR/; Relayed; 09 May 95 21:20:21 GMT Date: 09 May 95 21:20:21 GMT From: " (David Kopca)" Sender: owner-stds-dasc-sc@rab.ieee.org Message-ID: <9505092120.AA28675@daldd.sc.ti.com> To: stds.dasc-sc@ieee.org Subject: Please Redistribute Through Your Reflectors Importance: Normal X-Originally-From: davidk@daldd.sc.ti.com (David Kopca) Organization: IEEE Service Center, Piscataway, NJ X-Resent-To: stds-dasc-sc@mail.ieee.org X-Resent-Date: Tue May 9 17:36:37 EDT 1995 Errors-To: owner-stds-dasc-sc@rab.ieee.org Precedence: bulk X-Listname: stds-dasc-sc From 1076-1-request@sicmail.epfl.ch Wed May 10 16:23:51 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Wed, 10 May 95 16:23:44 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Wed, 10 May 95 16:23:39 -0400 Received: from mailgate.Cadence.COM by sicmail.epfl.ch with SMTP (PP) id <00590-0@sicmail.epfl.ch>; Wed, 10 May 1995 21:41:46 +0200 Received: (from smap@localhost) by mailgate.Cadence.COM (8.6.8/8.6.8) id MAA27464 for <1076-1@epfl.ch>; Wed, 10 May 1995 12:41:43 -0700 Received: from cds2072.cadence.com(158.140.24.54) by mailgate.cadence.com via smap (V1.0mjr) id sma027452; Wed May 10 12:41:32 1995 Received: from mailgate.Cadence.COM (mailgate.cadence.com [158.140.2.1]) by cds2072.Cadence.COM (8.6.8/8.6.8) with ESMTP id MAA08422 for ; Wed, 10 May 1995 12:41:28 -0700 Received: (from smap@localhost) by mailgate.Cadence.COM (8.6.8/8.6.8) id MAA27441 for ; Wed, 10 May 1995 12:41:27 -0700 Received: from vhdl.vhdl.org(198.31.14.3) by mailgate.cadence.com via smap (V1.0mjr) id sma027355; Wed May 10 12:41:02 1995 Received: by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA24906; Wed, 10 May 95 12:26:32 PDT Date: Wed, 10 May 95 12:26:32 PDT From: jose@vhdl.org (Jose Torres) Message-Id: <9505101926.AA24906@vhdl.vhdl.org> To: math@vhdl.org Subject: Standard Simulation Control Language Please find enclosed information about a new standardization effort that I have been asked to pass along. >>>>>>>>>>>>>>>>>> Announcing the formation of the Standard Simulation Control Language Study Group of the IEEE DASC A new Study Group has been approved by IEEE Computer Society Design Automation Standards Committee. The purpose of the Study Group is the following: Standardize a simulation control language that is portable across simulation environments. The Study Group is asking for participation from members of the Verilog and VHDL community who are willing to work on this *HDL- INDEPENDENT* effort. We would like to have participation from the EDA vendors as well as the user community. To view the Study Group's home page, view: http://vhdl.org/vi/scl/Welcome.html To find out more info about a group, send an email request to: scl-info@vhdl.org To get added to an email exploder and be made aware of the groups activities, send your email address to: scl-request@vhdl.org To submit a message to an email exploder, email the message to: scl@vhdl.org (Please do not send maintenance requests to this address!!) From 1076-1-request@sicmail.epfl.ch Thu May 11 08:23:17 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Thu, 11 May 95 08:23:13 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Thu, 11 May 95 08:23:05 -0400 X400-Received: by mta sicmail.epfl.ch in /PRMD=switch/ADMD=arCom/C=ch/; Relayed; Thu, 11 May 1995 13:57:11 +0200 Date: Thu, 11 May 1995 13:57:11 +0200 X400-Originator: 1076-1-request@sicmail.epfl.ch X400-Recipients: non-disclosure:; X400-Mts-Identifier: [/PRMD=switch/ADMD=arCom/C=ch/;sicmail.ep.882:11.04.95.11.57.11] Priority: Non-Urgent Dl-Expansion-History: 1076-1@epfl.ch ; Thu, 11 May 1995 13:57:09 +0200; From: "Jean-michel.Berge" Message-Id: To: analog_reflector <1076-1@epfl.ch> Subject: TR: DAC DASC Schedule X-Mailer: Mail*Link SMTP/MS 3.0.0 Here is the preliminary schedule for DASC meetings next month. I am currently writing the agenda for our WG meeting. Let me know (to berge@cns.cnet.fr) if you want to see specific points on it. Thanks, Jean-Michel _______________________________________________________________________________ De: Paul J. Menchini le Mer 10 Mai 1995 23:52 Objet: DAC DASC Schedule A: stds.dasc@rab.ieee.org Cc: (Paul J. Menchini) Ladies and Gentlemen, Attached is the (preliminary) schedule for DASC meetings immediately after DAC. (This version is text only; a PostScript version will follow.) I don't yet know the venue, but it should be somewhere in the Bay Area. I will announce when it's firmed up. Dates are believed to be firm at this point. WG/SG Chairs: Please verify info about your group and let me know if this schedule is ok. Regards, Paul -- Paul Menchini | email: mench@mench.com | "Se tu sarai solo, Menchini & Associates | voice: 919-990-9506 | tu sarai tutto tuo." 2 Davis Dr./POB 13036 | pager: 800-306-8494 | -- Leonardo Da Vinci RTP, NC 27709-3036 | fax: 919-990-9507 | =============================================================================== IEEE Computer Society Design Automation Standards Committee Meetings in Conjunction with the 1995 Design Automation Conference Somewhere in the Silicon Valley 16-17 June 1995 Friday, 16 June 8:30 am-12:30 pm Library IEEE Contents Study Group Contact: Andrew Guyler, Chair 503-685-1163 Mentor Graphics, Inc. 503-685-1268 [Fax] C-3 andrew_guyler@mentorg.com 8005 S.W. Boeckman Road Wilsonville, OR 97070-7777 8:30 am-12:30 pm System Design & Description Language Study Group Contact: Dave Barton, Chair 703-827-2606 Intermetrics, Inc. 703-827-2609 [Fax] 7918 Jones Branch Drive dlb@hudson.wash.inmet.com Suite 710 McLean, VA 22102 8:30 am-12:30 pm VHDL Shared Variables Working Group--P1076a Contact: Steve Bailey, Chair 510-659-0901, x227 Vantage 510-659-0129 [Fax] 47211 Lakeview Blvd. sab@vas.com Fremont, CA 94538 1:30 pm-5:30 pm VHDL Timing Methodology Working Group--P1076.4 Contact: Victor Berman, Chair 508-446-6276 Cadence 508-262-6777 [Fax] 270 Billerica Road berman@cadence.com Chelmsford, MA 01824 1:30 pm-5:30 pm VHDL Math Package Working Group--P1076.2 Contact: Jose Torres, Chair 415-694-4335 Synopsys, Inc. 415-694-4331 [Fax] 700 East Middlefield Road jose@synopsys.com Mountain View, CA 94043-4033 1:30 pm-5:30 pm Waveform and Vector Exchange Spec. Working Group--1029.1 Contact: Bob Hillman, Chair 315-330-2813 Rome Laboratory/ERG 315-330-2885 [Fax] 525 Brooks Road hillmanr@ernet.af.mil Griffiss AFB, NY 13441-4505 Saturday, 17 June 8:30 am-5:30 pm VHDL Analog Extensions Working Group--P1076.1 Contact: Jean-Michel Berge, Chair +33 76 76 43 35 CNS-CCI +33 76 90 34 43 [Fax] Chemin Du Vieux Chene--BP 98 berge@cns.cnet.fr MEYLAN CEDEX F-38243 FRANCE 8:30 am-12:30 pm VHDL Test Study Group Contact: Dr. Zainalabedin Navabi, Chair +98-21-633029 University of Tehran +98-21-688690 [Fax] Dept of ECE navabi_z@irearn.bitnet Building 2 navabi@nuvlsi.coe.neu.edu North Kagar Avenue 14399 Tehran IRAN 8:30 am-12:30 pm VHDL Parallel Simulation Study Group Contact: John Willis, Chair 507-253-8403 IBM Corporation willis@vnet.ibm.com 3605 Hwy. 52 North Rochester, MN 55901-7829 ------------------ RFC822 Header Follows ------------------ Received: by msmail with SMTP;10 May 1995 23:51:43 -0100 X400-Received: by /PRMD=cnet/ADMD=atlas/C=FR/; Relayed; 11 May 95 00:50:13+0200 X400-Received: by /ADMD=ATLAS/C=FR/; Relayed; 10 May 95 22:49:56 GMT X400-Received: by /PRMD=INTERNET/ADMD=ATLAS/C=FR/; Relayed; 10 May 95 22:49:49 GMT X400-Received: by /PRMD=INTERNET/ADMD=ATLAS/C=FR/; Relayed; 10 May 95 21:31:02 GMT Date: 10 May 95 21:31:02 GMT From: Paul J. Menchini Sender: owner-stds-dasc@rab.ieee.org Message-ID: <199505102131.RAA20193@mench.mench.com> To: stds.dasc@rab.ieee.org cc: " (Paul J. Menchini)" Subject: DAC DASC Schedule Importance: Normal X-Originally-From: "Paul J. Menchini" X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3100 Organization: IEEE Service Center, Piscataway, NJ X-Resent-To: stds-dasc@mail.ieee.org X-Resent-Date: Wed May 10 17:36:09 EDT 1995 Errors-To: owner-stds-dasc@rab.ieee.org Precedence: bulk X-Listname: stds-dasc From 1076-1-request@sicmail.epfl.ch Fri May 12 20:22:41 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Fri, 12 May 95 20:22:36 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Fri, 12 May 95 20:22:32 -0400 Received: from gatekeeper.ray.com by sicmail.epfl.ch with SMTP (PP) id <13189-0@sicmail.epfl.ch>; Sat, 13 May 1995 01:56:46 +0200 Received: from localhost (mailer@localhost) by gatekeeper.ray.com (8.6.4/8.6.5) id TAA26258 for <1076-1@epfl.ch>; Fri, 12 May 1995 19:55:27 -0400 Received: from sud2.ed.ray.com by gatekeeper.ray.com; Fri May 12 19:55:23 1995 Received: from SUD2.ED.RAY.COM by SUD2.ED.RAY.COM (PMDF V4.2-10 #4335) id <01HQFDIS1AKWA8FYI3@SUD2.ED.RAY.COM>; Fri, 12 May 1995 19:55:20 EDT Date: Fri, 12 May 1995 19:55:20 -0400 (EDT) From: "Joe Gwinn, 508-440-3330" Subject: Comments raised by LAT minutes of 4-7 Apr 95 meeting To: 1076-1@epfl.ch Message-Id: <01HQFDIS1K8IA8FYI3@SUD2.ED.RAY.COM> X-Envelope-To: 1076-1@epfl.ch X-Vms-To: IN%"1076-1@epfl.ch" X-Vms-Cc: GWINN Mime-Version: 1.0 Content-Transfer-Encoding: 7BIT I have a few comments to offer, after having read the LAT minutes. 1. With all the white papers becoming official documents, I would very much like to see them polished by a technical editor such as the IEEE's Mary Lynne Nielsen. The various documents are filled with lots of annoying little mistakes and unclear phrases, and will cause much trouble when a larger audience tries to read them. To be sure that the tech editor doesn't accidentially change the meaning of something, this polishing scan should be done before the documents are voted upon. 2. How does one specify the initial condition of an attribute? If ddt is an attribute, and as a consequence cannot be initialized, won't we then see a glitch whenever the analog solver is started or re-started? These glitches can be devastating. They can upset the solver, and can put undesired initial conditions on connected integrators. I would assume that ddt must be a function, so there is a way to specify its initial condition. [Richard Trihy may have been saying this, but the minutes weren't unambiguous, so I wanted to say it clearly, as it's a pet rock of mine.] 3. We seem to have lost Q'Rising and Q'Falling; only Q'Cross surviving. Well, direction often matters in that one does different things in the break code depending on direction. Now, one can certainly detect cross, then test a derivative's value within the break code. However, this forces the computation of an explicit derivative, which is somewhat more expensive. 4. On the issue of the break statement, I would comment that for models with essential discontinuities, like the bouncing ball, use of a break statement or its like is in practice essential, and not just a matter of a little bit of efficiency. One must be able to protect the analog solver from these discontinuities for the solution to be practical. And, a break statement, if correctly implemented, allows the solver to avoid creeping for fear of the discontinuity. An efficiency ratio of 100 or 1000 is a difference in kind in that a solver that slow cannot in practice be tolerated, so lack of break would preclude use of VHDL-A on the many systems with essential discontinuities. 5. We specifically excluded partial differential equations (PDEs) after some discussion some time ago. The way we excluded PDEs was by saying in DO2/DO6 that only lumped-element systems would be supported. Originally, the lumped-element requirement applied to electrical systems (DO2); this seems to have disappeared. Anyway, exclusion of PDEs is a good idea. We have bitten off quite enough as it is, and SPICE is our model. Joe Gwinn From 1076-1-request@sicmail.epfl.ch Fri May 12 20:22:47 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Fri, 12 May 95 20:22:45 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Fri, 12 May 95 20:22:41 -0400 Received: from gatekeeper.ray.com by sicmail.epfl.ch with SMTP (PP) id <13257-0@sicmail.epfl.ch>; Sat, 13 May 1995 02:08:45 +0200 Received: from localhost (mailer@localhost) by gatekeeper.ray.com (8.6.4/8.6.5) id UAA26329 for <1076-1@epfl.ch>; Fri, 12 May 1995 20:07:28 -0400 Received: from sud2.ed.ray.com by gatekeeper.ray.com; Fri May 12 20:07:31 1995 Received: from SUD2.ED.RAY.COM by SUD2.ED.RAY.COM (PMDF V4.2-10 #4335) id <01HQFEPMR3ZQA8FYI3@SUD2.ED.RAY.COM>; Fri, 12 May 1995 20:05:13 EDT Date: Fri, 12 May 1995 20:05:13 -0400 (EDT) From: "Joe Gwinn, 508-440-3330" Subject: Comments on the "Simultaneous Statements" White Paper To: 1076-1@epfl.ch Message-Id: <01HQFEPMR3ZSA8FYI3@SUD2.ED.RAY.COM> X-Envelope-To: 1076-1@epfl.ch X-Vms-To: IN%"1076-1@epfl.ch" X-Vms-Cc: GWINN Mime-Version: 1.0 Content-Transfer-Encoding: 7BIT I must say that one is left wondering after reading the paper on Simultaneous Statements. It seems to start in the middle, lost in the details. What's missing is an explanantion of the motivation. Why do we need this new class of VHDL-A statements? What problem are we solving? What bad thing happens if we don't have these statements? As near as I could tell from reading the paper, these statements are some kind of assertion with which one detects model errors, but I don't think that interpretation is correct. Some other white paper said something about using simultaneous statements to enforce conservation laws. I am not expressing an opinion on the technical merits of simultaneous statements. I am saying that I don't understand them well enough to judge the issue, and would like to see this paper expanded and clarified. Joe Gwinn From 1076-1-request@sicmail.epfl.ch Fri May 12 21:26:01 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Fri, 12 May 95 21:25:58 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Fri, 12 May 95 21:25:54 -0400 Received: from gatekeeper.ray.com by sicmail.epfl.ch with SMTP (PP) id <13838-0@sicmail.epfl.ch>; Sat, 13 May 1995 03:11:55 +0200 Received: from localhost (mailer@localhost) by gatekeeper.ray.com (8.6.4/8.6.5) id VAA27748 for <1076-1@epfl.ch>; Fri, 12 May 1995 21:10:38 -0400 Received: from sud2.ed.ray.com by gatekeeper.ray.com; Fri May 12 21:10:43 1995 Received: from SUD2.ED.RAY.COM by SUD2.ED.RAY.COM (PMDF V4.2-10 #4335) id <01HQFF24DO1OA8FYI3@SUD2.ED.RAY.COM>; Fri, 12 May 1995 21:10:42 EDT Date: Fri, 12 May 1995 21:10:42 -0400 (EDT) From: "Joe Gwinn, 508-440-3330" Subject: Comments on the "Mixed-Mode Simulation" White Paper To: 1076-1@epfl.ch Message-Id: <01HQFF24DO1QA8FYI3@SUD2.ED.RAY.COM> X-Envelope-To: 1076-1@epfl.ch X-Vms-To: IN%"1076-1@epfl.ch" X-Vms-Cc: GWINN Mime-Version: 1.0 Content-Transfer-Encoding: 7BIT 1. (Section 2.1, Break Statements) We make the correct statement that "A model that exhibits a discontinuity ... and does not execute a break statement ... is erroneous". However, we fail to make it clear that we expect the user to write a break statement for each and every essential discontinuity of his model, that the solver is not wrong to stumble if it encounters a discontinuity unaided. See my item 4. 2. Also see my comment (#4) about break statement in my comments on the minutes from the 4-7 April 1995 LAT meeting. For convenience, I repeat that comment here: On the issue of the break statement, I would comment that for models with essential discontinuities, like the bouncing ball, use of a break statement or its like is in practice essential, and not just a matter of a little bit of efficiency. One must be able to protect the analog solver from these discontinuities for the solution to be practical. And, a break statement, if correctly implemented, allows the solver to avoid creeping for fear of the discontinuity. An efficiency ratio of 100 or 1000 is a difference in kind in that a solver that slow cannot in practice be tolerated, so lack of break would preclude use of VHDL-A on the many systems with essential discontinuities. 3. (Section 3.1, The Mixed-Mode Simulation Cycle, 2nd paragraph, last sentence) The statement "No signal (not even a signal Q'Cross(E)) can change value between any two ASPs generated during a single invocation of the analog solver" seems a bit indirect. Aren't we trying to say that signals don't change while the analog solver is in control? I guess the business about Q'Cross(E) would appear to imply that its signal must be buffered until after the analog kernel relinquishes control. What about cases where the analog kernel is setting digital signals, such as A/Ds? Also, the sentence doesn't seem quite right. I think what was intended is that signals do not change between *adjacent* ASPs. Otherwise, the signal cannot change at all, as one can choose any pair of ASPs. I would suggest that we need to explicitly state that signals are digital and quantities are analog. It is implied, but never clearly stated. 4. (Section 3.3, Potential Optimizations of the Simulation Cycle, last paragraph) Having an explicit break statement allows one to solve discontinuous models without having left and right ASPs. As discussed in item 3 above, the ASP must land exactly on the essential discontinuity. What saves you is that an essential discontinuity is not the mathematical discontinuity of a function, is is a place where the physics of the problem being modeled forces one to switch from one set of well-behaved functions to another different but still well-behaved set of functions. So, landing an ASP exactly on the essential discontinuity incurs no risk of mathematical discontinuity, and the left and right ACPs will therefore both exist and will be equal. We have been using "discontinuity" loosely, covering both kinds, but they are very different, and perhaps we should be more precise in our discussions. So, "essential" means that the physical system being modeled has a discontinuity, a boundary between regions following different descriptive laws. I believe that we intend to permit what I call "essential discontinuities", and to forbid "mathematical discontinuities". In fact, it was expected that the solver could assume that the function it was generating was continuous with all its derivatives, and discontinuities were to be permitted only at the splice points between invocations of the analog solver. The overall result is a piecewise continuous function. 5. (Section 3.7.2, Detecting Discontinuities, first paragraph) I was all ready to fire missiles at the statement that break statements are unnecessary, until I read the rest of the section. I would suggest rearranging this section into the form followed by . Joe Gwinn From 1076-1-request@sicmail.epfl.ch Fri May 12 22:07:44 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Fri, 12 May 95 22:07:42 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Fri, 12 May 95 22:07:38 -0400 Received: from gatekeeper.ray.com by sicmail.epfl.ch with SMTP (PP) id <14193-0@sicmail.epfl.ch>; Sat, 13 May 1995 03:51:57 +0200 Received: from localhost (mailer@localhost) by gatekeeper.ray.com (8.6.4/8.6.5) id VAA28108 for <1076-1@epfl.ch>; Fri, 12 May 1995 21:50:39 -0400 Received: from sud2.ed.ray.com by gatekeeper.ray.com; Fri May 12 21:50:51 1995 Received: from SUD2.ED.RAY.COM by SUD2.ED.RAY.COM (PMDF V4.2-10 #4335) id <01HQFHBZEM02A8FYI3@SUD2.ED.RAY.COM>; Fri, 12 May 1995 21:50:49 EDT Date: Fri, 12 May 1995 21:50:49 -0400 (EDT) From: "Joe Gwinn, 508-440-3330" Subject: Comments on the "VHDL-A Language Architecture" To: 1076-1@epfl.ch Message-Id: <01HQFHBZEM04A8FYI3@SUD2.ED.RAY.COM> X-Envelope-To: 1076-1@epfl.ch X-Vms-To: IN%"1076-1@epfl.ch" X-Vms-Cc: GWINN Mime-Version: 1.0 Content-Transfer-Encoding: 7BIT These comments cover version 1.0 of the architecture. 1. (Section 2.2, Conservative Systems) I don't think we ever come out and say that natures must be internally consistent, that one cannot for instance combine electric current as the through variable with hydraulic pressure as the across variable. It's likely to be essential, but it's also likely that VHDL-A cannot itself enforce consistency, unless we force users to chose from a pre-ordained list, which is too limiting. 2. (Section 2.2, Conservative Systems) Likewise, we never come out and say that the product of a nature's through and across variables must be energy flow (ie, power). It appears to me that the definition of "internally consistent" is precisely that the through and across variables of a given nature together describe an actual (not fictitious) power flow, one whose size is given by their product. I'm not sure that the statement that natures from different diciplines are incompatible because they have different reference terminals quite captures the intent, although it may provide an enforcement mechanism of sorts. It certainly isn't much help in explaining how one decides what can and cannot be bundled together as a valid nature. 3. Another thing we never describe is how one would describe and model an electrical transformer, or any kind of power-conserving transducer (such as a loudspeaker or an electromagnetic microphone). I assume that VHDL-A can do this, but it won't be obvious and would make a good example. 4. (Section 2.4, Simulation Cycle) We should spell one femtosecond out, as "1 fs" is too easily mangled in reproduction. Likewise nanosecond, et al. 5. (Section 2.5, Initialization, DC Simulation) We should note that there may be multiple valid DC operating points. We keep talking of "the DC operating point", as if there could be only one. Flopflops have two DC operating points. Many complex analog circuits have more than one, and part of design is to ensure that the circuit picks the right one. SPICE models are famous for sometimes needing to be led to the correct operating point. So, we should instead speak of "a DC operating point", and we should provide a way in VHDL-A to specify a starting point from which to start the search for a DC operating point. 6. (Section 3.1, Math Package Support) When I read the initial VHDL Math postings of perhaps a year (or two?) ago, my impression was that they had strayed from requirements into prescribed implementation, with actual code, which is generally a no-no. The required behaviour and accuracy should be described in mathematical terms, and be left at that. And, it was never clear why we (VHDL or VHDL-A) needed to provide a definition for the sine function et al; these are well understood, and provided on all platforms one is likely to use for VHDL-A. There were a few functions, like CORDIC, that are uncommon, so it would make sense to describe and standardize them, but no others. Joe Gwinn From 1076-1-request@sicmail.epfl.ch Fri May 12 22:10:25 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Fri, 12 May 95 22:10:23 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Fri, 12 May 95 22:10:19 -0400 Received: from gatekeeper.ray.com by sicmail.epfl.ch with SMTP (PP) id <14413-0@sicmail.epfl.ch>; Sat, 13 May 1995 04:08:03 +0200 Received: from localhost (mailer@localhost) by gatekeeper.ray.com (8.6.4/8.6.5) id WAA28186 for <1076-1@epfl.ch>; Fri, 12 May 1995 22:06:39 -0400 Received: from sud2.ed.ray.com by gatekeeper.ray.com; Fri May 12 22:07:03 1995 Received: from SUD2.ED.RAY.COM by SUD2.ED.RAY.COM (PMDF V4.2-10 #4335) id <01HQFIW845U0A8FYI3@SUD2.ED.RAY.COM>; Fri, 12 May 1995 22:06:16 EDT Date: Fri, 12 May 1995 22:06:15 -0400 (EDT) From: "Joe Gwinn, 508-440-3330" Subject: Condensed comments on VHDL Math, FYI To: 1076-1@epfl.ch Message-Id: <01HQFIW84FH6A8FYI3@SUD2.ED.RAY.COM> X-Envelope-To: 1076-1@epfl.ch X-Vms-To: IN%"1076-1@epfl.ch" X-Vms-Cc: GWINN Mime-Version: 1.0 Content-Transfer-Encoding: 7BIT These comments were sent 6 December 1993 to Jose Torres. It certainly would appear from the rumours that these comments are still current. Some less relevant material has been deleted. Joe Gwinn's comments on VHDL Math Package and Declaration version 0.7, soon to be a IEEE 1076.2 draft standard, from an email sent 3-DEC-1993 23:38:00.05 by Jose Torres. This commentary may be circulated freely. 1. Why are we developing yet another math package? Hasn't this already been done? I recall that the Ada (83 and 9x) folk are also working on a standard math library. Also, the IEEE floating point arithmetic standard has a number of definitions, and also could be used as a model for how a math standard could or should be structured. By the way, beware LCAS, the "Language Compatible Arithmetic Standard (LCAS)" ISO's draft (ISO/IEC 10967:1991).. It attempts to evade the flaws in the floating point on every dinosaur machine that ever was, at great expense. It is much more pessimistic than necessary even on those dinosaurs, as no one machine suffered from all the flaws. In any case, modern machines use IEEE floating point (IEEE 754 and 854) or something very much like it, so the result of using LCAS would be considerable unneeded complexity and bloat. LCAS is in flux and is not supported by much field experience, while IEEE floating point arithmetic is currently in wide use, so IEEE arithmetic is much the better choice. Ref: "Analysis and Refutation of the LCAS", Professor W. Kahan, UCal Berkeley, ACM SIGPLAN Notices, V.27, N.1, Pp.61 et seq, January 1992. 2. It seems to me that specifying a reference "semantic" implementation without tolerance limits is overly constraining. Shouldn't we instead specify the mathematical function to be implemented, plus error bounds, and leave implementation issues alone? Design of numerical algorithms is something of a black art practiced mostly by Numerical Methods PhDs. The current semantic implementations could be kept in an appendix as a non-normative sample implementation. 3. Shouldn't we follow all the IEEE floating point formats, rather than limiting ourselves to just the fortran-like REAL? In any case, a FLOAT (= DOUBLE) is needed to allow widely-used legacy (IBM) machines to be used for critical simulations. The issue is that IBM mainframes' single-precision (32-bit) floating point arithmetic isn't all that accurate, forcing many people to use 64-bit floating point where other machines need only 32-bit arithmetic. The problem is fundamental, caused by the way floating point numbers are represented in memory. These legacy systems also are served if there is a easy global way to cause for instance REAL to be interpreted as if it were DOUBLE. 4. Be careful with the NBS Fortran Math Library tests. In many such test suites, the accuracy needed to get a passing grade varies with the platform, rather than simply the width of the floating point word, 32 or 64 bits. This variable tolerance for inaccuracy was intended to allow for instance IBM machines to pass. 5. I gather that FOREIGN means "coded in C'. It sounds as if the proposed interface will require conversion to strings and back, a very slow operation. Don't cripple VHDL/AHDL by requiring C interfaces to convert to strings and back. Remember, the C/C++ world is and will remain two or three orders of magnitude larger than the AHDL/VHDL (and Ada) world. 6. Naming the library simply "IEEE" is likely to lead to all manner of name conflicts. IEEE is at once too common and too simple. The IEEE has already standardized a number of languages, and will continue to do so. Suggest some long-winded and descriptive name like "AHDL_VHDL_Common_Math_Routines". 7. On the two Y**X functions, why is it necessary or a good idea to return an error when "X=0 and Y<=0.0" or "X<0 and Y<=0.0"? There are perfectly adequate and useful definitions of Y**X for these cases, and my HP calculator has no problem with them. 8. Is the pseudorandom stream generator UNIFORM reentrant? If one is to support multiple streams, it must be. Reentrancy isn't automatic, even if the underlying language of implementation supports reentrant procedures. It is also necessary that the reeentrant routine not have any static memory, such as the current seed values. Multiple streams are widely used in simulation, to prevent unintended coupling between parts of the simulation. Also widely used are multiple generator parameters (not just seeds); that is, one could have a number of different UNIFORM procedures, perhaps selected by a argument. Some implementations number streams from 1..100, and one would specify from which stream one wished to obtain the next random variate. 9. 10. Why are we defining CORDIC functions? First, this is an implementation. Second, are they really used in software (as opposed to coprocessors)? I think most transcendental packages use rational polynomials. ******* End of Joe Gwinn's comments ******** From 1076-1-request@sicmail.epfl.ch Sun May 14 21:57:32 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Sun, 14 May 95 21:57:29 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Sun, 14 May 95 21:57:24 -0400 Received: from mailgate.Cadence.COM by sicmail.epfl.ch with SMTP (PP) id <24313-0@sicmail.epfl.ch>; Mon, 15 May 1995 03:30:27 +0200 Received: (from smap@localhost) by mailgate.Cadence.COM (8.6.8/8.6.8) id SAA18159 for <1076-1@epfl.ch>; Sun, 14 May 1995 18:30:23 -0700 Received: from cds2072.cadence.com(158.140.24.54) by mailgate.cadence.com via smap (V1.0mjr) id sma018148; Sun May 14 18:30:11 1995 Received: from mailgate.Cadence.COM (mailgate.cadence.com [158.140.2.1]) by cds2072.Cadence.COM (8.6.8/8.6.8) with ESMTP id SAA05639 for ; Sun, 14 May 1995 18:30:06 -0700 Received: (from smap@localhost) by mailgate.Cadence.COM (8.6.8/8.6.8) id SAA18134 for ; Sun, 14 May 1995 18:30:04 -0700 Received: from vhdl.vhdl.org(198.31.14.3) by mailgate.cadence.com via smap (V1.0mjr) id sma018080; Sun May 14 18:29:51 1995 Received: by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA18195; Sun, 14 May 95 18:18:21 PDT Date: Sun, 14 May 95 18:18:21 PDT From: jose@vhdl.org (Jose Torres) Message-Id: <9505150118.AA18195@vhdl.vhdl.org> To: math@vhdl.org Subject: VITAL workshop For your information. If you are planning to attend DAC at San Francisco this year, then you may be interested on this workshop. >>>>> cut here VHDL INTERNATIONAL TO CONDUCT VITAL WORKSHOP SERIES First in Series Slated June 15-16 VHDL International is sponsoring a series of comprehensive two-day technical workshops to train ASIC library developement and modelling engineers to develop VHDL Initiative Toward ASIC Libraries (VITAL) models. The first workshop is scheduled June 15-16 at the Biltmore Hotel & Suites in Santa Clara, California. These seminars will help ASIC library developers world-wide to come up to speed rapidly on the VITAL 3.0 standard. Rapid adoption of the VITAL strategy for ASIC modeling will be beneficial for the ASIC and VHDL industry as a whole. Members of the IEEE VITAL team will be present at the workshop to assist partcipants and answer any questions during the design example session Some of the topics to be covered at the workshop are: * VITAL Overview * What is new in VITAL 3.0 and what has changed since 2.2b * Back Annotation Introduction to SDF (Purpose; Organization SDF to VITAL Mapping * VITAL Model Classification Level 0 Modeling (Requirements) Level 1 Modeling (Requirements) * Tables Truth Tables State Tables * Modeling Strategy Pin-to-pin Delay Modeling Distributed Delay Modeling Conditional delays and timing checks * Negative Timing Constraints Back Annotation and Negative Constraint Calculation Limitations * Application and Examples Combinational Model Sequential Models Bus Models Memories * Special Topics Differential Inputs Wired Logic Preleminary Workshop Agenda Day 1 June 15th, 1995 9:00 AM - 5:00 PM VITAL Basics SDF Delay styles Level 0 and level 1 requirements Day 2 June 16th, 1995 9:00 AM - 4:00 PM Application Design examples Negative constraints Changes from 2.2b Instructor: Ray Ryan, a full-time member of the technical staff at Synopsys in Mountain View, Calif., member of the IEEE Technical Action Group responsible for the VITAL specification and a former principal of Ryan & Ryan, will teach the workshop in Santa Clara. Course materials were developed by Ryan & Ryan of San Jose, Calif. Fees: $ 150.00 per person for VI corporate members $ 250.00 per person for non-members The fees include materials and lunch for two days. Cancellation Policy: A fee of $ 20.00 will be charged for cancellation prior to June 2, 95. 50% of the fees wil be refunded for cancellation between June 2 - June 9 No refund for cancellation after June 9th Payment: Cheque or credit card only. No Ppurchase orders. Make cheque payable to VHDL International Registration: The workshop is open on a first-come, first-served basis, with a limit of 100 attendees. For reservations, please provide the following info via fax or email to Lilia Periana of VHDL International: Name____________________________ Title_______________________ Company _______________________________________________________ Address________________________________________________________ ________________________________________________________ Tel: ____________________________Fax:________________________ email _____________________________ If paying by credit card then please provide the following: Credit card number:____________________________ Expires on:_______ Type of crdit card: Visa/MasterCard/________________________________ VHDL International, 3140 De La Cruz Blvd, Suite 200, Santa Clara, CA 95054 Tel: 408-492-9806 Fax: 408-970-4274 Email: viadmin@vhdl.org From 1076-1-request@sicmail.epfl.ch Mon May 15 12:54:49 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Mon, 15 May 95 12:54:46 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Mon, 15 May 95 12:54:42 -0400 Received: from tiny.sprintlink.net by sicmail.epfl.ch with SMTP (PP) id <13551-0@sicmail.epfl.ch>; Mon, 15 May 1995 18:38:17 +0200 Received: from analogy.com (analogy.analogy.com [149.117.1.1]) by tiny.sprintlink.net (8.6.9/8.6.9) with SMTP id MAA25066 for <1076-1@epfl.ch>; Mon, 15 May 1995 12:38:11 -0400 Received: from miller.analogy.com by analogy.com (4.1/Shared_Spool_1.3) id AA14216; Mon, 15 May 95 09:38:54 PDT Received: from satyr.analogy.com by miller.analogy.com (4.1/SMI-3.2) id AA25814; Mon, 15 May 95 09:38:53 PDT Received: by satyr.analogy.com (5.0/SMI-SVR4) id AA15979; Mon, 15 May 1995 09:38:52 -0700 Date: Mon, 15 May 1995 09:38:52 -0700 From: christen@analogy.com (Ernst Christen) Message-Id: <9505151638.AA15979@satyr.analogy.com> To: 1076-1@epfl.ch Subject: Computer Design article Content-Length: 2837 Some of you may have seen Steve Ohr's article in the May 1995 issue of Computer Design on "AHDL tools emerge before standards are realized". There are errors of fact and quotation in this article that may mislead readers. I would like to point out some of these errors, disassociate myself from some of the comments attributed to me and provide some additional context. I talked to Steve Ohr for about half an hour in January about the status of the 1076.1 language design work. Specifically, we talked about the issues that still (at that time) needed to be resolved, which included an explanation of syntax vs. semantics. To illustrate this and the kind of discussion that was going on at that time, I used the example of branch quantities and the question whether they have to be declared or not. I also mentioned that although we put a lot of emphasis on portability analog simulation results obtained with different tools will differ because both nonlinear solution techniques and numerical integration are subject to numerical errors. Finally, I mentioned the concern of the 1076.1 Working Group that the early VHDL-A-like tools _can_ cause confusion in the market place, an issue which has been resolved in the meantime by appropriate statements of the involved vendors. In his article Ohr first refers to me as the chairman of the 1076.1 working group. Well, I am not and, I never sought that position. Jean-Michel Berge has been chair for 2 years now and has just been confirmed for another 2 year term. In the first part of the section attributed to me Ohr's reporting is adequate although not correct compared to the conversation we had. The second part is completely wrong: I never said anything supporting Ohr's statement that "Christen believes ... MAST ... is more robust for analog use than [VHDL-A]." In fact I believe that robustness has several aspects. The one Ohr is referring to has nothing to do with the language. It is related to algorithms and is therefore a property of a tool. Concerning the language definition, the fact that the VHDL-A specifications will be completely documented (unlike proprietary languages, where part of the semantics are defined by the implementation) speaks for itself. There are other errors in Ohr's article. For instance, he associates analog extensions to Verilog with Anacad's HDL-A which he says will be ready by 1996. He also says that the VHDL-A developers "have attempted to embed transfer functions into the HDL code". Interesting, I never heard of this! I apologize if this article caused any confusion within the Working Group. I strongly believe in VHDL-A as the language for analog, digital and mixed analog/digital systems, and so does my company Analogy. Otherwise I would not spend as much time on it as I do. Ernst Christen 1076.1 vice-chair From 1076-1-request@sicmail.epfl.ch Tue May 16 14:02:39 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Tue, 16 May 95 14:02:05 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Tue, 16 May 95 14:01:47 -0400 Received: from newsgw.mentorg.com by sicmail.epfl.ch with SMTP (PP) id <07817-0@sicmail.epfl.ch>; Tue, 16 May 1995 19:18:47 +0200 Received: from wv.wv.mentorg.com by newsgw.mentorg.com (8.6.4/CF5.22R) id NAA02563; Tue, 16 May 1995 13:17:08 -0400 Received: from pdxml1.mentorg.com by wv.wv.mentorg.com (8.6.8.1/CF5.22R) id KAA16893; Tue, 16 May 1995 10:18:05 -0700 Message-Id: Date: 16 May 1995 10:01:24 -0800 From: Dan Damon Subject: Re: Comments raised by LAT m To: "Joe Gwinn, 508-440-3330" Cc: "1076.1 reflector" <1076-1@epfl.ch> X-Mailer: Mail*Link SMTP/QM 3.0.0 Reply to: RE>Comments raised by LAT minutes of 4-7 Apr 95 meeting Joe, It's certainly good to see that you have read the LAT minutes thoroughly. I think the minutes conveys the point that not all topics covered in the white papers have 100% approval by all members of the LAT. In fact, I think you have quite clearly outlined many points where there is disagreement among committee members. However, let me revisit the issue of a break statement. You stated that there was some disagreement if a break is even necessary. Most (if not all) LAT members agree that a break statement required under certain conditions. No one denies that this feature is necessary for efficient simulation under these conditions. However, the way the white paper is currently written, ALL discontinuities must be accompanied by a break statement, else that model is in error. Many committee members believe that some types of discontinuities should not require an explicit break statement. For example, any digital signal that drives an analog process (or relation if you prefer) is likely to produce a discontinuity. Why not anticipate that event instead of making the model writer explicitly state that there will be a discontinuity. As a potential model writer, I do not want to spend my days inserting break statements could be easily detected by the simulator. --Dan Damon -------------------------------------- Date: 5/12/95 17:38 To: Dan Damon From: Joe Gwinn, 508-440-3330 Received: by pdxml2.mentorg.com with SMTP;12 May 1995 17:33:37 U Received: from sicmail.epfl.ch by newsgw.mentorg.com (8.6.4/CF5.22R) id UAA17268; Fri, 12 May 1995 20:25:20 -0400 Received: from gatekeeper.ray.com by sicmail.epfl.ch with SMTP (PP) id <13189-0@sicmail.epfl.ch>; Sat, 13 May 1995 01:56:46 +0200 Received: from localhost (mailer@localhost) by gatekeeper.ray.com (8.6.4/8.6.5) id TAA26258 for <1076-1@epfl.ch>; Fri, 12 May 1995 19:55:27 -0400 Received: from sud2.ed.ray.com by gatekeeper.ray.com; Fri May 12 19:55:23 1995 Received: from SUD2.ED.RAY.COM by SUD2.ED.RAY.COM (PMDF V4.2-10 #4335) id <01HQFDIS1AKWA8FYI3@SUD2.ED.RAY.COM>; Fri, 12 May 1995 19:55:20 EDT Date: Fri, 12 May 1995 19:55:20 -0400 (EDT) From: "Joe Gwinn, 508-440-3330" Subject: Comments raised by LAT minutes of 4-7 Apr 95 meeting To: 1076-1@epfl.ch Message-id: <01HQFDIS1K8IA8FYI3@SUD2.ED.RAY.COM> X-Envelope-to: 1076-1@epfl.ch X-VMS-To: IN%"1076-1@epfl.ch" X-VMS-Cc: GWINN MIME-version: 1.0 Content-transfer-encoding: 7BIT I have a few comments to offer, after having read the LAT minutes. 1. With all the white papers becoming official documents, I would very much like to see them polished by a technical editor such as the IEEE's Mary Lynne Nielsen. The various documents are filled with lots of annoying little mistakes and unclear phrases, and will cause much trouble when a larger audience tries to read them. To be sure that the tech editor doesn't accidentially change the meaning of something, this polishing scan should be done before the documents are voted upon. 2. How does one specify the initial condition of an attribute? If ddt is an attribute, and as a consequence cannot be initialized, won't we then see a glitch whenever the analog solver is started or re-started? These glitches can be devastating. They can upset the solver, and can put undesired initial conditions on connected integrators. I would assume that ddt must be a function, so there is a way to specify its initial condition. [Richard Trihy may have been saying this, but the minutes weren't unambiguous, so I wanted to say it clearly, as it's a pet rock of mine.] 3. We seem to have lost Q'Rising and Q'Falling; only Q'Cross surviving. Well, direction often matters in that one does different things in the break code depending on direction. Now, one can certainly detect cross, then test a derivative's value within the break code. However, this forces the computation of an explicit derivative, which is somewhat more expensive. 4. On the issue of the break statement, I would comment that for models with essential discontinuities, like the bouncing ball, use of a break statement or its like is in practice essential, and not just a matter of a little bit of efficiency. One must be able to protect the analog solver from these discontinuities for the solution to be practical. And, a break statement, if correctly implemented, allows the solver to avoid creeping for fear of the discontinuity. An efficiency ratio of 100 or 1000 is a difference in kind in that a solver that slow cannot in practice be tolerated, so lack of break would preclude use of VHDL-A on the many systems with essential discontinuities. 5. We specifically excluded partial differential equations (PDEs) after some discussion some time ago. The way we excluded PDEs was by saying in DO2/DO6 that only lumped-element systems would be supported. Originally, the lumped-element requirement applied to electrical systems (DO2); this seems to have disappeared. Anyway, exclusion of PDEs is a good idea. We have bitten off quite enough as it is, and SPICE is our model. Joe Gwinn From 1076-1-request@sicmail.epfl.ch Tue May 16 15:16:54 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Tue, 16 May 95 15:16:51 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Tue, 16 May 95 15:16:46 -0400 Received: from tiny.sprintlink.net by sicmail.epfl.ch with SMTP (PP) id <09369-0@sicmail.epfl.ch>; Tue, 16 May 1995 21:07:15 +0200 Received: from analogy.com (analogy.analogy.com [149.117.1.1]) by tiny.sprintlink.net (8.6.9/8.6.9) with SMTP id PAA00979 for <1076-1@epfl.ch>; Tue, 16 May 1995 15:07:11 -0400 Received: from miller.analogy.com by analogy.com (4.1/Shared_Spool_1.3) id AA20891; Tue, 16 May 95 12:07:55 PDT Received: from satyr.analogy.com by miller.analogy.com (4.1/SMI-3.2) id AA28185; Tue, 16 May 95 12:07:54 PDT Received: by satyr.analogy.com (5.0/SMI-SVR4) id AA01545; Tue, 16 May 1995 12:07:53 -0700 Date: Tue, 16 May 1995 12:07:53 -0700 From: christen@analogy.com (Ernst Christen) Message-Id: <9505161907.AA01545@satyr.analogy.com> To: 1076-1@epfl.ch Subject: Next LAT meeting Content-Length: 1611 The next meeting of the 1076.1 Language Architecture Team will be held for 4 days during the week of DAC (Design Automation Conference), as follows: Monday, June 12 San Francisco Tuesday or Wednesday, June 13 or 14 San Francisco Thursday, June 15 San Jose Friday, June 16 San Jose Either Tuesday or Wednesday will be kept open for those who want to attend DAC. The 1076.1 Working Group meeting will then be held on Saturday, June 17, somewhere in the Valley. The issues that will be discussed at the meeting are based on the white papers that are currently being prepared by various people. Here is the list: - quantities and terminals - simultaneous statements, relations - simulation cycle, A/D and D/A interaction - time - initialization and DC analysis - solvability of DAEs - predefined language environment - frequency domain issues - SPICE compatibility issues - statistical analyses - elaboration - quantities as interface elements to subprograms - mixed netlists - simulation control - units and dimensions The discussions will include a review of the work that has been done so far. If you plan to attend the LAT meeting, please send me a message by May 30. Note however, that continuity is important, e.g. attending only parts of the meeting or some of the meetings may not be beneficial to you or the team. Also, meeting attendees are expected to have studied the white papers; they will be sent to them prior to the meeting. The detailed location and time of the meetings will be forwarded to the attendees about 7 to 10 days before the meeting. Thanks. Ernst Christen Chair LAT From 1076-1-request@sicmail.epfl.ch Tue May 16 16:59:26 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Tue, 16 May 95 16:59:23 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Tue, 16 May 95 16:59:18 -0400 Received: from gatekeeper.ray.com by sicmail.epfl.ch with SMTP (PP) id <16675-0@sicmail.epfl.ch>; Tue, 16 May 1995 22:17:55 +0200 Received: from localhost (mailer@localhost) by gatekeeper.ray.com (8.6.4/8.6.5) id QAA20891 for <1076-1@epfl.ch>; Tue, 16 May 1995 16:16:29 -0400 Received: from sud2.ed.ray.com by gatekeeper.ray.com; Tue May 16 16:17:39 1995 Received: from SUD2.ED.RAY.COM by SUD2.ED.RAY.COM (PMDF V4.2-10 #4335) id <01HQKQOS7M9CA99L7V@SUD2.ED.RAY.COM>; Tue, 16 May 1995 16:17:43 EDT Date: Tue, 16 May 1995 16:17:43 -0400 (EDT) From: "Joe Gwinn, 508-440-3330" Subject: Comments on Comments on LAT minutes To: 1076-1@epfl.ch Message-Id: <01HQKQOS8F76A99L7V@SUD2.ED.RAY.COM> X-Envelope-To: 1076-1@epfl.ch X-Vms-To: IN%"1076-1@epfl.ch" X-Vms-Cc: GWINN Mime-Version: 1.0 Content-Transfer-Encoding: 7BIT This is in response to Dan Damon's reply sent Tue, 16 May 1995 10:01:24. >However, let me revisit the issue of a break statement. You stated t= >hat there was some disagreement if a break is even necessary. Most (= >if not all) LAT members agree that a break statement required under c= >ertain conditions. No one denies that this feature is necessary for = >efficient simulation under these conditions. However, the way the w= >hite paper is currently written, ALL discontinuities must be accompan= >ied by a break statement, else that model is in error. =20 > >Many committee members believe that some types of discontinuities sho= >uld not require an explicit break statement. For example, any digit= >al signal that drives an analog process (or relation if you prefer) i= >s likely to produce a discontinuity. Why not anticipate that event i= >nstead of making the model writer explicitly state that there will be= > a discontinuity. As a potential model writer, I do not want to spen= >d my days inserting break statements could be easily detected by the = >simulator. My mental picture of break and its uses did not include required use at all one-bit (signal->quantity) D/A interfaces. My picture covered what I call "essential discontinuities", where the physics of the modeled system forces one to switch from one set of (well-behaved) equations to another set, with the break statement providing the place where user-provided fixup code can splice together the pieces of the piecewise continuous output curves, based on the physics of the modeled system. Even if there is no fixup code required, warning the solver of a mathematical discontinuity can be a great help to the solver. A set of equations containing a mathematical discontinuity is by definition not well-behaved. However, I can see an issue here. Injection of a ideal digital signal directly into an analog solution is likely to cause all manner of trouble. Now, this is still yet another kind of discontinuity -- an input quantity (=signal) contains a very large jump, a region of infinite slope. The analog equations can be perfectly well behaved, and yet there will be trouble, the solver may struggle and oscillate. The analog equations may well ring at each digital edge, excited by the implicit impulses in those edges. So, we now have three kinds of discontinuity here: essential, mathematical, and input signal. People do connect digital signals directly into analog circuits, and life goes on. So, why is this different? First of all, practical digital signals are always bandlimited, and so do not have infinite slope. Second, people tend not to connect digital signals to analog systems that will ring when so hammered, unless they want it to ring. Therefore, we have two problems here: The solver, a numerical integrator, may not handle step-function inputs at all gracefully. The real analog system itself may ring when struck. The first problem is an artifact of all practical solver implementations. The second is intrinsic to the system being modelled. So, I would propose that we solve the solver's problem, and ignore the ringing analog system problem. Therefore, all D->A conversions would have an implied low-pass filter (edges would have finite slope), and break statements would not in general be required, unless the user needed to run some fixup code. Now, the use of finite slope will cause a small time offset, but this is exactly as one sees in practical systems. There is always a typical maximum edge slope, characteristic of the logic family. I suppose that the A->D interface could instead or also internally warn the solver that it has been or is about to be fed an edge, and let the solver deal with it. If the user has no desire to add fixup code, it isn't obvious why one needs to call a break statement. The fact that we are connecting a digital signal to an analog quantity should suffice to allow the solver to do the right thing without difficulty. Simply stopping and restarting the solver exactly at the digital signal edge may well suffice. Joe Gwinn From 1076-1-request@sicmail.epfl.ch Tue May 16 17:34:05 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Tue, 16 May 95 17:34:03 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Tue, 16 May 95 17:33:54 -0400 Received: from sun5.vlsi.uwaterloo.ca by sicmail.epfl.ch with SMTP (PP) id <00599-0@sicmail.epfl.ch>; Tue, 16 May 1995 23:18:40 +0200 Received: by sun5.vlsi.uwaterloo.ca id ; Tue, 16 May 95 17:18:31 -0400 Date: Tue, 16 May 95 17:18:31 -0400 From: "J.A. Barby" Message-Id: <9505162118.AA19806@sun5.vlsi.uwaterloo.ca> To: 1076-1@epfl.ch Subject: Re: Comments on Comments on LAT minutes Return-Receipt-To: jabarby@sun5.vlsi.uwaterloo.ca > From 1076-1-request@sicmail.epfl.ch Tue May 16 16:59:26 1995 > From: "Joe Gwinn, 508-440-3330" > Subject: Comments on Comments on LAT minutes > To: 1076-1@epfl.ch > > This is in response to Dan Damon's reply sent Tue, 16 May 1995 10:01:24. > > >However, let me revisit the issue of a break statement. You stated t= > >hat there was some disagreement if a break is even necessary. Most (= > >if not all) LAT members agree that a break statement required under c= > >ertain conditions. No one denies that this feature is necessary for = > >efficient simulation under these conditions. However, the way the w= > >hite paper is currently written, ALL discontinuities must be accompan= > >ied by a break statement, else that model is in error. =20 > > > >Many committee members believe that some types of discontinuities sho= > >uld not require an explicit break statement. For example, any digit= > >al signal that drives an analog process (or relation if you prefer) i= > >s likely to produce a discontinuity. Why not anticipate that event i= > >nstead of making the model writer explicitly state that there will be= > > a discontinuity. As a potential model writer, I do not want to spen= > >d my days inserting break statements could be easily detected by the = > >simulator. > > My mental picture of break and its uses did not include required use > at all one-bit (signal->quantity) D/A interfaces. My picture covered > what I call "essential discontinuities", where the physics of the > modeled system forces one to switch from one set of (well-behaved) > equations to another set, with the break statement providing the place > where user-provided fixup code can splice together the pieces of the > piecewise continuous output curves, based on the physics of the modeled > system. > > Even if there is no fixup code required, warning the solver of a > mathematical discontinuity can be a great help to the solver. A set > of equations containing a mathematical discontinuity is by definition > not well-behaved. > > However, I can see an issue here. Injection of a ideal digital signal > directly into an analog solution is likely to cause all manner of > trouble. Now, this is still yet another kind of discontinuity -- an > input quantity (=signal) contains a very large jump, a region of > infinite slope. The analog equations can be perfectly well behaved, > and yet there will be trouble, the solver may struggle and oscillate. > The analog equations may well ring at each digital edge, excited by > the implicit impulses in those edges. > > So, we now have three kinds of discontinuity here: essential, > mathematical, and input signal. > > People do connect digital signals directly into analog circuits, and > life goes on. So, why is this different? First of all, practical > digital signals are always bandlimited, and so do not have infinite > slope. Second, people tend not to connect digital signals to analog > systems that will ring when so hammered, unless they want it to ring. > > Therefore, we have two problems here: The solver, a numerical integrator, > may not handle step-function inputs at all gracefully. The real analog > system itself may ring when struck. The first problem is an artifact > of all practical solver implementations. The second is intrinsic to the > system being modelled. > > So, I would propose that we solve the solver's problem, and ignore the > ringing analog system problem. Therefore, all D->A conversions would > have an implied low-pass filter (edges would have finite slope), and > break statements would not in general be required, unless the user needed > to run some fixup code. > > Now, the use of finite slope will cause a small time offset, but this > is exactly as one sees in practical systems. There is always a typical > maximum edge slope, characteristic of the logic family. > > I suppose that the A->D interface could instead or also internally warn the > solver that it has been or is about to be fed an edge, and let the solver > deal with it. If the user has no desire to add fixup code, it isn't obvious > why one needs to call a break statement. The fact that we are connecting a > digital signal to an analog quantity should suffice to allow the solver to > do the right thing without difficulty. Simply stopping and restarting the > solver exactly at the digital signal edge may well suffice. > > Joe Gwinn Joe, I suggest you read the paper "Analysis on Nonlinear Networks with Inconsistent Initial Conditions" by Vlach, Wojciechowski, & Opal in IEEE Trans on Circuits and Systems I: Fundamental Theory and Applications April 1995 (vol 42, No 4) pp 195-200 as it shows that numerical integrators can be made to handle step-function inputs and step discontinuities in the response functions. Basically, future solvers should be able to handle your we now have three kinds of discontinuity here: essential, mathematical, and input signal. If the solver knows an edge is happening, it should be able to deal gracefully with it. However, these are solver issues and not necessarily language issues. Jim Barby From 1076-1-request@sicmail.epfl.ch Thu May 18 13:35:36 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Thu, 18 May 95 13:35:26 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Thu, 18 May 95 13:35:16 -0400 Received: from gatekeeper.ray.com by sicmail.epfl.ch with SMTP (PP) id <27647-0@sicmail.epfl.ch>; Thu, 18 May 1995 18:08:41 +0200 Received: from localhost (mailer@localhost) by gatekeeper.ray.com (8.6.4/8.6.5) id MAA04282 for <1076-1@epfl.ch>; Thu, 18 May 1995 12:06:57 -0400 Received: from sud2.ed.ray.com by gatekeeper.ray.com; Thu May 18 12:06:37 1995 Received: from SUD2.ED.RAY.COM by SUD2.ED.RAY.COM (PMDF V4.2-10 #4335) id <01HQN8CLS7GWA94GD5@SUD2.ED.RAY.COM>; Thu, 18 May 1995 12:06:42 EDT Date: Thu, 18 May 1995 12:06:42 -0400 (EDT) From: "Joe Gwinn, 508-440-3330" Subject: Responses to Ken Bakalar and Jim Barbary To: 1076-1@epfl.ch Message-Id: <01HQN8CLSH42A94GD5@SUD2.ED.RAY.COM> X-Envelope-To: 1076-1@epfl.ch X-Vms-To: IN%"1076-1@epfl.ch" X-Vms-Cc: GWINN Mime-Version: 1.0 Content-Transfer-Encoding: 7BIT This is in response to Jim Barby's message sent Tue, 16 May 1995 17:18:31. >Joe, > >I suggest you read the paper > "Analysis on Nonlinear Networks with Inconsistent Initial > Conditions" by Vlach, Wojciechowski, & Opal in > IEEE Trans on Circuits and Systems > I: Fundamental Theory and Applications > April 1995 (vol 42, No 4) pp 195-200 >as it shows that numerical integrators can be made to handle step-function >inputs and step discontinuities in the response functions. Basically, >future solvers should be able to handle your > we now have three kinds of discontinuity here: essential, > mathematical, and input signal. >If the solver knows an edge is happening, it should be able to deal >gracefully with it. However, these are solver issues and not necessarily >language issues. Thanks for the reference. It's on order. I do have some initial reactions, though. First, this article is awfully young, so one wonders how much practical (academic or industrial) use this has gotten. Industrial use requires much more robust tools, as most industrial users are not experts in numerical methods, so we need to be very conservative about what we can assume to be practical for everyday use. But, on the other hand, we should ensure that the VHDL-A language provides the needed information to support advanced solver designs. How much is enough is a matter of judgement, of working group debate. In response to Kenneth Bakalar's message on "Comments raised by LAT minutes of 4-7 Apr 95 meeting", sent Tue, 16 May 1995 18:03:52. >I would greatly appreciate the aid of a technical editor. I didn't know >that the IEEE provided that service. It is true, as you say, that the >documents are unpolished, but you are too kind in not mentioning that they >contain not just minor, but major mistakes and omissions. They are works in >progress, which is what the LDC means by saying they are only >"provisionally" approved. If a vote of the WG is taken to use these results >in other subcommittees, this will not imply that the white papers are >accepted as is. Remember that what we will ballot is the revised LRM, >which must in the end stand or fall on its own merits. If editorial >assistance is a limited resource, we think that is where it should be >expended. I don't know that the IEEE does this, but we can certainly ask. They do make an editorial pass as part of the final publication process. Much of this materail will find its way into either the standard or the associated publications, which they will publish and sell, so they do have an interest. People can't really read these documents too many times before they cease to really read them, so we shouldn't use up their energy with documents that we don't believe in. Now, the various group members all seem to work for fairly large companies, ones that probably have technical writers on their staffs. These same companies are paying small fortunes to support the VHDL-A effort. I suspect they could easily be convinced to have one of those tech editors polish the texts. >The "tick" notation is used to form a certain class of names -- the >"attribute_name" nonterminal in the grammar. Attribute names can be the >names of a variety of different things; signals, functions, values, types >and ranges. To find out what a particular attribute name does and where it >can appear in the text, you have to look at the sort of thing the attribute >name names; thus S'Stable is a signal and so it can be used in a >sensitivity list, but S'Base is a type and cannot. We are proposing to >extend VHDL so that certain attribute names are the names of quantities and >terminals. Interesting, but how do I set the initial condition of a tick attribute? >You are correct that quantities (even quantities whose names are attribute >names) will need to be properly initialized. This is true regardless of the >syntax we choose for their names. The definition of initialization is >missing from the papers under discussion, although we understand its >importance and it is high priority topic right now in the discussion within >the LDC. So -- hold the phone? Sounds like a serious problem, one that should be solved quite soon. >We discarded the separate direction crossing signals on the grounds that >they are redundant (and then only after a lot of thought); that is, that >they add only a little convenience of use while complicating the >definition. > >In the definition as it stands, there is never any need to test the value >of the derivative after a crossing. If the crossing signal value is '1', >then the last crossing was necessarily in the positive going direction; if >'0', then in the negative direction. Ah. Why didn't you say so? If Q'Cross reports the direction, and its value can be used to prevent undesired breaks, then the problem is satisfied, and I can see why Q'Rising and Q'Falling are no longer needed. But, you must not keep it a secret. Remember, I can judge only what's on the net; I do not come to meetings. >PDEs have been excluded from the requirements and are not being considered. The point I was trying to make was that we needed to make the point that PDEs are excluded more clearly, by both putting the lumped-parameter qualification in the relevant places, and by saying in the rationales that the intent of the qualification is to exclude PDEs. In response to Kenneth Bakalar's message on "Comments on the 'Mixed-Mode Simulation' White Paper" sent Tue, 16 May 1995 18:04:03. >We do say so, but in an indirect way -- we say if you do not mark the >discontinuity with a break, all bets are off; your model is "erroneous" and >this document (and eventually, the LRM) can't tell you what to expect. The >LRM is written (to the dismay of many of its readers) with the intent of >instructing an implementor in what is required of a conforming >implementation, not with the intent of telling a modeler how to use the >language to solve his problem. That stuff goes in the rationale and in >tutorials. My point is that we are being too subtle. I don't buy the argument that implementors not part of the VHDL-A process will be any more able to read and correctly interpret our minds than the hapless users. And, if the impementors don't understand, portability of models and modelers will be lost, because those sadly misguided implementors will build many different variants of VHDL-A. Remember, if it isn't in the documents, it doesn't exist. Nothing said in a VHDL-A meeting counts; only the documents endure and, with luck, govern. And, if people on the net but not at meetings have trouble following, where does that leave people who will see only the published documents? >The language in the rationale is a little informal, but I don't think >misleading. The solver "resumes" at a certain place in the simulation >cycle; it calculates any number of ASPs and then it suspends. The period >between resumption and suspension is a "single invocation". Signals must >and will change while the solver is suspended; they never change after the >solver resumes but before it suspends. I don't agree that it doesn't matter if the rationale "is a little informal", and I do think it's misleading to those without benefit of meeting attendance. See prior comments. The language above would make a fine bit of rationale, and is much clearer than the existing text. So, let's use this new text. >>I would suggest that we need to explicitly state that signals are >>digital and quantities are analog. It is implied, but never clearly >>stated. > >Calling signals "digital" and quantities "analog" does give a first >approximation that may help a reader fix these ideas in his mind when he is >first learning VHDL-A. Perhaps this bit of explanation might go in the >introduction to the rationale. But what is essential is the way objects in >each class get their values during simulation. In the case of signals, it >is the driver update and hierarchical network evaluation algorithm >described in the LRM. For quantities, it's described in the Mixed-Mode >paper. Why not just call a spade a spade, and press on? There is no sin in writing simply and clearly. The rest is just a mass of confusing details. >>4. (Section 3.3, Potential Optimizations of the Simulation Cycle, last >>paragraph) Having an explicit break statement allows one to solve > >As you make clear in your exposition, a switch point is not so much a >characteristic of the model as a characterization of the designer's intent. >In the designer's mind the N dimensional quantity space is divided into a >number of N dimensional regions bounded by functions of the quantities. >Inside a region the behavior of the system is described by a >region-specific set of DAEs with coefficients that are either constants or >continous functions of time. When the trajectory of the sequence of ASPs >crosses the boundary into such a region, then the equations used in the >region just exited are put aside and a new set comes into effect. Perhaps "switch point" would be clearer. However, the essential discontinuities are in fact often true discontinuities in that some output curve has one or more kinks. What is forbidden are physically unrealizable discontinuities. >(We assume in the following that the region boundaries are static; that is, >they are not dependent on the history of the trajectory through quantity >space; or to put it another way, there is no hysteresis. The extension of >the argument to the case where there is a memory effect is straight >forward, however.) Support of hysteresis is required, as most physical systems exhibit it. >In many models, all quantities and their derivatives are continuous at >every region boundary and within every region. In that case there are a >number of different modeling techniques for implementing "equation >switching". The designer can use a condition test on the values of >quantities in a simultaneous statement: .... I suspect it's more general than that. With the sole known exception of black holes, all physical systems and their laws are continuous. For convenience, one often uses simplified laws that are discontinuous, but stays away from regions of bad behaviour. A classic example is the inverse square law of gravitation. In the usual formula, gravitational force is infinite at the center of the Earth. Not really so. In fact, once one passes below the Earth's surface, the force drops linearly from its value at the surface to zero at the center. Now, there is a more complex formula involving volume integration that captures this directly, but it's simpler to have two formulas and switch between them at the surface. And, the two-formula model is *much* faster running. >Each of the three techniques is useful in some situations. In each case, >all the quantities and their derivatives are continuous at the boundary >marked by the hyperplane Q1=0.0. Since no discontinuities occur anywhere, >no break statements need be executed at any time. Calculating an ASP at the >point where Q crosses zero is not required. Use of IF-THEN-ELSE logic has some problems. First, it's a great deal slower, as the logic must be invoked at each and every ASP. Second, merging wildly different formulas isn't likely to be either easy to do or the result clear to read. Very limiting, and a spaghetti-ball of a model will result. A break statement is much simpler and cleaner. >Any discontinuity in the generated function requires a break. We need to >calculate the left limit ASP at each break in order for the >simulation results to be correct at the end of that interval, which is >almost always required for calculating the right limit. We will need to >calculate a right limit ASP at each break because the values at the right >limit ASP are used as the initial values for the next continuous interval. >In the general case, the calculation of the right limit may involve new >initial conditions specified in the break set. Do people really write models where the solver is permitted to see a true mathematical discontinuity in the model? I bet they don't, at least not intentionally. I recall there was/is lots of trouble with erroneous SPICE models, ones where for instance the pieces of a piecewise continuous model didn't splice correctly. The resulting jump discontinuities often prevented convergence, resulting in striking simulation failures. I bet that hordes of perplexed users will call tech support. I suspect that we can simply ignore mathematical discontinuities in models and state that correct models have only essential discontinuities. Then, break statements need not worry about left and right ACPs, instead landing the ACP exactly on the switch point, as desired from the physics of the system being modeled. >In conclusion: not all switch points are associated with discontinuities in >a quantity, but some are. We only need breaks at discontinuities. >Therefore, we do not need a break at every switch point. There is not any >particular reason to calculate an ASP right at the switch point unless it >corresponds to a point of discontinuity. I disagree; see above point. >You are right in thinking that discontinuities (in a model that is not >"erroneous") can occur only at the splice points. As I explained above, the >overall result may or may not be piecewise continuous -- it depends on the >details. I guess I agree, but with the interpretation discussed above. >I see that the rhetorical approach taken here got your attention! Seriously >though, the definition section of the paper is quite clear on what the >conclusion is; the rationale is just explanation. The point I was making was that reversing the order will result in fewer misinterpretations. This is in response to Ken Bakalar's message on "Comments on the 'Simultaneous Statements' White Paper" sent Tue, 16 May 1995 18:04:21. >You are quite right is saying that the paper does not stand on its own. >"Simultaneous Statements" explains how to notate and evaluate the new class >of statements, but does not explain why you might want to do that. The >necessary context is set in a general way in the "architecture overview" >paper. For details on the simulation cycle ("when" the new statements get >evaluated) see the Mixed-Mode paper. The examples in the Mixed-Mode paper >use a number of different forms of simultaneous statements in appropriate >contexts. I can only judge what's on the net, on its own terms. The other papers seem to be much more free-standing than this one. If part of the explanation is somewhere else, a specific reference is in order. Don't make people guess. >With regard to question of "why have simultaneous statements at all?", I >draw your attention to the first paragraph of Section 3, the "Rationale", >where the purpose of simultaneous statements is described. Briefly, the >simultaneous statements are used to code the differential and algebraic >equations of the model -- no more, no less. For me, this is too general to be useful. Perhaps I would understand given some explanation to "set the stage", to motivate. >The language definition must state this operationally however; "If you >write this, this is how it will be evaluated, and this is the effect it >will have on the values of the unknowns." By its nature, LRM-ese has very >little tutorial value. Don't underestimate the need for clarity in a standard. A little explanation goes a long way. Natural languages are wonderfully imprecise, but flexible. Just stating the law, without also communicating the surrounding picture and reasoning, is a prescription for disaster. This is why IEEE standards have rationale sections. If the implementors do not understand, they will go in incompatible directions. Witness the early days of VMEbus. For FutureBus, the US Navy funded a number of prototypes as the standard was being developed. The output of these prototype contracts was the detection of mistakes of commission and omission in the draft standards, not hardware per se, the intent being to avoid repeating the mistakes of the early VMEbus standard. Joe Gwinn From 1076-1-request@sicmail.epfl.ch Thu May 18 16:55:33 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Thu, 18 May 95 16:55:28 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Thu, 18 May 95 16:55:21 -0400 Received: from tiny.sprintlink.net by sicmail.epfl.ch with SMTP (PP) id <15793-0@sicmail.epfl.ch>; Thu, 18 May 1995 22:47:35 +0200 Received: from analogy.com (analogy.analogy.com [149.117.1.1]) by tiny.sprintlink.net (8.6.9/8.6.9) with SMTP id QAA29227; Thu, 18 May 1995 16:47:22 -0400 Received: from miller.analogy.com by analogy.com (4.1/Shared_Spool_1.3) id AA02315; Thu, 18 May 95 13:48:06 PDT Received: from satyr.analogy.com by miller.analogy.com (4.1/SMI-3.2) id AA03163; Thu, 18 May 95 13:48:05 PDT Received: by satyr.analogy.com (5.0/SMI-SVR4) id AA03697; Thu, 18 May 1995 13:48:04 -0700 Date: Thu, 18 May 1995 13:48:04 -0700 From: christen@analogy.com (Ernst Christen) Message-Id: <9505182048.AA03697@satyr.analogy.com> To: GWINN@SUD2.ED.RAY.COM Subject: Re: Comments on the "VHDL-A Language Architecture" Cc: 1076-1@epfl.ch Content-Length: 7212 Reply to to Joe's comments. >These comments cover version 1.0 of the architecture. > >1. (Section 2.2, Conservative Systems) I don't think we ever come out and say >that natures must be internally consistent, that one cannot for instance >combine electric current as the through variable with hydraulic pressure as the >across variable. It's likely to be essential, but it's also likely that VHDL-A >cannot itself enforce consistency, unless we force users to chose from a >pre-ordained list, which is too limiting. > You are right that no statement about internal consistency is ever made in the VHDL-A Architecture Document, nor anywhere else. It is exactly for the reason that you state, that VHDL-A cannot enforce this consistency because it has no concept of what makes sense physically and what does not. However, there is no intention to let users chose from a pre-ordained list either. Rather, the language will provide the semantic framework that allows users to write natures that are related to the work that they are doing. The language semantics say exactly what each piece of the nature definition and declaration means. >2. (Section 2.2, Conservative Systems) Likewise, we never come out and say >that the product of a nature's through and across variables must be energy >flow (ie, power). It appears to me that the definition of "internally >consistent" is precisely that the through and across variables of a >given nature together describe an actual (not fictitious) power flow, >one whose size is given by their product. > You are right again, such a statement is never made. There are two reasons for this: 1. The same as above, i.e. the language itself does not have the concepts of power etc., so this kind of consistency cannot be enforced by the language. 2. The product of the across and through variables is not always power, although in many practical cases it is. In his book "Modeling Engineering Systems" (HighText Publications, 1994) Jack W. Lewis describes several physical disciplines. He says the following about thermal systems: [In analogy to electrical systems] temperature [in a thermal system] is the across variable, and heat flow rate is the through variable. ... We must be very careful with this analogy [, though,] when it comes to looking at power relationships. The rate of heat flow qh corresponds to power, as a consequence of the equivalency of heat and work stated by the first law of thermodynamics. ... >I'm not sure that the statement that natures from different diciplines >are incompatible because they have different reference terminals quite >captures the intent, although it may provide an enforcement mechanism >of sorts. It certainly isn't much help in explaining how one decides >what can and cannot be bundled together as a valid nature. > True, because the two issues are not related. The question of what can go into a nature is not part of the language, it is an aspect of how you use the language. On the other hand once you have created several different natures the statement says under which conditions they are compatible. In other words, whether it is legal to associate a terminal of one nature with a terminal of another nature. > >3. Another thing we never describe is how one would describe and model >an electrical transformer, or any kind of power-conserving transducer >(such as a loudspeaker or an electromagnetic microphone). I assume that >VHDL-A can do this, but it won't be obvious and would make a good example. > We have used a transformer example in a tutorial, but it is not part of the suite of examples distributed with the white papers because there is really nothing special about it. Here it is, for an n-port transformer: USE electrical_system.all; USE real_aux.all; -- contains definitions for real_vector, -- real_matrix and overloaded function "*" -- implementing matrix * vector ENTITY xfrm IS GENERIC (ml : real_matrix); -- self/mutual inductances PORT (TERMINAL p, m : elec_array); END ENTITY xfrm; ARCHITECTURE one OF xfrm IS QUANTITY v ACROSS i THROUGH p TO m; -- arrays! BEGIN v == ml * real_vector(i'dot); END ARCHITECTURE one; We can add this example to the ones in the white paper easily. >4. (Section 2.4, Simulation Cycle) We should spell one femtosecond out, >as "1 fs" is too easily mangled in reproduction. Likewise nanosecond, >et al. > The usage was intentional. The unit name fs (meaning femtosecond) is a standard part of VHDL. >5. (Section 2.5, Initialization, DC Simulation) We should note that >there may be multiple valid DC operating points. We keep talking of >"the DC operating point", as if there could be only one. Flopflops >have two DC operating points. Many complex analog circuits have more >than one, and part of design is to ensure that the circuit picks the >right one. SPICE models are famous for sometimes needing to be led to >the correct operating point. So, we should instead speak of "a DC >operating point", and we should provide a way in VHDL-A to specify >a starting point from which to start the search for a DC operating >point. > The problem is worse than than you think; the flip-flop has 3 DC operating points, not two (although only two are stable). Seriously though, the issue you point out needs careful consideration. The whole matter of initialization, of which DC initialization is a part, is an active area of investigation right now. We would like to define a way to choose among multiple DC operating points that is independent of the solver algorithm. > >6. (Section 3.1, Math Package Support) When I read the initial VHDL >Math postings of perhaps a year (or two?) ago, my impression was that >they had strayed from requirements into prescribed implementation, >with actual code, which is generally a no-no. The required behaviour >and accuracy should be described in mathematical terms, and be left >at that. And, it was never clear why we (VHDL or VHDL-A) needed to >provide a definition for the sine function et al; these are well >understood, and provided on all platforms one is likely to use for >VHDL-A. There were a few functions, like CORDIC, that are uncommon, >so it would make sense to describe and standardize them, but no others. > We all agree that the modeling of continuous time systems requires the availability of mathematical functions, e.g. trigonometric, exponential etc. To make them available in VHDL-A these functions must be declared somewhere. We believe that the math package should be this place, and its details are of great importance to us. The math package consists of two packages, one supporting real types, the other for complex types. Each package consists of a package header and a package body. The declaration of the functions is contained in the package header, a sample implementation is given in the package body. The issue described in the VHDL-A Architecture Document is that of the status of the package body: is it part of the standard or is it just an appendix? We are working with the 1076.2 group to resolve this issue. >Joe Gwinn Ernst Christen From 1076-1-request@sicmail.epfl.ch Thu May 18 18:25:46 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Thu, 18 May 95 18:25:39 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Thu, 18 May 95 18:25:35 -0400 Received: from sol.compass-da.com by sicmail.epfl.ch with SMTP (PP) id <28652-0@sicmail.epfl.ch>; Fri, 19 May 1995 00:02:36 +0200 Received: from [162.17.30.152] ([162.17.30.152]) by clsi.columbia.compass-da.com (8.6.9/8.6.9) with SMTP id RAA18906 for <1076-1@epfl.ch>; Thu, 18 May 1995 17:55:16 -0400 Reply-To: kenb@compass-da.com X-Sender: kennyb@clsi.columbia.compass-da.com (Unverified) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 18 May 1995 18:02:15 -0400 To: 1076-1@epfl.ch From: kenb@compass-da.com (Kenneth Bakalar) Subject: missing comments You may have seen Joe Gwynn's response to a set of comments attributed to me. Unfortunately, I made an addressing error that contrary to my intention sent the responses to Joe only, rather than to the working group at large. I will now correct that error, and I urge you to take a look at the original context before you consider Joe's response in detail. From 1076-1-request@sicmail.epfl.ch Thu May 18 18:25:56 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Thu, 18 May 95 18:25:51 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Thu, 18 May 95 18:25:46 -0400 Received: from sol.compass-da.com by sicmail.epfl.ch with SMTP (PP) id <28663-0@sicmail.epfl.ch>; Fri, 19 May 1995 00:03:07 +0200 Received: from [162.17.30.152] ([162.17.30.152]) by clsi.columbia.compass-da.com (8.6.9/8.6.9) with SMTP id RAA18912 for <1076-1@epfl.ch>; Thu, 18 May 1995 17:55:30 -0400 Reply-To: kenb@compass-da.com X-Sender: kennyb@clsi.columbia.compass-da.com (Unverified) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 18 May 1995 18:02:29 -0400 To: 1076-1@epfl.ch From: kenb@compass-da.com (Kenneth Bakalar) Subject: Re: Comments on the "Mixed-Mode Simulation" White Paper My comments on your reaction to the Mixed-Mode paper. ------------------------------ >1. (Section 2.1, Break Statements) We make the correct statement that >"A model that exhibits a discontinuity ... and does not execute a >break statement ... is erroneous". However, we fail to make it clear >that we expect the user to write a break statement for each and every >essential discontinuity of his model, that the solver is not wrong to >stumble if it encounters a discontinuity unaided. See my item 4. We do say so, but in an indirect way -- we say if you do not mark the discontinuity with a break, all bets are off; your model is "erroneous" and this document (and eventually, the LRM) can't tell you what to expect. The LRM is written (to the dismay of many of its readers) with the intent of instructing an implementor in what is required of a conforming implementation, not with the intent of telling a modeler how to use the language to solve his problem. That stuff goes in the rationale and in tutorials. > > >2. Also see my comment (#4) about break statement in my comments on the >minutes from the 4-7 April 1995 LAT meeting. For convenience, I >repeat that comment here: > >On the issue of the break statement, I would comment that for models with >essential discontinuities, like the bouncing ball, use of a break statement or >its like is in practice essential, and not just a matter of a little bit of >efficiency. One must be able to protect the analog solver from these >discontinuities for the solution to be practical. And, a break statement, if >correctly implemented, allows the solver to avoid creeping for fear of the >discontinuity. An efficiency ratio of 100 or 1000 is a difference in kind in >that a solver that slow cannot in practice be tolerated, so lack of break >would preclude use of VHDL-A on the many systems with essential >discontinuities. We all agree with you about the sign reversal in the bouncing ball problem. In fact, Mixed-Mode makes an even stronger argument; that all discontinuities must be signaled by breaks. We haven't got everybody around to this opinion yet. I have extended the argument in Mixed-Mode I made for this position below. > > >3. (Section 3.1, The Mixed-Mode Simulation Cycle, 2nd paragraph, last >sentence) The statement "No signal (not even a signal Q'Cross(E)) >can change value between any two ASPs generated during a single >invocation of the analog solver" seems a bit indirect. Aren't >we trying to say that signals don't change while the analog solver >is in control? I guess the business about Q'Cross(E) would appear to >imply that its signal must be buffered until after the analog kernel >relinquishes control. What about cases where the analog kernel is >setting digital signals, such as A/Ds? > >Also, the sentence doesn't seem quite right. I think what was intended is that >signals do not change between *adjacent* ASPs. Otherwise, the signal cannot >change at all, as one can choose any pair of ASPs. The language in the rationale is a little informal, but I don't think misleading. The solver "resumes" at a certain place in the simulation cycle; it calculates any number of ASPs and then it suspends. The period between resumption and suspension is a "single invocation". Signals must and will change while the solver is suspended; they never change after the solver resumes but before it suspends. Before I go on I need to treat a minor matter of LRM-ese. Q'Cross(E) is the name of a signal, so its okay to say that it "has a signal" (the signal it denotes), but it probably more clear to say that it _is_ (or denotes) a signal. The same relationship exists between any signal and a name that denotes the signal. The drivers of the signals Q'Cross(E) are updated by the analog solver just before it suspends. The solver decides to suspend prematurely (before the next "digital event") just because some Q'Cross(E) needs to be updated. The signal update itself is the responsibility of the VHDL kernel process. There is no time delay between detection and reporting. You might want to think of the driver of a signal Q'Cross(E) as the buffer. The drivers of the signals Q'Cross(E) are the _only_ drivers that the solver updates. Other signals can be effected by the values for quantities that the solver calculates, but that happens in a signal assignment statement, not in the solver. For example, here is a concurrent signal assignment statement that schedules a new value for S that depends on the values of two quantities: S <= Q2 after 5 ns when Q1'Cross(0.0)='1'; This statement executes when Q1 passes through zero in the positive direction. The value of Q2 is "sampled" at that time. The sample will appear on S 5 ns later. > >I would suggest that we need to explicitly state that signals are >digital and quantities are analog. It is implied, but never clearly >stated. Calling signals "digital" and quantities "analog" does give a first approximation that may help a reader fix these ideas in his mind when he is first learning VHDL-A. Perhaps this bit of explanation might go in the introduction to the rationale. But what is essential is the way objects in each class get their values during simulation. In the case of signals, it is the driver update and hierarchical network evaluation algorithm described in the LRM. For quantities, it's described in the Mixed-Mode paper. > > >4. (Section 3.3, Potential Optimizations of the Simulation Cycle, last >paragraph) Having an explicit break statement allows one to solve >discontinuous models without having left and right ASPs. As discussed in item >3 above, the ASP must land exactly on the essential discontinuity. What saves >you is that an essential discontinuity is not the mathematical discontinuity of >a function, is is a place where the physics of the problem being modeled forces >one to switch from one set of well-behaved functions to another different but >still well-behaved set of functions. So, landing an ASP exactly on the >essential discontinuity incurs no risk of mathematical discontinuity, and the >left and right ACPs will therefore both exist and will be equal. It seems that you are using the words "essential discontinuity" to mean a point where there is no discontinuity (or, at least, not necessarily a discontinuity) in the sense used in the theory of systems subject to analysis by limit processes. If that is the case, then I would rather call such a point by a name that doesn't use the word discontinuity -- for example, "switch point". As you make clear in your exposition, a switch point is not so much a characteristic of the model as a characterization of the designer's intent. In the designer's mind the N dimensional quantity space is divided into a number of N dimensional regions bounded by functions of the quantities. Inside a region the behavior of the system is described by a region-specific set of DAEs with coefficients that are either constants or continous functions of time. When the trajectory of the sequence of ASPs crosses the boundary into such a region, then the equations used in the region just exited are put aside and a new set comes into effect. (We assume in the following that the region boundaries are static; that is, they are not dependent on the history of the trajectory through quantity space; or to put it another way, there is no hysteresis. The extension of the argument to the case where there is a memory effect is straight forward, however.) In many models, all quantities and their derivatives are continuous at every region boundary and within every region. In that case there are a number of different modeling techniques for implementing "equation switching". The designer can use a condition test on the values of quantities in a simultaneous statement: if Q1>0.0 use Q2'dot == Q1**2; else Q2'dot == Q1**3; end use; he can use a function call within a simultaneous statement: Q2'dot == Q1**choose(Q1>0.0,2,3); [function choose returns an integer which is the second argument if the first (boolean) argument is true, otherwise the third argument] or he can use a signal: S <= 2 when Q1'Cross(0.0)= '1' else 3; Q2'dot == Q1**S; Each of the three techniques is useful in some situations. In each case, all the quantities and their derivatives are continuous at the boundary marked by the hyperplane Q1=0.0. Since no discontinuities occur anywhere, no break statements need be executed at any time. Calculating an ASP at the point where Q crosses zero is not required. Now compare the following fragments: if Q1>2.0 use Q2'dot == Q1**2; else Q2'dot == Q1**3; end use; ... Q'dot2 == Q1**choose(Q1>2.0,2,3); ... S <= 2 when Q1'Cross(2.0)= '1' else 3; Q2'dot == Q1**S; In each case, a discontinuity in the derivative of Q2 is introduced as the system crosses Q1=2.0 and a break is now required. We could introduce the break using the concurrent form of the break statement: break on Q1'cross(2.0); Any discontinuity in the generated function requires a break. We need to calculate the left limit ASP at each break in order for the simulation results to be correct at the end of that interval, which is almost always required for calculating the right limit. We will need to calculate a right limit ASP at each break because the values at the right limit ASP are used as the initial values for the next continuous interval. In the general case, the calculation of the right limit may involve new initial conditions specified in the break set. In conclusion: not all switch points are associated with discontinuities in a quantity, but some are. We only need breaks at discontinuities. Therefore, we do not need a break at every switch point. There is not any particular reason to calculate an ASP right at the switch point unless it corresponds to a point of discontinuity. > >We have been using "discontinuity" loosely, covering both kinds, but >they are very different, and perhaps we should be more precise in our >discussions. So, "essential" means that the physical system being >modeled has a discontinuity, a boundary between regions following >different descriptive laws. > >I believe that we intend to permit what I call "essential discontinuities", >and to forbid "mathematical discontinuities". In fact, it was expected >that the solver could assume that the function it was generating was >continuous with all its derivatives, and discontinuities were to be >permitted only at the splice points between invocations of the analog >solver. The overall result is a piecewise continuous function. You are right in thinking that discontinuities (in a model that is not "erroneous") can occur only at the splice points. As I explained above, the overall result may or may not be piecewise continuous -- it depends on the details. > > >5. (Section 3.7.2, Detecting Discontinuities, first paragraph) I was >all ready to fire missiles at the statement that break statements are >unnecessary, until I read the rest of the section. I would suggest >rearranging this section into the form followed by >. I see that the rhetorical approach taken here got your attention! Seriously though, the definition section of the paper is quite clear on what the conclusion is; the rationale is just explanation. > > >Joe Gwinn From 1076-1-request@sicmail.epfl.ch Thu May 18 18:26:09 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Thu, 18 May 95 18:26:01 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Thu, 18 May 95 18:25:56 -0400 Received: from sol.compass-da.com by sicmail.epfl.ch with SMTP (PP) id <28676-0@sicmail.epfl.ch>; Fri, 19 May 1995 00:03:25 +0200 Received: from [162.17.30.152] ([162.17.30.152]) by clsi.columbia.compass-da.com (8.6.9/8.6.9) with SMTP id RAA18915 for <1076-1@epfl.ch>; Thu, 18 May 1995 17:55:51 -0400 Reply-To: kenb@compass-da.com X-Sender: kennyb@clsi.columbia.compass-da.com (Unverified) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 18 May 1995 18:02:51 -0400 To: 1076-1@epfl.ch From: kenb@compass-da.com (Kenneth Bakalar) Subject: Re: Comments raised by LAT minutes of 4-7 Apr 95 meeting Thank you for your careful review of the LAT materials sent to the reflector. Your comments have stimulated a good deal of useful discussion. I offer some comments on your comments on the LAT minutes here. I will respond to your comments on the white papers separately. ------------------- >I have a few comments to offer, after having read the LAT minutes. > >1. With all the white papers becoming official documents, I would very >much like to see them polished by a technical editor such as the IEEE's >Mary Lynne Nielsen. The various documents are filled with lots of >annoying little mistakes and unclear phrases, and will cause much >trouble when a larger audience tries to read them. To be sure >that the tech editor doesn't accidentially change the meaning of >something, this polishing scan should be done before the documents >are voted upon. > I would greatly appreciate the aid of a technical editor. I didn't know that the IEEE provided that service. It is true, as you say, that the documents are unpolished, but you are too kind in not mentioning that they contain not just minor, but major mistakes and omissions. They are works in progress, which is what the LDC means by saying they are only "provisionally" approved. If a vote of the WG is taken to use these results in other subcommittees, this will not imply that the white papers are accepted as is. Remember that what we will ballot is the revised LRM, which must in the end stand or fall on its own merits. If editorial assistance is a limited resource, we think that is where it should be expended. >2. How does one specify the initial condition of an attribute? If ddt is an >attribute, and as a consequence cannot be initialized, won't we then see a >glitch whenever the analog solver is started or re-started? These glitches can >be devastating. They can upset the solver, and can put undesired initial >conditions on connected integrators. I would assume that ddt must be a >function, so there is a way to specify its initial condition. [Richard Trihy >may have been saying this, but the minutes weren't unambiguous, so I wanted to >say it clearly, as it's a pet rock of mine.] The "tick" notation is used to form a certain class of names -- the "attribute_name" nonterminal in the grammar. Attribute names can be the names of a variety of different things; signals, functions, values, types and ranges. To find out what a particular attribute name does and where it can appear in the text, you have to look at the sort of thing the attribute name names; thus S'Stable is a signal and so it can be used in a sensitivity list, but S'Base is a type and cannot. We are proposing to extend VHDL so that certain attribute names are the names of quantities and terminals. You are correct that quantities (even quantities whose names are attribute names) will need to be properly initialized. This is true regardless of the syntax we choose for their names. The definition of initialization is missing from the papers under discussion, although we understand its importance and it is high priority topic right now in the discussion within the LDC. > >3. We seem to have lost Q'Rising and Q'Falling; only Q'Cross surviving. >Well, direction often matters in that one does different things in the >break code depending on direction. Now, one can certainly detect cross, >then test a derivative's value within the break code. However, this >forces the computation of an explicit derivative, which is somewhat >more expensive. We discarded the separate direction crossing signals on the grounds that they are redundant (and then only after a lot of thought); that is, that they add only a little convenience of use while complicating the definition. In the definition as it stands, there is never any need to test the value of the derivative after a crossing. If the crossing signal value is '1', then the last crossing was necessarily in the positive going direction; if '0', then in the negative direction. In some cases only one direction is "interesting". For example, a particular model might need to do something when a positive crossing occurs, but do nothing when a negative crossing occurs. If this is so, the calculation of the exact time of the event that is generated for the negative crossing is potentially inefficient, but no functionality is lost by doing so. If you write the following statement in a process: wait until Q'Cross(0.0) = '1'; the process will continue only when Q crosses zero in the positive going direction. If you want to wait for a crossing in either direction, write: wait on Q'Cross(0.0); > >4. On the issue of the break statement, I would comment that for models with >essential discontinuities, like the bouncing ball, use of a break statement or >its like is in practice essential, and not just a matter of a little bit of >efficiency. One must be able to protect the analog solver from these >discontinuities for the solution to be practical. And, a break statement, if >correctly implemented, allows the solver to avoid creeping for fear of the >discontinuity. An efficiency ratio of 100 or 1000 is a difference in kind in >that a solver that slow cannot in practice be tolerated, so lack of break >would preclude use of VHDL-A on the many systems with essential >discontinuities. The Mixed-Mode paper agrees with you, but we haven't got everybody around to this opinion yet. In fact, Mixed-Mode makes an even stronger argument; that all discontinuities are "essential" in your sense, and that all must be signaled by breaks. More on this subject later in my comments (on your comments on) the Mixed-mode paper. > >5. We specifically excluded partial differential equations (PDEs) after >some discussion some time ago. The way we excluded PDEs was by saying >in DO2/DO6 that only lumped-element systems would be supported. Originally, >the lumped-element requirement applied to electrical systems (DO2); this >seems to have disappeared. Anyway, exclusion of PDEs is a good idea. We >have bitten off quite enough as it is, and SPICE is our model. PDEs have been excluded from the requirements and are not being considered. > > >Joe Gwinn From 1076-1-request@sicmail.epfl.ch Thu May 18 18:26:53 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Thu, 18 May 95 18:26:49 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Thu, 18 May 95 18:26:45 -0400 Received: from sol.compass-da.com by sicmail.epfl.ch with SMTP (PP) id <28657-0@sicmail.epfl.ch>; Fri, 19 May 1995 00:03:00 +0200 Received: from [162.17.30.152] ([162.17.30.152]) by clsi.columbia.compass-da.com (8.6.9/8.6.9) with SMTP id RAA18909 for <1076-1@epfl.ch>; Thu, 18 May 1995 17:55:22 -0400 Reply-To: kenb@compass-da.com X-Sender: kennyb@clsi.columbia.compass-da.com (Unverified) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 18 May 1995 18:02:21 -0400 To: 1076-1@epfl.ch From: kenb@compass-da.com (Kenneth Bakalar) Subject: Re: Comments on the "Simultaneous Statements" White Paper Here are my comments (on your comments) on Simultaneous Statements ------------------------ >I must say that one is left wondering after reading the paper on >Simultaneous Statements. It seems to start in the middle, lost in the >details. What's missing is an explanantion of the motivation. Why do >we need this new class of VHDL-A statements? What problem are we >solving? What bad thing happens if we don't have these statements? > >As near as I could tell from reading the paper, these statements are >some kind of assertion with which one detects model errors, but I don't >think that interpretation is correct. Some other white paper said >something about using simultaneous statements to enforce conservation >laws. > >I am not expressing an opinion on the technical merits of simultaneous >statements. I am saying that I don't understand them well enough to >judge the issue, and would like to see this paper expanded and clarified. > >Joe Gwinn You are quite right is saying that the paper does not stand on its own. "Simultaneous Statements" explains how to notate and evaluate the new class of statements, but does not explain why you might want to do that. The necessary context is set in a general way in the "architecture overview" paper. For details on the simulation cycle ("when" the new statements get evaluated) see the Mixed-Mode paper. The examples in the Mixed-Mode paper use a number of different forms of simultaneous statements in appropriate contexts. With regard to question of "why have simultaneous statements at all?", I draw your attention to the first paragraph of Section 3, the "Rationale", where the purpose of simultaneous statements is described. Briefly, the simultaneous statements are used to code the differential and algebraic equations of the model -- no more, no less. The language definition must state this operationally however; "If you write this, this is how it will be evaluated, and this is the effect it will have on the values of the unknowns." By its nature, LRM-ese has very little tutorial value. From 1076-1-request@sicmail.epfl.ch Fri May 19 13:11:41 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Fri, 19 May 95 13:11:34 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Fri, 19 May 95 13:11:27 -0400 Received: from gatekeeper.ray.com by sicmail.epfl.ch with SMTP (PP) id <25959-0@sicmail.epfl.ch>; Fri, 19 May 1995 18:16:54 +0200 Received: from localhost (mailer@localhost) by gatekeeper.ray.com (8.6.4/8.6.5) id MAA19250 for <1076-1@epfl.ch>; Fri, 19 May 1995 12:15:22 -0400 Received: from sud2.ed.ray.com by gatekeeper.ray.com; Fri May 19 12:16:02 1995 Received: from SUD2.ED.RAY.COM by SUD2.ED.RAY.COM (PMDF V4.2-10 #4335) id <01HQOQKYZU8GA97XQK@SUD2.ED.RAY.COM>; Fri, 19 May 1995 12:16:09 EDT Date: Fri, 19 May 1995 12:16:09 -0400 (EDT) From: "Joe Gwinn, 508-440-3330" Subject: References to instruct users on through and across To: 1076-1@epfl.ch Message-Id: <01HQOQKZ03VMA97XQK@SUD2.ED.RAY.COM> X-Envelope-To: 1076-1@epfl.ch X-Vms-To: IN%"1076-1@epfl.ch" X-Vms-Cc: GWINN Mime-Version: 1.0 Content-Transfer-Encoding: 7BIT Some time ago, there was a discussion of suitable references to teach users about through and across variables, and I promised a reference or two. Here are two, plus one provided by Peter Lieberman. "Introduction to Physical System Dynamics", Ronald C. Rosenberg and Dean C. Karnopp, McGraw-Hill 1983. A very clearly written book on Bond Graphs and their use in modeling all manner of physical systems. As I understand it, this was the first real textbook on Bond Graphs, and popularized the approach. "Continuous System Modelling", Francois Cellier, 1991. Very good book on Bond Graphs. A companion book, "Continuous System Simulation", is to appear, perhaps as soon as spring 1995. "Feedback Control for Analysis and Synthesis", D'Azzo and Houpis, John Wiley & Sons, 1967. Suggested by Peter Liebmann of Compass in a posting to the AHDL working group on Wed, 15 Mar 1995 14:51:27. Joe Gwinn From 1076-1-request@sicmail.epfl.ch Fri May 19 14:36:37 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Fri, 19 May 95 14:36:30 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Fri, 19 May 95 14:36:22 -0400 Received: from sol.compass-da.com by sicmail.epfl.ch with SMTP (PP) id <27795-0@sicmail.epfl.ch>; Fri, 19 May 1995 20:19:03 +0200 Received: from [162.17.30.155] ([162.17.30.155]) by clsi.columbia.compass-da.com (8.6.9/8.6.9) with SMTP id OAA24543; Fri, 19 May 1995 14:11:02 -0400 Reply-To: kenb@compass-da.com X-Sender: kennyb@clsi.columbia.compass-da.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 19 May 1995 14:18:08 -0400 To: "Joe Gwinn, 508-440-3330" From: kenb@compass-da.com (Kenneth Bakalar) Subject: Re:Responses to Ken Bakalar and Jim Barbary Cc: 1076-1@epfl.ch To continue the discussion... ============================== >This is in response to Jim Barby's message sent Tue, 16 May 1995 17:18:31. > >>Joe, >> >>I suggest you read the paper >> "Analysis on Nonlinear Networks with Inconsistent Initial >> Conditions" by Vlach, Wojciechowski, & Opal in >> IEEE Trans on Circuits and Systems >> I: Fundamental Theory and Applications >> April 1995 (vol 42, No 4) pp 195-200 >>as it shows that numerical integrators can be made to handle step-function >>inputs and step discontinuities in the response functions. Basically, >>future solvers should be able to handle your >> we now have three kinds of discontinuity here: essential, >> mathematical, and input signal. >>If the solver knows an edge is happening, it should be able to deal >>gracefully with it. However, these are solver issues and not necessarily >>language issues. > >Thanks for the reference. It's on order. I do have some initial >reactions, though. First, this article is awfully young, so one wonders >how much practical (academic or industrial) use this has gotten. >Industrial use requires much more robust tools, as most industrial users >are not experts in numerical methods, so we need to be very conservative >about what we can assume to be practical for everyday use. But, on >the other hand, we should ensure that the VHDL-A language provides the >needed information to support advanced solver designs. How much is >enough is a matter of judgement, of working group debate. > Let me add my two cents. Vlach et. al. show that if the time of a discontinuity is known, then there is a mathematically well-founded algorithm for reinitializing after the discontinuity. The solver algorithm is not part of VHDL-A so we won't include that algorithm in the definition. But we will provide the means to flag discontinuities -- the break statement. > > >In response to Kenneth Bakalar's message on "Comments raised by LAT minutes >of 4-7 Apr 95 meeting", sent Tue, 16 May 1995 18:03:52. > >>I would greatly appreciate the aid of a technical editor. I didn't know >>that the IEEE provided that service. It is true, as you say, that the >>documents are unpolished, but you are too kind in not mentioning that they >>contain not just minor, but major mistakes and omissions. They are works in >>progress, which is what the LDC means by saying they are only >>"provisionally" approved. If a vote of the WG is taken to use these results >>in other subcommittees, this will not imply that the white papers are >>accepted as is. Remember that what we will ballot is the revised LRM, >>which must in the end stand or fall on its own merits. If editorial >>assistance is a limited resource, we think that is where it should be >>expended. > >I don't know that the IEEE does this, but we can certainly ask. They do >make an editorial pass as part of the final publication process. Much >of this materail will find its way into either the standard or the >associated publications, which they will publish and sell, so they >do have an interest. > >People can't really read these documents too many times before they >cease to really read them, so we shouldn't use up their energy with >documents that we don't believe in. Now, the various group members >all seem to work for fairly large companies, ones that probably have >technical writers on their staffs. These same companies are paying >small fortunes to support the VHDL-A effort. I suspect they could >easily be convinced to have one of those tech editors polish the texts. > Are you volunteering Raytheon's technical writers? Any help will be welcome! COMPASS' technical writers are all tied up... The LDC is trying to achieve the proper balance between publishing only well-reviewed and polished documents on the one hand and keeping the WG up to date on the progress of our work on the other. It is possible to ere on one side or the other, but we try. > > >>The "tick" notation is used to form a certain class of names -- the >>"attribute_name" nonterminal in the grammar. Attribute names can be the >>names of a variety of different things; signals, functions, values, types >>and ranges. To find out what a particular attribute name does and where it >>can appear in the text, you have to look at the sort of thing the attribute >>name names; thus S'Stable is a signal and so it can be used in a >>sensitivity list, but S'Base is a type and cannot. We are proposing to >>extend VHDL so that certain attribute names are the names of quantities and >>terminals. > >Interesting, but how do I set the initial condition of a tick attribute? I take you to mean an attribute name denoting a quantity. We don't have syntax yet for the initial conditions of quantities. We are still working out the details of the semantics. That has to come first. > >>You are correct that quantities (even quantities whose names are attribute >>names) will need to be properly initialized. This is true regardless of the >>syntax we choose for their names. The definition of initialization is >>missing from the papers under discussion, although we understand its >>importance and it is high priority topic right now in the discussion within >>the LDC. > >So -- hold the phone? Sounds like a serious problem, one that should >be solved quite soon. Yes indeed. > > >>We discarded the separate direction crossing signals on the grounds that >>they are redundant (and then only after a lot of thought); that is, that >>they add only a little convenience of use while complicating the >>definition. >> >>In the definition as it stands, there is never any need to test the value >>of the derivative after a crossing. If the crossing signal value is '1', >>then the last crossing was necessarily in the positive going direction; if >>'0', then in the negative direction. > >Ah. Why didn't you say so? If Q'Cross reports the direction, and its >value can be used to prevent undesired breaks, then the problem is >satisfied, and I can see why Q'Rising and Q'Falling are no longer >needed. But, you must not keep it a secret. Remember, I can judge only >what's on the net; I do not come to meetings. This consequence of the definition was never explicitly drawn out. I will put the paragraph above in the rationale. I already use the idea in the examples -- see the bouncing ball. >>PDEs have been excluded from the requirements and are not being considered. > >The point I was trying to make was that we needed to make the point that >PDEs are excluded more clearly, by both putting the lumped-parameter >qualification in the relevant places, and by saying in the rationales >that the intent of the qualification is to exclude PDEs. > > >In response to Kenneth Bakalar's message on "Comments on the 'Mixed-Mode >Simulation' White Paper" sent Tue, 16 May 1995 18:04:03. > > >>We do say so, but in an indirect way -- we say if you do not mark the >>discontinuity with a break, all bets are off; your model is "erroneous" and >>this document (and eventually, the LRM) can't tell you what to expect. The >>LRM is written (to the dismay of many of its readers) with the intent of >>instructing an implementor in what is required of a conforming >>implementation, not with the intent of telling a modeler how to use the >>language to solve his problem. That stuff goes in the rationale and in >>tutorials. > >My point is that we are being too subtle. I don't buy the argument that >implementors not part of the VHDL-A process will be any more able to >read and correctly interpret our minds than the hapless users. And, >if the impementors don't understand, portability of models and modelers >will be lost, because those sadly misguided implementors will build >many different variants of VHDL-A. Remember, if it isn't in the >documents, it doesn't exist. Nothing said in a VHDL-A meeting counts; >only the documents endure and, with luck, govern. > >And, if people on the net but not at meetings have trouble following, >where does that leave people who will see only the published documents? This is another case in which a logical deduction from the definition was not explicitly drawn out. I certainly did not intend to write a document which depends on the extra-sensory abilities of the members of the WG (though it is well known that ESP is more higly developed among implementors than users). I would like to hear from a referee among you implementors out there who are reading (or are otherwise tuned in to) this discussion -- is the level and form of the definition appropriate for the LRM, or is it not? > >>The language in the rationale is a little informal, but I don't think >>misleading. The solver "resumes" at a certain place in the simulation >>cycle; it calculates any number of ASPs and then it suspends. The period >>between resumption and suspension is a "single invocation". Signals must >>and will change while the solver is suspended; they never change after the >>solver resumes but before it suspends. > >I don't agree that it doesn't matter if the rationale "is a little >informal", and I do think it's misleading to those without benefit of >meeting attendance. See prior comments. The language above would make >a fine bit of rationale, and is much clearer than the existing text. >So, let's use this new text. The definition is quite formal; the rationale is a little less so because it tries to get across the major ideas while leaving out obscuring detail. I will take your suggestion and put the new text in the document. > > >>>I would suggest that we need to explicitly state that signals are >>>digital and quantities are analog. It is implied, but never clearly >>>stated. >> >>Calling signals "digital" and quantities "analog" does give a first >>approximation that may help a reader fix these ideas in his mind when he is >>first learning VHDL-A. Perhaps this bit of explanation might go in the >>introduction to the rationale. But what is essential is the way objects in >>each class get their values during simulation. In the case of signals, it >>is the driver update and hierarchical network evaluation algorithm >>described in the LRM. For quantities, it's described in the Mixed-Mode >>paper. > >Why not just call a spade a spade, and press on? There is no sin in >writing simply and clearly. The rest is just a mass of confusing details. I do strive for simplicity and clarity. Most of the work goes in to getting those details just right. We need to heed Eintein's dictum -- make it simple, but not too simple. > >>>4. (Section 3.3, Potential Optimizations of the Simulation Cycle, last >>>paragraph) Having an explicit break statement allows one to solve >> >>As you make clear in your exposition, a switch point is not so much a >>characteristic of the model as a characterization of the designer's intent. >>In the designer's mind the N dimensional quantity space is divided into a >>number of N dimensional regions bounded by functions of the quantities. >>Inside a region the behavior of the system is described by a >>region-specific set of DAEs with coefficients that are either constants or >>continous functions of time. When the trajectory of the sequence of ASPs >>crosses the boundary into such a region, then the equations used in the >>region just exited are put aside and a new set comes into effect. > >Perhaps "switch point" would be clearer. However, the essential >discontinuities are in fact often true discontinuities in that some >output curve has one or more kinks. What is forbidden are physically >unrealizable discontinuities. I agree that switch points are often points of discontinuity. As for the rest, I take you to mean something like this: The language is intended for modeling real physical systems but it is beyond the power of a tool like this one to determine whether a model is physically realizable. We can't write enough rules in the language defintion to forbid unrealizable models. It's up to the designer to avoid writing them. > > >>(We assume in the following that the region boundaries are static; that is, >>they are not dependent on the history of the trajectory through quantity >>space; or to put it another way, there is no hysteresis. The extension of >>the argument to the case where there is a memory effect is straight >>forward, however.) > >Support of hysteresis is required, as most physical systems exhibit it. We've got you covered. > > >>In many models, all quantities and their derivatives are continuous at >>every region boundary and within every region. In that case there are a >>number of different modeling techniques for implementing "equation >>switching". The designer can use a condition test on the values of >>quantities in a simultaneous statement: .... > >I suspect it's more general than that. With the sole known exception >of black holes, all physical systems and their laws are continuous. >For convenience, one often uses simplified laws that are discontinuous, >but stays away from regions of bad behaviour. A classic example is >the inverse square law of gravitation. In the usual formula, gravitational >force is infinite at the center of the Earth. Not really so. In fact, >once one passes below the Earth's surface, the force drops linearly from >its value at the surface to zero at the center. Now, there is a more >complex formula involving volume integration that captures this directly, >but it's simpler to have two formulas and switch between them at the >surface. And, the two-formula model is *much* faster running. I agree. Some systems are described using piece-wise continous formulations with discontinuities at the end points of the continuous intervals.I talked about that (and gave some examples) in my original response. > > >>Each of the three techniques is useful in some situations. In each case, >>all the quantities and their derivatives are continuous at the boundary >>marked by the hyperplane Q1=0.0. Since no discontinuities occur anywhere, >>no break statements need be executed at any time. Calculating an ASP at the >>point where Q crosses zero is not required. > >Use of IF-THEN-ELSE logic has some problems. First, it's a great deal >slower, as the logic must be invoked at each and every ASP. You would have to show me why you think that. Using a conditional shouldn't be any slower than any of the other techniques for switching equations I showed in my original response. >Second, merging wildly different formulas isn't likely to be either easy to >do or the result clear to read. Very limiting, and a spaghetti-ball of >a model will result. The conditional simultaneous statement gives an extra pound of pasta to the modeler, with which he may, as you suggest, strangle himself. But the statement itself is not a death sentence. > A break statement is much simpler and cleaner. Breaks are required at discontinuitites, whatever the source. Extra breaks are harmless, but inefficient. A break does not by itself, however, cause changes to the equations or create discontinuities. It is the other way around; discontinuities in the equations cause the modeler to insert breaks. > >>Any discontinuity in the generated function requires a break. We need to >>calculate the left limit ASP at each break in order for the >>simulation results to be correct at the end of that interval, which is >>almost always required for calculating the right limit. We will need to >>calculate a right limit ASP at each break because the values at the right >>limit ASP are used as the initial values for the next continuous interval. >>In the general case, the calculation of the right limit may involve new >>initial conditions specified in the break set. > >Do people really write models where the solver is permitted to see a true >mathematical discontinuity in the model? I bet they don't, at least not >intentionally. I recall there was/is lots of trouble with erroneous >SPICE models, ones where for instance the pieces of a piecewise continuous >model didn't splice correctly. The resulting jump discontinuities often >prevented convergence, resulting in striking simulation failures. I bet >that hordes of perplexed users will call tech support. SPICE, and other simulators as well, suffer from the defect you describe -- or rather it's the users (and the applications engineers at the other end of the tech support line) that do the suffering. The substance of the argument concerning the need for break statements is directed towards solving this problem. The model must warn the solver that the time of a discontinuity has arrived using a break statement. Only then can the model safely let the solver "see" the discontinuity. > >I suspect that we can simply ignore mathematical discontinuities in >models and state that correct models have only essential discontinuities. >Then, break statements need not worry about left and right ACPs, instead >landing the ACP exactly on the switch point, as desired from the physics >of the system being modeled. I agree that discontinuitites between break points -- your mathematical discontinuities -- are forbidden. I agree that discontinuities must be signaled by breaks -- your essential discontinuity. However, the calculation of both left and right limits are required at a discontinuity. The argument I made above concerning the required processing at a discontinuity is motivated by the mathematical foundation of the solution of DAEs. See for example, K.E. Brenan, S.L. Campbell and L.R. Petsold: "Numerical Solution of Initial Value Problems in Differential-Algebraic Equations", North Holland (1989), page 138 et. seq. for an example of an algorithm for initialization. > >>In conclusion: not all switch points are associated with discontinuities in >>a quantity, but some are. We only need breaks at discontinuities. >>Therefore, we do not need a break at every switch point. There is not any >>particular reason to calculate an ASP right at the switch point unless it >>corresponds to a point of discontinuity. > >I disagree; see above point. I am not sure which of my several statements you are disagreeing with. I hope my preceding comments have touched on the relevant points. > >>You are right in thinking that discontinuities (in a model that is not >>"erroneous") can occur only at the splice points. As I explained above, the >>overall result may or may not be piecewise continuous -- it depends on the >>details. > >I guess I agree, but with the interpretation discussed above. > >>I see that the rhetorical approach taken here got your attention! Seriously >>though, the definition section of the paper is quite clear on what the >>conclusion is; the rationale is just explanation. > >The point I was making was that reversing the order will result in fewer >misinterpretations. > > >This is in response to Ken Bakalar's message on "Comments on the >'Simultaneous Statements' White Paper" sent Tue, 16 May 1995 18:04:21. > > >>You are quite right is saying that the paper does not stand on its own. >>"Simultaneous Statements" explains how to notate and evaluate the new class >>of statements, but does not explain why you might want to do that. The >>necessary context is set in a general way in the "architecture overview" >>paper. For details on the simulation cycle ("when" the new statements get >>evaluated) see the Mixed-Mode paper. The examples in the Mixed-Mode paper >>use a number of different forms of simultaneous statements in appropriate >>contexts. > >I can only judge what's on the net, on its own terms. The other papers >seem to be much more free-standing than this one. If part of the >explanation is somewhere else, a specific reference is in order. Don't >make people guess. The papers are all interrelated, like the chapters of a book. Publishing on the reflector means dividing things up into mail-sized pieces. Ernst Christen's cover letter contains the table of contents. it might be better to have a home page for this stuff -- I think almost everybody has access to a Web client these days. > > >>With regard to question of "why have simultaneous statements at all?", I >>draw your attention to the first paragraph of Section 3, the "Rationale", >>where the purpose of simultaneous statements is described. Briefly, the >>simultaneous statements are used to code the differential and algebraic >>equations of the model -- no more, no less. > >For me, this is too general to be useful. Perhaps I would understand >given some explanation to "set the stage", to motivate. > > >>The language definition must state this operationally however; "If you >>write this, this is how it will be evaluated, and this is the effect it >>will have on the values of the unknowns." By its nature, LRM-ese has very >>little tutorial value. > >Don't underestimate the need for clarity in a standard. A little explanation >goes a long way. Natural languages are wonderfully imprecise, but flexible. >Just stating the law, without also communicating the surrounding picture >and reasoning, is a prescription for disaster. This is why IEEE standards >have rationale sections. If the implementors do not understand, they will go >in incompatible directions. Witness the early days of VMEbus. For FutureBus, >the US Navy funded a number of prototypes as the standard was being developed. >The output of these prototype contracts was the detection of mistakes of >commission and omission in the draft standards, not hardware per se, the >intent being to avoid repeating the mistakes of the early VMEbus standard. > I have spent many hours writing and rewriting to achieve clarity and precision. Whether I have succeeded is for others to judge. The definition is, as you say, the law. Each object and notion must be defined exactly once. If something is defined twice using two different sets of words it is no longer possible to determine which definition is the cononical one. Didactic presentations are very important as well. Redundancy, context-setting, examples and informal reasoning ("sales talk") are all approriate in this context. The rationale and examples sections of the white papers are written with didactic intent as is the VHDL-A Architecture document. However, an implementor who relies on didactic presentations is courting disaster. A standard which is written with sufficient clarity and precision to allow mistakes to be readily pinpointed is a well written standard. I will be very pleased if we have accomplished as much in these working documents. I wasn't aware that IEEE standards commonly have rationale sections; as it happens, the VHDL LRM does not have one, though it doesn have a sprinkling of explantory footnotes. > >Joe Gwinn Ken Bakalar From 1076-1-request@sicmail.epfl.ch Mon May 22 18:21:32 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Mon, 22 May 95 18:21:08 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Mon, 22 May 95 18:21:02 -0400 Received: from gatekeeper.ray.com by sicmail.epfl.ch with SMTP (PP) id <04838-0@sicmail.epfl.ch>; Mon, 22 May 1995 23:42:07 +0200 Received: from localhost (mailer@localhost) by gatekeeper.ray.com (8.6.4/8.6.5) id RAA09978 for <1076-1@epfl.ch>; Mon, 22 May 1995 17:40:34 -0400 Received: from sud2.ed.ray.com by gatekeeper.ray.com; Mon May 22 17:41:10 1995 Received: from SUD2.ED.RAY.COM by SUD2.ED.RAY.COM (PMDF V4.2-10 #4335) id <01HQT6EBY45CA96RPV@SUD2.ED.RAY.COM>; Mon, 22 May 1995 17:41:08 EDT Date: Mon, 22 May 1995 17:41:08 -0400 (EDT) From: "Joe Gwinn, 508-440-3330" Subject: More comments on comments wrt Ernst's and Ken's comments To: 1076-1@epfl.ch Message-Id: <01HQT6EBY45EA96RPV@SUD2.ED.RAY.COM> X-Envelope-To: 1076-1@epfl.ch X-Vms-To: IN%"1076-1@epfl.ch" X-Vms-Cc: GWINN Mime-Version: 1.0 Content-Transfer-Encoding: 7BIT Response to Ken Bakalar's comments posted Fri, 19 May 95. >Let me add my two cents. Vlach et. al. show that if the time of a >discontinuity is known, then there is a mathematically well-founded >algorithm for reinitializing after the discontinuity. The solver algorithm >is not part of VHDL-A so we won't include that algorithm in the definition. >But we will provide the means to flag discontinuities -- the break >statement. I read this article over the weekend. I seems quite cogent to me, and easily accomodated by VHDL-A. I agree that the break statement appears to provide adequate information to a solver to support this algorithm. BTW, Figure 1 (Network with inconsistent initial voltage conditions) is widely used in industrial sensor networks, where it would be called a "flying-capacitor sampler". More commonly, there is a double pole double throw switch, with the capacitor flying from source to measuring instrument and back. This design has essentially infinite common-mode rejection ratio, and can easily withstand kilovolts of common mode signal. A classic use would be to measure the temperature of an electrode in an electric-arc steel smelting furnace -- the millivolt-level thermocouple signal is transferred from the ten kilovolt electrode down to ground, where ordinary instruments can amplify and measure the thermocouple signal. >Are you volunteering Raytheon's technical writers? Any help will be >welcome! COMPASS' technical writers are all tied up... No, I'm not. My interest in VHDL-A exceeds Raytheon's. Isn't the US Govt underwriting much of this effort? And, we aren't talking about weeks of effort here. >The LDC is trying to achieve the proper balance between publishing only >well-reviewed and polished documents on the one hand and keeping the WG up >to date on the progress of our work on the other. It is possible to ere on >one side or the other, but we try. Ah, well, we still need a cleanup pass every so often. >This is another case in which a logical deduction from the definition was >not explicitly drawn out. I certainly did not intend to write a document >which depends on the extra-sensory abilities of the members of the WG >(though it is well known that ESP is more higly developed among >implementors than users). And among attendees than non-attendees. >I would like to hear from a referee among you implementors out there who >are reading (or are otherwise tuned in to) this discussion -- is the level >and form of the definition appropriate for the LRM, or is it not? I would submit that this is the wrong test. The resulting standard and associated documents will be read by people completely uninvolved in the current process. It would be more informative to try the current documents out on a naive implementor. This and only this will reveal the unspoken yet critical agreements and assumptions, and thus will tell us exactly what needs to be buttressed. >>Use of IF-THEN-ELSE logic has some problems. First, it's a great deal >>slower, as the logic must be invoked at each and every ASP. > >You would have to show me why you think that. Using a conditional shouldn't >be any slower than any of the other techniques for switching equations I >showed in my original response. A break statement executes once in a while, not once per ACP. The detection of crossing, while it must be executed once per ACP, is much simpler than the IF-THEN-ELSE nest it will replace, and can be closely integrated compiled code within the analog solver. By contrast, the IF-THEN-ELSE code is in most simulators effectively interpreted in the same sense that Pascal P-Code was interpreted -- the output of the compiler was not native assembly/machine code for the target processor. >>Second, merging wildly different formulas isn't likely to be either easy to >>do or the result clear to read. Very limiting, and a spaghetti-ball of >>a model will result. > >The conditional simultaneous statement gives an extra pound of pasta to the >modeler, with which he may, as you suggest, strangle himself. But the >statement itself is not a death sentence. The point I was making was that it's much simpler and cleaner to write (and to read) a model consisting of two sets of equations plus some break statements to switch between them, than a merged model where the equation sets are intertwined with lots of conditional code providing the glue. If it's hard to read and understand, it's hard to review and to get right. >I wasn't aware that IEEE standards commonly have rationale sections; as it >happens, the VHDL LRM does not have one, though it doesn have a sprinkling >of explantory footnotes. I don't know that *all* IEEE standards come with rationale, but IEEE's POSIX (1003 series) standards certainly all do. So does Ada83 and Ada95. I don't know how VHDL escaped. The rationale is generally as long as the standard itself. VHDL and VHDL-A will mostly be run on POSIX-compliant platforms. Responses to Ernst Christen's comments: >You are right again, such a statement is never made. There are two reasons for >this: >1. The same as above, i.e. the language itself does not have the concepts > of power etc., so this kind of consistency cannot be enforced by the > language. I would be happy if it were discussed in the rationale. The users should at least be given a hint. >2. The product of the across and through variables is not always power, > although in many practical cases it is. In his book "Modeling Engineering > Systems" (HighText Publications, 1994) Jack W. Lewis describes several > physical disciplines. He says the following about thermal systems: > [In analogy to electrical systems] temperature [in a thermal system] > is the across variable, and heat flow rate is the through variable. ... > We must be very careful with this analogy [, though,] when it comes to > looking at power relationships. The rate of heat flow qh corresponds > to power, as a consequence of the equivalency of heat and work > stated by the first law of thermodynamics. ... Hmm. Now that you mention it, I do recall that exception. Cellier's book also discusses this, that thermodynamic variables are the exception. I don't recall that there were any other significant exceptions, though. Although some Bond Graph researchers were trying to apply BGs to Quantum Mechanics. Anyway, I submit that users and implementors would find it very illuminating to know that with the exception of thermodynamics (which they flunked anyway), the product of through and across is generally a true energy flow. The references can also direct the intrepid to selected textbooks. BTW, I don't agree that only implementors will read the standard. If past history is any judge, more users will read the standard than implementors. >We all agree that the modeling of continuous time systems requires the >availability of mathematical functions, e.g. trigonometric, exponential etc. >To make them available in VHDL-A these functions must be declared somewhere. >We believe that the math package should be this place, and its details are >of great importance to us. I guess I was asking a somewhat sharp question: If we (VHDL-A) do nothing but enumerate by name the required mathematical functions and their calling sequences, but do not otherwise define them, what bad thing will happen? Are we asking for anything not commonly found in the math library of every computer system on the market? (Complex functions of a complex variable might be the exception.) Are we really going to discover that someone forgot to include the Sine function, crippling VHDL-A? Joe Gwinn From 1076-1-request@sicmail.epfl.ch Tue May 23 10:31:35 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Tue, 23 May 95 10:31:33 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Tue, 23 May 95 10:31:26 -0400 Received: from mailgate.Cadence.COM by sicmail.epfl.ch with SMTP (PP) id <00752-0@sicmail.epfl.ch>; Wed, 10 May 1995 21:51:09 +0200 Received: (from smap@localhost) by mailgate.Cadence.COM (8.6.8/8.6.8) id MAA28271 for <1076-1@epfl.ch>; Wed, 10 May 1995 12:51:03 -0700 Received: from cds2072.cadence.com(158.140.24.54) by mailgate.cadence.com via smap (V1.0mjr) id sma028201; Wed May 10 12:50:54 1995 Received: from mailgate.Cadence.COM (mailgate.cadence.com [158.140.2.1]) by cds2072.Cadence.COM (8.6.8/8.6.8) with ESMTP id MAA08434 for ; Wed, 10 May 1995 12:50:46 -0700 Received: (from smap@localhost) by mailgate.Cadence.COM (8.6.8/8.6.8) id MAA28156 for ; Wed, 10 May 1995 12:50:43 -0700 Received: from vhdl.vhdl.org(198.31.14.3) by mailgate.cadence.com via smap (V1.0mjr) id sma028121; Wed May 10 12:50:25 1995 Received: by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA25069; Wed, 10 May 95 12:38:57 PDT Date: Wed, 10 May 95 12:38:57 PDT From: jose@vhdl.org (Jose Torres) Message-Id: <9505101938.AA25069@vhdl.vhdl.org> To: math@vhdl.org Subject: Math package status The purpose of this message is to let you know where we are at regarding the balloting of P1076.2. The status is as follows: 1) All the material was submitted to IEEE about 2 weeks ago. 2) IEEE is currently in the process of putting together the balloting packages. Their distribution will most probably happen within the next three weeks. 3) The last version of the package is located in the directory /vi/math/package at vhdl.org in the following files math_head.3.24.95.vhd -- package declaration math_body.3.24.95.vhd -- package body or math.3.24.95.tar.Z -- compressed tar file of the previous two 4) A template for the test bench is available now, but I need volunteers to fill in the information in the test bench before we can make it available. The job consists on entering input and output values, as well as running a simulator on it to check that things are in order. If you do not have access to ftp and want to have a copy of the package, please let me know it and I will e-mail the package to you. Regards, Jose A. Torres From 1076-1-request@sicmail.epfl.ch Tue May 23 18:46:36 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Tue, 23 May 95 18:46:32 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Tue, 23 May 95 18:46:26 -0400 Received: from tiny.sprintlink.net by sicmail.epfl.ch with SMTP (PP) id <04454-0@sicmail.epfl.ch>; Wed, 24 May 1995 00:28:41 +0200 Received: from analogy.com (analogy.analogy.com [149.117.1.1]) by tiny.sprintlink.net (8.6.9/8.6.9) with SMTP id SAA03788 for <1076-1@epfl.ch>; Tue, 23 May 1995 18:28:38 -0400 Received: from miller.analogy.com by analogy.com (4.1/Shared_Spool_1.3) id AA25050; Tue, 23 May 95 15:29:27 PDT Received: from popeye.analogy.com by miller.analogy.com (4.1/SMI-3.2) id AA11876; Tue, 23 May 95 15:29:27 PDT Received: by popeye.analogy.com (5.0/SMI-SVR4) id AA12996; Tue, 23 May 1995 15:29:25 -0700 Date: Tue, 23 May 1995 15:29:25 -0700 From: steveg@analogy.com (Steven Greenberg) Message-Id: <9505232229.AA12996@popeye.analogy.com> To: 1076-1@epfl.ch Subject: Re: Responses to Ken Bakalar and Jim Barbary X-Sun-Charset: US-ASCII Content-Length: 1083 >>In the definition as it stands, there is never any need to test the value >>of the derivative after a crossing. If the crossing signal value is '1', >>then the last crossing was necessarily in the positive going direction; if >>'0', then in the negative direction. > >Ah. Why didn't you say so? If Q'Cross reports the direction, and its >value can be used to prevent undesired breaks, then the problem is >satisfied, and I can see why Q'Rising and Q'Falling are no longer >needed. But, you must not keep it a secret. Remember, I can judge only >what's on the net; I do not come to meetings. The misunderstanding could have been avoided if the name of the variable had been chosen with more care. The variable is true if you are above the threshold and false if you are not above. "...that the variable associated with each signal Q'cross(E) for any prefix Q and value E has the value '1' if the sign of Q-E is positive and '0' otherwise." So the variable does not tell you about "cross". It tells you about "above". Q'above(E) would be one possible name. /Steve From 1076-1-request@sicmail.epfl.ch Wed May 24 11:09:07 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Wed, 24 May 95 11:08:48 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Wed, 24 May 95 11:08:30 -0400 X400-Received: by mta sicmail.epfl.ch in /PRMD=switch/ADMD=arCom/C=ch/; Relayed; Wed, 24 May 1995 16:28:05 +0200 Date: Wed, 24 May 1995 16:28:05 +0200 X400-Originator: 1076-1-request@sicmail.epfl.ch X400-Recipients: non-disclosure:; X400-Mts-Identifier: [/PRMD=switch/ADMD=arCom/C=ch/;sicmail.ep.930:24.04.95.14.28.05] Priority: Non-Urgent Dl-Expansion-History: 1076-1@epfl.ch ; Wed, 24 May 1995 16:28:03 +0200; From: "Jean-michel.Berge" Message-Id: To: analog_reflector <1076-1@epfl.ch> Subject: VHDL-A meeting during DASC in SF X-Mailer: Mail*Link SMTP/MS 3.0.0 Dear all, I have sent a call for "open questions" on the reflector. No answer. Since this meeting is very close from the previous one (In San-Diego), I consider that this meeting will mainly be the following of the previous one and only distribute a generic agenda. It will be a full-day meeting somewhere in the bay area (I will take you aware), starting at 8h30. I hope to be able to close the meeting at 16h00. Here is the agenda. o Working Group Status --> (result of votes) o Language Design Work presentation of the LAT results: updates of the "White Papers" already presented in San Diego + new WPs(Spice, Environment) --> several hours o Validation Status --> about 30 min o Documentation Status --> about 30 min o Open Questions (If any) From 1076-1-request@sicmail.epfl.ch Wed May 24 11:58:21 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Wed, 24 May 95 11:58:13 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Wed, 24 May 95 11:58:07 -0400 Received: from utep.el.utwente.nl by sicmail.epfl.ch with SMTP (PP) id <23929-0@sicmail.epfl.ch>; Wed, 24 May 1995 16:58:01 +0200 Received: from nt.el.utwente.nl (utelnt.el.utwente.nl) by utep.el.utwente.nl with SMTP id AA08484 (5.65c/IDA-1.4.4 for <1076-1@epfl.ch>); Wed, 24 May 1995 16:57:01 +0200 Message-Id: <199505241457.AA08484@utep.el.utwente.nl> Received: by nt.el.utwente.nl (1.37.109.4/16.2) id AA06696; Wed, 24 May 95 16:59:07 +0100 From: Marq Kole Subject: Quantity syntax To: 1076-1@epfl.ch Date: Wed, 24 May 95 16:59:07 WETDST Mailer: Elm [revision: 70.85] With respect to the syntax of the free quantity declaration as presented in the "Quantities-and-Terminals" white paper I have a minor remark: Why would a free quantity declaration be restricted to a single identifier instead of usign an identifier list, i.e. why not free_quantity_declaration ::= "quantity" identifier_list ":" subtype_indication [":=" expression] ";" This would also be consistent with the object_declaration as descibed in the LRM which declares signals, constants and variables. The nature and subnature declarations should have a single identifier and not a list to parallel the type and subtype declarations. The way these parallels are drawn in the white paper are really neat and, I think, at least simplify the task of the implementors as far as the hardware description aspects of VHDL/A are concerned. If I look back at a previous white paper, "Pins-and-Nodes", the A/D interface was much better separated there than with the current proposal. For instance, if I were to construct a latching comparator cell with the entity declaration ENTITY comparator IS GENERIC (delay : Time := 10 ns); PORT (clock : IN Bit; dig_out : OUT Bit); TERMINAL (ana_in : IN Electrical); END comparator; the analog and digital parts of the interface are easier to recognize in this specific case and in general it is easy to see whether a part is purely digital, purely analog or mixed signal. Also, the declarations for the analog part would now completely parallel those of the digital part where the formal and local port declarations would be "copied" into the formal and local terminal declarations. This is mostly a syntactical change and does not change the sematics of these declarations. With the current proposal, the above declaration would look be ENTITY comparator IS GENERIC (delay : Time := 10 ns); PORT (clock : IN Bit; dig_out : OUT Bit, TERMINAL ana_in : IN Electrical); END comparator; Not only are the digital and analog signals now combined in a single declaration list, the semantics of the various parts differ largely: the signals "dig_out" and "clock" require a TYPE, while the terminal requires a NATURE. Then again additional problems arise: an interface QUANTITY which is analog would best fit at the formal_terminal_list declaration, however, it requires a TYPE and not a NATURE violating the distinction between the "typed" elements and the "natured" elements. Marq Kole -- +-----------------------------------+--------------------------------------+ | Marq Kole, | email: M.E.Kole@el.utwente.nl | | Lab. Networktheory, EF-9254, | tel: +31-53-892773 | | Dept. of Electr.Engineering, | fax: +31-53-334701 | | University of Twente, Holland | | WWW: http://utelnt.el.utwente.nl/links/kole/marq.html | +-----------------------------------+--------------------------------------+ From 1076-1-request@sicmail.epfl.ch Thu May 25 11:24:57 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Thu, 25 May 95 11:24:52 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Thu, 25 May 95 11:24:47 -0400 Received: from tiny.sprintlink.net by sicmail.epfl.ch with SMTP (PP) id <06887-0@sicmail.epfl.ch>; Thu, 25 May 1995 17:09:22 +0200 Received: from analogy.com (analogy.analogy.com [149.117.1.1]) by tiny.sprintlink.net (8.6.9/8.6.9) with SMTP id LAA11939 for <1076-1@epfl.ch>; Thu, 25 May 1995 11:08:03 -0400 Received: from miller.analogy.com by analogy.com (4.1/Shared_Spool_1.3) id AA04034; Thu, 25 May 95 08:10:08 PDT Received: from satyr.analogy.com by miller.analogy.com (4.1/SMI-3.2) id AA16148; Thu, 25 May 95 08:10:07 PDT Received: by satyr.analogy.com (5.0/SMI-SVR4) id AA13784; Thu, 25 May 1995 08:10:07 -0700 Date: Thu, 25 May 1995 08:10:07 -0700 From: christen@analogy.com (Ernst Christen) Message-Id: <9505251510.AA13784@satyr.analogy.com> To: 1076-1@epfl.ch Subject: Re: Responses to Ken Bakalar and Jim Barbary Content-Length: 2515 #From kenb@compass-da.com Thu May 25 06:13:54 1995 #To: christen@analogy.com #From: kenb@compass-da.com (Kenneth Bakalar) #Subject: Re: Responses to Ken Bakalar and Jim Barbary At 3:29 PM 5/23/95, Steven Greenberg wrote: >>>In the definition as it stands, there is never any need to test the value >>>of the derivative after a crossing. If the crossing signal value is '1', >>>then the last crossing was necessarily in the positive going direction; if >>>'0', then in the negative direction. >> >>Ah. Why didn't you say so? If Q'Cross reports the direction, and its >>value can be used to prevent undesired breaks, then the problem is >>satisfied, and I can see why Q'Rising and Q'Falling are no longer >>needed. But, you must not keep it a secret. Remember, I can judge only >>what's on the net; I do not come to meetings. > >The misunderstanding could have been avoided if the name of the variable had >been chosen with more care. The variable is true if you are above the >threshold >and false if you are not above. "...that the variable associated with each >signal Q'cross(E) for any prefix Q and value E has the value '1' if the sign >of Q-E is positive and '0' otherwise." So the variable does not tell you about >"cross". It tells you about "above". Q'above(E) would be one possible name. > >/Steve That's a good idea. We can make 'Above Boolean valued instead of bit valued like 'Cross. The semantics are exactly the same except for the change from bit to Boolean -- "...that the variable associated with each signal Q'Above(E) for any prefix Q and value E has the value TRUE if the sign of Q-E is positive and FALSE otherwise." The change in name and type amounts to a shift in emphasis. Q'Cross emphasizes the fact that crossing a threshold is causing something to happen, while Q'Above (or its complement Q'Below?) emphasize the value that the signal has at any time. Consider the following cases: wait on q'above(e); wait on q'cross(e); Each of these does the same thing; it waits for the crossing event to happen, regardless of which direction it goes in. Q'Cross seems more appropriate. Now consider these: wait until q'above(e); wait until q'cross(e)='1'; wait until q'above(e)=true; These all do the same thing to; they wait for q to rise above e. They are unidirectional. Now Q'Above seems the more appropriate representation. I think, on balance, I prefer the new definition. I would vote against the obvious committee-style compromise -- to include them all! From 1076-1-request@sicmail.epfl.ch Thu May 25 11:25:19 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Thu, 25 May 95 11:25:11 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Thu, 25 May 95 11:25:00 -0400 Received: from tiny.sprintlink.net by sicmail.epfl.ch with SMTP (PP) id <06825-0@sicmail.epfl.ch>; Thu, 25 May 1995 17:04:13 +0200 Received: from analogy.com (analogy.analogy.com [149.117.1.1]) by tiny.sprintlink.net (8.6.9/8.6.9) with SMTP id LAA11768 for <1076-1@epfl.ch>; Thu, 25 May 1995 11:02:55 -0400 Received: from miller.analogy.com by analogy.com (4.1/Shared_Spool_1.3) id AA04002; Thu, 25 May 95 08:05:00 PDT Received: from satyr.analogy.com by miller.analogy.com (4.1/SMI-3.2) id AA16136; Thu, 25 May 95 08:04:59 PDT Received: by satyr.analogy.com (5.0/SMI-SVR4) id AA13770; Thu, 25 May 1995 08:04:59 -0700 Date: Thu, 25 May 1995 08:04:59 -0700 From: christen@analogy.com (Ernst Christen) Message-Id: <9505251504.AA13770@satyr.analogy.com> To: 1076-1@epfl.ch Subject: mail from Ken Bakalar (fwd) Content-Length: 171 Due to mail delivery problems, I have asked Ernst Christen to forward three posts of which I am the author to the 1076.1 reflector. The problem should be fixed today. From 1076-1-request@sicmail.epfl.ch Thu May 25 11:30:25 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Thu, 25 May 95 11:30:22 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Thu, 25 May 95 11:30:17 -0400 Received: from tiny.sprintlink.net by sicmail.epfl.ch with SMTP (PP) id <06847-0@sicmail.epfl.ch>; Thu, 25 May 1995 17:06:24 +0200 Received: from analogy.com (analogy.analogy.com [149.117.1.1]) by tiny.sprintlink.net (8.6.9/8.6.9) with SMTP id LAA11806 for <1076-1@epfl.ch>; Thu, 25 May 1995 11:05:05 -0400 Received: from miller.analogy.com by analogy.com (4.1/Shared_Spool_1.3) id AA04014; Thu, 25 May 95 08:07:09 PDT Received: from satyr.analogy.com by miller.analogy.com (4.1/SMI-3.2) id AA16140; Thu, 25 May 95 08:07:09 PDT Received: by satyr.analogy.com (5.0/SMI-SVR4) id AA13776; Thu, 25 May 1995 08:07:08 -0700 Date: Thu, 25 May 1995 08:07:08 -0700 From: christen@analogy.com (Ernst Christen) Message-Id: <9505251507.AA13776@satyr.analogy.com> To: 1076-1@epfl.ch Subject: Re: Quantity syntax Content-Length: 3139 #From kenb@compass-da.com Thu May 25 06:13:31 1995 #To: christen@analogy.com #From: kenb@compass-da.com (Kenneth Bakalar) #Subject: Re: Quantity syntax At 12:59 PM 5/24/95, Marq Kole wrote: >With respect to the syntax of the free quantity declaration as presented in >the "Quantities-and-Terminals" white paper I have a minor remark: Why would >a free quantity declaration be restricted to a single identifier instead of >usign an identifier list, i.e. why not > >free_quantity_declaration ::= > "quantity" identifier_list ":" subtype_indication [":=" expression] ";" I agree. It should allow an identifier list. > >If I look back at a previous white paper, "Pins-and-Nodes", the A/D interface >was much better separated there than with the current proposal. For instance, >if I were to construct a latching comparator cell with the entity declaration > >ENTITY comparator IS > GENERIC (delay : Time := 10 ns); > PORT (clock : IN Bit; dig_out : OUT Bit); > TERMINAL (ana_in : IN Electrical); >END comparator; > [stuff deleted] > >With the current proposal, the above declaration would look be > >ENTITY comparator IS > GENERIC (delay : Time := 10 ns); > PORT (clock : IN Bit; dig_out : OUT Bit, TERMINAL ana_in : IN Electrical); >END comparator; You are not alone in thinking that a separate interface list for interface terminals, perhaps combined with interface quantities, would look better. I prefer a single interface list myself, because having extra lists and extra keywords for labeling them (both in the declarations and in the component instances) introduces extra complexity without any additional functionality. Of course, that argument is not an absolute one; there is really no need for concurrent statements (you can always write out the equivalent process), but it's nice to have them -- it makes the description more readable. You could write the entity declartion like this: ENTITY compartor IS GENERIC (delay: Time:= 10 ns); PORT ( SIGNAL clock: IN Bit; SIGNAL dig_out: OUT Bit; TERMINAL ana_in: Electrical); END comparator; > >Not only are the digital and analog signals now combined in a single >declaration list, the semantics of the various parts differ largely: the >signals "dig_out" and "clock" require a TYPE, while the terminal >requires a NATURE. Then again additional problems arise: an interface >QUANTITY which is analog would best fit at the formal_terminal_list >declaration, however, it requires a TYPE and not a NATURE violating the >distinction between the "typed" elements and the "natured" elements. > There is a precedent in VHDL that we can follow. Consider the following procedure declaration: procedure foo (VARIABLE: a: INOUT integer; CONSTANT b: bit_vector; SIGNAL c: boolean); Variables, constants and signals have semantics that are very different from each other, yet the language lets you mix them up in a single list. ---------- In any case, we can choose to use as many interface lists as we like; the semantics of the individual terminal association elements and quantity association elements in (for example) a component instance doesn't change. From 1076-1-request@sicmail.epfl.ch Thu May 25 11:36:10 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Thu, 25 May 95 11:36:07 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Thu, 25 May 95 11:36:01 -0400 Received: from tiny.sprintlink.net by sicmail.epfl.ch with SMTP (PP) id <06861-0@sicmail.epfl.ch>; Thu, 25 May 1995 17:07:25 +0200 Received: from analogy.com (analogy.analogy.com [149.117.1.1]) by tiny.sprintlink.net (8.6.9/8.6.9) with SMTP id LAA11857 for <1076-1@epfl.ch>; Thu, 25 May 1995 11:06:05 -0400 Received: from miller.analogy.com by analogy.com (4.1/Shared_Spool_1.3) id AA04018; Thu, 25 May 95 08:08:09 PDT Received: from satyr.analogy.com by miller.analogy.com (4.1/SMI-3.2) id AA16143; Thu, 25 May 95 08:08:09 PDT Received: by satyr.analogy.com (5.0/SMI-SVR4) id AA13780; Thu, 25 May 1995 08:08:08 -0700 Date: Thu, 25 May 1995 08:08:08 -0700 From: christen@analogy.com (Ernst Christen) Message-Id: <9505251508.AA13780@satyr.analogy.com> To: 1076-1@epfl.ch Subject: Re: More comments on comments wrt Ernst's and Ken's comments Content-Length: 2969 #From kenb@compass-da.com Thu May 25 06:13:38 1995 #To: christen@analogy.com #From: kenb@compass-da.com (Kenneth Bakalar) #Subject: Re: More comments on comments wrt Ernst's and Ken's comments >>>Use of IF-THEN-ELSE logic has some problems. First, it's a great deal >>>slower, as the logic must be invoked at each and every ASP. >> >>You would have to show me why you think that. Using a conditional shouldn't >>be any slower than any of the other techniques for switching equations I >>showed in my original response. > >A break statement executes once in a while, not once per ACP. The >detection of crossing, while it must be executed once per ACP, is much >simpler than the IF-THEN-ELSE nest it will replace, and can be closely >integrated compiled code within the analog solver. By contrast, the >IF-THEN-ELSE code is in most simulators effectively interpreted in the >same sense that Pascal P-Code was interpreted -- the output of the >compiler was not native assembly/machine code for the target processor. > The modeler needs to pay the (computational) price for detecting crossings if he intends to change the behavior of the model conditioned on the state of the crossing -- that is, whether the quantity is above or below the crossing point. Then, he needs to use some kind of conditional form to choose between the sets of equations to be used in each state. Crossing detection is a good deal more expensive than the conditional test. All this is true whether or not a discontinuity exists at the crossing point. I showed a number of different ways to notate equations conditional on a crossing earlier in this thread. If a discontinuity in some quantity exists then a break statement must be executed at the time of the discontinuity. This is true regardless of the presence or status of any crossing signal. An implementation may use compilation, interpretation or a combination of techniques to process the source text. The choice is not dictated by the presence or absence of conditional statements. > >The point I was making was that it's much simpler and cleaner to write >(and to read) a model consisting of two sets of equations plus some >break statements to switch between them, than a merged model where the >equation sets are intertwined with lots of conditional code providing >the glue. If it's hard to read and understand, it's hard to review >and to get right. The break statement does not cause switching of equations. Only the conditional and selected simultaneous statements (and the as yet incompletely designed procedural statement) switch the equations. The switch may be conditional on the value and event time of a crossing signal. A break is signaled by the execution of a break statement within a (regular old, VHDL) process. The process containing the break may simultaneously cause the equations to switch by changing the values of signals that are used as coefficients or conditions in simultaneous statements. From 1076-1-request@sicmail.epfl.ch Thu May 25 11:36:22 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Thu, 25 May 95 11:36:19 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Thu, 25 May 95 11:36:14 -0400 Received: from tiny.sprintlink.net by sicmail.epfl.ch with SMTP (PP) id <07313-0@sicmail.epfl.ch>; Thu, 25 May 1995 17:33:06 +0200 Received: from analogy.com (analogy.analogy.com [149.117.1.1]) by tiny.sprintlink.net (8.6.9/8.6.9) with SMTP id LAA12535 for <1076-1@epfl.ch>; Thu, 25 May 1995 11:31:46 -0400 Received: from miller.analogy.com by analogy.com (4.1/Shared_Spool_1.3) id AA04114; Thu, 25 May 95 08:33:50 PDT Received: from satyr.analogy.com by miller.analogy.com (4.1/SMI-3.2) id AA16178; Thu, 25 May 95 08:33:50 PDT Received: by satyr.analogy.com (5.0/SMI-SVR4) id AA13838; Thu, 25 May 1995 08:33:49 -0700 Date: Thu, 25 May 1995 08:33:49 -0700 From: christen@analogy.com (Ernst Christen) Message-Id: <9505251533.AA13838@satyr.analogy.com> To: 1076-1@epfl.ch Subject: Re: More comments on comments wrt Ernst's and Ken's comments Content-Length: 3560 Responses to Joe Gwinn's comments: > > >>You are right again, such a statement is never made. There are two reasons for >>this: >>1. The same as above, i.e. the language itself does not have the concepts >> of power etc., so this kind of consistency cannot be enforced by the >> language. > >I would be happy if it were discussed in the rationale. The users >should at least be given a hint. > >>2. The product of the across and through variables is not always power, >> although in many practical cases it is. In his book "Modeling Engineering >> Systems" (HighText Publications, 1994) Jack W. Lewis describes several >> physical disciplines. He says the following about thermal systems: >> [In analogy to electrical systems] temperature [in a thermal system] >> is the across variable, and heat flow rate is the through variable. ... >> We must be very careful with this analogy [, though,] when it comes to >> looking at power relationships. The rate of heat flow qh corresponds >> to power, as a consequence of the equivalency of heat and work >> stated by the first law of thermodynamics. ... > >Hmm. Now that you mention it, I do recall that exception. Cellier's >book also discusses this, that thermodynamic variables are the exception. >I don't recall that there were any other significant exceptions, though. >Although some Bond Graph researchers were trying to apply BGs to Quantum >Mechanics. Anyway, I submit that users and implementors would find it >very illuminating to know that with the exception of thermodynamics >(which they flunked anyway), the product of through and across is generally >a true energy flow. The references can also direct the intrepid to >selected textbooks. > Both KCL and KVL are expressions of the physical law of energy conservation. In VHDL-A this las is expressed using natures, terminals, and branch quantities. The product of the across and through units of a nature is often but not always units of power. Advanced users may wish to know more, but I leave that to the tutorial writers. Implementors must implement the language as specified, without any such assumptions. The construction of an annotated bibliography of helpful articles and books would be desirable, but we are not focusing on that now. The short bibliography you distributed the other day might serve as the basis for such an effort. > >>We all agree that the modeling of continuous time systems requires the >>availability of mathematical functions, e.g. trigonometric, exponential etc. >>To make them available in VHDL-A these functions must be declared somewhere. >>We believe that the math package should be this place, and its details are >>of great importance to us. > >I guess I was asking a somewhat sharp question: If we (VHDL-A) do nothing >but enumerate by name the required mathematical functions and their calling >sequences, but do not otherwise define them, what bad thing will happen? >Are we asking for anything not commonly found in the math library of >every computer system on the market? (Complex functions of a complex >variable might be the exception.) Are we really going to discover that >someone forgot to include the Sine function, crippling VHDL-A? > If the math package is defined correctly then we don't even need to enumerate the required functions. We are particularly concerned that domain errors are handled in a consistent and appropriate way across implementations. There is not much consistency in this respect between math libraries on different computer systems. From 1076-1-request@sicmail.epfl.ch Thu May 25 13:44:10 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Thu, 25 May 95 13:43:55 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Thu, 25 May 95 13:43:49 -0400 Received: from clsi.columbia.compass-da.com by sicmail.epfl.ch with SMTP (PP) id <08540-0@sicmail.epfl.ch>; Thu, 25 May 1995 19:12:06 +0200 Received: from [162.17.30.152] ([162.17.30.152]) by clsi.columbia.compass-da.com (8.6.12/8.6.9) with SMTP id UAA00928 for <1076-1@epfl.ch>; Wed, 24 May 1995 20:30:59 -0400 Reply-To: kenb@compass-da.com X-Sender: kennyb@clsi.columbia.compass-da.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 24 May 1995 20:38:39 -0400 To: 1076-1@epfl.ch From: kenb@compass-da.com (Kenneth Bakalar) Subject: Re: Quantity syntax At 12:59 PM 5/24/95, Marq Kole wrote: >With respect to the syntax of the free quantity declaration as presented in >the "Quantities-and-Terminals" white paper I have a minor remark: Why would >a free quantity declaration be restricted to a single identifier instead of >usign an identifier list, i.e. why not > >free_quantity_declaration ::= > "quantity" identifier_list ":" subtype_indication [":=" expression] ";" I agree. It should allow an identifier list. > >If I look back at a previous white paper, "Pins-and-Nodes", the A/D interface >was much better separated there than with the current proposal. For instance, >if I were to construct a latching comparator cell with the entity declaration > >ENTITY comparator IS > GENERIC (delay : Time := 10 ns); > PORT (clock : IN Bit; dig_out : OUT Bit); > TERMINAL (ana_in : IN Electrical); >END comparator; > [stuff deleted] > >With the current proposal, the above declaration would look be > >ENTITY comparator IS > GENERIC (delay : Time := 10 ns); > PORT (clock : IN Bit; dig_out : OUT Bit, TERMINAL ana_in : IN Electrical); >END comparator; You are not alone in thinking that a separate interface list for interface terminals, perhaps combined with interface quantities, would look better. I prefer a single interface list myself, because having extra lists and extra keywords for labeling them (both in the declarations and in the component instances) introduces extra complexity without any additional functionality. Of course, that argument is not an absolute one; there is really no need for concurrent statements (you can always write out the equivalent process), but it's nice to have them -- it makes the description more readable. You could write the entity declartion like this: ENTITY compartor IS GENERIC (delay: Time:= 10 ns); PORT ( SIGNAL clock: IN Bit; SIGNAL dig_out: OUT Bit; TERMINAL ana_in: Electrical); END comparator; > >Not only are the digital and analog signals now combined in a single >declaration list, the semantics of the various parts differ largely: the >signals "dig_out" and "clock" require a TYPE, while the terminal >requires a NATURE. Then again additional problems arise: an interface >QUANTITY which is analog would best fit at the formal_terminal_list >declaration, however, it requires a TYPE and not a NATURE violating the >distinction between the "typed" elements and the "natured" elements. > There is a precedent in VHDL that we can follow. Consider the following procedure declaration: procedure foo (VARIABLE: a: INOUT integer; CONSTANT b: bit_vector; SIGNAL c: boolean); Variables, constants and signals have semantics that are very different from each other, yet the language lets you mix them up in a single list. ---------- In any case, we can choose to use as many interface lists as we like; the semantics of the individual terminal association elements and quantity association elements in (for example) a component instance doesn't change. From 1076-1-request@sicmail.epfl.ch Fri May 26 05:15:14 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Fri, 26 May 95 05:15:05 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Fri, 26 May 95 05:14:58 -0400 Received: from utep.el.utwente.nl by sicmail.epfl.ch with SMTP (PP) id <15939-0@sicmail.epfl.ch>; Fri, 26 May 1995 10:51:51 +0200 Received: from nt.el.utwente.nl (utelnt.el.utwente.nl) by utep.el.utwente.nl with SMTP id AA01332 (5.65c/IDA-1.4.4 for <1076-1@epfl.ch>); Fri, 26 May 1995 10:50:53 +0200 Message-Id: <199505260850.AA01332@utep.el.utwente.nl> Received: by nt.el.utwente.nl (1.37.109.4/16.2) id AA09298; Fri, 26 May 95 10:52:59 +0100 From: Marq Kole Subject: Subnatures To: 1076-1@epfl.ch Date: Fri, 26 May 95 10:52:59 WETDST Mailer: Elm [revision: 70.85] The definition of the SUBNATURE declaration in the "Quantities-and-terminals" white paper leaves something to be desired, IMHO. What is the case? Let me give you the definition again: subnature_declaration ::= "subnature" identifier "is" subnature_indication; nature_mark ::= nature_name|subnature_name subnature_indication ::= nature_mark [index_constraint] With the restriction that a "subnature_indication" is a "nature_mark" followed by an optional "index_constraint" reduces it to a mere ALIAS. Why not leaving it out altogether if it introduces no actual contribution to the language semantics. Of course, the nice parallel with the TYPE and SUBTYPE declarations would then be missing, but that would not be enough reason for its existence. Then, on the other hand, is it maybe possible to add a range-constraint to a "subnature_indication"? In that case the nature of a terminal would attain a similar restriction as types do with the signals, quantities, constants and variables. Such a scheme would simplify the modeling of device-failure and thus the implementation of tolerance analysis. Actually, the range-constraint would be propagated to the ACROSS and THROUGH types of the nature, recreating them as ACROSS and THROUGH subtypes and associating them with the subnature. Problem: the nature definition does not impose a restriction that would require the ACROSS and THROUGH attributes of a nature to be of the same type; such a restriction would be undesirable. This implies that a possible range-constraint on a subnature would be required to denote whether it constrains the THROUGH or the ACROSS type. A syntax proposal in this context would be subnature_indication ::= nature_mark [nature_constraint] nature_constraint ::= index_constraint | nature_range_constraint nature_range_constraint ::= [across_range_aspect] [through_range_aspect] across_range_aspect ::= range_constraint ACROSS through_range_aspect ::= range_constraint THROUGH Where it is an error if a nature_range_constraint includes neither an "across_range_aspect" nor a "through_range_aspect". Marq -- +-----------------------------------+--------------------------------------+ | Marq Kole, | email: M.E.Kole@el.utwente.nl | | Lab. Networktheory, EF-9254, | tel: +31-53-892773 | | Dept. of Electr.Engineering, | fax: +31-53-334701 | | University of Twente, Holland | | WWW: http://utelnt.el.utwente.nl/links/kole/marq.html | +-------------------------------+------------------------------------------+ From 1076-1-request@sicmail.epfl.ch Fri May 26 14:02:36 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Fri, 26 May 95 14:02:11 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Fri, 26 May 95 14:02:07 -0400 Received: from gatekeeper.ray.com by sicmail.epfl.ch with SMTP (PP) id <26267-0@sicmail.epfl.ch>; Fri, 26 May 1995 19:40:17 +0200 Received: from localhost (mailer@localhost) by gatekeeper.ray.com (8.6.4/8.6.5) id NAA06274 for <1076-1@epfl.ch>; Fri, 26 May 1995 13:38:39 -0400 Received: from sud2.ed.ray.com by gatekeeper.ray.com; Fri May 26 13:38:45 1995 Received: from SUD2.ED.RAY.COM by SUD2.ED.RAY.COM (PMDF V4.2-10 #4335) id <01HQYL1AEXGGA9B7S9@SUD2.ED.RAY.COM>; Fri, 26 May 1995 13:38:12 EDT Date: Fri, 26 May 1995 13:38:12 -0400 (EDT) From: "Joe Gwinn, 508-440-3330" Subject: More comments on comments on ... To: 1076-1@epfl.ch Message-Id: <01HQYL1AEXGIA9B7S9@SUD2.ED.RAY.COM> X-Envelope-To: 1076-1@epfl.ch X-Vms-To: IN%"1076-1@epfl.ch" X-Vms-Cc: GWINN Mime-Version: 1.0 Content-Transfer-Encoding: 7BIT Here are some small comments on recent net traffic. I will be away until Monday 12 June 1995. 1. Renaming Q'Cross() to Q'Above() or the like seems like a good idea. A few sentences in rationale and standard would also help. 2. "The break statement does not cause switching of equations." Hmm. Why not? "Only the conditional and selected simultaneous statements (and the as yet incompletely designed procedural statement) switch the equations." I guess we need to talk. The ability to switch between multiple sets of equations, and splice the pieces of the various quantities into overall piecewise continuous curves, is an objective. Having rats' nests of merged equations sets glued together with conditional statements is too ugly to contemplate, too clumsy to really use for anything complex enough to require such a powerful tool as VHDL-A. Don't be misled by the bouncing-ball example -- it's only a test case and example. Real models can have tens of thousands of lines of model code, the work of many hands, over many years. 3. What's a "domain error" in the math package? Feeding a negative number to a square root? Ernst's point that the rubber meets the road here, in domain errors, sounds to be on point. An enumeration of these errors is therefore in order. Joe Gwinn From 1076-1-request@sicmail.epfl.ch Sat May 27 06:16:24 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Sat, 27 May 95 06:16:19 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Sat, 27 May 95 06:16:15 -0400 Received: from c3imac12.epfl.ch by sicmail.epfl.ch with SMTP (PP) id <00680-0@sicmail.epfl.ch>; Sat, 27 May 1995 11:59:01 +0200 X-Sender: vachoux@c3i9.epfl.ch Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 27 May 1995 12:00:20 +0100 To: 1076-1@epfl.ch From: alain.vachoux@leg.de.epfl.ch (Alain Vachoux EPFL-LEG/C3i) Subject: E-mail discussion policy All, The undergoing e-mail discussion is really interesting and I would not like to slow it down. However, as the secretary of the WG, I'm trying to archive the messages in our ftp site by sorting them according to the topic addressed. You would *really* ease my job by following the rule: one topic, one message. Also, please use short subject lines. Thanks Alain Vachoux From 1076-1-request@sicmail.epfl.ch Mon May 29 07:38:37 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Mon, 29 May 95 07:38:21 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Mon, 29 May 95 07:38:14 -0400 Received: from utep.el.utwente.nl by sicmail.epfl.ch with SMTP (PP) id <16294-0@sicmail.epfl.ch>; Mon, 29 May 1995 12:28:17 +0200 Received: from nt.el.utwente.nl (utelnt.el.utwente.nl) by utep.el.utwente.nl with SMTP id AA04275 (5.65c/IDA-1.4.4 for <1076-1@epfl.ch>); Mon, 29 May 1995 12:27:15 +0200 Message-Id: <199505291027.AA04275@utep.el.utwente.nl> Received: by nt.el.utwente.nl (1.37.109.4/16.2) id AA11971; Mon, 29 May 95 12:29:20 +0100 From: Marq Kole Subject: Quantity types and subtypes To: 1076-1@epfl.ch Date: Mon, 29 May 95 12:29:20 WETDST Mailer: Elm [revision: 70.85] Hmm, I may seem to be picking a bit on the "Quantities-and-terminals" white paper, as I again have some comments, but I still think its a good and workable proposal. It's just a few minor quirks that have to be adjusted, IMHO. Let's get to the point... In this paper, quantities, whether declared in the interface list or as a free quantity, have a special restriction on their type: it should be a "nature-type" or a "nature-subtype". I quote: "A free quantity declaration declares a quantity of the specified type. A nature type is a floating-point type or a composite type with elements of anature type. The type of a quantity must be a nature type." Well, that seems fine, until you want to know how to create one: you can't, at least not explicitly. It's either an Across or Through attribute of a nature or of a component of a composite nature, but no explicit type. Unless a type that is used in a nature declaration is automatically associated with that nature. So if (I use an example from the white paper) we say TYPE kirchhoff IS RANGE -1.0E+100 TO +1.0E+100; SUBTYPE voltage IS kirchhoff; SUBTYPE current IS kirchhoff; NATURE electrical IS voltage ACROSS current THROUGH; ENTITY inductor1 IS GENERIC (L: inductance); PORT (TERMINAL n1, n2: electrical; QUANTITY q1: current); END inductor; Where the interface element "q1" has the type "current" which is IMPLICITLY a nature type because it has been used to define the nature "electrical". Actually, "current" is just an ordinary floating-point type. This practise, however, should not be allowed. For instance, when one type is used in two different natures, a "nature-clash" would result. I do recall something of velocity being used in different natures, in one as a through and in another as an across nature-type. Correct me if I'm wrong. Forcing users to create different names for both is in my opinion "not done", even if the impact is rather low. It is a sneaky "behind-your-back" compiler pass that would violate quite a lot of common sense programming rules. Hmm, I garbled somewhat, but I do hope you get my point. What's the solution: 1) Allow the creation of special NATURE TYPES. This is a bad idea because a new keyword would be required or an adaption of the TYPE syntax which could be left undisturbed with the currently proposed analog extensions to VHDL, as far as I can tell. 2) Restrict the nature types and subtypes to the across and through attributed subtypes, so only types like the following example are allowed (again taken from the white paper): NATURE elec_array IS ARRAY (integer RANGE <>) OF electrical; QUANTITY QF1: elec_array'Across (1 TO 10); This would reduce the readability of code to be forced to refer to "current" as "electrical'Across". 3) Change the definition of a nature to introduce new types in combination with the new nature, i.e.: NATURE electrical IS voltage IS kirchhoff ACROSS current IS kirchhoff THROUGH; Now voltage and current are explicit nature-types. The restriction remains that the same type cannot be attributed to more than one nature, so the abovementioned problem with velocity is not solved. However, I do think that the result is much clearer I do not say that the idea of nature type should be discarded, as it makes a "domain"-check possible (not to be confused with the mathematical domain errors and such), a check whether across and through types are not inadvertedly mixed, instead of explicitly. Marq -- +-----------------------------------+--------------------------------------+ | Marq Kole, | email: M.E.Kole@el.utwente.nl | | Lab. Networktheory, EF-9254, | tel: +31-53-892773 | | Dept. of Electr.Engineering, | fax: +31-53-334701 | | University of Twente, Holland | | WWW: http://utelnt.el.utwente.nl/links/kole/marq.html | +-------------------------------+------------------------------------------+ From 1076-1-request@sicmail.epfl.ch Mon May 29 13:13:09 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Mon, 29 May 95 13:13:02 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Mon, 29 May 95 13:12:56 -0400 Received: from c3imac12.epfl.ch by sicmail.epfl.ch with SMTP (PP) id <25993-0@sicmail.epfl.ch>; Mon, 29 May 1995 18:28:08 +0200 X-Sender: vachoux@c3i9.epfl.ch Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 29 May 1995 18:29:30 +0100 To: 1076-1@epfl.ch From: alain.vachoux@leg.de.epfl.ch (Alain Vachoux EPFL-LEG/C3i) Subject: DOD 2.1 vote results All, Here are the results of the vote on the Design Objective Document version 2.1. ================================================================================ Name YES NO ABSTAIN Comments Voting member? ------------------------------------------------------------------------------ Mart Altmae X Ken Bakalar X Ernst Christen X Dan Damon X Steve Drager X X Doug Dunlop X Hazem El Tahawy X X Oliver Fischer-Binder X X Serge Garcia-Sabiro X X Joe Gwinn X X Jim Hanna X Christophe Hui-Bon-Hoa X X Sylvie Hurat X X Jutta Ipsen * X NO Jean-Jose Mayol X X Larry Moore X X Eduard Moser X Siep Onneweer X Hidetoshi Onodera X Eric Sax X Richard Shi X David Smith X Alain Vachoux X Kevin Walsh X X Sam Wasche * NO ------------------------------------------------------------------------------- Total 17 6(8) 0 ------------------------------------------------------------------------------- YES NO ABSTAIN Comments Voting member? 25 people voted, of which 2 were not registered as voting members at the time of the vote. 17 people approved the DOD 2.1, while 8 did not. First, our policies require a quorum of 50% of the voting members for the vote to be effective. At the time the vote started (April 27), 87 people were registered as voting members. The vote has then to be done again. Second, all the people that voted NO asked to have a stronger support for frequency-domain analysis, mainly for small-signal AC and noise analysis. Other comments concerned a few misspellings or bad formulated sentences. I would then propose to vote again on a new version 2.2 of the DOD that accomodates for these comments. Before going into the new vote, I'd like to update the list of voting members. Remember that our policies require that a voting member failing to vote for two successive votes should be disqualified. I'm going to send a personal message to all 1076.1 members who are still voting members today (46 people). Anynone willing to be (re)instated as a voting member is kindly asked to send me a mail before the end of this week (June 4). Then we'll proceed to a new vote on DOD 2.2, with this time the quorum reached, I hope. Regards, Alain Vachoux Secretary 1076.1 WG From 1076-1-request@sicmail.epfl.ch Tue May 30 12:12:23 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Tue, 30 May 95 12:12:04 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Tue, 30 May 95 12:11:58 -0400 Received: from clsi.columbia.compass-da.com by sicmail.epfl.ch with SMTP (PP) id <14577-0@sicmail.epfl.ch>; Tue, 30 May 1995 17:00:01 +0200 Received: from [162.17.30.161] ([162.17.30.161]) by clsi.columbia.compass-da.com (8.6.12/8.6.9) with SMTP id KAA29616 for <1076-1@epfl.ch>; Tue, 30 May 1995 10:51:13 -0400 Reply-To: kenb@compass-da.com X-Sender: kennyb@clsi.columbia.compass-da.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 30 May 1995 10:59:30 -0400 To: 1076-1@epfl.ch From: kenb@compass-da.com (Kenneth Bakalar) Subject: Re: Subnatures At 5:52 AM 5/26/95, Marq Kole wrote: >The definition of the SUBNATURE declaration in the "Quantities-and-terminals" >white paper leaves something to be desired, IMHO. What is the case? Let me >give you the definition again: > > subnature_declaration ::= > "subnature" identifier "is" subnature_indication; > nature_mark ::= nature_name|subnature_name > subnature_indication ::= nature_mark [index_constraint] > >With the restriction that a "subnature_indication" is a "nature_mark" followed >by an optional "index_constraint" reduces it to a mere ALIAS. Why not leaving >it out altogether if it introduces no actual contribution to the language >semantics. Of course, the nice parallel with the TYPE and SUBTYPE declarations >would then be missing, but that would not be enough reason for its existence. > The utility of the subnature exactly parallels the utility of the subtypes of an array type. The nature mark may denote an unconstrained nature; e.g., nature electrical_array is array (integer range <>) of electrical; An interface terminal of a device can have an unconstrained nature. This is useful because the device can then be used with an actual array terminal of any length: entity AtoD is port (terminal input: electrical_array; signal output: out integer); end AtoD; The subnature indication is used in two ways; to create a subnature: subnature e10_array is electrical_array(9 downto 0); subnature e5_array is electrical_array(1 to 5); or to constrain a terminal at the time of declaration: terminal big is electrical_array(1 to 100); terminal little is electrical_array(1 to 5); Either "big" or "little" can be attached to the "input" terminal port of "AtoD". >Then, on the other hand, is it maybe possible to add a range-constraint to >a "subnature_indication"? In that case the nature of a terminal would attain >a similar restriction as types do with the signals, quantities, constants and >variables. Such a scheme would simplify the modeling of device-failure and >thus the implementation of tolerance analysis. Actually, the range-constraint >would be propagated to the ACROSS and THROUGH types of the nature, recreating >them as ACROSS and THROUGH subtypes and associating them with the subnature. >Problem: the nature definition does not impose a restriction that would >require the ACROSS and THROUGH attributes of a nature to be of the same type; >such a restriction would be undesirable. This implies that a possible >range-constraint on a subnature would be required to denote whether it >constrains the THROUGH or the ACROSS type. > >A syntax proposal in this context would be > > subnature_indication ::= nature_mark [nature_constraint] > nature_constraint ::= index_constraint | nature_range_constraint > nature_range_constraint ::= [across_range_aspect] [through_range_aspect] > across_range_aspect ::= range_constraint ACROSS > through_range_aspect ::= range_constraint THROUGH > >Where it is an error if a nature_range_constraint includes neither an >"across_range_aspect" nor a "through_range_aspect". > The simple nature underlying any nature declaration names two subtypes. Those subtypes are defined by subtype indications, each of which has a range constraint. Those range constraints can be different from each other. So most of the functionality that you require is already supplied without extending the language. It is, however, not possible to vary these constraints among different subnatures of a given nature -- for example, you can't make compatible terminals one of which has its across characteristic constrained to +-5 volts,and another with with its across characteristic constrained to +- 1 megavolt. However, you can write statements that monitor voltages and report out of range conditions. Consider, for example the following (regular old, VHDL) concurrent statement: ASSERT Q'cross(10.0)='1' or Q'cross(-10.0)='0' REPORT "I smell smoke!"; This monitors the quantity Q for an out-of-range condition and reports it the instant it occurs. I would be interested to hear more about your requirements for device-failure and tolerance analysis. We do not have any design requirement that addresses these matters explicitly, though the required functionality may be implicit in what we already have. >Marq > Ken From 1076-1-request@sicmail.epfl.ch Thu Jun 1 06:36:58 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Thu, 1 Jun 95 06:36:45 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Thu, 1 Jun 95 06:36:27 -0400 Received: from utep.el.utwente.nl by sicmail.epfl.ch with SMTP (PP) id <28236-0@sicmail.epfl.ch>; Thu, 1 Jun 1995 11:27:01 +0200 Received: from nt.el.utwente.nl (utelnt.el.utwente.nl) by utep.el.utwente.nl with SMTP id AA03265 (5.65c/IDA-1.4.4 for <1076-1@epfl.ch>); Thu, 1 Jun 1995 11:25:49 +0200 Message-Id: <199506010925.AA03265@utep.el.utwente.nl> Received: by nt.el.utwente.nl (1.37.109.4/16.2) id AA22685; Thu, 1 Jun 95 11:27:54 +0100 From: Marq Kole Subject: Re: Subnatures To: 1076-1@epfl.ch Date: Thu, 1 Jun 95 11:27:53 WETDST In-Reply-To: ; from "Kenneth Bakalar" at May 30, 95 10:59 am Mailer: Elm [revision: 70.85] On May 30, 1995 Ken Bakalar wrote > > The simple nature underlying any nature declaration names two subtypes. > Those subtypes are defined by subtype indications, each of which has a > range constraint. Those range constraints can be different from each > other. So most of the functionality that you require is already supplied > without extending the language. > > It is, however, not possible to vary these constraints among different > subnatures of a given nature -- for example, you can't make compatible > terminals one of which has its across characteristic constrained to +-5 > volts,and another with with its across characteristic constrained to +- 1 > megavolt. However, you can write statements that monitor voltages and > report out of range conditions. Consider, for example the following > (regular old, VHDL) concurrent statement: > > ASSERT Q'cross(10.0)='1' or Q'cross(-10.0)='0' REPORT "I smell smoke!"; > > This monitors the quantity Q for an out-of-range condition and reports it > the instant it occurs. > This describes more or less of the idea I had, but I can seen it is not necessary. My idea was to draw a parallel between the TYPE and SUBTYPE indications on digital SIGNALs that implement a kind of static structural test to the NATURE and SUBNATURE indications on TERMINALs to do the same. Howevere, the latter cannot be a static process but has to be dynamic; the static structureal test is implemented by assigning natures to terminals in the first place. > > I would be interested to hear more about your requirements for > device-failure and tolerance analysis. We do not have any design > requirement that addresses these matters explicitly, though the required > functionality may be implicit in what we already have. > > Ken > Let me get back on this one later. As far as I can see now there is no real need for extending the language as far as its syntax is concerned. I may have some implications on its semantics and implementation details, but then I would need to know more about the current proposal for analog subprograms; is there such a proposal. Ok, I'll elaborate somewhat. If we wanted to implement statistical analysis, it is necessary to associated certain parameters no longer with specific values, but rather with distribution functions. This is already possible to a certain extent in VHDL. The MATH package defines a UNIFORM procedure that gives a pseudo-random number. With additional manipulation a uniform distribution can be transformed to any other distribution function. I see no reason to standardise such additional distribution functions. It might be nice to have access to the seed of the UNIFORM procedure from outside the simulation environment, but I think that's an implementation detail. I'll get back to you on the issue of reliability analysis as that is a more complicated matter: it is a dynamic process instead of the above mentioned statistical analysis which is implicitly a static process. Marq -- +-----------------------------------+--------------------------------------+ | Marq Kole, | email: M.E.Kole@el.utwente.nl | | Lab. Networktheory, EF-9254, | tel: +31-53-892773 | | Dept. of Electr.Engineering, | fax: +31-53-334701 | | University of Twente, Holland | | WWW: http://utelnt.el.utwente.nl/links/kole/marq.html | +-------------------------------+------------------------------------------+ From 1076-1-request@sicmail.epfl.ch Thu Jun 1 13:21:37 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Thu, 1 Jun 95 13:21:27 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Thu, 1 Jun 95 13:21:16 -0400 Received: from clsi.columbia.compass-da.com by sicmail.epfl.ch with SMTP (PP) id <11636-0@sicmail.epfl.ch>; Thu, 1 Jun 1995 18:25:10 +0200 Received: from [162.17.30.161] ([162.17.30.161]) by clsi.columbia.compass-da.com (8.6.12/8.6.9) with SMTP id MAA13310 for <1076-1@epfl.ch>; Thu, 1 Jun 1995 12:16:18 -0400 Reply-To: kenb@compass-da.com X-Sender: kennyb@clsi Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 1 Jun 1995 12:26:22 -0500 To: 1076-1@epfl.ch From: kenb@compass-da.com (Kenneth Bakalar) Subject: Re: Quantity types and subtypes At 8:29 AM 5/29/95, Marq Kole wrote: >Hmm, I may seem to be picking a bit on the "Quantities-and-terminals" white >paper, as I again have some comments, but I still think its a good and >workable proposal. It's just a few minor quirks that have to be >adjusted, IMHO. Let's get to the point... > >In this paper, quantities, whether declared in the interface list or as >a free quantity, have a special restriction on their type: it should be >a "nature-type" or a "nature-subtype". I quote: > > "A free quantity declaration declares a quantity of the specified > type. A nature type is a floating-point type or a composite type > with elements of anature type. The type of a quantity must be a > nature type." > >Well, that seems fine, until you want to know how to create one: you >can't, at least not explicitly. The logic of that statement works like this: FOR ALL t SUCH THAT t IS A scalar type: IF t IS A floating point type THEN t IS A nature type. So every floating point type is a nature type. FOR ALL c SUCH THAT c IS A composite type: IF element type of c IS A nature type THEN c IS A nature type. So all arrays of floating-point elements, arrays of arrays and so on, are also nature types. Examples of nature type declarations are: TYPE myreal IS RANGE -1.0E-300 TO 1.0E+300; TYPE myreal_array IS ARRAY (integer RANGE <>) OF myreal; TYPE myrec IS RECORD field1: real; field2: myreal_array(1 to 10); END RECORD; The point is this: the variables (variables in the mathematical rather than the computer language sense) in a DAE are to be represented by numbers. A quantity of a scalar type represents a single variable. A quantity of a a composite type represents a collection of variables. The definition "nature type" is used only once. Perhaps it would be less confusing if I gave it another name so that it can't be confused with a nature declaration -- maybe "continuous type" or "simultaneous type". Recall that not every quantity is a branch quantity associated with a pair of terminals; there are free quantities too, for modeling non-conservative systems (among other uses). A free quantity is created by a quantity declaration, either a local declaration or an interface declaration. I think you may be assuming incorrectly that a free quantity is always local to a design unit. Let me reiterate; a quantity can be a branch quantity associated with a pair of terminals. The terminals of a branch quantity may be locally declared or they may be interface terminals (or one of each!). A quantity can be a free quantity. A free quantity can be declared in an interface declaration or it can be declared locally in a design unit. >It's either an Across or Through >attribute of a nature or of a component of a composite nature, but no >explicit type. Unless a type that is used in a nature declaration is >automatically associated with that nature. So if (I use an example >from the white paper) we say > > TYPE kirchhoff IS RANGE -1.0E+100 TO +1.0E+100; > > SUBTYPE voltage IS kirchhoff; > SUBTYPE current IS kirchhoff; > > NATURE electrical IS > voltage ACROSS > current THROUGH; > > ENTITY inductor1 IS > GENERIC (L: inductance); > PORT (TERMINAL n1, n2: electrical; QUANTITY q1: current); > END inductor; > >Where the interface element "q1" has the type "current" which is >IMPLICITLY a nature type because it has been used to define the nature >"electrical". Actually, "current" is just an ordinary floating-point >type. It is indeed an ordinary floating-point type. It is also a nature type, because all ordinary floating-point types are nature types, by definition. No reference in a nature declaration is required for this to be true. >This practise, however, should not be allowed. For instance, when one >type is used in two different natures, a "nature-clash" would >result. I do recall something of velocity being used in different >natures, in one as a through and in another as an across >nature-type. > Correct me if I'm wrong. Forcing users to create >different names for both is in my opinion "not done", even if the >impact is rather low. It is a sneaky "behind-your-back" compiler pass >that would violate quite a lot of common sense programming rules. Hmm, >I garbled somewhat, but I do hope you get my point. When declaring two different simple natures you may use the the same type names for both. You get two distinct, "imcompatible" natures -- they have different reference terminals (grounds) and you can't hook a terminal of one nature to a terminal of the other. > >What's the solution: > >1) Allow the creation of special NATURE TYPES. This is a bad idea > because a new keyword would be required or an adaption of the TYPE > syntax which could be left undisturbed with the currently proposed > analog extensions to VHDL, as far as I can tell. > >2) Restrict the nature types and subtypes to the across and through > attributed subtypes, so only types like the following example are > allowed (again taken from the white paper): > > NATURE elec_array IS ARRAY (integer RANGE <>) OF electrical; > > QUANTITY QF1: elec_array'Across (1 TO 10); > > This would reduce the readability of code to be forced to refer to > "current" as "electrical'Across". For readability, you may wish to do use: SUBTYPE volts_vector IS elec_array'Across( 1 TO 10); QUANTITY QF1: volts_vector; Again, this is one way to specify the type of a quantity, but not the only way. A quantity can be any natural type. The branch types of a nature are natural types, but you can declare other natural types too. > >3) Change the definition of a nature to introduce new types in > combination with the new nature, i.e.: > > NATURE electrical IS > voltage IS kirchhoff ACROSS > current IS kirchhoff THROUGH; > > Now voltage and current are explicit nature-types. The restriction > remains that the same type cannot be attributed to more than one > nature, so the abovementioned problem with velocity is not solved. > However, I do think that the result is much clearer > >I do not say that the idea of nature type should be discarded, as it >makes a "domain"-check possible (not to be confused with the >mathematical domain errors and such), a check whether across and >through types are not inadvertedly mixed, instead of explicitly. > >Marq > Ken __________________________________________________________________ Kenneth Bakalar voice +1 410 992 5700 ext. 1204 COMPASS Design Automation fax +1 410 992 3536 5457 Twin Knolls Road email kenb@compass-da.com Columbia MD 20845 USA __________________________________________________________________ From 1076-1-request@sicmail.epfl.ch Fri Jun 2 03:06:46 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Fri, 2 Jun 95 03:06:32 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Fri, 2 Jun 95 03:06:25 -0400 X400-Received: by mta sicmail.epfl.ch in /PRMD=switch/ADMD=arCom/C=ch/; Relayed; Fri, 2 Jun 1995 08:36:44 +0200 Date: Fri, 2 Jun 1995 08:36:44 +0200 X400-Originator: 1076-1-request@sicmail.epfl.ch X400-Recipients: non-disclosure:; X400-Mts-Identifier: [/PRMD=switch/ADMD=arCom/C=ch/;sicmail.ep.331:02.05.95.06.36.44] Priority: Non-Urgent Dl-Expansion-History: 1076-1@epfl.ch ; Fri, 2 Jun 1995 08:36:24 +0200; From: "Jean-michel.Berge" Message-Id: To: analog_reflector <1076-1@epfl.ch> Subject: VHDL-A WG meeting during next DASC X-Mailer: Mail*Link SMTP/MS 3.0.0 The site is finally known for the DASC meetings on 16-17 June. Remember our meeting is scheduled on Saturday 17th, 8h30-16h00. Mentor and to Andrew Guyler are hosting DASC meetings.The address is Mentor Graphics Corporation 1001 Ridder Park Drive, San Jose, CA Directions: Take BROKAW ROAD north from San Jose airport or Highway 101. Pass under Interstate 880. Turn left into Ridder Park. Mentor Graphics is on the left. Jean-Michel From 1076-1-request@sicmail.epfl.ch Fri Jun 2 06:14:27 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Fri, 2 Jun 95 06:14:11 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Fri, 2 Jun 95 06:14:00 -0400 Received: from utep.el.utwente.nl by sicmail.epfl.ch with SMTP (PP) id <08936-0@sicmail.epfl.ch>; Fri, 2 Jun 1995 11:08:12 +0200 Received: from nt.el.utwente.nl (utelnt.el.utwente.nl) by utep.el.utwente.nl with SMTP id AA03596 (5.65c/IDA-1.4.4 for <1076-1@epfl.ch>); Fri, 2 Jun 1995 11:07:00 +0200 Message-Id: <199506020907.AA03596@utep.el.utwente.nl> Received: by nt.el.utwente.nl (1.37.109.4/16.2) id AA25136; Fri, 2 Jun 95 11:09:04 +0100 From: Marq Kole Subject: Re: Quantity types and subtypes To: 1076-1@epfl.ch Date: Fri, 2 Jun 95 11:09:04 WETDST In-Reply-To: ; from "Kenneth Bakalar" at Jun 1, 95 12:26 (noon) Mailer: Elm [revision: 70.85] This is in reply to some comments Ken Bakalar made on my comments regarding the definition of nature types for quantities. > > At 8:29 AM 5/29/95, Marq Kole wrote: > >Hmm, I may seem to be picking a bit on the "Quantities-and-terminals" white > >paper, as I again have some comments, but I still think its a good and > >workable proposal. It's just a few minor quirks that have to be > >adjusted, IMHO. Let's get to the point... > > > >In this paper, quantities, whether declared in the interface list or as > >a free quantity, have a special restriction on their type: it should be > >a "nature-type" or a "nature-subtype". I quote: > > > > "A free quantity declaration declares a quantity of the specified > > type. A nature type is a floating-point type or a composite type > > with elements of anature type. The type of a quantity must be a > > nature type." > > > >Well, that seems fine, until you want to know how to create one: you > >can't, at least not explicitly. > > The logic of that statement works like this: > > FOR ALL t SUCH THAT t IS A scalar type: > IF t IS A floating point type THEN t IS A nature type. > > So every floating point type is a nature type. > > FOR ALL c SUCH THAT c IS A composite type: > IF element type of c IS A nature type THEN c IS A nature type. > > So all arrays of floating-point elements, arrays of arrays and so on, are > also nature types. > > Examples of nature type declarations are: > > TYPE myreal IS RANGE -1.0E-300 TO 1.0E+300; > TYPE myreal_array IS ARRAY (integer RANGE <>) OF myreal; > TYPE myrec IS RECORD > field1: real; > field2: myreal_array(1 to 10); > END RECORD; > > The point is this: the variables (variables in the mathematical rather than > the computer language sense) in a DAE are to be represented by numbers. A > quantity of a scalar type represents a single variable. A quantity of a a > composite type represents a collection of variables. > > The definition "nature type" is used only once. Perhaps it would be less > confusing if I gave it another name so that it can't be confused with a > nature declaration -- maybe "continuous type" or "simultaneous type". > That might solve some problems, but I do think that you want to stress the implicit relation with a nature. So maybe free_quantity_declaration ::= QUANTITY identifier ":" continuous_subtype_indication [ ":=" expression ] ";" continuous_subtype_indication ::= continuous_type_mark [ range_constraint ] scalar_nature_definition ::= continuous_type_mark ACROSS continuous_type_mark THROUGH which links the two implicitly. I admit that it does change the syntax much, but at least the semantics are clearer. > Recall that not every quantity is a branch quantity associated with a pair > of terminals; there are free quantities too, for modeling non-conservative > systems (among other uses). A free quantity is created by a quantity > declaration, either a local declaration or an interface declaration. I > think you may be assuming incorrectly that a free quantity is always local > to a design unit. > My point was that you couldn't create a NATURE TYPE explicitly. One way or another a check has to be made that the floating point type used to create a free quantity with is indeed associated with a nature. It would require that to use free quantities of a certain type that type should not only have been declared but also been associated with a specific nature. A floating point type is not a nature type until it has been associated with a nature somewhere in the design file. > Let me reiterate; a quantity can be a branch quantity associated with a > pair of terminals. The terminals of a branch quantity may be locally > declared or they may be interface terminals (or one of each!). A quantity > can be a free quantity. A free quantity can be declared in an interface > declaration or it can be declared locally in a design unit. > > > >It's either an Across or Through > >attribute of a nature or of a component of a composite nature, but no > >explicit type. Unless a type that is used in a nature declaration is > >automatically associated with that nature. So if (I use an example > >from the white paper) we say > > > > TYPE kirchhoff IS RANGE -1.0E+100 TO +1.0E+100; > > > > SUBTYPE voltage IS kirchhoff; > > SUBTYPE current IS kirchhoff; > > > > NATURE electrical IS > > voltage ACROSS > > current THROUGH; > > > > ENTITY inductor1 IS > > GENERIC (L: inductance); > > PORT (TERMINAL n1, n2: electrical; QUANTITY q1: current); > > END inductor; > > > >Where the interface element "q1" has the type "current" which is > >IMPLICITLY a nature type because it has been used to define the nature > >"electrical". Actually, "current" is just an ordinary floating-point > >type. > > It is indeed an ordinary floating-point type. It is also a nature type, > because all ordinary floating-point types are nature types, by definition. > No reference in a nature declaration is required for this to be true. > I think you should say so explicitly in the proposal. I do not like the idea to "promote" every floating point type to a nature type. VHDL is by choice a strongly typed language, requiring users to make consistent and logical interfaces. One way terminals are restricted to have a single nature and disallow any explicit links between two terminals of different natures, on the other hand the use of free quantities is released from this strict "law of nature" by allowing any floating point type, even those not directly associated with a previous or subsequent nature definition. I'd like to see a restricted choice of types for quantities and have variables of a floating point type take on the role of messager between two quantities of different nature types inside the architecture bodies. I think (free) quantities in an interface should be restricted in nature type, enforcing a design to "belong" to a specific physical domain. Do you or anyone else maybe have an example where the nature of a free quantity in a model is not known a priori? The scheme presented above should interact at the level of the simultaneous statements. Using quantities as "analog values" of a specific nature and floating point variables as "analog values" in general, the requirement that rhs and lhs of a simple simultaneous expression have the same nature type is met. For instance for a motor or a generator, we might end up with two simultaneous statements, one for the mechanical part and one for the electrical part. Their interaction can be managed through variables who are "nature-less". The opportunities for static verification of the analog part through type and nature check of the terminals and quantities is thus retained. Marq -- +-----------------------------------+--------------------------------------+ | Marq Kole, | email: M.E.Kole@el.utwente.nl | | Lab. Networktheory, EF-9254, | tel: +31-53-892773 | | Dept. of Electr.Engineering, | fax: +31-53-334701 | | University of Twente, Holland | | WWW: http://utelnt.el.utwente.nl/links/kole/marq.html | +-------------------------------+------------------------------------------+ From 1076-1-request@sicmail.epfl.ch Fri Jun 2 12:29:02 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Fri, 2 Jun 95 12:28:50 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Fri, 2 Jun 95 12:28:43 -0400 Received: from mail.Germany.EU.net by sicmail.epfl.ch with SMTP (PP) id <06653-0@sicmail.epfl.ch>; Fri, 2 Jun 1995 17:54:05 +0200 Received: by mail.Germany.EU.net with UUCP (8.6.5:29/EUnetD-2.5.1.g) via EUnet id RAA25346; Fri, 2 Jun 1995 17:55:45 +0200 Original-Received: from obelix.noname anacad.de by anacad.de (4.1/SMC-5.11) Pp-Warning: Illegal Received field on preceding line Received: from chip by obelix.noname (4.1/SMI-4.1) id AA22675; Fri, 2 Jun 95 17:38:43 +0200 X-Mailer: InterCon TCP/Connect II 1.2 Message-Id: <9506021739.AA17721@chip.robelix> Date: Fri, 2 Jun 1995 17:39:17 +0100 From: Larry Moore To: 1076-1@epfl.ch Cc: Doug_Lundin@mentorg.com Subject: Computer Design Article: more comments DISCLAIMER ========== An article has appeared in Computer Design, written by Stephen Ohr. It contains the following statements: "Two of these toolsets - SpectreHDL from Cadsence Design Systems (San Jose CA), introduced last summer and Mix-VHDL from ANACAd EES (Milpitas CA) - are said to be 4working prototypes4 of the analog-language extensions being evolved for VHDL." This contains a number of mistakes. a) The product name is MixVHDL. b) This is NOT a prototype, it is a product. There are three versions of this product namely EldoHDL, EldoVHDL, MixVHDL. Each are based on the HDL-A structural and behavioral language. c) We have NEVER claimed and do not claim that the HDL-A language is a prototype of what is being done in 1076.1 - that would be counterproductive for a number of reasons, including the fact that the HDL-A language is a stable product - of which hundreds of licenses are in industrial use. We DO SAY THAT: ============== a) Our MixVHDL product includes full VHDL capability - obvious true since we have merged with the V-System simulator - supporting even VHDL-93 and VITAL b) We do support analog and digital hierarchy - easily proven by trying it - or see us at DAC 95; c) The HDL-A language does use VHDL semantics - self evident statement when you look at it; d) Our approach is based on the LES document and DOD; e) Anyone modeling using HDL-A has at his disposal the full scope and exact syntax and semantics of VHDL-93 - with extensions for analog of course: that person may later convert to whatever VHDL-A will be, easily because VHDL-A and HDL-A semantics are self-evidently similar and via the Language Sensitive Mapper (tm). IN PARTICULAR PLEASE NOTE THAT: ============================== a) At no time have we said that we have already the implemented 1076.1 Standard, this being quite obviously false and easily proven to be so - there is no standard yet. b) At no time did we try and use the IEEE and IEEE members to further our commercial purposes. From 1076-1-request@sicmail.epfl.ch Fri Jun 2 13:28:45 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Fri, 2 Jun 95 13:28:40 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Fri, 2 Jun 95 13:28:35 -0400 Received: from chronos.synopsys.com by sicmail.epfl.ch with SMTP (PP) id <07911-0@sicmail.epfl.ch>; Fri, 2 Jun 1995 18:48:05 +0200 Received: from atropos.synopsys.com by chronos.synopsys.com with SMTP id AA11940 (5.65c/IDA-1.4.4 for <1076-1@epfl.ch>); Fri, 2 Jun 1995 09:47:42 -0700 Received: from limbo.synopsys.com (limbo.synopsys.com [146.225.92.31]) by atropos.synopsys.com (8.6.9/8.6.9) with ESMTP id JAA06949; Fri, 2 Jun 1995 09:47:39 -0700 From: "Ivan M. Kissiov" Received: (kissiov@localhost) by limbo.synopsys.com (8.6.9/8.6.5) id JAA10635; Fri, 2 Jun 1995 09:47:32 -0700 Date: Fri, 2 Jun 1995 09:47:32 -0700 Message-Id: <199506021647.JAA10635@limbo.synopsys.com> To: 1076-1@epfl.ch Subject: Re: Computer Design Article: more comments Cc: Doug_Lundin@mentorg.com > From: Larry Moore > "... propaganda deleted ..." > > c) The HDL-A language does use VHDL semantics - self evident statement when > you look at it; I am sorry to be picking on details, but VHDL IS NOT a language the semantics of which can be inferred from it`s grammar. Therefore it would be quite unlikely that it is self-evident, regardless of wheter you look at it or not. Beside, if it is SLEF evident, it doesn`t need to be predicated, nor it neeeds an observer. > ivan From 1076-1-request@sicmail.epfl.ch Tue Jun 6 12:30:44 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Tue, 6 Jun 95 12:30:22 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Tue, 6 Jun 95 12:30:15 -0400 Received: from clsi.columbia.compass-da.com by sicmail.epfl.ch with SMTP (PP) id <19181-0@sicmail.epfl.ch>; Tue, 6 Jun 1995 17:36:10 +0200 Received: from [162.17.30.159] ([162.17.30.159]) by clsi.columbia.compass-da.com (8.6.12/8.6.9) with SMTP id LAA12661 for <1076-1@epfl.ch>; Tue, 6 Jun 1995 11:26:01 -0400 Reply-To: kenb@compass-da.com X-Sender: kennyb@clsi.columbia.compass-da.com (Unverified) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 6 Jun 1995 11:35:02 -0400 To: 1076-1@epfl.ch From: kenb@compass-da.com (Kenneth Bakalar) Subject: Re: Quantity types and subtypes (Kole) At 7:09 AM 6/2/95, Marq Kole wrote: >This is in reply to some comments Ken Bakalar made on my comments regarding >the definition of nature types for quantities. > >> >> At 8:29 AM 5/29/95, Marq Kole wrote: >> >Hmm, I may seem to be picking a bit on the "Quantities-and-terminals" white >> >paper, as I again have some comments, but I still think its a good and >> >workable proposal. It's just a few minor quirks that have to be >> >adjusted, IMHO. Let's get to the point... >> > >> >In this paper, quantities, whether declared in the interface list or as >> >a free quantity, have a special restriction on their type: it should be >> >a "nature-type" or a "nature-subtype". I quote: >> > >> > "A free quantity declaration declares a quantity of the specified >> > type. A nature type is a floating-point type or a composite type >> > with elements of anature type. The type of a quantity must be a >> > nature type." >> > >> >Well, that seems fine, until you want to know how to create one: you >> >can't, at least not explicitly. >> >> The logic of that statement works like this: >> >> FOR ALL t SUCH THAT t IS A scalar type: >> IF t IS A floating point type THEN t IS A nature type. >> >> So every floating point type is a nature type. >> >> FOR ALL c SUCH THAT c IS A composite type: >> IF element type of c IS A nature type THEN c IS A nature type. >> >> So all arrays of floating-point elements, arrays of arrays and so on, are >> also nature types. >> >> Examples of nature type declarations are: >> >> TYPE myreal IS RANGE -1.0E-300 TO 1.0E+300; >> TYPE myreal_array IS ARRAY (integer RANGE <>) OF myreal; >> TYPE myrec IS RECORD >> field1: real; >> field2: myreal_array(1 to 10); >> END RECORD; >> >> The point is this: the variables (variables in the mathematical rather than >> the computer language sense) in a DAE are to be represented by numbers. A >> quantity of a scalar type represents a single variable. A quantity of a a >> composite type represents a collection of variables. >> >> The definition "nature type" is used only once. Perhaps it would be less >> confusing if I gave it another name so that it can't be confused with a >> nature declaration -- maybe "continuous type" or "simultaneous type". >> > >That might solve some problems, but I do think that you want to stress >the implicit relation with a nature. So maybe > > free_quantity_declaration ::= > QUANTITY > identifier ":" continuous_subtype_indication [ ":=" expression ] ";" > > continuous_subtype_indication ::= > continuous_type_mark [ range_constraint ] > > scalar_nature_definition ::= > continuous_type_mark ACROSS > continuous_type_mark THROUGH > >which links the two implicitly. I admit that it does change the syntax >much, but at least the semantics are clearer. > >> Recall that not every quantity is a branch quantity associated with a pair >> of terminals; there are free quantities too, for modeling non-conservative >> systems (among other uses). A free quantity is created by a quantity >> declaration, either a local declaration or an interface declaration. I >> think you may be assuming incorrectly that a free quantity is always local >> to a design unit. >> > >My point was that you couldn't create a NATURE TYPE explicitly. One way or >another a check has to be made that the floating point type used to create >a free quantity with is indeed associated with a nature. It would require >that to use free quantities of a certain type that type should not only >have been declared but also been associated with a specific nature. A >floating point type is not a nature type until it has been associated with >a nature somewhere in the design file. The restriction you propose would be best expressed as a static semantic constraint on the exisiting syntax, something of the form "the base type of every quantity must be the base type of a type mentioned in the across or through aspect of a scalar nature definition". This expression of the idea isn't specific enough to go in an LRM, but I think it is the idea you want. It is asking something additional to the "nature type" rule, which only requires that the elements of the type are floating-point values. Your addition would require that the type names used in a free quantity declaration also be the type names used in a nature declaration. Since the type names could be used in more than one nature declaration, they aren't specific to a particular nature. I don't like the additional restriction because I think it adds complexity both to the LRM and to the modeler's code (by forcing the use of type conversions) that does not have sufficient corresponding benefit. > >> Let me reiterate; a quantity can be a branch quantity associated with a >> pair of terminals. The terminals of a branch quantity may be locally >> declared or they may be interface terminals (or one of each!). A quantity >> can be a free quantity. A free quantity can be declared in an interface >> declaration or it can be declared locally in a design unit. >> >> >> >It's either an Across or Through >> >attribute of a nature or of a component of a composite nature, but no >> >explicit type. Unless a type that is used in a nature declaration is >> >automatically associated with that nature. So if (I use an example >> >from the white paper) we say >> > >> > TYPE kirchhoff IS RANGE -1.0E+100 TO +1.0E+100; >> > >> > SUBTYPE voltage IS kirchhoff; >> > SUBTYPE current IS kirchhoff; >> > >> > NATURE electrical IS >> > voltage ACROSS >> > current THROUGH; >> > >> > ENTITY inductor1 IS >> > GENERIC (L: inductance); >> > PORT (TERMINAL n1, n2: electrical; QUANTITY q1: current); >> > END inductor; >> > >> >Where the interface element "q1" has the type "current" which is >> >IMPLICITLY a nature type because it has been used to define the nature >> >"electrical". Actually, "current" is just an ordinary floating-point >> >type. >> >> It is indeed an ordinary floating-point type. It is also a nature type, >> because all ordinary floating-point types are nature types, by definition. >> No reference in a nature declaration is required for this to be true. >> > >I think you should say so explicitly in the proposal. I do not like the idea >to "promote" every floating point type to a nature type. VHDL is by choice >a strongly typed language, requiring users to make consistent and logical >interfaces. One way terminals are restricted to have a single nature >and disallow any explicit links between two terminals of different natures, >on the other hand the use of free quantities is released from this strict >"law of nature" by allowing any floating point type, even those not directly >associated with a previous or subsequent nature definition. I'd like to >see a restricted choice of types for quantities and have variables of a >floating point type take on the role of messager between two quantities >of different nature types inside the architecture bodies. I think (free) >quantities in an interface should be restricted in nature type, enforcing >a design to "belong" to a specific physical domain. Do you or anyone else >maybe have an example where the nature of a free quantity in a model is not >known a priori? In top down design people start designing their system at an abstract level and defer the decision about how certain parts of the system will be implemented till later. At this level models tend to be signal flow models, where the ports are interface quantities. For instance, an integrator is just that, it has not been "given" a technology yet. > >The scheme presented above should interact at the level of the simultaneous >statements. Using quantities as "analog values" of a specific nature and >floating point variables as "analog values" in general, the requirement >that rhs and lhs of a simple simultaneous expression have the same nature >type is met. For instance for a motor or a generator, we might end up with >two simultaneous statements, one for the mechanical part and one for the >electrical part. Their interaction can be managed through variables who >are "nature-less". The opportunities for static verification of the analog >part through type and nature check of the terminals and quantities is >thus retained. Variables can not be used to represent unknowns in the equations. Variables get their values by assignment in processes. Their scope is limited to the process in which they are declared. In contrast, quantities get their values by simultaneous solution of all of the equations of the model. They cannot be assigned values in processes, but they can be used in processes because the scope of a quantity is the same as the scope of a signal declared in the same place -- for example, anywhere in the statement part of the architecture in which the quantity is declared. In general, the expression of a simple simultaneous statement may involve free quantities together with branch quantities from terminals of one or more natures. The existing VHDL type system is too weak to characterize a situation like this -- we would need a "units and dimensions" system to do that. At this point, we only require that both sides be numbers (or arrays or records of numbers) of the same type. Frequently that type is going to be the predefined type "Real". Variables could not be used in the messenger role unless they were of the same type as the quantities (and then only in the sequential context, unless you use shared variables). For example, the assignment V := Q; is illegal unless V and Q are the same type. > >Marq > Ken From 1076-1-request@sicmail.epfl.ch Wed Jun 7 04:57:45 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Wed, 7 Jun 95 04:57:35 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Wed, 7 Jun 95 04:57:29 -0400 Received: from wall.scn.de by sicmail.epfl.ch with SMTP (PP) id <01138-0@sicmail.epfl.ch>; Wed, 7 Jun 1995 10:16:09 +0200 Received: (from mchetri@localhost) by wall.scn.de (8.6.11/8.6.11) id JAA19904 for 1076-1@epfl.ch; Wed, 7 Jun 1995 09:20:02 +0200 Date: Wed, 7 Jun 1995 09:20:02 +0200 From: Marc Chetrit Message-Id: <199506070720.JAA19904@wall.scn.de> Apparently-To: 1076-1@epfl.ch I have some comments on the last Larry Moore E-mail. > Anyone modeling using HDL-A has at his disposal the full scope an exact >syntax and semantics of VHDL-93 with extensions for analog of course ... The word FULL is a mistake, HDL-A is only based on VHDL semantics and syntax. It uses only a subset of VHDL-93: just one process, no resolution function, no access type... I'am just want to correct this mistake, yet I'm thinking we 're not here to speak about a commercial product. Except if that provides usefull informations. But to my mind it's a good think some product, like HDL-A or SpectreHDL, based (like Larry said) on the LES document and DOD, appear. That can involved users in VHDL-A. Philippe MOYER -------------------------------------------------------------------------- Philippe MOYER \\|// SIEMENS AUTOMOTIVE "(O-O)" TOULOUSE ------------------------------oOO--(_)--OOo------------------------------- Groupe CAE | Tel. : 61-19-82-21 Avenue du Mirail | Fax : 61-44-47-02 BP 31036 TOULOUSE Cedex, France | Mail : casse@risc2.insa-tlse.fr -------------------------------------------------------------------------- From 1076-1-request@sicmail.epfl.ch Wed Jun 7 07:05:14 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Wed, 7 Jun 95 07:05:07 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Wed, 7 Jun 95 07:05:01 -0400 Received: from mail.Germany.EU.net by sicmail.epfl.ch with SMTP (PP) id <05024-0@sicmail.epfl.ch>; Wed, 7 Jun 1995 12:21:03 +0200 Received: by mail.Germany.EU.net with UUCP (8.6.5:29/EUnetD-2.5.1.g) via EUnet id MAA20594; Wed, 7 Jun 1995 12:22:46 +0200 Original-Received: from obelix.noname anacad.de by anacad.de (4.1/SMC-5.11) Pp-Warning: Illegal Received field on preceding line Received: from chip by obelix.noname (4.1/SMI-4.1) id AA02757; Wed, 7 Jun 95 12:13:11 +0200 X-Mailer: InterCon TCP/Connect II 1.2 Message-Id: <9506071213.AA42052@chip.robelix> Date: Wed, 7 Jun 1995 12:13:42 +0100 From: Larry Moore To: 1076-1@epfl.ch Subject: Comments from Philippe (Marc) Philippe, A clarification! MixVHDL has embedded the V-System simulator from Model Technology Inc. and thus incorporates completely the VHDL-93 standard, including analysis, compilation and execution. In my original message it was perhaps not clearly enough stated that: HDL-A == VHDL-93 plus extensions! Those extensions are for analog hierarchy and obviously analog modeling. Note that the Computer Design Article refers to the version of HDL-A which is in the MixVHDL product, which is currently in test. Your comments are perfectly correct when they apply to HDL-A which you may be using or have seen. That version was limited to "behavioral modeling". As a general comment, commercial discussions in this reflector should be avoided - we all agree. What is true however is that an article appeared where statements were made regarding the "opinions" of the 1076.1 WG on commercial products - though it is clear that no such opinion was represented (I hope). We (ANACAD) have no choice but to respond. I think that in this case the WG should ALSO respond to make clear that the WG does not take official positions on such issues. Larry Moore > Date: Wed, 7 Jun 1995 09:20:02 +0200 > From: Marc Chetrit > Message-Id: <199506070720.JAA19904@wall.scn.de> > Apparently-To: 1076-1@epfl.ch > > I have some comments on the last Larry Moore E-mail. > > > Anyone modeling using HDL-A has at his disposal the full scope an > > exact > >syntax and semantics of VHDL-93 with extensions for analog of > >course ... > > The word FULL is a mistake, HDL-A is only based on VHDL semantics and > syntax. It uses only a subset of VHDL-93: just one process, no > resolution function, no access type... > > I'am just want to correct this mistake, yet I'm thinking we 're not > here to speak about a commercial product. Except if that provides > usefull informations. > > But to my mind it's a good think some product, like HDL-A or > SpectreHDL, based (like Larry said) on the LES document and DOD, > appear. That can involved users in VHDL-A. > > Philippe MOYER > > > ------------------------------------------------------------------------- > - > > Philippe MOYER \\|// SIEMENS AUTOMOTIVE > "(O-O)" TOULOUSE > ------------------------------oOO--(_)--OOo------------------------------ > - Groupe CAE | Tel. : 61-19-82-21 > Avenue du Mirail | Fax : 61-44-47-02 > BP 31036 TOULOUSE Cedex, France | Mail : casse@risc2.insa-tlse.fr > ------------------------------------------------------------------------- > - > From 1076-1-request@sicmail.epfl.ch Wed Jun 7 11:22:27 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Wed, 7 Jun 95 11:22:03 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Wed, 7 Jun 95 11:21:58 -0400 X400-Received: by mta sicmail.epfl.ch in /PRMD=switch/ADMD=arCom/C=ch/; Relayed; Wed, 7 Jun 1995 16:32:08 +0200 Date: Wed, 7 Jun 1995 16:32:08 +0200 X400-Originator: 1076-1-request@sicmail.epfl.ch X400-Recipients: non-disclosure:; X400-Mts-Identifier: [/PRMD=switch/ADMD=arCom/C=ch/;sicmail.ep.734:07.05.95.14.32.08] Priority: Non-Urgent Dl-Expansion-History: 1076-1@epfl.ch ; Wed, 7 Jun 1995 16:32:06 +0200; From: "Jean-michel.Berge" Message-Id: To: analog_reflector <1076-1@epfl.ch> Subject: Please ! X-Mailer: Mail*Link SMTP/MS 3.0.0 Dear VHDL-A WG members, On this reflector, we have between 200 and 300 Working group members. Although everybody is working in the same direction (having a high quality standard as soon as possible), competitors are present and work together. This is especially true for tool vendors. It is therefore obvious that discussions about tool capabilities can very quickly degenerate in a big mess. One of the aspects of my role is to avoid this. I fully agree with Larry Moore statement: >As a general comment, commercial discussions in this reflector should be >avoided. But, It is clearly impossible to avoid that tool's names appear on the reflector. This is unrealistic since many analog designers usually discuss langage issues through tool characterics... and we need analog designer's inputs... But we can discipline ourself: if you think that such or such information about a given tool which has been published on the reflector is wrong, just send a message to a member of the executive committee. We will do our best to obtain the correction (or the clarification) of this information (by its author) without polemics. A last word: I think that Ernst's Clarification about computer design's article was clear enough and that the case is closed. If you disagree on this, or think that other things are wrong in this article, please let me PERSONALLY know. Jean-Michel Berge Chair of 1076.1 From 1076-1-request@sicmail.epfl.ch Mon Jun 12 11:47:09 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Mon, 12 Jun 95 11:46:50 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Mon, 12 Jun 95 11:46:44 -0400 Received: from trefle.saclay.cea.fr by sicmail.epfl.ch with SMTP (PP) id <15378-0@sicmail.epfl.ch>; Mon, 12 Jun 1995 14:17:17 +0200 Received: from oeillet.saclay.cea.fr by trefle.saclay.cea.fr (8.6.10/ CEANET-ROUTER-3.0) with ESMTP id OAA08717 for <1076-1@epfl.ch>; Mon, 12 Jun 1995 14:17:28 +0200 Received: from dphs07.saclay.cea.fr by oeillet.saclay.cea.fr (8.6.10/ CEANET-ROUTER-3.0) with SMTP id OAA24014 for <1076-1@epfl.ch>; Mon, 12 Jun 1995 14:19:29 +0200 Received: by dphs07.saclay.cea.fr (4.1/SUNDAP-2.0.1) id AA09355; Mon, 12 Jun 95 14:16:32 +0200 Date: Mon, 12 Jun 95 14:16:32 +0200 From: M Rouger Message-Id: <9506121216.AA09355@dphs07.saclay.cea.fr> To: 1076-1@epfl.ch Subject: A.H.D.L. Dear sir, I just give you my email's references in order to get more continue information about your work;this demand is coming from an seminar which was organised by M.WLADIMIRESCU who gave us your adress. Best Regards. M.ROUGER From 1076-1-request@sicmail.epfl.ch Mon Jun 12 18:49:35 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Mon, 12 Jun 95 18:49:32 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Mon, 12 Jun 95 18:49:29 -0400 Received: from gatekeeper.ray.com by sicmail.epfl.ch with SMTP (PP) id <28425-0@sicmail.epfl.ch>; Tue, 13 Jun 1995 00:33:28 +0200 Received: from localhost (mailer@localhost) by gatekeeper.ray.com (8.6.4/8.6.5) id SAA05068 for <1076-1@epfl.ch>; Mon, 12 Jun 1995 18:31:30 -0400 Received: from sud2.ed.ray.com by gatekeeper.ray.com; Mon Jun 12 18:31:57 1995 Received: from SUD2.ED.RAY.COM by SUD2.ED.RAY.COM (PMDF V4.2-10 #4335) id <01HRMLU70OM88WYS1G@SUD2.ED.RAY.COM>; Mon, 12 Jun 1995 18:31:59 EDT Date: Mon, 12 Jun 1995 18:31:58 -0400 (EDT) From: "Joe Gwinn, 508-440-3330" Subject: Experience with solution of DAEs To: 1076-1@epfl.ch Message-Id: <01HRMLU720UQ8WYS1G@SUD2.ED.RAY.COM> X-Envelope-To: 1076-1@epfl.ch X-Vms-To: IN%"1076-1@epfl.ch" X-Vms-Cc: GWINN Mime-Version: 1.0 Content-Transfer-Encoding: 7BIT On vacation, I read some articles from Dr. Cellier and his students. It would appear that they have solved a number of the problems with DAEs that we have been discussing. Two articles in particular impressed me as on point: Elmqvist, H., M. Otter, and F.E. Cellier (1995), "Inline Integration: A New Mixed Symbolic/Numeric Approach for Solving Differential-Algebraic Equation Systems," Keynote Address, Proceedings ESM'95, European Simulation Multiconference, Prague, Czech Republic, June 5-8. 12 pages. The above, a keynote address, is the main article. Apparently, Cellier's 1995 book "Continuous System Simulation" covers some of the same ground, presumably at greater length. The publisher is Springer-Verlag. Cellier, F.E., M. Otter, and H. Elmqvist (1995), "Bond Graph Modeling of Variable Structure Systems," Proceedings ICBGM'95, Second International Conference on Bond Graph Modeling and Simulation, Las Vegas, Nevada, January 15-18, pp.49-55. The above article shows an approach to handling switches, where the discontinuities are sidestepped. By contrast, Vlach handled them directly. I don't know that Cellier's sidestep is all that general, but it would appear that one can use both approaches at once. Electronic copies may be obtained by direct email request to Dr. Cellier at "CELLIER@CADMUS.ece.arizona.edu". His response to my request was quite rapid. I just received "Numerical Solution of Initial-Value Problems in DAEs", Brenan, Campbell, and Petzold, North-Holland 1989, which was mentioned on the net as a good source, page 138 et seq in particular. I will read this over the next week or so. Joe Gwinn From 1076-1-request@sicmail.epfl.ch Tue Jun 13 10:50:16 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Tue, 13 Jun 95 10:50:12 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Tue, 13 Jun 95 10:50:05 -0400 Received: from isis.u-strasbg.fr by sicmail.epfl.ch with SMTP (PP) id <10200-0@sicmail.epfl.ch>; Tue, 13 Jun 1995 15:58:20 +0200 Received: from erm1 (root@erm1.u-strasbg.fr [130.79.74.61]) by isis.u-strasbg.fr (8.6.9/8.6.9) with SMTP id PAA25082 for <1076-1@epfl.ch>; Tue, 13 Jun 1995 15:56:02 +0200 Date: Tue, 13 Jun 1995 16:00:05 +0100 From: Bruno Boettcher Subject: mail addresses of VHDELDO Team To: 1076-1@epfl.ch Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello, sorry for disturbing but I do not know where to ask elsewhere and since these are persons that should be well known here... I was reading a paper taken from EURODAC 93 about VHDELDO with following Authors H. El Tahawy, D. Rodriguez, S. Garcia-Sabiro, J.J- Mayol I was specially interested by the articles in the bibliography but encountered a big problem in getting those from the VHDL-Forum spring 91 Meeting in Marseille. Our bibliotheque is unable to find any trace of this Meeting... any help is apreciated ciao bboett ============================================================== bboett@erm1.u-strasbg.fr http://sneezy.u-strasbg.fr/~bboett =============================================================== the total amount of intelligence on earth is constant. human population is growing.... From 1076-1-request@sicmail.epfl.ch Mon Jun 19 07:49:28 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Mon, 19 Jun 95 07:49:26 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Mon, 19 Jun 95 07:48:27 -0400 Received: from mailgate.Cadence.COM by sicmail.epfl.ch with SMTP (PP) id <01576-0@sicmail.epfl.ch>; Mon, 19 Jun 1995 11:00:14 +0200 Received: (from smap@localhost) by mailgate.Cadence.COM (8.6.8/8.6.8) id CAA17584 for <1076-1@epfl.ch>; Mon, 19 Jun 1995 02:00:09 -0700 Received: from cds2072.cadence.com(158.140.24.54) by mailgate.cadence.com via smap (V1.0mjr) id sma017504; Mon Jun 19 01:59:56 1995 Received: from mailgate.Cadence.COM (mailgate.cadence.com [158.140.2.1]) by cds2072.Cadence.COM (8.6.8/8.6.8) with ESMTP id BAA05731 for ; Mon, 19 Jun 1995 01:59:51 -0700 Received: (from smap@localhost) by mailgate.Cadence.COM (8.6.8/8.6.8) id BAA17499 for ; Mon, 19 Jun 1995 01:59:50 -0700 Received: from vhdl.vhdl.org(198.31.14.3) by mailgate.cadence.com via smap (V1.0mjr) id sma017450; Mon Jun 19 01:59:32 1995 Received: by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA17864; Mon, 19 Jun 95 01:29:22 PDT Date: Mon, 19 Jun 95 01:29:22 PDT From: jose@vhdl.org (Jose Torres) Message-Id: <9506190829.AA17864@vhdl.vhdl.org> To: math@vhdl.org Subject: minutes from meeting on 6/16/95 VHDL MATH PACKAGE WORKING GROUP, P1076.2 Minutes of meeting in San Jose, 16 June 1995 Present: Jose Torres (Chair), jose@vhdl.org Charles Swart Chuck Swart John Hines Greg Peterson Joanne DeGroat Next meeting: most probably at VIUF in October at Boston, MA, USA. SUMMARY OF MEETING J. Torres presented an overview of deliverables for this group, status of the standardization process for this standard, expected schedule, and open issues. C. Swart presented an overview on the test bench for 1076.2, as well as issues regarding accuracy to compare results and compare with zero. Open issues were discussed and proposals for resolution were presented 1. DELIVERABLES for P1076.2 The VHDL math packages (P1076.2) will consist of basic functions and type conversions for real and complex types. It consists of two packages: MATH_REAL and MATH_COMPLEX. The packages will be installed in library IEEE. The deliverables will consist of the following: package declarations, package bodies, and documentation for the standard. A testbench will be prepared for each package as a guideline for implementors, but it will not formally be part of the standard and/or the documentation. The latest version of the packages is available through anonymous ftp from vhdl.org, in the directory /vi/math/package, file names are: math_head.6.13.95.vhd math_body.6.13.95.vhd or math.6.13.95.tar.Z -- for tar compressed version of the 2 files The packages can be retrieved as follows: ftp vhdl.org username: anonymous password: ftp> cd /vi/math/package ftp> get math_head.6.13.95.vhd ftp> get math_body.6.13.95.vhd ftp> bye If you do not have access to ftp, send an e-mail request to jose@vhdl.org 2. STATUS of P1076.2 All documentation for P1076.2 has been sent to IEEE for balloting. Based on the most up-to-date information, IEEE is planning to start sending ballots out by 6/15/95. Assuming that ballots are mailed around 6/15/95, the current tentative schedule is as follows: - balloting: 6/22 - 7/22 - address negative ballots: 7/22- 8/22 - submit standard to IEEE board: 9/15/95 - get IEEE approval: 12/95 (board gets together every quarter) For all of you who are part of the balloting group, please MAKE SURE TO RETURN YOUR MATERIALS ASAP so that we have time to address your answers and make the 9/15/95 date, which is critical. If we miss the September date, then we may need to wait until 3/96 to get IEEE approval. The following is an extract of the conformance rules discussed and mentioned in the documentation that apply and pertain to the use and implementation of this standard: a) No modifications shall be made to the package declarations whatsoever b) The standard mathematical definition and conventional meaning of the mathematical functions that are part of this standard, which are clarified by the Math_Real and Math_Complex package bodies, represent the formal semantics of the implementation of the Math_Real and Math_Complex package declarations. Implementers of these packages may choose to simply compile the package bodies as they are; or they may choose to implement the package bodies in the most efficient form available to the user. Users shall not implement a semantic that differs from the formal semantic specified herein. c) The Math_Real package shall be built on top of the standard data type and precision requirements for floating point operations defined in IEEE P1076-1993 (STD.STANDARD) d) The minimum precision required is that of the VHDL LRM (IEEE P1076): minimum of six decimal digits of precision in a range contained within the bounds -1E38 to 1E38 inclusive. Because of this reason and the fact that the functions are implemented on digital computers with only finite precision, the functions provided in this set of packages can, at best, only approximate the corresponding mathematically defined functions. An implementation is allowed to provide a higher precision. e) For some functions, the implementation must deliver "prescribed results" for certain special arguments, as defined in the comments for the functions both in the function declaration and the function body. The purpose is to strengthen the accuracy requirements at special argument values. Prescribed results take precedence over maximum relative error requirements. f) The semantics of the standard require that all the functions in the packages detect and report invalid parameters (out of range) through an assert statement. Domain of valid values is indicated in the Math_Real and Math_Complex package declarations. The default value of the severity level shall be Error. An implementation is allowed to provide a mechanism for the user to redefine the value of the severity level. g) The semantics of the standard do not require detection of overflow or underflow. Therefore, detection of underflow/overflow is optional and implementation dependent h) A definition of what comprises the capability of representing and distinguishing signed zeroes is beyond the scope of this standard. Implementations are allowed the freedom not to exploit the capability even when available. i) If an implementation chooses to provide any extensions beyond the minimum requirements of this standard (e.g., precision, overflow handling, ...), then it shall document its behavior accordingly. 3. ISSUES with P1076.2 Currently IEEE is in the process of reviewing the scope and text of copyright declarations, as well as whether or not the source code part of a standard will be available for free distribution or not. Therefore, the current copyright in the packages for P1076.2 is temporary and subject to change based on IEEE's resolution on this matter. This is a very controversial matter that is being reviewed by all the standardization groups that are in the process of submitting documentation for balloting. A proposal was presented to modify the documentation to document the standard without including the source code for the packages (POSIX like), and put the source code in a different place for free access. We will address this issue during the balloting period. 4. TESTBENCH: Status and Issues The testbench, which is not part of the standard, will be provided as a reference for implementors and will not be part of the documentation. The testbench is completely self-contained and fully written in VHDL. The test bench exercises data points for all the functions, compares the values generated by an implementation against a set of "golden" outputs, and produces a report with min accuracy found for each function. The goal of the test bench is to provide a clue on how close an implementation is to the expected results and accuracy, but not to be a validation tool. It is important to note that the math package results may be slightly different on different workstation combinations due to the workstations particular support for floating point arithmetic, which may not be immediately apparent to the average VHDL user. Also, there are issues regarding the comparison of values against zero (i.e., should e-25 be considered close or far from e-40?). The current status of the test bench is as follows: a template for all the functions is available, a reasonable/adequate set of data points is available for some functions but not all, further work/help is needed to complete the sets of data points, it has been run on 4 different commercial VHDL simulation tools. The current version of the test bench is only available upon request, since it is not complete. If you are interested on receiving a copy, please send e-mail to jose@vhdl.org or cswart@analogy.com. Once the test bench is complete, it will be placed in the /vi/math/package directory and eventually will be transferred to John Hines, so that it becomes part of the VHDL test suite his group is responsible for. From 1076-1-request@sicmail.epfl.ch Mon Jun 19 12:45:22 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Mon, 19 Jun 95 12:45:15 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Mon, 19 Jun 95 12:45:40 -0400 Received: from isis.u-strasbg.fr by sicmail.epfl.ch with SMTP (PP) id <10492-0@sicmail.epfl.ch>; Fri, 16 Jun 1995 12:37:11 +0200 Received: from erm1 (root@erm1.u-strasbg.fr [130.79.74.61]) by isis.u-strasbg.fr (8.6.9/8.6.9) with SMTP id MAA03294 for <1076-1@epfl.ch>; Fri, 16 Jun 1995 12:34:55 +0200 Date: Fri, 16 Jun 1995 12:38:59 +0100 From: Bruno Boettcher Subject: partial Diff's with VHDL-A To: 1076-1@epfl.ch Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello perhaps a stupid question: In all papers about the new 1076.1 Norm I have read that partial differentiations would not be supported. I could not find the reason for it. this point does annoy me since for physical simulations (e.g. hydraulic or solar cell simulations) I need partial differentiations. could somebody please explain me the reason for this omission? ciao bboett ============================================================== bboett@erm1.u-strasbg.fr http://sneezy.u-strasbg.fr/~bboett =============================================================== the total amount of intelligence on earth is constant. human population is growing.... From 1076-1-request@sicmail.epfl.ch Mon Jun 19 14:26:28 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Mon, 19 Jun 95 14:26:09 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Mon, 19 Jun 95 14:26:26 -0400 Received: from clsi.columbia.compass-da.com by sicmail.epfl.ch with SMTP (PP) id <01457-0@sicmail.epfl.ch>; Mon, 19 Jun 1995 18:55:15 +0200 Received: from [162.17.30.157] ([162.17.30.157]) by clsi.columbia.compass-da.com (8.6.12/8.6.9) with SMTP id MAA18120 for <1076-1@epfl.ch>; Mon, 19 Jun 1995 12:44:19 -0400 Reply-To: kenb@compass-da.com X-Sender: kennyb@clsi.columbia.compass-da.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 19 Jun 1995 12:54:44 -0400 To: 1076-1@epfl.ch From: kenb@compass-da.com (Kenneth Bakalar) Subject: Time in VHDL-A Time in VHDL-A ================= 0. Revision history 6/2/95 -- Initial version. 1. Introduction The representation of time in the analog solver must have the constant relative precision provided by a floating-point representation of numbers. A VHDL simulator uses an integer-based representation with constant absolute precision over its entire range. Synchronization between the solver and the VHDL kernel process requires the normalization of the two representations. 2. Representation of time in VHDL Type time is a member of the class of physical types. It seems probable that the physical types were invented to create a generalized language feature that would encompass the requirements for the representation of time. The physical types (with the exception of type time) have not proved very functional, and are seldom used in practical models. A physical type declaration defines a collection of "physical units". These are the "primary unit" for the type and any number of "secondary units", each a scaled multiple of a previously defined unit of the same type. Each value of a physical type is constrained to be an integral multiple of the primary unit for the type. The primary unit of type time is "fs". The position number corresponding to a (primary or secondary) physical unit is the number of primary units represented by the unit name. We deduce that the position number of "fs" is 1. The position number of a unit of type time is independent of the chosen "resolution limit". The "resolution limit" of type time is one of the units of type time. The resolution limit is "fs" by default, but a different unit can be chosen each time a model is executed. The implementation must choose a representation for type time that makes it possible to represent a single "resolution limit" unit exactly. We deduce that any integer multiple of the resolution limit unit can also be represented exactly. Values less than the resolution limit must be truncated to zero. The definition allows the implementation to "restrict the precision" of type time, but does not specify an algorithm. However, the only sensible choice is to truncate non-integer multiples of the resolution limit unit, just as values less than the resolution limit are required to be truncated. It is an error if a physical unit smaller than the resolution limit appears anywhere in the design. If a resolution limit unit is made to correspond to a low order bit of the stored representation then the available range of time is maximized. Note, however, that the variable resolution limit allows the shift of the radix point to the left, but not to the right; sub-femtosecond resolution in type time cannot be obtained by adjusting the resolution limit. A physical literal is a physical unit, optionally preceded by an integer or real literal. The physical literal represents that value of the physical type whose position number is the largest integer not greater than the product of the integer or real literal and the position number of the physical unit. This calculation always truncates the low order bits of the product. The multiplication and division operators on physical types are also defined in terms of computations on the corresponding position number. The function valued attribute Time'High is defined as the "upper bound" of the type Time. This upper bound cannot be the upper bound of the range constraint used in the declaration of type time. We must assume that the upper bound is the upper bound of the range constraint multiplied by the position number of the resolution limit unit. The impure function NOW returns a value of type time equal to Tc, as defined in section 12.6.4 on the simulation cycle. The following tables illustrate the resolution (in seconds) and approximate positive range limit (in appropriate units) for values of type time, assuming the indicated representations and choice of resolution limit unit. Two additional resolution limit units are illustrated as well that are not currently in the definition of type time, corresponding to attoseconds and thousands of attoseconds. base res range, 64 bit 2's comp range, 32 bit 2's comp ---- --- ---------------------- ---------------------- hr 3600 100 thousand u.l. 245 thousand years min 60 1,750 univ lifetimes 4 thousand years sec 1E+00 30 universe lifetimes 68 years ms 1E-03 300 million years 25 days us 1E-06 300 thousand years 36 minutes ns 1E-09 300 years 2 seconds ps 1E-12 3 years 2 milliseconds fs 1E-15 3 hours 2 microseconds (at) 1E-18 9 seconds 2 nanoseconds () 1E-21 9 milliseconds 2 picoseconds base res range,53 bit mag + 1 bit sign ---- --- ----------------------------- hr 3600 102 universe lifetimes min 60 2 universe lifetime sec 1E+00 286 million years ms 1E-03 286 thousand years us 1E-06 286 years ns 1E-09 104 days ps 1E-12 2.5 hours fs 1E-15 9 seconds (at) 1E-18 9 milliseconds () 1E-21 9 microseconds The 64 bit 2's complement representation is universal among current-day VHDL simulators. 32 bit 2's complement representation fits the minimum required by the definition, but the range limit at the typical time resolutions required by designers is too severe, even with the ability to change the resolution limit. The definition of the minimum range for type time is an obsolete artifact of the narrow CPU data paths and expensive memory of former days. The 53 bit magnitude plus sign limits are interesting because an IEEE double precision floating point representation has a 52 bit fraction (see below). 3. Representation of floating-point numbers in VHDL The required precision of the exponent and fraction of a value of the floating-point class is defined in the LRM in an indirect way. For the exponent, a range of values that must be representable is defined. For the fraction, a mandatory decimal precision is specified. The result is equivalent to saying that the exponent must have at least 8 and the fraction at least 20 binary digits of precision. An IEEE Std 754 single precision number has an 8 bit exponent and a 23 bit fraction, and so exceeds the requirement. Every analog simulator we know of uses a double precision representation for unknowns, presumably as a consequence of hard-won experience with the numerical problems presented by typical designs when a lower precision representation is used. Without further analysis or anecdote, we adopt the same approach. We will require a range of +-1E308, and a decimal precision of 14 digits for all floating-point types in a VHDL-A implementation. The IEEE Std 754 double precision representation, with 11 bit exponent and 52 bit fraction, just exceeds this requirement. If time is represented in seconds as a value of a floating-point type, the resolution is, as you would expect, dependent on the absolute value. Here is a table showing the resolution of an IEEE Std 754 double precision number over the portion of the range centered around 1 second: range low range hi resolution --------- -------- ---------- 0.0009766 0.0019531 2.168E-19 0.0019531 0.0039063 4.337E-19 0.0039063 0.0078125 8.674E-19 0.0078125 0.015625 1.735E-18 0.015625 0.03125 3.469E-18 0.03125 0.0625 6.939E-18 0.0625 0.125 1.388E-17 0.125 0.25 2.776E-17 0.25 0.5 5.551E-17 0.5 1 1.110E-16 1 2 2.220E-16 2 4 4.441E-16 4 8 8.882E-16 8 16 1.776E-15 16 32 3.553E-15 32 64 7.105E-15 64 128 1.421E-14 128 256 2.842E-14 256 512 5.684E-14 512 1024 1.137E-13 1024 2048 2.274E-13 The resolution drops below 1 fs after 8 seconds of elapsed time, and so the absolute precision of a 64 bit physical type time representation is greater after that amount of simulation time. For purposes of comparison, a range of 4.5 seconds at a resolution of 1 fs is achieved with a physical type representation of 52 bits of magnitude, and a range of 9 seconds with 53 bits. Despite the varying resolution this system works very well. The only place absolute time is used in analog simulators is in the abstract representation of source functions (e.g., sin(omega*T) ). All other times are maintained as values relative to the last established ASP. In effect, the last ASP is moved to zero, and all times are relative to that. Since steps are closely spaced in time, all times values are close to zero and the effective resolution is quite high. Those few resolution problems that arise in users' models are the result of ignoring the loss of resolution inherent in products like omega*T as T gets large. But most source functions are periodic, and the problem can be avoided by using, for example, T modulus 1/omega in place of T; that is, effectively resetting T to zero at the beginning of each period. (1/omega must be exactly representable in the chosen floating-point system for this to work perfectly). The minimum resolution is now a function of omega rather than a function of the length of the simulation run. Source functions with long periods tend to change fairly slowly, so a precise value of time is not necessary to get a precise value for the function value. Thus, the unavoidable loss in precision of absolute time as simulation time increases is easy to tolerate in practice. No decimal fraction of a second can be exactly represented in a floating point notation that interprets the exponent as a power of two, which is to say all modern floating-point representations. Since all process resumptions in a VHDL-1076 model are at times represented by decimal fractions of a second, the time of a process resumption cannot be exactly represented. We conclude that the implementation must pay careful attention to the rounding and truncation errors that will occur as time values are converted back and forth to floating-point values. 4. Time and the mixed-mode cycle A good solution will retain the high relative precision of time that has in the past proven itself in existing analog simulators while retaining the discrete time semantics of VHDL-1076 and its constant absolute resolution. The definition must be couched in terms of changes to the simulation cycle. We will treat the advance of time as continuous rather than step-wise. Events caused by the analog solver can occur at times that are not integral multiples of the resolution limit unit. It is helpful to think of these times as the sum of a value of type time and a floating-point offset less than a resolution limit unit. If the offset is non-zero, we say that such a time is an "offset time". Processes sensitive to crossing signals can execute at offset times. Other processes, not necessarily sensitive to crossing signals, may execute in the following series of delta cycles. All calculations performed in a process that implicitly reference the current time Tc use a value truncated to the nearest multiple of the resolution limit; the "current discrete time", which is also the value of the function NOW. If the result of the implicit calculation of an absolute time is less than the current time Tc, Tc is used instead. Thus, no event caused by a signal assignment with non-zero delay can occur at an offset time, and no resumption of a process consequent to a "wait for" with non-zero delay can occur at an offset time. Events caused by signal assignments with zero delay ("delta-delayed" assignments) occur at the current time, which may be an offset time. The same is true of the time that a process resumes as a consequence of a wait statement with a time-out of zero seconds. A process may therefore execute in one of a series of delta cycles at an offset time even if it is not itself sensitive to a crossing signal. In particular, a postponed process may execute in the last cycle of such a series. 4.1. The problem with VHDL time The idea that the current time is a value of physical type time seems to have been buried in the imaginations of the designers of VHDL, but it is never made explicit. In general, time is treated without sufficient formality. We must assume that all VHDL-1076-1993 events occur at times represented by integer multiples of the resolution limit. This is nowhere explicitly stated. It was probably intended to be a consequence of the way the "current time" is initialized and incremented, but those definitions are defective. The time values Tc and Tn, used in the simulation cycle, are never given a type, although various arithmetic operations are performed using them as operands. The function NOW is defined only by a comment in package standard. The time of execution of a process containing a given statement is variously referred to as "the current time", "the current simulation time" or "the current simulation time, Tc". For the attributes 'STABLE and 'QUIET, the time against which intervals are measured is not defined at all. The function valued attribute T'High is defined as the "upper bound" of the type T. The upper bound of a physical type is not defined. A new definition for time must overcome these obstacles while adding the appropriate extensions for VHDL-A. We have adopted what you might call a normative strategy; if the words in the LRM have been interpreted in one way by all the existing implementations and everyone seems to agree that nobody made a mistake, then that interpretation is assumed, even if the words aren't completely clear. In this way, we change as little as possible of the existing text and minimize possible confusion. 4.2. A plan for unifying time We define the times Tc and Tn to be of type universal_real and functions to convert between values of universal real and physical type time. This establishes the equivalence between the physical value 1 sec and the universal_real value 1.0. The functions make extensive use of type conversion; see LRM 7.3.5. function C(t: time) return universal_real is begin return universal_real(time'pos(t)) / universal_real (time'pos(sec)); end C; Function C specifies a unique universal_real value for each time. function D(u: universal_real) return time is begin return time'val(universal_integer( u*universal_real(time'pos(sec) ) ); end D; We interpret the rule of 3.1.3.1-234 to specify that the position number of the value of any expression of physical type time is truncated to an integer multiple of the position number of the resolution limit unit. The function D returns the time corresponding to the truncated position number. To put it more informally but more directly, the time that D returns is rounded down to a multiple of the resolution limit unit. The time will be the same for a range of values of universal_real; u=C(t) is the least value such that D(u)=t. The subprogram specifications (the interfaces) of these functions cannot be coded in VHDL because the universal types are anonymous; it is not possible to declare an object to be of a universal type. Moreover, the function C cannot be used in an expression, because function names are not in the defined class of convertible universal operands (7.3.5-530). We can, however, embed these conversion functions in the language by specifying that type time is "closely related" to any floating-point type. Then we can use the type conversion notation Time(r) to convert a floating-point value r of arbitrary type to a time, and conversely, F(t) to convert a time t to a given floating-point type F. The type conversions will be given semantics based on C and D, with proper attention paid to the finite precision of floating-point representation. Time(F(t)) will be equal to t for sufficiently small values of t (less than 8 sec for an IEEE double precision floating point representation, assuming a physical type representation with at least 53 bits and a fs resolution limit). F(Time(r)) = r above that limit. Specifically, *after 7.3.5-516 (type time and any floating-point type are closely related) c) Type Std.Standard.Time -- The predefined type Time is closely related to any floating-point type. In an explicit type conversion where the type mark denotes type Time the operand can be any floating-point type. Conversely, in an explicit type conversion where the type mark denotes any floating-point type the operand can be of type Time. The conversion of a value R of a floating-point type to a value of type Time is equivalent to the evaluation of the expression Time'val(universal_integer(universal_real(R) * Time'pos(sec)). The conversion of a value T of type Time to a value of a floating-point type F is equivalent to the evaluation of the expression F(universal_real(time'pos(T)) / universal_real (time'pos(sec)))+E, where E is the smallest non-negative value of type F such that Time(F(T))=T . *** We will say that the universal real u "corresponds to" or "is the time corresponding to" the value t of physical type time if and only if u is the least value such that Time(u)=t, or identically, universal_real(t)=u. Next, we define the function NOW to return Time(Tc) and the function ANOW to return Real(Tc). NOW truncates Tc to an integer multiple of the resolution limit unit. ANOW "rounds up" so that Time(ANOW)=NOW for sufficiently small absolute times; this is a consequence of the extended definition of type conversion. Finally, we make a series of minor adjustments to the way time is referenced: *12.6.4-633 (define the initial value of Tc to be a universal_real value) At the beginning of initialization, the current time, Tc, is assumed to be 0 ns. At the beginning of initialization, the current time, Tc, is assumed to be 0.0. *12.6.4-646 (clear up the comparison of Tn with TIME'HIGH) Simulation is complete when Tn=TIME'HIGH ... Simulation is complete when Time(Tn) =TIME'HIGH ... *12.6.4-655 (clear up the calculation of Tn in the simulation cycle) 1) TIME'HIGH 1) universal_real(TIME'HIGH) *14.2-829 (correct the comment in package Standard concerning function NOW) -- A function that returns the current simulation time, Tc (see 12.6.4): -- A function that returns Time(Tc) (see 12.6.4). *8.4.1-237 (use NOW in calculating the time of a transaction when interpreting a signal assignment statement) The time component of the transaction is determined by the current time added to the value of the time expression in the waveform element. The time component of the transaction is the greater of 1) the current time, and 2) the time corresponding to the sum of NOW and the value of the time expression in the waveform element. *8.1-71 (use the current discrete time as the base for calculating when a "wait for" will wake up) The suspended process will resume, at the latest, immediately after the timeout interval has expired. The suspended process will resume, at the latest, at the greater of 1) the current time, and 2)the time corresponding to the sum of NOW and the value of the timeout interval. *14.1-246 (Delete two of the three specifications of the result of S'DELAYED[(T)]) A signal equivalent to signal S delayed T units of time. The value of S'DELAYED(t) at time Tn is always equal to the value of S at Tn-t. Specifically: [delete] *14.1-263 (Correct the description of the result of S'STABLE[(T)]) A signal that has the value TRUE when an event has not occurred on signal S for T units of time, and the value FALSE otherwise (See 12.6.2). A signal that has the value TRUE when the time of the last event on S is less than the time corresponding to NOW-T, and the value FALSE otherwise (See 12.6.2). *14.1-273 (Correct the description of the result of S'QUIET[(T)]) A signal that has the value TRUE when the signal has been quiet for T units of time, and the value FALSE otherwise (See 12.6.2). A signal that has the value TRUE when the time of the last transaction on S is less than the time corresponding to NOW-T, and the value FALSE otherwise (See 12.6.2). 4.3 Implementation considerations The time associated with a transaction is of type universal_real according to the scheme outlined above. The common practice among existing implementations is to use the stored representation of physical type Time to represent the time aspect of a transaction. But by definition the time of every transaction with a time aspect that is different from the current time is an integer multiple of the time represented by one resolution limit unit. Each such value of universal_real can be represented as a value of type Time for sufficiently small times. Thus, no change in the representation of transactions used by existing simulators is necessary. The implementation of F(t) cannot naively use the integer to floating-point conversion instruction of the hardware underlying the implementation. If that conversion yields a result such that Time(F(t)) /= t, then the value will need to be adjusted upwards. The equivalence Time(F(t))=t cannot be maintained for any finite precision representation of values of type F if t becomes large. We will want to provide the following constraint on the implementation-defined value Time'High; that for all t<=Time'High, Time(F(t))=t. In that case Time'High would be less than the value that would naturally fall out of a 2**N byte integer representation for type Time; for example, 2**63-1 for a 64 bit signed integer. For an IEEE double precision floating-point representation Time'High would be about Time'pos((2**53)*res_limit). Examination of the tables in section 1 will show that the resulting range of time is adequate for most applications even with a resolution limit of fs. Other resolution limit units yield correspondingly greater ranges. From 1076-1-request@sicmail.epfl.ch Tue Jun 20 04:59:56 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Tue, 20 Jun 95 04:59:52 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Tue, 20 Jun 95 04:59:46 -0400 X400-Received: by mta sicmail.epfl.ch in /PRMD=switch/ADMD=arCom/C=ch/; Relayed; Tue, 20 Jun 1995 10:27:38 +0200 Date: Tue, 20 Jun 1995 10:27:38 +0200 X400-Originator: 1076-1-request@sicmail.epfl.ch X400-Recipients: non-disclosure:; X400-Mts-Identifier: [/PRMD=switch/ADMD=arCom/C=ch/;sicmail.ep.389:20.05.95.08.27.38] Priority: Non-Urgent Dl-Expansion-History: 1076-1@epfl.ch ; Tue, 20 Jun 1995 10:27:37 +0200; From: "Jean-michel.Berge" Message-Id: To: "(E-Mail USER)" Cc: analog_reflector <1076-1@epfl.ch> Subject: RE: Analog VHDL Information request X-Mailer: Mail*Link SMTP/MS 3.0.0 Francois, Two weeks ago, I post this (see below) to the reflector... This is true for everybody and also concern information about commercial product... Please, read it again and stop using this reflector to promote proprietary tools. I especially have a problem with your post-scriptum: "P.S. : At the moment, the 1076.1 LRM is not already available, but we have some other usefull documentation package." Which can only create confusion. We are currently providing all "official" information requested on 1076.1 through our secretary, Mr Alain Vachoux, and our ftps servers. Your "usefull documentation package" has probably nothing to do with this information and, (I may be wrong but...) only concern proprietary tools... Thanks, Jean-Michel Berge Chair of 1076.1 **************************************************************************** On this reflector, we have between 200 and 300 Working group members. Although everybody is working in the same direction (having a high quality standard as soon as possible), competitors are present and work together. This is especially true for tool vendors. It is therefore obvious that discussions about tool capabilities can very quickly degenerate in a big mess. One of the aspects of my role is to avoid this. ... But we can discipline ourself... ... From 1076-1-request@sicmail.epfl.ch Wed Jun 21 00:25:32 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Wed, 21 Jun 95 00:24:00 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Wed, 21 Jun 95 00:23:56 -0400 Received: from mailgate.Cadence.COM by sicmail.epfl.ch with SMTP (PP) id <01066-0@sicmail.epfl.ch>; Wed, 21 Jun 1995 06:18:45 +0200 Received: (from smap@localhost) by mailgate.Cadence.COM (8.6.8/8.6.8) id VAA00527 for <1076-1@epfl.ch>; Tue, 20 Jun 1995 21:18:42 -0700 From: VhdlCohen@aol.com Received: from cds2072.cadence.com(158.140.24.54) by mailgate.cadence.com via smap (V1.0mjr) id sma000517; Tue Jun 20 21:18:26 1995 Received: from mailgate.Cadence.COM (mailgate.cadence.com [158.140.2.1]) by cds2072.Cadence.COM (8.6.8/8.6.8) with ESMTP id VAA13732 for ; Tue, 20 Jun 1995 21:18:24 -0700 Received: (from smap@localhost) by mailgate.Cadence.COM (8.6.8/8.6.8) id VAA00512 for ; Tue, 20 Jun 1995 21:18:22 -0700 Received: from vhdl.vhdl.org(198.31.14.3) by mailgate.cadence.com via smap (V1.0mjr) id sma000495; Tue Jun 20 21:18:12 1995 Received: from mail04.mail.aol.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA08610; Tue, 20 Jun 95 20:53:18 PDT Received: by mail04.mail.aol.com (1.37.109.11/16.2) id AA090476423; Tue, 20 Jun 1995 23:47:03 -0400 Date: Tue, 20 Jun 1995 23:47:03 -0400 Message-Id: <950620234336_99068088@aol.com> To: math@vhdl.org Subject: Book Announcement: "VHDL Coding Styles and Methodologies" VHDL Coding Styles and Methodologies by Ben Cohen VHDL Coding Styles and Methodologies provides an in-depth study of the VHDL language rules, coding styles, and methodologies. This book clearly distinguishes good from poor coding methodologies using an easy to remember symbology notation along with a rationale for each guideline. The VHDL concepts, rules and styles are demonstrated using complete compilable and simulatable examples which are also supplied on the accompanying disk. VHDL Coding Styles and Methodologies provides practical applications of VHDL and techniques that are current in the industry. It explains how to apply the VHDL guidelines using several complete examples. The 'learning by example' teaching approach along with an in-depth presentation of the language rules application methodology provides the necessary knowledge to create digital hardware designs and models that are readable, maintainable, predictable, and efficient. VHDL Coding Styles and Methodologies is intended for both college students and design engineers. It provides a practical approach to learning VHDL. Combining methodologies and coding styles along with VHDL rules leads the reader in the rights direction from the beginning. Contents: Preface. About the Disk. Notation Conventions. 1. VHDL Overview and Concepts. 2. Basic Language Elements. 3. Control Structures. 4. Drivers. 5. VHDL Timing. 6. Elements of Entity/Architecture. 7. Subprograms. 8. Packages. 9. User Defined Attributes, Specifications, and Configurations. 10. Functional Models and Testbenches. 11. UART Project. 12. Vital. 13. Design for Synthesis. Appendix A: VHDL'93 and VHDL'87 Syntax Summary. Appendix B: Package Standard. Appendix C: Package Textio. Appendix D: Package STD_Logic_1164. Appendix E: VHDL Predefined Attributes. Kluwer Academic Publishers, Boston Date of publishing: July 1995 392 pp. Hardbound ISBN: 0-7923-9598-0 Prices: NLG: 160.00 USD: 94.00 GBP: 63.95 ================================================================= Author: Ben Cohen Title: VHDL Coding Styles and Methodologies ( ) Hardbound / ISBN: 0-7923-9598-0 NLG: 160.00 USD: 94.00 GBP: 63.95 Ref: KAPIS ( ) Payment enclosed to the amount of _____________________ ( ) Please send invoice ( ) Please charge my credit card account: Card no.: |_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_| Expiry date: ________ () Access () American Express () Mastercard () Diners Club () Eurocard () Visa Name of Card holder: __________________________________________ Delivery address: Title : _____________________ Initials: ____________M/F______ First name : ________________ Surname: ________________________ Organization: _____________________________________________________ Department : _____________________________________________________ Address : _____________________________________________________ Postal Code : ___________________ City: ___________________________ Country : _______________________Telephone: ________________ Email : _______________________________________________ Date : _______________ Signature: _______________________ Our European VAT registration number is: |_|_|_|_|_|_|_|_|_|_|_|_|_|_| To be sent to: For customers in Mexico, USA and Canada: Rest of the world: Kluwer Academic Publishers Kluwer Academic Publishers Group Order Department Order Department P.O. Box 358 P.O. Box 322 Accord Station 3300 AH Dordrecht Hingham, MA 02018-0358 The Netherlands U.S.A. Tel : 617 871 6600 Tel : +31 78 524400 Fax : 617 871 6528 Fax : +31 78 524474 Email : kluwer@world.std.com Email : services@wkap.nl Payment will be accepted in any convertible currency. Please check the rate of exchange with your bank. Prices are subject to change without notice. All prices are exclusive of Value Added Tax (VAT). Customers in the Netherlands please add 6% VAT. Customers from other countries in the European Community: * please fill in the VAT number of your institute/company in the appropriate space on the orderform: or * please add 6% VAT to the total order amount (customers from the U.K. are not charged VAT). ================================================================= ============================================================================== = Ben Cohen is the author of "VHDL Coding Styles and Methodologies ... an In-Depth Tutorial" (ISBN 0-7923-9598-0) to be published in July 95 by Kluwer Academic -- Publishers. (see gopher://gopher.wkap.nl for more information, or write to kluwer@world.std.com). (Book was written as an independent project to help teach VHDL) Hughes Aircraft Co, RE- R1/B507 2000 East Imperial Hwy El Segundo, Ca, 90245 (310) 334-7389, fax: (310) 334-1749 ====================================================================== From 1076-1-request@sicmail.epfl.ch Thu Jun 22 19:31:34 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Thu, 22 Jun 95 19:31:32 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Thu, 22 Jun 95 19:31:28 -0400 Received: from tiny.sprintlink.net by sicmail.epfl.ch with SMTP (PP) id <03579-0@sicmail.epfl.ch>; Fri, 23 Jun 1995 01:02:16 +0200 Received: from analogy.com (analogy.analogy.com [149.117.1.1]) by tiny.sprintlink.net (8.6.9/8.6.9) with SMTP id SAA03833 for <1076-1@epfl.ch>; Thu, 22 Jun 1995 18:58:30 -0400 Received: from miller.analogy.com by analogy.com (4.1/Shared_Spool_1.3) id AA14049; Thu, 22 Jun 95 16:03:23 PDT Received: from satyr.analogy.com by miller.analogy.com (4.1/SMI-3.2) id AA04353; Thu, 22 Jun 95 16:03:23 PDT Received: by satyr.analogy.com (5.0/SMI-SVR4) id AA14407; Thu, 22 Jun 1995 16:03:22 -0700 Date: Thu, 22 Jun 1995 16:03:22 -0700 From: christen@analogy.com (Ernst Christen) Message-Id: <9506222303.AA14407@satyr.analogy.com> To: 1076-1@epfl.ch Subject: LAT Meeting Summary Content-Length: 4625 The 7th meeting of the 1076.1 Language Architecture Team was held on June 12, 13, 15, and 16 in San Francisco, in parallel with DAC. This is a brief summary of the meeting, detailed minutes will follow. The meeting was attended by 13 people. The agenda included the discussion of a critique of previous LAT work, two proposals with alternative forms for representing branches and equations, a white paper on the unification of time, presentations of drafts of several white papers, and updates on the progress on some other work. The meeting started with the announcement that the Language Design Committee has been consolidated by merging the LAT and the LES groups into the Language Design Team. This reorganization was approved by a vote among all WG members who participated in LAT meetings and in LES groups. This organizational issue was followed by a critique of the LAT work. Five points were raised. One issue was resolved immediately, one resulted in an action item, two were put on hold until a definition of the simultaneous procedural statement is available, and one was used by the author as the basis for his alternative proposal. The first alternative proposal is in many respects closer to the LESs than the LAT work. It is based on contributions to nodes, and there are no explicit branch declarations. Rather, a new form of a selected name mechanism is used, consisting of two terminals and an identifier from the nature (which is a type in this proposal). We agreed that the issue addressed by the analog type in the proposal can be postponed until we deal with support for frequency domain. We also identified major problems using selected names to identify through or across branches, particularly when the natures are composite. The second alternative proposal includes explicit branch declarations, but it suffers from the same problem with selected names as the first one. A possible solution for this problem could be the declaration of the branch quantities. The proposal also includes an equation formulation method that is based on generalized controlled sources; in fact all continuous behavior is specified by controlled sources. It was demonstrated that this formalism has the same expressive power as the simultaneous statements proposed in the LAT work. Neither of these two proposals is as far advanced as the work described in the Quantities and Simultaneous Statements papers. However, some ideas are interesting, and the LAT agreed on a process to resolve the question how branches should be represented. One of the central pieces of the analog extensions to VHDL is a unification of the semantics of time. In VHDL'93 time is represented as an integer multiple of 1 fs, while in continuous simulation time is best represented as a floating point number. We discussed a paper that defines a unification of these two models of time and that is backward compatible with VHDL'93. The paper was provisionally approved, and it has been sent to the reflector earlier this week. As part of the discussion on Relations and Simultaneous Statements it was observed that the relation as proposed duplicates functionality that already exists with blocks. As a consequence the decision was made to abandon the relation and define a procedural simultaneous statement with semantics as outlined during the discussion. Further discussions included the Predefined Language Environment, SPICE issues and Statistical Modeling, the last two being presented for the first time. There are several unresolved issues around extending package STD.Standard or creating a new package, e.g. ASTD.Standard. We re-emphasized the point that the 1076.1 effort will not define application specific packages (e.g. we will not standardize a SPICE package). Part of the paper on Statistical Modeling is based on an incorrect understanding of static expressions; this part must be reworked. Finslly, updates were given on Solvability, Initialization and DC, Quantities and Mixed-Mode Simulation. Progress was made in all areas, but much work is still required to include the results of the theoretical studies on initialization in the VHDL-A language definition. To summarize, we made considerable progress at this meeting: One more paper provisionally approved, one issue resolved, and agreement on a process to resolve another. On behalf of the 1076.1 Working Group I would like to thank all attendees for their contributions, both before and during the meeting. Special thanks go to Mentor Graphics and Cadence Design Systems for providing the meeting facilities. Ernst Christen Chair LAT From 1076-1-request@sicmail.epfl.ch Fri Jun 23 05:18:22 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Fri, 23 Jun 95 05:18:14 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Fri, 23 Jun 95 05:17:18 -0400 Received: from c3imac12.epfl.ch by sicmail.epfl.ch with SMTP (PP) id <13900-0@sicmail.epfl.ch>; Fri, 23 Jun 1995 10:44:41 +0200 X-Sender: vachoux@c3i9.epfl.ch Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 23 Jun 1995 10:46:17 +0100 To: 1076-1@epfl.ch From: alain.vachoux@leg.de.epfl.ch (Alain Vachoux EPFL-LEG/C3i) Subject: Minutes WG meeting of June 17 Minutes of IEEE VHDL 1076.1 working group IEEE CS DASC working group meetings, June 17, 1995 Mentor Graphics, San Jose, CA Submitted by Alain Vachoux Reviewed by Jean-Michel Berge and Ernst Christen Attendees (30): Kenneth Bakalar kenb@compass-da.com Jim Barby jabarby@uwaterloo.ca Dave Barton dlb@hudson.wash.inmet.com William Bell wrbell@ingr.com Jean-Michel Berge berge@cns.cnet.fr Jean-Jacques Charlot charlot@elec.enst.fr Bob Collins rcollins@mtl.com Ernst Christen christen@analogy.com Dan Damon dan_damon@mentorg.com Steven Drager dragers@rl.af.mil Hazem El Tahawy hazem@anacad.fr Oliver Fischer-Binder olli@anacad.de Serge Garcia-Sabiro serge@anacad.fr Paul Grojean pmg@srsdcst0.sr.hp.com Jim Hanna hanna@rl.af.mil Robert Hillman hillman@rl.af.mil Tokimori Kozawa kozawa@crl.hitachi.co.jp Lewis Matthew mlewis@mamacass.sp.trw.com Joannis Papanuskas joannis@dic.k8.rt.bosch.de Bill Paulsen Greg Peterson gdp@el.wpafb.af.mil Steffen Rochel steffen@anacad.de Jacques Rouillard rouillard@acm.org C.-J. Richard Shi cjshi@eng.uiowa.edu Chuck Swart cswart@analogy.com Ken Simone ksimone@mtl.com David Smith dws@analogy.com David Thornhill david_thornhill@gmail4.sp.trw.com Richard Trihy trihy@cadence.com Alain Vachoux vachoux@leg.de.epfl.ch Agenda: General information (Jean-Michel Berge) - DOD 2.1 ballot, San Diego resolution - IEEE copyright issue - ABCD Language design committee report - Progress report (Ernst Christen) - VHDL-A architecture (Ernst Christen) - White paper on time (Ken Bakalar) Validation committee report (Oliver Fischer-Binder) Miscellaneous - VHDL-A repository on WWW (Alain Vachoux) VHDL-A examples (Ken Bakalar, Ernst Christen) The meeting started at 8.30am and finished at 4pm. A postscript version of the slides presented during the meeting are available in the 1076.1 ftp archive site in the directory: pub/vhdl/standards/ieee/1076.1/wg_meetings/DASC_jun95 1. General information (Jean-Michel Berge) 1.1. DOD 2.1 ballot, San Diego resolution The ballot on the Design Objective Document (DOD) version 2.1 closed on May 19. 25 people voted, of which 2 were not registered as voting members the time the vote started. 17 people approved the DOD 2.1, 8 did not. Since our policies require a quorum of 50% of the voting members (87 when the vote started), the vote has to be done again. Since several comments have been made on version 2.1 (stronger support of small-signal AC and noise analyses, some misspellings or badly formulated sentences), a new version 2.2 that accomodates for these comments wil be submitted for the new vote. After the DOD has been approved, the resolution adopted in the last DASC meeting in San Diego (slightly modified to account for a change in the internal structure of the language design committee): "The validation and the documentation teams will use the White Papers approved (provisionaly or finally) by the LDC as a base for their work." will be submitted to another vote. Question from the audience: Q: Will DOD 2.2 define a new scope for the support of frequency-domain applications? A: No, it won't. The DO related to small-signal frequency analysis will be upgraded from a "should" to a "must". 1.2. IEEE copyright issue IEEE decided to introduce a copyright on the standard packages that won't make them anymore free of charge. The current copyright text specifies that package files can only be copied between "licensed users" and that these packages may not be included with software that is sold without a license from the IEEE. This may become a problem for our standardization process, since different packages will be developped in it. The discussion is currently running between IEEE and DASC and a tradeoff is always posible. Jean-Michel will follow the evolution of this discussion. 1.3. ABCD ABCD is a C-based API for SPICE-like simulators aimed at the description and the simulation of electrical circuits. It is based on XSPICE from Georgia Tech. A description of the ABCD effort will be made available to the working group as soon as possible. The first step is to figure out how the 1076.1 and the ABCD efforts stand relatively to each other. Jean-Michel provided the ABCD group with the draft version of the white paper on SPICE issues. The ABCD group is seeking a way to standardization through IEEE or ECSI (European CAD Standardization Initiative). Comment from the audience: C: Providing a draft version of an unapproved white paper outside the LDC broke the LDC document policy. A: Jean-Michel agreed that it was probably a mistake although he made verbal statement about the unapproved status of this working document. Jean-Michel will send the same written statement to ABCD representative to reinforce this. 2. Language design committee report 2.1. Progress report (Ernst Christen) [A postscript version of the slides presented here is available in the file ldcstatus_slides.ps] After a recap of the language design tasks, the language design guidelines and the LDC process, Ernst announced an internal reorganization of the language design committee. The four LES groups and the LAT, which were under the umbrella of the language design committee, are no longer existing as such. Only a single language design committee remains. People involved in the LES groups and in the LAT also remain in the LDC. This decision was approved after a poll of all people (27) that have been involved in the LES groups and the LAT. There were 7 YES, 2 NO, and 18 ABSTAIN or no response. Since the rule was that an abstention count as a YES, the poll carried. Regarding the work progress, 75% of the 16 identified major architecture pieces have been studied under the form of a first draft white paper. 50% have already been discussed by the LDC, and 20% are provisonally approved. A new white paper on a unified model of time has been discussed and provisionally approved during the LDC meeting that was held the same week. Two white papers (statistical modelling and SPICE issues) were discussed for the first time. The two white papers on simultaneous statements and on relations collapsed, the relation being replaced by a simultaneous procedural statement. A review of the LDC from Serge Garcia-Sabiro and an alternative proposal from Richard Trihy brought up a discussion on the way quantities and equations should be used. The LDC meeting members agreed on a decision process to resolve the issues. A more complete report of the last LDC meeting will be sent separately to the reflector. A first set of provisionally approved white papers was sent to the reflector soon after the last San Diego meeting. Several threads of discussion then started on the reflector. This material has also been exposed to ISAC and several other presentations (EDTC and VIUF tutorials, AVI board, VIUF mini-workshop). The next LDC meeting is planned during EuroDAC/EuroVHDL in September in Brighton, UK. 2.2. VHDL-A architecture (Ernst Christen) [A postscript version of the slides presented here is available in the file langarch_slides.ps, they are identical to the slides presented at the previous WG meeting] Ernst presented first the foundations of the language, namely the mathematics of differential algebraic equations (DAEs). Then, he presented the major architectural pieces, namely the quantities, the modeling of conservative systems, the simultaneous statements, the mixed-mode simulation cycle, the initialization and DC simulation, the solvability of DAEs, aand the frequency domain support. Open issues still exist for the math package (IEEE 1076.2, soon to be balloted), dimensional analysis, statistical modeling, algorithm band-aids, tolerances, display of analog simulation points, and the support of SPICE concepts. Ernst concluded that much progress has been done, yielding a solid language architecture, although there are still missing pieces. Question from the audience: Q: Do DAEs, as considered here, deal with ordinary differential equations (ODEs) only? A: Yes they do. 2.3. White paper on time (Ken Bakalar) Ken presented a new white paper on a unified model of time for the mixed-mode simulation cycle in VHDL-A. The WP will be made available to the reflector by week #25. Ken highlighted the loose definition of time in the 1076-1993 LRM. Since everybody seems to agree on the same interpretation of time in current implementations, Ken proposed to change as little as possible to the existing text. The unified model is based on an ideal floating point system with time values observable in either type Time or a floating point type. The ideal floating point system is not part of the definition, as functions are defined to convert between floating-point and physical time values with the equivalence 1 sec of physical time (PT) = 1.0 floating-point time (FPT). Investigations on current integer based representations of PT and possible floating-point based representations of FPT showed that the IEEE Std 754 double precision representation fits the requirement for analog simulation accuracy. Since the minimum resolution limit is currently 1 fs of PT, a maximum absolute value of 8 sec of FPT guarantees a correct synchronization between both times. Note that absolute values of time are almost never used in analog simulators since time is expressed relative to the time the last analog solution point (ASP) has been computed. An offset time is defined as a floating-point value less than the resolution limit unit. A process sensitive to crossing signals may executes at offset times. Other processes may also execute at offset times in the following series of delta cycles. Ken then proposed a series of changes to do in the 1076-1993 LRM to account for the new model of time. He noticed that the proposal would impose that Time'HIGH returns a lower value than current implementations would allow, i.e. about 9 sec (53 bit range) vs. 3 hrs (64 bit range), respectively, with a resolution limit of 1 fs. Also, a new standard function ANOW is introduced to return the current FPT. Main comments/questions from the audience: Q: Does a "wait for 0 ns" result in a "wait for 1 fs" with this proposal? A: No, it does not. The (physical) time of the transaction is always truncated to the nearest multiple of the resolution limit, resulting here in a new delta delay. C: A new "at" physical time unit (resolution of 1.0e-18) will cause portability problems as Time'POS will return different results. Q: Does the proposal make use of objects of type universal real or universal integer in the description? A: No, it does not. Types universal real and universal integer represent ideal infinite precision numbers and they are only used for definitions in the 1076-1993 LRM. Calculations always use finite precision floating-point values. C: The concept of resolution limit is loosely defined in the 1076-1993 LRM. From the digital side, removing resolution limit won't change anything for simulation. Setting the resolution limit is however useful to modify Time'HIGH. Q: Need clarifications on process activation at an offset time. A: After postponed processes execute, time Tc changes, but function NOW still returns the old truncated PT value. Function ANOW advances, however. Q: What happens if several processes sensitive to 'CROSS signals are activated within a 1 fs resolution? A: No truncation to the nearest multiple of 1 fs does occur. A: Processes sensitive to different 'CROSS signals all resume at offset times. Since the current time advances they are executed in the proper sequence. This mechanism is required to handle discontinuities from the analog side correctly (break statement). Q: Did you consider the possibility of defining 1.0 FPT equal to 1 fs? A: Time constants in electrical networks are often defined as RC products. It would be virtually impossible to define the scaling required to make this idea work in the LRM. 3. Validation committee report (Oliver Fischer-Binder) [A postscript version of the slides presented here is available in the file valid_slides.ps] Since a first package of provisonally approved white papers is now available, the validation task may start. Oliver presented an evaluation of the modeling style implied by these WPs. He highlighted three issues: 1) To force the user to declare quantities that are not used in the description. 2) To disallow the declaration of more quantities than constraints. 3) To disallow access to through quantities of terminals from outside a component. This would prevent re-use of library components. Oliver also presented an example of a mixer to illustrate issue #1. Main comments/questions from the audience: C (on issue #1): All declared quantities are used. Those that do not appear explicitly in the description have a value: they are solved for and may be displayed. C (on issue #2): The approach is consistent as it intends to allow static and dynamic solvability checks. C (on issue #3): This kind of access is not possible due to existing VHDL visibility rules. A review of Analogy's component library did not show places where this is used. Anacad's end users do however ask for this capability. From the usage perspective, it is useful to develop testbenches that probe or display quantities. A solution for this kind of use was already proposed to the LDC and will be submitted to the end users. C: Jean-Michel fully disapproved the way the validation work has been presented. This work should be based on examples of use rather than on language details. It should not give solutions, but rather indicate/find problems. Indication of problems may imply the presentation of pieces of code. These problems have to be submitted to the language design committee. Oliver agreed. Two new persons joined the validation team: Jean-Jacques Charlot and Joannis Papanuskas. 4. VHDL-A repository on WWW (Alain Vachoux) Alain recalled that the 1076.1 master ftp archive was reorganized in early 1995. He then proposed to set up a WWW server that would allow for easier access to information, thanks to the use of hypertext links. For instance, the VHDL-A language architecture document may contain links to white papers. Also, a page may list available VHDL-A examples with links where they actually reside. Dave Smith proposed to develop the home page. He will also make the URL available to VI. 5. VHDL-A examples (Ken Bakalar, Ernst Christen) Ken presented several examples of VHDL-A models from the provisionally approved white papers on quantities/terminals (QT) and on mixed-mode simulation cycle (MMSC). Main comments/questions from the audience: C (on the opamp model in QT): Architecture "one" wastes one entry in the system matrix. A: An implementation is free to optimize the description by compacting the equations to be solved simultaneously. Q (on the diode model in QT): How does the solvability check proceed in this case? A: 1) # of through quantity declarations = 2, 2) # of free quantity declaration = 1, 3) # of interface quantities = 1, yielding 4 unknowns. Since there are 4 equations, everything is OK. Note that this is a necessary, but not sufficient, solvability condition. C (on the diode model in QT): Mode "out" is missing in the interface quantity declaration. Note that mode carries the same association semantics as for interface signals. However, it does not imply the same writing mechanism as for unresolved signals. C (on the ampli model in MMSC): The IF...USE statements do not introduce discontinuities on quantities, although they do on Q'dot. However, since Q'dot is not explicitly used in the description, this is not a problem of solvability. C (on slipper in MMSC): It is implicitly assumed that stick > slip. Should be asserted in the description. Q (on slipper in MMSC): Why break on an event on signal "stopped" rather than on quantity "velocity"? A: Signal "stopped" catches more than the fact that velocity goes to zero. Moreover, the cross-over condition on velocity does not introduce any discontinuity. C: Solvability checks may not be necessary a priori, but only to indicate the probable cause of the problem when a numerical computation fails. C: As far as the language goes, any description that exhibits discontinuites but miss break statements is considered as erroneous. This means that the simulation results are unpredictable. It is moreover impossible to come up with necessary and sufficient conditions in the language that detect all possible discontinuities in the description. Ernst then presented a few examples centered around a PLL description that were part of a VIUF tutorial in April and of a DAC tutorial on June 16. The full set of examples from these tutorials will be made available in the ftp repository. 6. Summary of action items What Who Comment ABCD statement Jean-Michel ASAP DOD 2.2 vote Alain To start by week #25 WWW server ASAP White papers on time to Ernst By week #25 the reflector Tutorial examples in ftp rep. ASAP WWW server home page Dave ASAP 7. Next working group meeting The date of the next WG meeting is not yet fixed. Possible dates are during EuroDAC/EuroVHDL'95 in Brighton, UK, September 18-22, or during the Fall'95 VIUF Conference in Boston, MA, October 1-4. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Alain Vachoux Swiss Federal Institute of Technology (EPFL) Dept. of Electrical Engineering Integrated Systems Center (C3i) e-mail: alain.vachoux@leg.de.epfl.ch EL-Ecublens Phone: (+41) 21 693 69 84 CH-1015 Lausanne, Switzerland Fax: (+41) 21 693 46 63 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From 1076-1-request@sicmail.epfl.ch Fri Jun 23 11:02:05 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Fri, 23 Jun 95 11:01:38 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Fri, 23 Jun 95 11:01:28 -0400 Received: from mailgate.Cadence.COM by sicmail.epfl.ch with SMTP (PP) id <00888-0@sicmail.epfl.ch>; Wed, 21 Jun 1995 05:49:46 +0200 Received: (from smap@localhost) by mailgate.Cadence.COM (8.6.8/8.6.8) id UAA29016 for <1076-1@epfl.ch>; Tue, 20 Jun 1995 20:49:43 -0700 From: VhdlCohen@aol.com Received: from cds2072.cadence.com(158.140.24.54) by mailgate.cadence.com via smap (V1.0mjr) id sma029003; Tue Jun 20 20:49:33 1995 Received: from mailgate.Cadence.COM (mailgate.cadence.com [158.140.2.1]) by cds2072.Cadence.COM (8.6.8/8.6.8) with ESMTP id UAA13700 for ; Tue, 20 Jun 1995 20:49:23 -0700 Received: (from smap@localhost) by mailgate.Cadence.COM (8.6.8/8.6.8) id UAA28996; Tue, 20 Jun 1995 20:49:21 -0700 Received: from mail02.mail.aol.com(152.163.172.66) by mailgate.cadence.com via smap (V1.0mjr) id sma028990; Tue Jun 20 20:49:17 1995 Received: by mail02.mail.aol.com (1.37.109.11/16.2) id AA023226234; Tue, 20 Jun 1995 23:43:54 -0400 Date: Tue, 20 Jun 1995 23:43:54 -0400 Message-Id: <950620234352_99068218@aol.com> To: ahdl1076@cds2072.Cadence.COM, jose@synopsys.com, azamfire@edaca.ingr.com, ecker@nixe.zfe.siemens.de, gabe@dazixca.ingr.com, berman@cds2072.Cadence.COM, ses@asd470.dseg.ti.com, ehuy@sh.alcbel.be, ah@zfe.siemens.de, 544-6089@mcimail.com, p24742@email.mot.com, duzy@zfe.siemens.de, robin@aol.com Subject: Book Announcement: "VHDL Coding Styles and Methodologies" VHDL Coding Styles and Methodologies by Ben Cohen VHDL Coding Styles and Methodologies provides an in-depth study of the VHDL language rules, coding styles, and methodologies. This book clearly distinguishes good from poor coding methodologies using an easy to remember symbology notation along with a rationale for each guideline. The VHDL concepts, rules and styles are demonstrated using complete compilable and simulatable examples which are also supplied on the accompanying disk. VHDL Coding Styles and Methodologies provides practical applications of VHDL and techniques that are current in the industry. It explains how to apply the VHDL guidelines using several complete examples. The 'learning by example' teaching approach along with an in-depth presentation of the language rules application methodology provides the necessary knowledge to create digital hardware designs and models that are readable, maintainable, predictable, and efficient. VHDL Coding Styles and Methodologies is intended for both college students and design engineers. It provides a practical approach to learning VHDL. Combining methodologies and coding styles along with VHDL rules leads the reader in the rights direction from the beginning. Contents: Preface. About the Disk. Notation Conventions. 1. VHDL Overview and Concepts. 2. Basic Language Elements. 3. Control Structures. 4. Drivers. 5. VHDL Timing. 6. Elements of Entity/Architecture. 7. Subprograms. 8. Packages. 9. User Defined Attributes, Specifications, and Configurations. 10. Functional Models and Testbenches. 11. UART Project. 12. Vital. 13. Design for Synthesis. Appendix A: VHDL'93 and VHDL'87 Syntax Summary. Appendix B: Package Standard. Appendix C: Package Textio. Appendix D: Package STD_Logic_1164. Appendix E: VHDL Predefined Attributes. Kluwer Academic Publishers, Boston Date of publishing: July 1995 392 pp. Hardbound ISBN: 0-7923-9598-0 Prices: NLG: 160.00 USD: 94.00 GBP: 63.95 ================================================================= Author: Ben Cohen Title: VHDL Coding Styles and Methodologies ( ) Hardbound / ISBN: 0-7923-9598-0 NLG: 160.00 USD: 94.00 GBP: 63.95 Ref: KAPIS ( ) Payment enclosed to the amount of _____________________ ( ) Please send invoice ( ) Please charge my credit card account: Card no.: |_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_| Expiry date: ________ () Access () American Express () Mastercard () Diners Club () Eurocard () Visa Name of Card holder: __________________________________________ Delivery address: Title : _____________________ Initials: ____________M/F______ First name : ________________ Surname: ________________________ Organization: _____________________________________________________ Department : _____________________________________________________ Address : _____________________________________________________ Postal Code : ___________________ City: ___________________________ Country : _______________________Telephone: ________________ Email : _______________________________________________ Date : _______________ Signature: _______________________ Our European VAT registration number is: |_|_|_|_|_|_|_|_|_|_|_|_|_|_| To be sent to: For customers in Mexico, USA and Canada: Rest of the world: Kluwer Academic Publishers Kluwer Academic Publishers Group Order Department Order Department P.O. Box 358 P.O. Box 322 Accord Station 3300 AH Dordrecht Hingham, MA 02018-0358 The Netherlands U.S.A. Tel : 617 871 6600 Tel : +31 78 524400 Fax : 617 871 6528 Fax : +31 78 524474 Email : kluwer@world.std.com Email : services@wkap.nl Payment will be accepted in any convertible currency. Please check the rate of exchange with your bank. Prices are subject to change without notice. All prices are exclusive of Value Added Tax (VAT). Customers in the Netherlands please add 6% VAT. Customers from other countries in the European Community: * please fill in the VAT number of your institute/company in the appropriate space on the orderform: or * please add 6% VAT to the total order amount (customers from the U.K. are not charged VAT). ================================================================= ============================================================================== = Ben Cohen is the author of "VHDL Coding Styles and Methodologies ... an In-Depth Tutorial" (ISBN 0-7923-9598-0) to be published in July 95 by Kluwer Academic -- Publishers. (see gopher://gopher.wkap.nl for more information, or write to kluwer@world.std.com). (Book was written as an independent project to help teach VHDL) Hughes Aircraft Co, RE- R1/B507 2000 East Imperial Hwy El Segundo, Ca, 90245 (310) 334-7389, fax: (310) 334-1749 ====================================================================== From 1076-1-request@sicmail.epfl.ch Wed Jun 28 17:49:38 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Wed, 28 Jun 95 17:49:36 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Wed, 28 Jun 95 17:49:33 -0400 Received: from mailgate.Cadence.COM by sicmail.epfl.ch with SMTP (PP) id <06035-0@sicmail.epfl.ch>; Wed, 28 Jun 1995 23:28:47 +0200 Received: (from smap@localhost) by mailgate.Cadence.COM (8.6.8/8.6.8) id OAA21454 for <1076-1@epfl.ch>; Wed, 28 Jun 1995 14:28:42 -0700 Received: from cds8200.cadence.com(158.140.24.155) by mailgate.cadence.com via smap (V1.0mjr) id sma021438; Wed Jun 28 14:28:28 1995 Received: (from trihy@localhost) by cds8200.Cadence.COM (8.6.8/8.6.8) id OAA19712; Wed, 28 Jun 1995 14:28:26 -0700 Date: Wed, 28 Jun 1995 14:28:26 -0700 From: Richard Trihy Message-Id: <199506282128.OAA19712@cds8200.Cadence.COM> To: 1076-1@epfl.ch Subject: VHDL-A equation formulation The LAT team has reached an important turning point that will dramatically affect the useability and utility of VHDL-A. Furthermore, they plan to make a decison on which way they will go without consulting the rest of the 1076.1 community. We think that these issues are very important to potential users of the language, and in our redoubled emphasis to get closure quickly on an LRM, we may be neglecting important end user concerns. Our prototype implementations have generated considerable discussion in our customer community, and the feedback we have received from design departments has consistently been that usability is THE paramount concern; and even that tradeoffs in other areas may be warranted in favor of enhanced usability. The risk we face in a low-usability language is that its use may never leave the CAD laboratory, instead of being used by design engineers. And even worse, a VHDL-A that is overly arcane may not compete with the proprietary AHDL's. Thus, the issues should be presented and discussed by the whole 1076.1 community. We will be sending out a few messages that will educate you about the issues, and allow you to express your opinion as to which is the preferred approach. This represents the first time that you will be able to have an important affect on VHDL-A without having to travel to the far corners of the world or wade through piles of white papers that have been encrypted in LRM-ese. This is important, so take a few moments to read these messages and make your opinion's known. Richard Trihy Dan FitzPatrick Ken Kundert From 1076-1-request@sicmail.epfl.ch Wed Jun 28 17:49:20 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Wed, 28 Jun 95 17:49:15 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Wed, 28 Jun 95 17:49:08 -0400 Received: from mailgate.Cadence.COM by sicmail.epfl.ch with SMTP (PP) id <06082-0@sicmail.epfl.ch>; Wed, 28 Jun 1995 23:31:28 +0200 Received: (from smap@localhost) by mailgate.Cadence.COM (8.6.8/8.6.8) id OAA21896 for <1076-1@epfl.ch>; Wed, 28 Jun 1995 14:31:12 -0700 Received: from cds8200.cadence.com(158.140.24.155) by mailgate.cadence.com via smap (V1.0mjr) id sma021841; Wed Jun 28 14:31:00 1995 Received: (from trihy@localhost) by cds8200.Cadence.COM (8.6.8/8.6.8) id OAA19715; Wed, 28 Jun 1995 14:30:58 -0700 Date: Wed, 28 Jun 1995 14:30:58 -0700 From: Richard Trihy Message-Id: <199506282130.OAA19715@cds8200.Cadence.COM> To: 1076-1@epfl.ch Subject: Survey 1: LAT equation formulation ****** Survey 1 ******* A decision is to be made by the LAT team on the approach for describing the continuous-time equations governing behavioral models. They are considering two proposals, both of which have the required descriptive power. Since the main application area of interest for VHDL-A is electrical systems we have used electrical models as a vehicle to educate you on this single fundamental issue under consideration. The following survey is designed to gather information on the usability of the two different approaches. Please take a few minutes to read the models below and answer the multiple choice questions as best you can. We are very interested in your feedback. Richard Trihy Dan FitzPatrick Ken Kundert -------------------------------------------------------------------- Consider the following models for a voltage-controlled voltage source (VCVS). (A VCVS is a critical component in behavioral modeling since most behavioral models map voltage (across) inputs to voltage (across) outputs, e.g. amplifiers, vcos, mixers) * Please examine the models below and identify, after each model if you think it will work or not. For each example, respond with a, b, or c as follows: a: Acts as forward voltage-controlled voltage source (Vin is input and Vout is output) or (in@V is input and out@V is output) b: Acts as reversed voltage-controlled voltage source (Vin is output and Vout is input) or (in@V is output and out@V is input). c: Flawed description that cannot work. vvvvvvvvvvvvvvvvvvvvvvvvvvvv cut here vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv Voltage-Controlled-Voltage Source You can send your response to vhdla@cadence.com (or to the reflector). If you are not a member of the LAT team, would you like to be involved in this decision (yes or no): COMMENTS: -------------------------------------------------------------------- entity vcvs is generic( gain : real ); port( Terminal p, n, ps, ns : electrical); end vcvs; 1a: ----------------------------------------- architecture oneA of vcvs is quantity Vin across ps to ns; quantity Vout across p to n; begin Vout == gain * Vin; end oneA; What behavior do you expect? ___ a: Acts as forward voltage-controlled voltage source (Vin is input and Vout is output) or (in@V is input and out@V is output) b: Acts as reversed voltage-controlled voltage source (Vin is output and Vout is input) or (in@V is output and out@V is input). c: Flawed description that cannot work. 1b: ----------------------------------------- architecture oneB of vcvs is quantity Vin across Iin through ps to ns; quantity Vout across Iout through p to n; begin Vout == gain * Vin; end oneB; What behavior do you expect? ___ a: Acts as forward voltage-controlled voltage source (Vin is input and Vout is output) or (in@V is input and out@V is output) b: Acts as reversed voltage-controlled voltage source (Vin is output and Vout is input) or (in@V is output and out@V is input). c: Flawed description that cannot work. 1c: ----------------------------------------- architecture oneC of vcvs is quantity Vin across ps to ns; quantity Vout across Iout through p to n; begin Vout == gain * Vin; end oneC; What behavior do you expect? ___ a: Acts as forward voltage-controlled voltage source (Vin is input and Vout is output) or (in@V is input and out@V is output) b: Acts as reversed voltage-controlled voltage source (Vin is output and Vout is input) or (in@V is output and out@V is input). c: Flawed description that cannot work. 1d: ----------------------------------------- architecture oneD of vcvs is quantity Vin across Iin through ps to ns; quantity Vout across p to n; begin Vout == gain * Vin; end oneD; What behavior do you expect? ___ a: Acts as forward voltage-controlled voltage source (Vin is input and Vout is output) or (in@V is input and out@V is output) b: Acts as reversed voltage-controlled voltage source (Vin is output and Vout is input) or (in@V is output and out@V is input). c: Flawed description that cannot work. 1e: ----------------------------------------- architecture oneE of vcvs is quantity Vin across Iin through ps to ns; quantity Vout across Iout through p to n; begin Vout == gain * Vin; Iin == 0; end oneE; What behavior do you expect? ___ a: Acts as forward voltage-controlled voltage source (Vin is input and Vout is output) or (in@V is input and out@V is output) b: Acts as reversed voltage-controlled voltage source (Vin is output and Vout is input) or (in@V is output and out@V is input). c: Flawed description that cannot work. 1f: ----------------------------------------- architecture oneF of vcvs is quantity Vin across Iin through ps to ns; quantity Vout across p to n; begin Vout == gain * Vin; Iin == 0; end oneF; What behavior do you expect? ___ a: Acts as forward voltage-controlled voltage source (Vin is input and Vout is output) or (in@V is input and out@V is output) b: Acts as reversed voltage-controlled voltage source (Vin is output and Vout is input) or (in@V is output and out@V is input). c: Flawed description that cannot work. 1g: ----------------------------------------- architecture oneG of vcvs is quantity Vin across Iin through ps to ns; quantity Vout across Iout through p to n; begin Vout == gain * Vin; Iin == 0; end oneG; What behavior do you expect? ___ a: Acts as forward voltage-controlled voltage source (Vin is input and Vout is output) or (in@V is input and out@V is output) b: Acts as reversed voltage-controlled voltage source (Vin is output and Vout is input) or (in@V is output and out@V is input). c: Flawed description that cannot work. 2a: ----------------------------------------- architecture twoA of vcvs is branch in :electrical from ps to ns; branch out:electrical from p to n; begin out@V <- gain * in@V; end twoA; What behavior do you expect? ___ a: Acts as forward voltage-controlled voltage source (Vin is input and Vout is output) or (in@V is input and out@V is output) b: Acts as reversed voltage-controlled voltage source (Vin is output and Vout is input) or (in@V is output and out@V is input). c: Flawed description that cannot work. 2b: ----------------------------------------- architecture twoB of vcvs is branch in :electrical from ps to ns; branch out:electrical from p to n; begin in@V <- gain * out@V; end twoB; What behavior do you expect? ___ a: Acts as forward voltage-controlled voltage source (Vin is input and Vout is output) or (in@V is input and out@V is output) b: Acts as reversed voltage-controlled voltage source (Vin is output and Vout is input) or (in@V is output and out@V is input). c: Flawed description that cannot work. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ cut here ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ From 1076-1-request@sicmail.epfl.ch Wed Jun 28 17:49:51 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Wed, 28 Jun 95 17:49:48 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Wed, 28 Jun 95 17:49:42 -0400 Received: from mailgate.Cadence.COM by sicmail.epfl.ch with SMTP (PP) id <06091-0@sicmail.epfl.ch>; Wed, 28 Jun 1995 23:31:50 +0200 Received: (from smap@localhost) by mailgate.Cadence.COM (8.6.8/8.6.8) id OAA21958 for <1076-1@epfl.ch>; Wed, 28 Jun 1995 14:31:44 -0700 Received: from cds8200.cadence.com(158.140.24.155) by mailgate.cadence.com via smap (V1.0mjr) id sma021934; Wed Jun 28 14:31:28 1995 Received: (from trihy@localhost) by cds8200.Cadence.COM (8.6.8/8.6.8) id OAA19718; Wed, 28 Jun 1995 14:31:27 -0700 Date: Wed, 28 Jun 1995 14:31:27 -0700 From: Richard Trihy Message-Id: <199506282131.OAA19718@cds8200.Cadence.COM> To: 1076-1@epfl.ch Subject: Survey 2: LAT equation formulation ****** Survey 2 ******* A decision is to be made by the LAT team on the approach for describing the continuous-time equations governing behavioral models. They are considering two proposals, both of which have the required descriptive power. Since the main application area of interest for VHDL-A is electrical systems we have used electrical models as a vehicle to educate you on this single fundamental issue under consideration by the LAT team. The following survey is designed to gather information on the usability of the two different approaches. Please take a few minutes to read the models below and answer the multiple choice questions as best you can. We are very interested in your feedback. Richard Trihy Dan FitzPatrick Ken Kundert -------------------------------------------------------------------- * Please examine the ideal operational amplifier models below and identify in the form provided which models you think will work, which will not. For each example, respond with a, b, or c as follows: a: Acts as forward ideal operational amplifier (Vin is input and Vout is output) or (in@V is input and out@V is output). b: Acts as reversed ideal operational amplifier (Vin is output and Vout is input) or (in@V is output and out@V is input). c: Flawed description that cannot work. vvvvvvvvvvvvvvvvvvvvvvvvvvvv cut here vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv Operational Amplifier You can send your response to vhdla@cadence.com (or to the reflector). If you are not a member of the LAT team, would you like to be involved in this decision (yes or no): COMMENTS: -------------------------------------------------------------------- entity opamp is generic( gain : real ); port( Terminal p, n, ps, ns : electrical); end opamp; 1a: ----------------------------------------- architecture oneA of opamp is quantity Vin across ps to ns; quantity Vout across p to n; begin Vin == 0; end oneA; What behavior do you expect? ___ a: Acts as forward ideal operational amplifier (i.e. Vin is input and Vout is output or in@V is input and out@V is output). b: Acts as reversed ideal operational amplifier (i.e. Vin is output and Vout is input or in@V is output and out@V is input). c: Flawed description that cannot work. 1b: ----------------------------------------- architecture oneB of opamp is quantity Vin across Iin through ps to ns; quantity Vout across p to n; begin Vin == 0; end oneB; What behavior do you expect? ___ a: Acts as forward ideal operational amplifier (i.e. Vin is input and Vout is output or in@V is input and out@V is output). b: Acts as reversed ideal operational amplifier (i.e. Vin is output and Vout is input or in@V is output and out@V is input). c: Flawed description that cannot work. 1c: ----------------------------------------- architecture oneC of opamp is quantity Vin across ps to ns; quantity Vout across Iout through p to n; begin Vin == 0; end oneC; What behavior do you expect? ___ a: Acts as forward ideal operational amplifier (i.e. Vin is input and Vout is output or in@V is input and out@V is output). b: Acts as reversed ideal operational amplifier (i.e. Vin is output and Vout is input or in@V is output and out@V is input). c: Flawed description that cannot work. 1d: ----------------------------------------- architecture oneD of opamp is quantity Vin across Iin through ps to ns; quantity Vout across p to n; begin Vin == 0; Iin == 0; end oneD; What behavior do you expect? ___ a: Acts as forward ideal operational amplifier (i.e. Vin is input and Vout is output or in@V is input and out@V is output). b: Acts as reversed ideal operational amplifier (i.e. Vin is output and Vout is input or in@V is output and out@V is input). c: Flawed description that cannot work. 1e: ----------------------------------------- architecture oneE of opamp is quantity Vin across Iin through ps to ns; quantity Vout across Iout through p to n; begin Vin == 0; end oneE; What behavior do you expect? ___ a: Acts as forward ideal operational amplifier (i.e. Vin is input and Vout is output or in@V is input and out@V is output). b: Acts as reversed ideal operational amplifier (i.e. Vin is output and Vout is input or in@V is output and out@V is input). c: Flawed description that cannot work. 1f: ----------------------------------------- architecture oneF of opamp is quantity Vin across Iin through ps to ns; quantity Vout across p to n; begin Vout == 0; end oneF; What behavior do you expect? ___ a: Acts as forward ideal operational amplifier (i.e. Vin is input and Vout is output or in@V is input and out@V is output). b: Acts as reversed ideal operational amplifier (i.e. Vin is output and Vout is input or in@V is output and out@V is input). c: Flawed description that cannot work. 1g: ----------------------------------------- architecture oneG of opamp is quantity Vin across Iin through ps to ns; quantity Vout across Iout through p to n; begin Vout == 0; Iout == 0; end oneG; What behavior do you expect? ___ a: Acts as forward ideal operational amplifier (i.e. Vin is input and Vout is output or in@V is input and out@V is output). b: Acts as reversed ideal operational amplifier (i.e. Vin is output and Vout is input or in@V is output and out@V is input). c: Flawed description that cannot work. 2a: ----------------------------------------- architecture twoA of opamp is branch in :electrical from ps to ns; branch out:electrical from p to n; begin out@V => in@V == 0; end twoA; What behavior do you expect? ___ a: Acts as forward ideal operational amplifier (i.e. Vin is input and Vout is output or in@V is input and out@V is output). b: Acts as reversed ideal operational amplifier (i.e. Vin is output and Vout is input or in@V is output and out@V is input). c: Flawed description that cannot work. 2b: ----------------------------------------- architecture twoB of opamp is branch in :electrical from ps to ns; branch out:electrical from p to n; begin in@V => out@V == 0; end twoB; What behavior do you expect? ___ a: Acts as forward ideal operational amplifier (i.e. Vin is input and Vout is output or in@V is input and out@V is output). b: Acts as reversed ideal operational amplifier (i.e. Vin is output and Vout is input or in@V is output and out@V is input). c: Flawed description that cannot work. 2c: ----------------------------------------- architecture twoC of opamp is branch in :electrical from ps to ns; branch out:electrical from p to n; begin out@V => out@V == 0; end twoC; What behavior do you expect? ___ a: Acts as forward ideal operational amplifier (i.e. Vin is input and Vout is output or in@V is input and out@V is output). b: Acts as reversed ideal operational amplifier (i.e. Vin is output and Vout is input or in@V is output and out@V is input). c: Flawed description that cannot work. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ cut here ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ From 1076-1-request@sicmail.epfl.ch Wed Jun 28 17:49:28 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Wed, 28 Jun 95 17:49:26 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Wed, 28 Jun 95 17:49:20 -0400 Received: from mailgate.Cadence.COM by sicmail.epfl.ch with SMTP (PP) id <06166-0@sicmail.epfl.ch>; Wed, 28 Jun 1995 23:40:33 +0200 Received: (from smap@localhost) by mailgate.Cadence.COM (8.6.8/8.6.8) id OAA23206 for <1076-1@epfl.ch>; Wed, 28 Jun 1995 14:40:29 -0700 Received: from cds8200.cadence.com(158.140.24.155) by mailgate.cadence.com via smap (V1.0mjr) id sma023172; Wed Jun 28 14:40:16 1995 Received: (from trihy@localhost) by cds8200.Cadence.COM (8.6.8/8.6.8) id OAA19738; Wed, 28 Jun 1995 14:40:15 -0700 Date: Wed, 28 Jun 1995 14:40:15 -0700 From: Richard Trihy Message-Id: <199506282140.OAA19738@cds8200.Cadence.COM> To: 1076-1@epfl.ch Subject: Survey 3: LAT equation formulation ****** Survey 3 ******* A decision is to be made by the LAT team on the approach for describing the continuous-time equations governing behavioral models. They are considering two proposals, both of which have the required descriptive power. Since the main application area of interest for VHDL-A is electrical systems we have used electrical models as a vehicle to educate you on this single fundamental issue under consideration. The following survey is designed to gather information on the usability of the two different approaches. Please take a few minutes to read the models below and answer the multiple choice questions as best you can. We are very interested in your feedback. Richard Trihy Dan FitzPatrick Ken Kundert -------------------------------------------------------------------- Consider the following models for a mixed voltage-controlled voltage source (VCVS) and current-controlled current source (CCCS). (A VCVS is a critical component in behavioral modeling since most behavioral models map voltage (across) inputs to voltage (across) outputs, e.g. amplifiers, vcos, mixers) * Please examine the models below and identify in the space provided which models you think will work, which will not. For each example, respond with a, or b as follows: a: Acts correctly as combination of voltage-controlled voltage source and current-controlled current source (forward or reversed). b: Flawed description that cannot work. vvvvvvvvvvvvvvvvvvvvvvvvvvvv cut here vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv Voltage-Controlled-Voltage Source and Current-Controlled-Current Source You can send your response to vhdla@cadence.com (or to the reflector). If you are not a member of the LAT team, would you like to be involved in this decision (yes or no): COMMENTS: -------------------------------------------------------------------- entity cs is generic( gain : real ); port( Terminal p1, n1, p2, n2, ps1, ns1, ps2, ns2 : electrical); end cs; 1a: ----------------------------------------- architecture oneA of cs is quantity Vin1 across ps1 to ns1; quantity Vout1 across p1 to n1; quantity Iin2 through ps2 to ns2; quantity Iout2 through p2 to n2; begin Vout1 - gain * Vin1 == 0; Iout2 - gain * Iin2 == 0; end oneA; What behavior do you expect? ___ a: Acts correctly as combination of voltage-controlled voltage source and current-controlled current source (forward or reversed). b: Flawed description that cannot work. 1b: ----------------------------------------- architecture oneB of cs is quantity Vin1 across ps1 to ns1; quantity Vout1 across p1 to n1; quantity Vin2 across Iin2 through ps2 to ns2; quantity Iout2 through p2 to n2; begin Vout1 - gain * Vin1 == 0; Iout2 - gain * Iin2 == 0; Vin2 == 0; end oneB; What behavior do you expect? ___ a: Acts correctly as combination of voltage-controlled voltage source and current-controlled current source (forward or reversed). b: Flawed description that cannot work. 1c: ----------------------------------------- architecture oneC of cs is quantity Vin1 across ps1 to ns1; quantity Vout1 across Iout1 through p1 to n1; quantity Vin2 across Iin2 through ps2 to ns2; quantity Iout2 through p2 to n2; begin Vout1 - gain * Vin1 == 0; Iout2 - gain * Iin2 == 0; Vin2 == 0; end oneC; What behavior do you expect? ___ a: Acts correctly as combination of voltage-controlled voltage source and current-controlled current source (forward or reversed). b: Flawed description that cannot work. 1d: ----------------------------------------- architecture oneD of cs is quantity Vin1 across ps1 to ns1; quantity Vout1 across p1 to n1; quantity Iin2 through ps2 to ns2; quantity Vout2 across Iout2 through p2 to n2; begin Vout1 - gain * Vin1 == 0; Iout2 - gain * Iin2 == 0; Vout2 == 0; end oneD; What behavior do you expect? ___ a: Acts correctly as combination of voltage-controlled voltage source and current-controlled current source (forward or reversed). b: Flawed description that cannot work. 1e: ----------------------------------------- architecture oneE of cs is quantity Vin1 across Iin1 through ps1 to ns1; quantity Vout1 across p1 to n1; quantity Vin2 across Iin2 through ps2 to ns2; quantity Vout2 across Iout2 through p2 to n2; begin Vout1 - gain * Vin1 == 0; Iout2 - gain * Iin2 == 0; Vout2 == 0; end oneE; What behavior do you expect? ___ a: Acts correctly as combination of voltage-controlled voltage source and current-controlled current source (forward or reversed). b: Flawed description that cannot work. 1f: ----------------------------------------- architecture oneF of cs is quantity Vin1 across Iin1 through ps1 to ns1; quantity Vout1 across Iout1 through p1 to n1; quantity Vin2 across Iin2 through ps2 to ns2; quantity Iout2 through p2 to n2; begin Vout1 - gain * Vin1 == 0; Iout2 - gain * Iin2 == 0; Vin2 == 0; end oneF; What behavior do you expect? ___ a: Acts correctly as combination of voltage-controlled voltage source and current-controlled current source (forward or reversed). b: Flawed description that cannot work. 2a: ----------------------------------------- architecture twoA of cs is branch in1 :electrical from ps1 to ns1; branch in2 :electrical from ps2 to ns2; branch out1:electrical from p1 to n1; branch out2:electrical from p2 to n2; begin out1@V <- gain * in1@V; out2@I <- gain * in2@I; end twoA; What behavior do you expect? ___ a: Acts correctly as combination of voltage-controlled voltage source and current-controlled current source (forward or reversed). b: Flawed description that cannot work. 2b: ----------------------------------------- architecture twoB of cs is branch in1 :electrical from ps1 to ns1; branch in2 :electrical from ps2 to ns2; branch out1:electrical from p1 to n1; branch out2:electrical from p2 to n2; begin in1@V <- gain * out1@V; in2@I <- gain * out2@I; end twoB; What behavior do you expect? ___ a: Acts correctly as combination of voltage-controlled voltage source and current-controlled current source (forward or reversed). b: Flawed description that cannot work. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ cut here ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ From 1076-1-request@sicmail.epfl.ch Thu Jun 29 07:08:47 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Thu, 29 Jun 95 07:08:42 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Thu, 29 Jun 95 07:08:25 -0400 Received: from c3imac12.epfl.ch by sicmail.epfl.ch with SMTP (PP) id <13826-0@sicmail.epfl.ch>; Mon, 26 Jun 1995 09:56:52 +0200 X-Sender: vachoux@c3i9.epfl.ch Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 26 Jun 1995 09:58:29 +0100 To: 1076-1@epfl.ch From: alain.vachoux@leg.de.epfl.ch (Alain Vachoux EPFL-LEG/C3i) Subject: Vote on DOD 2.2 All, It is now time to proceed to a new vote on the 1076.1 Design Objective Document (DOD) version 2.2. I recall you that the vote on DOD 2.1 did not carry since the quorum of 50% of the voting members was not reached. Nevertheless, this has been a good opportunity for us to have this text one more reviewed and to get comments. DOD 2.2 accomodates these comments. The supporting document, the Design Objective Rationale (DOR) has also been modified to reflect the changes in DOD 2.2 and has now version 1.2. DOD 2.2 and DOR 1.2 are available in our ftp repository (nestor.epfl.ch, 128.178.50.20) in the directory /pub/vhdl/standards/ieee/1076.1/requirements in the files DOD_v2.2.txt and DOR_v1.2.txt respectively. I can send these documents through e-mail upon request for those with no ftp access. The question is: Do you approve of the Design Objective Document (DOD), version 2.2, 23 jun 95, as the basis for the first release of VHDL-A? Here are the instructions about how to proceed: - A quorum of at least 50% of the voting members (68 as of June 26) must be reached for the vote to be effective. - Vote "yes", "no", or "abstain". Note that the annex of the DOD contains original requirements that are put here the way they were submitted. The annex is not part of the vote. Also, the DOR 1.2 is an accompanying document that is not part of the vote. - At least 70% of the returned votes must be positive (consensus) for the vote to carry. - Negative votes must state the reason(s) of the vote. - Positive votes may include some comments. - The requirement subcommittee must respond to all negative votes and if necessary reflect such responses in the voted document; it may also decide to respond the same way to comments that came with positive votes. - The vote is anonymous. - Closing date for the vote is July 15, 1995. Thanks, Alain Vachoux Secretary 1076.1 WG From 1076-1-request@sicmail.epfl.ch Thu Jun 29 07:09:42 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Thu, 29 Jun 95 07:09:35 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Thu, 29 Jun 95 07:08:43 -0400 Received: from mail.Germany.EU.net by sicmail.epfl.ch with SMTP (PP) id <17376-0@sicmail.epfl.ch>; Thu, 29 Jun 1995 09:53:52 +0200 Received: by mail.Germany.EU.net with UUCP (8.6.5:29/EUnetD-2.5.1.g) via EUnet id JAA06863; Thu, 29 Jun 1995 09:55:34 +0200 Original-Received: from chip anacad.de by anacad.de (4.1/SMC-5.11) Pp-Warning: Illegal Received field on preceding line X-Mailer: InterCon TCP/Connect II 1.2 Message-Id: <9506290945.AA46098@chip.machtnix> Date: Thu, 29 Jun 1995 09:45:46 +0100 From: Larry Moore To: 1076-1@epfl.ch Subject: VHDL-A "rush" We completely agree with the Email below. We would add that the decision to "accelerate" the decision process, forcing issues to be "closed" by certain dates, completely undermines the whole point of open discussions, especially when unrealistic time lines are dictated. We are as keen as anybody to see progress, but our impression is that little progress was made for a very long time, and suddenly issues of great importance are forced. We have prepared a large set of issues for further discussion. We have even presented a set of possible solutions to the problems we saw. At the last meetings, with only one exception the whole audience of the meeting agreed in principle with the validity of our statements. Now however we see no answer or resolution to our points. We also are concerned by the possibility of a language being defined which looks good only on paper. We feel that if the whole working group gets a chance to discuss and vote on the issues, the chances of a user friendly language being defined will greatly increase. Frankly we see no reason for the sudden "rush". Since Richard and others have added their comments and proposals on this reflector, we add here ours, which were presented at the last LAT meeting in ths US. IN THE TEXT BELOW, EACH EMAIL IS HEADED BY THE MESSAGE "EMAIL N" WHERE "N" GOES FROM 1 TO 5; YOU CAN USE THIS TO FIND THE START OF SUCCEEDING MESSAGES. Serge Garcia Oliver-Fisher Binder Jutta Ipsen Kevin Walsh Larry Moore EMAIL 1 Contributions : comments ================== Preamble ------- The syntax contained in this text is the syntax as currently proposed by the LAT group, or least we have tried to use a syntax which is as close as possible to that syntax. The material contained herein has been presented within the LAT and 1076.1 WG at various times, but as yet the problems illustrated have not been addressed to our satisfaction. This is one of a series of key comments which are our latest attempt to focus the 1076.1 WG to what we feel are fundamental problems which now require urgent attention. The complete set of commentaries is: Serge: Quantities and terminals Serge: AD Confusion Serge: Nature Declarations Serge: Library Reuse Serge: BREAK Purpose ------ The purpose of this comment is to highlight what we consider to be inefficiencies and unfortunate restrictions of the current proposed use contributions and assignments. Discussion ------- In VHDL, the structure description is based on the concept of "nets" and "net" is a VHDL term. PORTs are connected together via SIGNALs. The behavioral description uses the net concept. When values are assigned (as for example in the statement "sig <= '1';"), these values are transferred to a driver, which performs signal resolution (at the end of the delta delay) and therafter assigns the final value to the net assigned to the net. We need not declare the driver explicitly. The SIGNAL does take however the value assigned to it (not necessarily the same value which is assigned to the net). This is illustrated in the simple following example : ENTITY multiple_processes IS SIGNAL sig : std_logic; END ENTITY multiple_processes; ARCHTECTURE one_driver OF multiple_processes IS BEGIN sig <= `1'; END ARCHITECTURE one_driver; ARCHITECTURE two_drivers OF multiple_processes IS BEGIN sig <= `1'; sig <= `L'; END ARCHITECTURE two_drivers; What is now proposed as extension for trhe analog part uses a different philosophy and we disagree with this. What the LAT approach implements is explained in the following: The equivalent of the SIGNAL for digital is the TERMINAL and QUANTITY for analog. In the analog behavioral model, the LAT apprach does not use TERMINALs but forces the model writer to declare "branches"; a branch is used to assign a value of what flows between *two* terminals. Thus while for digital modeling we have the concept of an implicit driver applied to one connection point and the concept of assignment after resolution to a net, in analog we always are forced to think in terms of explicit branches and "couples"; Thus digital implicit drivers applied to an explicit net analog explicit branches applied to an explicit couple of nets This is unnecessary and results in cumbersome modeling. Furthermore.because of the above we have modeling problems as shown below. a) we must declare objects which never appear in an equation set (example below) ENTITY ideal_amp IS PORT (TERMINAL inplus, inminus, output : electrical); END ENTITY ideal_amp; ARCHITECTURE one OF ideal_amp IS QUANTITY voltage_input ACROSS current_input THROUGH inplus TO inminus; QUANTITY current_output THROUGH -- declared but never used output TO electrical'REFERENCE; BEGIN voltage_input == 0.0; current_input == 0.0; END ARCHITECTURE one; If we remove the declaration of current_output, which is that of an unused object, the model contains an error (from the LAT required semantics point of view) b) if we declare an object and do not associate to it an equation, the system must declare an error (example below) ARCHITECTURE two OF ideal_amp IS QUANTITY voltage_input ACROSS current_input THROUGH -- declared but not used inplus TO inminus; QUANTITY current_output THROUGH output TO electrical'REFERENCE; BEGIN voltage_input == 0.0; END ARCHITECTURE two; The above (theoretical) example contains wrong semantics because two branches are declared and only one equation is defined. c) if we declare all objects associated to all equations but the number of branches is not the same as the number of equations, an error will occur. In this case we declare two objects belonging to one branch, and we have two equations; the system would expect ONE equastion only, since only one branchis defined. ARCHITECTURE three OF ideal_amp IS QUANTITY voltage_input ACROSS current_input THROUGH inplus TO inminus; BEGIN voltage_input == 0.0; current_input == 0.0; END ARCHITECTURE three; Conclusions -------- There is no language consistency between VHDL and the LAT proposed extensions, in the general subject of object declaration and therefore situations occur when a) object declarations are required even when they are not used b) it is not possible to declare more objects than equations All this leads to inconsistent and cumbersome modeling style. Solutions to these problems will be proposed in the White Paper called "Quantities, Nodes and Contributions" from Serge Garcia-Sabiro, to be presented at DAC 95. Aknowledgments ----------- The opinions expressed herein are those of Serge Garcia-Sabiro Jan Jose Mayol, Hazem El Tahawy, Oliver Fisher Binder and have been derived following extensive discussions with a variety of other people. Thus "we" refers to a collection rather than an individual. EMAIL 2 Analog Digital Confusion: comments ========================= Preamble ------- The syntax contained in this text is the syntax as currently proposed by the LAT group, or least we have tried to use a syntax which is as close as possible to that syntax. The material contained herein has been presented within the LAT and 1076.1 WG at various times, but as yet the problems illustrated have not been addressed to our satisfaction. This is one of a series of key comments which are our latest attempt to focus the 1076.1 WG to what we feel are fundamental problems which now require urgent attention. The complete set of commentaries is: Serge: Quantities and terminals Serge: AD Confusion Serge: Nature Declarations Serge: Library Reuse Serge: BREAK Purpose ------ The purpose of this comment is to highlight what we consider to be admittedly implementation problems with the current approach of the LAT proposal. We submit that we need to design a language which will be implementable by EDA suppliers and in particular we should if at all possible avoid producing a language model which will cause severe problems to users and suppliers of VHDL and SPice methodologies. Discussion -------- Of necessity the 1076.1 WG have defined an "ideal analog solver"; the "ideal digital solver" is in fact defined by the VHDL standard itself; that standard goes as far as to define the simulation cycle. In VHDL, "statements" are "concurrent". Within a VHDL "statement" all digital quantities (SIGNAL) are defined to be computed in a "concurrent" or "parallel" manner. The concept of "concurrency" is defined in the 1076 LRM (VHDL). The 1076.1 WG has defined "analog statements" containing expressions (or equations); the expressions define analog waveforms (QUANTITY), whose value must be calculated "simulateneously". The concept of "simultaneously" is defined in the appropriate LAT White Papers. We agree to all the above. Unfortunately the current LAT proposal also states that the digital "statement" may in the future explicitly *calculate* analog values (thus calculate the value of QUANTITY). This is well illustrated in the simple "bouncing ball" example, included below as reference, where the BREAK statement refers an analog QUANTITY. In our opinion this is a) not necessary; we have never found a modeling need for such behaviors b) will cause tremendous problems to all existing digital simulators which will be forced to a major redesign - from the point of view of practical, pragmatic engineering, this may be the most important point c) will prevent someone who *only* wishes to model analog effects, to work with a subset of the language and use only the analog solver We believe that we should aim for a language structure which maintains current methodologies and if at all possible does not invalidate simulation technologies already implemented, unless of course we come across modeling problems which cannot otherwise be solved. This has not happened as of today. Conclusions -------- We disagree with a language model which would force the digital solver to calculate analog values (thus somehow incude an analog solver?). Solutions to these problems will be proposed in the White Paper called "Analog Statements" from Serge Garcia-Sabiro, to be presented by the end of July 95. P.S. and more technical: ----------------- Splitting the calculation of QUANTITY between analog and digital solvers, putting some of the analog QUANTITY *calculation* in the digital solver, has additional implications when such values need to be *all* solved simultaneously; in that case iteration procedures will be much more complicated and digital solvers will need to get heavily involved with analog processing. This "involvement" will be far greater than synchronization and data transmission. It is not clear that many digital simulator suppliers would want to implement such features; we need to begin to seriously consider the usability and acceptability of what we are designing. Aknowledgments ----------- The opinions expressed herein are those of Serge Garcia-Sabiro Jan Jose Mayol, Hazem El Tahawy, Oliver Fisher Binder and have been derived following extensive discussions with a variety of other people. Thus "we" refers to a collection rather than an individual. Example of "bouncing ball", included here for reference ARCHITECTURE ball OF boucer IS QUANTITY v: velocity := 0.0; QUANTITY s: displacement := 10.0; CONSTANT g: real := 9.81; CONSTANT air_res: real := 0.1; BEGIN BREAK v => -v ON s'CROSS(0.0); s'DOT == v IF v > 0.0 USE v'DOT == -g - v**2*air_res; ELSE v'DOT == -g + v**2*air_res; END USE; END ARCHITECTURE ball; The BREAK statement, implemented from a semantoic point of view as PROCESS (hence digital), manipulates an analog value EMAIL 3 BREAK Statement: comments ==================== Preamble ------- The syntax contained in this text is the syntax as currently proposed by the LAT group, or least we have tried to use a syntax which is as close as possible to that syntax. The material contained herein has been presented within the LAT and 1076.1 WG at various times, but as yet the problems illustrated have not been addressed to our satisfaction. This is one of a series of key comments which are our latest attempt to focus the 1076.1 WG to what we feel are fundamental problems which now require urgent attention. The complete set of commentaries is: Serge: Quantities and terminals Serge: AD Confusion Serge: Nature Declarations Serge: Library Reuse Serge: BREAK Purpose ------ The purpose of this comment is to highlight what we consider to be inconsistencies or problems associated to the BREAK statement, currently proposed by the LAT. Discussion ------- Of necessity, 1076.1 WG have defined an "ideal analog solver"; the "ideal digital solver" is in fact defined by the VHDL standard itself; that standard goes as far as to define the simulation cycle. In VHDL, "statements" are "concurrent". Within a VHDL "statement" all digital quantities (SIGNAL) are defined to be computed in a "concurrent" or "parallel" manner. The concept of "concurrency" is defined in the 1076 LRM (VHDL). The 1076.1 WG has defined "analog statements" containing expressions (or equations); the expressions define analog waveforms (QUANTITY), whose value must be calculated "simulateneously". The concept of "simultaneously" is defined in the appropriate LAT White Papers. The ideal analog and digital solvers need to work together and often synchronize their results. It is widely acknowledged that there are models which need to handle discontinuities. Such models occur in many all disciplines (mechanics, electronics, physics etc); over the last few months several such models have been discussed in the 1076.1 WG; we use here to highlight our point of view, the "bouncing ball" and the "analog-digital variable synchronization" models. Such models illustrate the problem of high-level modeling of complicated differential-algebraic equations in the presence of discontinuity. To address this kind of problem, the BREAK statement (or a semantically equivalent one) has been defined. There are two major reasons why the BREAK statement has been introduced namely: a) to notify the solver(s) of the need to *reset* QUANTITY values (analog values) b) to notify the solver(s) of the need to *synchronize* themselves We believe that in the case of models where a reset of the QUANTITY values is necessary, the BREAK statement is indeed essential and should be used. On the other hand we believe that models should not be coded to explicitly control synchronization because this is an implementation requirement, resulting perhaps from some specific ideas of how mixed signal synchronization works. In fact models which are forced to include BREAK statements when synchronization is necessary, tend to be difficult and error prone to write and put limitations on the solvers. Our experience shows that mixed signal synchronization is possible by careful analysis of the language structure itself. We illustrate both cases using the examples of the bouncing ball and the "analog-digital variable synchronization". Example "bouncing ball" ----------------- The implementation presented here is a simplified model, where we assume that a ball falling on to a plate will bounce back with no energy loss due to friction. ARCHITECTURE ball OF boucer IS QUANTITY v: velocity := 0.0; QUANTITY s: displacement := 10.0; CONSTANT g: real := 9.81; CONSTANT air_res: real := 0.1; BEGIN BREAK v => -v ON s'CROSS(0.0); s'DOT == v IF v > 0.0 USE v'DOT == -g - v**2*air_res; ELSE v'DOT == -g + v**2*air_res; END USE; END ARCHITECTURE ball; In this case the use of BREAK is easy to understand; when the "displacement" QUANTITY reaches zero (contact is made), the model must be instructed that the velocity "v" (also a QUANTITY) will undergo a discontinuity. Example "analog-digital variable synchronization" ----------------------------------- In this example we have two analog values (QUANTITY) called "y1" and "y2" whose values are determined in differential equations which themselves contain digital values (SIGNAL) "c2" and "c4"; the latter are subject to discontinuous change (as is natural for digital values). In the example, when "y1" and "y2" go through specified thresholds, "c2" and "c4" are changed abruptly. As a result "y1" and "y2" remain continuous, but their derivatives change discontinuously. The BREAK statement is used to tell the solver(s) that when values of "c2" and "c4" change, synchronization of the analog and digital solvers needs to occur. At this point it is important to point out that whatever the implementation of the tool(s), we will always have a "Newton" or other analog solver and an "event queue" of some kind, thus synchronization will always be necessary independently of "unified" or "single" or whatever. ARCHITECTURE simple OF two_states IS QUANTITY y1,y2: real; CONSTANT c1: real:= 2.7E6; CONSTANT c3: real := 3.56; SIGNAL c2, c4: real := 0.1; BEGIN y1'dot == c1 * (y2 + c2 - y1); y2'dot == c3 * (c4 - y2); BREAK ON c2,c4; PROCESS BEGIN s1: c2 <= 0.4; c4 <= 5.5; WAIT ON y1'cross(5.8); s2: c2 <= -0.3; c4 <= 2.73; WAIT ON y1'cross(2.5); END PROCESS; END ARCHITECTURE simple; Our point is that this puts a heavy (and unnecessary) burden on the model designer. In the above example it may be obvious that synchronization is necessary when "c2" and or "c4" change, but we can easily construct more complex models where this is not so. Furthermore, we can also design a model where the BREAK statement for the purpose of synchronization causes such "synchronization" more often than necessary. Imagine a situation where "y1" and "y2" are calculated by two sets of equations, one of which is selected at each model execution depending on some other condition, and imagine that one set of equations does *not* contain dependency on "c2 and "c4". The BREAK statement would also cause in that case synchronization when none is required. That synchronization would at least cause the solver(s) to stop and then restart having done essentially nothing. Conclusions -------- a) We agree on the use of BREAK for variable reset purposes b) We disagree on the use of BREAK for synchronization purposes Solutions to these problems will be proposed in the White Paper called "Analog Statements" from Serge Garcia-Sabiro, to be presented by the end of July 95. P.S. See also the comments "A-D Confusion" on a related topic. Aknowledgments ----------- The opinions expressed herein are those of Serge Garcia-Sabiro Jan Jose Mayol, Hazem El Tahawy, Oliver Fisher Binder and have been derived following extensive discussions with a variety of other people. Thus "we" refers to a collection rather than an individual. EMAIL 4 Library Reuse : comments ================== Preamble ------- The material contained herein has been presented within the LAT and 1076.1 WG at various times, but as yet the problems illustrated have not been addressed to our satisfaction. This is one of a series of key comments which are our latest attempt to focus the 1076.1 WG to what we feel are fundamental problems which now require urgent attention. The complete set of commentaries is: Serge: Quantities and terminals Serge: AD Confusion Serge: Nature Declarations Serge: Library Reuse Serge: BREAK Purpose ------ The purpose of this comment is to highlight what we consider to be a serious problem with the current approach of the LAT proposal, relating to the usability and portability of the models. Discussion ------- The Design Objective Document was not as complete as it should have been. Some essential objectives were forgotten, perhaps because considered "obvious". One such obvious "objective" is the following: "A model which instantiates a component, should be able to read and use (access) each pin voltage as well pin current, independently of the way that component model is written". In the current approach this is not possible. Thus it is not possible to enable the access of both the "through" and "across" quantities of any one interface point; two PORTs are required, one of nature TERMINAL and the other of nature QUANTITY (a PORT is the language implementation of a "pin"). That is an unnecessary and very uncomfortable restriction. Consider the case of schematic editor driven system design, where the component connections are represented by pins on a drawing; in that case one will see additional "pins" present only to provide additional information about the component data and not representing the physical nature of the component. Thus, with the currently proposed approach it is not possible to use component libraries in different applications, some requiring the access of "through" values at the connection points and some not. Both the ENTITY and the ARCHITECTURE require recoding, depending on the application. Conclusions -------- We do not agree with the current LAT language implementation philosophy which forces models to be coded differently, depending on the kind of information which the instantiating model will require from any one connection point (PORT). Solutions to these problems will be proposed in the White Paper called "Quantities, Nodes and Contributions" from Serge Garcia-Sabiro, to be presented at DAC 95. Acknowledgments ----------- The opinions expressed herein are those of Serge Garcia-Sabiro Jan Jose Mayol, Hazem El Tahawy, Oliver Fisher Binder and have been derived following extensive discussions with a variety of other people. Thus "we" refers to a collection rather than an individual. EMAIL 5 Nature Declarations: comments ====================== Preamble ------- The material contained herein has been presented within the LAT and 1076.1 WG at various times, but as yet the problems illustrated have not been addressed to our satisfaction. This is one of a series of key comments which are our latest attempt to focus the 1076.1 WG to what we feel are fundamental problems which now require urgent attention. The complete set of commentaries is: Serge: Quantities and terminals Serge: AD Confusion Serge: Nature Declarations Serge: Library Reuse Serge: BREAK Discussion -------- VHDL is a strongly typed language which includes the TYPE mechanism. For VHDL-A, it is generally agreed that we need a "nature" mechanism which defines the structure of a basic analog connection. We do not understand why the VHDL TYPE mechanism has not been used (extended) fo this purpose and instead a complete new parallel mechansim has been defined - that of NATURE TYPES. Conclusions -------- We believe that the additional burden on tools and model developers placed by the proposed "double approach" to the declaration of "natures" should be avoided if at all possible. Solutions to this problem will be proposed in the White Paper called "Quantities, Nodes and Contributions" from Serge Garcia-Sabiro, to be presented at DAC 95. Acknowledgments ----------- The opinions expressed herein are those of Serge Garcia-Sabiro Jan Jose Mayol, Hazem El Tahawy, Oliver Fisher Binder and have been derived following extensive discussions with a variety of other people. Thus "we" refers to a collection rather than an individual. Serge Garcia Oliver-Fisher Binder Jutta Ipsen > Date: Wed, 28 Jun 1995 14:28:26 -0700 > From: Richard Trihy > Message-Id: <199506282128.OAA19712@cds8200.Cadence.COM> > To: epfl.ch!1076-1 > Subject: VHDL-A equation formulation > > > > The LAT team has reached an important turning point that will > dramatically affect the useability and utility of VHDL-A. > Furthermore, they plan to make a decison on which way they will go > without consulting the rest of the 1076.1 community. We think that > these issues are very important to potential users of the language, and > in our redoubled emphasis to get closure quickly on an LRM, we may be > neglecting important end user concerns. > > Our prototype implementations have generated considerable discussion in > our customer community, and the feedback we have received from > design departments has consistently been that usability is THE > paramount concern; and even that tradeoffs in other areas may be > warranted in favor of enhanced usability. > > The risk we face in a low-usability language is that its use may never > leave the CAD laboratory, instead of being used by design engineers. > And even worse, a VHDL-A that is overly arcane may not compete with the > proprietary AHDL's. > > Thus, the issues should be presented and discussed by the whole 1076.1 > community. We will be sending out a few messages that will educate you > about the issues, and allow you to express your opinion as to > which is the preferred approach. This represents the first time that > you will be able to have an important affect on VHDL-A without having > to travel to the far corners of the world or wade through piles of > white papers that have been encrypted in LRM-ese. This is important, > so take a few moments to read these messages and make your opinion's > known. > > > Richard Trihy > Dan FitzPatrick > Ken Kundert > > > From 1076-1-request@sicmail.epfl.ch Thu Jun 29 07:12:17 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Thu, 29 Jun 95 07:12:02 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Thu, 29 Jun 95 07:11:58 -0400 Received: from isis.u-strasbg.fr by sicmail.epfl.ch with SMTP (PP) id <01761-0@sicmail.epfl.ch>; Thu, 29 Jun 1995 12:55:22 +0200 Received: from erm1 (root@erm1.u-strasbg.fr [130.79.74.61]) by isis.u-strasbg.fr (8.6.9/8.6.9) with SMTP id LAA04972; Thu, 29 Jun 1995 11:08:44 +0200 Date: Thu, 29 Jun 1995 11:11:10 +0100 From: Heiko Fricke Subject: Question on survey 1-3, LAT equation formulation To: Richard Trihy Cc: 1076-1@epfl.ch Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, maybe I have overlooked something somewhere. My question is: what is the difference of '=>' used in opamp example 2a-2c compared with '<-' in the vcvs and cs examples? Does it mean the same? Am I free to use '=>' or '->' alternatively or is there a thought behind I didn't catch? Thanks Heiko Heiko FRICKE heiko.fricke@ensps.u-strasbg.fr | Numeric stability is Ecole Nationale Superieure de Physique de Strasbourg | probably not all that Equipe de Recherche en Microelectronique | important when you're Tel.: +33-88.65.50.95 Fax: +33-88.65.52.49 | guessing. From 1076-1-request@sicmail.epfl.ch Thu Jun 29 09:50:17 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Thu, 29 Jun 95 09:50:06 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Thu, 29 Jun 95 09:49:57 -0400 X400-Received: by mta sicmail.epfl.ch in /PRMD=switch/ADMD=arCom/C=ch/; Relayed; Thu, 29 Jun 1995 14:59:55 +0200 Date: Thu, 29 Jun 1995 14:59:55 +0200 X400-Originator: 1076-1-request@sicmail.epfl.ch X400-Recipients: non-disclosure:; X400-Mts-Identifier: [/PRMD=switch/ADMD=arCom/C=ch/;sicmail.ep.865:29.05.95.12.59.55] Priority: Non-Urgent Dl-Expansion-History: 1076-1@epfl.ch ; Thu, 29 Jun 1995 14:59:49 +0200; From: "Jean-michel.Berge" Message-Id: To: analog_reflector <1076-1@epfl.ch> Subject: About the "survey".... X-Mailer: Mail*Link SMTP/MS 3.0.0 At its meeting two weeks ago the 1076.1 Language Design Committee (LDC) discussed two proposals that were submitted as alternatives to the work that had previously been approved by the Language Architecture Team (LAT) and sent to the reflector. One of the alternatives, which is closer to the LESs than the LAT approach, was presented by Serge Garcia Sabiro, the other one, which is loosely based on SpectreHDL, by Richard Trihy. Both alternatives are descriptions of ideas without firm semantics, but we did not expect this at this stage. There are many similarities between the LAT approach and the alternatives, but there are also differences. One of the differences has to do with the declaration of branches. The LDC agreed on a process to resolve this issue, by documenting the similarities and differences, discussing the issues by email within the LDC, and finally vote within the LDC in late July or early August. This process was approved by the meeting attendees with 12 votes in favor and Richard's vote against. Richard thought that the issue should be resolved at the next meeting in September, not through email. Nobody suggested during that discussion that this resolution should involve the Working Group at large, because the resolution of a language design issue cannot be a popularity contest. It also is not a democratic process, because too many issues have to fit together that cannot be looked at independently. Given the consensus within the LDC, the step taken by Richard Trihy, Dan Fitzpatrick and Ken Kundert to conduct a public survey on a small part of the language design is completely unexpected and counter productive. It is unfair because it picks out a single issue without providing context, and it suggests that language design can be done starting with some syntax and guessing what it should mean. This approach has been used unsuccessfully in the past, and it resulted in emotional discussions rather than technical ones. For about 9 months now the language design effort has been a top-down process, where semantics are defined before syntax. As a result the discussions have substance and are much less emotional, and we have made considerable progress, as demonstrated again at the Working Group meeting in San Jose. One of the attendees of the last LDC meeting actually pointed out (after having missed several LDC meetings) that he was pleased with the high technical level of the discussions. There will always be differences of opinion about details, because there are several ways of doing the same thing. The LDC has been working hard at investigating several solutions, but it is impractical to work out all of them in detail. This does not mean that we will get a bad language, it means that we will get a good language in a reasonable time frame. Even if we were given an infinite amount of time and resources it would be impossible to get the best language, because different people have different priorities. Language design is an exercise in consensus building, where many details have to be taken into consideration that all must work together in a coherent and consistent way. It seems that Richard Trihy, Dan Fitzpatrick and Ken Kundert have a strange idea about what team work is all about, and their lack of following the process agreed upon by consensus is stunning, particularly because Dan Fitzpatrick accused the 1076.1 leadership last fall of not following its processes. At that time he did not even bother to respond to the answer prepared by the Executive Committee. Jean-Michel Berge, Ernst Christen and Alain Vachoux 1076.1 Executive Committee From 1076-1-request@sicmail.epfl.ch Thu Jun 29 11:25:16 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Thu, 29 Jun 95 11:25:09 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Thu, 29 Jun 95 11:24:51 -0400 Received: from c3imac12.epfl.ch by sicmail.epfl.ch with SMTP (PP) id <12728-0@sicmail.epfl.ch>; Thu, 29 Jun 1995 16:31:44 +0200 X-Sender: vachoux@c3i9.epfl.ch Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 29 Jun 1995 16:33:23 +0100 To: 1076-1@epfl.ch From: alain.vachoux@leg.de.epfl.ch (Alain Vachoux EPFL-LEG/C3i) Subject: Validation report All, Quoting the last 1076.1 WG meeting minutes: >3. Validation committee report (Oliver Fischer-Binder) > >[A postscript version of the slides presented here is available in the file >valid_slides.ps] > >Since a first package of provisonally approved white papers is now available, >the validation task may start. Oliver presented an evaluation of the modeling >style implied by these WPs. A first answer to this review was done before the meeting by Ken Bakalar, but the audience was only the people involved in the language design committee meeting that was held the same week. Actually, Ken answered a text document coming from Serge Garcia-Sabiro. Serge's text was recently broadcasted to the whole WG in the email "VHDL-A "rush"" of June, 29. To be fair, Ken's answer, as well as Oliver's slides, are now publicly available on the ftp repository in the directory pub/vhdl/standards/ieee/1076.1/validation/review Files are: jun95_slides.ps Oliver's slides jun95_answer.txt Ken's answer Alain Vachoux From 1076-1-request@sicmail.epfl.ch Thu Jun 29 11:37:33 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Thu, 29 Jun 95 11:37:16 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Thu, 29 Jun 95 11:37:01 -0400 Received: from clsi.columbia.compass-da.com by sicmail.epfl.ch with SMTP (PP) id <12102-0@sicmail.epfl.ch>; Thu, 29 Jun 1995 16:14:22 +0200 Received: from adhara.columbia.compass-da.com (adhara [162.17.30.14]) by clsi.columbia.compass-da.com (8.6.12/8.6.9) with ESMTP id KAA04494 for <1076-1@epfl.ch>; Thu, 29 Jun 1995 10:14:44 -0400 From: Peter Liebmann Reply-To: peterl@compass-da.com Received: (peterl@localhost) by adhara.columbia.compass-da.com (8.6.9/8.6.9) id KAA00723 for 1076-1@epfl.ch; Thu, 29 Jun 1995 10:14:45 -0400 Date: Thu, 29 Jun 1995 10:14:45 -0400 Message-Id: <199506291414.KAA00723@adhara.columbia.compass-da.com> To: 1076-1@epfl.ch Subject: RE: VHDL-A survay COMMENTS: In 1a, no branch is defined - in present VHDL-A a branch is defined by declaring a THROUGH quantity. A defined branch means that a description of the branch must be given which, in present VHDL-A, is a single simultaneous statement (i.e. for each THROUGH quantity declaired in an entity there must be a single simultaneous statement in that entity - not necessaraly visa-versa). In example 1a, none of the conditions (declarations) exist which can cause the existance of a simultanious statement. All present proposals (LAT, Cadence and Anacad) have a mechanism to tell how many branches (simultaneous statements) are present in an entity, and, at this point, I see no ambiguity in any of the proposials (I am also not aware of any limitations). I think the point of this survey is to get an opinion from users which is the easiest description to use. HOWEVER, none of the proposed syntaxes are intuitively obvious - all users will need some sort of training, so the statement "the easiest description" is somewhat meaningless. Maybe if the semantics were presented in the questions along with the syntax, the survay will have more meaning since it could reflect the amount of training a user will need to read or write a VHDL-A design. -------------------------------------------------------------------- entity vcvs is generic( gain : real ); port( Terminal p, n, ps, ns : electrical); end vcvs; 1a: ----------------------------------------- architecture oneA of vcvs is quantity Vin across ps to ns; quantity Vout across p to n; begin Vout == gain * Vin; end oneA; What behavior do you expect? _C__ a: Acts as forward voltage-controlled voltage source (Vin is input and Vout is output) or (in@V is input and out@V is output) b: Acts as reversed voltage-controlled voltage source (Vin is output and Vout is input) or (in@V is output and out@V is input). c: Flawed description that cannot work. 1b: ----------------------------------------- architecture oneB of vcvs is quantity Vin across Iin through ps to ns; quantity Vout across Iout through p to n; begin Vout == gain * Vin; end oneB; What behavior do you expect? _C__ a: Acts as forward voltage-controlled voltage source (Vin is input and Vout is output) or (in@V is input and out@V is output) b: Acts as reversed voltage-controlled voltage source (Vin is output and Vout is input) or (in@V is output and out@V is input). c: Flawed description that cannot work. COMMENTS: 1c: ----------------------------------------- architecture oneC of vcvs is quantity Vin across ps to ns; quantity Vout across Iout through p to n; begin Vout == gain * Vin; end oneC; What behavior do you expect? __A_ a: Acts as forward voltage-controlled voltage source (Vin is input and Vout is output) or (in@V is input and out@V is output) b: Acts as reversed voltage-controlled voltage source (Vin is output and Vout is input) or (in@V is output and out@V is input). c: Flawed description that cannot work. 1d: ----------------------------------------- architecture oneD of vcvs is quantity Vin across Iin through ps to ns; quantity Vout across p to n; begin Vout == gain * Vin; end oneD; What behavior do you expect? _B__ a: Acts as forward voltage-controlled voltage source (Vin is input and Vout is output) or (in@V is input and out@V is output) b: Acts as reversed voltage-controlled voltage source (Vin is output and Vout is input) or (in@V is output and out@V is input). c: Flawed description that cannot work. 1e: ----------------------------------------- architecture oneE of vcvs is quantity Vin across Iin through ps to ns; quantity Vout across Iout through p to n; begin Vout == gain * Vin; Iin == 0; end oneE; What behavior do you expect? _A__ a: Acts as forward voltage-controlled voltage source (Vin is input and Vout is output) or (in@V is input and out@V is output) b: Acts as reversed voltage-controlled voltage source (Vin is output and Vout is input) or (in@V is output and out@V is input). c: Flawed description that cannot work. 1f: ----------------------------------------- architecture oneF of vcvs is quantity Vin across Iin through ps to ns; quantity Vout across p to n; begin Vout == gain * Vin; Iin == 0; end oneF; What behavior do you expect? _C__ a: Acts as forward voltage-controlled voltage source (Vin is input and Vout is output) or (in@V is input and out@V is output) b: Acts as reversed voltage-controlled voltage source (Vin is output and Vout is input) or (in@V is output and out@V is input). c: Flawed description that cannot work. 1g: ----------------------------------------- architecture oneG of vcvs is quantity Vin across Iin through ps to ns; quantity Vout across Iout through p to n; begin Vout == gain * Vin; Iin == 0; end oneG; What behavior do you expect? _A__ a: Acts as forward voltage-controlled voltage source (Vin is input and Vout is output) or (in@V is input and out@V is output) b: Acts as reversed voltage-controlled voltage source (Vin is output and Vout is input) or (in@V is output and out@V is input). c: Flawed description that cannot work. 2a: ----------------------------------------- architecture twoA of vcvs is branch in :electrical from ps to ns; branch out:electrical from p to n; begin out@V <- gain * in@V; end twoA; What behavior do you expect? _A__ a: Acts as forward voltage-controlled voltage source (Vin is input and Vout is output) or (in@V is input and out@V is output) b: Acts as reversed voltage-controlled voltage source (Vin is output and Vout is input) or (in@V is output and out@V is input). c: Flawed description that cannot work. 2b: ----------------------------------------- architecture twoB of vcvs is branch in :electrical from ps to ns; branch out:electrical from p to n; begin in@V <- gain * out@V; end twoB; What behavior do you expect? _B__ a: Acts as forward voltage-controlled voltage source (Vin is input and Vout is output) or (in@V is input and out@V is output) b: Acts as reversed voltage-controlled voltage source (Vin is output and Vout is input) or (in@V is output and out@V is input). c: Flawed description that cannot work. From 1076-1-request@sicmail.epfl.ch Thu Jun 29 13:24:44 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Thu, 29 Jun 95 13:24:42 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Thu, 29 Jun 95 13:24:38 -0400 Received: from mailgate.Cadence.COM by sicmail.epfl.ch with SMTP (PP) id <00850-0@sicmail.epfl.ch>; Thu, 29 Jun 1995 18:53:32 +0200 Received: (from smap@localhost) by mailgate.Cadence.COM (8.6.8/8.6.8) id JAA05734 for <1076-1@epfl.ch>; Thu, 29 Jun 1995 09:53:23 -0700 Received: from cds8200.cadence.com(158.140.24.155) by mailgate.cadence.com via smap (V1.0mjr) id sma005720; Thu Jun 29 09:53:07 1995 Received: (from trihy@localhost) by cds8200.Cadence.COM (8.6.8/8.6.8) id JAA24196; Thu, 29 Jun 1995 09:53:05 -0700 Date: Thu, 29 Jun 1995 09:53:05 -0700 From: Richard Trihy Message-Id: <199506291653.JAA24196@cds8200.Cadence.COM> To: 1076-1@epfl.ch Subject: Question on survey 1-3, LAT equation formulation Some clarifications, * We will send the correct answers to the examples to the reflector later. * vhdla@cadence.com is NOT an alias for the 1076.1 reflector. Send your replies to either or both. Richard From 1076-1-request@sicmail.epfl.ch Thu Jun 29 13:26:22 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Thu, 29 Jun 95 13:26:15 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Thu, 29 Jun 95 13:26:07 -0400 Received: from clsi.columbia.compass-da.com by sicmail.epfl.ch with SMTP (PP) id <04195-0@sicmail.epfl.ch>; Thu, 29 Jun 1995 19:16:32 +0200 Received: from adhara.columbia.compass-da.com (adhara [162.17.30.14]) by clsi.columbia.compass-da.com (8.6.12/8.6.9) with ESMTP id MAA04965 for <1076-1@epfl.ch>; Thu, 29 Jun 1995 12:34:44 -0400 From: Peter Liebmann Reply-To: peterl@compass-da.com Received: (peterl@localhost) by adhara.columbia.compass-da.com (8.6.9/8.6.9) id MAA00735 for 1076-1@epfl.ch; Thu, 29 Jun 1995 12:34:45 -0400 Date: Thu, 29 Jun 1995 12:34:45 -0400 Message-Id: <199506291634.MAA00735@adhara.columbia.compass-da.com> To: 1076-1@epfl.ch Subject: RE: VHDL-A survay Voltage-Controlled-Voltage Source and Current-Controlled-Current Source COMMENTS: 2a and b describe 4 branches but have only 2 equations to describe them. The number of equations must = the number of branches in a design entity (see my comments in the first survay). It is also noted, as with any circuit with ideal components, that there may not be a solution although the description is correct. For example, one may describe a voltage controlled voltage source between nodes 1 and 2 controlled by 3 and 4 in one entity and in another entity add two voltage sources, one between 1 and 2 and one between 3 and 4 which violates the condition on the VCCS (i.e. creating a voltage loop which contradicts KVL). Again, as in the first survay, I fail to see what will be accomplished with these questions since they can all be answered with the simple fact that an equation must be defined for each branch. (NOTE: it really does not matter which equation is associated with which branch since the results will be identical if there is a solution - it may cause instability in a matrix solution, but that is another story). I would rather see questions focusing on semantic rules which a designer has to learn to write VHDL-A. -------------------------------------------------------------------- entity cs is generic( gain : real ); port( Terminal p1, n1, p2, n2, ps1, ns1, ps2, ns2 : electrical); end cs; 1a: ----------------------------------------- architecture oneA of cs is quantity Vin1 across ps1 to ns1; quantity Vout1 across p1 to n1; quantity Iin2 through ps2 to ns2; quantity Iout2 through p2 to n2; begin Vout1 - gain * Vin1 == 0; Iout2 - gain * Iin2 == 0; end oneA; What behavior do you expect? __A_ a: Acts correctly as combination of voltage-controlled voltage source and current-controlled current source (forward or reversed). b: Flawed description that cannot work. 1b: ----------------------------------------- architecture oneB of cs is quantity Vin1 across ps1 to ns1; quantity Vout1 across p1 to n1; quantity Vin2 across Iin2 through ps2 to ns2; quantity Iout2 through p2 to n2; begin Vout1 - gain * Vin1 == 0; Iout2 - gain * Iin2 == 0; Vin2 == 0; end oneB; What behavior do you expect? _B__ a: Acts correctly as combination of voltage-controlled voltage source and current-controlled current source (forward or reversed). b: Flawed description that cannot work. 1c: ----------------------------------------- architecture oneC of cs is quantity Vin1 across ps1 to ns1; quantity Vout1 across Iout1 through p1 to n1; quantity Vin2 across Iin2 through ps2 to ns2; quantity Iout2 through p2 to n2; begin Vout1 - gain * Vin1 == 0; Iout2 - gain * Iin2 == 0; Vin2 == 0; end oneC; What behavior do you expect? _A__ a: Acts correctly as combination of voltage-controlled voltage source and current-controlled current source (forward or reversed). b: Flawed description that cannot work. 1d: ----------------------------------------- architecture oneD of cs is quantity Vin1 across ps1 to ns1; quantity Vout1 across p1 to n1; quantity Iin2 through ps2 to ns2; quantity Vout2 across Iout2 through p2 to n2; begin Vout1 - gain * Vin1 == 0; Iout2 - gain * Iin2 == 0; Vout2 == 0; end oneD; What behavior do you expect? _B__ a: Acts correctly as combination of voltage-controlled voltage source and current-controlled current source (forward or reversed). b: Flawed description that cannot work. 1e: ----------------------------------------- architecture oneE of cs is quantity Vin1 across Iin1 through ps1 to ns1; quantity Vout1 across p1 to n1; quantity Vin2 across Iin2 through ps2 to ns2; quantity Vout2 across Iout2 through p2 to n2; begin Vout1 - gain * Vin1 == 0; Iout2 - gain * Iin2 == 0; Vout2 == 0; end oneE; What behavior do you expect? _A__ a: Acts correctly as combination of voltage-controlled voltage source and current-controlled current source (forward or reversed). b: Flawed description that cannot work. 1f: ----------------------------------------- architecture oneF of cs is quantity Vin1 across Iin1 through ps1 to ns1; quantity Vout1 across Iout1 through p1 to n1; quantity Vin2 across Iin2 through ps2 to ns2; quantity Iout2 through p2 to n2; begin Vout1 - gain * Vin1 == 0; Iout2 - gain * Iin2 == 0; Vin2 == 0; end oneF; What behavior do you expect? __B_ a: Acts correctly as combination of voltage-controlled voltage source and current-controlled current source (forward or reversed). b: Flawed description that cannot work. 2a: ----------------------------------------- architecture twoA of cs is branch in1 :electrical from ps1 to ns1; branch in2 :electrical from ps2 to ns2; branch out1:electrical from p1 to n1; branch out2:electrical from p2 to n2; begin out1@V <- gain * in1@V; out2@I <- gain * in2@I; end twoA; What behavior do you expect? __B_ a: Acts correctly as combination of voltage-controlled voltage source and current-controlled current source (forward or reversed). b: Flawed description that cannot work. 2b: ----------------------------------------- architecture twoB of cs is branch in1 :electrical from ps1 to ns1; branch in2 :electrical from ps2 to ns2; branch out1:electrical from p1 to n1; branch out2:electrical from p2 to n2; begin in1@V <- gain * out1@V; in2@I <- gain * out2@I; end twoB; What behavior do you expect? __B_ a: Acts correctly as combination of voltage-controlled voltage source and current-controlled current source (forward or reversed). b: Flawed description that cannot work. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ cut here ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ From 1076-1-request@sicmail.epfl.ch Thu Jun 29 17:46:18 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Thu, 29 Jun 95 17:46:16 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Thu, 29 Jun 95 17:46:11 -0400 Received: from newsgw.mentorg.com by sicmail.epfl.ch with SMTP (PP) id <10280-0@sicmail.epfl.ch>; Thu, 29 Jun 1995 23:16:55 +0200 Received: from wv.wv.mentorg.com by newsgw.mentorg.com (8.6.4/CF5.22R) id RAA25438; Thu, 29 Jun 1995 17:16:02 -0400 Received: from pdxml1.mentorg.com by wv.wv.mentorg.com (8.6.8.1/CF5.22R) id OAA07173; Thu, 29 Jun 1995 14:16:50 -0700 Message-Id: Date: 29 Jun 1995 14:09:28 -0800 From: Dan Damon Subject: Re: About the "survey".... To: "1076.1 reflector" <1076-1@epfl.ch> X-Mailer: Mail*Link SMTP/QM 3.0.0 Reply to: RE>About the "survey".... Jean-Michel: It seems to me that you are reacting rather harshly to Richard's surveys. Richard merely indicated that he thought there is a potential for misunderstanding in the way the current LDC white papers declare branches. The majority of the LDC agree that this potential for misunderstanding exists. If you look at the survey there is no bias in the questions that are asked. Richard did not inducate which answers are "right" and which are "wrong". I certainly would like to see the answers to the survey questions from members of the 1076.1 working group who are not intimately familiar with the white paper methodologies. The 1076.1 group represents a well educated, fairly representative group of engineers who will be using VHDL-A. If there is a serious potential for misunderstanding, it's better that we know about in now rather than later. Therefore, I'd like to urge 1076.1 members to answer survey questions as honestly and intelligently as possible. The compiled data will be very useful in defining what typical users will find confusing. I expect that Richard, or any other LDC member will provide answers to anyone who asks. --Dan Damon -------------------------------------- Date: 6/29/95 7:08 To: Dan Damon From: Jean-michel.Berge Received: by pdxml2.mentorg.com with SMTP;29 Jun 1995 06:21:05 U Received: from sicmail.epfl.ch by newsgw.mentorg.com (8.6.4/CF5.22R) id JAA15019; Thu, 29 Jun 1995 09:10:40 -0400 X400-Received: by mta sicmail.epfl.ch in /PRMD=switch/ADMD=arCom/C=ch/; Relayed; Thu, 29 Jun 1995 14:59:55 +0200 Date: Thu, 29 Jun 1995 14:59:55 +0200 X400-Originator: 1076-1-request@sicmail.epfl.ch X400-Recipients: non-disclosure:; X400-MTS-Identifier: [/PRMD=switch/ADMD=arCom/C=ch/;sicmail.ep.865:29.05.95.12.59.55] Priority: Non-Urgent DL-Expansion-History: 1076-1@epfl.ch ; Thu, 29 Jun 1995 14:59:49 +0200; From: "Jean-michel.Berge" Message-ID: To: analog_reflector <1076-1@epfl.ch> Subject: About the "survey".... X-Mailer: Mail*Link SMTP/MS 3.0.0 At its meeting two weeks ago the 1076.1 Language Design Committee (LDC) discussed two proposals that were submitted as alternatives to the work that had previously been approved by the Language Architecture Team (LAT) and sent to the reflector. One of the alternatives, which is closer to the LESs than the LAT approach, was presented by Serge Garcia Sabiro, the other one, which is loosely based on SpectreHDL, by Richard Trihy. Both alternatives are descriptions of ideas without firm semantics, but we did not expect this at this stage. There are many similarities between the LAT approach and the alternatives, but there are also differences. One of the differences has to do with the declaration of branches. The LDC agreed on a process to resolve this issue, by documenting the similarities and differences, discussing the issues by email within the LDC, and finally vote within the LDC in late July or early August. This process was approved by the meeting attendees with 12 votes in favor and Richard's vote against. Richard thought that the issue should be resolved at the next meeting in September, not through email. Nobody suggested during that discussion that this resolution should involve the Working Group at large, because the resolution of a language design issue cannot be a popularity contest. It also is not a democratic process, because too many issues have to fit together that cannot be looked at independently. Given the consensus within the LDC, the step taken by Richard Trihy, Dan Fitzpatrick and Ken Kundert to conduct a public survey on a small part of the language design is completely unexpected and counter productive. It is unfair because it picks out a single issue without providing context, and it suggests that language design can be done starting with some syntax and guessing what it should mean. This approach has been used unsuccessfully in the past, and it resulted in emotional discussions rather than technical ones. For about 9 months now the language design effort has been a top-down process, where semantics are defined before syntax. As a result the discussions have substance and are much less emotional, and we have made considerable progress, as demonstrated again at the Working Group meeting in San Jose. One of the attendees of the last LDC meeting actually pointed out (after having missed several LDC meetings) that he was pleased with the high technical level of the discussions. There will always be differences of opinion about details, because there are several ways of doing the same thing. The LDC has been working hard at investigating several solutions, but it is impractical to work out all of them in detail. This does not mean that we will get a bad language, it means that we will get a good language in a reasonable time frame. Even if we were given an infinite amount of time and resources it would be impossible to get the best language, because different people have different priorities. Language design is an exercise in consensus building, where many details have to be taken into consideration that all must work together in a coherent and consistent way. It seems that Richard Trihy, Dan Fitzpatrick and Ken Kundert have a strange idea about what team work is all about, and their lack of following the process agreed upon by consensus is stunning, particularly because Dan Fitzpatrick accused the 1076.1 leadership last fall of not following its processes. At that time he did not even bother to respond to the answer prepared by the Executive Committee. Jean-Michel Berge, Ernst Christen and Alain Vachoux 1076.1 Executive Committee From 1076-1-request@sicmail.epfl.ch Fri Jun 30 06:37:23 1995 Received: from vlsi.uwaterloo.ca by sun5.vlsi.uwaterloo.ca with SMTP id ; Fri, 30 Jun 95 06:37:20 -0400 Received: from sicmail.epfl.ch by vlsi.uwaterloo.ca with SMTP id ; Fri, 30 Jun 95 06:37:02 -0400 Received: from newsgw.mentorg.com by sicmail.epfl.ch with SMTP (PP) id <04787-0@sicmail.epfl.ch>; Fri, 30 Jun 1995 11:54:30 +0200 Received: from holland.ebv.mentorg.com by newsgw.mentorg.com (8.6.4/CF5.22R) id FAA01144; Fri, 30 Jun 1995 05:53:31 -0400 Received: from gbr.gbr.mentorg.com by holland.ebv.mentorg.com (8.6.4/CF5.23R) id LAA11486; Fri, 30 Jun 1995 11:54:17 +0200 Received: from ae106hpu.gbr.mentorg.com by gbr.gbr.mentorg.com (8.6.8.1/CF5.24H) id KAA19401; Fri, 30 Jun 1995 10:49:59 +0100 From: richard_wilton@MENTORG.COM (richard_wilton@mentorg.com) Received: by ae106hpu.gbr.mentorg.com (1.38.193.3/CF5.23L) id AA16133; Fri, 30 Jun 95 10:52:17 +0100 Date: Fri, 30 Jun 95 10:52:17 +0100 Message-Id: <9506301052.ZM16131@ae106hpu.gbr.mentorg.com> X-Mailer: Z-Mail (3.0.0 15dec93) To: 1076-1@epfl.ch Subject: Poll response 3 Cc: richard_wilton@gbr.MENTORG.COM Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 vvvvvvvvvvvvvvvvvvvvvvvvvvvv cut here vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv Voltage-Controlled-Voltage Source and Current-Controlled-Current Source You can send your response to vhdla@cadence.com (or to the reflector). If you are not a member of the LAT team, would you like to be involved in this decision (yes or no): COMMENTS: -------------------------------------------------------------------- entity cs is generic( gain : real ); port( Terminal p1, n1, p2, n2, ps1, ns1, ps2, ns2 : electrical); end cs; 1a: ----------------------------------------- architecture oneA of cs is quantity Vin1 across ps1 to ns1; quantity Vout1 across p1 to n1; quantity Iin2 through ps2 to ns2; quantity Iout2 through p2 to n2; begin Vout1 - gain * Vin1 == 0; Iout2 - gain * Iin2 == 0; end oneA; What behavior do you expect? _b__ a: Acts correctly as combination of voltage-controlled voltage source and current-controlled current source (forward or reversed). b: Flawed description that cannot work. 1b: ----------------------------------------- architecture oneB of cs is quantity Vin1 across ps1 to ns1; quantity Vout1 across p1 to n1; quantity Vin2 across Iin2 through ps2 to ns2; quantity Iout2 through p2 to n2; begin Vout1 - gain * Vin1 == 0; Iout2 - gain * Iin2 == 0; Vin2 == 0; end oneB; What behavior do you expect? __b_ a: Acts correctly as combination of voltage-controlled voltage source and current-controlled current source (forward or reversed). b: Flawed description that cannot work. 1c: ----------------------------------------- architecture oneC of cs is quantity Vin1 across ps1 to ns1; quantity Vout1 across Iout1 through p1 to n1; quantity Vin2 across Iin2 through ps2 to ns2; quantity Iout2 through p2 to n2; begin Vout1 - gain * Vin1 == 0; Iout2 - gain * Iin2 == 0; Vin2 == 0; end oneC; What behavior do you expect? _b__ a: Acts correctly as combination of voltage-controlled voltage source and current-controlled current source (forward or reversed). b: Flawed description that cannot work. 1d: ----------------------------------------- architecture oneD of cs is quantity Vin1 across ps1 to ns1; quantity Vout1 across p1 to n1; quantity Iin2 through ps2 to ns2; quantity Vout2 across Iout2 through p2 to n2; begin Vout1 - gain * Vin1 == 0; Iout2 - gain * Iin2 == 0; Vout2 == 0; end oneD; What behavior do you expect? __b_ a: Acts correctly as combination of voltage-controlled voltage source and current-controlled current source (forward or reversed). b: Flawed description that cannot work. 1e: ----------------------------------------- architecture oneE of cs is quantity Vin1 across Iin1 through ps1 to ns1; quantity Vout1 across p1 to n1; quantity Vin2 across Iin2 through ps2 to ns2; quantity Vout2 across Iout2 through p2 to n2; begin Vout1 - gain * Vin1 == 0; Iout2 - gain * Iin2 == 0; Vout2 == 0; end oneE; What behavior do you expect? b___ a: Acts correctly as combination of voltage-controlled voltage source and current-controlled current source (forward or reversed). b: Flawed description that cannot work. 1f: ----------------------------------------- architecture oneF of cs is quantity Vin1 across Iin1 through ps1 to ns1; quantity Vout1 across Iout1 through p1 to n1; quantity Vin2 across Iin2 through ps2 to ns2; quantity Iout2 through p2 to n2; begin Vout1 - gain * Vin1 == 0; Iout2 - gain * Iin2 == 0; Vin2 == 0; end oneF; What behavior do you expect? _b__ a: Acts correctly as combination of voltage-controlled voltage source and current-controlled current source (forward or reversed). b: Flawed description that cannot work. 2a: ----------------------------------------- architecture twoA of cs is branch in1 :electrical from ps1 to ns1; branch in2 :electrical from ps2 to ns2; branch out1:electrical from p1 to n1; branch out2:electrical from p2 to n2; begin out1@V <- gain * in1@V; out2@I <- gain * in2@I; end twoA; What behavior do you expect? _a__ a: Acts correctly as combination of voltage-controlled voltage source and current-controlled current source (forward or reversed). b: Flawed description that cannot work. 2b: ----------------------------------------- architecture twoB of cs is branch in1 :electrical from ps1 to ns1; branch in2 :electrical from ps2 to ns2; branch out1:electrical from p1 to n1; branch out2:electrical from p2 to n2; begin in1@V <- gain * out1@V; in2@I <- gain * out2@I; end twoB;