Hi John,

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

I agree with this.

> A few comments. 

Your discussion of input-ready propagation and its intended usage is very illuminating.  Thank you.  We should keep this in mind when we go look at SCE-MI extensions, e.g., variable length message ports, so as to preserve the semantics of input-ready propagation as it applies to these new port types.  But that is beyond the horizon of IM26.

So I think we should be able to settle IM26 . . .

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

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

==========================================================

John> I'm not sure what you mean by "two messages occur at the 
John> port back to back". 

This is a case where the infrastructure is capable of `moving' 
the second message one uclock cycle after the first. In this 
case TransmitReady and ReceiveReady are both asserted for two 
clock cycles. This case is not shown in Figure 10 on p. 26 
and I was wondering what the rule for input-ready propagation 
for the second message is in this case. If input-ready is 
propagated it will inevitably propagate to the SW side *after* 
the message it refers to has actually moved. This makes me 
wonder if IsReady() should even be called in this case. 

John> Input ready does not result from sends of messages to the 
John> input port. 

I understand that. 

John> It results from indications from the input port that the 
John> H/W side is ready to receive a message. Each such indication 
John> (detected via ReceiveReady) will result in the calling of the 
John> callback. 

I am still not sure how to deal with batches of back-to-back 
messages although reading what you just said makes me believe 
you might prefer to treat a batch of back-to-back messages as 
a single message for the purpose of input-ready propagation. 
What do you think? 

Thanks for taking time to answer these questions. 
Per 

==========================================================

Bojsen, Per wrote: 
> Hi, 
> 
> I thought I understood input-ready propagation but upon 
> rereading the discussion in the standard on pages 25 and 
> 26 there are a few things I am wondering about: 
> 
> 1) It appears that the intent of the IsReady() callback 
> and input-ready propagation is for the software side 
> to send exactly one message per IsReady() callback 
> for the port of interest. But the SCE-MI infrastructure 
> is not required to enforce this. 

johnS: 
The SCE-MI infrastructure should supoprt the issuance of 
exactly one callback per input ready indication from the H/W 
side. What the infrastructure does not enforce is the application 
obeying or even utilizing the input ready mechanism. 

It is provided as a convenience but not a requirement. 

However, if the application does use the feature (i.e. by 
registering an input ready callback) there will be exactly 
one of these calls per valid clock cycle in which the 
ReceiveReady becomes valid. 

> 
> 2) Given the infrastructure is not enforcing the throttled 
> flow of messages, what is supposed to happen with 
> input-ready propagation if two messages occur at the 
> port back-to-back? Is the infrastructure supposed to 
> generate an IsReady() callback for each message or only 
> once for the batch of back-to-back messages? Or is this 
> implementation defined? 

johnS: 
I'm not sure what you mean by "two messages occur at the 
port back to back". Input ready does not result from sends 
of messages to the input port. It results from indications 
from the input port that the H/W side is ready to receive 
a message. Each such indication (detected via ReceiveReady) 
will result in the calling of the callback. 

It will then be up to the software application to send messages 
in response to these input ready's. 

> 
> 3) The waveforms on p. 26 show input-ready propagation 
> happening on the first rising edge of uclock where ReceiveReady 
> is detected high either after being deasserted, right after a 
> message moved, or right after ureset ended. Is to be taken 
> literally or does the implementation have some leeway as to 
> how quickly the input-ready condition is propagated? I 
> suppose the answer here must be yes as there is no requirement 
> defining an upper bound on when the input-ready condition 
> should be seen on the SW side. 

Yes, the infrastructure can take as much time as it needs to respond 
to a receiveReady. The time points shown in the waveform simply indicate 
the soonest time an input ready indication can be possibly be sent to the 
S/W. In reality it may take many uclocks before the notify finally reaches 
the S/W side. The transaction may chose to stop the clock while waiting for 
the message or not depending on what type of operation is desired. Streaming 
transactors may be able to give early input ready indications if there is 
still room in their input data buffers. 

> 
> Thanks, 
> Per 
> 

-- johnS