Minutes of IEEE DASC P1076.1.1 Meeting at DAC'02

Attendees:
Richard Shi   	University of Washington        shi@ee.washington.edu
Alan Mantooth	University of Arkansas  	mantooth@eng.uark.edu
Peter Schwarz   Fraunhofer Inst.   Dresden      Schwarz@eas.iis.fhg.de
Mark Zwolinski  Univ. of Southampton            mz@ecs.soton.ac.uk
Adam Morawiec   ECSI                            adam.Morawiec@ecsi.org
Peter Ashenden  Ashenden Designs                peter@ashenden.com.au
John Shields    Synopsys                        john.shields@synopsys.com
Paul Menchini   Menchini & Associates           mench@mench.com
Greg Peterson	University of Tennessee 	gdp@utk.edu


1. Meeting started at 2pm.
2. Alan presented an update on the status and schedule of the group.
3. Alan called the technical discussions on the following open issues:
a. packaging the packages 
i. combine all to one  (Peter Wilson, Mark Zwolinski)
1. disadvantages (maintanence)
2. advantages: easy to use; easy to ensure interoperability;
ii. why separate packages (Paul,...)?
1. Use names in the domain it likes; hard to please everyone.
2. Use electrical.all  or thermal.all (resistance..)
3. hard to ensure Interoperability 
4. Choose to use different packages for different applications (Paul Menchini) 
for emerging applications; hard to do it in one package.
iii. (John Sheilds):  what packages to include  (to support separate packages; 
maintainability by having people from different areas; addressing issues in 
their particular areas; 
iv. A motion to accept different packages (with the ideas of not overloading 
names; for example, thermal resistance and more issues) and interoperability 
issues
b. MMF units
i. Alan summarized the issues on MMF units.
ii. Discussions 
iii. Peter suggested investigating other standards on units. Paul mentioned 
there is no IEEE standard 100  (as a resource); go with IEEE recommendation 
(SCC14 responsible for IEEE 100).
iv. Action Item: Alan to contact SCC14 chair with the help from Paul
c. Remove material properties (e.g. permittivity of SiO2)
i. Alan summarized the issue: where it goes, numbers can be different 
dependent upon how it is extracted, etc.
ii. Paul suggested to have a standard name (deferred constant): to give a 
value at the package body (elaborated at the implementation);
iii. Greg re-stated that the users want to have their values;
iv. Paul: is there any issue or need to standardize the constant names? If 
they are not central (converters, interface...), users need to supply values. 
Then cannot go to IEEE standard.  The fundamental issue is there is a value 
to standardize the names. 
v. Maybe fundamental constant package (charge, etc...)
vi. Questions:     deferred constant packages can be changed by users; 
fundamental constant packages go to IEEE; 
vii. John: is there any significance of having a separate fundamental constant 
package?  (Paul and Mark) other folks may need to use it too; so a separate 
package would be reusable.
viii. Can put the fundamental constants in a package in lib IEEE - but not 
in the standard natures package - to allow use for VHDL & VHDL-AMS as well 
as for use in a physical constants package that would include deferred 
constants that users can provide with values.
ix. Would need a new library with a standard package with the names of 
deferred constants for physical constants.
x. All the prefixes such as mega, kilo, milli, etc. should be included in the 
fundamental packages.
d. Fluidic systems deemed inappropriate for biofluidics  - folks at CMU and 
Duke will help with this.
e. Thermal and radiant packages need attention - need someone for radiant 
packages - Mark Z. will help with lining up folks to check with this.
f. Check on the capitalization of units - check with Bruce.
g. Address thermal resistance, capacitance - invent thermal inductance
h. Why use MOMENT_I?  How about ANGULAR_ACCEL not spelled out?  Is there a 
magnetic moment?
i. MMOMENT_I type error
j. Why use TRANSLATIONAL_V instead of TRANSLATIONAL_VELOCITY?  Perhaps use an 
alias to let users use either spelling... (?)
k. FORCE_VECTOR is defined twice.  Need to create a FORCE_V_VECTOR for 
translational velocity.  Same thing with torque
l. Next meeting: FDL 2002 (Sept 24-27) in Marseille.