Phone Conference P1450.1 Working Doc Subgroup Thurs Oct 11, 10:00 am PDT --------------------------------------------- Attendees: ---------- Tony Taylor Greg Maston Gregg Wilder Doug Sprague Peter Wohl Agenda ------ Review the p1450.1 spec, version 0.98, distributed by Greg the night before. Issues ------ Draft Version Identification. Because of issues that Gregg Wilder confronted with the IEEE during dot2-submission, we will change the header of this document to identify an integer draft that reflects the number of internal recirculations of this document. Instead of "Draft 0.98" as currently use, the next circulation of this document will be identified as "D12" to reflect the number of entries in the History table. Section 6.3 - hierarchical cellname constructs. Tony identified a limitation of the naming convention present here, that the names are currently defined to be single-hierarchical level, but the environment should not be so constrained. Therefore, it is necessary to add ()+ around the reference to INST_NAME, to allow multiple levels of naming hierarchy. pg 15 - Reference here to table 4 should be to table 5. Tony identified that the last 2 entries of table 4 need some work, as the last one is incomplete and the second-to-last one is really showing boolean ops. Section 6.9.1 - wording change from "this functions value" to "the mergedscan operation" Section 11, pg 20. Tony questioned the statement "Usage SimulationOnly;". Since this is a design-oriented spec, Should this be "DesignOnly"? Greg identified that this spec does contain specific references to information provided for simulation-only contexts and that therefore he feels "SimulationOnly" is an appropriate context, however, there may be ADDITIONAL contexts. Tony identified another potential context as being the translation behavior (MergedScan operation is primarily a translation-only context). No changes were made to this construct in this meeting, however the Working Group was asked to consider this issue and determine if additional contexts could be identified, and should be added here. Also it is worthwhile to consider whether references to various applications in the rest of this document are clear and reflect, in particular, this notion of Usage here. Section 12 -- Tony identified 3 types of "constraints" on ParallelPatList blocks/execution. He requests augmenting the current ParallelPatList construct to support an optional designation of the following constraints: SyncStart - all parallel patterns shall start together, but may diverge during execution. Independent - all parallel patterns may start whenever and finish whenever LockStep - all parallel patterns shall execute every Vector in synchronized fashion; all Vectors shall have the same period, and all patterns present shall finish together. This was accepted in this group without dissention although some discussion followed about the implications and necessity to check the validity of these constraints when present. Some discussion also ensued about needing to check the constraints on non-overlapping signals in the set of patterns referenced by ParallelPatList. This constraint/requirement that the set of signals be non-overlapping in ParallelPatList was not found in the current document and indicates a missing requirement. Section 14, ScanStructures. Tony presented that the CTL group needs to identify the Scan Enable information per chain, and presented the opportunity to define that statement as part of the ScanStructures extensions present in dot0, rather than requiring this section be yet-again-redefined in the dot6 spec. Greg presented that the "enable" needs to be represented as a logical_expr, to support a relatively-relaxed set of constructs on enabling. The syntax was identified as: ScanEnable logical_expr; Peter voiced concern about this construct in this standard, on several different fronts. 1. There are scan architectures where scan-enable makes sense, but there are some scan environments where the notion of a scan-enable is either "not supported", or confusing. By placing this statement in the language we may not get a uniform concept of a "scan enable" presented by all users. 2. The purpose of the ScanStructures, for dot0 and dot1, are to support direct simulation of scan data, and to allow a level of diagnostic information down to the scancell level. Neither of these applications find use with the ScanEnable construct, which makes this information out of the required scope. Greg identified a concern however if the dot6 group then needs to redefine the scanstructures just to declare this statement, our standards aren't coordinating very well -- and we've already identified that the Scan*Clock statements already defined are of similar concern (they are not needed to satisfy reqiurements of this block either), so we might as will simplify the number of times this structure gets defined across the standards. Greg made motion to add statement here. Gregg W. seconded; Peter abstained; Gregg, Greg were in favor. Annex C --- Tony identified that this annex, while elaborating the use of logical_expr, only elaborated it in the context of CTL and assumes a CTL syntax in here. Decision to remove from this annex from the document. Annex O ---- 3rd para "independent" should be "independently". References in this section to "reader" will be changed to "consumer", to differentiate stil-parsing issues from stil-use issues. Doug identified 3 additional issues at the end of this annex: 1. dot0 spec says one Shift block per procedure/macro... Do we need to explicitly open-up this statement? (the answer to that is Yes) - we need to add a clarification in dot0 about section 24.4, - and something in dot1 .... someplace, to further open-up this condition with non-overlapping signals caused by if/else. 2. Doug is concerned about parameter passing of this information, but he's not sure of any specific issues. He will review his concerns here. 3. X statement (and labels) in procedures -- X statements in the procedures are not unique; need to put the X statement into the argument list of the call to be applied.... Greg identified that the "nearest X" would be attached in the patterns at the calling point of the macro/procedure, and the offset could be evaluated from this context. But everyone appreciated that this was not an easy task (particularly if the If/Else or other flow control variants in the proc/macro body). No resolution of this issue was identified in the meeting but was left for consideration by the Working Group members. Next Steps ---------- Greg will complete the changes above and send to Tony for review of the additional constructs. Then we will email a quick-review process to look over these final changes and move the document into the internal review process.