1. expression syntax

Tony reported on the meeting that was held on 12/1 and attended by Tony, Greg, and John. The last remaining issue with regard to the use of tics and parens was discussed. It was agreed to leave the syntax as currently defined in the document. The following is a summary of the conclusion and the rationalization.

 

The changes to expression in dot1 do represent a departure from the conventions established in dot0. However, moving to the use of parens makes for more robust parsing. The new rules address issues that were reported by several ballotters

1. tics are not as reliable a parens for parsing since it is not possible to differentiate between the leading and trailing tic

2. tic delimters should not be part of the expression and, hence, not required around all expressions

3. the expression syntax should be uniform across all types of expressions - integer, real, signal, boolean

 

Tony has the action item to present the new expression definition (clause 5) to the three ballotters who were the most concerned with this issue, in order to get their assessment before we begin the formal ballot re-circulation process.

2. pattern block examples

The changes to the pattern examples were explained. Doug agreed to review the changes to see if they are now adequate.

3. Feed back from Doug/Tom on the PatternFailReport

1) MINOR: For the the FailData block and the piece following the SIG_NAME,
   I think the first of the 3 statement formats should not have a
   vertical bar in front of it.
Decision: change accepted.

2) MINOR: Under (8) c) CYCLE_OFFSET...  There is a repeat of "the last"
   in the first sentence.

Decision: document to be corrected

3) Under (8) a) We are having a debate internally as to third sentence
   in there which says:  "Reference shall always be to an X statement
   encountered in the pattern execution sequence within the base pattern."
   The issue is that we have plans to use the PFR outside the scope of
   STIL with other legacy pattern formats.  This statement is absolutely
   correct in the context of a pure STIL environment, so I lean towards
   that being the right way to say it.  But when using the PFR with
   legacy pattern formats which don't have X statements, then that is where
   the gotcha is.  But again, I'm leaning towards keeping it as is assuming
   we are only trying to address a pure STIL environment here.  But I
   mention this so to bring it up to the group and get their take incase
   they have similar efforts and if they see this as an issue.

Decision: No change to be made to the document. It is fine for this syntax to be used to log fails from non-STIL patterns, however it is up to the application to define the semantics of such usage.

4) The PFR block has an optional REPORT_NAME but does not seem to be
   defined anywhere and there don't seem to be any rules which indicate
   if it has to be unique across all PFRs found in a stream/file.  Also,
   should multiple PFRs be allowed to have the same DeviceID?  I think
   the answer is yes but I throw it out there for the group.

Decision: The explanation for the PFR statement is to be enhanced to define the purpose of REPORT_NAME and what is allowed. After some discussion, it was agreed that the normal block rules should apply - i.e., only one un-named PFR block allowed; any number of named blocks, with all blocks in the file/stream having unique names.

4. clause 12.3 - pattern tiling

There wasn't much recollection of the previous discussion or why this issue was not resolved at that time. However, it was agreed that the new rule should be added, and that the diagram should be changed to shows the signal states to extend across pattern-burst boundaries. The new rule added to the document states:

The extend operation is in effect until a new pattern includes the extended signals or until the end of the outermost PatternBurst.

5. New issue from Denis on the use of Equiv statement

Greg presented the issue, having had discussion with Denis about it. The major issue stems from the wording in the original D18 version of the document with regard to WFCMap. The issue has been resolved by clarifying semantic rules that are now in the D20 document. The new semantic requires that a WFCMap within a pattern burst, if it is used, is a function of the base signal (i.e., like Termination in dot0). No further change to the document is required.

6. Need for syntax to define a repeat clock

Tony brought up a new issue - how to specify a repeat clock in STIL? If the number of repeats fits neatly into the period then the sub-waveform syntax in dot0 can be used. If the frequencies do not match, things are more difficult. The only solution avail in the dot1 extensions is to use parallel-pat-list for the repeat clock.

Tony presented a possible enhancement (to dot0 or dot1) to allow something like \r* to mean to repeat a sub-waveform across multiple periods. Such a change would seriously affect the cyclized behavior of the language. It was agreed that this is not a good time to consider such a diversion. Our main goal at this time is to get dot1 back into the ballot cycle ASAP. No action identified.

Meeting ended at 11:05