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?

Actually, the only use model I personally am concerned with would be the one
shown as "ServiceLoop(BLOCK)";

I.e., my g() function is:
// "g" function for Service Loop, used to cause blocking until a message is
received
int sLoophandler( void * context, bool pending ) {
  return pending ? 0 : 1;
}

which I believe is the one defined in the spec for this purpose.

It would have been great if this were the default mode, rather than polling,
as it would lead to more serendipitous deterministic operation outcomes by
users.


> 
> >  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.

Yeah. That's true.

> 
> >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?

I thought it was in your original email: "Now, assume an implementation
which only transfers input messages in ServiceLoop()". Did you mean "only
transfers input messages in SL() <as opposed to immediately when Send() is
called>  -OR- "ONLY transfers input messages in SL(), nothing else -- such
as waiting for output messages"?

> 
> >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 not sure we solved the ambiguity. We could write the spec that way, but
I'm not sure we were in consensus on this? There is an advantage in
simplicity if input messages are non-buffered and occur in series (on the
HDL side).

E.g., a transactor has 2 input ports. One receives a 'byte count' to some
FSM, and the other "enables" the FSM to start. If the byte count load isn't
completely direct (takes >1 uclock to get loaded into the FSM for whatever
reason) then the enable could cause a counter to start  decrementing with
the wrong initial value. But if the designer could rely on series reception
of input messages, then it becomes simple: a) load byte count   b)enable (in
software)  <-> same operation in hw.

Yes, you could mandate that loading a count and starting should be the same
transaction, but my point is that one could more easily design it
incorrectly with those sort of constraints. And yes, the degree of
protection offered from "series reception" is limited -- if one designed
something that needed 100 uclocks between input messages to work properly,
then GIGO.

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

In our spare time :) ???

> 
> 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






---------------------------------------
---    Russ Vreeland (949)926-6143  ---
---    vreeland@broadcom.com        ---
---    Senior Principal Engineer    ---
---    Broadcom Corporation         ---
---------------------------------------

>