SV-CC meeting minutes October 15, 2002 9:00am PST Attendees: [--xxxxxx] Yatin Trivedi (ASIC Group, Chair) [-----xxx] Tarak Parikh (@HDL) [--xx-xxx] Francoise Martinole (Cadence) [xxx--xxx] Stuart Swan (Cadence) [------xx] John Amouroux (Mentor) [------x-] Emerald Holzwarth (Mentor) [-----xxx] John Stickley (Mentor) [------xx] Doug Warmke (Mentor) [--xx-xxx] Michael Rohleder (Motorola) [xxx-xxxx] Kevin Cameron (National Semi) [x-------] Tayung Liu (Novas) [-xxxx-xx] Bassam Tabbara (Novas) [-----xxx] Swapnajit Mittra (SGI) [--x----x] Darryl Parham (Sun) [xxx-x---] Simon Davidmann (Synopsys) [xx-xx---] Peter Flake (Synopsys) [xxxxxxxx] Joao Geada (Synopsys) [xxx-xxxx] Ghassan Khoory (Synopsys, Co-Chair) [xxxxx-xx] Andrzej Litwiniuk (Synopsys) [---x-xxx] Alain Reynaud (Tensilica) [x-----xx] Mike McNamara (Verisity) Yatin encourages everyone to communicate more via email. He feels there isn't enough work being done to further our contributions to the LRM. Discussion of face-to-face meeting in November. Yatin proposes Thursday, Nov 7. (Monday Nov 11 could be a backup date in case too many people can't make it Nov 7.) Yatin would like lots of technical progress before Nov 7 so that we can be very productive during the meeting. Discussion of meeting durations: Rather than biweekly 2 hour meetings, we will have a 1 hour meeting every Tuesday. The new weekly schedule will start next Tuesday, 10/22. Swapnajit suggests keeping a bug-tracking system to keep track of the issues that people bring up. Swapnajit can maintain the system. Yatin will forward Swapnajit's email which proposes the system. *** Minutes from Oct 1 meeting *** Joao proposes that minutes of Oct 1 meeting be accepted. Michael seconds, unanimous approval. *** Presentation of Coverage API *** Joao presents off the slide set. Two components of the API: 1) First is for use by designers/engineers 2) Second is for use by tool developers Some TB's, methodologies require runtime access to coverage data. Interest is to know how coverage is improving with simulation time. (Especially for reactive testbenches) 3rd party tools would like to be able to display coverage info just as well as the built-in simulator features. Need a good API to achieve that goal. The coverage donation was described as follows: There is a set of enums used in the API. There are 3 tasks: 1) Control task (turn on, turn off, query availability of coverage) 2) Acquisition task (obtains metrics for certain design regions) 3) Limiting task (obtains available limits for certain design regions) Tasks 2 and 3 can be used to derive a coverage percentage. The API is neutral as per meaning of the numbers returned by the tasks. The tasks operate on all kinds of coverage metrics (assertion, path, toggle, line, state, etc.) All tasks have some kind of design region control. Module-based, instance-based, all instances of module foo, etc. There is also an API available to help gather/control coverage for C-based testbenches. Joao terms this the "user coverage API". There is a further part of the API intended for 3rd party tools. It provides more detailed access to coverage. The spec only deals with FSM coverage at the moment. The API is used to gather the state vector for each FSM, along with other FSM-specific data. Discussion about usefulness of coverage if different tools produce different numbers regarding coverage. Currently there are no standards for measuring coverage. Joao makes the point that the API presented here remains neutral on this topic. Two ways of generating FSM vectors are 1) heuristics-based and 2) manual user-entry based. Discussion about "should SV-CC" be the one to standardize the technical details of coverage?" No strong enthusiasm shown about taking this on. Joao states: The API does not control what coverage does. It is just a mechanism for accessing what is done by the coverage tool built into the SV simulator. The point was made that the current FSM definition in the Synopsys donation may be slightly limiting. Right now it is a set of states and transitions. It could be extended to be more general. [Editor's note: sorry, I couldn't understand if any specific suggestions were made in this regard - please email those if you have them.] The suggestion was made to allow the API to give input into the tool to help influence the coverage numbers. For example, "consider these regions totally covered for path coverage". Discussion about limits. i.e. what does 100% coverage mean? Limits are defined by the coverage tool, but are static numbers based on properties of the design. Once again, there are no standards in this area - each tool will define its own limits for each type of coverage data. *** Currently Synopsys is not changing the coverage API and has no plans to do so except for incorporating feedback from SV-CC. Synopsys is amending the assertions API to incorporate more debug features (as explained previously). *** Deadline for acceptance vote on coverage API is Friday 10/18. Yatin will be corresponding with us on this topic. *** Yatin sez: Next week's meeting will address the issues that have been brought up in regards to each donation. Start with DirectC, then move to assertions, then coverage. Hopefully most issues will be addressed via email. The meeting can be used for voting and tie-up discussion. *** These meeting minutes were taken and edited by Doug Warmke of MTI, 10/15/02. Please email me if I made any notable errors and I can resend the minutes.