Subject: Re: Proposed global requirements for all SV APIs
From: Michael Rohleder (michael.rohleder@motorola.com)
Date: Mon Aug 19 2002 - 05:08:49 PDT
Joao,
thanks a lot for provinding this list. I have interspersed some comments in this list. Hope you all find this is useful information.
Regards,
Michael
Joao Geada wrote:
> 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.
What about functionality that is substantially flawed in an 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.
I think this statement is not strict enough. Simple example: we have implemented a PLI interface for C/C++ models for many of today's commercial simulators. One of them had special header files that converted some of the provided functions; resulting in a
different object code that did NOT run on other simulators. So the compatibility was on the source code level, but you have to recompile to make sure the resulting object code is working within the particular simulator.
We must make sure that this situation is avoided; it is a nightmare to have a different object code for different platforms (Solaris, HP-UX, AIX, Linux, NT) _and_ different simulators!
> 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.
Please specify which point-tasks you envision. I tried to do this with my Use Cases.
Is there another level of tasks or what are you talking about?
> 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.
We also need to define a versioning mechanism for the API (e.g. identify version# of the API and version# of related/used data structures -- if it makes sense to defines versions at this level; there is also a certain tradeoff w.r.t. speed here). We also
should do this in a way that later extensions of the API, as well as related structures are possible.
There is also a need to identify the correctness of a function in a multi-threading environment; e.g. identify the whether a API function is multi-threading-save or not. Many of today's C/C++ dialects use multi-threading capabilities; we should at least
give the user some hint what (s)he can expect.
> 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.
Please be more specific. VHDL defines delta-cycles, which do also not consume time, but are still advancing the simulation; I think you also want to prohibit these cases -- the important aspect is that the simulator is the master, not the comsumption of
time.
> 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
> ==============================================================================
-- Quote of the day: "Better to remain silent and be thought a fool than to speak out and remove all doubt." [Abraham Lincoln (1809-1865)]NOTE: The content of this message may contain personal views which are not neccessarily the views of Motorola, unless specifically stated.
The information contained in this email has been classified as: Motorola General Business Information (x) Motorola Internal Use Only ( ) Motorola Confidential Proprietary ( ) when marked, please note: This e-mail and any attachments are confidential and Motorola reserves all rights of privilege in respect thereof. It is intended for the use by the addressee only. Please delete it from your system, if you are not the intended recipient. Any use, disclosure, or copying of the included information is unauthorised. ___________________________________________________ | | _ | Michael Rohleder Tel: +49-89-92103-259 | _ / )| Software Technologist Fax: +49-89-92103-680 |( \ / / | Motorola, Semiconductor Products, ASA Methodology | \ \ _( (_ | _ Schatzbogen 7, D-81829 Munich, Germany _ | _) )_ (((\ \>|_/ > < \_|</ /))) (\\\\ \_/ / mailto:Michael.Rohleder@motorola.com \ \_/ ////) \ /_______________________________________________\ / \ _/ \_ / / / \ \
This archive was generated by hypermail 2b28 : Mon Aug 19 2002 - 05:10:38 PDT