RE: Notes from meeting on 2010-05-25

I meant the meeting from 2010-05-18. The meeting hasn't happened yet
today.

Thanks,
Scott

-----Original Message-----
From: owner-sv-dc@eda.org [mailto:owner-sv-dc@eda.org] On Behalf Of
Little Scott-B11206
Sent: Tuesday, May 25, 2010 8:16 AM
To: sv-dc@eda.org
Subject: Notes from meeting on 2010-05-25

Hi all:

Below you will find my notes from the previous meeting. I wouldn't
consider them official minutes. They are a representation of what I
captured although several sections of the meeting aren't represented.
If anything is inaccurate please let me know.

Thanks,
Scott

2010-05-25
SV-DC

Ken Bakalar (Mentor), John Havlicek (FSL), Gord Vreugdenhil (Mentor),
Achim Bauer (ind), Top Lertpanyavit (Intel), Kevin Cameron (ind), Arturo
Salz (SNPS), Dave Cronauer (SNPS), Ian Wilson (BDA), Ed Cerny (SNPS),
Scott Little (FSL), Tapan Halder (SNPS), Ghassan Khoory (SNPS), Jonathan
David (obs), Jim Holmes (Lynguent), Sundaram Sangameswaran (TI)

JH: Formed as an ad hoc committee under P1800 done at the last P1800 WG
meeting. The general call was for us to study discrete domain real
modeling and come back to the P1800 WG with a scope paragraph or
document. I don't think it has to be a long document. I think that the
P1800 will look at that and consider whether we will continue. We are
under an IEEE WG and are thus subject to IEEE rules. As a matter of
procedure we need to read the patent policy. I apologize that we don't
have currently a sharing facility to view these slides. I can read a
URL: http://standards.ieee.org/board/pat/pat-slideset.ppt

JH read the patent policy.

JH: Ad hoc committee charged to come up with a scope document for
discrete domain real modeling. We don't necessarily have approval at
this point to do technical work on the P1800 LRM or a dot standard or
anything like that. Presuming approval we will eventually move to that
state. From my perspective the primary user need that needs to be
addressed is simulation performance of mixed models. Analog solver and
Verilog-AMS are slow. We want to be able to create discrete domain
(digital simulator) models with real quantities. We have to consider
the whole use case. If we swap in these models we have to have the
ability to correlate and run the simulations efficiently.

AB: What do you mean by swap?

JH: There are several levels of models and they should interoperate.

??: This is called plug and play in the AMS world.

JH: We would like to avoid a large overhead in the swapping. We would
like to avoid having to do extra work to make things fit in.

??: There is additional information needed.

JH: Yes, but we need to be cognizant of how much.

??: Are you just looking for a generalization of Verilog-AMS connect
module methodology?

JH: It is more than that.

KB: When you say replace models?

GV: I want to address the CM question. CM do a domain mapping. I think
that JH is talking about doing a domain replacement.

KB: Can you explain more?

GV: If you retain electrical semantics you are going to have issues of
how to explain those in a pure digital environment. From a pure user
point of view if you want to substitute a model at one level of
abstraction you need to talk about the interconnect differently from the
domain.

JD: Most of the work I have been doing we don't ever substitute in
analog models. We tend not do type conversions. We code all of the
conversions between analog and digital by a circuit that does the
conversion.

KC: The CM stuff. We do it as modules b/c we need to maintain state.
You can do it with a function if you don't need to maintain state. CMs
convert one driver from one type to another.

IW: If you regard a domain as an indication that it is something that
you need another simulator type to deal with. If you have a junction
between analog and envelope you would need to convert between the
domains and then the types.

KB: Can we say that time is part of a type conversion function?

AB: What about conversion between discrete real and discrete logic you
may want to ignore transients of one type to another.

GV: I would like to make sure that we are talking carefully about 3
terms.
domain: analog domain vs. discrete domain...that is how I have been
using the word
type: also important
resolution: how you determine the final value on some net based on its
contributions
One thing that I think has been an issue in VAMS is that there has been
an unfortunate merging of type and resolution. We need to keep those
two points distinct.

??: Can we call it driver resolution?

IW: You take all the drivers and convert them to the same domain and
then resolve it to the receiver.

KB: Existing resolution functions are all without state.

IW: That is what the CMs do.

KB: Not quite.

JH: Can you give an example of why state is needed?

KB: Converting a baseband representation to a real signal flow
methodology is one example.

??: What if you have an 'x on the digital side, you don't want to set
the analog to 'x.

AB: Can we separate resolution function?

GV: Do people think that a full merge of the VAMS definitions are
required to make progress in this area? If we are only discussing
discrete reals then there is a subset of things that we don't need to
talk about.

JH: I don't believe that we need to integrate substantial or the whole
of VAMS into P1800 to make progress in this area. Exactly where the
boundaries are I am not sure but we need to be willing to look over the
fence and understand what is on the other side.

AB: I agree with this. I don't think we need to worry about continuous
behavior too much. Imagine if you have several real value drivers and
adding them in a resistive way. You add this up to a common RC value.
You don't have to solve this in an analog way, but you can know that it
lifts up based on a specific time base function.

JH: You should be able to model and check that efficiently.

KB: Can we ignore the interface to the analog side to focus the
discussion for a bit.

JH: We need to provide a scope to the WG, but we also need a longer term
vision. As we understand what can be done in phase 1 and phase 2, etc
that it ultimately leads to a good solution to the users.

AB: IMO, the real-valued resolution function will be important.

KC: The Mentor proposal on ADMS supports general user types. All of
this stuff has been done before in one way or another.

KC: We need to do user defined types with nets with resolution functions
and cross-type resolution with PWL.

AB: Scope, real ports and generic port types. You could specify a
vector or bus width with them. Generic ports in a way that you allow
for a real bus or real array. We want real value read/write XMR. We
might want to worry about synchronizing. Compliance w/ VAMS. Type
conversion or connect elements.

GV: This is far too detailed for a scope document. This will cause all
sorts of issues.

KC: Aim for what VHDL does for compatibility with user defined types.
Aim for better interaction between VHDL and SV.

JD: This is similar to what Qualcomm would want. Record or structural
real on a net. I don't care about real port types but being able to
drive a net with one or more values.

AB: I meant struct port.

KC: I think that the Mentor proposal does this.

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