Subject: Re: DirectC C-Layer: open arrays and abstract access
From: Kevin Cameron (Kevin.Cameron@nsc.com)
Date: Fri Dec 20 2002 - 10:11:51 PST
Michael Rohleder wrote:
> Hello Francoise,
>
> having used until now only acc_ and tf_ functions I have taken a deeper look into vpi to make sure I really understand what you want to say. As a result of this excercise I am even hanging more towards Joao's side of having a self-contained I/F; -- if a normal design engineer has to search through all this document pages - just to find out how to get some array properties - a lot of the simpleness and ease-of-use of DirectC will be lost.
> On the other side I understand - and even support - your request for compatibility with VPI.
> The most obvious question resulting from this would be: would it not be possible to define the abstract handle provided by DirectC to be a VPI handle (or to be compatible to it)? Then this handle could be used directly by any VPI function ...
That's what's in my proposal. My working assumption is that access to new data types has to be available
through VPI (and/or PLI) anyway, so you might as well use the same mechanism for argument access from
C called from SV - it makes your code more reusable and avoids having to spec two interfaces.
From an implementation/performance point of view it isn't a big overhead since you only need to enable
VPI for hierarchy browsing and for the arguments themselves. The data for hierarchy browsing is static
and should not impact on runtime performance. Since the simulator knows when the VPI calls are being
made from C it has just called, it is possible to optimize those calls for faster access, it is also possible
to say that those particular handles are volatile and cannot be saved by the C for future use - which would
allow the supporting structures to be created temporarily on the call stack (obviates garbage-collection).
Kev.
> Just my $0.02
>
> -Michael
> Francoise Martinolle wrote:
>
>> At 05:30 PM 12/17/2002 -0500, Joao Geada wrote:
>>
>> > Francoise
>> >
>> > the problem with the VPI approach is that VPI (as described in the standard)
>> > is a very indiscriminate interface: once you have VPI enabled you can do
>> > *anything, anywhere*. Sure, every vendor has come up with (mutually incompatible)
>> > approaches to reign in these capabilities but these approaches:
>> > a- require the user to unerringly specify the access they need for each and
>> > every instance/signal across an entire design
>>
>>
>> Not really. The user is only to required to specify the access they need if this access is not obvious.
>> When using user-defined system task or functions, VPI or PLI access to the arguments
>> must be provided by the simulator because the C code may access at least the arguments.
>> A directC function should just be treated as a user-defined task in that
>> respect and if an abstract handle has to be passed because it is an open array, that handle
>> should be a vpi handle. Access to the array types, dimensions, left and right ranges and
>> values of the elements is fully defined in VPI.
>>
>>
>> > or
>> > b- rely on some "learning" mechanism for the simulator to attempt to identify
>> > what signals the user/application will access/modify
>>
>>
>>
>>
>>
>> > One of the conveniences of DirectC is doing away with all those complex, fragile
>> > and vendor-specific approaches. Instead, the user just puts in the appropriate
>> > extern declaration and can then start using the function. No fuss, no complexity.
>> > Both the compiler and the user know straightaway what is needed/available with
>> > no room for error.
>> >
>> > As soon as VPI comes into the picture all that nicety goes straight out, and I
>> > do not believe anyone has made a compelling argument as to why we should discard
>> > the user-friendly properties that a DirectC-specific interface provides.
>>
>>
>> I like the directC access but for open arrays, I don't see any direct access defined, I see
>> an abstract handle which you have to access with some API functions.
>>
>>
>>
>> > Please note that I am not against judicious use of VPI (eg assertion API proposal
>> > I sent yesterday is now a VPI extension). I am just concerned that each interface
>> > preserves all its required properties.
>>
>>
>> Understood and I have the same opinion; that's way leave abstract access with VPI and
>> direct access to DirectC.
>>
>>
>>
>> > Joao
>> > ==============================================================================
>> > Joao Geada, PhD Principal Engineer Verif Tech Group
>> > Synopsys, Inc TEL: (508) 263-8083
>> > 344 Simarano Drive, Suite 300, FAX: (508) 263-8069
>> > Marlboro, MA 01752, USA
>> > ==============================================================================
>> >
>> >
>> > -----Original Message-----
>> > From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org]On Behalf Of
>> > Francoise Martinolle
>> > Sent: Tuesday, December 17, 2002 4:49 PM
>> > To: Andrzej Litwiniuk; sv-cc@eda.org
>> > Subject: Re: DirectC C-Layer: open arrays and abstract access
>> >
>> >
>> >
>> > I would not want to create yet another abstract interface. We already have
>> > VPI and PLI.
>> > VPI access to multi-dimensional arrays is already defined in Verilog 1364
>> > 2001 and with
>> > some modifications it can be enhanced to manage open arrays.
>> > VPI provides a nice interface to iterate over the elements of an array and
>> > to get
>> > the value of each element. VPI should be the abstract access interface.
>> > DirectC should be the interface to use for direct access.
>> >
>> > Francoise
>> > '
>>
> --
>
> NOTE: The content of this message may contain personal views
> which are not neccessarily the views of Motorola, unless specifically stated.
>
> ___________________________________________________
> | |
> _ | Michael Rohleder Tel: +49-89-92103-259 | _
> / )| Software Technologist Fax: +49-89-92103-680 |( \
> / / | Motorola, Semiconductor Products, System Design | \ \
> _( (_ | _ Schatzbogen 7, D-81829 Munich, Germany _ | _) )_
> (((\ \>|_/ > < \_|</ /)))
> (\\\\ \_/ / mailto:Michael.Rohleder@motorola.com \ \_/ ////)
> \ /_______________________________________________\ /
> \ _/ \_ /
> / / \ \
>
> The information contained in this email has been classified as:
> Motorola General Business Information (x)
> Motorola Internal Use Only ( )
> Motorola Confidential Proprietary ( )
>
>
> *** This note may contain Motorola Confidential Proprietary or
> Motorola Internal Use Only Information and is intended to be
> reviewed by only the individual or organization named above.
> If you are not the intended recipient or an authorized representative
> of the intended recipient, you are hereby notified that any review,
> dissemination or copying of this email and its attachments, if any,
> or the information contained herein is prohibited. If you have received
> this email in error, please immediately notify the sender by
> return email and delete this email from your system.
> Thank you! ***
>
-- National Semiconductor, Tel: (408) 721 3251 2900 Semiconductor Drive, Mail Stop D3-500, Santa Clara, CA 95052-8090
This archive was generated by hypermail 2b28 : Fri Dec 20 2002 - 10:12:18 PST