SV-EC Ballot Resolution Committee Meeting Monday April 18 2005, 11:00am - 1:00pm [Minutes distributed for approval at next (sv-ec) committee meeting] (01111) Day (41258) (00000) Month (44444) (00000) Year (55555) --------- Attendees ---------- (-AAAA) Arturo Salz (AAAAA) Brad Pierce (AA--A) Cliff Cummings (AAAAA) Dave Rich (AAAAA) Francoise Martinolle (A----) Karen Pieper (AAAAA) Mehdi Mohtashemi (AAAAA) Neil Korpusik (AAAAA) Ray Ryan (AAAAA) Steven Sharp (AA-AA) Surrendra Dudani (-AAAA) Gordon Vreugdenhil (-----) Bill Paulsen (----A) 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: Steven Abstain: Opposed: 2) Review Meeting minutes, April 11th, 2005 and April 12th, and April 15th 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 http://www.eda.org/sv-ec/Minutes/SV-EC_BallotRes_Meeting_April_15_2005_Minutes.txt Move: Brad Second: Ray Abstain: Opposed: approved 3) Miscellaneous P1800 meeting is tomorrow (4/19/2005) at 9am Austin time. This Thursday at 8am svbc will meet. 60 total ballot items for svec 23 now resolved 37 still open 3 high priority items were from negative ballots (240, 238, ---) 4) Voting rights Some people have missed meetings, have to start with 2 of last 3 attendance. Voting meetings must be announced 2 weeks in advanced. (Cliff) 5) Continue the resolution of ballot issues http://www.eda.org/sv/sv-champions/P1800_Committee_Assignments_05_03_29.xls Issue 283 (Mantis 615, 662): multi-dimensional arrays. [was passed in sv-ec, with 3 abstains, 1 no vote, champions had some concerns] If an array has any dynamic ...dimensions. Move: Ray in addition to 615 (BNF file) the new file 662 Second: Dave Abstain: Opposed: ***** 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 Ray: did we catch the case of function return value, Gordon: that was the note in 8.2, Brad: the text says it too. Arturo: do we need 'backward compatibility' Move: Brad (amendment 8.2 as well note, directly and no backward compatibility proposal in mantis (svdb) 93. Second: Gordon Abstain: Opposed: approved * AI: Brad to write up a proposal for description Issue 281 (Mantis - 683): mailbox return value (-1,1 vs negative, positive) Gordon: can we say non-zero positive. Ray: how about integral, Steven: the prototype define the return value Surrendra: int Brad: it should be integer. Clause 14.2.4 Replace "1" by "a positive integer" Replace "-1" by "a negative integer" Move: Surrendra (with Brad updating the document html format) Second: Brad abstain: approve: * AI: Brad update the proposal in the correct format in svdb Issue 2 (Mantis 219) (fork-join and existing verilog disables) - From Steven * AISteve - put together a writeup to cover the common cases. NO ACTION DONE: LEAVE FOR NEXT TIME Issue 233: bit-streaming of class No update yet - classes as bit-streamed type Arturo will have something today. * AI: Arturo write up the rules, place on Mantis Issue 238 (Mantis 671) using clocking blocks in modules may cause races Dave: it is not normative, Arturo - The race is between "The clock trigger and reading the sampled value." Move: Dave Second: Ray Abstain: Opposed: passed Issue 266: Cliff: currently in 3rd revision, by end of day will be done by tonight. Issue 240: (Mantis- 681 ) semantics of a class is based on where it is declared. Gordon - 1. scheduling Two proposals for this issue in Gordon's email a. schedulting semantics should follow semantics of the calling thread b. impose some restrictions about mixing declarations across scheduling regions. 2. Class extensions Arturo - proposal 1 is already in LRM (i.e. for tasks). Gordon - 17.5 talks about synchronizing program code and module task calls. Dave - when a program calls a task in a module. How does the program know if the task blocks or not. Steven - if there is no delay within the task it should just return... - doesn't want the behavior of a task to be dependent on the caller. Would possibly require two copies of each task. Ray - users usually object to writing things twice. Steven - could `include it. Arturo - not sure if this is an actual use model that will exist. - A well intended proposal but not sure if we need it. - If calling a task in a module. The module won't know if it will be called from a program. Dave - real issue is with class methods. - Arturo - inheritance complicates it. Let's decide on verilog subroutines first. Mehdi - Is it an issue of separate compilation? Gordon - If the intent of the caller is to use reactive q there will be odd behavior. Steven - If calling something down in the module let the user deal with the possibility of unexpected results. If it is in a module it should behave like a module. Arturo - The LRM in 17.5 should not say "executed" in a particular region. It is "scheduled" in a particular region. Gordon - Unfortunate coupling of regions with declarations. Mehdi - For some items we have agreed on a more restrictive solutions with the understanding that it is easier to lift restrictions later. Steven - Would require all proposals to be taken into account to come up with something that allows us to extend later. There isn't a lot of common ground to come up with something. Gordon - Allowing programs to call blocking tasks within a module is a main issue here. Current language excludes extensions. We may need to disallow calls to blocking tasks. We don't want to cripple the testbench by over-restricting things. Assumes a one-day f2f would allow us to get close or we would then realize that there is a deadlock situation. Dave - High level design may want to communicate with the program via a common object. If can't share a class between the two we need to get to that point. May require a f2f meeting. This issue is important enough that we should take the time to resolve it. There are corollary issues - ports of program block. What semantics do they use? 3 weeks tops - after a f2f. Arturo - A procedural interface like this is probably doable. - Agrees that the proposal is trying to resolve a real problem. - Synopsys definitely had a use model in mind when proposed the current LRM language. - There are even issues with calling a non-time-consuming task from the testbench (so-called loopholes). Dennis - P1800 - allowing more time would need to be a topic of discussion. - will definitely be discussed tomorrow. Ray - agree we need to step back and decide what the main issues are. Mehdi - Want to discuss the agenda for a f2f then 15 days Dave - want to be able to model at a high-level (eg build own mailbox and share across both regions) Want to have classes that are extended Today can have tasks/functions in interfaces Want to pass classes across the two regions. Not just re-use, want to share a type across regions. Gordon - there are restrictions on what can be done in these mixed-region contexts. In worst-case we would restrict calls to module tasks from the program block. This would however cripple the testbench. Defining classes in packages - what does it mean? Arturo - if extend across the two - don't we end up with a mixture. virtual methods are a problem. Dave - what if define a class in a package. or $unit create a handle to it in both module and program new it in a program pass the handle to the module Arturo - they would be different types. - If anything alters the behavior means it is a differnt type. Gordon - Is it possible to restrict the kinds of classes that we have in packages to be like c++ abstract classes. Not instantiable until know which domain it will be in. Could be extended in either region. Ray - requires the methods to be written twice. - Since in a non-region specific place it couldn't possibly contain region specific data. May need to `include the behavior. Neil - that allows the data to be passed around Arturo - this might be a possible compromise. Ray - virtual class in an unspecified region - extend it in a testbench space extend it in the module space - Two ways to get methods defined twice 1. `include 2. take this function twice Dave - possible make the decision when the handle is declared - can abstract classes be extended into other abstract classes? Gordon thinks it would be ok. Gordon - decide on semantics when extend the class. - new keyword may need to be required. Ray - is there data that is region sensitive? Dave - whether we use blocking or non-blocking types is also an issue. Gordon - I would write up a straw-man proposal today and send it to the sv-ec. * AI Gordon: write up a straw-man proposal on this concept of virtual classes send it to sv-ec for review 6) Next meeting A) Thursday April 21 2005 11:00am -1:00pm PST B) face-to-face: April 25 2005 10:00am-5:00pm Agenda for f2f -------------- - can code in a program block call a task within a module? a. semantics based on thread of caller b. semantics based on declaration of task - looking for a way to reuse Defining classes in packages Monday 4/25/05 - possible f2f - 2 weeks after we get proposal (5/03) - 1 week is too little. ======================================================================================== Action items: (4/18/2005): 1) AI(issue 1, Mantis 93): Brad to write up a proposal for description 2) AI(issue 281, Mantis 683): Brad update the proposal in the correct format in svdb 3) AI(issue 2 - Mantis 219): Steven: writeup to cover the common cases. 4) AI(issue 233 ): Arturo write up the rules, Based on what is missing in definition. create a new mantis, place in svdb 3) AI(issue 240 - 681 ): Gordon: write up a straw-man proposal on this concept of virtual classes send it to sv-ec for review 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) 240 ? (Mentor response) semantics of class 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 ===================================================================================