Re: Questions about input-ready propagation

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

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
________________________________________________________________
Received on Mon May 3 21:13:40 2004