MeetingMinutes20090310 < VerilogAMS

VerilogAMS Web>AmsAssertions>RequirementsGatheringGroup>MeetingMinutes20090310 (2009-03-10, ScottLittle) (raw view)EditAttach
Attendees:
   * 111111 Himyanshu Anand 
   * 011111 Kenneth Bakalar
   * 111110 Prabal Bhattacharya
   * 011110 Eduard Cerny
   * 111011 Scott Cranston
   * 110111 Mike Demler
   * 000000 Surrendra Dudani
   * 111000 John Havlicek
   * 111000 Kevin Jones (RGG Leader)
   * 111111 Scott Little
   * 101000 David Sharrit
 
Decisions:
----------
   1. The AL should support both online (assertions are run in a parallel process to the simulator and may affect simulator time steps) and offline (assertions are evaluated against a waveform after the simulation has been run) modes.

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

   1. Freescale will put together a more concrete proposal about the possibility of using bind to access Verilog-AMS constructs in the AL when SystemVerilog is the host language.
 
Details:
--------

MD expressed some concern about whether flattening the Twiki is more user friendly or not.  SC mentioned that if you click on the '<' sign between the revisions you will get a diff output.  SL expressed concerns about the usability of that diff.  SC then explained that using the 'More topic actions...' link at the bottom of the diff allows you to see a side by side view which could be more usable. 

We started up discussion on paragraph 4 of the Requirements on Language section of the requirements document.

SC: What are the trade-offs of this restriction?

SL: If we assume that SV is the host language then we are not allowed to directly access analog events or continuous quantities like have been demonstrated in some of the Freescale proposed renderings.  SV could be extended to have dense time and comparisons of real values, but you would have to still pass continuous values and events by converting them to digital signals and passing them through ports in the way it is done with the current set of assertions and languages.  SV-AMS is the host language where these assertions are ideally suited, but the timeline for the release of SV-AMS may be longer than we want to wait for the AL.  By allowed the AL to be used in SV this could get the language into the hands of users sooner.

KB: Interopability between SV and Verilog-AMS is more important than the SV-AMS language.  SV is a verification language which instantiates Verilog modules.  Not only is it a matter of timing, but it is a matter of utility.  Since we don't know what the nested language will look like we should do the extentions for dense time available in SV in the short term.  Subsequent hosting in SV-AMS may be an extension.

SL: If Verilog-AMS is the host language it isn't totally clear which parts of SVA could be used (KB: not clocking blocks).  In Verilog-AMS you would have access to analog events and continous variables though.

KB: There is an implementation issue for the developers.  It will be the responsibility of the digital simulators to do the assertion evaluation.  It is essentially a digital problem except for the reference of the objects in the Verilog-AMS.

SL: We focused on thinking about how the AL would work in SV as a host language because we assumed that is where most of the assertions will be written.  We aren't ready to agree to such a strong restriction as we think that access to analog events and continous values provides significant value.  We would like to propose using the bind construct in SV to access the analog events and continuous values.

SC: What is the advantage to putting it in via bind?

SL: SV wouldn't have to be able to reference things like V(a) because bind can remap the name.

KB: This idea needs at least a sketch.  We need to be careful about stepping on the SV-ams committee.  We need to be careful about defining a semantics with the bind that restricts the future language.

SL: We will put together a proposal this week or next week.

KB: We may introduce new reserved words.  The next statement says that we are not talking exclusively about post-processing.  I want to be able to change the direction based on the assertion evalutions.

HA: I think running in parallel is important, but I also want to run in post-processing mode.

KB: Running in parallel is required and desired, so that we can act as quickly as possible.  For reasons of efficiency it will be necessary for the assertions processor to control the time step.  This is done now w/ above and cross now.  They adjust the timestep.

HA:  I don't disagree w/ your ideas, but I don't think it should have to run that way.  We would like to be able to run it in post-processing mode.

MD: From a practical point of view there may be requirements that make the processor and the simulator run sequentially.  We shouldn't try to dictate the implementation saying that it must be in parallel.

KB: I am not talking about the implementation.  I am talking about the way the user perceives that the tool runs.

KB: Without the assertions the simulator just finds points that the designers of the simulator decided to output.  There is no reason that the resulting waveform couldn't be played back and the assertions run during the playback.  In this case there would be no difference between online and offline except in the case where the assertions affect the simulator timestep.

KB:  Do you want to define how @cross works for both online and offline?

HA:  That is one option.  The other option would be to disallow cross in post-processing.

KB: Dejan does linear interpolation and assumes it is accurate for offline.  That is one way we could go.  I don't want to exclude the ability to be reactive to the ongoing calculation.

HA:  We want both online and offline modes.

KB:  That is a reasonable way to go about it.

SL:  We should have a definition for how cross is handled in both online and offline modes.

KB: I am not sure that there is a need to define the post-processing algorithm.

SL: We want different assertion evaluators to get the same result given the same input (waveform and assertions) in offline mode.

KB: We want simulators to have the same limit and not the same result.  We want to define a language such that having the same limit is a consequence.  As you adjust the simulator precision controls they should converge.

SL: Could we just have the assertion evaluator expose its interpolation method to the user like it done today w/ integration methods in Spice simulators?  We could require that all assertion evaluators support at least linear interpolation.

KB: I don't want to define a notion of precision in the language.


-- Main.ScottLittle - 10 Mar 2009
Topic revision: r1 - 2009-03-10 - 21:41:32 - ScottLittle
VerilogAMS