________________________________ From: Neil.Korpusik@Sun.COM [mailto:Neil.Korpusik@Sun.COM] Sent: Friday, April 25, 2008 6:49 PM To: sv-champions@eda.org; Korchemny, Dmitry Subject: minutes of the April 24 conference call --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. Champions April 24, 2008 Conference call Thursday 8-10am PDT Attendees: ---------- 1. * Stu Sutherland 2. * Surrendra Dudani 3. * Brad Pierce 4. * Francoise Martinolle 5. * Shalom Bresticker (late) 6. * John Havlicek 7. * Dave Rich 8. * Neil Korpusik 9. - Karen Pieper 1. Review IEEE patent policy http://standards.ieee.org/board/pat/pat-slideset.ppt Move: Dave - assume the patent policy was read Second: John Passed unanimously 2. List of Mantis items for review 2.1 1757 SV-AC Property resets: accepton(b) P, rejecton(b) P - fixed - Was sent back to the svcc by the champions (December 20) - Extracted the vpi portion out into mantis 2336 - 2008-03-25: approved by voice vote 8y/0n/0a. - I did not explicitly check to ensure that the Champions feedback was addressed (Neil). Move: John - approve the proposal for Mantis item 1757 Second: Shalom Passed unanimously 2.2 1688 SV-CC Performance of VPI access to memories and MDAs is inadequate - fixed - On 04/09/2008 the SV-CC approved a motion to consider the changes made by Chuck Berking on 04/02/2008 to be within the scope of the friendly amendments approved during the 03/26/2008 meeting (unanimous). Dave - some of the cross refs aren't in green Move: Dave - approve the proposal for Mantis item 1688 Second: Stu Passed unanimously 2.3 1465 SV-BC 19.8: port declarations without directions - clarification - fixed - On March 25, 2008 the SV-BC unanimously approved the attached proposal. John - The proposal addresses all of the concerns that he had (see the bug notes for a list of those issues). - Somewhere it says tasks and functions use the same rules for port lists. Shalom - There are differences in the defaults. A module default port direction is inout, also wire. Not the same for tasks and functions. - In the future they need to be better documented. there is an open Mantis on that. Move: Shalom - approve the proposal for Mantis item 1465 Second: John Passed unanimously 2.4 2183 SV-EC Only simple identifiers allowed in solve-before constraint - fixed - unanimously approved by the sv-ec in the conference call of February 4, 2008 - Was sent back to the sv-ec by the Champions Feb 25. There was one sentence that both Stu and Brad questioned. "simply identify" was used in that sentence. - Approved on March 29 2008, unanimously, by email vote, sv-ec Move: Brad - approve the proposal for Mantis item 2183 Second: Dave Passed unanimously 2.5 2302 SV-EC Champions feedback for Mantis item 1447 - fixed - This mantis item was to address Champions feedback on Mantis 1447 - Approved by sv-ec on March 25 2008, unanimously. John - if slowest varying dimension is constant it is fixed size Neil - each dimension is viewed separately Shalom - an array of arrays (only single dimension of arrays) - if a chain - multidimensional array - for size of an array you look at the slowest varying dimension. Move: Shalom - approve the proposal for Mantis item 2302 Second: John Passed unanimously 2.6 2242 SV-EC issues with get_coverage(ref int, ref int) - fixed - Approved on March 25 2008, unanimously. Move: Dave - approve the proposal for Mantis item 2242 Second: Brad Passed unanimously 2.7 1503 SV-CC 27.33 VPI diagram of propertyinst has no vpiArgument - fixed - SV-CC PASSED this on 04/09/2008 (unanimous) with a friendly amendment to add #defines in the appropriate place in sv_vpi_user.h. This friendly amendment has already been incorporated into the proposal. - The following issues were reported late after the SV-AC and SV-CC committee approvals. SV-AC recommends that the champions provide the following friendly amendments: 1. In 36.76 Let declaration, a. This is dependent on approval of the let proposal: 0001728 b. vpiDefFile and vpiDefLineNo should be crossed out as was done on the other diagrams. c. A details note should be added of the semantic restriction that "seq formal decl" can only be a boolean expression, not a sequence or a named event 2. 38.5.2 ?verification statements? should be ?assertion statements? (2 times) 3. In diagram 36.45 Property specification, "clocked property" should be "clocked prop" to be consistent with vpiClockedProp and vpiClockedSeq This note was approved by SV-AC voice vote 2008-04-22: 7y/0n/0a - 1728 is one of the Mantis items under review by the sv-sc If 1503 is dependent on 1728, we need to wait for 1728 and the sv-sc. John - was approved by the svac - there were some issues noted after the vote was completed. The svac wants the Champions to send it back. Move: Stu - send the proposal for Mantis item 1503 back to the sv-ac so they can work on the issues that have been identified. Second: John Passed unanimously 2.8 2237 SV-AC VPI additions for 1667 - fixed - 2008-04-08: Passed by voice vote 9y/0n/0a. - SV-CC reviewed the subsequent changes to the proposal since our last review and on 04/09/2008 we PASSED it again (unanimous). John - changed some citations to reduce dependencies on 1503, it now just contains the true changes being made by this proposal. - the diagrams being changed are introduced by 1503 <Put this on hold until 1503 is completed - 1503 was sent back to the svac> 2.9 2326 SV-AC add VPI diagrams for property case - fixed - 2008-03-20: Voice vote 5y/0n/0a - The SV-CC reviewed this on 04/09/2008 and PASSED it (unanimous). <dependent on 2173 - which was sent to the sv-bc for review> 2.10 2246 SV-AC VPI definitions of assertkill need modification - fixed - 2008-04-08: Passed by voice vote 9y/0n/0a. - SV-CC reviewed this on 04/09/2008 and PASSED it (unanimous). Move: Francoise - approve the proposal for Mantis item 2246 Second: John Passed unanimously 2.11 1809 SV-BC forward references into $unit package - fixed - The Champions unanimously agreed to send the proposal back to the technical committee in the Jan 17, 2008 conference call with the expectation that the technical committee will be able to update the proposal such that more consensus is reached. - On March 25, 2008 the SV-BC unanimously approved the attached proposal. Shalom - What does the Editor think of this? Stu - A.1, A.2 and B.1 FM - The Editor can change the numbering. - There are two ordered lists. John - There are 2 separate algorithms being described. That distinction needs to be retained. Possibly add a heading for each of them. AI/Neil - add a bug note that the Editor can change the lists to conform to the IEEE standards requirements. Move: Francoise - approve the proposal for Mantis item 1809 Second: John Passed unanimously 2.12 2250 SV-AC VPI changes related to 1932 - fixed - On 04/02/2008 the SV-CC voted (unanimous) to accept this proposal provided the SV-AC update the proposal to reflect the change in the nexttime keyword. This friendly amendment has since been incorporated. - 2008-04-08: Passed by voice vote 9y/0n/0a. FM - vpiOpStrong isn't in the M.2 Source code listing. John - see last line of the proposal (it should have been Blue) Stu - he will be able to deal with it since that line doesn't exist. FM - 'strong' was added to avoid having two versions of lots of constants Stu - the complex assertion language makes the corresponding vpi complex Move: Francoise - approve the proposal for Mantis item 2250 make sure vpiOpStrong is added to the M.2 Source code. Second: John Passed unanimously 2.13 2333 SV-AC Champions feedback on 0002173 - duplicate of 2327 - 2008-04-08: Passed by voice vote 9y/0n/0a. John - The proposal writer created a new mantis item for the same item. Move: John - approve the resolution of duplicate for Mantis item 2333 Second: Stu Passed unanimously 2.14 1898 SV-CC Describe the explicit mappings from assertion system tasks to callbacks - fixed - 2007-11-20: e-mail ballot passed, 6y/0n/0a - The proposal was sent back to the SV-CC for review by the Champions in the December 20th, 2007 conference call. Dave - there are several vpi callbacks. FM - should be in the vpi section Dave - the scheduling semantic section introduces some callbacks. John - motivation was to show the correspondence - correspondence between tasks and callbacks. - Bassam added these. Stu - need a cross ref in vpi registercb(), that is where people look for a list of callbacks. and possibly other (vpicontrol) Editor to fill in actual numeric values (Stu is ok with it) - SV-CC reviewed this proposal and voted to accept it on 04/02/2008 (unanimous). FM - the svcc thinks it is ok. Stu - his comment on the cross reference is just a convenience thing. Move: Stu - approve the proposal for Mantis item 1889 Second: Francoise Passed unanimously 2.15 1698 SV-AC The description of sampled value functions is insufficient - fixed - The Champions sent the proposal back to the svac in the March 20, 2008 conference call. The TC needs to clarify clock inferencing for $rose (and all of the other sampled value functions). The TC has already acted on this feedback. - 2008-03-25: Approved by voice vote: 7y/0n/0a John - An example implied something was illegal if there was no default clocking. That raised the following question: What if there was a default clocking? - It was already stated in the proposal. - A continuous assignment from $past to a variable - that example was removed. FM - $sample - can use an inferred clock Is this capability tied to assertions in procedural code or checkers? Will assertions in procedural code use $sample? Surrendra - $sample doesn't have a clock anymore Stu - bottom of p4, iff is bold - should it be bold here? John - is 'ev iff expression2' a valid event? Dave - he thinks so John - iff can be used bo build an event_expression - the text is referring to counting gated events, not just the plain clocking event. Stu - doesn't like seeing contexts of $rose, etc. in conjunction with always_ff - not meant to be synthesizable code. Not illegal but he doesn't like that coding style. It isn't synthesizable sequential logic. Brad - is it sequential logic? Stu - It isn't sequential logic that accurately represents logic behavior Stu - A bigger issue is assertions in procedural code. This needs to be reviewed with the sv-sc with regards to procedural code. John - Is having trouble understanding the concern. Thinks of $rose(b, @(posedge clk2)) as getting the sampled value of b (at posedge of clk2) Brad - The issue is not synthesizability is it? Concerned about simulation? FM - $rose could be used just for simulation as well. Stu - Can't really put his finger on the problem, but there seems to be something missing on how putting $past into the procedural code is meant to work. John - If eval in a timestep - you compare the sampled value (preponed) with sampled value of b in timestep prior to the clock edge. There is a special rule for the beginning of simulation. That depends on the default initial value of the data type. Brad - Should go to the svsc? Stu - He thinks so. FM - Thinks that the inferred clock is the problem Dave - Inferring a clock in conjunction with checkers is similar. John - Doesn't think that anything is missing. - could say that the rules for clock inferencing are incomplete. Brad - Are any new concepts added by this proposal? Stu - Yes, $past() without specifying the cycle it is sampled on. Brad - Thought it was clarifying things. Stu - This doesn't solve the problem, if anything it compounds it. Doesn't see how it can always be inferring sampled points. Brad - This isn't a sufficient proposal for this mantis? - Sampled functions still not fully defined? Stu - Yes, that is correct. - Need to deal with it in same context as assertions in procedural code. - Not comfortable with just this, not sure when things will be sampled. - Wants all simulators to use the same rules. Move: Stu - send the proposal for Mantis item 1698 to sv-sc Second: Dave Abstain: Surrendra - thinks this is an improvement Opposed: John - the semantics are well defined provided the clock to the function is known. There may be issues in some cases, but not a reason to send to sv-sc. Should use a new mantis to deal with the incompleteness of the clock. Brad - same reason Dave - wants to send a new mantis to sv-sc to address Stu's concern In favor of the proposal (Francoise, Stu) Motion failed. Move: Dave - approve the proposal for Mantis 1698 Second: John Opposed: Stu - it isn't ready to be incorporated into the standard without more information on how to infer the clock. Francoise - same reason as Stu Passed with two opposed. Motion: Dave - open a new Mantis for the sv-sc to resolve inferred clock ambiguities with the sampled functions Second: John Passed unanimously John - action on the new mantis item could change the inferred clk. AI/Neil - open a new mantis item for this. 2.16 2327 SV-AC 2173 adds property case, need to add vacuity definition and multi clocking behavior in it - fixed - 2008-03-20: Voice vote 5y/0n/0a <dependent on 2173 - which was sent to the sv-bc for review> 2.17 2173 SV-AC Add case construct for properties. - fixed - 2008-03-20: Voice vote 5y/0n/0a Neil - should this one be reviewed by the svbc? FM - in svsc we decided it wasn't necessary Stu - doesn't see anything that needs to be reviewed. Dave - any possible issues with side-effects case expressions as constants. There are a lot of pieces of functionality that go along with a case statement. Shalom - Agreed with Dave's concerns. Move: Dave - send Mantis 2173 to the sv-bc for review Second: Shalom Abstain: Stu, Brad - not necessary Passed with 2 abstains (5 in favor) Stu - the note at the top says it is contingent on 1932 1932 - was approved by champions in April 10th meeting with friendly, was updated by Dmitry and reapproved by svac - note to the editor on page 16, if 1757 passes, move text from it to a new location in 1932. Stu - The Editor will have fun with this one. John - Both are touching the same section of the LRM. - People didn't want to write all of the proposals to be contingent. - It has become a challenge for the proposal writers. New mantis proposals will need to be with respect to draft 5. Stu - there could be some possible numbering issues. - ECD Friday for draft 5 of the LRM 3. Next meeting May 8, 2008 8am-10am (PDT)Received on Sun May 4 06:10:36 2008
This archive was generated by hypermail 2.1.8 : Sun May 04 2008 - 06:10:49 PDT