supporting dynamic indexing in SCE-MI 2.0 Pipes object based proposal

ITC Techies,

 

Enclosed is updated intro section of the SCE-MI 2.0 Pipes object based
proposal that supports dynamic indexing. I'd like to emphasize that
Jason and I yet don't think that dynamic indexing is a very useful
feature, but given that others on the committee such as John and Per
think that this feature should be retained, we accepted their view with
the enclosed enchantments to support dynamic indexing.

 

John, 

 

We drilled more on your handle related comments. We think that scope and
handle are interchangeable but please take a look at this and tell us if
you see a difference between the two. Note that we don't think that you
no longer need to provide a flag to denote pipe input or output with
this proposal when obtaining the scope handle.

 

Brian,

 

You may want to let the ITC members study this proposal for another week
as we could only deliver this today while resolving some dangling
technical issues.

 

Thanks,

 

Shabtay

 

------------------------------------------------------------------------
------------------------------------------------------------------------

 


1.2       SCE-MI Transaction pipe objects - introduction


All pipes within a given HDL module scope are created as System Verilog
modules (also named objects) presenting task level interfaces. The
module instance name (also named pipe object) becomes a unique
identifier of the pipe. This allows, for example, to instantiate
multiple pipes with distinguished names such as pipe0, pipe1, pipe3,
pipe4, etc in a single HDL module. All pipe operations on the HDL side
must indicate the pipe object name and the task name used for the
operation. 

Pipes can contain one or more identical channels. The number of channels
is defined during instantiation.

Here is an example how to instantiate and use a pipe object containing
one channel on the HDL side. Note that channel ID is not used with a
single channel pipe object.

module bfm;

   scemi_in_pipe #(32) pipe0 (); //instantiates input pipe0 with 32 bits
per element

   always @(posedge clk) 

      pipe0.receive(num_elements, num_elements_read, 

                        data, eom);          //calling pipe0 receive
task

   scemi_out_pipe #(36) pipe1 ();//instantiates output pipe1 with 36
bits per element

   always @(posedge clk) begin

      pipe1.send(num_elements, data, eom); //calling pipe1 send task

      pipe1.flush(); // No arguments required when calling flush on a
single channel pipe

   end

endmodule

Note that this proposal suggests to further simplify the implementation
of SCE-MI 2.0 by defining the pipe bits_per_element as a static
parameter passed to pipe instance during instantiation.

Here is an example how to instantiate and use a pipe object containing
multiple channels on the HDL side. Note that the max number of number of
channels within a pipe is defined as the first parameter during
instantiation. The channel ID must be specified as the first argument on
the argument list when calling the multi-channel pipe. All channels used
by multi-channel pipe share the same attributes (e.g. direction and
bits_per_element). 

module bfm;

   scemi_in_mc_pipe #(5, 32) mcpipe0 (); //instantiates multi-channel
pipe0 with 

                                      5 channels; 32 bits per element

   always @(posedge clk) 

      mcpipe0.receive(4, num_elements, num_elements_read, 

                 data, eom);          //calling mcpipe0, channel 4
receive task

      mcpipe0.receive(1, num_elements, num_elements_read, 

                 data, eom);          //calling mcpipe0, channel 1
receive task

 

   scemi_out_pipe #(10, 36) mcpipe1 ();//instantiates output pipe1 with
36 bits per element

   always @(posedge clk) begin

      mcpipe1.send(9, num_elements, data, eom); //calling mcpipe1
channel 9 send task

      mcpipe1.send(6, num_elements, data, eom); //calling mcpipe1
channel 6 send task

      mcpipe1.flush(9);    // Flush channel 9

      mcpipe1.flush(6);    // Flush channel 6

 

   end

endmodule

 

Note that each multi-channel pipe is called with a channel ID provided
as the first argument on the call argument list. The argument value can
vary between 1 to the number of channels instantiated per pipe or the
task will return with a run-time error.

This proposal allows defining a multi-channel pipe with a single channel
if user prefers doing so. However this channel must also be called with
channel ID 1 as the first argument on the argument list when calling the
multi-channel pipe.

 

The C side can call a single channel pipe or a multi-channel pipe as
follows. On the C side a single channel or multi-channel pipe has a
single unique scope that must be identified by its pipe HDL scope. 

Here is an example how a single channel pipe is being called:

void thread0()

{

   scemiScope scope;

   scope = svGetScopeFromName("bfm.pipe0");

                                      //derive handle from object
instance name

    while(1) {

      svBitVecVal message;

      /* fill in the message */

      scemi_pipe_send(scope , num_elements, 

          data, eom);      //sends message to channel 1 in the current
pipe scope

   }

}

 

void thread1()

{

   scemiScope scope;

    scope = svGetScopeFromName("bfm.pipe1");

    while(1) {

      svBitVecVal message[2];

      scemi_pipe_receive(scope, num_elements,

           num_elements_read, data, eom);

      /* do something with message */

   }

}

When a multi-channel pipe is instantiated the scope is linked to the
pipe and not to any pipe channel. Channels within multi-channels pipes
could be called with the pipe scope as follows:

 

{

   scemiScope scope;

   scope = svGetScopeFromName("bfm.mcpipe0");

                                      //derive scope from object
instance name

    while(1) {

      svBitVecVal message;

      /* fill in the message */

      scemi_mcpipe_send(scope, 4, num_elements, 

          data, eom);      //sends message to channel 4 in the current
pipe scope

      scemi_mcpipe_send(scope, 1, num_elements, 

          data, eom);      //sends message to channel 1 in the current
pipe scope   }

}

 

void thread1()

{

   scemiScope scope;

    scope = svGetScopeFromName("bfm.mcpipe1");

    while(1) {

      svBitVecVal message[2];

      scemi_mcpipe_receive(scope, 9, num_elements,

           num_elements_read, data, eom);

      scemi_mcpipe_receive(scope, 6, num_elements,

           num_elements_read, data, eom);

      /* do something with message */

   }

}

Notes:

*         Deriving the scope from the name no longer requires retrieving
it from the combination of a pipe's intra-module ID and its HDL but
simply from the pipe object name instantiated in the transactor. 

*         In this proposal, scope and handle are the same as both relate
to the scope of the pipe independently whether it is a single channel
pipe or multi-channel pipe.

 

 

-------------------------------------

 

Shabtay Matalon

Solution Architect

R&D, CVA

Phone: (408) 428 5081

email: shabtay@cadence.com



 

________________________________