Per, 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. 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. 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(). -- johnS Per Bojsen wrote: > Hi, > > 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 :-) > > 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 \ \ \ Mgr., Acceleration Methodologies \ \________________ Mentor Graphics - MED \_ 17 E. Cedar Place \ john_stickley@mentor.com Ramsey, NJ 07446 \ Phone: (201) 818-2585 ________________________________________________________________Received on Fri Jul 15 14:48:09 2005
This archive was generated by hypermail 2.1.8 : Fri Jul 15 2005 - 14:48:11 PDT