• 1111111 Himyanshu Anand
• 0111111 Kenneth Bakalar
• 1111101 Prabal Bhattacharya
• 0111101 Eduard Cerny
• 1110111 Scott Cranston
• 1101110 Mike Demler
• 0000000 Surrendra Dudani
• 1110000 John Havlicek
• 1110001 Kevin Jones (RGG Leader)
• 1111110 Scott Little
• 1010000 David Sharrit

Decisions:

1. Extend SVA with arbitrary resolution and real values from Verilog-AMS and the ability to reference time steps.

Action Items:

1. Examples from participants to check whether the language being proposed is going to be sufficient.

Details:

HA: Described bind. The bind will allow the extension syntax to reside in one place. Currently the features that we have in mind are most probably not supported by bind.

HA: The extensions to bind will allow us to get access to Verilog-AMS values and events (through event variables) and allow to bind different instances of variables and allow minimal changes to SVA syntax.

ED: Can we do this through aliasing?

KB: They have to both have meaning in the host language.

ED: One could extend alias as you would extend bind.

KJ: Should we wait for System Verilog-AMS standard.

ED: Can we import of the constructs into SVA.

KB: Fundamental issue is dense time. And dense time is a pre-requisite to have a dense time digital assertion language even if it can't refer to Verilog-AMS.

ED: Do you really need dense time or achieve it through time resoultion and time step?

KB: Analog simulation is sample of time not really dense time that make us convinced that there is a good relation with the physical world. Where we take those samples gives us a better notion of accuracy.

ED: So, there is no really lower bound on the simulation which is told by the language?

KB: Yes, except that you are working on a computer.

ED: If you define assertions on a dense time then when you move to digital side it needs to be mapped to digital time.

KB: Yes, this is an issue of precision not of time step.

ED: How would you determine that for digital side, a-priori? Could you not write your assertion around your digital time step.

KB: You might say the limit of the density is the low order bit of the time. It may not have all the precision of the analog simulator but you don't want to lock them together. Limited dense time is the low order bit of the digital clock.

ED: Then you can describe it in terms of abstract discrete time.

KB: I don't think we should do it.

KJ: What you are asking for is arbitrarily dense time in simulator?

KB: I don't want to specify those limits in the language.

KJ: You want arbitrary dense time.

KB: Yes. Is there a good reason to proceed without a unified System Verilog-AMS language? SV is used by verification engineers rather than designers. The other thing is interface between AMS-SVA.

KJ: Didn't we say that the this language is intended for AMS verification engineers.

KB: Verification has a separation between verification engineers who use SV and design engineers who use Verilog. Therefore reasoning in parallel, verification engineers need a dense time to write properties that cross digital-analog interface.

KJ: Proposal to add arbitrary time steps to the resolution and real values and that would give us System Verilog AMS Assertions. Is that an over-simplification?

HA: I would say that is necessary. I am not sure if that is enough.

KJ: Is it time to move to concrete examples from people to see whether the examples fit the definition of the proposal?

PB: Will the assertions only interact with instances/objects in the scope of the language.

KB: You can be access wires/variables using hierarchical names from Verilog-AMS/System Verilog.

HA: Is it supported today?

KB: No, but it could be defined.

PB: What you are saying is having Verilog-AMS to support named events. If we are talking about name references or instantiations in System Verilog to bring Verilog-AMS etc using reals, then it cannot have bi-directional, there can be only one driver.

KB: They can be defined as ref and it will work. The issue of interconnect is different from issue of AMS assertions. 'wreal', has not been introduced into standards. What do you do when two drivers drive a 'wreal'?

PB: Depends on the values. The resolution function is probably falling on the voltage or current. I am expressing this concern, that with this strategy that you are proposing we do have a restriction which needs to be removed with System Verilog.

KB: It does too much damage to SV to treat real variables different from other variable types. It probably need to expand the integral types to include real type.

HA: Can we put this as a restriction that the real variables crossing cannot have multiple drivers?

KB: Assertions need to just read they are not write values.

PB: Yes, but we might run into serious limitations soon

KJ: Two questions to resolve - 1) Is it rich enough to satisfy everyone and the 2) How do we make it semantically meaningful. Is it a reasonable to gather examples and bring them to the discussion table and see whether they can be expressed in the proposed extension.

KB: Jitter in VHDL-AMS.

KJ: Has FSL provided these examples that deal with jitter?

HA: We have discussed these internally (jitter), don't recall whether we shared it or not.

KB: Frequency within a certain time.

HA: FSL has provided those examples and that was why we wanted built-in function.

ED: For frequency can we collect it in some array and the apply FFT?

HA: There is a concern with frequency being a user defined function, whether it will have some side effects and whether they are acutally even correct.

KB: Built-in functions are just one way of solving the requirements.

KJ: Recommend that examples will be provided in the Case Studes/Examples section by everyonoe to check whether we are headed in the right direction and that the language being worked upon is expressive enough to express the properties that we want to verify.

-- AnandHimyanshu - 23 Mar 2009