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

Per,

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

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.

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. In fact, stoppage of clocks while
blocking for the first input is more atypical than typical. A
C model that wishes to bind to this trasactor might send an
"activate" transaction. Absent that, the disabled transactor
would remain idle for the entire simulation - but not 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.

So really I think at the specification level this should be
a non-issue. However, a "transaction coding guidelines" document
could certainly suggest proper usage here.

And I think non-bound ports can be quite a useful feature
when used correctly.

-- johnS

Bojsen, Per wrote:
> Hi,
>
> 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.
>
> Thanks,
> Per
>
> --
> Per Bojsen Email: <bojsen@zaiqtech.com>
> Zaiq Technologies, Inc. WWW: http://www.zaiqtech.com
> 78 Dragon Ct. Tel: 781 721 8229
> Woburn, MA 01801 Fax: 781 932 7488
>

-- 
This email may contain material that is confidential, privileged
and/or attorney work product for the sole use of the intended
recipient.  Any review, reliance or distribution by others or
forwarding without express permission        /\
is strictly prohibited. If you are     /\   |  \
not the intended recipient please     |  \ /   |
contact the sender and delete        /    \     \
all copies.                      /\_/  K2  \_    \_
______________________________/\/            \     \
John Stickley                   \             \     \
Principal Engineer               \             \________________
Mentor Graphics - MED             \_
17 E. Cedar Place                   \   john_stickley@mentor.com
Ramsey, NJ  07446                    \     Phone: (201) 818-2585
________________________________________________________________