Per:
let's take a brief break from the SCE-MI 2.0 discussions and consider the following.  On Fig 8, p. 24 in SCE-MI 1.1.0, it is shown how input-ready propagation happens right after ureset deasserts when ReceiveReady is asserted.  On p. 54 in the paragraph on the top of the page and the NOTE below Fig. 17 it is implied that messages can be transferred during reset.  Although it talks about output messages I do not think we have disallowed input messages to be transferred.

So here is the apparent contradiction: on one hand we allowed messages to be transferred during reset, on the other hand input-ready propagation does not seem to be allowed during reset.

There is a follow on question to all of this because for message transfer to happen, ports must be bound.  So as far as I remember the exact event that starts the reset process is not specified in the spec.  Please correct me if I am wrong here.  I have assumed that it is triggered by SceMi::Init().  If SceMi::Init() triggers the reset, then the application must be awfully quick to bind its ports if it intends to transfer messages during reset, or the user must specify an extremely long reset sequence.  Alternatively, one could start the reset process on the very first call of ServiceLoop().  This would allow (essentially infinite) time to bind all ports and then transfer messages during reset.

Is this whole idea of transferring messages during reset just a bad idea?

If Duaine and/or John S. could spare a few moments to answer the above questions, I'd appreciate it.  I am once again (perhaps
naively) hoping we can clarify the intent without opening up another can of worms :-)

JohnS:
Yes the idea of transferring messages during reset is a bad idea.

I don't see where the paragraph at the top of page 54 implies it is OK to send messages during reset.

> Per:
> It implies it at least for output messages by talking about what the value of cycle stamp is during reset.  If it is not allowed to send output messages during
> reset it does not make sense to specify what value cycle stamp should have during reset since it would have no user-visible impact.  I remember when we
> were talking about this at one meeting.  I remember Duaine being reluctant to restrict message transfer during reset.


And the NOTE: below the figure clearly discourages it though you're right it does imply it is allowed. I would be in favor of disallowing it altogether. I'm not sure why the
NOTE: was being wishy washy about it.

>Per:
> We added the note because we wanted to keep the door open for this kind of usage.  I'd like to revisit this and see if we can agree to disallow transfer
> of messages during reset.  Duaine, do you still have reservations about disallowing message transfer during reset?


Assuming messages during reset are not allowed, I agree the concerns you raise below are alleviated.

The first input message will not occur until it is sent on some bound in port - which should not happen until after SceMi::Init().

And the first output message (or input ready callback) will not be processed until the first call to ::ServiceLoop()
- which should not happen until all potential output ports (and input ports for IR callbacks) are bound.

I think the spec somewhere says that if an output message is sent on an unbound port, it is simpy ignored. But the user can easily avoid a race by simply making sure all the output ports that he cares about are bound some time between SceMi::Init() and the first call to ::SerivceLoop().

> Per: I agree.