[sv-dc] Notes from SV-DC meeting on 2011-02-09

Hi all:

Below are the summary-style notes from yesterday's meeting. Please let me know if you have any corrections.

Thanks,
Scott

2011-02-09
----------
SV-DC Meeting Notes

Attendees:
v 11111--11111 Jim Lear (Co-chair, Cirrus)
v 11111-11-111 Achim Bauer (EXL-Modeling)
n ---111111111 John Havlicek (Freescale)
v 111111111111 Scott Little (Chair, Freescale)
n 1-------1111 Scott Cranston (Cadence)
v -11-1111111- Sundaram Sangameswaran (TI)
v -11111111-11 Gord Vreugdenhil (Mentor)
n ----1111-11- Top Lertpanyavit (Intel)
n -----------1 Dana Fisman (Synopsys)
n -1-11--1-1-1 Ghassan Khoory (Synopsys)
v 11-11111-1-- Ian Wilson (BDA)
n ------------ Ken Bakalar (Mentor)
n 1--1111-111- Kevin Cameron (obs)
v 11111-11-111 Arturo Salz (Synopsys)
n 1--1-------- Dave Cronauer (Synopsys)
n ------------ Ed Cerny (Synopsys)
n -------1--11 Tapan Halder (Synopsys)
n ------------ Jonathan David (obs)
n ------------ Jim Holmes (Lynguent)
n ------------ Walter Hartong (Cadence)
v 111111-11111 Shekar Chetput (Cadence)
n --11111111-- Martin O'Leary (Cadence)
v 11-----1---- Francoise Martinolle (Cadence)
n ---1--1----- Prabal Bhattacharya (Cadence)
v 11.......... Abhi Kolpekwar (Cadence)
n -1.......... Steven Sharp (Cadence)
  |-> attendance on 2011-02-09
|---> voting eligibility on 2011-02-09

Abhi asked for clarification on the AMS alignment. Scott stated that the purpose of SV-DC is to provide a complete real-valued modeling solution within SV. We understand that VAMS exists and these features need to avoid complicating the ongoing SV-VAMS merger. AK agreed that we are on the same page.

Achim asked to discuss the recent mailing list thread regarding the addition of disciplines. There was discussion stating that disciplines are used to store a set of static attributes of a net. Jim asked if we wanted the discipline to store the resolution function. There was discussion about how to encode supply information in the net for use in resolution functions and also how to access supply information from the discipline using a resolution function. Shekar mentioned that encoding the information in two places (SV in the nets and VAMS in the discipline) could cause migration issues post-merger. Abhi stated that we have a complete solution for SV with the methods we are discussing and recommended that we stay away from introducing disciplines. The group agreed that we don't need to introduce disciplines for this work.

The discussion moved to the need for late association of resolution functions. Abhi stated that he doesn't see a need for late association of resolution functions, but he does see the need for a generic interconnect type. Jim stated that the struggled to figure out a solid use case where late resolution is needed. Arturo agreed that he couldn't make a convincing argument either. Scott stated that he is okay to require a resolution function in the nettype declaration if we have generic interconnect. Kevin made the point that supporting back annotation is a good reason to have late association of resolution functions. There was discussion of various schemes for back annotation.

Jim raised an example where there are 4 identical drivers. Two drivers are driving net1 and the other two drivers are driving net2. After back annotation he would like to change the resolution function for net1 and net2 or at least a constant/parameter within that resolution function. He wanted to know if that is possible under the scheme proposed by Abhi with generic interconnect. Arturo suggested that there should be an override scheme on a net by net basis. At the end of the meeting it was unclear if Jim's case could be handled. Scott encouraged Jim to send an example out the reflector for discussion.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.