Comments on Pipes - Topics for discussion in the face to face meeting tomorrow

Hi John/ITC techies

 

Here are our suggested enhancements to the pipes proposal based on our
analysis to date. As noted we have requested Mentor's permission to test
your example a week ago on 2/1/06 and have not received it yet. I assume
we could provide additional feedback after being authorized to run the
examples on Modelsim.

 

1. Pipes synchronization semantics (Flush).

 

We look at pipes as candidate for implementing complex
message/transaction passing via a transport layer that is streaming
enabled. This is one of the key attributes that differentiates pipes
from DPI. Based on this perspective, pipes synchronization should occur
by default on transaction boundaries. While it is a benefit that Flush
could be called, we don't thing that BFMs and proxy models should be
required to call Flush() for correct synchronization semantics to occur.
We think that synchronization should take place implicitly on
transaction boundaries in what we define as the reactive (default) mode.
Reactive mode insures correct bring up of the environment w/o any
pipe/buffering latencies.

 

The means to support streaming is to modify the synchronization
semantics on a per pipe basis to streaming. A method could be provided
for each pipe on the SW side to make the pipe stream. Once a pipe is set
to streaming, synchronizations would be driven by the fifo full/empty
and optionally subject to explicit flush control. By this paradigm the
use of flush by the producer even in streaming mode is optional.
Streaming/batching can take place by changing the attribute of the pipe
to streaming. 

 

Last, some producers may use Flush in the model. What I conceive is that
producers calling Flush are forcing synchronization that cannot be
modified by the end user who may change the reactivity of the pipe. For
example, pipes used for implementing tightly coupled bi-directional
protocol (like a read transaction for example) may use flush to force
synchronization at the end of a bi-directional transaction. 

 

The use model I defined above basically allows creating simulation
friendly transactors using pipes that do not require knowledge of
acceleration/emulation specific attributes such as synchronization and
streaming. The models could be used in simulation and configured in
acceleration to provide additional performance.

 

2. Implicit NOOP

 

Implicit NOOP is an important attribute of the interface.  In a nut
shell, it reflects a condition where a consumer is requesting a
transaction and the producer cannot provide one. As an example, an AHB
master BFM may ask for next transaction. The PM notifies the test but
the test decided not to satisfy the request until it receives a response
from a different transactor. This scenario is quite common and should
not deadlock the interface. HW side simulation should resume when all SW
side threads are blocked even if response has not been provided to the
BFM requesting the transaction. 

 

Implicit NOOP does not prevent the option of using explicit NOOP meaning
that the PM could have been designed to convey NOOP explicitly to the
BFM on the same pipe, use a different pipe or use an exported DPI
function. However the later is unnecessary complication.

 

I'd like to comment that some BFMs may wish to use a non-blocking call
in conjunction with Implicit NOOP should the BFM needs to react to this
condition by asserting specific data on the DUT interface.

 

3. Large messages

 

Output BFMs should not be required to know the size of the largest
transaction they deliver neither consider issues such as the maximum
buffer size designated by the implementation on the HW side. 

 

Assume that the implementation has decided to allocate buffer whose
depth is 64 bytes on an output pipe. The transaction delivered is 151
bytes long. Assume the consumer wishes to read full transactions. It is
up to the implementation to manage the transport such that the consumer
will read the entire 151 bytes long transaction independently of the
length of the buffer. Neither the producer BFM nor the consumer Proxy
should be aware how much buffer was designated in the HW. The producer
should have the liberty to deliver transitions of any size as produced
by the interface. 

 

4. Global flush

 

Given that the test may be aware when it needs to synchronize data
across multiple pipes, we should offer a global flush option. Once
called, it will return to the caller when all pipes have been flushed.
This is important in particular to accomplish synchronization at the end
of the test and/or to allow response checkers consume all data to
determine if the test passed and fail. I also expect global flush to be
used in the middle of test for example when switching between one test
scenarios to another.

 

I hope we will designate some quality time for discussing these issues
tomorrow.

 

Thanks,

 

Shabtay

 

 

 

 

 

 

 

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

 

Shabtay Matalon

Solution Architect

R&D, CVA

Phone: (408) 428 5081

email: shabtay@cadence.com