IM26: Input ready propagation

Hi,

one of my action items was to suggest some clarifying wording regarding
input ready propagation that would cover the case of back-to-back
messages or, more generally, the case where more than one message may
be sent to a port in response to a input ready propagation (IsReady()
callback). At least week's meeting John S. stated that the intent of
the standard is that an input ready propagation (and subsequently, an
IsReady() call) happens every time ReceiveReady is seen asserted after
a message has transferred (plus at the beginning of the simulation just
after reset if ReceiveReady is asserted before TransmitReady).

Here is the proposed clarifying wording:

  Input-ready propagation shall happen

    1) On the first rising edge of uclock after reset at which
       ReceiveReady is asserted, and

    2) On the first rising edge of uclock after a message transferred
       at which ReceiveReady is asserted,

  when an IsReady() callback is registered.

Case 1 covers the input-ready propagation for d1 in Figure 8. Case
2 covers the others (d2, d3, and d4).

I propose that this wording is inserted in the second paragraph of
Section 5.2.2.2 (document page 26, PDF page 34) before the
first sentence.

My action item was supposed to be to propose some language that would
clarify the behavior John S. described. While reading the section on
input ready propagation I noticed that in the commentary for Figure 8
it actually has some language about back-to-back messages. However,
figure 8 does not show such a scenario. The actual sentence I'm
referring to is the one at the bottom of document page 26, PDF page
34, Section 5.2.2.2 in the second paragraph from the bottom, third
sentence starting "First, if input-ready propagation is enabled [...]".
This sentence seems to be a vestige that might refer to an old version
of the figure that did include the back-to-back message case.

As long as precisely one message is sent per IsReady() call, there will
be an alternation between ReceiveReady asserting, a message arriving,
i.e., TransmitReady asserting, and message moving, i.e., ReceiveReady
and TransmitReady deasserting.

However, if more than one message is sent in response to an IsReady()
call, things are different. Say n messages are sent. It is possible
for those n messages to be available to the BFM back-to-back, i.e.,
TransmitReady will stay asserted until all n messages have moved.
The extreme case is when the BFM is able to gobble all n messages up
immediately. Then TransmitReady and ReceiveReady will be asserted at
n consecutive uclock rising edges and n messages will move in n uclock
cycles. According to John S. as I understood him, this train of
messages would generate n input ready propagations and n calls of
IsReady(). The unique thing here is that at least some of the n
input ready propagations (if not all) will occur after the train of
messages has transferred due to latency in the communication to the
software side. That means, when the IsReady() callback is called it
is possible for it to refer to an input ready condition that existed
in the past rather than one that exists in the present.

It might be argued that the above use model is outside the scope of
the intent of the input ready propagation mechanism, but before
dismissing it entirely consider the case where a transaction must
be transferred to the BFM as a sequence of more than 1 SCE-MI message
(and the number of messages may be variable). If this is done and
input ready propagation is desired, then one must know how IsReady()
behaves in the scenario above.

The behavior John S. stated which is captured by the wording proposed
above allows the back-to-back scenario with the possibility of delayed
IsReady() calls.

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