IEEE Std 1076.1.1 Working Group - Standard VHDL analog and mixed-signal extensions - packages for multiple energy domain support Meeting Minutes Date : 26th September 2002 Location : FDL 2002, Marseille, France Attendees ------------ Alan Mantooth mantooth@engr.uark.edu Peter Wilson prw@ecs.soton.ac.uk Ernst Christen ernst.christen@synopsys.com Alain Vachoux alain.vachoux@epfl.ch Richard Munden munden@acuson.com Francois Pecheux francois.pecheux@lip6.fr Joachim Haase joachim.haase@eas.ns.fhg.de Introduction and Update (AM) ------------------------------------- The working group has now been officially designated with the number 1076.1.1 and the name "Standard VHDL analog and mixed-signal extensions - packages for multiple energy domain support". The main outstanding activities include a real need for further input particularly with regard to optical, thermal and fluidic domains (especially micro- and bio-fluidics). The membership list was presented, with a note that the standard VHDL-AMS reflector will continue to be used for discussions. AV noted that we need to ensure that the ballot constituency is correct (i.e. the mix between academics, EDA and users is correct, and that there is no domination by a single vendor). AV also noted that membership of the IEEE standards committee is required to vote. The schedule was revisited, with the original dates clearly being unrealistic. The revised schedule was proposed as follows: Packages drafted and presented Summer 2001 Packages revised Sep 2001, Summer 2002 We are now in a "final" period of discussion, with the intention to set the mechanism up for a ballot in Spring 2003. Review of DAC 2002 Decisions --------------------------------------- Issues discussed at this meeting were as follows: The question of whether the packages should remain as separate files, or one single package was decided in favour of the status quo. MMF units (A or At) is to be checked and we will use the NIST unit. It was decided to split the constants in those that could be termed 'fundamental' constants e.g. ?0, and have a separate package for the 'material' or other constants whose value may change depending on the context or accuracy of the measurement. There will therefore be two new packages called fundamental.vhd and materials.vhd (or some similar naming convention) With regard to the materials package, the package body is there to define the constant names, but the values MUST be left out, this makes the definitions deferred constants that can be overwritten by the user. This was to be discussed further. If a value was defined explicitly, then the package needs to be overwritten. It was noted that this needs to be built into the software, if the deferred method was not to be used. For this reason, a query was raised as to whether a package of constants that needed to be overwritten or had 'questionable' values as defaults should be part of a standard. EC stated that he would investigate this further. Open Issues --------------- Fluidic systems. Comments from reviewers have stated that the current definitions are fine for hydraulic systems, but not necessarily for bio- or micro- fluidic systems. Potential contacts were mooted including Darrell T and Richard Freyer (?). The thermal and optical packages require attention. MMF Units - Action AM to check NIST definition Global Temperature An important issue that was raised was that of the global circuit temperature, such as that used in SPICE. EC proposed using a constant defined in the materials package as a deferred constant. Action is required (EC?) to define a name for this environmental temperature. It was noted in relation to this issue (and others), that if a constant is changed (e.g. TEMP), that the package must be recompiled, however, that an implementation could be smart and recognize this, and thereby only change the value. This is essentially a tool issue, but the standard does not impinge on the ability of users and vendors to be clever with their use of these constants. Thus, if deferred constants are to be handled in a different way by the tools, then that is a matter for the vendors (EC). PW raised the issue of hierarchy of temperature, i.e. different environmental temperatures in different areas of the design, EC stated that this was supported using the deferred constant approach. AM noted that a thermal subsystem can be connected, and that this does not impact either way. It was also noted that the scooping protects the assignment of temperature variables. The recommendation of the group was that environmental constants, such as temp or sea level pressure etc, could be usefully defined in name only as deferred constants in the 'materials' package. Action AM to out this out on the email. Types in Array Natures JH noted an apparent inconsistency with the use and definition of array natures, i.e. should they be defined as across quantities or as real vectors ? EC noted the typing rules in VHDL, with the key point being should an array of, say, voltages be defined using the electrical vector ? ELECRICAL_VECTOR'across or REAL_VECTOR Action EC - EC noted that he knew the resolution to this and a complete explanation but he would have to look it up. The related issue to this was whether vectors or R,L and C should be defined as subtypes or should it only be types that could normally change in a simulation, e.g. Q, Flux etc AM noted that for consistency it made sense to include them. Some discussion about the definition of the subtypes took place with AV & EC noting that mixing subtypes is OK, but EC also noted that ELECRICAL_VECTOR'across is not the same as a REAL_VECTOR, but has implications relating to the nature. Units AM stated that all units would use the NIST definition and capitalized if named after an individual (e.g. Coulomb or Ohm). Thus ohm needs to be changed to Ohm (Action AM) Reference in Vectors A question was raised about whether is was necessary to have vectors of references, but EC noted that there was no need, as although the vector applies to the through and across variables of a nature, it does not imply a vector of references. Units & Symbols EC noted that the unit is actually what we call the symbol. Symbol should be the abbreviated version. The question was, do we need both ? After discussion it was agreed that we should have both and AM took an action to modify the current packages to reflect this, e.g. in energy systems : Attribute UNIT Ampere Attribute SYMBOL A Discussion of Draft packages ----------------------------------- Energy_systems Action AM to cut out common scaling factors (now in fundamentals) Action AM to revise UNIT and SYMBOL definitions The question was asked whether we need this package at all, and perhaps could move into the fundamentals package Action AM need to change the use clauses EC noted that the MATH_REAL reference is not required where the constants have been removed. Mechanical Action AM - to check all the units are correct The question was raised, do tolerances make sense on constants e.g. mass Fundamental Use a standard prefix, the options mooted included PHYS, or FUND. It was agreed that PHYS would be appropriate. EC proposed that we use the same prefix whether the constant is deferred or not for consistency. Action AM - to check values with latest NIST info Action AM - typo DENCI -> DECI Also need to alias DEKI and DECI Materials Action AM - Add the permitivitty of Germanium Action AM - Add PHYS_ prefix Thermal Much more review is required Fluidic OK for hydraulics, but not necessarily for bio- & micro-fluidics Radiant Candela and lumen names ? Action PW to talk to the opto-electronics and photonics groups at Southampton for their thoughts PW also noted that photovoltaic people use Irradiance in W/m2 Vice-Chair ------------- AM proposed that PW take on the Vice chair role to assist, and also be the European contact for this WG. Next Meeting ----------------- Location: DATE 2003 (Munich), March 2003 Advance Notice of further tasks : To define the balloting strategy EC noted that the balloting process takes 2-3months, that the affiliations and contacts of the constituency must be kept up to date, and that the balloting process itself should be understood to ensure easy progress. There must be a balance between users, industry and academia. Meeting Closed.