Subject: Re: Proposed global requirements for all SV APIs
From: Joao Geada (Joao.Geada@synopsys.com)
Date: Mon Aug 19 2002 - 16:08:10 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.
You're welcome and thanks for the comments. My comments attached.
>
> >
> > 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 ?
Good question. I personally believe these should be treated as exception
cases: individually identified and corrected, either by making the necessary
changes to the bad API and/or by providing an alternative "clean" API for the task.
> > 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!
Yes you are correct, I was not strict enough. I definitely intended that code, once compiled on a given
platform, should interwork with all simulators providing these APIs (with the possible exception
of special tool specific value formats that may be requested by an application for efficiency
purposes, but this must be only at the specific request of the application and alternative portable
formats have to exist)
> > 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?
Yes, your use cases UC1 through UC6.
> > 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.
Good point. Make that 7.5 !
> 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.
This one is trickier, though I agree with the intent. It causes an "interesting" amount of careful implementation
work to do an efficient thread safe API and even in then there is a performance loss (a larger number of
registers are reserved for the compiler, accesses to global data have to be guarded against concurrent
access/modification etc) relative to the more straight-forward plain API. I'd prefer to provide a
locking/concurrency control API as a separate beast to control access to the simulator, leaving all the
other APIs unencumbered; then threading guarantees could be made specific only to the correct use of
the locking API.
> > 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.
Anything that causes events to be consumed by the scheduler.
It is difficult to be more specific here as different Verilog simulators have very different
notions about scheduling behavior and the standard is not particularly helpful for users there.
Joao
==============================================================================
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 : Mon Aug 19 2002 - 16:10:36 PDT