detailed feedback on object pipes proposal

Shabtay and Jason.

I have some general comments on your object pipes proposal
which I will follow with some detailed feedback on the
different sections of it.

In general, I'm still OK with some sort of object based pipes
interface being layered over the existing symetric function
based interface but I think there are a number of important
reasons to keep the existing interface as a foundation -
most of which we had discussed last week.

I also don't think a good case has been made that the existing
interface has a significantly more difficult use model. In fact,
in some ways, I would argue the contrary. Both have their ease of
use advantages and disadvantages but the differences are
so slight that ease-of-use alone is not a reason to me
to change the entire interface.

Thirdly, I would strongly encourage you to re-structure this
object pipes interface to be an object oriented TLM compliant
interface. I think we would get more "bang for the buck" with
it that would make our standard more TLM friendly and therefore
increase its chances of wider adoption.

Here are some more specific inputs.

Re: 1.4.1.2
   - I see you've removed pipe handles. I suggest we keep them
     as we have it now.

     There are a number of advantages of having an explicit handle
     and not depending on a call to svSetScope() prior to the call.

     If it makes things easier, we may have another variant of
     scemi_pipe_c_handle() called something like scemi_pipe_object_c_handle()
     can be a wrapper around scemi_pipe_c_handle() where the pipd ID is
     always 1.

Re: 1.5
   - You asked why c_try_flush() is needed. This is to provide
     a thread neutral call for the benefit of the blocking c_flush()
     to be implemented over a specific threading system
     just as c_try_send() is the thread neutral assist call for
     the benefit of the blocking c_send() call.

Re: 1.5.1
   - I thought we had decided to defer an HDL-side non-blocking
     interface until we better understood implications. I suggest
     we should stick to this decision and concentrate on getting
     the existing capability of the blocking HDL interface solified
     before introducing non-blocking i/f's on the HDL side.

     I believe our agreement before was the non-blocking i/f's
     are more important on the C side to allow creation of a
     thread-neutral interface that can be easily used to adapt
     the C blocking interface to different thread packages.

Re: 1.5.1.4
   - Let's not remove byte_offset or strike out the paragraph
     explaining why it is used. It turns out to be a rather nice
     way of supporting unlimited transactions on the C side.

     I think Per was also happy with this solution as well.

     Please review the exmple most recent spec revision and
     blocking dpi_pipe_c_send() call that illustrates how
     this feature is used.

     Also, the reference model just sent out actually has working
     support for unlimited buffer sizes.

Re: 1.5.1.6
   - scemi_pipe_get_notify_context() is used to see if a notify
     callback has heretofore been established for a pipe. If not,
     establish one for the first time. See dpi_pipe_c_send() call
     implementation for an example. You may want to also
     read the paragraph immediately after your question.
     Let's not strike this out.

Re: 1.5.2.4
   - See comments for 1.5.1.4 - let's keep byte_offset.

Re: 1.6.1
     scemi_pipe_c_set_depth() now takes a bytes_per_element arg.
     (see new revision 1.12 document I've just updated).

Re: 1.6.2
     - Again, I think we need to keep the pipe handle argument.

Re: 1.7
    - Some good comments on flush semantics - those have been added to the
      latest document spec. revision 1.12.

-- johnS

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
________________________________________________________________