[sv-cc] List of issues Synopsys VPI extension donation presentation - part II


Subject: [sv-cc] List of issues Synopsys VPI extension donation presentation - part II
From: Swapnajit Mittra (mittra@juno.com)
Date: Wed Nov 12 2003 - 20:48:09 PST


   Fwding Avinash's list of VPI issues.

  --
  Swapnajit Mittra
  Project VeriPage ::: http://www.angelfire.com/ca/verilog

  ---------- Forwarded Message ----------
>From owner-sv-cc Wed Nov 12 17:37:26 2003
Received: from vaxjo.synopsys.com (vaxjo.synopsys.com [198.182.60.75])
        by server.eda.org (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id hAD1bP8h015584
        for <sv-cc@eda.org>; Wed, 12 Nov 2003 17:37:26 -0800 (PST)
Received: from crone.synopsys.com (crone.synopsys.com [146.225.7.23])
        by vaxjo.synopsys.com (Postfix) with ESMTP id A2DFEDFD1
        for <sv-cc@eda.org>; Wed, 12 Nov 2003 17:37:24 -0800 (PST)
Received: from synopsys.com (localhost [127.0.0.1])
        by crone.synopsys.com (8.9.1/8.9.1) with ESMTP id RAA02811
        for <sv-cc@eda.org>; Wed, 12 Nov 2003 17:37:23 -0800 (PST)
Message-ID: <3FB2E053.3080601@synopsys.com>
Date: Wed, 12 Nov 2003 17:37:23 -0800
From: Avinash Mani <avinash@synopsys.com>
Organization: Synopsys Inc.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: sv-cc@server.eda.org
Subject: Summary from Synopsys VPI extension donation presentation
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

Hello All,
Here is a summary of what I captured during the VPI donation
presentation today.

General Comments :
1) Some of the captions and use of lines etc have to revised and
corrected where required.
2) Packages need to be added everywhere in diagrams we have instances
currently.
3) Other extensions are required regarding vpi_get_value() /
vpi_put_value() and also changes to the callbacks.

Variables: Page 7 and 8:
1) the vpiBit<āvpiParent relationship should be only for the bit var not
for any other variables types also this relationship should be
one-to-many from parent to the bit var.
2) How to get to part selects and bit selects for Variables? --- Not
available yet (reg type capability) *** Notes 2 and 9.
3) The integer type variable is missing from the diagram for Variables
4) The bubbles for variable driver and variable load on the var
select are redundant and should be removed
5) Variable diagram is in many respects a merger of reg/reg array and
the variable diagram from 1364
6) Consider the need for cbTypeChange callback, should be discussed and
included and required.
7) An order of firing cbSizeChange and cbValueChange callbacks should be
defined logically it seems that the cbSizeChange should fire first.

Variable Drivers/Loads Page 9:
1) You will now get multiple drivers or loads when a query is done. Then
the application has to do additional processing to figure out which bits
of the variables are affected by which drivers.
2) Note No. 2 we should specify that for an unpacked array or memory you
can get drivers to the entire array and also every element of the array
and also part selects/bit selects of elements of the array.
3) Should we generalize the notion of drivers/loads to mean
readers/writers to make applications simpler, these are not of a
permanent nature, they can change. This should probably be in a separate
new class definition and we should not change the drivers/loads class
definitions

Instance Arrays: Page 9:
1) **** In all VPI diagrams wherever we have instances we have to add
packages since the package proposal has been accepted.

Scopes: Page 10:
1) Name of unnamed stuff is going to be undefined it will be depend on
implementation
2) Missing a relationship arrow back from the InternalScope to the Scope.
3) Declarations in unnamed regions can cause inconsistencies and
probably should be looked into and cleared defined as to what is allowed
and what is not allowed.
4) Should clocking domains be in scopes as well? Check if clocking
domains can make declarations
5) *** Scopes section pertains to static hierarchy which is always
available not for dynamic entities such as assertions or other properties.
6) How do classes fit in here and how do you reach classes that are not
instantiated to reach the static variables from the class?

IO Decl: Page 11:
1) Only difference is that we have a one-to-many relationship to range.
This is to support MDAs and slices of MDAs as io declarations
2) We should add interface and class to the relationship along with
module udp defn etc&
3) This diagram pertains to the formal side.
4) Due to the complexity of the type system of SV vs. 1364 we should
introduce a system in VPI to access types without making repeated
queries on flat types.
5) typedef access has to be added to VPI so that typedefs are maintained
for VPI purposes even after elaboration. Further discussion is required.
Joao : this will simplify things but it would break the current VPI from
1364.
6) *** Default values for task and function declarations have to
represented. This has been left out from this diagram.

Clocking Domain: Page 11:
1) Clocking domain diagram should also have a fullname.
2) Clocking IO decl diagram both the direction and the name should be
properties not objects
3) Relationship for skew gives the explicit skew not the default skew.
This will refer to the active skew.
4) It would be useful to also be able to access the default skew, to
ascertain if this is different from the active skew.
5) In the clocking domain diagram the vpiClocking should not be in bold.
6) Check the BNF on the clocking domain and make sure that the skew and
sampling/driving edge should be separated from each other.

Task/Function: Page 18:
1) DPI extern is required as a property
2) What is the virtual here? Is it related to virtual tasks, yes SV3.1
has virtual methods in classes, this refers to that property of a
certain task/function

Alias statement: page 19:
1) Arrow from instances to alias should be many to one type.
2) Can we have aliases on other types than nets?

Frame/Thread: page 20 and 21:
1) Thread is a stack of frames
2) Arrow needed pointing back from frame to thread on the thread diagram
on page 21.
3) We should have a frame for all tasks/functions and always type
processes that are active especially to accommodate the possible
automatic variables everywhere

Property Spec: page 24:
1) Need to separate the variables from the rest and have an arrow back
to the property
spec from the variables.

Property Expr: page 25:
1) Should just point to an Operation rather than fanout to 3 different
possibilities.

Sequence Expr: page 27:
1) The iterator to assignment should be from the seq expr directly there
is no need for the reference to expr inside the sequence expr.

Atomic Statement: page 29:
1) jump should be expanded to return, break and continue

________________________________________________________________
The best thing to hit the internet in years - Juno SpeedBand!
Surf the web up to FIVE TIMES FASTER!
Only $14.95/ month - visit www.juno.com to sign up today!



This archive was generated by hypermail 2b28 : Wed Nov 12 2003 - 20:51:54 PST