Subject: RE: $sv-ec References in SystemVerilog (proposal)
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Tue Sep 24 2002 - 14:25:44 PDT
> From owner-sv-ec@server.eda.org Tue Sep 24 13:11:46 2002
>
> Just as a comment in passing. I think we need to focus on what the two
> requirements are that have come from the other groups. These are the
> reason the pointers were moved from an inactive state to active:
>
> 1. support for opaque pointers in C interface/API.
You can probably just use longint for that.
> 2. support for pass by reference semnantics for passing structures (and
> other composite types) as arguments.
>
> The definition of the "var" keyword for use in argument passing defined
> on page 2-11 of the Testbench donation is designed (I believe) to handle
> this.
My proposal just removes "var" and replaces it with "&" - one less keyword
and less typing since it's associated with the identifier instead of the
type (like C), otherwise the intent is the same.
> While there may be many other valuable things that could be added
> related to pointers we need to focus on the two requirements that we
> have to meet.
>
> I think that Steven comments are still relevant in this context but need
> to be worked through.
>
> Regards
> David
>
> -----Original Message-----
> From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of Steven Sharp
> Sent: Tuesday, September 24, 2002 11:42 AM
> Subject: Re: $sv-ec References in SystemVerilog (proposal)
>
>
> I would like to point out some serious issues with trying to add
> pointers to Verilog. Verilog variables are not simple storage locations
> that you can just write to, like variables in most other languages
> (including C and VHDL). They have a lot of extra semantics already
> defined for them. They can have fanout that has to be notified any time
> the value changes. They can have procedural continuous assigns and
> forces applied to them, which prevent any other writing to them.
>
> Any write to a Verilog variable via a reference type is going to have to
> handle all of this properly and efficiently. That rules out any kind of
> simple pointers that are just addresses of data storage and can be
> manipulated arithmetically, like in C. Off the top of my head, I can
> see a few ways of trying to deal with this:
My proposal is just a rehash of "var" with additional functionality. You
can view a reference as a macro substitution, it doesn't assume anything
about the structure of the object in memory. You can view it as a "safe"
subset of pointer functionality.
> 1. Define a new type of variables that act like variables in other
> languages, and don't allow the full functionality of existing Verilog
> variables. Only allow pointers to variables of this type.
I think the 2-state stuff is supposed to operate that way already, but
I wasn't advocating adding C style pointers at this time. If SuperLog
is the only existing implementation of SV and it already does lay out
data in a C compatible way then we should probably make some statement
about pointers/data layout so that other implementations will support
pointers too if we decide we want them.
> 2. Severely restrict what can be done with reference types so that the
> system can easily keep track of what object any reference object refers
> to. For example, no pointer arithmetic. The same restrictions should
> help avoid some of the bugs that come up with unrestricted pointers, and
> which many hardware engineers will not be familiar. Note that even
> these restricted reference types would kill many optimizations on any
> object that might be referenced.
There's nothing intrinsically wrong with pointer arithmetic, it just
tends to be error prone (/unsynthesizable). By contrast "reference
arithmetic" always refers back to the referenced object to evaluate
whether an operation is valid or not, i.e. a pointer to an element in
an array contains no information about the array, a reference to an
array element will have access to the array dimensions as well as the
index information to pick out the refence target - how that information
is stored would be entirely up to the implementation.
> 3. Turn all reference types into more complex descriptors that keep
> track of what object they reference plus an address somewhere in the
> storage for the object. This requires extra work for every operation
> involving the reference type, slowing down simulation. This is in
> addition to the other effects on optimizations.
That was implied in the proposal by making the reference invalid/null
if arithmetic takes it out of range. How much extra work is required
depends on the implementation.
The proposal is mainly intended to make it easy to translate C/C++
to SV and vice versa.
> Steven Sharp
> sharp@cadence.com
I'll be doing a rewrite shortly :-)
Regards,
Kev.
This archive was generated by hypermail 2b28 : Tue Sep 24 2002 - 14:31:23 PDT