Summary of Action Items

Summary of Decisions

Summary of Priorities for 1450A

Wednesday Meeting started at 10:00am

 Attendees:
 

Discussion of organization of the meeting:

• ITC Meeting Plans
• 1450 Ballot Issues
• Charter of 1450A
• Divide into three focus groups
• Team 1 Digital Pattern Completion
• Team 2 Tester Targeting
• Team 3 EDA and Test feedback & Design Stimulus
• STIL Parser

 
1. Discussion of meeting plans for ITC. IEEE P1500 has been formed for embedded core testing. Part of their charter is extensions to STIL. Want to involve this committee in the discussions of STIL.

2. 1450 Ballot Issues

3. Charter for 1450A "Extensions Committee"

It is proposed to break into functional groups to discuss the three groups. Tony will go through each of the groups, and try to define topics

It was decided that the group would remain together and review the issues as a body, rather than smaller groups.

• Levels: How many levels, vol/voh, how to define

The following diagram (or a variation of this diagram) was drawn to illustrate the need for different pattern exec domains, and how they would reference an "Environment Domain". The environment domain may be contain information for the conditions under which that test was executed (or simulated). There needs to be some reference between pattern exec instances (or perhaps environment domains) so that one domain knows the conditions under which its test was created.

• EDA->test intent (Guard band, loading conditions)
• Higher level glue: Describe flow through the test program, hook pattern execs together. Binning conditions (exit, downbinning, etc).

Ernie says that "Test Descriptions" and program flow need to be discussed together.

• Discussion of test description:

Need to find out from the different tester vendors whether they will share their test instances to consider as a standard. Tom Munns suggested that we need to take STIL to the point that it refers to a native tester’s test. Then the native (probably optimized) test can be used on each test platform. (i.e., have STIL say "leakage test" and some parameters, then the tester native modules. But you may want to specify a standard so that all suppliers can be measured as to how they meet the standard. If we get presentations from each of the tester vendors listed (LTX, Credence, Sclum, IMS, etc.)

Don Organ says that LTX will offer their data model for creating an entire program.

• Tester Rules Definition:

Defining tester limits or restrictions on resources. It may be difficult to define at what level you cut off the tester rules. It may be something that the ATE companies develop and give to their customers for use in simulation, or translation. But it would also need to be user customizable. STIL would have a syntax and a container for rules, but not attempt to dictate what the rules are.

• Tester Transformation:

• Test Feedback:

• Simulation: Presentation by Nathan Biggs and Dave Dowding of Microchip

To make STIL usable as a simulation database (in place of HDL, and given the appropriate software tools to communicate STIL to the simulator) there are four areas that need to be extended, or enhanced.

1. Environmental descriptions: Need to add statements to contain environmental information, including alternate databases, and mapping namespaces to those alternate entities. Would also include a modification to PatternExec to be able to reference an environment domain name.
2. Timing Extensions: In order to specify user defined events at a given point in time, it is proposed to modify the timing "waveform" syntax to allow a compound statement after the time expression.
3. Pattern Statement Addition: Existing pattern statements can be used to specify stimulus (V, W, C, macro, etc.) but there needs to be another statement to allow communication to alternate processes (i.e., simulation). It is proposed to have a "SimCntrl" statement that contains user defined keywords, or annotations. The process consuming STIL would need to know how to process these.
4. Pattern Burst Extensions: Simulation has a notion of concurrent events. This could be easily handled in STIL by providing a way to specify patterns that could run in parallel. This means that the patterns would have separate signal spaces.

These enhancements would allow STIL to be used as a simulation database. There may also be many other applications for the enhancements.

Don Organ wants an electronic version of the simulation proposal to put on the web page and to invite comments. Nathan Biggs will generate HTML version and send it to Don.
 

9/25 Meeting 8:00am

Attendees:
  

Proposed 1450A charter from Tony

Need to discuss process of communicating between meetings:

Conference calls,
E-mail list

Will discuss how to contact balloters for questions. Attendees are invited to indicate whether they do not want to be involved in contacting balloters.
 
Discussion of proposed charter:

Frank does not like the word "all" in "all other aspects of test definition for digital devices". This is too broad of a statement and does not specify and end condition.

Ernie and Phil proposed leaving the word "all" out.
Move the enumerated list of things to work on up.

The version of the 1450A charter that everyone agreed on is:
 

Dave Dowding wants to discuss a date for the next meeting. It is proposed to have a December 3-4, 1997 meeting at Microchip in Chandler. Dave will post a meeting invitation a few weeks after the minutes are posted. The December meeting will be a 1450 meeting for reviewing ballot issues. The ITC meeting will be on 1450A. Is that appropriate? Or should the existing ballot issues be discussed? It is proposed that the ballot issues take top priority on the meeting agenda.
 
What about the analog (1450B) meeting? Tony: we need another chair person that will take leadership of the B meeting. The people (companies) interested in mixed-signal need to take this and get it moving. The charter and forming of the B working group at the Thursday ITC meeting.
 
We still need to find a host for the Wednesday ITC meeting.

Francisco Hernandez agreed to host the Wednesday ITC meeting.

Issue from agenda to discuss today: STIL Parser:
 
Tom Munns said that Motorola will probably have the means to contribute to the development a STIL parser. HP will also fund it, as well as TSSI. LTX will not do anything until there is a specific proposal to get signed off.
 
Tony has proposals from two companies to do a STIL parser: SAS and Sabre. We need to define the extent of the parser. Will it be a Lex/Yacc gramar only, or will it include an API and database access?
 

SAS (Silicon Automation Systems) proposal:

The project:

Givargis wants to change the name from "OO Database" to "Class Libraries"

There is a discussion of whether there is a read only library access, or a read and write API.
 

First Pass SRS:

LexYacc Parser and syntax check
Does the database persist? (No)
Able to read and write STIL data through API?
Does it include semantic checking or just syntax?

Tony distributed the actual proposal from SAS.

Phil and Greg agree that it should be the read access scope only. Tony has added the addendum to the spec that not all files will be kept in memory. Pattern files may need to be cached.

Tony’s description of SAS: Company in India. 170 engineers and grow to 320 in next year. Tightly associated with EDA world. Telecommunications, signal processing, System Design/Tools (verilog, vhdl, simulators, synthesis, layout...)
 
Phil wants to know if they would do the tool, and then put it on the market, rather than have a jointly funded effort.
 
Frank Peyton wants to investigate doing it from his resources, and having the software available from within the committee. Frank will put together a proposal.
 
There is a discussion on whether we need semantic checking or just syntax checking. Stefan says that a semantic check is outside the scope of a standards committee, while Givargis says that semantic checking is vital to the project. At the minimum we need to check the semantics that are listed in the STIL spec.
 
Phil suggests that a joint engineering effort may be desirable, while Don says that dividing this effort would be difficult.

Ross says that performance is a large consideration. A "world-class" parser is needed to show the benefit of STIL.

Tony: Who is interested in doing this? And who is interested in funding this? Dave says that this is a 1450 meeting issue, and this may be put off until the next 1450 meeting. Tony wants to get going.
 

There are three issues that need to be considered:

Parser, Syntax checking, and Semantic checking
Data structure establishment with STIL output writer
read/write methods in and out of the database and semantic checking
 

SRS:

Lex/YACC
Class libraries for reading objects
Able to write full STIL data (but maybe not hierarchical)
Data structures
Semantic checking as defined in STIL spec
Performace of parser
 

 

By ITC all existing proposals will be reviewed and a selection will be made.

 

Dave explains workshop format at ITC, and why it might be important for STIL committee members to be in attendance at the STIL workshop. The workshop is on economics of test/design/manufacturing. Management people will be in attendence at the workshop, and it may be advantageous to have a STIL presence at this discussion.

The proposed Thursday STIL working group meeting will be in conflict with this workshop. It is proposed to dismiss the Thursday meeting. The Wednesday meeting will still be open door, with a proposal review to follow that evening. The vote was unanimous to arrange the meetings this way.

----- review of agenda items ----

Ross wants to expand simulation environment to handle signal-by-signal environment specification.
 

Tony wants to focus on pattern related issues for expansion before we go into other areas of test. The pattern related things need to get top priority.

Brainstorm on each of the top priorities: (what is included)

DUT Environment

Resource Table (aka DC Table)  (analogous to WFT)
May want to change DC resources on the fly (between each vector)

What are the contents of the Resource/DC table? (Changeable on the fly)

Power(s) (device perspective)
Comparator levels (vol/voh)
Drive levels (vil/vih)
Tri-state leakage (ioh/iol)
Load (vil/vih/vref, output impedence per in/out state)
Output Buffer Strength
Clamps (hi/lo)
Calibration points
Guardbands (?)
Process variations
Simulated operation range
Constraints (i.e., limits to the levels)
Characterization information (i.e, Ranges, expected results)
Device modelling (Dave Dowding will get parameter list on this)
Buffer technology
Temperature
Accuracy
Mode

Somebody needs to take the action of expanding each of these items and putting some description behind each one. Dave Dowding and Ross Youngblood will each take a pass at it.
 
Nathan Biggs rehashed the simulation proposal for the people that were not involved yesterday. There was some discussion about the rectangular requirement for parallel patterns.
 
Nathan will e-mail an ascii file of the example (ls245) to Tony Taylor for syntax review.
 
== Chris Nelson and another Intel engineer came in, there was a review of issues covered so far ==
 

Discussion of Test Flow and Test Methods
 
Don Organ has supplied notes for the enVision data model. He discussed each of the objects in enVision.

Suggests adding the "TesterCh = x;" statement to map STIL pins to tester resources. There is the notion of "Cbit" that controls a loadboard. STIL may need the ability to control device external things.
Line 147 in handout is the first "test block"
 
There is a question as to how the committee will handle test methods. Do we define the specific tests and their types, or do we define "how" a test is constructed, but not how the test is done. Whatever we do it needs to be extensible, because whatever we do, we will leave some of the tests out.

Line 251 is the flow object
 
Don will also come up with some pictures that will relate some of these objects. There was concensus that this was a good start for the syntax that we want for flow, and test.
 

Discussion of Tester Targeting:
 
Should there be a definition of the order that the tests should be executed in?

To optimize for given tester
What re-ordering is allowed?
List (ordered) vs. Collection (no order)

Givargis said that the Microchip proposal for timing could be used for tester targeting in timing selection

Chris says that we need to be able to specify the time-set scramble.

Tony says that there is a document with the original proposal for time-set scramble. He will re-distribute the document.
 

Other tester specific items:

Channel mapping (mux, multi-site testing)
Calibration (standard, fixture, and focused)
Accuracy (waveform choices, analog)
Resource limits
Number of pins (may be tester rule)
Control bits for external control
EPROM on DUT board for identification
GPIB for instrument control
Power Supply Delays
External Clock
Mux-mode, Doublet, etc.
Match Mode
Pattern functions (Subroutine variable parameters)
All items that fall out of 1450A should be considered as tester targeting.