MeetingMinutes20090819 < VerilogAMS

VerilogAMS Web>AmsAssertions>RequirementsGatheringGroup>MeetingMinutes20090819 (2009-08-19, ScottLittle) (raw view)EditAttach
Attendees:

   * 000000000000000100001011110 Qamar Alam
   * 111111111111111111101011111 Himyanshu Anand
   * 011111111001111110111010001 Kenneth Bakalar
   * 111110101011011011101100001 Prabal Bhattacharya
   * 000000000000001100001010010 Sri Chandra
   * 011110111111111111011010111 Eduard Cerny
   * 111011100001011010111011111 Scott Cranston
   * 000000000000000100000000000 Dave Cronauer
   * 000000000000110000000001111 Dejan Nickovic
   * 110111011110010000000000000 Mike Demler
   * 000000000000000000000000000 Surrendra Dudani
   * 111000000011111111111100110 John Havlicek
   * 111000110010000000000000000 Kevin Jones (RGG Leader)
   * 000000011111111110111011111 Jim Lear
   * 000000000000111011100000000 Top Lertpanyavit
   * 111111011011111111111111101 Scott Little
   * 000000000000010000000000000 Erik Seligman
   * 101000000000000000000000000 David Sharrit
   * 000000010000000000000000000 Murtaza
   * 000000010000000000010110011 Martin O'Leary 
		
Decisions:
----------

Action Items:
-------------

Details:
--------
		
SL: Ken, I see that you have updated the Twiki?

KB: I have decided that the update is wrong and I want help from you guys to fix it.  We were going to extend VAMS to use an SV-style bind.  The module being bound would be an SV module.  This is equivalent to instantianting SV within a VAMS module.  Now the issue becomes what constraints are we going to make on the form of that module instantiation inside VAMS.  Clearly we can't do things that are completely illegal in VAMS like for example instantiating a module that has variable ports.  There are a series of restrictions on the form of a VAMS module instantiation.  I would like to do as little possible damage to VAMS by extending it this way.  I would like to prevent from having a variable port on the SV side.  Normally, the actuals refer to things within the local module. At one point someone wanted to use the bind in another way in which some of the actuals were OOMRs that referred to SV objects.  We were talking about restricting the class of objects those reference. When you do a bind can you provide actuals that are bound in the binding call rather than references to where the binding it taking place?

SC: What was the fundamental reason for suggesting bind in the first place?

KB: There are two reasons.  Just as a general case the ability to back annotate verification stuff with bind.

SC: Why can't you do that with an instantiation directly?

KB: The verification guy wants to work separately.

SC: So it is really just the standard purpose for bind.

KB: Someone was talking about having hierarchical references to SV objects.

SL: It was Freescale who was asking for this extension.  In our checkers we may be checking an AMS property, but to put the check in proper context we need system state contained in SV modules that is not passed into the VAMS module.  In this case, the checker would need to have both types of information and would be instantiated in the VAMS module.

KB: My understanding of the bind is that the actuals must be known in the context.  The idea is that when you bind the checker in the VAMS module some of its port expressions will refer to local objects and some would refer to OOMR.

JL: Couldn't you do this with a secondary wrapper?

KB: The problem is that you are binding to early.  Now the wrapper isn't reusable.

JL: Right, now two items aren't reusable.

KB: Now you have to write a custom checker for each use and this destroys the reusablity of checkers.

SL: If bind is like instantiation and instantiation allows it then what is the problem?

KB: Maybe there isn't a problem.

SC: Section 23.11 in P1800-2009 describes bind.

KB: If we allow an arbitrary SV expression as an actual we have a big leak in the dike b/c it must have some meaning in VAMS.  The idea is to restrict those expressions to things that are ok in VAMS.  Now, one way to do that is to say that the expression is either a legal VAMS expression or a primary which is the name of a SV object.  Now we don't have any restrictions of the type of thing being pointed to.  The binding is done on the other side and is the responsibility of the SV processor.  As far as VAMS is concerned the name is uninterpretted.  It is the name for a generic object.  Rather than restricting the type we could restrict the expression to just a name.

SL: I think that is preferrable.

KB: Okay, let me see if I can work it that way.  That is a slick solution.  What you want is to preassign specific items in the bind and then just add a couple of items in the VAMS module.  This syntacically looks like currying.  Okay, so I think that idea works.

HA: Ken, have you looked at previous meetings minutes?  We had some discussions taken.  Do you want to add anything to that discussion?

KB: I think that Dejan and I are in agreement despite the large number of > signs.

HA: Are people in agreement with that notion of the accuracy model?

KB: The solution I propose is a bit ugly b/c I have to mention the comparison operator twice. Once explicitly and once implicitly in the cross.

HA: You say that the event happens at a synchronization point.  When exactly is that?

KB: It is at the resolution of the digital clock.

HA: This is still at the precision of the SV ticks.

DN: Even though the synchronization happens at the precision of SV can you still extract the exact value at the event time?

SL: Are you concerned about getting time or values?

DN: For events just time.

KB: My claim is that the offset between the actual event time and the digital time is negligible.

JL: What you are saying Ken is that you can crank down the timestep to get the noise difference to where you want it.

KB: The reason that people move the point is to collapse digital events onto each other.  I think we can always make the resolution of the digital clock small enough to make the difference between analog time and digital time negligible.  By creating an event you can make sure that the relational operator would happen at an accurate time.  Why not use the cross directly instead of using the relational expression.  The one issue is that it might be somewhat unnatural.  It might be more natural to use the relational operator.  Then my question is can someone formulate this using the cross event?  Then this allows us to have a more accurate cross and the less accurate relational operator.

SL: I think this makes sense as this would be familiar those who currently use Verilog-AMS.

KB: Ideally, you would like cross to actually be a signal that is false before the cross and true afterward.  That would give you the ability to generate events and use it as a boolean.

DN: I don't think this should be put in the language.  I think we will have trouble with the semantics.  We really ought to try and keep the language clean.

KB: You want to keep the assertion language as clean as possible.  Does the SVA have the property of cleanliness?

DN: Yeah, I think it is pretty clean, but it does have more complication than pure LTL or regular expressions.

HA: Dejan, putting cross statements I can see why you are concerned b/c tolerances are there.  If you look at Ken's example you can see that if the cross is embedded or not it is more or less the same.

DN: With a clean language you could easily change the accuracy, but if cross gets in the assertion this can't necessarily happen.

HA: I think that Ken's proposal the cross is involved and both methods are fundamentally the same thing.

KB: Can we have the cross in the syntax but translate it to the relational operator in the formal semantics?

JL: We are talking about cross, but right now cross doesn't exist in SV.  If we have an accurate stream of data then we can post process it in the simulation.

KB: Why can't you just grab the entire simulation database?

JL: Because we want to do this on the fly.

HA: Can't you do this already by cranking down your accuracy and just observing the data.

JL: If you want to detect a cross accurately you have to have a cross operator in the simulation.  Instead of putting cross into the operators if your assertions have access to recent waveform data then you can check this.  You can use a circular buffer to maintain the recent data.  You can check the buffer periodically or based on an event.

KB: Then you really have the assertion in two places with cross and the relational operator.

JL: I am not thinking about an event.  I just want the simulator to accurately generate data around the cross.  It is a minor difference.

KB: Your contention is that this kind of expression based logical language just isn't necessary.  What is necessary is a package that accumulates buffers and makes checks on these buffers.

JL: Yes, I think that ought to be the first step.  Once you have the capability to do this post processing you can do most of the important checks.

KB: Your claim is that this fancy expression grammar goes beyond the needs of analog designers.

JL: Yes and no.  The general specifications are quite simple.

KB: What you are arguing is that a temporal expression grammar is overkill for the application.

JL: Yes, but there are some items I want from the temporal expression grammar.

KB: You are talking about a pure analog world not a mixed-signal application though.

JL: Well, I am coming from a signal processing perspective.

KB: We should talk about this more.

-- Main.ScottLittle - 19 Aug 2009
Topic revision: r1 - 2009-08-19 - 17:00:25 - ScottLittle
VerilogAMS