Subject: Proposed global requirements for all SV APIs
From: Joao Geada (Joao.Geada@synopsys.com)
Date: Wed Aug 14 2002 - 14:13:05 PDT
SV-CC GLOBAL REQUIREMENTS:
NOTE: DFLI == Direct Foreign Language Interface
These are the requirements I believe should apply to all the APIs to System Verilog
1- all APIs are to be defined as C function-based APIs.
Justification: C has been standardized long enough and well enough
that C compilers can generate code that works together with code
from other C compilers. Standards compliance for all important parts
of the C language is adequate on all platforms. The same cannot
currently be said for any other foreign language of interest to the
verification community (eg C++). Furthermore, due to the importance
of C, all other interesting programming languages can communicate
with a C API.
1.2- APIs should consist of only function interfaces, type definitions and
constants. No "naked variables" should be part of the user visible API
2- Interworking of APIs:
2.1- Some APIs explicitly require a design context for a specific call
(eg those related to accessing arguments to a system call). For these
APIs the context will be generated automatically by the compiler. None
of these APIs may be invoked without the correct context and can only
be used from within APIs that can supply the necessary context.
2.2- APIs that do not require context can be invoked from any place,
including the context from other APIs
2.3- There is no requirement that specific data or protocols (eg
handles or specific data types/formats) used by one API be
interchangeable with other APIs.
3- APIs should not unnecessarily duplicate functionality present in
the other APIs. For example, VPI provides a design iteration set of
APIs and therefore no other API should provide a design iteration API.
4- Barring conflict with any of the other requirements, the APIs
provided must be able to be implemented efficiently and should have
minimal impact on the ability of compiler to optimize.
NOTE: this does not imply a requirement that the APIs be
implemented efficiently, merely that such an implementation should
be possible.
5- APIs must be defined such that they can work correctly regardless
of endianess or of the word-width of the platform on which it is being
run. NOTE that this is a statement about the APIs, rather than about a
specific implementation running on a specific architecture, which will
naturally be tied to that particular architecture.
6- Dedicated APIs should be provided for dedicated "point-tasks"
Justification: In general, dedicated "point-task" APIs are to be
preferred over monolithic "do-everything" APIs because they tend to
be easier to learn, easier to use and debug and are easier to
implement. Further "point-task" APIs have more predictable impact
on optimization capabilities as their interaction with the
simulation is more circumscribed.
7- A standard mechanism must be defined to inform the compiler about
7.1- the APIs that are to be available and
7.2- any specific access/side-effects caused/needed by this usage
of the API (eg that a particular use of the VPI will require read
access to specific signals/areas in the design)
7.3- If this information is not supplied the compiler has to assume
that any access is possible and generate code accordingly.
7.4- If this information is supplied the compiler can assume this
to be correct and use this to improve the generated code. If user
provides incorrect information the behavior of the API is to be
undefined.
8- All API functions should complete in 0 simulation time ie APIs are to function
as slaves to the simulator (simulator is master, API is slave). Specifically,
the only means APIs have to affect simulation time is by returning control
back to the simulator.
Additionally, for discussion purposes (ie not a requirement), it would be ideal
if the behavior of each function in each API was to be classified according to
the general area of functionality being provided. A suggested classification
would be:
A.1- design information:
A.1.2- static design information (eg source refs, hierarchy traveral)
A.1.3- dynamic design information (eg active drivers)
A.2- callbacks (setting up, clearing, etc)
A.3- value exchange (read/write)
Another "not a requirement" is a personal observation that there are two
separate constituencies that require APIs into the language:
B.1 - application developers (including custom applications being
written by users, simulator vendors and third parties), whose primary
usage is extending the tool (eg debug/analysis/coverage/...)
B.2 - HDL developers/designers, whose primary usage is foreign language
extensions to their design environment
These different types of users have different requirements:
B.3 - application developers need APIs that provide
B.3.1 - full access to the entire design representation
with interface between design and application being implicit
(ie constructed dynamically)
B.3.2 - interface between application and design cannot be
constrained 'a priori', ie application has to be constructed
without knowing the structure of the design, and design is built
without known what the application will look at. The interface
is realized only at simulation when both parts are joined
B.3.3 - full access to any information being generated by the
design during simulation
B.3.4 - as much control as viable (ie full if possible) over the
simulation process
B.4- designers require
B.4.1- well defined interface between design and foreign
language, with the interface between design and foreign language
defined up-front in the design itself.
B.4.2- easy to use interface: minimal programming/bookkeeping
overhead to be associated with interface. The fewer handles etc
that are to be managed by the user the better
For each API, the primary type of user should be identified to
ensure that their specific requirements are addressed.
==============================================================================
Joao Geada, PhD Sr. Staff R&D Engineer Verif Tech Group
Synopsys, Inc TEL: (508) 263-8083
154 Crane Meadow Road, Suite 300, FAX: (508) 263-8069
Marlboro, MA 01752, USA
==============================================================================
This archive was generated by hypermail 2b28 : Wed Aug 14 2002 - 14:15:09 PDT