00000000000000010000101111000000000 Qamar Alam
11111111111111111110101111111011111 Himyanshu Anand
01111111100111111011101000111111111 Kenneth Bakalar
11111010101101101110110000111000111 Prabal Bhattacharya
00000000000000110000101001000010010 Sri Chandra
01111011111111111101101011111011111 Eduard Cerny
11101110000101101011101111101111111 Scott Cranston
00000000000000010000000000000001000 Dave Cronauer
00000000000011000000000111111001111 Dejan Nickovic
11011101111001000000000000000000000 Mike Demler
00000000000000000000000000000000000 Surrendra Dudani
11100000001111111111110011011111111 John Havlicek
11100011001000000000000000000000000 Kevin Jones (RGG Leader)
00000001111111111011101111111111111 Jim Lear
00000000000011101110000000000000000 Top Lertpanyavit
11111101101111111111111110111111111 Scott Little
00000000000001000000000000000000000 Erik Seligman
10100000000000000000000000000000000 David Sharrit
00000001000000000000000000000000000 Murtaza
00000001000000000001011001100000010 Martin O'Leary


Action Items:


JL: When you sample, it does not force a time point.

KB: Its the implementation and what it does is returns the time point using
a lot of heuristics.

JL: The point of the proposal is that the values that are returned are
inadequate, so there has to be a way to force a time point.

KB: This has to do with VAMS and nothing to do with ASVA.

JL: The FFT sampling that he got was very bad.

KB: If you want to do FFT, you have to have very precise sampling. Its not
the language definition problem.

JL: Those samples need to be under control for the checkers.

KB: You want to dynamically control the accuracy of the cross statement.

SL: The digital clock does not necessarily force the analog solver to solve
for that time. Its allowed by the LRM.

KB: Is the $timer adequate to satisfy the requirement?

JL: $timer is certainly a mechanism in the right direction. It could just be
a function call. It may be a function, not a VAMS language, but something
that allows to control the accuracy from within SV.

KB: Probably then $timer needs to be put in SV first. So, sometimes you want
be exactly precise and at other times you do not want to that accurate.

DN: Can you change the $timer dynamically just like @cross can be controlled

HA: John, ED, do you have an opinion on this. This seems more of the larger
VAMS committee issue.

ED: There will be no changes in SV for a year or two. There is a global
clocking is this in any way related to that.

KB: $timer is a special function.

SL: This has an effect on events and on solve points of analog solver, just
like @cross, @event.

ED: If we connect a SV module to VAMS, then can you tie the SV event to an
analog event?

KB: Their effect is the same. Used to execute processes.

ED: Modules can receive events by reference and checkers can receive by

SL: The definition of analog event and digital event is not the way the LRM

SC: Digital event is controlled by the digital part of the design.

KB: The event does not occur in digital but is affected by digital event.

SC: How can digital event affect the Mixed Signal simulation?

KB: It does.

PB: Does the @timer work for you. It could be something we could bring into

JL: @timer would be great for simulator.

JL: JL2, ability to access analog events within SV.

KB: What does it meant to access an event?

JL: This poses a lot of implementation problems. I was hoping to get a
function that will return an event. The basic idea is ideally SV specifies a
crossing and the function either return/does not return an event.

SC: How will the function now wait for the event.

KB: The function is an event. Fundamentally you want to be able to read the
value of access functions.

JL: Just having a scalar port is not going to be sufficient. I want an access
function that allows me to have an accurate waveform.

KB: Can you do the stuff you want in VAMS or not?

JL: Yes, Then the trick is that you make them accessible from VAMS to SV.

ED: Will do you most of the calculations on VAMS side and then receive the
final judgement on SV side.

JL: That is possible, but would like all the checking functions in one

ED: If you get the timer functions and read them on real port. Is it not the


JL: Yes, there are two sampling mechanisms that I want - timer functions
forcing time points and another is accepting analog time points.

KB: If you want accurate point, you are going to pay the same amount no
matter how you do it. You want dynamic control over precision.

JL: JL3. If there is some imprecision between analog and digital time
point, then I want better accuracy. As the analog clock has a different
value then the digital value.

KB: In VHDL the analog time and the digital time has the same number of

JL: I want to be able to get an accurate value with accurate time, which
does not have an artifical clock jitter.

KB: I am afraid of getting these two ideas entangled together. First define
the language in the limit.

JL: JL5, this is like corollary to JL1. This one talks about not forcing a
time point but just observing the values.

KB: So, the proposal basically calls for two kinds of assignments, one is to
have a synchronized assignment and the other to not have synchronized

JL: That is not correct. The language is ambigious and the implementations
are probably not following the LRM.

-- AnandHimyanshu - 2009-11-03

Topic revision: r1 - 2009-11-03 - 21:57:58 - AnandHimyanshu
Copyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback