(r1) 107611MmApr2810 < P10761

P10761 Web>ProjectsArea>ProjectInteg107611>MeetingMinutes107611>107611MmApr2810 (revision 1) (raw view)~~EditAttach~~
---++ IEEE P1076.1 Subcommittee on Integration of IEEE Std 1076.1.1 - April 28, 2010 8am PDT

%TOC%
---+++ Attendees
   * David Smith, champion
   * Peter Ashenden
   * Ernst Christen, note taker
   * Alain Vachoux
---+++ Agenda
   * Call to order
   * Approval of agenda
   * Review plan and refine
   * Discuss Requirements analysis steps and solicit volunteers
   * Next Meeting
   * AOB
   * Adjourn
---+++ 1. Call to order at 8am PDT

David opened the meeting and started presenting the [[%ATTACHURL%/1076.1.1_Integration_SC_-28_April_2010.pptx][meeting slides]]
---+++ 2. Approval of agenda

The agenda was discussed and there were no changes.
---+++ 3. Review plan and refine

The plan was reviewed in the slides and the only change was related to requirements including the delivery of a machine readable package containing the package definitions from the current 1076.1.1 standard plus any additions. The times were accepted as being general guidelines with the only real work related to the additional goal to handle "compatible" natues and types.
---+++ 4. Discuss Requirements analysis steps and solicit volunteers

General requirements are to integrate the 1076.1.1 standard into 1076.1. This includes:
   * Splitting description and package
   * Deliver packages as machine readable files
   * Insert description at appropriate places in the 1076.1 LRM. Normative text in clause 16, User Guide in Annex G. The fact that the 1076.1.1 LRM is written in MS Word will not pose major issues.

In addition to these general requirements there is a goal to address a problem arising from models being created that use different units for a physical dimension. The specific example given was a model using a thermal nature with Kelvin as across type and another using a nature that uses degrees C as across type. If Fahrenheit is also included we have to deal with scaling and offset. A question was raised whether representation of power in W and dBm should also be a requirement. This would require a more general mechanism to transform a value with one unit to the other. No decision was taken.

A brief review of quantity ports and their connection capabilities yielded that in the original 1076.1.1 effort the trade-off was whether the unit of physical quantities should be expressed by separate types or by subtypes of real. The second approach was taken because writing models when each quantity has a different type would be difficult. The drawback is that it is possible from the language perspective to connect a quantity formal port of subtype voltage with an actual of subtype rotational_velocity. It's caveat emptor.

An agreement was reached to focus on terminal ports, where different natures are incompatible. The discussion went on to explore ideas how a relationship between across and through quantities of different natures could be represented. Specifically:
   * Subtypes. Value range can be restricted (among other things), but no scaling of values is possible.
   * Approach similar to conversion functions. There are two issues: the reference must also be considered, and it is typically not part of a connection, and any functional approach is unidirectional, but we need simultaneity.
   * Attribute mechanism. Verilog uses attributes for some compatibility issues. This was not further explored.
   * Creation of physical real types, i.e. a class of types that has units like physical types but is not discrete, plus conversion functions. Unfortunately, if different physical quantities have different physical real types the same difficulty arises when writing models as was described above.
   * Link to mixed netlist project. There is some similarity in the sense that we want to define the semantics of a connection element where formal and actual are incompatible. The mixed netlist project has so far only considered the case when formal and actual belong to different object classes. This would be a new requirement.

It was observed that many aspects to deal with have some relationship to a dimensional analysis. During the initial definition of 1076.1 a white paper was written to investigate the feasibility of dimensional analysis in the context of the VHDL type system.
---+++ 5.Next Meeting

Wednesday May 26, 2010, 8am PDT.
---++++ Action Items:
   * Ernst - locate paper on dimensional analysis
   * David - develop scope with use cases
---+++ 6. AOB
---+++ 7. Adjourn

Meeting was adjourned at 9am PDT.
Attachments
I	Attachment	Action	Size	Date	Who	Comment
pptx	1076.1.1_Integration_SC_-28_April_2010.pptx	manage	52.0 K	2010-04-30 - 21:57	DavidSmith
Topic revision: r1 - 2016-01-22 - 17:56:30 - TWikiGuest
P10761