[sv-dc] SV-DC notes for 2010-07-28

Hi Folks:

Scott Little's notes from our latest meeting are below.

J.H.

-----Original Message-----
From: Little Scott-B11206
Sent: Thursday, July 29, 2010 7:55 AM
To: Havlicek John-R8AAAU
Subject: My SV-DC notes for 2010-07-28

2010-07-28
SV-DC meeting notes
 
Attendees:
11 Jim Lear (Cirrus)
11 Achim Bauer (EXL-Modeling)
11 John Havlicek (Freescale)
11 Scott Little (Freescale)
11 Scott Cranston (Cadence)
-1 Sundaram Sangameswaran (TI)
11 Gord Vreugdenhil (Mentor)
-1 Top Lertpanyavit (Intel)
1- Dana Fisman (Synopsys)
1- Ghassan Khoory (Synopsys)
-- Ian Wilson (BDA)
-- Ken Bakalar (Mentor)
-1 Kevin Cameron (obs)
11 Arturo Salz (Synopsys)
-- Dave Cronauer (Synopsys)
-- Ed Cerny (Synopsys)
11 Tapan Halder (Synopsys)
-- Jonathan David (obs)
-- Jim Holmes (Lynguent)
-- Walter Hartong (Cadence)
11 Shekar Chetput (Cadence)

SUMMARY:

A discussion of Gordon Vreugdenhil's framework document.

DETAILS:

KC moves to consider IEEE patent policy as read. SL seconds.

JH: Is someone willing to take minutes? [no one volunteered] Please
think about it but we will continue as we have been.

GV discusses the framework document he sent out.

GV: I don't want to cover the entire document. I want to start with
Section 2 and talk from a high level. This isn't a formal proposal or
Mentor donation. These are just some ideas we have been kicking around.
I hope we can use it as a basis for discussion.

There are two primary requirements that I have heard for real valued
discrete modeling. How you actually represent things is one item.
Another thing that is very important is the ability to move back and
forth between AMS descriptions and digital descriptions and manage
pinouts in a very general way without a lot of management of the port
maps. I am also postulating some requirements from the digital side
like the requirement that there doesn't need to be a solver.

AB: Does this mean no solvers ever?

GV: I say at the end of the section that this doesn't preclude some form
of efficient solving. I don't want to preclude it in the future, but I
don't want to require it in this round. This gets into the feasibility
assumptions. I think it would be a huge issue if this committee
proposes significant changes to existing SV semantics.

I am not assuming strict compatibility w/ VAMS as long as there is a
reasonable path to compatibility.

Section 2.1 talks about some substitutability. I believe that we want
to have a good substitutability model and the pin outs is a big deal. I
believe that a good long term solution requires composite nets.
Conceptually the composite net describes a single wire or connection
point.

Section 2.2 is a first level description of the resolution model. In
the analog world when you look at a node there is a set of equations
that are solved simultaneously. That is not the way the digital side
works. One thing that will need further discussion is that if you talk
about a connection that describes something analog can you adequately
model it using the digital solving style

Section 3 talks about the generalized interconnect model. What I am
trying to do is deal with the substitutability requirement. I want to
have a way to describe interconnect without making assumptions about the
types. Using wire as the generic interconnect in VAMS I don't think was
a good result.

SV already allows unpacked composites as nets. The problem is that
those composites are viewed as a distinct set of elements. We can't
change or break that. I believe it is important to talk about composite
atomic nets. This is a composite net that describes a single
connection. There are several ways to do this. One could decide that
the presence of a real value would produce an atomic composite. I chose
to make it part of the description of the net itself.

Section 4.3 describes resolution functions. These should give
implementations some reasonable freedom about when resolution functions
should be applied. In Section 4.3.1 I give an example of when
resolution functions should be called and this should be compatible with
the VAMS cycle. Signals should be in the same state when resolution is
done as when analog solutions are found.

Section 4.3.2 proposes a few things to allow one to write resolution
functions. Allows the resolution function to determine which parts of a
composite are being driven and then react appropriately and potentially
set the parts not being driven.

SC: Why is this not included in the semantics?

GV: If you predefine resolution functions it isn't a problem. If you
define user resolution functions then this is needed.

JL: I don't understand indicate_edge.

GV: It is a directive given to the simulator to determine what an edge
means.

KC: These items aren't in VHDL. I am not sure they are needed.

GV: I believe that you can get at the previous value in VHDL. There are
also some other constructs in SV that could be used to build these
functions.

Sections 4.4 and 4.5 describe how to associate resolution functions with
nets.

Section 4.6 is a way to allow partial driving of a composite net. This
would only be allowed for primitive nets. I haven't really dealt with
type conversions yet. This is just a starting point for discussion.

AB: Let's discuss a specific situation. We have an analog driver and a
load. We have a behavior model that will drive and a digital load that
will read if the net is a 0 or a 1 basically. How does the methodology
detect that the net is inert?

GV: My basic answer is I don't address that. If you need to model the
size or delay in the net then you would need to create a composite
digital module and understand that.

AB: Is it possible with a composite net for the digital side to add to
the composite net about the loading strength and then the resolution
function can react. How would the net be delayed? How would a probe
figure this out when the 0->1 transition happens?

GV: Verilog already has the concept of a delayed net. I don't see
anything inherently difficult that after resolution occurs that the
result would be delayed.

AB: Now imagine we have an analog probe has a dynamic threshold at 1.7
V. Is there any way that the net can have discrete delay, but also
identify that it is at a certain value?

GV: That is not a scenario I have considered. I would have to sit down
and think about it. There is a bunch of stuff in a truly mixed design
that I haven't looked at yet. I have been focused on substitutability.

JL: You have to recognize that there are limitations here. You aren't
likely to get a cross function out of this.

GV: In terms of a crossing function with a delayed net it wouldn't be
unreasonable to get a pending value from the net. It isn't something I
have thought through.

JL: I want to point out in regard to the scheduling that in some of the
models I developed the caps required trapezoidal integration. It became
an iterative problem in delta time.

GV: Right now the resolution function I provided is very restrictive and
stateless. If you look at the big loop scheduling in SV if we relax
some of the restrictions or allow some time passage through "deltas"
then we can get what you are describing. I think it is useful to get
there.

JL: The resolving function was stateless. The driver would drive a
value, wait for the resolution, calculate a new value and drive it out
another port. When you attach that to a Verilog-AMS model it may not
work well.

KC: There is a capability in VAMS you can write digital version of a
capacitor because you can look at the driver values and not the node
values.

SS: You have to be careful to avoid oscillation.

KC: These things only oscillate because you are looking at the resolved
values and not the driver values.

GV: My hope is to get enough functionality to write interesting models
although it may not be easy.

JL: The one thing that we may want is to capture state.

GV: An ugly way to keep the state history would be to add state fields
in the composite net and the resolution function could use these as
needed. You can even timestamp the state values yourself if needed.

KC: What is the real requirement here? Are people wanting to do RC
networks in a discrete simulator.

JL: I think the proposal allows this. The purpose of this isn't to
replace AMS though.

GV: I would be very interested in seeing someone take the basic
structure I have presented and write up a semi-realistic example
involving loading.

JL: Is the way resolution functions are handled in Verilog flattened as
opposed to hierarchical?

GV: All of the resolution functions defined in Verilog are associative,
so it doesn't matter how they are done. This proposal assumes that you
do them in a flat manner. This isn't currently assumed in Verilog.

KC: We don't seem to be working from requirements.

GV: I was trying to define enough infrastructure that is general enough
that it allows for a number of use case models to be solved. I don't
have the ability to say if there really are fundamental limitations that
preclude certain use models.

KC: My concern is that we don't have requirements and we may not meet
some important requirements if we operate in this way.

SS: We have spent a lot of time discussing resolution functions. Can we
collect the various implementations of resolution functions and
understand their limitations/boundaries? It may help us understand what
we need.

AS: Gord, can you explain model substitution?

GV: If you look at a resistor model in VAMS you will have two electrical
pins. If you try to describe that without composite nets you will have
to burst that pinout to describe it with a digital model. The purpose
of the interconnect is designed to be a generic way to connect things
without worrying about whether it is analog or digital.

KC: The interconnect idea is redundant.

GV: It is semi-redundant, but I address that in my write-up.

KC: The item you want to attach to that is the discipline. It tells you
what technology you are in.

GV: I also wanted to not preclude discipline resolution, but I didn't
want to have to bring all of that into the language right now.

SS: I want to know what people don't like about VHDL resolution
functions.

GV: I have heard that the hierarchical model doesn't work well. I have
proposed the "flat model" where all the drivers are know at resolution
time.

AS: I think it is important to discuss the trade-offs hierarchical vs.
flat, state vs. stateless, time vs. untimed.

JH: I got the impression that there was a tacit assumption that the
resolution function in VHDL is symmetric. I got the impression that by
using the system functions you can avoid this assumption.

AS: I think that the SNPS proposal isn't incompatible.

KC: Which is why we need requirements.

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