SV-EC Meeting Minutes 8 July 2002 Attendees consisted of: (a-) Cliff Cummings (Sunburst) * (-a) Dave Kelf (Co-Design) (aa) David Smith (Synopsys) * (-a) Dennis Brophy (ModelTech) (aa) Heath Chambers (HMC) * (aa) Karen Pieper (Synopsys) * (aa) Kevin Cameron (National) * (aa) Mehdi Mohtashemi (Synopsys) * (-a) Neil Korpusik (Sun) (aa) Paul Graham (Cadence) * (aa) Peter Flake (Co-Design) * (a-) Roy Armoni (Intel) * (aa) Simon Davidmann (Co-Design) * (-a) Stefan Boyd (-) (aa) Steven Sharp (Cadence) * (-a) Tom Fitzpatrick (Co-Design) * indicates eligible to vote on consensus issues Action Items: 1. Review/Approve these minutes at the next meeting. 2. (Kevin) To post requirements on dynamic process control, to allow more information on usage. 3. Time is critical, at this rate it will take much longer to analyze the donation. Need to try alternatives, such as focusing on top-level issues, review these and come up with major issue list, and/or add more days/time for meetings. Need to solicit and concur ways to expedite, otherwise deadline will be missed. 4. (Mehdi) Clarify the event definition/usage, also virtual port definition. Review other questions, and possible updates to the meeting minutes [if any]. Discussion: 1. First item on the agenda: Review and approve the meeting minutes of the June28_02 SV-EC meeting. Simon asked a procedural question about quorum, how many people are on the reflector and how many are on the call today. (David) 31 people on the reflector, not all eligible for voting, 10 present at the moment to be able to vote. In this context attendance rule were discussed. David asked for comments on the revised version of the meeting minutes, asked for motion to approve then. (Karen) Set out the motion, (?) seconded, there were all yes, zero abstention/NO. The revised meeting minutes were unanimously approved and as such noted. 2. The second item on the agenda: To review and discuss/finalize a) the mission statement b) the process of how to go through the donation. (Dave Kelf) Brought out the question of single syntax and element of separate or same LRM. (David) Refined even further, clarified, at the high level we can view this in two different ways; 1) Rationalize the syntax leading to semantics that may be different for testbench addition/or/extension. 2) Semantically /and/ syntactically similar, again it can/or/may become a chapter in SystemVerilog for testbenches. (David) Again on the subject of Process, we need to analyze and see what to do with the donation. (?) What form would clarification and also reconciliation of the donation take from the donor. (Mehdi) The donation is intended for testbench extension as a whole, however, in the analysis if there are inconsistencies, or change to syntax is desired, Synopsys will look at these request for reconciliation, need to clarify the testbench usage model. (?) There was a question about how/what it means for the committee to accept the donation. (David) Asked for any further comments on the mission statement. (Simon,?) Question on the part of statement pertaining to donations provided to committee by the TCC chair: "Process any donations provided to the committee by the TCC chair." Recommendation to remove 'by the TCC chair' and leave the portion, 'to the committee'. (David) Asked for motion to approve the mission statement, no discussion pursued. (Karen) Set the motion for approval, (Simon) provided a second to the motion. By unanimous decision, committee approved the amended mission statement. 3. The last part of the second item on the agenda was on approving the process to go through the donation. There were no other discussion. (David) Asked for motion to approve the process as it is stated. (Heath) Set out the motion to approve, (Mehdi) seconded. With no abstention/NO vote, unanimous decision the 'process' was approved. 4. The third part was devoted to the proposal Kevin Cameron had sent out with respect to Dynamic Process Control. (Kevin) Briefly reviewed the notion of process id, hierarchical names for processes. (?) A question was asked on the type associated with process id, it is a special type, the pid_t in C is/maybe different in this sense. Again questions were raised as to what can be done with process id? besides kill, sleep. (Kevin) The threads are basically similar to posix light-weight threads. More questions were raised with respect to the functionality/usage of the dynamic process: [example follows] (Peter) There are system functions such as $list_process (??), or you can disable the process, hold the process [within the process] and access the process from outside. (Kevin) Need to review functionality. (Simon) Can we write-up a sample requirement, the problem, what types of control do we have, etc. (David) An action item for Kevin to post requirements for dynamic process control so that folks can gain more insight/information on this. 5 The fourth discussion was stated as review of first two chapters of testbench donation, chapters 1 and 2. (David) Observed that through analyzing the document we need to see what is needed to support this as the tesbench extension or component. Review what could be missing, inconsistencies and requires clarifications. Another discussion ensued based on Tom's question on the process, will this be another chapter in SystemVerilog Spec or will it be incorporated through the SV. (?) Statement was made as to having another testbench language or extension to the current language. (?) The intention is to extend the SV for system design and testbench language. (?) Observation was made that it maybecome necessary to have yet another committee to take up the Test bench issue. In this light the question was raised as to possibility of changing the mission statement. At this point in the interest of time the chair started the review process, looking at chapter 1. pager 1-1. - Comment section looks the same as SV. - Statement block definition, { and } is concatenation in SV, also a syntactical issue. The begin and end would work fine. (?) We can either reject this {} or subject it to modification. (?) This again is highlighted for assumption of single verilog parser, with the possibility of a translator from Vera to valid code. - (?) Empty statement is valid in SV. - Identifiers: (Peter) SV allows $ to be used in the middle of identifiers. (Mehdi) In Vera, the $ is used for virtual port signals as well as c function call statement. The virtual ports are not part of the donation. - String: It is observed that in SV [or verilog] strings are [reg] character arrays. String construct has to be one-line constructs. Need to check the \ line extension may have conflict within the macro usage/definition. - Numbers: Question was raised on sign identifier for numbers that is missing from the document. [page 1-4]. Nee to clarify negative signs. - Data types [page 1-6]. (Simon) Question was raised on the 'real' type, it is not part of VeraLite. Also the virtual port is stated here but not defined. [The virtual port is not part of VeraLite, documentation error]. (?) Question was raised on including data types in SV, how do changes if any occur in the testbench document, is there a source or would the donor need to modify it/and/or add clarifications/definitions. (Dave) What is the basic data type, vs. standard data type; clarification. (all) What is the scalar term used in 1-6. (Mehdi) short hand notation for the returned value of functions, not a keyword. (Simon) Question was asked about the global scope of variables at the program level. Observation that the program is similar to $root. - Integer [page 1-7]: (several) In SV the integer definition can have both x and z. Also portions of it can be x, not the whole integer becoming x. Bit slices can be extracted. (?) Do we need this integer definition in SV, does it create confusion between the two. It was noted that for performance reasons integer in VeraLite is defined and used in this manner. - Bit [page 1-7]: (several) The bit data type is a restricted version of logic in SV. [reg and bit in VeraLite can be used interchangeably]. (?) Question on the MSB:LSB, formation. (Mehdi) Declaration needs this as well as LSB to be 0. (several) Since this can be a restricted logic definition, can be translated into SV. (?) Would a syntactical change be required or part of is semantics. - String [page 1-8,1-9]: (several) New data type, separate from array of characters in SV. Is it ok the way defined here. - Event [page 1-9]: (several) Additional semantics to SV event, how different is it. (Mehdi) Usage is for synchronization between parallel processes, the triggering functions/and sync methods are missing from the document, need to update them. (several) Is this just like a signal, or bit that can be toggled. (David) Think of this data-type as something else, not named event, then look at the functionality. (Mehdi) There are lot more functionality with this where order of events/synchronization come into play. When we reached here, the allocated 2hrs meeting time was up. (several) Observed that the committee was only able to go through 9 pages so far, certainly it will take much longer than the what the TC has demanded for deliverables, how do we make progress and go furhter in shorter time frame. (David) Either have to have more meetings which may not ever happen or re-arrange how we analyze the donation. It is observed that one way to expedite this is to concentrate and focus on the top/major issues, everyone can review the items and bring them to the meeting fro disucssion. (?, Mehdi) Need to go higher-level, in the same spirit as above, foucing on big picture. (several) Observed that time would be very critical and a bottleneck. Was observed that committee needs to take this up and come to a resolution. --------------------- end July 8_2002 mtg minutes---------------