Minutes from meeting on 2010.06.08

2010-06-08
SV-DC meeting notes

Attendees:
111 Jim Lear (Cirrus)
111 Achim Bauer (obs)
11- John Havlicek (Freescale)
111 Scott Little (Freescale)
11- Scott Cranston (Cadence)
111 Sundaram Sangameswaran (TI)
11- Gord Vreugdenhil (Mentor)
11- Top Lertpanyavit (Intel)
11- Dana Fisman (Synopsys)
111 Ghassan Khoory (Synopsys)
11- Ian Wilson (BDA)
1-- Ken Bakalar (Mentor)
1-- Kevin Cameron (obs)
1-1 Arturo Salz (Synopsys)
1-- Dave Cronauer (Synopsys)
1-- Ed Cerny (Synopsys)
1-- Tapan Halder (Synopsys)
1-- Jonathan David (obs)
1-- Jim Holmes (Lynguent)

SUMMARY:

-The P1800 WG will would prefer to approve multiple small chunks of work
instead of one big piece. We should break up the work we intend to do
in this PAR in a few chunks.

-Jim Lear discussed some use cases based on the paper he sent to the
SV-DC reflector on 05.25.

-User companies are encouraged to submit use cases to drive the roadmap
discussion moving forward.

DETAILS:

SL: We have been approved to work on a roadmap for the SV-DC work.
Based on the direction of the P1800 WG I think it makes sense to try and
break up the work we hope to accomplish during this PAR (prior to Oct.
2011) into a few small but useful chunks. The P1800 WG would prefer to
approve too little work and have the groups come back and get more work
approved than approve too much work. Our challenge is to find chunks
that are useful by themselves even if we don't have time to accomplish
everything we hope during this PAR. The other item that should likely
be a part of the roadmap is some indication as to which other SV
committees would have overlap. We need to give them a heads up and make
sure they realize that some time by that entire committee or at least a
few of its members will be needed to ensure proper continuity of the
proposals with the other ongoing work.

JL: I was thinking that resolution functions don't play well w/
continuous solver. If you start doing plug and play you will likely end
up in a case where discrete and continuous nets need to be resolved.

SL: I had envisioned that the resolution functions would sit in the
discrete domain. Any interactions with continuous signals would first
require discretization.

AB: If we just care about discrete but could think about dense time. We
might build a bridge to continuous with dense time.

JL: That occurred to me. Matrix solvers don't have ports and drivers
they just have nodes. Possible to describe port or block in some matrix
form?

AB: Don't forget about the stimulus.

JL: Entries in the matrix can be values or functions. A good solution
may play nice with both matrix and discrete time solvers.

AB: How are you imagining this to work?

JL: There are ways to represent n ported blocks into a matrix form. I
am imagining describing a block in a matrix form instead of a procedural
form. Maybe the discrete solver can easily convert this to discrete
time.

AB: When I thought of real valued modeling I didn't think of it as a
network. What I had thought was that we had neighboring modules driving
with real values and loading with real values. This could be resolved
to a dense time and discrete time values.

JL: That may be more realistic. I was just sort of thinking about the
possibilities.

SS: I agree with Achim. The matrix solvers won't see the these discrete
real.

JL: You should read the paper on Thevenin modeling (a link to the paper
was sent to the reflector previously). One problem is to do a R or C
you need a Thevenin equivalent of what is driving onto the resistor
node. The discrete solvers don't really present that information. I
was imagining the Thevenin drives out a real value for the resistance
and a scalar value for the voltage. Maybe instead of driving out a
resistance you could drive out an impedance. My concern is how that
plays with resolution functions. When you start really doing plug and
play scenarios does this play well?

AB: My impression is that you are worrying that in complex MS circuits
there are some additional complexities that maybe don't fit into the
current modeling styles.

JL: Very frequently I encounter discrete devices outside the chip.
There is often impedance matching issues. These lead us to want to have
discrete devices.

AB: Structs should be able to help us handle these things. I think that
structs are powerful and can be used to collect bunches of different
items about each of the ports.

SL: I think that we should provide use cases that illustrate the type of
plug and play problems facing us today.

SS: Partitioning will be important in the plug and play depending on how
the modeling proceeds.

JL: In modeling the partitioning is often not under your control. In
modeling you would often like to get the analog designer to get the
external discrete devices and tuck them into the model. This is the
ideal case. Ultimately you don't have full control over your
partitioning because there are hard boundaries like block boundaries and
chip boundaries.

AB: Can we think about using drive strengths instead of
resistance/capacitance? We could then convert that drive strength to
the electrical world.

AS: What is the input to the matrix solver? Is it a completely separate
netlist.

JL: That is the problem. The input to the continuous solver is a port
from the discrete solver. What happens when you have a resolved type
that interacts with the continuous solver. Can we have a struct to
electrical converter?

AS: Don't you need to synchronize these?

JL: Yes. The bigger problem is that the electrical needs to present
itself as a struct type. That may be hard to do w/ VAMS.

AS: I think what happens is that analog portions get pushed into the
analog solver.

JL: What happens if the analog components are modeled in the discrete
time world.

SL: I think that there are three likely candidates for the work that can
be done in this PAR. Generic ports that can be connected together via
wires, user defined resolution functions, and type conversion. We need
to look at the feasibility and complexity of accomplishing these tasks.

AS: Adding user defined resolution functions involves some complexity.
In Verilog we don't usually have user defined resolution functions.
Traditionally those have been builtin. VHDL has no built-in types or
resolution functions. Verilog has built-in types and resolution
functions. The natural way would be to declare a port of voltage type
and the resolution function would do what voltages do. User defined
resolution functions would be a large divergence because we haven't had
that previously.

AB: I think we need them.

AS: To support resolution functions you need to support unsized arrays.
The size of the domain of things you need to swallow would be large.
This is because you don't know the number of connections until
elaboration.

JL: I think that incorporating all of the types and resolution into the
language has been a mistake. This is more of a philosophical statement.
I am not sure how to do this without user defined functions. We could
introduce types.

AS: We could introduce voltage, current, and maybe frequency. You could
then put forth the resolution function for these types. That would sort
of follow the Verilog style.

JL: I really believe that we need user defined resolution functions.

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