[sv-dc] Notes from meeting on 2011-06-29

Reminder: The meeting scheduled for 2011-07-13 will not be held. We will meet again on 2011-07-27.

SV-DC Meeting Notes

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

Upcoming dates to note:
2011-07-27 - SV-DC meeting
2011-08-10 - SV-DC meeting
2011-08-24 - SV-DC meeting
2011-09-07 - SV-DC meeting
2011-09-21 - SV-DC meeting
2011-10-01 - P1800 TC work ends

Agenda:
0. IEEE patent policy (http://standards.ieee.org/board/pat/pat-slideset.ppt)
   Please review these slides prior to the meeting if needed.
1. Schedule of next meeting (07/13)
2. Election of co-chair
3. Discussion of generic interconnect
4. Mantis 3625
5. Opens

SL directed attendees attention to the IEEE patent policy.

Scheduling was discussed briefly. It was decided to revisit the topic at the end of the meeting.

We discussed the election of a new co-chair. IW and AK expressed interest. IW still needed to get permission of management. SL will send out an e-mail requesting nominations prior to the next meeting.

There are several technical points that need to be discussed regarding the generic interconnect proposal. These points will be discussed among the vendors.

SL: FM wanted to discuss mantis 3625 today.

FM: We thought the current statement was wrong and wanted to say that the function has to be automatic and preserve no state and have no side effects. We decided to correct this in all places in the LRM. I brought this up in the BC meeting and there was a long discussion and the outcome is that they didn't want to change it. Do we want to make the change only for our section?

AS: I think the motivation is okay. The constraint is how much do you want to force the tool to check. Even an automatic function could preserve information using hierarchical references. Do you want to disallow side effects like printf, etc.?

FM: We stated that we would allow them for debugging purposes.

GV: This is that awkward place where you want to restrict what is allowed but in practice people need to debug this stuff. It makes it awkward to find a balance between what should the LRM be saying and what do developers actually need to figure out what is going wrong in their designs. I am going to stick with what I said before which is it is a general issue not specific to this committee. I would rather be consistent with it and if there is general consensus we can change it then.

AK: We are concerned that resolution functions are new and they have greater power to cause problems if we have this language. There is a great desire for these to hold state. I have talked to a lot of AMS users and their first reaction is, "Oh, this is a connect module." It is not and resolution functions don't hold state.

AS: I think it is okay to state that bad things will happen if you try to maintain state.

FM: We really don't want to allow functions that maintain state information.

AS: How do you disallow it? Doing the checks to disallow it is nontrivial.

FM: You are saying we can't check it?

AS: I am saying you can't do it without doing it conservatively. I think that is too restrictive.

GV: Solving it exactly is solving the halting problem. You can go and be restrictive, but you will have to be very restrictive. The intent is reasonably clear and if you want to make it a reasonably checkable error then I think it will be overly restrictive.

SS: I don't agree that the intent is clear.

AS: Yes, I believe it is clear. The system could cache the result and use that result again. I agree with the statement that we can't prove it so we have to tighten it too much. I don't know as this is the best committee to be resolving this. We can try to change it but we should change it for everything.

SS: My concerns is that there will be objection to changing it elsewhere because of backward compatibility. This doesn't apply here.

FM: Pure is defined in the LRM.

SS: I am fine with saying that it should be a pure function. That requires that it be automatic. Do you think we could get agreement from the other committees to have it be pure?

GV: I think we are going to have the same conversation we just had. It is all the same issues.

FM: We can add a note saying what we would like to see. What is our ideal wording?

SS: Did GV have a specific phrase for the wording?

GV: Me. No, I don't think what sufficiently pure is in these contexts is sufficiently clear. I would say that the function is dependent on its explicit inputs and the closure of the function is immutable during simulation. I am not sure that will be helpful to the average reader of the LRM.

SS: If we specify a property of the resolution function and the computation then we can avoid specifying the constructs it uses.

GV: Stating it behaviorly that at any point during simulation a pure function is one given the same explicit inputs provides the same output. That is the intent. We could say that it is the user's responsibility to ensure this is the case and implementation dependent behavior may occur if this property is violated.

SS: I don't see other language like that in the LRM.

FM: There is wording in the DPI section.

SS: Can we steal the wording there?

SS: I am proposing that we suggest as text saying that resolution functions should be pure and refer to the DPI section otherwise the behavior is undefined.

FM: Do we need to say should instead of shall?

SS: That is correct because we can't enforce it. We should say pure and have no side effects.

GV: I would like to address the definition of pure behaviorally rather than define it structurally.

SS: Trying to do it structurally you run into problems

FM: "A resolution function should be pure (see section 35.5.2) otherwise the behavior is undefined."

We discussed the next meeting and determined to skip it.

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