RE: ServiceLoop() Revisited

It seems that this ServiceLoop() issue might reveal something that could be
corrected by the upcoming revision/evolution of SCEMI. Just a few comments:

1) The use of the g() function is too low level a user interface. It's not a
given that anything like the "ServiceLoop()" will even be part of a next
generation SCEMI.
But if it were, why not just use a set of constant parameters as arguments
to ServiceLoop(), define the expected behavior produced by each of the
paremeters, and let the implementation be "under the hood".

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

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

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? 

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've seen both series and parallel implementations from vendors who support
SCEMI, and this can break transactors when porting over.

---------------------------------------
---    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 Per Bojsen
> Sent: Thursday, April 14, 2005 10:25 AM
> To: itc@eda.org
> Subject: ServiceLoop() Revisited
> 
> 
> Hi,
> 
> I apologize for bringing this up again especially now that 
> 1.1 has been approved, but I'm just looking for a quick 
> answer to the following question regarding ServiceLoop() and 
> the g() function.  I don't remember if we covered this 
> particular facet in our previous
> ServiceLoop() discussions and I missed it when reviewing the 
> pseudo code for ServiceLoop() that John contributed.  Anyway, 
> the pseudo code shows ServiceLoop() as having two internal disjoint
> loops: one over pending input messages and one over what we 
> called service requests (pending output messages and 
> input-ready notifications). The g() function is only invoked 
> in the second loop.
> 
> Now, assume an implementation which only transfers input 
> messages in ServiceLoop(), i.e., Send() just queues messages 
> on the software side. I believe the spec allows this, 
> correct?  This means, that as long as g() returns 1, 
> ServiceLoop() stays in the second loop and no input messages 
> will get transferred.  g() must return 0 at some point to 
> cause ServiceLoop() to kick out and the application must ensure
> ServiceLoop() gets called again to get any new input messages 
> to transfer.  Is this correct, or am I missing something?
> 
> I have seen several examples of users assuming g() could be 
> used in a mode where it returns 1 until the test is done at 
> which time g() returns 0.  So the assumption is that the 
> whole test will invoke
> ServiceLoop() exactly once and g() will cause ServiceLoop() 
> to stay looping internally until the test is done.  This 
> usage model seems to conflict with the pseudo code in the 
> spec (unless, of course, the test only sends a few messages 
> at the beginning before ServiceLoop() is invoked).
> 
> Long story short: Is the above use model invalid or is the 
> pseudo code wrong or did I miss something?
> 
> 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
>