[sv-dc] Notes from meeting on 2011-05-18

2011-05-18
----------
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 111111111111111111 Scott Little (Chair, Freescale)
v 111-111-------1111 Scott Cranston (Cadence)
v 1111-1-11-1111111- Sundaram Sangameswaran (TI)
v 1-1111-11111111-11 Gord Vreugdenhil (Mentor)
n ---1------1111-11- Top Lertpanyavit (Intel)
n -----------------1 Dana Fisman (Synopsys)
n -1-11--1-11--1-1-1 Ghassan Khoory (Synopsys)
n 1----111-11111-1-- Ian Wilson (Accellera/BDA)
n ------------------ Ken Bakalar (Mentor)
n -----11--1111-111- Kevin Cameron (obs)
v 1111-111111-11-111 Arturo Salz (Synopsys)
v 11-11-1--1-------- Dave Cronauer (Synopsys)
n ------------------ Ed Cerny (Synopsys)
n -------------1--11 Tapan Halder (Synopsys)
v 11-111------------ Jonathan David (Qualcomm)
n ------------------ Jim Holmes (Lynguent)
n ------------------ Walter Hartong (Cadence)
v 111111111111-11111 Shekar Chetput (Cadence)
n --------11111111-- Martin O'Leary (Cadence)
v 11111111-----1---- Francoise Martinolle (Cadence)
n ---------1--1----- Prabal Bhattacharya (Cadence)
v 111-1111.......... Abhi Kolpekwar (Cadence)
v 111111-1.......... Steven Sharp (Cadence)
n 1-1--1............ Kishore Karnane (Cadence)
n 1----1............ Dave Miller (Freescale)
v 11111............. Jess Chen (Qualcomm)
v 111............... Mark Hartoog (Synopsys)
  |-> attendance on 2011-05-18
|---> voting eligibility on 2011-05-18

Upcoming dates to note:
2011-05-31 - E-mail vote ends (mantis 3398)
2011-06-01 - SV-DC meeting
2011-06-15 - SV-DC meeting
2011-06-29 - SV-DC meeting
2011-07-13 - SV-DC meeting
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

0. IEEE patent policy (http://standards.ieee.org/board/pat/pat-slideset.ppt)
Accept the IEEE patent policy as read.
Move: GV
Second: AS
Unanimously approved.

1. Accellera representative to SV-DC (Clarification from Karen re: IEEE SA advanced members)
SL: Ian Wilson is the Accellera representative to SV-DC. He will join as an active participant and represent Accellera. Ian will work closely with the Verilog-AMS committee to represent their interests on SV-DC.

SL: Karen has clarified that IEEE SA Advanced members may participate until 3 months after the invoices for the additional P1800 fees have been out. This clarification allows representatives from TI and Qualcomm to become active participants until August 1. They can continue to actively participate after that date if they pay the additional P1800 fees. If the fees are not paid they may participate as observers.

2. P1800 Draft1 availability
SL: The Draft1 of the P1800 standard is available. All mantis items should now be created in reference to Draft 1. If you need a copy of Draft1 please let me know. I can provide instructions for obtaining the draft.

3. Discussion of updated proposal for user-defined nets and resolution functions (Mantis 3398)

FM: The changes are mainly editorial.

AS: What is meant by "time zero driver changes"? How about, "...during the guaranteed call, which may precede or follow any driver changes at time zero."

After the initial call, the resolution function evaluation is scheduled based on changes to the drivers. Can we change that from scheduled to called?

GV: The change doesn't immediately induce a call. It is scheduled.

JC: Is it possible to create an initialization loop? Can I get a warning for this?

AS: Sure. You can create a loop.

SS: I am not sure it is possible to do this only with resolution functions. Something else would have to intervene.

GV: There isn't a specific warning specified in the LRM. That would be vendor-specific.

GV: We can drop the sentence if AS doesn't want the word scheduled.

SS: Okay, let's drop the sentence.

AS: Do we want to say that atomic nets must be fully driven and then say what restrictions that prescribes?

SS: Sure. One advantage is if someone finds another way to do it the intent is clear.

JD: I have a question of 10.3.2. It says that the entire nettype must be driven. I presume I only have to drive the values that I know?

GV: No, everything must be driven.

SS: These rules don't deal with aggregates of atomic nets. If you have an array of atomic nets I don't think these rules are general enough. You will have to go down element wise until you hit an atomic net. This can be dealt with later as the intent seems clear.

SS: What happens if you have a strength on a driver and connect it to an atomic net? Ignore or error?

GV: I would regard it as a conversion and it would be ignored.

SS: I wonder if you should warn the user about this.

AS: Shouldn't it be an error.

GV: I think that making it an error would take away potential options.

SL: I would like a warning.

JC: Why do we need an interconnect in the first place?

AK: Looking to define and interconnect that will allow the ports of two nettypes to be connected. Currently all ports through the hierarchy need to be declared the proper nettype. With addition of generic interconnect the path through the hierarchy could become generic interconnect and allow model swapping to be handled more easily.

GV: There are three major items we can potentially deal with in this PAR cycle. 1. The basic idea of how you define resolution and user defined nettypes 2. typeless interconnect 3. change resolution binding, etc. This proposal only addresses the first part. We could wait until we have a complete solution, but that will be a bunch of additional discussion.

JC: How will the tools work with these new types?

GV: I expect that if you are netlisting out from a schematic capture environment that the netlister will be modified to handle the typing for you.

JC: What about integral types? Is real excluded from the new nettypes?

GV: No.

SS: Currently only integral types and aggregates of integral types can be used on nets. This proposal extends that to allow integral types and real types as well as unpacked structs and fixed size arrays of integral and real types.

AK: We will take an action item to publish version 9.

4. Vote on mantis 3398 (http://www.eda-twiki.org/svdb/view.php?id=3398)

GV: Can I suggest an e-mail vote due to the number of changes made today?

SL: Yes. The vote will close on 2011-05-30 which is the day before our next schedule meeting.

5. SV-DC next steps and poll results.

SL: Generic interconnect seems to be the top of folks lists. Arturo seems to have a different take. How would folks like to proceed?

GV: I would like to see a sketch of Arturo's idea.

AS: The general idea is that you can bind late and then the types can be determined at a late stage.

GV: The netlister concern comes up in the situation where you need to go through the hierarchy and that type needs to be defined. How does this proposal deal with that?

AS: I don't have a specific mechanism in mind to deal with that.

GV: The late binding is sufficient to change the resolution function, but I don't think it is sufficient to change the type.

AS: I was thinking it was sufficient, but I guess it is not. I thought you could maybe change the type with the resolution function.

GV: Changing the type of things in the intervening levels is hard in a safe and composable way if you can have operations on that type in the intervening levels. One thing I want to say is that you can't have operations on generic interconnect.

AS: Operations?

GV: Assigning.

FM: You can only read a generic interconnect?

GV: I am not sure I want to allow that. I can put together a proposal sketch for generic interconnect prior to the next meeting. It will have to wait until a day or two before the meeting as I am swamped before then.

ShC: How are we going to prioritize the work that needs to be done?

SL: In the next meeting we will hear from Gord regarding generic interconnect. Based on the poll results that is our top priority. Any remaining time will be given to other proposals on poll items. We can also entertain proposals on clarifications of 3398 like the one SS mentioned today.

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