SV-BC/SV-EC 1800 Scoping Meeting Date: Feb 18, 2015 Time: 09:00am-11:00am PST * Roll Call Matt Maidment: Intel Brad Pierce: Synopsys Ray Ryan: Mentor Jonathan Bromley: Verilab Daniel Schostak: ARM Mark Hartoog: Synopsys Neil Korpusik: Oracle Arturo Salz: Synopsys Shalom Bresticker: Intel Dave Rich: Mentor Francoise Martinolle: Cadence Stu Sutherland: SutherlandHDL Sachin: Mentor * SV-EC Chair Matt explained that there currently is on SV-EC chair and open for a volunteer. Contact Matt or Brad or Karen Pieper if interested. * General Direction Roll Call Dave Rich (http://www.eda.org/sv-bc/hm/11673.html) "implementation differences from what the LRM specifies that are very confusing for the user community. I would like to see people bring these issues forward and addressed in the next PAR." Dave sees a lot of new users come into verification. New users cannot rely only on the LRM to do their job. Implementation has changed behavior to improve on LRM or adjust for other implementations. Other areas of LRM have never been implemented and would like to see those features removed. Jonathan agrees with Dave. LRM not in sync with tools and in cases not precise. Also would support removal of unimplemented features. Would like to focus on LRM clarity. Daniel would like to see some implemented but unspecified features properly standardized in the LRM. Brad asked for examples of implementations and LRM not being in sync. Dave provided 2. (1) No one has implemented operator overloading. (2) Chaining of method function calls. There are restrictions in the LRM that implementers have relaxed and ill-specified areas that implementers have constrained. There is a lot of divergence in covergroups. From BC perspective there are issues with 2-state wires and nettypes. Dave estimates that there are 3 years of committee effort required to resolve the most important issues. Mark Hartoog raised that interface and modport specifications can be improved. Neil asked if next PAR should prevent enhancements. Dave explained that some resolution of differences require enhancements. Brad asked who will be positively impacted by resolving these issues. Dave responded that users and implementers will be helped. Vendors can chase fewer implementation-specific issues. Users can proceed with their work without hitting LRM problems. Brad asked if improving the LRM will help address the problem or that training or books would suffice. Stu commented that users like the User-guide nature of the LRM. Response to Brad is that clarification simplifies training and books and user experience. Brad pointed out that vendors still have to support the old way, despite later fixes. So even fixes do not simplify vendor responsibility. Dave pointed out that vendors are working on new random constraint features. If there's no period for these requests to be added to the LRM then implementations will diverge. Ray: Agree with Dave in general. See user code with ifdefs for different vendors. It's an issue for each new user and slows user proficiency. There are some new areas like randomization of reals that would benefit from committee attention. Daniel: Mostly interested in clarification and enhancements in a few areas. Mark: Would like to resolve inconsistencies even to the point of stating where implementation can choose semantics. Neil: Clarification and minor enhancements. Not in full agreement to remove features that have yet to be implemented. Arturo: Focus on corrections and maybe minor enhancements. Shalom: I would like to see this time a more orderly effort to deal with a lot of the errata and clarification issues in Mantis. Selected minor enhancements- especially where there are clear owners to drive completion. Many of them don't require a lot of effort and are small, but collectively they add up to a significant cleanup. Francoise: In favor of clarification and small enhancements to bring implementations into alignment. Would like to see prioritization based on state of implementations- where they agree or disagree. Suggest doing review by feature and addressing the whole feature and not issue-by-issue. Interfaces and packages interaction with libraries is under-specified (Mantis 3048). Dave suggested re-organizing committees to better align with the work-for example merge EC and BC and focus on outstanding issues overall. Arturo would be open to this idea. Might make direction more cohesive and offer better visibility and trade-offs on what to pursue. Stu: Clarifications are important from both vendor and user points of view. Would not like to see scope of enhancements limited. Sees more work needed in assertions and classes. Implementations have created unique x-propagation semantics. Shows LRM x-propagation semantics insufficient. Would like to see one semantic standardized. Stu offered to be a champion of x-propagation but participation in standardization process beyond role as an editor is an issue. Matt: Users have a list of enhancements they would like not just clarifications. * Mantis Roll Call: 5015, 2583, 4607, 4764, 4763 (http://www.eda.org/sv-ec/hm/8540.html) 2502 (http://www.eda.org/sv-ec/hm/8543.html) 2117, 4703, 4698, 4927, 4928 (http://www.eda.org/sv-ec/hm/8544.html) 678, 2969, 2962, 4798, 4753, 2991, 2992, 1202, 2994 (http://www.eda.org/sv-bc/hm/11686.html) 2735, 2996, 3054 (http://www.eda.org/sv-ec/hm/8564.html) Shalom has created master issues to help group issues and provide a higher-level perspective. Interface master issues from BC side and Classes, randomization on EC-side (among others). Mark: 3047 & 3048 Dave: 2117/4703 Francoise asked if tagging requests would be a good way to identify interest. Dave responded that filtering based on tags does not seem to work. Dave added an entry to the 'target version' field called P1800-201X and updating items of interest. Jonathan asked that if updating the target version field, leave a note on the Mantis item to better understand the motivation. AI: All update 'target version' field Mantis items of interest. Matt will update items for those who do not have full Mantis account. AI: Matt check with Karen about a Mantis account for Daniel. AI: All enter new Mantis items if needed. * Non-Mantis Roll Call: Stu * X-Propagation: There are some related items in Mantis but they don't likely match how implementations are performing it. * Temporal assertions within classes: Users would like this. (4119 & 5068) Matt * Using reals in constraints (2841): Jonathan agreed this would be beneficial for users. * Wait statement expressions including function calls Daniel * Extend/inherit interfaces in a limited way. Arturo * Should there be more coordination with the UVM committee to understand how methodology and language might better collaborate? Arturo asked if there's any looming deadline or predetermination of LRM timeline? Neil thought IEEE requires an update every 5 years. Jonathan thought this has been relaxed to 10. There is a lot of work on-going in AMS, UPF and UVM that impacts these committees. Summary * Consensus is to include for errata and clarification. This could include minor enhancements for resolution. Strong consensus from vendors and users. * If there are major enhancements they should be done with sufficient contributors. Asking for these enhancements but requesting them to be implemented by same committee members will not succeed. * Would like to see global resolution of priority. During 2012 effort, BC and EC members were pulled into AC/DC work. Would like to ensure that AC/DC or any other major initiative is properly scoped. Should consider impact of 1801, 1802, AC, AMS/DC, 1735 and others. * Difficult to make recommendations without timeframe. Timeframe would influence scope. BC/EC should suggest timeframe and factor this into their proposal (short vs medium vs long) AI: Matt ask Karen for guidance. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Thu Feb 19 00:23:10 2015
This archive was generated by hypermail 2.1.8 : Thu Feb 19 2015 - 00:23:28 PST