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