Phone Conference P1450.3 Working Group

Thursday, Apr 13, 2005 -  10:00-11:30 Pacific Time




Attendees:

Tony Taylor (chair & scribe)
John Cosley

Dave Galagher
Daniel Fan
 

Docs:

 

    http://grouper.ieee.org/groups/1450/private/1450.3-D12.pdf

 

Agenda:

 

Agenda:
 
1. Syntax for Assert, \config, \param.
 
2. Review changes to Dan's TRC file.
 
3. Re-visit the scoping of TRC rules. Two point of view ...
 
a) John Cosley correctly points out that in most cases, in STIL, things are cumulative - i.e., signal names, scan cell names, macro names, procedure names. The rule is that the set of domains that are in scope at any point must not have any naming conflicts.
 
b) Greg and Tony both are of the opinion that in the case of TRC rules, that when a lower level block references a new domain name that the new rules should completely replace the higher level rule set. To do otherwise, means that we would have to specify all the ways that rule conflicts can occur, what is allowed, what is not allowed. Maybe this should be looked on differently since these are statements, not named entities.
 

Discussion:

 

Nothing under discussion or presentation for this meeting was identified as being proprietary or restricted.

 

1. Create a table of scoping rules across all STIL statements as to when data from one block filters down into lower level blocks. Apparently this is done on a statement level in dot6. Dot0/1 do it mostly for named objects like signals, scancells, macro names, etc. Intent is to see if we are consistent.
 
2. Need to identify the allowed (or disallowed) scope of the Assert statement. Is it a) a run time statement (e.g., in a pattern or burst) or b) a declaration (e.g., to be done when a block is initially processed), or  c) a monitor function (e.g., like Fixed in a pattern that works over all the statements)? The concensus was that we should define the Assert as it applies to dot3 only, and not get into the detailed semantics of how it might work in a run time environment.
 
3. On the \config and \param token, John had an excellent suggestion. Define new statements to be allowed inside a Variables block - ConfigConstant, ParamConstant (names subject to revision). This does away with the back-slash and keeps the expressions simpler. (Note: New D12 contains this new syntax - tt 4/21/06)



Meeting adjourned 10:45 Pacific time


Next meeting

Date: Next meeting Thursday, Apr 27
Time: 10:00 to 11:30 Pacific time

 


Action Items: