New IM: Pipe ID restrictions

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>