Re: ServiceLoop() Revisited

Hi Russ,

>  void ServiceLoop( int mode = POLL);  // default
>
>  * ServiceLoop( POLL ) // polling behavior
>  * ServiceLoop( BLOCK ) // block until ONE output message received, then
>return
>  * ServiceLoop( BLOCK_FLUSH ) // block until at least ONE output message
>received
>                               // return only after all pending messages
>serviced
>  * ServiceLoop( SEND_ONLY) // send pending input messages then return
>
>  enum { POLL, BLOCK, BLOCK_FLUSH, SEND_ONLY };

The problem with doing this is that we have to decide on a list of
pre-defined behaviors that is reasonable. g() provides maximum flexibility
to the user.  The behaviors presented as examples in the spec are just
that: examples.  Note, you do not have to use g() at all which is the
simplest use model.  Have you found you need to use g() in your SCE-MI
applications?  Did you need to do any of the above use models?

>  Even if SCEMI 2.0 does away with the ServiceLoop() concept, the above
>could be adapted as part of the backward compatibility of the standard ( it
>would be easy for existing apps to adapt this or keep the g() function
>style).

In the C++ API that is fairly simple because we can use overloading.  In
C we would have to add a new function with a different name.

>2) The usage mode where there are no output message callbacks serviced is
>interesting, and surprising. I added the SEND_ONLY option above --- is this
>really a use mode that arises more than once out there?

Actually, that use model is impossible today because g() is always called
after the output message is received.  Where did you see this usage
described?

>3) The SCEMI 1.1 spec has an ambibuity as to the sending of Input Messages.
>When ServiceLoop() is called, I believe the spec says that the first loop
>within ServiceLoop() "sends" Input Messages to the HDL side. No confusion
>there. However, on the HDL side, it makes a difference in transactor design
>if these messages are assumed to be in series (accomplished on different
>uclocks) or whether they all happen (or some of them happen) in parallel on
>the HDL side.

I think we solved the ambiguity at the meeting: basically, the transactor
designer cannot make any such assumption either way.  The virtual channels
between software side proxies and hardware side macros are to be considered
fully parallel.  The message ordering rules apply only to controlled clocks,
not uclocks.

I'm wondering who will volunteer to write the note to add to the spec? :-)

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