[sv-dc] notes from SV-DC meeting on 2010-09-15

Below are John's notes from the meeting today.

2010-09-15
----------

SV-DC Meeting Notes
 
Attendees:
v -11111 Jim Lear (Cirrus)
v 11-111 Achim Bauer (EXL-Modeling)
v 111111 John Havlicek (Freescale)
v 111111 Scott Little (Freescale)
v --1111 Scott Cranston (Cadence)
v 11111- Sundaram Sangameswaran (TI)
v 111-11 Gord Vreugdenhil (Mentor)
v 11-11- Top Lertpanyavit (Intel)
n -----1 Dana Fisman (Synopsys)
v -1-1-1 Ghassan Khoory (Synopsys)
v 11-1-- Ian Wilson (BDA)
n ------ Ken Bakalar (Mentor)
v 1-111- Kevin Cameron (obs)
v 11-111 Arturo Salz (Synopsys)
n ------ 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 -11111 Shekar Chetput (Cadence)
v 1111-- Martin O'Leary (Cadence)
n -1---- Francoise Martinolle (Cadence)
n 1----- Prabal Bhattacharya (Cadence)
  |-> attendance on 2010-09-15

SUMMARY: Requirements proposed by Kevin Cameron and a statement about
a communication meeting with VAMS were added to the roadmap document.
The roadmap document was approved.

The next meeting will be on 2010-10-06 at 11 a.m. CDT (UTC-05:00).

Roadmap document:

http://bit.ly/apjS6s

We have 8/13 valid voters without chair; 9/14 valid voters including the
chair.
SS joined later, making 9/13 valid voters without chair; 10/14 valid
voters
including the chair.

IEEE patent policy.
- GV moves. MOL seconds. 0n/0a/8y. unanimous.

Roadmap Document discussion.

Kevin Cameron's suggestions:

  R+1: [SHOULD] Mechanisms for type conversions to access nominal and
  actual power supplies (for accurate conversion of logic values to
  voltages etc.).

AB: Is this already included in aggregates? Does it need to be
mentioned separately?
KC: I did not understand the comment.
AB: This information could be put into an aggregate.
KC: I am open to suggestions of how to meet the requirement.
AS: I think the requirement to access the power supply is still needed.
AB: I see, dynamic access to actual power supply is a good requirement.

  R+2: [SHOULD] Mechanisms for back-annotating circuitry (parasitics
  and wiring) that work with the above mechanisms (so that post
  place-and-route simulations will work with the models using
  user-defined wire types).

KC: A problem with AMS development is that this capability did not get
in and mistakes
  were made.
MOL: This is AMS related.
KC: The requirement is neutral in
GV: Leaving this as "should" leaves us open to address the problem, but
there is a lot
  of stuff involved.
MOL: I think it's better to leave this to SV-VAMS merger.
KC: There is not a back-annotation mechanism in VAMS.
KC: We need to consider the mechanisms for back-annotation while
designing the SV-DC
  capabilities. We don't have to create the back-annotation as a part
of the development
  process.
AB: This requirement is interesting even for the digital side, e.g.
capacitances in
  huge digital designs with high frequencies
KC: Is SDF going to handle the needs going forward?
AB: It does not seem so. This is important for digital models and it
seems relevant
  for this committee.
MOL: This is also relevant for AMS. VAMS needs to be involved.
KC: There is no mechanism today. I don't care if this is also
considered by VAMS, but
  it is relevant here.
SL: Why is it a problem for SV-DC to study a general back-annotation
scheme?
MOL: There could be issues for merging.
SL: I think KC is saying it is fine to limit our consideration to the
digital space.
KC: My proposal addresses both AMS and discrete modeling.
AB: We need to resolve aggregate nets and it is good to take
back-annotation into
  account.
MOL: I think SV-DC and VAMS should do joint work on back-annotation.
There isn't yet a
  forum for collaboration. VAMS is currently avoiding discrete real
modeling. It
  would be better to wait until SV-VAMS merger is under IEEE to work on
back-annotation.
KC: You would agree that the scheme should be back-annotatable?
MOL: We should talk about it.
SL: What about moving this to items for another PAR?
MOL: That would make me more comfortable.
KC: I prefer to leave it where it is.
GV: I don't think it is feasible to do this in the current PAR.
KC: Did anyone look at the proposal?
GV: I am going to have issues with elaboration of large digital
designs.
KC: The proposal is very simple.
MOL: The requirement is to consider back-annotation. Maybe just
mention that in the
  roadmap.
KC: If you can't back-annotate the discrete modeling, there are going
to be problems
  in the future.
MOL: We're going to be at this for years.
JH: Is there a way to reword the requirement to make it more agreeable.

MOL: AB's wording seemed better. It is more a requirement than a
proposal.
KC: I'd prefer to switch "should" to "could" and leave the wording the
same.
JH: I don't see that the current wording suggests a particular
proposal.
MOL: I'm o.k. with this as a "could".

Sync-up meeting.

SL: Intention is to make sure there is communication between VAMS and
SV-DC, that
  Sri and I are aware of what we are doing. P1800 WG may also have
interest in how
  communication will occur.
MOL: So you could report back to SV-DC on the result of the sync-up.
MOL: If there are areas of contention, how would that be handled?
E.g., $tablemodel.
  Suppose we decide in SV-DC that $tablemodel needs to work one way and
VAMS doesn't
  want that to happen.
GV: Clearly we can't address that. There is no overriding organization
to address
  that.
MOL: I want to hear from Scott how that would work in practice.
SL: The communication will ensure that both committees are aware of the
technical
  issues underlying a conflict, but SV-DC will have to make its decision
in SV-DC.
  Vendors, e.g., don't want to have multiple implementations.
KC: We want to reduce the overall work. We don't want two equally bad
solutions.
GV: The discussion has reflected good faith interest in moving forward
with discrete
  modeling and also bear in mind VAMS.
MOL: Why can't we have a formal mechanism?
GV: That needs to go to the working group or IEEE level.
SL: We don't have authority to create a more formal mechanism.

MOL: We should talk about mapping between wreal and the mechanisms to
be developed in
  SV-DC. Want to change wording from "study mapping" to "propose
mapping". Don't have
  to have bidirectional map. It can be one-directional.
KC: Wreal could be considered a user-defined type.
MOL: The mapping could be quite simple.
IW: I don't like changing from "study" to "propose unidirectional"
KC: SV-DC could consider supporting all previously defined types in
user-defined schemes.
AS: I think we want to avoid this discussion here at this time.
GV: I agree.
GV: I object to have SV-DC commit to produce an artifact that is a
cross-standard
   entity. That has risk issues. If you appeal to a definition in
another standard and
   that definition changes, you have all sorts of issues. We don't want
to code artifacts
   of other standards into an IEEE standard.
MOL: Can it be made informative rather than normative?
GV: That involves the study. We don't want to put it in the roadmap.
GV: I think the current statement is clear enough.
IW: I agree that the statement of intent is very clear.
AS: I agree.
JH: I think that the study should occur before a commitment to results
is made.
MOL: What about the order in which things are done?
GV: I don't want to micromanage that in the roadmap.
KC: What about other types, from SystemC, VHDL, etc.?
MOL: I think the situation is different because VAMS is a
Verilog-family language.
MOL: When will the study happen?
GV: This is not an event. It's an ongoing process, like in other
technical committees.

Ballot of Roadmap Document

GV: Motion to approve the roadmap as currently written.
SS: Second
0n/0a/9y

SL: Working group is undergoing nominations, looks like they will
consider roadmap in
  October. Do we want to continue meeting in the interim?
SS: We could here from Cadence on wreal.
SL: Shekar had talked about presenting.
MOL: I will follow up with Shekar.
SS: We could also look at other languages, VHDL, and how mixed
implementation issues
  could be addressed.
SL: I don't want to move other language issues into our agenda. Folks
can look at this
  themselves and report back to us.
SS: What about getting reports from other committees like VAMS on their
plans?
SL: That is feasible.
AB: We could brainstorm about an application example to understand what
is needed
  to ensure that the methodology really works.
SL: We need to avoid conflicts with SV-CC. We will meet again in 3
weeks.

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