RE: New IM: Pipe ID restrictions

Hi John,

Let me first start by summarizing the issues that I still see with the
pipes specification, then I will directly comment on some of your
replies:

I see two main issues with pipes, the first being the Pipe ID and being
able to sufficiently restrict the Pipe ID at compile-time.  I feel very
strongly that if Pipe ID needs to be restricted, or capped, that it must
be handled with a compile-time error.  Handling this at run-time is not
sufficient.  Imagine that the end user makes a mistake and uses a
variable that exceeds the bounds of the legal Pipe ID in HDL.  He
compiles his simulation, with no errors.  He compiles for an
accelerator, with no errors.  He runs his acceleration and discovers
that the Pipe ID goes out of bounds.  Now he needs to fix his source and
recompile.  If I am the user I am going to become very frustrated.  I
don't see why we shouldn't be able to prevent this with a robust
specification that falls within the bounds of the languages that we use.

The second issue that I see is on the implementation side.  The
scemi_pipe send/receive function calls conceptually will do dynamic
buffer allocation.  I say that this is dynamic because you don't know
the value of Pipe ID until the function is called at run-time.  When
vendors will go to implement this in hardware, I see this as a big
limitation as to how you can implement such a scheme.  It seems to me
that it is unnecessarily complex and prohibits the infrastructure from
optimizing resource allocation at compile-time.

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

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

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

> Attempts to used ID's that are out of this range would simply result 
> in a clearly specified run-time error.

I don't think that a run-time error is sufficient.  I'll refer to the
scenario described in the summary above.  My personal opinion is that
the standard will look sloppy if it allows some designs to work with
some compliant implementations but not others with a vendor-specific
cap.

> While the object oriented pipes proposal of IM 218 does provide some 
> advantages, it does not facilitate variable indexing of pipes 
> described above and for this reason I would consider it somewhat of a 
> limitation.

I see this as a big advantage rather than a limitation.  The
module-based pipes approach offers static (compile-time) error checking
as well as implementation ease, in my opinion.  It effectively
represents what will be implemented in hardware by physically
instantiating a pipe module, and offers the same ease of use with the
task-based interface.  However, if you can find a way to address these
issues in the context of your proposal, please do so.

Regards,
Jason