Re: IM33: Modifying and/or sending messages received

Russ and Per,

I carefully reviewed this thread and thought about it a bit.

One thing I think we still want to do is keep SceMiMessageData
construction and re-use to be something managed by the user.

A typical example might be a queue and free-pool of reusable
data packets all sized for use with a specific port.

There may be times in the simulation when a number of such
packets exist in the queue and so having one message data
tied to the port would be restrictive and would require
data copying from queued packets on each send. So I think
we want to keep this capability is it is.

However, as to re-sending output messages to input, I can
see pros and cons to making a restriction here.

On the one hand, I think this would be useful to receive
an output message and within the same receive callback function
tweek a couple of fields and turn it right around and send
back to H/W on an input port. This would avoid data coping
to a second message data object that is to be used on input.

Also would not even require allocation of a second message data
on the fly or stored in some global area or in the context
pointer area.

So long as the input port and output port widths are the
same, the packet would be reusable.

On the other hand, I can understand Per's concern that
message data's used for input might have different "internals"
than message data's used for output.

As for cyclestamps here is my suggestion:

1. We keep CycleStamp() in messages themselves. Having messages
    that carry along timestamps of when they were sent is
    quite useful.

2. If a SceMiMessageData is constructed and the CycleStamp
    is queried it would return 0.

3. Aside from CycleStamps in messages, it would be useful
    to have a global CycleStamp accessor - possibly a method
    of class SceMi that returns the CycleStamp of the last
    message received. This would allow applications to query
    the current time of the H/W side at any time without having
    to track the cyclestamps returned with each message.

    We're seeing in several applications where this would
    be useful.

-- johnS

Russell Vreeland wrote:

> Per,
>
> It's a valid point that the SceMiMessageData class could represent an
> interface to the actual transfer data rather than an object for storage. The
> implementations I've used (all one of them) don't do it that way and the
> language that's in the spec regarding the objects having the same width as
> the ports they're sent to hints that the objects are separate and
> self-contained rather than interfaces.
>
> Nevertheless, after these last couple emails, it's hard to argue that a
> clarification is not in order! Maybe you could work the word "persistent"
> into your proposed language?
>
> Not that this is doable at this late date but I guess it would make more
> sense to me if the SceMiMessageData class were folded into the two Proxy
> classes -- that would eliminate the CycleStamp issue and generally simplify
> things. Each proxy would encapsulate its own MessageData and the user
> wouldn't have to fool with a separate construction of a MessageData object,
> and be sure it's the same width as the proxy. If SCEMI ever implements
> variable message lengths, this would be more suitable for that, I believe,
> since you wouldn't have problems with port and message data width
> discrepancies occuring dynamically. To address multiple data copy issues, it
> would be cool to be able to set up an input port proxy to hold
> references/pointers to data space elsewhere, or to have it call a user
> function that could be used to do some assembly of message data every time
> Send() is called.
> Just musing out loud.
>
> -Russ
>
> ---------------------------------------
> --- Russ Vreeland (949)926-6143 ---
> --- vreeland@broadcom.com ---
> --- Senior Principal Engineer ---
> --- Broadcom Corporation ---
> ---------------------------------------
>
>
>
> -----Original Message-----
> From: owner-itc@eda.org [mailto:owner-itc@eda.org] On Behalf Of Bojsen, Per
> Sent: Friday, November 05, 2004 8:24 AM
> To: 'vreeland@broadcom.com'; itc@eda.org
> Subject: RE: IM33: Modifying and/or sending messages received
>
>
> Hi Russ,
>
> > I believe the spec adequately describes the limited scope and lifetime
> > of SceMiMessageData objects received through an OutputPortProxy.
>
> Agreed, but the issue was not this, but whether the spec allows or should
> allow these objects to be sent to input ports. Although this is a minor
> issue and probably uncommon usage, what the spec says does affect the
> implementation. For instance, if the spec explicitly forbids this usage,
> then the implementation could take advantage of this in how it internally
> handles and implements SceMiMessageData objects. Note, the SceMiMessageData
> class is only the interface the application sees and more state may be kept
> under the hood that differs depending on the direction of message transport.
>
> > I would suggest, without any real fervor, that whether a user
> > chooses to construct once and store SceMiMessageData objects for
> > use with an InputPortProxy or "use once and discard" is an
> > implementation detail best left to the users and requires no
> > further clarification.
>
> The point of adding the clarification was to ensure that all SCE-MI
> implementations support both of these use models. This is important for
> portability. If we do not specify whether reusing SceMiMessageData objects
> are allowed or not, then there is a risk that eventually some
> implementations will allow it while others will not.
>
> > Since we're dealing with a C++ class here, and we're passing it to
> > Send() via a const reference, the proposed clarification amounts to a
> > C++ truism.
>
> It is not that simple because the SceMiMessageData class is just the
> interface. There is no requirement in the spec that the SceMiMessageData
> class contain all the information related to a message. It is quite
> possible to envision a case where forbidding reuse of SceMiMessageData
> objects could lead to a more optimized implementation. In fact, allowing
> reuse makes it harder for the implementation to avoid a data copy.
>
> > The requirement that SceMiMessageData objects have the same
> > width as the ports they're sent to is addressed in the description
> > of the constructor in 5.4.5.1
>
> True. Removing this, the proposal is now:
>
> Send()
>
> In Section 5.4.6.1, document p. 53, PDF p. 61, after the
> sentence under
> `data' add:
>
> This object may be arbitrarily modified after Send() and used for
> an arbitrary number of sends to the same and other message ports.
>
> Receive()
>
> In Section 5.4.7.1, document p. 55, PDF p. 63, after the last
> paragraph in the section add:
>
> The class SceMiMessageData object passed to the receive callback
> may be sent any number of times to any number of input ports.
> Modifying the class SceMiMessageData object by casting away const
> leads to undefined behavior.
>
>
> > Changing subjects, after reading the spec some more, I found
> > what might be a
> > separate issue. The CycleStamp() accessor for
> > SceMiMessageData objects is
> > presented in the spec (p52, PDF 60) without any description
> > of what would
> > happen if a renegade user were to call it on a
> > SceMiMessageData object not
> > originating from an OutputPortProxy. Should the accessor call
> > the port's
> > error handler in this case, return 0, or is "undefined
> > behavior" adequate?
>
> I don't think undefined behavior is good. I think it makes sense to make
> this an error, but unfortunately, CycleStamp() does not have a SceMiEC
> argument so we cannot make it an error without changing CycleStamp()'s
> declaration. If doing this is not an option, the only reasonable choices
> left are to return 0, or, perhaps better, return the most recent value of
> cycle stamp received through an output proxy.
>
> Regards,
> 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                   \             \     \
Principal Engineer               \             \________________
Mentor Graphics - MED             \_
17 E. Cedar Place                   \   john_stickley@mentor.com
Ramsey, NJ  07446                    \     Phone: (201) 818-2585
________________________________________________________________