Subject: RE: $sv-ec References in SystemVerilog (proposal)
From: David W. Smith (david.smith@synopsys.com)
Date: Tue Sep 24 2002 - 13:04:57 PDT
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.
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.
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
To: sv-ec@eda.org
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:
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.
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.
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.
Steven Sharp
sharp@cadence.com
This archive was generated by hypermail 2b28 : Tue Sep 24 2002 - 13:07:40 PDT