Hi John, Please review my responses to your email. Shabtay -----Original Message----- From: owner-itc@verilog.org [mailto:owner-itc@verilog.org] On Behalf Of John Stickley Sent: Tuesday, June 06, 2006 8:31 AM To: itc@verilog.org Subject: 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 symmetric 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. [Shabtay] We don't see reason for providing two interfaces. Users will be better served with one interface. 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. [Shabtay] Robustness is a key ease of use issue and I do see key benefit in our enhancements to your proposal. 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. [Shabtay] TLM to my knowledge is only defined for SystemC at this time. What is missing in our proposal for creating more TLM compliant interface in your opinion? Can you suggest the specific enhancements to make it more TLM compliant? 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 pipe ID is always 1. [Shabtay] Our proposal was based on early version of you draft and we don't have objections to using handles. 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. [Shabtay] Our reservation to c_try_flush() was that flush should always be implicitly successful. Which conditions should cause the to c_try_flush() function to return with failed or success status? 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. [Shabtay] Humm. Have we actually decided that? I don't recall. Can you please point me to the minutes capturing that? In any case, the benefits for supporting non-blocking interface on the HDL side are: 1. Allowing the BFM to insert itself to idle state if try_receive failed. 2. SCEMI 2.0 becomes symmetrical (a feature you emphasized is important) 3. SCEMI 2.0 becomes more TLM compliant as TLM promotes offering both blocking and non-blocking calls (again you promote being more TLM compliant). So why object? 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. [Shabtay] OK. Let us take the time and look at your latest information. 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. [Shabtay] OK. Let us take the time and look at that. 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). [Shabtay] What I believe is proposed is dynamic configuration of the depth which will not apply to the buffer depth actually allocated in hardware at compile time. Is this correct? I am concerned of the added complexity of this feature allowing users to dynamically configure the pipe depth at run time. I think we should discuss the scope of this. 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. [Shabtay] Great. But we need to settle try_flush semantics. -- 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 ________________________________________________________________Received on Wed Jun 7 15:58:02 2006
This archive was generated by hypermail 2.1.8 : Wed Jun 07 2006 - 15:58:06 PDT