Phone Conference P1450.1 Working Doc Subgroup Thurs July 5, 10:00 am PDT --------------------------------------------- Attendees: ---------- Tony Taylor Greg Maston Jason Doege Peter Wohl Agenda ------ Agreed to by consensus: 1) Review Tony's latest p1450.1 [1] 2) flow into Tony's Variables annexes addition [2]. Documents discussed: -------------------- [1] p1450.1 proposal, dated Jun 23, 2001, distributed by Tony. [2] Tony's Annex_X_Y, additional variable examples for dot1 annexes. P1450.1 Discussions (doc [1]) ----------------------------- Section 4: new item that came up in a .6 discussion. Bodily move the definitions present in 1450.0 section 4 into this section, to eliminate confusion on the constructs used in this document. These definitons should be local to this doc; they should be consistant with dot0 but defined here. Section 5.4, end of second paragraph: currently states that Variables etc. cannot have names matching Signals. Proposal is to make namespace handling the same as SignalGroups (since names are found in here). Greg to reword this last sentence and section in Table 5 pertinent to this construct, to allow named-block names to override. Section 5.5, question about the interpretation of true/false. Tony to move the 3rd paragraph and parts of the second paragraph where boolean behavior is defined, of section 5.10 to here. Table 4: Reduction-ops still present, Tony will eliminate those rows. Move Table 3 and 4 to new section after all the *_expr, since these operators are shared across all the expression types (shared at least as defined in these tables). Section 10.2, example: question from Tony - do Enumerations need a Length? How do we define the length? Greg's response: the length is an attribute of the WFC-assignment construct, ie "grab = \l6 FF; " (that's an "ell-6"), and not an attribute of the Enum. If we add a Length option to the enum it would only behave as a compile/parse-time check of the enum values and Greg doesn't feel that is much value-added to customers. After some more arguments from Greg, this issue was tabled for subsequent resolution. Section 11.5 and 16.1 - strikeout text (and gm's red comments) were resolved in prior meetings and will be removed from this document. Section 13.2: Tony to complete this example with SignalGroup block definition and also move this to a new annex (or part of Annex B?). Annex I: Tony to reword the second paragraph so that it does not bind the flow working group to a specific implementation. Annex K, second example: Tony raised an issue with Figure 5, wondering if the master needs a path to the scanout, since the complex information indicates that this path exists. Greg elaborated that the "path" described by the complex information, is a path created by a clocking construct through the slave and that there is no direct path (other than through the slave) to the scanout... but that this clocking construct was not apparent in the diagram (but related intimately to the 'scanmode' interpretation as well). No change to this diagram was defined. Jason raised an issue with the complex scan data - if many cells have this same information, it is redundant to repeat this same data. Greg believes that the hierachical scancell construct (InheritScanStructures) can be used here to define this data once for a cell architecture, and took the action item to draft this example and send it around for review/consideration. Tony's Additional Annex X and Y Document [2]: --------------------------------------------- Discussion about the semantics of differing-data-lengths for the Loop Data construct. Greg established that the text right now indicates that the "shortest amount of data terminates the loop". Tony is concerned about losing data. Alternatives were proposed: 1. that the shorter data take on the last-value-defined-outside-the-loop (which matches Shift behavior with padding), or 2. the shorter data maintains the last argument value (which matches general incremental-data behavior for Vectors in STIL). Because these two options are very different yet each has a logical basis in the language, this group decided to add to the semantic defintion of Loop Data: - different-length arguments to '#' parameters in the Loop Data are an ERROR. Integer Base construct: There was a long discussion on the meaning of a "Base Hex" on an Integer. Greg identified that attempting to map WFCs with an Integer, using only Integer defintitions, is inconsistant with the current language (which maps the WFCs through the group definition). Also, if the Base of an Integer implies expression operations, there are now two types of expressions - decimal_integer, and hex_integer, and the value of the expression "A = B + 99;" is not apparent without either defining additional constructs on constants AND "+" operations in both decimal and hex math. - Also note that Greg went to some length (well, one sentence) in the declaration of SignalGroups, section 10.1, under the definition of the Base statement - to NOT ALLOW Integers to be Based (only enums and SignalVars... although they weren't called SignalVars when he wrote that one sentence). Greg emphasized that if integers were used in WFC-assignments, they need to follow the same semantics currently defined for WFC-assignments, for example (following Annex X); SignalGroups { grp_a = 'abus[1..8]' { Base Hex DU; } // Base on the Signal h1 Integer // { Base Hex LH; } No Base on Int } MacroDefs { mdata { C { h1 = #; h2 = #; } V { grp_a = 'h1'; } } } - As defined in the current standard, the value of 'h1' is now interpreted to be a "hex value" in the context of grp_a, and mapped to WFC characters based on the default grp_a defintion. It should be noted that it doesn't matter whether this Integer is "decimal" or "hex" because the value is still the same -- and it is the value that is being mapped. NOW, there are still open issues about how to assign a VALUE to an INTEGER that is meant to be a hex-based value. Greg is of the opinion that Integer expressions should all be "decimal", and that hex-values should really be used through SignalVars only. If this is not the case, then STIL needs to define constructs for hex-based constants and decimal-based constants, as well as expression semantics for each type of expression. This issue was tabled here for this meeting. Greg identified that the Loop 'logical_expr' construct used in Annex X needs to be defined in the standard. Right now Loops support integer values or the Data option only, and logical_expressions would be an error unless this construct is added. Jason raised a question about the the overhead/time of performing expression evaluations. When expressions are present in C statements, it takes real (elapsed) time to execute the statement, yet the C statement is meant to operate as a zero-time ("nostep") operation. Is there an identifed or permissible amount of time to allow this to execute? Tony pointed out the scope of this effort is in design environments, where the "time" is an external attribute and it's possible to not advance the time during a C statement. Applying these constructs outside of this domain needs to be considered and is an issue but is officially outside the scope of this effort. New Business ------------ Section 17 of [1]: Peter mentioned that this section needs to be updated. Commas need to be added to the integer_lists in the examples. Table 2 needs to have the comma added as an additional reserved character in STIL as well. Peter asked about the CompareExpect. Greg took an action item to write-up the doc additions and mail to Tony. Jason indicated that Rick Dokken and Don Organ would be interested in participating in the (now fairly dormant) dot4 and dot5 working groups. Tony will send them the latest information on these standards. Next meeting July 19, 2001, same time. Meeting was adjourned at 11:40 PDT AIs ---------- miscellaneous changes as identified above.