Phone Conference P1450.1 Working Doc Subgroup Thurs Aug 2, 10:00 am PDT --------------------------------------------- Attendees: ---------- Tony Taylor Greg Maston Doug Sprague Jason Doege Gregg Wilder Agenda ------ Agreed to by consensus: 1) Review Tony's latest p1450.1 [1] 2) L.3 addition from Tony [2] Documents discussed: -------------------- [1] p1450.1 proposal draft 0.96, distributed by Tony. [2] Tony's Annex L.3, additional complex scan example from Greg P1450.1 Discussions (doc [1]) ----------------------------- Doug asked about section 7, the changes to the STIL statement, and how other dotted standards are going to support this change. The current dot2 proposal has all the words of this section, with just the change of ext_name from Design to DCLevels. While replicating definitions across the standards is not ideal, the necessary information to define this change for each of these standards would require all the words here anyway to unambigously identify the affected statement - there is no duplicated definition given where the change in this statement occurs for these two efforts. Page 10 - new section on engr_expr, and "Type" of variables. The following section was added to this document: ---- Question: There is no way in STIL.0 to define the type of a variable except by implication by setting it to a value like 'Min=23ns' (see p94). I think that we need to add a new statement in the same block as Min,Typ,Max as follows: Type ; // all the types in table 3 plus real which is the default The following are valid expressions: '23.5ns + 1.5ns/2' // time expression 'wattage = 5v * 2ua' // where wattage is of type 'Watts' 'slewrate = 5v/ns' // where slewrate is of type 'Real' 'realvar = 5v', 'realvar = 5ma' // where realvar is of type 'Real' Whereas the following expressions are NOT valid: '23.5ns + 2'; 'wattage = 5v;' // where wattage is of type 'Watts' ---- Greg raised a concern about the reference to "valid expressions" - if this statement is used, "valid expressions" must be defined in the standard. After some discussion: a. Section 5.7 was agreed to be removed, b. with pertinent first paragraph info moved to real_expr section, and c. Greg will add to the recommendation document in dot-zero, to recommend the proper application of units as demonstrated in the examples above. Page 21 - integer values are optionally assigned to enums of type integer. Discussion centered about the notion of default value assignment for "integer enums", and the concern that different default value assignments (if we don't specify what the default assignment is) may result in different program behaviors. Greg identified that enums, while having a value, CANNOT actually "use" that value directly in expressions; you cannot compare an enum to an integer variable (even if it is an integer enum) - you can only compare and assign enum variables with enum value-names declared for that type of enum. The ONLY reason to allow assignment of actual integer values with integer enums is to allow multiple enums to equate to the same value, which is occassionally desired if two value-names are meant to be ambiguous (equivalent) to each other. However, any enum operation occurs through the enum value-name only and never to the value of that enum, at least for integer enums (wfc enums do allow the enum value to be assigned to signals - but that's it). It was identified that this issue needs clarification in section 5.8; additional words are required to identify the capabilities and restrictions of enum expressions. Greg took an AI to provide those words. For example, enum variables cannot be compared against non-enums; they can be compared against enum-value-names for that type or other enum variables of the same type only. Page 37 - Type file_type statement: request from Tony to put definitions from dot6 in here, with "user" extension mechanism. Greg argued that the user extension mechanism was just yet another way of working around the standard, is completely equivalent to the existing UserKeywords options, and redundant to capability already present. There is an issue that dot6 wants to define a limited set of values for this field (although with the user extension option), it was discussed whether dot1 should contain this list or dot6 should. Tony will add these types back in and see what sort of response he gets again. Page 71 - Current proposed Annex M: Example L.3 (doc [2]) is very similar to this, and a single example can serve both purposes. Greg took AI to extend the current L.3 to also contain a "multi-bit scan cell", and demonstrate using inheritance to support that definition for both redundancy-elimination for complex cells AND "multiple-cell" scan cell perspectives. New Business ------------ Doug would like a frame version of the doc to put the Else clause in, and work with the Merge/Unmerge information - a function definition and annex for description of the behavior. Reduced the request to identifying affected sections (and how substantially they are affected) first. Greg needs send the CompareSubstitute info to Tony. Next meeting Aug 16, 2001, same time. Meeting was adjourned at 11:15 PDT AIs ---------- miscellaneous changes as identified above. Mostly on Greg's plate.