Re: More questions on pipes

Shabtay,

Just getting back from a busy week of travel where I was
not able to address this.

Sending out a response now that can be discussion points
for the meeting if we want.

Comments embedded ...

Shabtay Matalon wrote:
> Hi John,
> 
>  
> 
> Here are some additional questions on pipes requiring some clarifications.
> 
>  
> 
> 1. Assume a SystemC test component is generating and sending 
> transactions to two producers on the C side. Assume that each producer 
> has its own SystemC execution thread and that the producers don’t know 
> about each other. One of the two (let say B) will be notified first (in 
> random order) and call dpi_pipe_c_send to send the transaction and than 
> call dpi_pipe_c_flush.
> 
>  
> 
> How pipes are expected to work in this case? Do you expect the consumer 
> of B to consume the transaction and the HW side simulation to resume 
> immediately or do you expect that thread B will be suspended and thread 
> A will be notified to allow producer A to send its transactions and that 
> simulation on the HW side would start running after both transactions 
> have been sent?

johnS:
I will expect both A and B to be given opportunity to execute
in 0-time before H/W time advances in an untimed scenario.
B's thread will be suspended until the consumer takes it's
flushed transaction. Meanwhile, A may be yielded to in the
same sync cycle and given the opportunity to write its transaction.

The easiest way to think of pipes is to think of implementing
them in a pure Verilog environment using events as handshakes.
All of the same issues apply. I don't think SystemC brings
anything new to the table assuming that its thread model blends
properly with that of the HDL side.

And think of a flush as a handshake between producer consumer.

i.e.

producer sends
producer issues flush
producer waits for flush ack
consumer receives
consuemr issues flush ack

It is really no more complicated than that - nor does it need
to be. Especially if you think of it all implemented and
executing in a homogeneous threading system - i.e. in pure Verilog.
Generally anwers you find on semantics there will apply across
to a C threading env such as SystemC.

> 
>  
> 
> Your answer to this question may also address questions such as:
> 
>  
> 
> a)       Do pipes based on the proposal support interaction of more than 
> 1 producer/consumer pair during the same synchronization cycle?

johnS:
Yes.

> 
> b)       Do you expect the pipes implementation to be aware of the 
> threading package used by the application (SystemC threads in this case)?

johnS:
Yes. But this can be hidden from the user quite nicely using
sufficient encapsulation techniques.

> 
>  
> 
> 2. In pure DPI (Caller/Callee model) the calee must respond for the 
> caller to resume its execution. With pipes, what happens when a consumer 
> on the HDL side is calling for example dpi_pipe_hdl_receive, the pipe is 
> empty and the producer on the corresponding C side has no new 
> transaction to send? Will this scenario stall the progression of 
> simulation on the HW side?

johnS:
Yes. This is a user induced deadlock. The assumption is that the
user typically sends an "announcer" transaction to kick of
some streaming operation whose end might be marked by a count
or eom. At the end of the streaming operation the consumer
would not go back in and read the pipe again unless the producer
indicates readiness of another data stream.

> 
>  
> 
> Your answer to this question may address questions like:
> 
>  
> 
> a)       Is an implicit NOP scenario supported by pipes or if any NOP 
> condition must be conveyed from producer to consumer explicitly?

johnS:
I don't believe this is needed using an eom or count scheme.
Again, the idea is to keep it like Unix streams.

Generally you don't eep reading a Unix file stream once you've
received EOF. Same idea here.


> 
> b)       If explicitly, how would the consumer know when a new 
> transaction can be consumed after explicit NOP notification was sent?

Our thinking is via an exported DPI announcer function
or some other operation which initiates a data stream.

-- johnS
<eom> (meaning "don't read beyond this message" ! :-)

> 
>  
> 
> Thanks,
> 
>  
> 
> Shabtay
> 
>  
> 
> -------------------------------------
> 
>  
> 
> Shabtay Matalon
> 
> Solution Architect
> 
> R&D, CVA
> 
> Phone: (408) 428 5081
> 
> email: shabtay@cadence.com
> 
>  
>