Attendees:

Tony Taylor (chair)
Greg Maston (scribe)
John Cosley
Bruce Kaufmann
Dave Dowding
Jose Santiago

Discussion:

Dot1 status
On it's way to revcom.

John raised concern about different rules in different dots - specifically different formats of time expressions. Greg identified that the *goal* of any extension is to continue to support the original context (to be backwards-compatible), which allows parsers to develop in a single direction, and at their discretion to be sufficiently
"paranoid" as to not allow an extension syntax out-of-context, but that to a large extent this is really an incoming STIL file restriction that if not obeyed only means that the header inadequately defined the contents - worthy of a warning, but perhaps not even a full error.

Dot3
The following bullets of issues with the current spec were presented:

- Review Greg's memory checks proposal
- Bruce offered to do a more complete review
- Pin-channel mapping issues to discuss
- Tony will remove tics in expressions per dot1 parsing rules
- Tony will change table 4 for more relaxed keyword constraints
- John identified some cross-refs to dot1 are incorrect
- Spec needs examples & completeness work. For instance a list of
  the common elements across different usage models helpful.
- Dan's (and Greg's) issues with fluid rules

Bruce identified a concern about calculating memory usage. Memory usage can be dependent on the failure mode that the test is being run under, for instance a "run to first failure" mode requires different memory availability than a mode that "collects all failure data". How does one define memory runs when they are dependent on the type of
test and that isn't known until load-time?

The current TRC usage model is that given a STIL program, you run against all TRC blocks, and there may be multiple TRC blocks. It's possible to define the two different memory environments above as separate TRC blocks (assuming the memory constraint definitions are sufficiently robust), and to generate a TRC-block-specific error if a
test program violates one, but not all, of the blocks. This allows the checking process to identify, for example, that the "collect all failure data" mode might not be usable for a particular STIL test but the "run to first failure" mode works.

memory proposal

Concern in section 3.1, specifically about nested loops. What happens if an environment counts the first loop level one way, but subsequent nested levels are counted differently? For instance, an environment only implements support for one level of loop, but the nested loops are handled by flattening the loops.

This is an example of a statement 'sub-behavior', a behavior where the context of the statement is necessary to properly interpret the memory consumption of that statement. Currently the document does not support differentiating memory counts based on the context of the statement as well as the statement itself, but it is expected this will be necessary to address this type of problem.

Discussed the issue with relating signals to "types" such as clock/data/in/out. While these types are present in the current dot3 spec, there is not an identification of how to relate a signal in STIL to any of these types. The memory spec presents one notion of how to identify signals, concerns were raised specifically with the definition of "clock".

It was identified that dot6 contains attributes on signals, and there is a possibility to extract this data if a CTL definition of the dut is available. It is still an open issue of how to do this if no CTL is present.

There are concerns that this memory counting proposal is too architecture-specific. Which it may well be, and it needs to be evaluated in that context with other memory consumption models.

There is a concern about how to handle expressions that contain a number of signals, along several lines: (1) how do you write an expression that references a number of 'some type' of signal; (2) how do you collect signals under 'some type', and (3) how do you partition all the signals up into these types - do they partition uniquely or can a signal be accounted for under multiple sets?

There is a concern that CHANGES to the linear sequence of operation will affect how memory is consumed. For instance, in-line Vectors after a Loop statement might require an initial consumption to start the sequencer up again. In this case, it's not just the presence of a STIL statement, but actually what the next statement is after this operation (this wouldn't happen, for instance, if the next statement was another Loop because the sequencer count would have been counted for that statement).

There was some discussion about modulus effects, which Greg is certain are not fully covered either. For instance, related to the changes of linear sequence issues above, if a context requires re-alignment after an operation but that alignment is dependent on the next behavior.

Concern about shift counts, Current spec defines that the longest chain (or longest data) affects all data for that shift. Different contexts might be dependent only on the total amount of data across all chains in the shift. This isn't supported today.

Jose raised a concern about what is required to be defined vs. what are optional behaviors, needs to be delineated clearly.

Tony requested that when Greg re-works this proposal, that he organize it to match the standard - i.e., which clauses and annexes should the new stuff go into. Greg: shouldn't be a major problem although because syntax is distributed, the examples probably end up as an annex.
 

Other
There was brief talk about changing the start time of this meeting to earlier, to allow European participation. This was tabled pending European interest.

 

Next meeting

Date: Next meeting Thursday, May 5
Time: 10:00 to 11:30 Pacific
Dial-in#: 888-635-9997
Participant code: 539645

Action Items:

AI-1: Greg -  update spec for "extended memory counting"

AI-2: Bruce - create TRC for the Teseda tester using the D09 draft

AI-3: Tony - address issues listed in "Dot3", above