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

2010-08-11

SV-DC meeting notes

Attendees:

111 Jim Lear (Cirrus)

111 Achim Bauer (EXL-Modeling)

111 John Havlicek (Freescale)

111 Scott Little (Freescale)

111 Scott Cranston (Cadence)

-11 Sundaram Sangameswaran (TI)

11- Gord Vreugdenhil (Mentor)

-11 Top Lertpanyavit (Intel)

1-- Dana Fisman (Synopsys)

1-1 Ghassan Khoory (Synopsys)

--1 Ian Wilson (BDA)

--- Ken Bakalar (Mentor)

-11 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)

111 Shekar Chetput (Cadence)

--1 Martin O'Leary (Cadence)

SUMMARY:

-Discussion of the roadmap document led to an e-mail solicitation of
roadmap content focusing on the requirements.

DETAILS:

IEEE patent policy as read - SL moved, TL second 0n/0a/13y

JH: Main thing that we need to talk about is roadmap document. Stated
in the scope that we would finish one by Sept. 15. Have had
presentations that give us ideas. Open to ideas regarding format and
length. My personal opinion is that we don't need tremendous detail. I
would say that 5 pages is an upper bound. It might be nice to have a
half page executive summary. Not trying to stop discussion. Are there
others who want to bring something forward? Cadence?

ShC: We have shared some wreal extensions with Accellera and are looking
into if we can share here as well.

MO: Is this roadmap something we have to follow strictly? Can we amend
it down the line? What are the implications?

JH: We are not currently authorized to do any work to create the
features we are talking about. We need to present a roadmap to the WG
to become authorized to do the work. I wouldn't consider the roadmap
set in stone. We should try to write it in a way that doesn't pen us
in.

MO: How does the process work for changing the roadmap?

JH: I am not sure. There are several results that could come from
showing the WG the roadmap. We could be told no; be told that there are
areas of concern that need to be adjusted; or be told that it looks good
and we are authorized to work on these things.

MO: Do you have an example of another roadmap to give us a sense of what
would be expected?

JH: I do not. Does someone have an example?

SL: WG has approved the standing subcommittees to work on specific
mantis items. My guess is that the roadmap should contains details like
you would find in a general mantis item. Things like generally what
areas will be changed and which committees need to be aware of the
changes.

MO: I would like some clarification from the WG about the procedures for
changing the road map, etc.

JL: I would like to see a rough example of a roadmap if you have one.
Is the roadmap more or less our work items?

KC: I would try to avoid details at this stage and focus on requirements
and use cases.

AS: The roadmap is requirements and a general direction.

JL: John you mentioned that you had tossed some items around on a
whiteboard. What was on the white board?

JH: real nets, composite nets, 4-state reals, resolution functions, type
conversion

SS: I think we need system functions that extend what Gord presented.
The ability to get information or affect the driver(s) is important.

JH: What about gleaning items for roadmap document from what has already
been presented? Arturo could you do that?

AS: Yes.

AB: Can I contribute?

JH: Yes.

JL: Are we going to create a features document instead of a requirements
document?

JH: Maybe?

AS: I think that is a concern that was raised last week.

JL: What are the primary use cases?

AS: I am not sure that the group has converged. I thought that we were
adding badly needed features to model analog at high speed.

JL: I believe that is true, but there are many facets to consider. I
was thinking about power supply modeling.

AB: My proposal addresses that requirement.

KC: Power domain modeling is missing in Verilog-AMS.

AB: That is why we should do it.

JH: Am I hearing that we should cast our roadmap in terms of
requirements?

JL: That is my preference.

JH: Okay, that is fine but we still need to address the feasibility.

AB: What is out of bounds?

AS: Adding a solver or electrical networks. Anything that interrupts
the event based solver would be problematic.

KC: I think we should stick to discrete but that doesn't mean we can't
do PWL.

AB: In a few weeks I should have an example showing that multiple
evaluations of the discipline resolution functions won't have a big
impact on performance.

JH: Can SNPS extract the items from your document in terms of
requirements?

AS: Yeah, that is possible.

JH: Anyone is free to send in their representation of what they think
should go in the document with a focus on requirements. I am thinking
in terms of what, why, and when. The what will be requirements and the
why will be use cases or some rationale for the requirements. The when
has something to do with effort and feasibility. I can send out an
e-mail that calls for that.

AB: If we have lumped components floating around do we want to address
this? Is there enough interest to focus this?

JL: Are you asking if we want to model a discrete resistor?

AB: My impression is that we need a more powerful methodology to really
address this problem. We would need things like events in the
resolution functions. I want to take a quick vote on this issue.

JL: I think this is well within the scope of what we are talking about.

AB: Do you believe that we need the capability to cause the reevaluation
of the contributors?

JL: We haven't thoroughly gone through the problem you are describing.
I am not sure that we can't do this with what we are discussing.

JH: Are you trying to take a straw poll in this meeting?

AB: Yes, I am trying to understand how important it is for us to address
the dangling analog components that may be hanging around the design.

JL: My experience is that we can likely handle these things with the
resolution functions that have been proposed.

KC: I would like to see the requirements at a higher level. Don't
necessarily say I need something because I want to solve the problem in
a specific way. Make the requirement on the general problem.

SL: Freescale's perspective is that this capability isn't one of our top
priority requirements. We think it is useful, but it isn't at the top
of our list.

KC: This is a good basic requirement. There is also a good reason to
have this just for a connectivity perspective. There are use cases
where you may not want to simulate but you want to be able to create
connectivity.

JH: There will be disagreements about what a requirement is and what a
high-level requirement is. We can work that out during the discussion.
I will send out a call for requirements. What else do we need to
discuss today?

SS: What happens with this roadmap?

JH: We will need to approve it as a body. Then it will go to the
working group where I will present it and there may be some discussion
and questions. There may possibly be some iteration. The WG will then
make a decision about the future of the committee and what we are
allowed to work on.

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