Jason, I've been thinking about this issue since our meeting yesterday and it occurs to me that variably specifiable (non-static) pipe ID's may actually be part of the power of the current function call based interface rather than a limitation as you suggest below. 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 see two scenarios for implementation of pipes on the HDL side. 1. Directly as DPI imported functions 2. Over vendor optimized implementations that don't necessarily call direct DPI imports For #1 handling arbitrary variably specified pipe ID's may not be that big of a deal as processing and management of those ID's is handled primarily on the C side For #2, I can see where you might want to be able to put practical caps on valid pipe ID values. Certainly your point below about an ID space spanning millions of values is a good one. It is likely not practical to handle such wide open ID space bounds in any practical emulator 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. 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. Attempts to used ID's that are out of this range would simply result in a clearly specified run-time error. I think this would be a reasonable way to put a put a practical limit on needed emulation resources yet retain the flexibilty of variably specified pipe ID's that the current specification allows for. 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 suggest that we retain the current interface for the added flexibility it affords for variable indexing but possibly consider the object based pipes as a facility that can be built on top of the function based pipes layer if the committee feels there is enough added advantage in the object based model. My personal feeling is that we should reserve an object based model for when SystemVerilog TLM becomes more mature. -- johnS Jason Rothfuss wrote: > As discussed in today's meeting, we would like to open up an IM for > discussion on how to restrict Pipe ID sufficiently to ease > implementation for emulation vendors. See problem description below: > > > > On the HDL side, the following blocking tasks are declared for > sending/receiving data using a SCEMI pipe: > > > > import "DPI-C" context task scemi_pipe_hdl_send( > > input int pipe_id, // input: intra-module > pipe identifier > > 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 byte eom); // input: > end-of-message marker flag > > > > import "DPI-C" context task scemi_pipe_hdl_receive( > > input int pipe_id, // input: intra-module > pipe identifier > > input int bytes_per_element, // input: #bytes/element > > input int num_elements, // input: #elements to > be read > > output int num_elements_read, // output: #elements > actually read > > output bit [`SCEMI_PIPE_MAX_BITS-1:0] data,// output: data > > output byte eom); // output: > end-of-message marker flag > > > > The syntax of the SystemVerilog LRM with respect to DPI import tasks > allows for the actual argument passed as the pipe_id argument to be any > value between -2147483647 and 2147483647, since the formal argument is a > signed int. Syntactically, the value can be dynamic; it may be computed > and passed as a variable, as shown below: > > > > always @(posedge clk) begin > > currentPipeID = a + b + c; > > scemi_pipe_hdl_receive(currentPipeID, 1, 1, nElements, pipeData, eom); > > end > > > > Since we know that practically, an emulator will likely have a fixed > number of channels, the question is: How do we enforce a statically > bounded pipe_id at compile time in both simulation and emulation, when > language syntax permits a dynamic actual argument? > > > > Also, let me point out that a module-based approach as we proposed for > IM 218 is one way to resolve this issue, since the task call is > associated with a module instance statically at compile time. > > > > Regards, > > Jason > > > > > > *Jason Rothfuss* > /Verifcation Acceleration R&D/ > > > *Cadence Design Systems, Inc.* > 54 Columbia > Irvine, CA 92612 > > Office: > > > > > > > > +1 (408) 944-7180 > > Mobile: > > > > > > > > +1 (310) 210-2754 > > > > rothfuss@cadence.com <mailto:rothfuss@cadence.com> > www.cadence.com <http://www.cadence.com> > > > > > > > > C a d e n c e <http://www.cadence.com> > > > -- 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 Fri May 19 06:35:03 2006
This archive was generated by hypermail 2.1.8 : Fri May 19 2006 - 06:35:09 PDT