shabtay’s take 04/28 - Cadence to submit enhancements/modifications to existing pipes proposal based on Jason’s initial email.

Committee agrees. Still active. Latest version of spec

JasonR>

After exploring pipes for several weeks, there is an idea that I would like to get feedback from the group:

Instead of passing the Pipe ID as an argument to a function, why not create a Pipe object instead?  Here is an example: 

// SystemVerilog

module test;

   // parameter is pipe element size (32-bits)

   scemi_pipe #(32) pipe0 ();

   always @(posedge clk)

      pipe0.receive(bus_data);

   scemi_pipe #(36) pipe1 ();  // parameter is pipe element size (36-bits)

   always @(posedge clk) begin

      pipe1.send(data_out);

      pipe1.flush();

   end

endmodule

/* C */

void thread0()

{

   svScope scope;

   scope = svGetScopeFromName("test.pipe0");

   while(1) {

      svBitVecVal message;

      /* fill in the message */

      svSetScope(scope);

      scemi_pipe_send(&message);  

   }

}

void thread1()

{

   svScope scope;

   scope = svGetScopeFromName("test.pipe1");

   while(1) {

      svBitVecVal message[2];

      svSetScope(scope);

      scemi_pipe_receive(message);

      /* do something with message */

   }

}

Doing this, the pipe module can export tasks/functions such as try_send(), try_receive(), send(), receive(), flush().  To me this seems more consistent with DPI, where you call a function/task associated with the Pipe object, rather than passing an ID or handle.  Also, having instances versus run-time function calls with Pipe ID, can make inferring the buffer objects more efficient.  In addition to its ease of use and ease of implementation, the approach seems more "object-oriented", reduces the parameter list for function calls, and is more TLM-like.

<JasonR