SV-EC Ballot Resolution Committee Meeting Friday April 15, 2005 8:00am - 10:00am [Minutes distributed for approval at next (sv-ec) committee meeting] (0111) Day (4125) (0000) Month (4444) (0000) Year (5555) --------- Attendees ---------- (-AAA) Arturo Salz (AAAA) Brad Pierce (AA--) Cliff Cummings (AAAA) Dave Rich (AAAA) Francoise Martinolle (A---) Karen Pieper (AAAA) Mehdi Mohtashemi (AAAA) Neil Korpusik (AAAA) Ray Ryan (AAAA) Steven Sharp (AA-A) Surrendra Dudani (-AAA) Gordon Vreugdenhil (----) Bill Paulsen (----) Dennis Brophy (----) Stu Sutherland (----) Alex Wakefield (----) Yogesh Pandey (----) Don Mills (----) Eugene Zhang (----) David Smith ** Minutes taken by Neil Korpusik and Mehdi Mohtashemi Agenda: 1) Review the IEEE patent policy ref: http://standards.ieee.org/board/pat/pat-slideset.ppt Move: Gordon Second: Brad Abstain: Opposed: 2) Review Meeting minutes, April 11th, 2005 and April 12th, 2005 http://www.eda.org/sv-ec/Minutes/SV-EC_BallotRes_Meeting_April_11_2005_Minutes.txt http://www.eda.org/sv-ec/Minutes/SV-EC_BallotRes_Meeting_April_12_2005_Minutes.txt Leave it till Monday April 18, 2005 3) Continue the resolution of ballot issues http://www.eda.org/sv/sv-champions/P1800_Committee_Assignments_05_03_29.xls Issue 233: bit-streaming of class Surrendra: sv-ac chair, ok for restriction of sub-classes, no handles, no embedded classes, class would be the bit-streaming type. Ray: rather restrictive, struct that has classes, Surrendra: as long as it does not have sub-classes.. Neil: just handles not embedded classes. we could relax it bit, just ignore handles. Dave: if you have a class in a bit-stream, group of arg in bit-stream task, traversing into the class. why the definition is not recursive Arturo: what is the criteria for recursive. Dave: if there is a bit-stream cast with a list of elements, one of them could be a handle. If we ignore handles all together we would need to ignore a handle in this case as well. Arturo: you can not bit-stream anything that is null. Francoise: specify if null-handle, issue a warning. Dave: behaviour what to do when the handle is null, inheritance, elements go Arturo: it goes at the end. Dave: issue of the unpacked, handles if they are null in an unpacked bit-stream. Arturo: you have to pre-create, these operators should not create objects, for strings and dynamic arrays already known, Dave: rule needs to be the same for both cases. Ray: as a result of unpacking and packing. Dave: Users like to use classes like a struct. A traversal of embedded classes would need to be done. Nested classes would also need to be expanded. A recursive traversal would be required, breadth-first. 1. Behavior of what to do when the handle is null. 2. What about inheritance? 3. Handles within a class 4. pack/unpack *AI: Arturo write up the rules, Based on what Dave says is missing. place on Mantis Vote on Monday. Issue 235: (Mantis- 666) pass by ref for static tasks http://www.eda.org/svdb/bug_view_page.php?bug_id=0000666 http://www.eda.org/svdb/file_download.php?file_id=809&type=bug Move: Gordon Second: Dave Abstain: Opposed: Approved Issue 236: (Mantis 642) scope for default expressions http://www.eda.org/svdb/bug_view_page.php?bug_id=0000642 Brad: do we need to get rid of the last statement. Dave: Expression is evaluated the sub Ray: updated it. Below is the new wording "The default_value is an expression. The expression is evaluated in the scope containing the subroutine declaration each time a call using the default is made. If the default_value is not used, the expression is not evaluated." Gordon: you still need to ensure that the number of arguments is correct. Move: Gordon Second: Brad Abstain: Opposed: Approved Issue 238 (Mantis 671) using clocking blocks in modules may cause races In 16.3 following the first paragraph, ADD Note: When a clocking block is declared in the same module as an always construct which is sensitive to the same clock, a race condition is present. It needs to cover the following cases: Assertions Interfaces Modules Ok in programs When a clocking block and a xxx are sensitive to the same clock... a race "may be" present. Dave: outside of a program block, Ray: when a clocking module and always block are sensitive Dave: re-written in terms of event control, race, not always block and the clocking block. not in the re-active region Arturo: in 1364, would they mention this, we can refer to it, race-condition, race between always block. outside of program block, read the value of clcoking block, sampled value of current cycle. * AI: Dave and Ray for new words on this vote on Monday. Issue 240: (Mantis- ) semantics of a class is based on where it is declared. Arturo: sent out an email early this morning - below is a short summary 1. extending classes while crossing module and program boundaries. Changes the behavior of a class... A fundamental issue. Could end up with a derived class with mixed semantics. 2. extending classes across hierarchical scope $root package or same hierarchical scope If you access local variables from a module (e.g. parameters). issues: a. static variables He suggests that we keep restrictions Gordon: agrees to split it into two issues thinks that there are other scheduling issues Within same scheduling region - is valuable and implementable Dave: goes beyond inheritance - package that isn't in an anonymous program. e.g. a mailbox - could be user defined or extended from existing mailbox In a program that instantiates this class - was declared outside the program block but now want reactive region semantics. Visibility and writeability are also issues. If use rules about where declared versus where instantiated we can't use functions to write to it. Declare in package (ie module semantics). Declare a class in a program block that extends the base class. Can't do this today. Would require two sets of utility classes (not good). More than just testbench and synthesizable code, e.g. higher level of abstractions for design representation. - reactive region is really only needed where there are tasks that wait on time. Functions are not an issue. - If have a class that only contains functions. Must use non-blocking assignments to write to variables. - May want to write a high-level design that uses classes and want a high-level testbench in the program block. - Program block was created as a verification construct. Will want to eventually replace the high-level module with rtl. Would like to keep the existing testbench. It appears as though everything needs to be in the program block if we want to re-use a testbench when replace high-level design block with an rtl representation. - mailbox - is it in the reactive or module region? Not asking for a class to have split personalities. Want one personality based on where it is instantiated. There are parameterization and instantiation issues to consider. Static elaboration/instaniation...is what is the concern. Arturo: can still use blocking assignments. - described a concept of putting higher level design constructs within the program block. - Does agree that you may want to use a class to represent design constructs. - Not sure how to implement the code if relax the restrictions. Surendra: using one class across the design/program environments sounds very confusing (which semantics apply? - reactive region or not?). Ray: randomization is a testbench issue. Mehdi: a testbench can drive either a high-level design or RTL. Steve: would the more restrictive approach prevent us to extend it later? Gordon: scheduling issues still need to be resolved. - clearly crossing program/module boundaries is an issue. * AI Gordon, Dave - send email on the reflector to see if we can get closer to a resolution on this. Will revisit on Monday. ***** From sv-bc: for EC review Issue 1: (mantis 93) Optional empty argument list for subroutine calls - () http://www.eda.org/svdb/bug_view_page.php?bug_id=0000093 Steve: originally from Infineon - can't always easily tell if it is a variable reference or function call - local calls - can use a symbol table hier ref - can't determine if a function call until elab time. - the return reg could be used as a loop counter for example Gordon: hier path - don't know if a ref to a function or data member - separate compilation issue. - simple identifier (hicon of a port in a module instantiation) if f is undeclared it is an implicit net. f may actually be a function call, from upward resolution. What do un-adorned identifiers represent? Function calls are treated as hierarchical ref in this case. If use () you know to look upwards in the hierarchy for it. - could possibly break backward compatibility Arturo: within the scope of a function the name of the function must always represent the return value. - Note: recursive calls? - others disliked this exception case - The original idea came from class members. Want to retain the ability to leave out () for class member calls. - Willing to compromise and not allow leaving out () for calls that don't apply to class methods. Brad: "uniform access principle" applies for classes. If someone changes a class you shouldn't have to change your code. e.g. if a class item is changed from a data member to a method. - doesn't think SVBC has a strong opinion either way on this item. Concensus resolution: Gord: can only leave out () in very specific cases. - wants to require () if a function call is on RHS. - Any use of function name within the body of a function is the return value of that function and not a recursive call to the function. Optional () only applies to calls to class methods. Arturo: wants any method calls have () as optional. - methods can assign to the function name - recursive calls require the () - * AI: Brad to write up a proposal for description, optional () only for class method, if it refers to itself it is a return value, recursive call must use (). Vote on Monday Issue 244 (Mantis 632) [approved in SV-BC 4/11/05; for sv-ec to review and comment if necessary] http://www.eda.org/svdb/bug_view_page.php?bug_id=0000632 Section 20.2 At the end of 20.2, ADD If the actual of an interface port connection is a hierarchical reference to an interface or a modport of a hierarchically referenced interface, the hierarchical reference shall refer to an interface instance and shall not resolve through an arrayed instance or a generate block. Francoise: this was returned to bc from the champions. Gordon: something that is highly unlikely for someone to try doing. Steve: goal is to eliminate possibility of a loop. Arturo: understands the problem and agrees with it, good rule to have. Dave: none of the champions understood it originally. No action was taken by SVEC on this item. * AI Mehdi: to report back to sv-bc on this Issue 229 (mantis 644): [Was passed in sv-ec, but sv-bc reviewed and failed due to abstentions] The SV-BC reviewed the proposal to address issue 229 in its April 11th meeting. It was not approved. Here's the message that the committee agreed to convey to the EC: The SV-BC did not pass the proposed resolution to issue 229 as captured in Mantis #644. The motion failed with only abstention. Those abstaining felt that making such a change so late in the life-cycle of the LRM was not a good idea. They had concerns about issues such as: -continuous assignment to variables -initializer passed with with Type through parameters which is a new paradigm. Dave - bc was concerned with the part about init of struct. Steven - behaves differently from nets. - if drive with a continuous assignment, what do you do if ther was an init. - did not discuss the svec portion of rand portion. Neil - the svec wants to keep the part on randomization of struct elements. The struct initialization portion is not an svec concern. Mehdi - leave it for the champions. * AI Mehdi: send to champions meeting to decide, EC vote is still is there. Issue 283 (Mantis 615): [was passed in sv-ec, with 3 abstains, 1 no vote, champions had some concerns] There were 3 champions that gave the following feedback. http://www.eda.org/sv/sv-champions/Resolved_Issues_05_04_11.htm Need to reword first sentence of 5.6: One or dimensions of an array or queue can be dynamic... Add 2 dimensional example. We should consider making these changes. Stu said that he thinks that the BNF change is now in conflict with the text. Arturo: the issue is the array of arrays, not mulit-dimensional. Dave: the first paragarph was informative. * AI Dave: writeup a new addendum for the section on arrays to clarify. - It should only require a couple of extra words in one sentence. Issue 281: mailbox return value (-1,1 vs negative, positive) Neil: if value was relaxed to encode the values. Dave: if encode some other values, it should be specified in the LRM. If implementations are going to encode additional information the code could become non-portable Surrendra: it will not comply with LRM, Dave: what if return value is not what user expect. Surrendra: In the future, we can extend it, for now it * AI: Surrendra place it in Mantis, and place the proposal (create a new Mantis for this) we will vote on Monday. Issue 2 (Mantis 219) (fork-join and existing verilog disables) - From Steven Steven: second issue with return, what do normal verilog do with join-any/none Arturo: it should do what it does in verilog, terminate all instances of that code, but not terminate the subprocesses. Steven: some variation, xl kills everything, vcs. fork/join none could have exited, for continous assigment. Arturo: disable fork, executes that instance of the process. should be killed it is undefined,that all instances that are executing that code should be disabled, but should not disable join_any/none processes. Should be similar to the way fork/join is handled in verilog today. - disable_fork - tree only in instance of scope - A partial definition is better than nothing. Gordon - better to cover most cases and leave only corner cases unspecified. * AISteve - put together a writeup to cover the common cases. vote on Monday. 4) Next meeting Monday April 18th, 2005 1:00pm -3:00pm PST Action items: (4/15/2005): 1) AI(issue 233 ): Arturo write up the rules, Based on what is missing in definition. create a new mantis, place in svdb 2) AI(issue 238 - Mantis 671): Dave and Ray for new words on this, place in mantis. 3) AI(issue 240 - ): Gordon/Dave to send email reflector, to get closer to consensus 4) AI(issue 1 - Mantis 93): Brad to write up detailed proposal. 5) AI(issue 244 -Mantis 632 ): Mehdi to report it back to sv-bc. 6) AI(issue 229 - Mantis 644): Mehdi to send it to Champions for their final decision 7) AI(issue 283 - Mantis 615): Dave writeup a new addendum for the section on arrays to clarify. 8) AI(issue 281 - ): Surrendra, create a new mantis, create a proposal and place in svdb. 9) AI(issue 2 - Mantis 219): Steven: writeup to cover the common cases. =========================================== == Issues not yet resolved/voted on ======= Issue # Mantis # 233 ? (Surrendra - from sv-ac chair) bit-streaming of classes (writeup by Arturo) 238 671 (Ray) using clocking block (writeup by Dave/Ray) 240 ? (Mentor response) semantics of class ***** From sv-bc: for EC review 1 93 Optional argument list for subroutine calls [tasks() and func()] ---------------------------------------------------------------------- 281 ? mailbox return value (-1,1 vs negative, positive 2 219 (disable/fork-join item) 5 319 (root thread) 7 344 ( 8 370 ( chap 13.13 seed/RNG) 10 409 (ref arguments, should be taken care of with item 236 22 514 ( type for mailbox ) 36 270 (enhancement -- randomize) -- queues/concatenation) 13 412 23 517 24 520 -- program/scheduling semantics) 30 549 41 551 32 553 ----------------------- 94 511 ( type assignments) 95 512 (object copying) 96 516 (type compatiblity description) 97 518 ( queues, arrays, page 51) 98 519 ( empty array 99 521 ( queues, pattern assignment) 100 522 ( queues concatenation) 101 523 ( queue return type) 122 251 (enhancemet -- coverage) 123 253 ( coverage) 162 552 ( coverage -- BNF update) 171 564 (cross program references) 187 594 ( interface access through clocking block) 188 595 (invalid example clocking block assignemnt -- proposal) 190 597 (unnamed cloking blocks in bnf) 199 607 (accessing values in cloking block) 200 608 (clocking block value resolution) 201 609 (##cycle meaning in 16.14 ------------------------------------------------------ ============== SUMMARY of action items and issue items ============ == Approved issues === on April 15, 2005: 235 ( Mantis- 666) [approved on 4/15/05] 236 ( Mantis- 642) [approved on 4/15/05] on April 12, 2005: Issues approved: 232 ( Mantis- 652 ) [approved on 4/12/05] 236 ( Mantis- 642 ) [approved on 4/12/05] 189 ( Mantis- 596 ) [approved on 4/12/05] on April 11, 2005: Issues approved: 250 ( Mantis- 636 ) [approved on 4/5/05, re-approved 4/11/05] 252 ( Mantis- 637 ) [approved on 4/5/05, re-approved 4/11/05] 229 ( Mantis- 644 ) 230 ( Mantis- 646 ) 163 ( Mantis- 554 ) [one abstain -- Neil, (not read)] 255 ( Mantis- 641 ) [one abstain -- Neil, (not read)] on April 5, 2005: 11 ( Mantis- 410 ) 109 ( Mantis- 537 ) 161 ( Mantis- 550 ) 237 ( Mantis- 616 ) 250 ( Mantis- 636 ) 251 ( Mantis- 643 ) 252 ( Mantis- 637 ) 253 ( Mantis- 649 ) [combined with 254 into one Mantis (649) 254 ( Mantis- 649 ) [2 abstains: Francoise & Steven, no knowledge of coverage] 270 ( Mantis- 638 ) 271 ( Mantis- 639 ) [one abstain: Steven, not read the proposal] 272 ( Mantis- 640 ) 283 ( Mantis- 615 ) [Votes: 4 yes(Brad,Neil,Dave, Surrendra), & Mehdi 3 abstain:(Ray,Francoise, Steven), and 1 No (cliff)] Issues marked not feasible 204 Issues sent to other committees for review: 125 294 (sv-ac) (vpi question) 229 644 (sv-bc) (struct initialization) [NOTE: here is what sv-ec received on 229 from April 11th sv-bc meeting: The SV-BC reviewed the proposal to address issue 229 in its April 11th meeting. It was not approved. Here's the message that the committee agreed to convey to the EC: The SV-BC did not pass the proposed resolution to issue 229 as captured in Mantis #644. The motion failed with only abstention. Those abstaining felt that making such a change so late in the lifecycle of the LRM was not a good idea. They had concerns about issues such as: -continuous assignment to variables -initializer passed with with Type through parameters which is a new paradigm. -------------------------------------------------------------- Action items: (4/12/2005) 1) AI(issue 232 Mantis 652): Dave update the svdb mantis for this item 2) AI(issue 235 Mantis 666 ): Gordon to write up the proposal in mantis with the same proposal as in the spreadsheet. 3) AI(issue 236 Mantis 642) : Ray make the changes. Keep proposal A, get rid of the "...". Also close Manti 411. (duplicate) 4) AI(issue 238 Mantis ---): Ray - Create a mantis item and proposal for 238. - It will be an informative note on the race. 5) AI(issue 189 Mantis 596): Arturo place the proposal in the svdb. 6) AI(issue 240): Arturo - writeup on issues for 1. region crossings 2. scope extensions - also create a mantis entry. ---------------------------------------------- Action items: (4/11/2005) 1) Issue 250 (Mantis- 636): Ray to place updated proposal on SVDB. 2) Issue 252 (Mantis- 637): Ray to place updated proposal on svdb. 3) Issue 229 (Mantis- 644): Dave update proposal on svdb. 4) Issue 230 (Mantis- 646): Dave update proposal on svdb. 5) Issue 232 (Mantis- 652): Gordon to create a new proposal/svdb. 6) Issue 233 (Mantis- ? ): Surrendra to ask svac chair for clarifications. =============================================================== Action items: (4/5/2005) 1) For issues 270: Brad to place it on SVDB. -- Mantis: 638 2) For issues 271: Brad to place it on SVDB. -- Mantis: 639 3) For issues 272: Brad to place it on SVDB -- Mantis: 640 4) for issue 250 Ray, to fix the sentence, add to svdb -- Mantis: 636 5) for issue 252: Ray to place it in svdb. -- Mantis: 637 6) for issue 255: Brad to place proposal in the database -- Mantis: 641 7) for issue 229: Mehdi to send it to sv-bc for review/discussion of -- Sent to BC the first portion, initialization 8) for issue 229: Dave/Ray to put further details to the proposal for -- Mantis:644 review next Monday. 9) for issue 11: Brad to place the proper html proposal in svdb -- Mantis: 11 10) for issue 230: Dave to do the rewrite/rewording of the proposal -- Mantis: 646 11) for issue 233: Surrendra to write more clarification to the bit-stream operators for class, pack/unpack (for Monday discussion) 12) for issue 236: Ray to finish the proposal for default args, for -- Mantis: 642 Monday discussion, 'has to be visible, by caller..' 13) for issue 237: Brad to place into the svdb -- Mantis: 616 14) for issue 239: Brad to place into the svdb -- Mantis: 617 15) for issue 251: Brad to place into the svdb -- Mantis: 643 16) for issue 125: Mehdi to send to sv-cc for review -- sent to CC 17) for issues 253 & 254: Mehdi to add the proposal into svdb -- Mantis: 649 18) for issue 161: Brad to place into the svdb -- Mantis: 550 19) for issue 109: Brad to place into the svdb (Mantis 537) -- Mantis: 537 ===================================================================================