[sv-dc] notes from SV-DC meeting 2010-08-25

Hi Folks:

Below are notes from yesterday's SV-DC meeting. Thanks to Scott L. for
taking these. We've tried to capture the roadmap discussion for use in
creation of the roadmap document. If you have corrections, please send
them to the reflector as soon as possible.

J.H.

2010-08-25

SV-DC meeting notes

Attendees:

1111 Jim Lear (Cirrus)

111- Achim Bauer (EXL-Modeling)

1111 John Havlicek (Freescale)

1111 Scott Little (Freescale)

1111 Scott Cranston (Cadence)

-111 Sundaram Sangameswaran (TI)

11-1 Gord Vreugdenhil (Mentor)

-11- Top Lertpanyavit (Intel)

1--- Dana Fisman (Synopsys)

1-1- Ghassan Khoory (Synopsys)

--1- Ian Wilson (BDA)

---- Ken Bakalar (Mentor)

-111 Kevin Cameron (obs)

111- Arturo Salz (Synopsys)

---- Dave Cronauer (Synopsys)

---- Ed Cerny (Synopsys)

11-- Tapan Halder (Synopsys)

---- Jonathan David (obs)

---- Jim Holmes (Lynguent)

---- Walter Hartong (Cadence)

1111 Shekar Chetput (Cadence)

--11 Martin O'Leary (Cadence)

   |-> attendance on 2010-08-25

SUMMARY:

-SV-DC needs to elect a chair and co-chair. JH was just appointed by
the P1800-WG. JH is not going to stand for the chair. SL was nominated
as chair and JH as co-chair. Nominations will remain open until next
meeting. We will vote in the next meeting.

-Discussion of the Freescale roadmap items.

-MO and ShC will work on a draft of the roadmap. We will discuss that
in a meeting next week (2010-09-01).

DETAILS:

IEEE patent policy motion: GV 2nd: MO

JH: In the P1800 WG meeting chairs and co-chairs were discussed. Other
committees have standing chair/co-chairs. They are being allowed to
keep their current leadership until we get the new rules and the
associated FAQ. We need to elect a chair/co-chair. I can't answer what
the new rules will do to the eligibility of the various members of the
committee. We may have to change after the rules come out. I should
say that I am not going to stand for chair as I will be taking a medical
leave soon.

MO: Would you stand as co-chair?

JH: I could do that.

MO: What about Scott?

SL: I would be willing to do that. I don't have a great depth of
experience, so I am a bit nervous.

SS: I am happy with John/Scott. I would be willing to propose Kevin or
Achim.

JH: What do we want to do?

JL: How about we make nominations today and vote next meeting.

JH: That sounds good.

MO: Nominate SL for chair. SS second.

MO: Nominate JH for co-chair. ShC second.

JH: In the interim if there is interest in others serving in these roles
we can add them to this list.

JH: Main item to discuss is content for our roadmap. Sent out a
solicitation for content organized into 4 headings. We have seen items
from AB and Freescale. Are others planning to submit material?

ShC: We are looking to add some content that should be ready before the
next meeting.

MO: It is similar to what has already been sent.

JL: Can we start putting something together now? We don't need all of
the use cases do we?

JH: No.

ShC: Is the roadmap document all the work we can do or can we add items?

JH: The roadmap gives the P1800 WG something to make a decision as to
whether we should continue or not. If we deviate substantially the WG
may wonder what we are doing.

ShC: So, it is sort of like and abstract that gives a sketch of what we
will do. Once the abstract is accepted then we can fill in the details.

JH: That is a good analogy. The WG could be concerned if we are looking
to make large changes. How our work may impact the other committees is
another concern.

JH: Scott can you go over the Freescale roadmap contribution?

SL: Sure, I will go over the document I sent to the reflector. I
believe that was sent out on Friday and then Monday I sent out a 3 page
pdf with some figures. I will refer to both parts.

Discussed executive summary and use case 1. There were questions on use
case 2.

JL: Can't what is shown in use case 2 be done today?

SL: Yes, it is possible that it could. Although many of the required
items aren't fully standard. There is also the case where one of the
wires carries both current and voltage information. If we want to
connect that to a Spice net, connect modules as they exist today
wouldn't allow that.

JL: Can you clarify that case then? Indicate that both current and
voltage are on the wire.

SS: What about parameterized ports? Is that something that we are going
to address? It can be problematic as you move into schematic capture
environments. It works well in a command line flow, but we have
problems swapping models around with parameterization.

GV: I don't understand the exact problem. Can you be more specific?

SS: I will find a concrete example and get back to you.

SL: The first requirement is for real valued nets. There are also
parenthetical statements that give additional explanation as to how we
interpret the requirements. This one states that we would like to have
compatibility between SV real nets and wreal. Compatibility in the
sense that wreal could be connected to a SV real net. It may be
necessary to have some sort of compatibility layer.

Discussion by JL, KC, and GV around the fact that we shouldn't limit
ourselves by conforming to the wreal definition. There are several
issues with wreal and we want to be free to make the correct decision.
We should instead provide an general mechanism to convert between types.
This should enable a user defined net to be mapped into wreal.

JL: Should we strike reference to VAMS? The roadmap has a conversion
mechanism. Is that not sufficient?

MO: The overall intention is that VAMS will combine w/ SV. Overlapping
capabilities w/in languages is a concern.

JL: Removing wreal from requirements gives us freedom. Our intention is
that the mapping mechanisms will be sufficient.

GV: I don't think that we should start the integration of SV/VAMS in
this committee. That isn't our intention.

MO: I don't see why we can't do some integration and develop good
real-valued modeling capabilities.

JL: Is anyone opposed to removing wreal from the requirements?

MO: I am opposed.

JH: I think we should avoid the word compatibility. I think we should
show the mapping to wreal as a demonstration of the quality of our
mechanisms. If we can't do that mapping then the mechanism isn't
adequate.

GV: I agree. For us to say that VAMS stuff is directly pulled in is
bad.

SL: Discussed requirements on composite nets and then resolution
functions. The idea in the parenthetical statement is that standard
definitions for commonly used types and resolution functions would be
provided by the vendors and hopefully these would be optimized and high
performance.

MO: Built-in types provides performance. We don't want two different
ways to do the same thing after the SV/VAMS merger.

JL: I don't like the word predefined. I would prefer standard.

GV: SV has moved away from defining so many built-ins. As an example,
the list definition has been thrown out. The focus has been more on
getting core functionality and having other bodies to define packages
and/or methodologies using the core methodologies. Something along the
line of UVM.

JL: This raises another item for me. If we have an undriven net then it
would be good to have a user-defined default value.

GV: There is already a precedent for this in SV on associative arrays.

JL: Can we add this to requirements? Ensuring a default value is
applied to undriven nets and can be user defined.

GV: Or at least a mechanism if you don't have any drivers upon creation
then you could use user defined resolution functions to describe that.
No inputs to a resolution function could cause the correct value.

SL: Covered conversion mechanism (which should be updated to match the
conversation that happened earlier in the meeting). The generic
interconnect concept was mentioned. It is related to the third slide in
the presentation. We would like to address these requirements in this
PAR cycle. Does that seem reasonable? Are there thoughts from others?

MO: We will have to scope the work and we may have to prioritize.

JH: Achim has sent in other material. I guess we should wait on that.

JH: How to proceed? ShC had said that Cadence would contribute
something. Gord, what about how this relates to your proposal?

GV: I think today's discussion captured my thoughts. I want a flexible,
general mechanism that is able to describe as special cases things like
wreal and meets the users needs.

JH: It may be possible for us to give that intention in the executive
summary or some other non-contentious way. Is there a volunteer to put
together a first draft of the roadmap?

MO: I can take a crack at it. What is the timeframe?

JH: We will send out notes soon that tries to capture the discussion.
If it doesn't then people need to speak up soon. If we continue our
bi-weekly schedule then we only have one more meeting. I think we need
two more meetings.

JL: If there is a hard deadline in 3 weeks then we ought to meet next
week.

MO: Okay, we can meet next week and then work on it that way. Should we
do a Google doc? What about change management? We should consider
that.

JL: Google docs allows live viewing of changes which is nice.

MO: Will put draft of roadmap in on Google docs or the wiki before next
week's meeting.

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