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.