Notes from SV-DC Meeting 2010-06-22

Hi Folks:

Below are notes, slightly edited, that Scott took. Please send corrections as you see fit.

J.H.

2010.06.22
SV-DC meeting

 
Attendees:
1111 Jim Lear (Cirrus)
1111 Achim Bauer (obs)
1-11 John Havlicek (Freescale)
1111 Scott Little (Freescale)
1-11 Scott Cranston (Cadence)
1111 Sundaram Sangameswaran (TI)
--11 Gord Vreugdenhil (Mentor)
--11 Top Lertpanyavit (Intel)
--11 Dana Fisman (Synopsys)
-111 Ghassan Khoory (Synopsys)
1-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--1 Jim Holmes (Lynguent)
1--- Walter Hartong (Cadence)

Attendees: Achim Bauer, Jim Lear, Jim Holmes, Ian Wilson, Scott Little, John Havlicek, Scott Cranston, Walter Hartong, Sundaram Sangameswaran

Discussion of use cases by Achim Bauer

Pic 1 several driving paths that that may be active at the same time and require some sort of resolution function.

Pic 2

SC: Is everything in Pic 2 wreal?

AB: This is an example where lumped components end up at the top level.

JL: I contend that wreals are wholly inadequate.  I presume you mean discrete real?

SC: No, it seems like this is difficult for wreal.  I was wondering if that was the intent.

AB: That isn't the intention.  This is just an example use case.

SS: Is the intention that we can run a circuit like this in the digital world?

AB: It is my understanding that we are talking only about the digital world here.  I think it makes sense to think about it we can deal with this sort of thing in the digital world.

SS: Can we use some sort of table model to solve this circuit?

AB: Table models remind me of IBIS.  In this case, I would describe the resistor as a table model.  It is more or less a device that looks at the voltages and draws current.  This may not require a network solution but just a coarse approximation of the real situation.

JL: A VI solution tends to end up with a male and female end of the device which can be problematic.

AB: That is good point.  I am also worried that there might be some requirements on the timestep to avoid numerical problems.

Pic 3

Connecting different voltage domains is something that I would like to check.  This could be done.

Pic 4

Given a digital input through a buffer with a load you may want to see a linear approximation of the behavior.

Pic 5

Very similar to picture 1, but it uses an XMR

Pic 6

WH: You mentioned timesteps.  Aren't they fixed or dependent on the digital simulator?

AB: I think it would be good to have a struct to see how often or fast a signal changes.  It would be good to have a quasi-continuous behavior.  You could understand the rate of time and then determine how much time should be allowed to pass.  If the simulator can't resolve that amount of time then it could be zero.

JL: In my experience it is event driven and the drivers do dictate the timestep.  If the load has state then they are drivers as well.

WH: I think this is a good restriction.  If we want true analog behavior then why not use the analog simulator?

AB: If only the driver is setting the timestep then this could be problematic because it doesn't know about all of the loads.  A very small load could be problematic.  A resolution function could maybe be used to determine the timestep.

JL: That is a good point.  I am not sure how the resolution function would work.  I am not sure if there is a solution to this problem.  We should try to provide the tools and then listen to the users to see if we haven't covered their requirements.

AB: The rest of the document discusses some items that would be necessary to implement the use cases.  Let's move to the next picture (unnumbered Pic).  This is not an analog network to solve.  It is just a set of current contributions.  The C is a central load that is summing up all of the current in the network by the resolution function.

JL: We should allow any aggregate type as port types.  In VHDL they restrict against pointers.  I think we should allow all aggregate types including classes.

AB: I am concerned that analog designers may not be excited about using the entire class structure and the vendors may not want to be this open as well.

JL: That is true.  Vendors might even have concerns about resolution functions themselves.  If we have structs it shouldn't be a big stretch to allow all data types.

AB: SystemC-AMS is very popular in academia, but in a few years it might interface with SystemVerilog.  This could be a nice way to have that interface.

AB: I haven't written a lot about type conversion.  There may be some link between connect modules and the type conversion.

JL: I think it is clear that the use cases present a large number of problems.  We may not be able to solve all of the problems.  This does make a very good case for user defined resolution functions.  We need to boil down the question of the language features we want to add and leave the solutions to the users.  I still have two questions.  Do we want the resolution functions to have state?  How do we handle converting from one type to another?  For instance, a Thevenin driver into a digital input as in picture 3. 

JH: We are charged to come up with a roadmap that includes the work that enables the features that users will need to address these types of use cases.

SS: What about back annotating data?  Is that possible?

AB: It seems like it should be possible to take the back annotation information and add that to the digital nodes to get accurate loads in the model.

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