[sv-dc] notes from SV-DC meeting on 2010-10-06

Below are John's notes from yesterday's meeting.

2010-10-06
----------

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

IEEE Patent Policy
. Motion to consider it read: GV; MOL. 0n/0a/8y

Discussion of Next Steps
. MOL: Cadence will give a presentation on wreal. This will be useful
as a
  foundation. It will be useful for someone else to make a presentation
on SV reals
  and SV composite types. Also, it will be helpful to have use cases,
especially
  illustrating use of composite types.
. SL: Do other people have interest in presentations along the lines
suggested
  by MOL? Wreal, SV composites, Use cases?
. GV: At what level does SV discussion need to be?
. MOL: There is a set of requirements; need to know the gap between
existing
  features and requirements.
. GV: I can talk to most stuff in SV digital. I need to understand
where the
  boundary is, what interactions people are interested in.
. JH: We could ask for people who don't have the knowledge to send in
requests
  for topics and put a short deadline and let whoever volunteers to make
a
  presentation decide on the scope.
. SL: We want to get started quickly, not spend more than a couple of
meetings on
  such presentations.
. GV: There is a big investment in creating such a presentation. I'm
not ready to
  commit to that now.
. SL: MOL, can Cadence present on wreal in two weeks, and how long
would it take?
. SC: That is feasible, we could plan for 45 minutes to an hour?
. KC: Is the material restricted to what is currently in VAMS? I'm not
particularly
  interested in the extensions.
. SL: The distinction between what is currently in VAMS and what may be
proposed
  needs to be clear.
. KC: Requirements going forward are fine; I prefer not to see
solutions.
. GV: Requirements that go beyond the donation are interesting.
. SC: Please send questions.
. GV: I don't have questions about the current state of wreal or the
proposed
  extensions.
. SL: In two weeks, Cadence will present on wreal. Questions should be
sent to
  the reflector.
. SL: GV, can you answer questions on SV real and composite types?
. GV: I can answer questions sent to the reflector and we can consider
a more
  involved way to respond, but I am not going to commit to prepare and
present
  training material.
. MOL: We also want to see use cases.
. SL: There have been examples presented. What needs to be added or
elaborated on?
. MOL: Practical examples where composite types are needed to solve a
mixed signal
  modeling problem. AB has discussed examples, but we didn't find them
clear.
. SL: JL's examples can also be studied.
. Others are interested in use cases as well.
. SL: What level of detail does it need to be at?
. IW: Skeleton outlines, fragments of code are useful.
. MOL: Where is JL's stuff? Do we have a website to upload examples?
. SL: There is a web doc that was sent to the reflector.
. MOL: We should set up an infrastructure for sharing examples and
information.
  Google doc, e.g.
. SL: Are there other users who can contribute use case examples?
. SS: I will check and get back on whether I can provide use cases.
. SL: Freescale ought to be able to provide some use cases.
. SL: After the background material, how should we move forward in
working on the
  requirements? Are there independent sets of requirements? Is this
serial work?
. MOL: Let's get the roadmap up on the screen.
. SC: Need to work on scalar types first.
. SL: Not sure, GV has suggested working on both together.
. GV: I want to work on the general solution first. Then we can
specialize to scalars.
  I don't want the solution to be fundamentally different between scalar
and composite
  types.
. MOL: It's something of a matter of preference; I prefer to work from
specific to
  general.
. SL: Is there concern that starting with the general case is prone to
get bogged down?
. MOL: We don't want to get lost in abstractions.
. GV: I certainly don't want to get lost in abstractions. We need to
look at how
  the mechanisms map to the cases of interest, like composites and
scalars. We should
  start with a strawman for the mechanisms and do frequent checks to
understand how
  the particular examples or use cases can be represented.
. SL: Need to define the list of mechanisms that need to be created,
determine
  what requirements are involved, whether they can be worked on
together.
. GV: An important mechanism is general user defined resolution
functions that are
  able to apply to different kinds of nets.
. MOL: How does this relate to the "must" requirements. This would
address multiple drivers.
  What about unknown or undriven values?
. GV: There are different approaches. We could consider them.
. MOL: What about the unidirectional and bidirectional ports?
. GV: How would one talk about dominating nets and net collapsing?
This needs to be
  done carefully with respect to new net types. Need to make sure that
relationships
  between user-defined resolution, new net types, and net collapsing are
handled carefully.
  There are some deep misunderstandings about how SV ports work.
. MOL: What are the relevant LRM sections?
. GV: You need to talk to your digital implementers. There is what is
in the LRM and
  there is what every implementer understands.
. KC: There is a lot of optimization in the digital simulators. There
is pushback
  when trying to add stuff.
. GV: If this committee tries to add stuff that is at odds with the way
things are
  implemented, there will be pushback.
. GV: An example is incremental vs. monolithic resolution. This
impacts, e.g., averaging
  resolution in Cadence donated extensions.
. KC: Need to consider longer timelines too. Perhaps taking a hit in
the short term
  performance to get a longer term viable algorithm is a good decision.
. GV: It needs to be discussed; it may not be a winning strategy.
. MOL: Are there new challenges in R08?
. GV: No, that is just a detail of resolution. E.g., current and
voltage may need to
  be resolved jointly. SV doesn't do this today.
. MOL: What about R09?
. GV: If you talk about 4-state real, you are going to have to talk
about how the
  4 states participate in expression evaluation.
. KC: X,Z can be dealt with as properties of a net rather than values
on the net.
  This can help optimization.
. GV: I'm not convinced that the 4-state value approach for reals is
the way to go.
. SC: Current SV resolution functions work on 4-state logic types.
When talking about
  user-defined resolution, are they supposed to apply to any user
defined type?
. GV: Yes.
. SC: Will the new real data type be hashed out after user defined
resolution?
. GV: I think we should define the general mechanism, then look at the
mapping to
  understand if it is sufficiently expressive to cover the real scalar
case. Until
  then, we can't make some of these further decisions.
. KC: We would like to move the capabilities into user-defined space.
Wreal could
  be done in a header or package.
. GV: That is the way to go. We all win with this approach. Specific
packages can
  be optimized directly. Users will not be dependent on committees to
add new types
  or resolutions.
. SC: How will we address compatibility with analog?
. KC: We will try to avoid incompatibilities.
. SL: We need to work within the limits of SystemVerilog.
. SL: Looks like first work will be on general user-defined resolution
functions.

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