Re: IM26: Input ready propagation

Per,

A few comments.

Bojsen, Per wrote:
> 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.

johnS:
This looks good. I think it strengthens up what the diagram tells
you and what the bullets after the diagram tell you.

Also, a minor editing fix to Brian:
The text in the 5th paragraph in "NOTE" is smaller to indicate
note text. But the paragraph following it is also part of
the discussion in the NOTE. So, it should also be the small font
to indicate a continuation of the note.

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

johnS:
I think you're right about the vestige of an old diagram.
Perhaps we should remove this text as it probably only adds
confusion.

I would suggest we remove this sentence starting with "First ..."
and removing the entire remainder of the paragraph.

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

johnS:
Good discussion Per and you bring up some interesting points.
A few comments.

As to multiple messages per input ready, this is indeed beyond
the scope of what it was intended for. Although the spec does not
enforce how input ready itself is used, if more sophisticated
semantics of multiple inputs per IR are desired, a user can
easily, and might be better advised to, implement such a scheme
using output ports instead of input readys. In this case, the
user would not make use of the input ready mechanism at all by not
registering an IR callback, but use a dedicated output port
for this purpose instead.

For example a transactor can send an output message saying
"I've got space for 10 inputs".

A fairly sophisticated streaming transactor can be built using
such a scheme.

However, the input ready mechanism was intended for something
far simpler. It is a way of signaling prefetch of the data while
the clock is running and the DUT is crunching on the previous
data. This can be done without all the work of creating an extra
output port just for this commonly used scenario.

It turns out you can still accomplish the equivalent of the 10
input scheme described above using input ready in a special
way.

Suppose you make the message size 10 transactions wide, the
input ready to get the next 10 transactions all at once, then dole
out the 10 transactions to the DUT within the local space of the
transactor itself. So this would still avoid the need for an output
port.

Input ready itself is, in effect a flow control mechanism that
faclitates data pre-fetch without necessarily stopping a clock,
yet retaining determinism.

In another scenario where it can be used, suppose each transaction
generates 15 DUT clocks of activity before the next transaction
comes in. Keeping receiveReady high following movement of the
previous transaction, the C side can automatically be notified
(via IR callback) that the transactor is ready for more, and can
then go to work sending the next transaction possibly within those
15 clocks before it is needed - which would be very efficient.

This can all be accomplished with the expenditure of only one
input port in the transactor model and C model.

If the next transaction arrives early within the 15 clocks, great,
the transactor will hold it, deassert receive ready, and
not use it util the DUT is ready (at the end of the 15 clocks).

If, on the other hand, the next transaction does not arrive
within the 15 clocks, the transactor will stop
the DUT clock until it does arrive (BTW, here's a case where
"just in time" clock control semantics might be more efficient,
i.e. if this DUT clock we're speaking of is a slow clock it
will give C more time to facilitate the transaction request
without unecessarily stopping faster cclocks that are
unrelated to this transactor's interface).

So what input ready generally does is facilitates efficient
data pre-fetch while still retaining deterministic DUT clocking
behavior.

Pre-fetch can also be coveniently deployed with a double
buffering scheme if desired.

-- johnS

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