Subject: [sv-cc] Meeting Minutes: SV-CC Weekly Meeting - 10-22-03
From: Stickley, John (john_stickley@mentorg.com)
Date: Wed Dec 03 2003 - 10:13:58 PST
Attendees:
Joao Geada
Ralph Duncan
Bassam Tabarra
Francoise Martinolle
Michael Rohleder
Avinash
John Stickley
- Will have polls for assertion API and coverage API errata
- Bassam sent new version of assertion API this morning
- Francoise spent some time at Cadence with Avinash and
others reviewing VPI data model for SystemVerilog VPI
- Found minor issues, corrections - no major issues that
need to be redone
- They will have another session next week to review assertions
and constraints.
- They even found issues with Verilog 2001 VPI while reviewing
which they've forwarded to that committee.
- At next level (Dec, Jan time frame) they will do another
deeper, more thorough review.
- Francoise would like to see access to data types added.
- Joao said he would send an update of VPI spec by Friday
with Cadence feedback so far incorporated.
- JohnS asked if we still have plans to convert VPI model
to UML.
- Joao said it is an issue of getting diagrams into Frame.
- Francoise said they already have a Rational Rose entry of
all of Verilog 2001 VPI in UML but it is just a question of
getting the RR format converted to diagrams suitable for
FrameMaker.
- There is a standard interchange format for UML diagrams
based on XML. A lot of UML tools can import this XML
representation of UML.
- They have also been using the checking capabilities of the
UML tools to verify some of the correctness of the model.
- Bassam quickly gave an overview of his updates to trace data API.
He is still awaiting feedback from others.
- Joao asked how one would use the API to read more than one
waveform db at a time.
- We may need a per database function tray that can be used.
Each function in the API is a pointer in that tray and invoking
the function is done by calling through the function pointer
in the tray.
- Different trays could then be provided for different databases
and thus differentiation could be handled that way.
- The user would obtain a tray handle as part of initialization
for each database that is being read.
- Bassam asked if we need to do this for the data reader API,
should we also do it for the VPI in general ?
- Francoise suggested being able to couple the VPI with the data
reader API by taking an object's handle and asking for its
value changes.
- Led to a long discussion of whether the waveform database
model is disjoint with the VPI model and whether handles
case be used between them. Francoise suggested that if we're
calling the database API "extensions to VPI" we should really
support interchangeable handles.
If they are truely disjoint, it should not be called
"extensions to VPI".
- Bassam finally said that his intent was that for interactive
waveform database are intended to share the same handle
space as the simulators own VPI data model and that here
the values changes in the waveform are truely an extension
to the VPI data model.
- But he said that post simulation database handles cannot be
shared among each other or with the simulator VPI model.
- Need to clarify what portion of the database model is the
minimum required for post simulation databases vs. the full
VPI data model supported by interactive databases.
- Secondly we need to explicitly state (if this is indeed the
case ?) that interactive waveform database handles are
interchangeable with VPI simulation data model handles and
therefore full VPI data model traversable from those handles.
-- johnS
______________________________/\/ \ \
John Stickley \ \ \
Principal Engineer \ \________________
Mentor Graphics - MED \_
17 E. Cedar Place \ john_stickley@mentor.com
Ramsey, NJ 07446 \ Phone: (201) 818-2585
________________________________________________________________
This archive was generated by hypermail 2b28 : Wed Dec 03 2003 - 10:17:13 PST