[sv-ec] Can modules have ports of [ref] event type?

From: Jonathan Bromley <jonathan.bromley_at_.....>
Date: Sat Oct 27 2007 - 13:15:34 PDT
Dave Rich wrote:

> 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.

I suspect I didn't sufficiently clarify my concerns.

Obviously I am aware that you can pass an event as a ref or
input argument to a task, and that you're not likely to 
need "ref" in such a situation, since the event argument
is itself a reference.  My question was whether you can
have a module/interface/program port of event type, 
or of ref event type.  

Having a module port of input event type suggests that
there is a continuous assignment of one event reference
(the hiconn, a real event or event handle in the outside
world) to the event handle represented by the port's loconn.
That struck me as faintly curious, which is why I felt
that an event port, if it's permissible at all, perhaps
should be a ref.  However, I'm not too worried about that
difference at this stage.  Note what I said below...

> > >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, 

[note carefully]
> > > with either "ref" or "input" direction;
> > >another simulator reports both cases as an
> > >error.

One simulator permits both "input event" and "ref event" 
ports on a module, another forbids both.  
And as Steven Sharp said:

> > I don't know whether it is supposed to be legal.

If someone can tell me where in the LRM it is
permitted or forbidden, I'll be happy - and repentant
if necessary.  Otherwise, perhaps we should clarify it.
-- 
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK
Tel: +44 (0)1425 471223                   Email: jonathan.bromley@doulos.com
Fax: +44 (0)1425 471573                           Web: http://www.doulos.com

The contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Sat Oct 27 13:15:58 2007

This archive was generated by hypermail 2.1.8 : Sat Oct 27 2007 - 13:16:19 PDT