RE: Yet Another ServiceLoop() Question

Hi John, Per,
    Should any of this be reflected in the specification?

Brian

-----Original Message-----
From: owner-itc@eda.org [mailto:owner-itc@eda.org] On Behalf Of John
Stickley
Sent: Friday, March 24, 2006 7:52 AM
To: bojsen@zaiqtech.com
Cc: itc@eda.org
Subject: Re: Yet Another ServiceLoop() Question

Per,

This is indeed a way of deadlocking the System.

To be "well behaved" and avoid this transactors need to be
designed in one of two ways:

1. They are prepared to always take input (on any uclock)
    to avoid a backup on the channel.

    In this scenario it is often the case that an output
    port is ultimately used to tell the S/W side when it
    is OK to send the next input, thereby acheiving throttling
    that way.

    A caution is that, in certain scenarios this can cost extra
    output ports (where none might otherwise be needed) which can
    be expensive and using an input ready mechanism (#2 below) might
    be cheaper.

2. If 1 is not possible, they need to deploy input ready callbacks
    as flow control whereby the S/W model is well enough behaved
    to know not to messages until the input ready callback is
    received.

For #2 good streaming performance can be realized if
the input port transactor asserts ReceiveReady immediately
for the next data even as it takes the current data and processes
it further rather than waiting until it processes the
first data and then decides "ok, now I'm ready for the
next data, let me assert receiveReady".

Of course with SCE-MI 2 pipes the beauty is that the
infrastructure, not the user can worry about all of this.

-- johnS

Per Bojsen wrote:
> Hi,
> 
> 
>>Now, what happens with the second message?  If the transactor does
>>not assert ReceiveReady the message cannot be sent to the port since
>>the first message is still waiting to be transferred.  Hence, the
>>first while loop will loop forever or at least until the transactor
>>decides to assert ReceiveReady, that is we have a deadlock.
> 
> 
> I forgot to mention that I am assuming that the HW side infrastructure
> only has room for one input message per input port.  If it has room
> for n messages we can extend the argument to n+1 messages.  The
> deadlock is still possible if I'm interpreting the pseudo code
> correctly.  To my knowledge SCE-MI does not impose any requirements
> on the number of messages the HW infrastructure is supposed to buffer
> so assuming a buffer depth of 1 message is perfectly reasonable,
> right?
> 
> Per
> 


-- 

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                   \             \     \
Mgr., Acceleration Methodologies \             \________________
Mentor Graphics - MED             \_
17 E. Cedar Place                   \   john_stickley@mentor.com
Ramsey, NJ  07446                    \     Phone: (201) 818-2585
________________________________________________________________