Integration Subcommittee May 26, 2010 Meeting David W. Smith IEEE DASC P Working Group

Agenda Call to order Volunteer for minutes Approval of agenda Review and approve meetings from April 28 th meeting Review action items and any content provided from them Discussion Next Meeting AOB Adjourn 5/26/20102VHDL-AMS Integration

Action Items Ernst – Locate paper on dimensional analysis (David posted in group work area) David – develop scope with use cases 5/26/20103VHDL-AMS Integration

Scope has 3 items – Add into LRM (most of document becomes machine readable code and rest is simple textual description) – Review all definitions and comments against SI (normalize comments with SI10 standard) – Add support for compatible natures with quantities that are scaled and translated from SI units (remaining scope) 5/26/2010VHDL-AMS Integration4

Compatible Units SI units are used as the basis for all units in VHDL- AMS Quantities, Natures, and Terminals are defined with respect to these units ( define many of the physical domains) Engineers are not limited to SI in their work and still use units derived from SI. Examples are: – Centigrade or Fahrenheit for temperature – Inches, mils, cm for distance – Etc… 5/26/2010VHDL-AMS Integration5

Possible conversions Expressions in Simultaneous statements contain quantities that could be of different but derived units – mix of temperature in Kelvin and Fahrenheit. Actual port and formal port being terminals or quantities that have different but derived units – thermal defined in Centigrade for actual or formal and defined in Kelvin for other port (for terminals), similar for quantities 5/26/2010VHDL-AMS Integration6

Scope and Rational For expressions trying to handle the difference in units results in the need for units to be a part of the logic and to handle a unit algebra. The intent here is that all quantities used within an entity/architecture should be consistent and no check is done to see if they are. This is a natural consequence of all quantities are subtypes of real and equivalent. 5/26/2010VHDL-AMS Integration7

Scope and Rational (continued) Actual and formal port conversion is the case where the port is different in the architecture and its parent. Again, consistency within an architecture/entity is assumed to be reasonable and the only issue is using an entity defined with one set of ports but used in an architecture with a different, but compatible set of ports. Example is a thermal resistance modeled with temperature in Centigrade used in a thermal network that is defined in Kelvin. For port quantities there is no checking that the quantities are compatible since they are all subtypes of real. For port terminals the formal and actual subnatures must be the same (12.2.4). 5/26/2010VHDL-AMS Integration8

Scope and Rational (continued) The desired goal is to be able to check that the formal and actual quantities (for either a quantity or a terminal) are scaled and translated so that the value when used and referenced in the architecture containing the formal uses the units and values of the formal and when in the architecture containing the actual it uses the units and values of the actual. Example: – Architecture a1 of entity a has a terminal T defined as thermal_kelvin. It has connected to this terminal to entities (b and c with architectures b1 and c1 respectively). The port of entity b is defined as thermal_kelvin. The port of entity c is defined as thermal_centigrade. – The terminal T in a1 is always seen as being in kelvin. – The terminal connected from b1 is seen as kelvin in a1 and in b1. – The terminal connected from c1 is seen as kelvin in a1 but in centigrade in b1. What this means is that there is a scaling and translation of the temperature values to kelvin in a1. (or from kelvin in b1). The same discussion is appropriate if it is not a terminal but a free quantity in a1 and port quantities in b and c. 5/26/2010VHDL-AMS Integration9