Subject: SV-CC Meeting Minutes 12/18/02
From: Warmke, Doug (doug_warmke@mentorg.com)
Date: Wed Dec 18 2002 - 10:32:03 PST
SV-CC Minutes, Wednesday, 12/18/02
Rolling 12 Week Attendance List:
[xx-----------] Yatin Trivedi (ASIC Group)
[x-x----------] Tarak Parikh (AT HDL)
[xxx-xxxxxxxxx] Francoise Martinole (Cadence)
[xxx-x-xxxxxxx] Stuart Swan (Cadence)
[xxxxxxx-xxx-x] John Amouroux (Mentor)
[--xxx--------] Emerald Holzwarth (Mentor)
[xxx-xxxxxxxxx] John Stickley (Mentor)
[----x--------] Duaine Pryor (Mentor)
[xx-xxxxxxxxxx] Doug Warmke (Mentor)
[xxxxxxxx-xxx-] Michael Rohleder (Motorola)
[xx-xxxxxxxxxx] Kevin Cameron (National Semi)
[-------------] Tayung Liu (Novas)
[xxxxxxxxxx---] Bassam Tabbara (Novas)
[xxxx-xxxxx-xx] Swapnajit Mittra (SGI)
[xx-----------] Darryl Parham (Sun)
[-------------] Simon Davidmann (Synopsys)
[-------------] Peter Flake (Synopsys)
[xxxxxxxxxxxxx] Joao Geada (Synopsys)
[xxxxxxxxxxx--] Ghassan Khoory (Synopsys)
[xxxxxxxxxxx--] Andrzej Litwiniuk (Synopsys)
[xx-x---------] Alain Reynaud (Tensilica)
[xx--x--------] Mike McNamara (Verisity)
[---x-------xx] Kurt Takara (0-in)
[----x--------] Dave Rich (?)
[----xxxxxx---] Joe Daniels (LRM Editor)
Action Items ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
1. Francoise will check with Charles about VPI numeric ID allocations.
2. Swapnajit to help Joao pursue information about the definition
for "observable points of an assertion". Needs to discuss with
Bhassam and others. If this information is not found, then Joao
will have to drop back to his original proposal on observing the
individual steps of each assertion check.
3. Joao: treat "check" more equitably w.r.t. "property" in
when using/creating names in the API.
Swapnajit's General Issues ::::::::::::::::::::::::::::::::::::::::::::
Next meeting: January 7th
Next face-to-face: January 23rd (Swapnajit still looking into venues)
We need to close the poll on Kevin's proposal (Issue 1.1B) by Friday.
List of eligible voters will be the same as before.
Please send your vote to the reflector by Friday:
Vote YES or NO on Kevin's proposal to add support
for dynamic binding to our standard.
Joao's Presentation of Revised Assertions API :::::::::::::::::::::::::::
The major change was to re-cast the proposal in terms of VPI.
Can iterate assertions globally via vpi iterators.
Users can move back and forth between assertions API
and VPI via instance names (i.e. get handle by name).
Francoise: Why is there only one class called "property",
with no finer granularity?
Joao: This is mirroring what is happening with assertions in SV-AC.
The properties do have subclasses.
The top level classes are:
1. property (temporal assertions)
2. check (non-temporal, inlined procedural assertion, same as an "if check",
placed directly into behavioral code as a statement.)
Swapnajit: Is there any way of accessing constraints?
Joao: As far as I know, constraints are just the same as properties.
There are 4 types of properties:
1. assertion (always has to be true)
2. assume (formal assumes it is correct, simulation checks it)
3. restrict (constraint)
4. cover (property used for functional coverage purposes)
So this API, which handles properties, can access all the above.
Francoise: There are two kinds of classes, and the property class has
subclasses. Suggest re-doing things slightly, so that a property query
would return its type. Instead of defining 4 different kinds of
properties, define only one kind of property, and then create a
vpiPropertyKind enum type that characterizes the property.
Joao: From a simulation perspective, they all behave the same way.
Once you have a property, you can get all information about
it in one shot.
Joao's approach is instead of touching everything in VPI, just do
the minimum modifications and minimize linkage between the new
additions and existing VPI.
Customers tend to want everything in one go, instead of getting
piecemeal bits of information one query at a time (which is
the conventional VPI model).
Joao agrees to add one more link in the VPI object model,
which is a line from property (via property directive)
to one of the four property types. There will be a new
property called vpiPropertyDirective, which when applied,
will return one of the 4 property types.
Francoise is concerned about Joao's selection of numeric id's
in his proposed extensions to vpi_user.h. She will check
with "Charles", who is on the vpi task force.
***
Joao continues on to explain section 3.
There is an extension to vpi_handle_by_name() to get a handle
to the requested assertion. Once you have the handle, you can
obtain all static assertion information in one shot via
the struct and enums defined in section 3.2.
In section 3.2.1, there is some work that needs to be done.
Joao is waiting on feedback from Bhassam for defining the
"observable" points of an assertion. Once this is defined,
the items in section 3.2.1 can be filled out (structure
of assertion, set of HDL variables used by assertion,
and set of HDL expressions used by assertion).
(Section 4.2 has similar dependencies.)
***
Section 4 on Dynamic Information
Joao discusses placing assertion "system" callbacks.
These callbacks are all made in unique places and
do not overlap with existing VPI callbacks.
For placing callbacks on specific properties,
there are some differences from the system callbacks.
JohnS: Not sure why there needs to be different
callback mechanisms for these two use modes.
(i.e. there seem to be overlaps between, e.g.,
cbPropertyStart and cbPropertySysStart).
Joao: Explains that the "system" callbacks have
to do with the general assertion engine under
the hood, whereas the instance-specific callbacks
are used for finer grained control/observability
over each individual assertion.
The new cb structure was created to contain extra
information needed for assertions. Joao didn't want
to change the existing cb structure so that lots
of VPI legacy code would not be adversely affected.
Section 5
The registration mechanism from Joao's earlier proposal
is now gone.
The control method is the same as normal VPI control.
The mechanisms in this section are "primitives" that
can be used by verification engineers that would use
them to construct verification environments.
e.g. disable all coverage checks in certain regions
of the design.
****
Francoise: What about more static properties, enough
to be able to actually decompile an assertion?
Joao: Would need to maintain the parse tree all the
way into runtime in order to give the user the
information. Lots of overhead with dubious value.
Doug: This part of VPI could be extended in the future.
Joao: No users asking for it anyways, since they all
want to parse the assertion themselves.
Swapnajit, Joao: This whole API needs to remain open
and flexible in order to keep up with the changes
in SV-AC.
Francoise: No specific mention of "check" as compared
to property.
Joao: You can also use the word "check" everywhere
that "property" is used.
Doug: Only in the static query part?
Joao: No, in every part. In many respects, "checks"
are trivial assertions with a pre-condition.
Francoise: The callbacks look like they only apply
to properties, suggests renaming them so that it
appears they apply to checks as well.
Joao: Sees Francoise's point and agrees to change things
Will attempt to be more equitable in the treatment of
terms "check" and "property".
Doug: What is the relationship of "coverage" to "property"?
Joao: "coverage" checks don't result in failures.
Properties generate events that can be used in SV itself.
You can declare a property whose directive is "coverage".
This API gives on-the-fly information, no state.
The coverage API maintains state. In that API, a user
can ask questions like "has this line ever been executed?"
Here is an example of using of the cover property directive:
In the PCI protocol, there are read transactions.
Users can create a property that says "a read transaction
has occured". You can't call that an "assertion",
since that property doesn't hold all the time.
However, it does mark an interesting point in time.
When the point does occur, the read transaction cover
directive fires, and the user code can react to it.
Stuart: Isn't it the case that assertions are built
up on properties? i.e. properties don't always have
to be true or false, they are just complex temporal
conditions. [Joao: correct in essence, but we're
getting into a terminology nightmare]
******
Joao: What are next steps in the development of this API?
Expect to keep tweaking, but want to know process.
Swapnajit: This should follow the same procedure as
for the other proposals. Make the suggested changes,
republish, then we will take a vote on the proposal.
Francoise: What about integrating the LRM?
Swapnajit: We need to condense all the various
proposals into the Accelera-approved LRM format.
Joe Daniels is currently working with the original
donations from Synopsys and is converting them
into Accelera-approved LRM format.
Doug: What about high level outline for the LRM volume?
The original Synopsys donations have almost no bearing
on where we have evolved things.
Francoise: Agrees that high level organization of all
aspects of our work will be difficult. (SV-side 17 points,
C-side 3 sections, Michael's compile/link standardization,
etc. etc.)
Joao: The DirectC interface should be its own chapter
in the eventual LRM, since it is standalone from the
other API's (vpi, acc, tf)
General: There is some contention on what has been
approved for inclusion in the LRM and what is pending.
Swapnajit: All polls are in the meeting minutes and have
been approved. All approved material will be included
in some form in the LRM. The owners of the issues that
have been approved have to present the write-up of the
issues to Joe. Then Joe will integrate it all. Then
a final vote on the LRM will be taken.
Francoise, Doug: Joe will be wasting his time to convert
the original donations into new LRM format. (Since almost
no material is being used) It is a base of work, but no
need to have it in a certain format.
Joao: There is a lot of boilerplate in the original
donations that could be re-used.
Doug: When are we going to poll on Andrzej's/Joao's C-side?
Swapnajit: Wants to do this in first week of January.
Kevin: Wants to defer the vote on his proposal
Kurt: What about closing the loop on the assertion API
with SV-AC?
Swapnajit: Would like Joao to start a channel of
communication between our group and SV-AC.
Joao: Already has informal channels for this purpose.
Others: Just an idea, make the channels more official
and have some kind of formal presentation when we're done.
END OF MINUTES
[Apologies from Doug if there are any incorrect statements -
that was a pretty frenzied meeting!]
This archive was generated by hypermail 2b28 : Wed Dec 18 2002 - 10:33:17 PST