Action items from 2-15-07 meeting; Revised feedback for MainBody_v3_070125-johnS-2.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: Simplify non-blocking "try_receive()" functions by removing
     "num_elements_valid" arguments.

     We agreed in this meeting that the return value is adequate
     for indicating number of elements received - even accounting
     for flush/eom operations.

   - Done - see attached document.

AI: Fix "100 bytes" analogy that explains data shaping and
     variable length messaging to use "elements" instead.

   - Done - see attached document.

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

AI: Correct the small proposal for vendor specifiable default
     buffer depth. Previous proposal erroneously gate PAYLOAD_MAX_ELEMENTS
     as this depth rather than adding a required 3rd parameter.
     That proposal has now been fixed.

     Here's the text of the corrected proposal:

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

interface scemi_input_pipe();
     parameter BYTES_PER_ELEMENT = 1;
     parameter PAYLOAD_MAX_ELEMENTS = 1;
     parameter BUFFER_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
BUFFER_MAX_ELEMENTS left alone, for example,

     scemi_input_pipe #(
         .BYTES_PER_ELEMENT(32),
         .PAYLOAD_MAX_ELEMENTS(16)) p0( ... );

This will allow streaming of transactions in an optimal manner
for the vendor. This use model may typically choose to
use a flush/eom 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.