[sv-dc] notes form SV-DC meeting on 2010-11-17

Below are John's notes from the meeting on 2010-11-17

2010-11-17
----------

SV-DC Meeting Notes

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

IEEE Patent Policy
. Motion to consider it read: AS; JH. 0n/0a/7y (some valid voters had
not yet joined)

Thevenin Modeling (JL)
. JL presented the examples that were sent to the reflector
. SL: The examples illustrate the need for and power of user defined
types and
  resolution functions.
. GV: The examples are more detailed than what I showed, but they don't
contain any
  surprises from my perspective.
. AS: Does not show connection to digital. Can only put a limited
number of these
  models in before performance degrades.
. JL: This is not a substitute for Spice.
. Editorial remarks on virtues and vices of VHDL and SystemVerilog.
. KC: Conversion between discrete types and analog has been dealt with
in VAMS.
. Discussion of plug-and-play and conversions.
. AB: Another approach is to resolve on a net basis. Collect data on
  digital side and feed into equivalent analog. This is essentially a
  connect module. Net is a component too.

Example from SL
. GV: What is the difference between "wire" and "input logic"?
. SL: It's not so clear.
. GV: There is no difference.
. GV: The places where domain changes (real to logic and vice versa)
happen
  need to be clear. If these happen behind your back, then you are in a
bad
  place.
. SC: "wire" seems to be interconnect.
. GV: The intent is clear in this example. The problem is codifying
the
  general inference rules.
. SL: This code is representative of what is already kicking around.
  The intent is clear, but it doesn't necessarily agree with the
  language, and that is a problem.
. SC: Do you expect conversions to be put at certain places in such a
design?
  Or should a tool infer the conversions?
. SL: There are several options, and they have conflicts. It is nice
if
  the tool can automatically infer and place conversion elements.
Sometimes
  a tool will place conversion elements unexpectedly. It may be needed
to
  annotate places where conversion elements are expected.
. KC: Do you care if conversion elements are placed where you don't
expect
  them?
. SL: Yes, because it usually indicates that things are hooked up
wrong.
. PB: Sounds like the values are of primary importance, how they are
grouped
  and connected are secondary?
. JL: Like a void type?
. KC: Lack of type. The thing that's joining doesn't have a type.
. GV: Composite net could be one part of bus.
. JL: There seem to be two concerns.
. SL: Being able to convert from digital type to real and what
mechanism
  there should be to do that.
. SC: Record of two elements rather than array of two bits?
. SL: Want to be able to pass items of different types through
hierarchy
  and give them names.
. GV: Need to be careful about non-homogeneous arrays and when type of
  elements can change underneath people. It's important to say that if
  you want to describe interconnect in this manner, the array at this
  point cannot be used as a value. You can only talk about the
underlying
  elements, not the composite.
. AS: I have the same confusion and share the concern.
. KC: You use the wire to connect things, the wire does not have a
type.
. GV: That's not true. The wires have types.
. KC: You do not assign directly to wires. You assign to the drivers.
. GV: If you have an aggregated assignment to a bus, then there are
typing
  restrictions. There is a type resolution between the LHS and the RHS
  of an assignment. The '{ makes this clear.
. KC: You are confusing the types of the wires with the types of the
drivers.
. AS: SystemVerilog today defines wires to have types.
. KC: That is a confusion, it is syntactic sugar.
. GV: You can insist on viewing the world this way, but that doesn't
mean
  that the world actually is this way.
. GV: There are restrictions and assumptions regarding the homogeneous
  behavior of arrays and at what points various entities have types and
values.
. GV: SystemVerilog already has implicit conversion between logic and
real types.
  If you assign a real value to a bit vector, it will work.
. KC: We need to clean this stuff up so that simulations will work.
One needed
  clarification/change is that the wiring should be type neutral,
untyped.
. GV: That's not going to happen.
. GV: My proposal shows a way to have neutral interconnect without
messing with
  the existing types of wires.
. AS: Why should interconnect have no types?
. KC: You need this for plug-and-play.
. AS: Typing of wires is useful for creating structures and ensuring
that they
  get hooked up consistently.
. JL: What about GV's new interconnect?
. AS: That can be added consistently.
. KC: There are two problems -- dimensionality and type.
. AS: In order to make progress along the lines KC is suggesting, we
will need
  to have a more specific written proposal to review and discuss.
. AB raised questions about methodology and capabilities in a mixed
signal
  setting.
. SL: There are important questions in cross cutting methodology, but
there
  is no spice standard and we are working within the limits of
SystemVerilog.
. KC: The interconnect modules in VAMS were designed in committee.

SL: Our next meeting will be on 2010-12-01. People should think about
how we will move forward and partition work. I would like to be able
to get some volunteers at the next meeting so that people can ruminate
on some of this stuff over the winter holidays.

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