Phone Conference P1450.1 Working Doc Subgroup Thurs Mar 1, 10:00 am PST --------------------------------------------- Attendees: ---------- Tony Taylor Peter Wohl Doug Sprague Greg Maston Gregg Wilder Agenda ------ Proposed by Tony and agreed to by consensus: 1) Update from Greg on what he has done over the last 2 weeks 2) Discuss any issues by reviewers 3) Hand of of document to Peter - to add BistStructures 4) Decide what to do next Documents discussed: -------------------- [1]Greg's latest P1450.1 doc v9.2 (dated 2001), pdf [2]Email from Greg proposing Variables/Enums under SignalGroups Greg's changes: --------------- Overview: three primary focii of change in this document: - location of the Variables/Enums/Constants declarations (under SignalGroups now) [discussed in email from Greg, included at end of these minutes] - location of the If and While constructs in the PatternBurst [new proposal to address syntax uniformity issues] - Replacement of ScanChain with ScanCell under the Environment block [discussed in last meeting] SignalGroups changes issues --------------------------- Tony raised a concern/question about putting general Variables (particularly those used in logical_expr) under the SignalGroups. This seems a bit strange. Greg identified the motivation here as: (1) Variable usage is the same as SignalGroups; by defining them under this construct we leverage the necessary definitions to access these additions without defining additional identical rulesets. (2) We maintain a simplier overall language by not requiring additional descriptions for new namespaces to support additional top-level blocks, etc. Doug raised his concern (previously mentioned in email) about the declaration statement order - '"name" Type;' vs 'Type "name";'. Most languages define the Type first and then the name. Motivation (from Greg) to do this name-first is for syntax uniformity inside this block. As this block contains user-name statements and not STIL-keyword statements, it is more uniform to the langauge to do the first choice here. PatternBurst changes issues --------------------------- Greg identified two sets of changes to the PatternBurst information. One was the removal of the Variable and Enumeration reference statements inside this block, since these constructs use the SignalGroups reference statements. Greg also identified a proposal to change the If and While from block-structured statements (inside a user-name statement block again), to an attribute construct. The attribute construct supports the same capabilities with a corresponding language simplification for this block. This change was accepted for this round of review. Greg identified that he also changed the term "nonTesterUsage" to be "nonATEOnly", to reflect terminology used more uniformly. Tony further proposed that the term be defined in a positive sense, and proposed to change "nonATEOnly" to "SimulationOnly". This was accepted with the following issue: Doug raised a question on what else could go into here. Should we define other values here, or is there really only one Usage? This may become an issue if other people establish (or determine they want to establish) "their own usages". Greg took AI[7] to implement this change. Tony raised a question from the SignalGroups example, about having a complete example showing variable application as well. This was discussed and Greg took AI[1] to review the entire doc for variable examples and determine whether an additional Annex is necessary. Tony raised a question on the scope of a Constant declared in the Signals; Greg stated his expectation that it was global. Greg took AI[2] to add some statement about scope of Constant declarations in the Signals block. Greg took AI[3] to italicize the pat_expr references in the PatternBurst syntax. New Business ------------ Peter asked a question about Table 5, and the intent to reference the BistStructure in the PatternBurst. He identified his expectation to reference the BistStructs only in the Patterns. Greg took AI[4] to remove all references to PatternBursts here. Peter asked a question about passing parameters between procedures and macros. This topic was presented at this point. The basic issue is that the capability to pass parameters through one procedure and into another is defined in dot0 to not be allowed. However, for dot1, we would like to ease this restriction and allow parameter passing with explicit same-name resolution of these parameters (that is, a parameter passed into one procedure may be passed into the call of the next procedure as long as the parameter name is the same). Greg took AI[5] to add this to the current document. This requires adding a new section to modify the dot0 procedure and macro handling, and explicitly define the allowed parameter-pass-through mechanism. Greg identified a concern about the expression environment defined in this document; he is not sure about the uniformity or completeness of the definitions present yet. Greg identified that the TestResult construct was still present in this document, although the previous ITC meeting had voted this construct out. This Working Group made the decision to not implement this request until additional review of the document. Greg took AI[6] to send this new document to Steve S. at Microchip for the express purpose of review of the TestResult issue. Next Steps ---------- (1) Greg will cleanup the resolved issues in the current document, remove change bars, make changes identified in AIs, and send the document to Peter. (2) Peter will integrate the BistStructures proposal into this document. Status of P1450.2 ----------------- Tony asked Gregg for a quick status of P1450.2. Gregg has several things to add to the doc (because of Greg), but will have a new document ready for review at the .2 phone conference next week. His expectation is that this document will soon be ready for extended review. Extended Review --------------- Tony asked for the next P1450.1 meeting, that we consider names to distribute both the .1 and .2 efforts, with anticipation that we would distribute these two documents to an extended review as a pre-ballot step within the next 4 weeks. Meeting was adjourned at 10:57 PST. AIs ---------- AI[1] Greg - review current variable examples and determine need for an additional Annex to present expected usage. AI[2] Greg - add statement about scope of Constant declarations in the Signals block. AI[3] Greg - italicize the pat_expr references in the PatternBurst syntax. AI[4] Greg - remove any ref to PatternBurst in Table 5 BistStruct. AI[5] Greg - define macro/proc parameter-pass-through capability. AI[6] Greg - send current document after cleanup to Steve S/MicroChip. AI[7] Greg - change nonATEOnly to SimulationOnly. ----------------------------------------------------------- Email from Greg on proposal to move Vars under SignalGroups ----------------------------------------------------------- Subject: P1450.1 - how about moving Variables and Enums into the SignalGroups? Date: Fri, 02 Feb 2001 12:33:12 -0700 From: Greg Maston Reply-To: gmaston@qwest.net Organization: Synopsys, Inc. To: Peter Wohl , Tony Taylor , "Douglas E. Sprague" , Gregg Wilder , Rohit Kapur alright Tony mentioned this in our last phone discussion. It's maybe a bit weird only because things of different type start to get mixed together under a blockname that becomes less meaningful (but there are sufficient structural capabilities that users can define them separately if that's a concern). Anyway, since the application/use/namespace of Variables and Enums overlaps SignalGroups (in order to allow them to be used interchangeably), and because SignalGroups have an "=" in the declaration statement today (i never thought i would thank Gordon R. on that one), we could unambiguously put Variables and Enums declarations into the SignalGroups block as follows: SignalGroups { ( GROUPNAME = sigref_expr { ( WFCMap {} )* } )* ( VAR_NAME < Real | Integer | WFC | Enumeration ENUM_NAME >)* ; ( VAR_NAME < Real | Integer | WFC | Enumeration ENUM_NAME > { ( Usage NonTesterOnly; ) ( Base < Decimal | Hex > WFC_LIST; ) ( Alignment < MSB | LSB >; ) ( Length DECIMAL_INTEGER; ) ( InitialValue pat_expr; ) } )* ( ENUM_NAME EnumerationWFC { ( Base WFC_LIST; ) Values { (ENUM = stuff )+ ; } } )* ( ENUM_NAME EnumerationInteger{ Values { ( ENUM (= DECIMAL_INTEGER ) )+ ; } } )* ( CONST_NAME Constant = DECIMAL_INTEGER ; )* } An example of this is: ---------------------- SignalGroups a { HiBusAddrValue Constant = 16; pcommands EnumerationWFC { Base Hex DU; Values { grab = FF { Ann {* moves cursor *} } release = 00 { Ann (* releases cursor *} } } } conditions EnumerationInteger { Values { red { Ann {* critical processing error *} } yellow { Ann (* cautionary processing condition *} } green { Ann (* processing OK *} } } } MainIntrBus = ABUS[ HiBusAddrValue .. 0 ]; CurrentOp Enumeration pcommands; CurrentState Enumeration conditions { InitialValue 'green'; // do I need quotes to define this on type enum? } } -------------------- now, you probably noticed that I added yet another "type" to the language called Constant. that's because I realized that the whole reason we were trying to reference enums into the SignalGroups was not because we wanted enums -- we wanted a mnemonic name that represented a constant value there. Since Enums are defined under a named "class" only it's difficult to access the enum values without using that named class...(in fact you're not supposed to be able to) so to make the example work above I added "Constant". (Note I think I should probably further identify this type as ConstantInteger because someone someplace will expand the use of constants.... This actually cleans up a BUNCH of issues: it clearly identifies how constants get resolved when present in SignalGroups (uses the same definitions that resolve singlegroups), it removes added reference statements for these blocks in the PatternBurst , AND uses the same SignalGroup reference and resolution processes for these names, already defined in .1 (and clarified in that clarifications doc). The one negative is it's not easy to identify the "variables" from the "groups" - Variables always have a type declaration, and Groups always have an "=", so there is no ambiguity -- it's more a readability thing... I've NOT yet added these statements to the Signals block, not because we can't, but because the Signals block has "types" already ... however I'm concerned that the primary reason for wanted constant values to specify "parameterized" bus widths PROBABLY needs to allow constants into the Signals block to be useful. But if I do this I'm not sure I like the two forms of statements that appear in this block: Signals { HiAddrValue Constant = 16; TopBus [ HiAddrValue ... 0 ] InOut; } ...we've just avoided putting statements of such different forms together in one block so far... also this opens up the question of whether we should put variables and enums into the Signals block...(again, we CAN - i just don't know if we SHOULD... a jurassic-park quandary...) I'm looking for feedback on this concept. Personally I think that putting the vars and enums under signalgroups is a major simplification (not touching signals yet) and I want to do it unless someone out there says STOP! -- -------------------------------------------------------- Greg Maston (303)748-2584 Fax:(303)321-3549 Synopsys, Inc. 1335 Dexter Street Denver,CO 80220-2456