Jason, Quick correction. I was just reminded that this week's meeting was canceled. Hopefully we can continue this discussion by e-mail. -- johnS John Stickley wrote: > 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 > ________________________________________________________________ > -- 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 Thu May 25 08:00:29 2006
This archive was generated by hypermail 2.1.8 : Thu May 25 2006 - 08:00:31 PDT