Re: SCE-MI 1.0/1.1: Input ready propagation and reset

From: John Stickley <John_Stickley_at_.....>
Date: Fri Jul 15 2005 - 14:46:30 PDT
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