Re: DPI and transaction pipes

Hi John and ITC techies,

 

I have few questions that popped up while reviewing the latest draft 1.7
of SCE-MI 2 Working Document. Could you address these questions?

 

1. I'll start with a higher level question. In section 2.1 you indicate
that "The (DPI) function call is the transaction". We have spent quite
some time defining the DPI subset that should be used for transaction
passing. Then, later in section 4, the concept of transaction pipes is
introduced and the example in Appendix C illustrates how transactions
are conveyed using pipes. DPI per se is very lightly used in this
example only to communicate Reset Complete. Exported functions are not
even used. By this I can deduct that DPI is mainly used for providing
means for HW and SW side to conveying some vector level information to
each other, but that the transaction is not the argument of the DPI
imported/exported function but rather the argument of the input and
output pipe. 

 

Is my assumption correct so far? If not, why not?

 

I am trying to conceive what simulation users who care will do when
building simulation models when learning the SCE-MI 2.0 supports DPI. I
would expect them to use DPI for transaction level communication (and
hopefully the quite reasonable DPI subset that we endorse for
acceleration). But what will happen when using acceleration? Are the
users expected to modify the interface of their transactors to using
pipes to get the added performance? Or should we enforce using pipes for
transactions with limited role for using pure DPI?

 

2. In sections 4.2 and 4.3 you use the following style for declaring the
pipes:

 

 "DPI-C" context task dpi_pipe_hdl_receive/send

 

I am wondering why you are using DPI semantics when declaring the pipes
or even calling these dpi pipes. For example, assume that the HDL wants
to call dpi_pipe_hdl_send (some arguments). If dpi_pipe_hdl_send is a
DPI import task, it should follow the DPI semantics and yield control
immediately to the C side. But by my understanding, you do not want the
task to yield control to the SW side until the HDL side issues a flush.
Isn't this contradictory to calling DPI task?

 

On the same line of thought, what prevents the dpi_pipe_hdl_receive/send
from simply being a Verilog 2001 task? The implementation is hidden from
the user in the included file and this it is up to the implementation if
it uses DPI, VPI, PLI, SCE-MI 1 or any underlying transport mechanism.
Is this correct? 

 

3. The spec doesn't explicitly define the HW/SW yield control semantics
when using pipes. Here is want we understand so far:

 

Pipe is empty and receive() is called - Yield to producer 

Pipe is full and send() is called - Yield to consumer 

Pipe is not empty and flush() is called - Yield to consumer

 

Is this correct? Shouldn't the spec define explicitly the above
semantics?

 

Thanks,

 

Shabtay

 

 

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

 

Shabtay Matalon

Solution Architect

R&D, CVA

Phone: (408) 428 5081