STIL Dotted Extensions P1450.1, P1450.2 Working Group ----------------------------------------------------- August 10-11, IBM office in Portland, Maine The STIL Working Group thanks IBM for hosting the Working Group at their Portland Maine office. Participants ------------ Doug Sprague - dsprague@btv.ibm.com Greg Maston - greg_maston@fluence.com Ernie Wahl - ejwahl@lucent.com Gregg Wilder - gwilder@dal.asp.ti.com Tony Taylor - tonyt@synopsys.com Peter Wohl - wohl@together.net Working Documents: ------------------ The following documents were referenced in this meeting: [Doc1] Tony's current document for P1450.1 [Doc2] Gregg's current document for P1450.2 [Doc3] Greg's current clarification document for 1450.0 [Doc4] Greg's section of the P1450.1 document All documents were emailed to participants before the meeting, hard copies were available at the meeting for those who had been on vacation before coming here (and would be going back on vacation after this meeting). Agenda ------ Discussed breakdown of effort for this meeting; partitioning of effort between .1 and .2, presentation of new material, and finally presentation of current doc status. Proposed Agenda: ---------------- 1. resolve any remaining technical issues with 1450.0 supplement 2. resolve any remaining technical issues with 1450.1 extension 3. review the latest definition for 1450.2 extension 4. work on the 1450.0 and 1450.1 documents 5. plan for moving the 1450.0 and 1450.1 to completion and ballot 6. plan for finishing up 1450.2 7. what about the other extensions? 8. what about a meeting at ITC? Working Agenda: --------------- Dot0 - 1 hour overview/review - review dot0 clarifications - doug questions about mixing bases Dot1 - 1 hour overview/review - peter proposal to add "partial STIL" identifier - tony "UserParameter" proposal Dot2 - 1 hour overview/review Next Meeting/ITC efforts - 1 hour Dot0 [Doc3] ---- Proposal by Greg to add two docs to the web, a clarification doc and a recommendations doc. Because these two contexts are handled separately by the IEEE,if we conform to their constraints now we'll simplify the integration of these things. Request was made to change the references in this doc from week number to date. Greg took [AI8] to do this. Mixing bases ------------ Discussed briefly that the presented issue is not supported by the current standard; cannot define a "mixed base", groups do not carry-over base definitions from earlier declarations, and "groups on-the-fly" only have default attribute definitions. - Greg may need to add a clarification about default bases for expressions on-th-fly...? This is [AI3]. Dot1 [Doc1] ---- Issue was raised about the style of the document, placing the tutorial infront of the syntax. Proposal is to make this document ordered different - some discussion about the options here; proposal to put everything on one construct, in one place. Cannot put informative info in the normative section... so discussion to move the "tutorial" back in this document as an annex, and opened discussion about collecting aspects of one construct across all different blocks, into one place. Took our first break at 10:50-11:05 Greg raised a question about how to maintain relationship of changes here with the 1450 doc; Tony proposed rather than using same section numbering, to use a reference to the affected section of the 1450.0 doc so this document does not have an implicit relationship with that document. Restarted with gregs working doc [Doc4]. STIL statement -------------- talked about the generality of the STIL statement, and affecting other standards...how to open this up to allow "more" contexts without causing problems. Changed the Extension statement in the STIL block to remove the keyword Extension and allow any statement in the STIL block (without needing to pre-define that as a userkeyword before the STIL statement). Peter's Partial STIL indication issue: discussed the perspective of indicating in the STIL file that it is either (a) incomplete for some set of STIL information contained here, or (b) complete for some subset of STIL information. This point was resolved in this working group, when Peter decided that the ability to present undefined user statements in the STIL statement supports his concept to identify the containing information. Concern that the STIL version statement indicates the ability to add new keywords (defined in a different standard) as part of that STIL environment. Presence of an unknown or unsupported undefined unkeyword means that this STIL context may contain unexpected constructs that the environment cannot properly handle. "If there is an unrecognized keyword here, don't know that you can read the rest of the file". Discussion on the Scope of the STIL statement: does the scope of the set of STIL versions, continue past STIL file boundaries (flow into subsequent files? flow back from included files?) Does the parser need to know upfront, (therefore REQUIRE that the first STIL statement) identify ALL subsequent versions? Resolution that the STIL statement is FILE-BOUND; the scope of the version statement is for THAT FILE ONLY; each included file must specify it's own set of versions as appropriate and necessary for the contents of that file. UserKeywords ------------ minor wording changes to the proposal, no concept changes. UserParameters statement (unwritten proposal by Tony representing a request from the P1500 working group)) ------------------------ Discussion about the notion of a "UserParameters" statement, that allows the set of parameters defined on a statement to be extended (like a UserKeyword statement)... Concern raised by Peter that a generic extension would affect very low levels of parse operations -- for instance, extending the Signals type would have significant processing penalty. Proposal by Doug to limit the context of UserParameters. Purpose of this construct is to eliminate statements that contain "user defined" fields, to be able to check the set of information (particularly spelling...). The Working Group is floundering between rigorous checking (no user-extensions) and totally free-"form" (userkeyword contents), and we had a long digression on the pros and cons of each side of this arena, and how far we go in either direction. Decision on the statements contained in the filereference block, to remove the defined types in this document, and make the parameters user-extensible only and move the list of types in this document into a recommendation section. Decisions here: 1. The Working Group recommends that parameter extensions not be user-specfic, but rather where needed, they are user-defined (as opposed to defined statements that ARE MEANT TO BE specific). 2. Unresolved references will be detected in the context that they are used in. It is not necessary OR APPROPRIATE for the language to protect the user/tool. the Working Group fell apart for lunch at 1:10 pm and returned at 2:50 pm Discussed an issue with the environment_defined_statements... how to indicate that these statements are meant to be defined in some other document, and furthermore that the keywords here are meant to be defined in some source associated with a version statement in the STIL version block... worked through an "expected to be" reference to the STIL version in that statement to please Greg who really complained about the "shall". PatternBurst extensions ----------------------- ...review and edit but no new constructs [AI4] Greg and Tony flesh out cross-reference of ALL syntax across all STIL documents The paragraph after the patternburst syntax contains a "how to" definition. This should become a complete example... The syntax changes to the PatternBurst in the current working document is distributed across umpteen sections. The following changes are needed: 1. All syntax needs to be coalesced to one section 2. Constructs part of the PatList in 1450.0 need to be added to PatSet and ParallelPatList. 3. Additional statements in PatSet and ParallelPatList (conditional If and While) need to be added to a PatList block... Moved data around to: (1) bring all PatternBurst blocks together (2) move the pattern-statement changes together Everyone to consider what should be defined (what type of constructs and operatrors to suppport) in the 'conditional_expression' or unitless_expression construct, to define what needs to be added to the document. Peter took [AI5] to generate this information for the group. \m,\j constructs ---------------- Minor edits around here. Greg raised a concern that this section affects multiple 1450.0 clauses, and is distributed. Greg reserved some subsequent discussion on the \j construct as well. Fixed,Equiv constructs ---------------------- Need to move this section into the common pattern-statement-changes section of the final document. Peter moved some "motivation" description to strike-out text. Scanstructures -------------- reorganized to collect the additions to one place. This completed the syntax review for this meeting. The effort expired on the first day at 6:23 pm. Next day: --------- Join statement - Greg argued vehemently against the \j. Peter agreed to review the use of this construct. Escaped quote proposal - talked about the effect of defining an escape option in the STIL string option. Identified the PROBLEM, and will add a clarification note that this is a problem (with no fix). Greg got AI to do this [AI6] as part of the clarification doc. Fail feedback: -------------- After some minor reordering of data, the Working Group realized that they completely confused themselves with the fact that the X statement may really appear in two different contexts, and it is necessary when interpreting this statement to know which context is being used. Therefore: (1) need to identify that the X statement is used in two files - a source vector file and a "reference file". (2) need to identify that the X in the reference file is applied in context with the next V{} statement in that file. Doug took [AI7] to work on this, in addition to the following perspectives: .... Peter presented the following concept of usage for this xref: Pattern exp { X "pos1"; X "pos3"; // these are location declarations V { ... } V { ... } V { ... } X "pos1" { Offset 4; } // this is a reference to a previous X decl. V { ... } After much discussion, the following additional resolutions were made: (3) Change "Offset" to "VectorCount", to refer to the number of VECTORS after the label. (4) Extend "Loop" to indicate that it's count is the value of Any and All iterated constructs present around the current referenced Vector at that VectorCount location - Loop, Shift, While... Next Meeting: ------------- ITC, on Monday - 1 day, all day. Process and Timeline: --------------------- 8/12 - 8/25: organize and distribute .1 8/25 - 9/17: individual edits 9/17 - 10/1: coallesce and review .1 up to ITC meeting DCLevels - P1450.2 ------------------ Discussed the current proposal. Issues were discussed on the multiple DCLevels ad DCSequence statements... concern that there is very different reasons for multiple of each of these. Need to identify if the DCLevels can be specified multiple times on one pin, (across multiple named DCLevels blocks) or whether multiple DCLevels are used to define across all signals. The motivation of some members of the Working Group is to define all signals in a single DCLevels block. The DCSequence needs to be complete across the set of affected signals for each named sequence (unless you allow inherit)(how are sigref expressions resolved? where are group references resolved?). Question: how are group names resolved in these constructs? If at the pattern exec level, needs signalgroups references in here. Proposal of the Working Group is to remove the DCSequence (or set of DCSequences) from the PatternExec, and allow a higher level mechanism (the same mechanism used to select/order PatternExecs) to select the DCSequence to be used... Concern about the need to be able to change the levels for a set of vectors inside a Pattern. The current document applies levels across a PatternBurst, and supports intra-cycle changes, but does not provide a clean mechanism for changing levels uniformly across signals at a single point during pattern execution. The notion of a "levelset" was postulated, to be referenced inside a pattern, as one way of supporting this issue. Added a SignalGroups statement to the DCLevels and DCSequence block. Requested to remove all commas here --- STIL doesn't do commas. Reconstructed some statements to either make things optional - i.e., on the ForceHi statement, the dc_expr is either optional or not allowed (uses VHi value), need to add optional multiple constructs on the Connect and Disconnect. AIs...unfortunately not Artificial Intelligence... --- [AI1] Greg: add example of signalgroup name resolution to the clarification doc. [AI2] Greg: generate two documents - clarifications and recommendations [AI3] Greg: do we need a clarifying statement about attributes and groups on the fly? [AI4] Greg and Tony flesh out cross-reference of ALL syntax across all STIL documents [AI5] Peter will generate a section on unitless expressions. [AI6] Greg to add clarification about double-string problem. [AI7] Doug will rework the Fail feedback stuff [AI8] Greg to change references in clarifications doc from week number to date.