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

Duh. That's what I get for jumping right into the body and not reading
the subject line.

But a ref port of a module and a ref argument of a task is actually the
same thing. And it's the same as what you get when you don't use a
modport in an interface to access a variable in an interface. You're
getting another name to reference the same variable, not another
variable.

There is no restriction on any variable data type that could be used as
a formal port except a chandle (which is a restriction that could be
easily relaxed, but not very useful). There are only a few restrictions
for the actual expression connected to the port, like selects of dynamic
variables. There are no restrictions on events that I am aware of.

An SV event is a weird object if you don't know its history in Verilog.
In Verilog, an event data type was just valueless variable. In SV, an
event data type is a reference variable to a valueless object that is
constructed by default. This construction by default behavior was to
make this new reference event backward compatible with the existing
Verilog event. It works because Verilog never allowed an event in the
context of an assignment.

In the context of an assignment, an event is no different than a class
handle variable copying a reference. You can think of an SV event data
type as a shortcut for a class object with a single member event
variable. In the context of a trigger or event expression, you are
actually referencing the member, not the handle. In fact, this is what I
tell people to do when they want a queue of events or an associative
array of events since there is no way currently to explicitly construct
an event object.

Dave


> -----Original Message-----
> From: Steven Sharp [mailto:sharp@cadence.com]
> Sent: Saturday, October 27, 2007 2:09 PM
> To: Rich, Dave; sharp@cadence.com; cliffc@sunburst-design.com; sv-
> ec@eda.org; jonathan.bromley@doulos.com
> Subject: Re: Can modules have ports of [ref] event type?
> 
> 
> >From: "Jonathan Bromley" <jonathan.bromley@doulos.com>
> 
> >My question was whether you can
> >have a module/interface/program port of event type,
> >or of ref event type.
> 
> Sorry Jonathan.  My mind jumped the track from ports to arguments,
> and apparently dragged Dave along :-)
> 
> 
> >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.
> 
> While I think there is an oddity here, I don't think it makes the
> construct unimplementable.  To make it work, the continuous assignment
> would have to wait for the hiconn event handle to change, and then
> update the loconn event handle accordingly.  Any triggers on the event
> would be irrelevant to the continuous assignment.
> 
> The oddity is that I had to derive this rule for the behavior based
> on what would be necessary to make it work.  I don't think that it
> follows clearly from the text in the LRM.
> 
> Another way to see the oddity is that this algorithm for the
continuous
> assignment cannot be expressed in procedural code with the usual
> equivalent combinational always block.  If you tried to express it
with
> 
> 	always @(hiconn_event)
> 		loconn_event = hiconn_event;
> 
> you run into the problem that the hiconn_event in the event
> control is not a wait for the handle value to change.  It is a
> wait for a trigger on the event object that it references.
> This implicit dereferencing of an event in an event control
> makes it difficult to express procedurally a wait for the handle
> to change.  This might also create a problem for a tool trying
> to implement the continuous assignment, since it would presumably
> require special treatment as a result.
> 
> This also presents a problem in the definition of
> 
> 	always_comb
> 		loconn_event = hiconn_event;
> 
> making it not be equivalent to
> 
> 	assign loconn_event = hiconn_event;
> 
> A continuous assignment to a variable is usually equivalent to
> replacing "assign" with "always_comb", but apparently not in this
> case.
> 
> >One simulator permits both "input event" and "ref event"
> >ports on a module, another forbids both.
> 
> It would not surprise me for an implementation not to support this.
> The implementor might not have even considered the possibility.
> Or if they did, they might have noticed the oddity and concluded
> that it was illegal.
> 
> 
> >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.
> 
> If it is supposed to be legal, then I agree that it should be
> clarified.  As I said, I don't think the required behavior for the
> continuous assignment follows from the existing LRM text.
> 
> 
> Steven Sharp
> sharp@cadence.com


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