RE: [sv-ec] How do I make a "Virtual Port"

Steven, Gord,

Sure, If there are issues with automatic variables then restricting this
to static ones is fine with me.  The major benefit I see from this comes
from accessing/referencing DUT state and interface which are static
anyway.  So either of your suggestions (they are very similar) works for
me.  A restriction to static is clearly what I want.  If that isn't too
much of an implementation issue, I think this will be very beneficial to
add to the language (on the next round of course).  Another qualifier on
ref that explicitly states it as 'static' works for me. Do you want me
to post this as an sv-ec mantis issue?

Thanks, -Tom

-----Original Message-----
From: Steven Sharp [mailto:sharp@cadence.com] 
Sent: Monday, October 06, 2008 2:46 PM
To: Dave_Rich@mentor.com; sv-ec@eda.org; stuart@sutherland-hdl.com;
Alsop, Thomas R
Subject: RE: [sv-ec] How do I make a "Virtual Port"

Tom,

One major problem with your request is that automatic variables could be
passed to the ref arguments of your new() function.  It would record
their
addresses in the class and then return to the caller.  The caller could
then exit the scope of the automatics, which would cease to exist.
Their
memory could then be re-used for something else.  Attempting to access
them
through the now stale refs in the class could then corrupt whatever they
were used for.  This could cause bizarre results, or crash the
simulator.

This is the same reason that fork..join_none/join_any subprocesses were
not
allowed to access ref arguments.  In the same way, they could use the
ref
arguments to continue accessing automatic variables that had been
deallocated.

There were several possible solutions to this problem.  One suggestion
was
that automatics should all be treated as heap objects, like classes, and
go through the same allocation and garbage collection process.  This
approach
was rejected due to its inefficiency.  That left a couple of possible
ways
to restrict things.  One was not to allow automatic variables to be
passed
by reference in the first place.  That was considered too severe of a 
restriction.  The other way was not to allow fork..join_none/join_any
subprocesses to access ref arguments.  That is what was adopted.

Now you are proposing another way to keep references to variables around
indefinitely.  This runs into the same problem.  They cannot be allowed
to refer to automatic variables.  If they were a separate construct,
then
you could just make this rule.  For your purposes, you only need to
refer
to static design variables anyway.  But you want them to be able to be
assigned from ref arguments.  If the previous problem had been solved by
not allowing automatics to be passed by reference, then this would be
fine.
But it was not solved that way.  Automatic variables can be passed by
reference, so any ref argument could refer to an automatic variable.

I suppose you could introduce the concept of a qualifier on a ref arg
that indicated that it was a ref to a static.  This could be similar to
"const ref" (which probably should have used the syntax "ref const"). 
You could have "ref static logic i", and only allow a static value to be
passed to it.  Passing an automatic or a ref to non-static (which could
be an automatic) would be disallowed.  Then you could allow things for
"ref static" args that you would not allow for ordinary ref args.  That
could include referencing them in fork..join_none/join_any and assigning
to your pointer types.

In general, introducing more general pointer types is going to create a
lot of potential safety issues.  That is presumably the reason why they
were so restricted in the first place.  The design philosophy has been
to
make the language safe from pointer errors.  The reasoning is presumably
that hardware designers do not want to have to deal with the kind of
pointer bugs that software engineers have to deal with.  Even for
engineers
with experience dealing with unsafe pointers, SV has a lot of features
that
other languages don't, which complicate the situation.  For example, the
fact that fork..join_none creates problems with passing automatic
variables
by reference was not obvious to most people.  Furthermore, if you have a
pointer bug that results in corrupting simulation state or internal
simulator data structures, you may have no way of debugging it to find
your mistake.

Steven Sharp
sharp@cadence.com


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.