[sv-ec] 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.