SV-EC Meeting Minutes 19 August 2002 (--a--) Adam Krolnik (LSI Logic) (---a-) Alec Stanculescu (Fintronic) (a-aaa) Cliff Cummings (Sunburst) (-aaa-) Dave Kelf (Co-Design) (aaaaa) David Smith (Synopsys) (-aaa-) Dennis Brophy (ModelTech) (---aa) Francoise Martinolle (Cadence) (aa-aa) Heath Chambers (HMC) (aaaaa) Karen Pieper (Synopsys) (aaa-a) Kevin Cameron (National) (---a-) Kurt Takara (0-in) (--a--) Michael McNamara (Verisity) (aaaap) Mehdi Mohtashemi (Synopsys) (-aaaa) Neil Korpusik (Sun) (aaa--) Paul Graham (Cadence) (aapaa) Peter Flake (Co-Design) (a----) Roy Armoni (Intel) (aapa-) Simon Davidmann (Co-Design) (-aaaa) Stefen Boyd (Boyd Technology, Inc.) (aa---) Steven Sharp (Cadence) (-aaaa) Tom Fitzpatrick (Co-Design) a => Attended p => Attended by proxy - => Missed Action Items: 1) Kevin: Add detailed description of requirements for Data Channels. 2) CC to develop FSM slides. 3) CC and PF to discuss FSM enhancements and implied register types. 4) All proposals for top 6 items must be in by 15 September. 5) David S to send out notice to SV-EC/SV-BC confirming meeting date and topics 6) David S to put all notes regarding the Vera donation into a single document Item for BC: Peter to add clarification for how a = (b = c); when there are issues with the sizes. 1. Review and approve minutes Proposal: Accept minutes Proposed: David S. Second: Tom F Approved unanimously 2. Review action items (see list below) Kevin sent email proposal for his action item (1) Mehdi sent email answers for his items (2 & 9) Item 2: Item 9: Limited to 64-bit Cliff has not yet done his items (4 & 5) Cliff asked about goto statement, usefull for implicit fsm coding style. Wants it to be synthesizable. No one asked Tom F. verified that enums are auto-casted (item 8) David S noted clarification of donation agreement for Synopsys Vera lite donation. (Item 7) David S asked about moving meeting to another date so more people could make meeting. Since tickets have already been purchased, meeting will continue. Probably will not discuss intefaces, but David S to consider this and send out email. (Item 6) 3. Review status of the outstanding extensions proposals: Review Kevin's proposal for process control requirements: 8/12/02 email Peter - Syntax has potential problems in that it makes the process statement into an expression. Suggested use of $getpid for child setting pid somewhere in global variable. Kevin - Dynamic process is like software... looking to C for syntax ideas. Can do it by saving variable but doesn't prefer. David S - We are not in C... Francoise M - Asked if this could be done using pli? Why are there dynamic processes? Peter - Originally for: dynamic pipeline for behavioral synthesis verification tasks Francoise M - Is process control required for these applications? Peter - Not for the first, but for the second. David S - Since it can be used for both, is control even an issue for synthesis. Isn't it static? Peter - For synthesis, process is simple. Putting control in the process is simple. Kevin - No current methodology for synthesizing dynamic processes, so what matters is other uses. David S - Shall we continue this discussion after we Francoise M - Asked about statement in proposal that states that there no mechanism to disable process. But noted existence of disable for named blocks. Arturro - Although disable might be able to get all processes, sounds like Kevin wanted only individual process. Kevin - Might be good to wait Proposal will be picked up again after testbench donation has been reviewed. Channel Proposal (Dated 8/8/2002 from Kevin Cameron) Kevin - Example is an abstract fifo that doen't have problem Tom - Superlog has syntax to handle the same kind of behavior. Kevin - It's not as efficient. Tom - Behavior in proposal differs from Verilog language semantics for registers. Kevin - Doesn't have models inside of an interface. Tom - If there are clear requirements, they can probably be met with current SystemVerilog. Stefen - Confused as to what Kevin requires that isn't already in SystemVerilog. Kevin - Wants to replace C++/pli mess with SystemVerilog solution. If he could call interface from C, that would solve his problem. David S - Requested email discussion, particularly problem descriptions that demonstrate why 4. Continue review of Synopsys donation Start page 21: increment/decrement on enumerated types Cliff - Looks like this requires keeping track of order and values in separate lists Tom - Note that this makes the operator different in the way it acts on enum from other types, such as registers. Arturo - Works with strong typing of enums. Note: ++/-- operators on enum are different from SV (although behavior of ++/-- in SV isn't completely nailed down yet). Page 22: Note: Wild equality, inequality, lhs concat diff from SV. LHS concat is artifact is artifact Cliff C - Looks like wild equality/inequality has value. Note: Bitwise nand, bitwise nor, bitwise xor not from SV. Peter - concerned about non-associative nature of operators. Precedence: no conflicts with SV Tom - What does unary plus do? Cliff - Same as SV. Note: last sentence on page 24 should mention z as well as unknown. Note: Page 1-26 needs mention of bitwise operators. David S - Page 28 has mention of type real Arturo - is mistake and paragraph needs cleanup. Note: Paragraph at top of 28 needs rewrite Page 1-28: Strings consistent with SV Tom - Is null a reserved word. Arturo - Null is not the same as empty string. Note: need definition of null (perhaps in string section). Note: Page 1-29 needs form shown that includes nested concatenations Page 1-30: assignments and use of increment/decrement +=, -= are consistent with SV. Page 1-31: compound assignment of SV is not supported by Vera. David S - Why not use right associativity in SV? Peter - It prevents accidental assignment. It doesn't require a smart parser - making parser easier to write. Arturo - What happens when the sizes are not compatible? David S - Asked Cliff to add BC item for tracking this in SV spec.