RE: [sv-ec]E-mail Vote: Closes 12am PST October 26th 2007

There is nothing illegal about passing an event by reference, although
there may be other rules in play that prevent a ref argument.

As you point out, it is rare that you need to pass an object that is a
reference by reference. It's also rare that you need to pass any object
by reference in SV unless you have a blocking task that needs to
propagate values through the argument as time progresses.

Dave


> -----Original Message-----
> From: owner-sv-ec@server.eda.org [mailto:owner-sv-ec@server.eda.org]
On
> Behalf Of Steven Sharp
> Sent: Saturday, October 27, 2007 9:35 AM
> To: cliffc@sunburst-design.com; sv-ec@server.eda.org;
> jonathan.bromley@doulos.com
> Subject: RE: [sv-ec]E-mail Vote: Closes 12am PST October 26th 2007
> 
> 
> >I can't find anywhere in the LRM that forbids
> >ports of type "ref event"; the BNF definitely
> >admits it, though of course that is not very
> >strong evidence.  The little example below
> >works in at least one simulator, with either
> >"ref" or "input" direction; another simulator
> >reports both cases as an error.  Is it illegal?
> 
> I don't know whether it is supposed to be legal.
> 
> But I will point out that you wouldn't need to use a ref port to
> pass the original event object, and wait on or trigger it.  The
> event is already a reference to the synchronizing object, and
> passing it to an input port should give access to that object,
> just like any assignment of one event to another.  The only reason
> you would need to pass it by reference is if you wanted to be able
> to make an assignment to the ref arg inside the subroutine, and
> have that affect what synchronizing object the actual argument
> pointed to.
> 
> Note that this would mean it was illegal to pass a clocking block
> as a ref arg, since that would allow assigning to it.  At most,
> you could pass it as a const ref arg, though I don't see any
> advantage that would give over passing it as an input.
> 
> Steven Sharp
> sharp@cadence.com
> 
> 
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.


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