for a given testbench with a number of SCE-MI transactors, is there
a requirement that *all* SCE-MI ports be bound when running a test?
If no, then what is the implementation supposed to do with inactive,
unbound ports?  It can't just leave them idle because the ports may
be inside transactors that will stop the clock while waiting for
a message on an in port or while sending a message on an out port.

Take the case of a transactor with an unbound in port, for instance.
If this transactor deasserts ReadyForCclock while it is waiting
for TransmitReady on the in port to be asserted, then the test would
deadlock unless the infrastructure would assert TransmitReady and
present some dummmy data on the Message outputs since it knows the
port is not bound.  However, this appears to be a can of worms because
there is no way the infrastructure can know what a benign Message
value is.  The issue is that although the message port is inactive,
there is no way at the SCE-MI level to indicate that the BFM should
be inactive as well.

Hmm, this leads me to conclude that all ports must be bound and
that transactors must implement an idle mechanism at the application
layer if it is desired to be able to leave transactors inactive in
certain tests.  Was this the intent of he SCE-MI committee?  I don't
recall a specific requirement that all ports be bound, but I may have
missed it/forgotten it.  Let me know if there is such a thing.  If
not, and if the committee believes it is a requirement, then I propose
we add a paragraph or sentence to that effect with a note explaining
why this requirement exists.

======================================================================

I think you're brining an application level issue
down to something the infrastructure has to worry about.
I really don't believe we need the complication of putting
this issue in the infrastructure.

It is largely up to the user interface protocols between
the application and the transactors to coordinate.

There are many opportunities for deadlocks to be introduced
due to coordniated behavior, or lack thereof, between
C models and transactors.

This is only one of those opportunities. As a general rule
the infrastructure can only do so much to prevent these
situations. 

All good points. Comments embedded.

Bojsen, Per wrote:
> Hi John,
> 
>  > We have to be careful not to fall in the
>  > trap of significant complication to the infrastructure
>  > to deal with some of this stuff for little gain realized
>  > and for only addressing the tip of an iceberg of deadlock
>  > opportunities.
> 
> Agreed.  I raised the issue primarily to find out if there
> it is mandated that the application bind all ports or not.
>  From what you say, it sounds like there is no such mandate
> and that it is up to the application to deal with the consequences
> of leaving ports unbound.

johnS:
Yes.

> 
>  > In this particular situation that you describe, I have found
>  > it useful in the past to not bind to transactors whose interfaces
>  > that are disabled from a given simulation. Different testbenches
>  > can be configured to stimulate different interfaces while
>  > other interfaces remain idle.
> 
> I agree that this is an important use model if for no other
> reason than that emulation compilation is very expensive.
> The user will want to be able to use the same hardware configuration
> with as many tests as possible so it is important to be able to
> leave transactors idle.  However, leaving transactors idle at
> the application level does not necessarily translate to leaving
> ports unbound.  For instance, Zaiq has defined an application
> level idle mechanism for its SCE-MI transactors.  We still bind
> to all SCE-MI ports.  The application will tell unused transactors
> to idle indefinetely.

johnS:
Let's allow for either approach.

> 
>  > In such a scenario it might be typical for a transactor to
>  > monitor in input port to wait for an activation transaction
>  > but not stop the clock.
> 
> So when you are not using the transactor you leave the port
> unbound and it will wait forever without stopping the clock . . .

johnS:
Yes.

> 
>  > In fact, stoppage of clocks while
>  > blocking for the first input is more atypical than typical.
> 
> Interesting.  I assume you have at least one transactor that
> will stop the clock at the beginning of emulation, though,
> otherwise how can you guarantee repeatable cycle stamp
> values?

johnS:
Perhaps one could have a global "reset transactor" that does this.
But all interface transactors would not need to stop the clock.

> 
>  > It logically follows then that for output ports, we should
>  > never have a clock stoppage either because disabled transactors
>  > should never send output.
> 
> But in order to be able to disable the transactor it must have
> an input port, right?  This is an important guideline for hte
> transactor coding guidelines document as you point out.

johnS:
Good point.

Alternatively, the infrastructure could send outputs from
"output only" transactors to the bit bucket if their ports
are never bound.

In otherwords, the C side, by not binding an output port, is
declaring "I shall ignore all output from this transactor".

Infrastructure can optimize accordingly.

> 
>  > And I think non-bound ports can be quite a useful feature
>  > when used correctly.
> 
> So essentially you confirmed that there is no requirement that
> all ports be bound and you also confirmed that idling of
> transactors must be handled at the application level.  I am
> fine with that.
> 
> We can probably close this issue real quick unless somebody
> else objects :-)

johnS:
Great !

> 
> Per
> 

-- johnS

======================================================================