RE: IM26: Input ready propagation

        I have no seen no responses or discussion about Pers suggested fix
for IM26, so I will incorporate his suggestion. We will do the final review
of it at the next meeting.
        
        Brian
        
        -----Original Message-----
From: owner-itc@eda.org [mailto:owner-itc@eda.org] On Behalf Of Bojsen, Per
Sent: Thursday, November 04, 2004 1:05 PM
To: 'itc@eda.org'
Subject: 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
Received on Sat Nov 6 10:57:14 2004