Phone Conference P1450.1 Working Doc Subgroup

Thurs, Feb 10, 2005, 10:00 am PST

 

Attendees:

Tony Taylor (chair & scribe)
Doug Sprague
John Cosley

Bruce Kaufman

Dan Fan

Bob Roberts

 

Documents

Agenda

 

1. New Annex F
2. John Cosley (JC-1) - new issue with regard to mapping of integers to/from wfc
3. Gordon Robinson (GR-1..10) - new list of issues (see D22 resolution doc)

 


Meeting discussion

 

IEEE meeting clearances

Nothing under discussion or presentation for this meeting

was identified as being proprietary or restricted.

 

New Annex F

This annex has been re-worked at the request of ballotter (Rohit Kapur) so as not to be confused with the scan implementation that is presented in dot6 for embedded cores. Instead of two serially connected scan chains, it now has two identical modules each with two common signals - one primary input  that is used as a select signal, and one primary output that is used to compare the result of the selected module. The wg agreed with the new example and thought that it was a better example of the use of AllowInterleave since one did not have to deal with the complexities of scan to understand it. Rohit has been asked to review and comment.

 

Mapping of integers to/from wfc

John Cosley has pointed out a conflict in what the syntax allows and one of the examples. Specifically, the example "Y = \W INT;" which is supposed to map the content of the integer variable called INT onto the wfc's of a signal group called Y. Upon discussion, several issues arose:

1. There was a lack of understanding of the rules for mapping an integer to a list of wfc's. Is it always LSB oriented? Is it an error if group Y is defined as MSB? What if group Y is greater than 32 bits (the max int); does it 0 fill the signals beyond 32? What if the data contained in the integer requires more wfcs than there are signals in the group - is it an error? does it lose the MSB bits? What if there are no mapping chars defined in group Y? Does it default to 0/1? Can more than two states be mapped?  These issues need to be clarified in dot0 since they apply equally to the mapping of integer literals using \d. Tony will work with Greg to see what clarification needs to be added to dot0.

 

2. There was confusion between the use of \W to map the integer vs. the use of \d to map an integer. Upon further analysis (after the meeting), Tony now believes that "Y=\d INT;" is a better solution - i.e., just extend the definition of \d to allow integer variables as well as integer literals. The \d syntax also has the needed definition to allow mapping characters -  "Y=\dAB INT;"

 

3. Should we also define the mapping of wfc to integer? Two options were discussed - INT := \IAB Y; or INT := WFC2Int (AB, Y); The second form is more consistent with a function definition that would typically be used in an arithmetic expressions, whereas the first is more consistent with pattern-data syntax.

The WG then discussed whether this capability is required in this dot0 extension. For completeness, it certainly fits. But the application might be better suited for a standard for either analog, memory, or algorithmic patterns. The question as to whether to allow or not is left open until the next meeting.

 

New issues GR1..10

Although the wg had not had time to study Gordon's inputs and Gordon was not present, we walked quickly through the issues to get an initial reaction.

GR-1: No specific resolution seems to be required to this issue. The specifics are addressed in the other issues.

 

GR-2: The WG has hashed the definition of booleans several times and does not feel that it needs to be changed. The issue that needs to clarified (with Gordon, and perhaps in the document) is the difference between a boolean type (which there is none) and a boolean interpretation of an expression (which is referred to as boolean_expr in clause 5).

 

GR-3: As currently defined, delimiters around expressions (tics or parens) are optional unless specifically required by the statement context in which they are used. Gordon is correct that there is no forward reference to these exceptions, but the two current exceptions are - 1) pattern data "GRP=\r(FOO-1) X;" and 2 waveform timing - "0/1 { '2ns' D/U; }. The wg is inclined to keep this requirement for the reason that: 1) it simplifies parsing of the data and 2) it improves error recovery when the syntax is incorrectly specified. However, the wg will review this definition one more time to see if there is actually a parsing conflict if the delimiters are made completely optional.

 

GR-4: This issue is being addressed due to suggestions made by Don Organ. Clause 5 is being modified such that the definition of terms is removed from table 5, and table 5 will have a clear definition of operators, operands, and casting. WG will ask for Gordon's input when this re-write is complete.

 

GR-5: Same issue as GR-3

 

GR-6: WG agrees with this change

 

GR-7: The WG would like to leave this as is. The user always has the option of defining user-functions to do explicit trunc/round/other.

 

GR-8: This one requires more thought.

 

GR-9: Agree

 

GR-10: Seems like we all agree on the functionality. Tony will review the write-up to see how to make things more clear.

 

Meeting ended at 11:17


Next meeting

Next meeting in two weeks, Feb 24, 10 am PST.

 

AIs

  1. Tony - create a new D22 and make the changes agreed to on 1/14 and 1/27.

  2. Tony - make adjustments to the document wrt "type safe" issue discussed on 1/27

  3. Rohit - discuss with Jason Doege the P1500 definition for complex scan cells and see if they can define a better way to represent these cells in 1450.1.

  4. Tony - make changes to Table 5 per Don's suggestion to clarify the content of expressions

  5. WG - re-visit the integer-wfc mapping issue described above

  6. Tony - review and make changes per GR1..10 above.