Action items from last meeting; Feedback for MainBody_v3_070125.doc

ITC Techies,

I've done my AIs for the last meeting and have a new revision
of the above ref'ed document with my feedback. Change highlights
show only my feedback since Brian posted the document last
week with changes reset.

The document is attached in a separate mailing.

Summary of changes:

AI: Fix comment for 'byte_offset' argument in try_send/receive calls.
   - Done - see attached document.

AI: Change argument comment on try_send/try_receive calls
     to be more accurate.
   - Done - see attached document.

AI: Clarify num_valid argument on try_receive() calls - why
     needed.
   - Done - see attached document.

AI: Review e-mail Shabtay wrote regarding Mantis items and
     see if document reflects the conclusions.

   - It does. I had looked in the wrong sections before but
     I see Shabtay had incorporated it in 4.9.1 and 4.9.2.
     I still have some reservations about having two different
     sets of synchronization semantics depending on whether
     kernel is tightly linked or loosely linked. I think that
     is going to cause issues going forward and simulation
     behavior inconsistencies. I would push to try to restrict
     the synchronization semantics in such a way that they
     will be consistent with either model. I think this might
     mean choosing the more restricted semantics of 4.9.1.
     We can discuss further.

AI: Write up a small proposal for default #elements and
     how buffer size can a vendor default over ridable by
     a statically specified user defined value.

     Here's the text of that proposal:

-------------------- cut here ---------------------------
Buffer depth for pipes is statically specified in the
HDL-side pipe interfaces. By default the vendor can
set the depth a value that is optimal for their implementation:

interface scemi_input_pipe();
     parameter BYTES_PER_ELEMENT = 1;
     parameter PAYLOAD_MAX_ELEMENTS = <vendor specified>;

However, users can override this value by specifying it in
the pipe instantiations.

For a typical streaming use model, a user may instantiate
a pipe with the BYTES_PER_ELEMENT specified but the
PAYLOAD_MAX_ELEMENTS left alone, for example,

     scemi_input_pipe #(.BYTES_PER_ELEMENT(32)) p0( ... );

This will allow streaming of transactions in an optimal manner
for the vendor. This use model may typically choose to
use a flush mechanism with the pipe as well to define
proper synchronization points between producer and
consumer.

For a typical fifo oriented use model (such as TLM fifos), a user
will explicitly want specify the pipe to be a specific depth which will
facilitate consistent behavior in terms of how long threads
continue to write to or read from pipes before yielding.

Such a use model may typically choose not to use a flush
mechanism.

-- johnS

______________________________/\/            \     \
John Stickley                   \             \     \
Mgr., Acceleration Methodologies \             \________________
Mentor Graphics - MED             \_
________________________________________________________________


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.