Re: New IM: Pipe ID restrictions

Jason,

Just some quick responses to a couple of your comments.

The rest we can perhaps discuss today.

Jason Rothfuss wrote:
> 
>>The example you raised yesterday of having loops be able to index 
>>which pipes they are accessing in each iteraction is one example of 
>>where dynamic indexing could be quite powerful.
> 
> 
> I agree that it is powerful from a general programming perspective,
> allowing the user to dynamically allocate messaging channels at
> run-time.  However, I don't know that this is practical for a hardware
> accelerator.  It may even restrict the efficiency of an implementation.

johnS:
Please understand I'm distinguishing "dynamic allocation" from
"dynamic indexing".

The former is, I agree substantially more complex to implement
in H/W and, IMHO not worth it.

The later however, still gives the programmatic flexibility but
allows a simple scheme whereby a static ceiling of indices can
be utilized. This prevents the need for dynamic allocation.

So you have the advantage of programming flexibility (dynamic
indexing) without the complexity of a fancy dynamic channel
allocation scheme.

I think we can just specify a simple "MAX_CHANNELS"
in dpi_pipes.vh that makes this easy. It can be customized by the user
on a per module basis by externally overriding it exactly as is done
with the send/receive call payload width now.

Actually, I just looked at the header and realized it already
supports this !

`ifdef SCEMI_PIPE_MAX_CHANNELS
`else
`define SCEMI_PIPE_MAX_CHANNELS 32
`endif

So, here the user can override this externally by pre-defining
SCEMI_PIPE_MAX_CHANNELS prior to inclusion.

Vendors can supply their own scemi_pipes.vh with a different
value than 32 if that is more appropriate.

This way you get the best of all worlds:

1. Complete programming flexibility with dynamic indexing
2. Vendor control of optimum default values
3. User control of values required for specific applications

One more thought that can make this even more statically
controllable at compile time:

How about we specify MAX_CHANNELS as a bit width
(i.e. ID space a power of 2) then stipulate that on the
H/W side the ID width must be limited by that value, i.e.

`ifdef SCEMI_PIPE_MAX_CHANNELS_WIDTH
`else
`define SCEMI_PIPE_MAX_CHANNELS_WIDTH 5
`endif

import "DPI-C" context function int scemi_pipe_hdl_try_receive(
     input bit [`SCEMI_PIPE_MAX_CHANNELS_WIDTH-1:0]
                pipe_id,             //  input: intra-module pipe identifier
     input  int byte_offset,         //  input: byte_offset within data array
     input  int bytes_per_element,   //  input: #bytes/element
     input  int num_elements,        //  input: #elements to be read
     output int num_elements_valid,  // output: #elements that are valid
     output bit [`SCEMI_PIPE_MAX_BITS-1:0] data, // output: data
     output bit eom );               // output: end-of-message marker flag

import "DPI-C" context function int scemi_pipe_hdl_try_send(
     input bit [`SCEMI_PIPE_MAX_CHANNELS_WIDTH-1:0]
                pipe_id,             //  input: intra-module pipe identifier
     input int byte_offset,       // input: byte_offset within data array
     input int bytes_per_element, // input: #bytes/element
     input int num_elements,      // input: #elements to be written
     input bit [`SCEMI_PIPE_MAX_BITS-1:0] data, // input: data
     input bit eom );             // input: end-of-message marker flag

This way we address your concern of static compile time limiting
but address my concern of retaining programming flexibility ?

> 
>>So what I would suggest to alleviate that is to stipulate that an 
>>implementation can put a vendor specified cap on a maximum mount of 
>>channels that are usable by an application either at the module level 
>>or a global level.
> 
> 
> I don't like the idea of a vendor cap, because this cap then becomes
> non-standard.  From the user's perspective, the standard should try to
> ensure that running a design on compliant Vendor A's version matches
> compliant Vendor B's version.

johnS:
Good point about the vendor cap. How about we just make it a
and vendor suggested/user overridable cap as suggested above ?

> 
> 
>>Alternatively this could be a value that is user specified and 
>>alterable in dpi_pipes.vh. User's could alter this value to a value 
>>that is a nice compromise between what their applications require and 
>>some practical limit stipulated by the vendor.
> 
> 
> I also don't like the idea that a user should modify a header file to
> get their design to run.  What happens when a user upgrades to a new
> version of the vendor's software?  They will have to be sure to make the
> same modification to the header file when they install the software
> package.  To me, this seems to create complexity and a dependency on an
> IT group that has access to the software installation path.

johnS:
The good news is that this can be done without modifying the
header.

The vendor can provide a "suggested cap" in the header.
The user can override on a per module basis where needed
an external `define where necessary (but probably not needed
90% of the time).

-- 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
________________________________________________________________