SV-BC Meeting Date: Monday, November 22, 2010 Time: 9:00am-11:00am PST Toll Free Dial In Number in North America: 1-888-813-5316 Caller Paid Dial In Number: 1-650-584-6338 Meeting ID: 7839818 202213101 Day 285730629 111000000 Month 110998887 111111111 Year 000000000 aaaaaaa-a Matt Maidment - Intel aaaaa-aaa Brad Pierce - Synopsys aaaaaaaaa Mark Hartoog - Synopsys aaaaaa-aa Dave Rich - Mentor Graphics -aaaaaaaa Gordon Vreugdenhil - Mentor Graphics aaaa-aa-a Alex Gran - Mentor Graphics aa--a--aa Heath Chambers - Consultant/Trainer aaaaaaa-a Tom Alsop - Intel ----aaaaa Cliff Cummings - Sunburst Design aaaaaaaaa Shalom Bresticker - Intel -aa---aaa Don Mills - LCDM Engineering a-aaaaaaa Arnab Saha - Mentor Graphics --a-aa-aa Daniel Schostak - ARM aaaaa--aa Kaiming Ho - Fraunhofer Institute -a-aaaaa- Steven Sharp - Cadence aaa-aaaaa Francoise Martinolle - Cadence -aa-aa-aa Eric Coffin - Mentor Graphics --------- David Gates - AMD -a-aaa--a Peter Flake - Elda Technology --------- Scott Little - Freescale --------- John Havlicek - Freescale --------- Rishiyur Nikhil - BlueSpec ----a---a Jonathan Bromley - Verilab -------a- Greg Jaxon - Synopsys aaaaa---- Linc Jepson - 74ze Agenda + Review IEEE patent policy http://standards.ieee.org/board/pat/pat-slideset.ppt Reviewed. + Previous Meeting Minutes http://www.eda-twiki.org/sv-bc/minutes/sv-bc_10_11_08.txt Tom moves to accept minutes. Shalom seconds. No opposed. Abstain: Arnab (did not attend) Motion passes. + Port Declaration Clarification Discussion Shalom posted questions/comments to the reflector: http://www.eda-twiki.org/sv-bc/hm/10714.html 1. Differences between task/function ports (formal arguments) and module/interface/program ports: - Port direction can also be 'const ref' - Ports can only be variables, but not nets or interfaces - The default direction is input - 13.5.3 says, "The syntax to declare a default argument in a subroutine is as follows: subroutine( [ direction ] [ type ] argument = default_expression); The optional direction can be input, inout, output, or ref." Can a const ref port have a default? No one could definitively answer this immediately. 2. Default values are not inherited by the next port declaration. No disagreement. 3. The BNF does not allow default values for explicitly named ports. Should they be allowed? Was overlooked in default value proposal. 4. Interface ports (i.e., a port that is an interface, not a port of an interface): - No explicitly named interface ports? Should be clarified as not allowed. Would be an enhancement to allow upwardly passed interfaces. AI: Brad to file Mantis item for upward passing of interfaces. 6. ANSI: Consider the following case: "a, B b", where a is some port. B is searched for. If it is found to be a type identifier (the search rules have to be written), then b is a regular port. If B is found to be an interface identifier, then b is an interface port. What are the search rules for resolving 'B' as interface or data type? If B is defined as data type and interface, unclear which is chosen. Likely solution, if a type of a port is not defined as a data type, assume it is an interface. Only way for interface to take precedence is to rename either the data type or the interface. Another instance where ambiguity of interface between data type and design element makes use of interfaces complex and problematic. 7. ANSI: Following an interface port declaration, if the subsequent port only contains a port identifier (and possibly unpacked dimensions), then it is treated as a continuation of the list of interface identifiers. Otherwise, it begins a new type of port. LRM does not describe this. Additional langauge would clarify. 8. Inheritance rules: Current rules don't adequately cover the case where the data type is a typedef that may include unpacked dimensions. I think the basic rule is simply that everything to the left of the port identifier is inherited, everything to the right of the port identifier is not. Succinct rule. Not inheriting unpacked dimenions of user-defined type would be difficult for users to manage. + Interface Discussion Previous meeting indicated potential support for parameterized interfaces. Regarding http://www.eda-twiki.org/sv-bc/hm/10638.html and based on previous meeting, committee needs to decide on option to pursue the interpreted domain (like item C in Peter's list). No BC support for taking this direction. If this were relaxed, other strict type checking would have to be relaxed (e.g structs being compatible if derived from the same data type, not by their composition). Once that question is decided. Next questions to consider: Should Interfaces become more like classes? Should classes be extended to include some key features of interfaces? Fraincoise: Classes are dynamic objects. Interfaces are not. Not necessary to make interfaces classes. Too many class features to sort out in relation to interface usage. During elaboration, how do you resolve an interface name to an actual interface in the design? What constitutes the type of the interface? Q: Do you ask in order to resolve virtual interface assignement? A: Yes. Q: And to resolve type before elaboration? A: Yes. Brad: What's unique about interfaces? A: Bundling of wires A: modports A: Can contain structural entities Francoise: Makes sense to keep interfaces as a design element Brad: Interfaces not always hardware. Cannot instantiate a module in an interface. Shalom: Allowing multiple drivers of nets is useful. Francoise: Enough differences that interfaces need to be distinct from classes. Classes are better in that their types are well defined. Brad: Inheritence of interfaces and modports has been requested. Shalom: Inheritance has been requested for enums and modules among other elements. Kaiming: Dynamic nature of classes too radical of a change for hardware designers. Allowing interfaces and modports to be defined in a package may be sufficient. What are rules for resolving an interface "type"? What about Jonathan Bromley's point: Interface without modport is essentially a module. What about treating modports uniquely? December 6 is ok for next meeting. What about December 13? In January, switch schedule to every other week starting Dec 27th but skipping Dec 27 (Jan 10,24, etc.) 10:59 AM: Shalom moves to adjourn. Email Vote Sent - Respond by Dec 3, 2010 + Mantis 1106 (http://www.eda-twiki.org/svdb/view.php?id=1106) + Mantis 2395 (http://www.eda-twiki.org/svdb/view.php?id=1106) + Mantis 2889 (http://www.eda-twiki.org/svdb/view.php?id=2889) + Mantis 2929 (http://www.eda-twiki.org/svdb/view.php?id=2929) + Progress/Discussion for Top 10 Looking for proposal sketches or discussion for any of these issues. 696 - Complete 2310(1084, 1201) - Participants: Eric, Tom, Shalom, Steven, Wilson Snyder 3053 - Participants: Francoise, Mark, Alex, Kaiming 3055 - Participants: Gord, Mark 2991 - Champion: Tom, Participants: Steven 1566 - For future discussion 2114 - Similar to 3053. Have same group look at it. 210 - Participants: Shalom, Matt 3056 - Champion: Shalom, Participants: Steven, Francoise Action Items Complete 08/16/10 Brad update Mantis items passed by email vote. 11/08/10 Shalom to update proposal for 2889 11/08/10 Shalom to add proposal for 2929 11/08/10 Matt ask 1800 WG about proposal to have an implementation available to help reason about pre-processor. 11/08/10 Matt to include 2395 in email vote. Outstanding 05/10/10 Matt create Master Issue for WG-approved SV-BC Top-25 07/19/10 Matt follow-up about voting rules for technical sub-committee. Is there a limit on the number of reps from 1 entity? 07/19/10 Dave to post request to reflectors for clarification of 2108 07/19/10 Jonathan post some items for discussion related to 2114 to reflector. 08/02/10 Brad give SV-BC feedback on Mantis 2992 to Mehdi 08/02/10 Eric start reflector thread on Mantis 2310 08/02/10 Gord meet F2F with Mark when in Bay Area 08/16/10 Matt to rethink 210 in terms of configuration and alias. 08/16/20 All send Shalom feedback about prioritizing the issues raised in port declaration issue summary: http://www.eda-twiki.org/sv-bc/hm/10498.html 09/13/10 Jonathan show simple examples of virtual interfaces, sub-interfaces and base classes in modules to demonstrate different methods for connecting design and testbenches. 09/27/10 Tom post updated proposal to 696. 09/27/10 Review Shalom's list of interface issues and suggest issues to tackle now. 05/10/10 Matt create Master Issue for WG-approved SV-BC Top-25 07/19/10 Matt follow-up about voting rules for technical sub-committee. Is there a limit on the number of reps from 1 entity? 07/19/10 Dave to post request to reflectors for clarification of 2108 07/19/10 Jonathan post some items for discussion related to 2114 to reflector. 08/02/10 Brad give SV-BC feedback on Mantis 2992 to Mehdi 08/02/10 Eric start reflector thread on Mantis 2310 08/02/10 Gord meet F2F with Mark when in Bay Area 08/16/10 Matt to rethink 210 in terms of configuration and alias. 08/16/20 All send Shalom feedback about prioritizing the issues raised in port declaration issue summary: http://www.eda-twiki.org/sv-bc/hm/10498.html 09/13/10 Jonathan show simple examples of virtual interfaces, sub-interfaces and base classes in modules to demonstrate different methods for connecting design and testbenches. 09/27/10 Tom post updated proposal to 696. 09/27/10 Review Shalom's list of interface issues and suggest issues to tackle now. 11/22/10 Brad to file Mantis item for upward passing of interfaces.