RE: SCE-MI: Can some ports be left unbound?

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.

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

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

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

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

> 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 :-)

Per
Received on Wed, 17 Mar 2004 14:45:45 -0500