Re: [Qemu-devel] [RFC] QOMification of AXI stream

[Peter Crosthwaite]

On Tue, 2012-06-12 at 09:58 +0200, Edgar E. Iglesias wrote:
> On Tue, Jun 12, 2012 at 10:33:51AM +1000, Peter Crosthwaite wrote:
> > >
> > > Hi,
> > >
> > > IIRC the word array thing is device specific, not really AXI stream.
> > > I think the whole connection to AXI is a bit unfortunate,
> > 
> > Yes, so I think we can summaries the confusion here with AXI stream is
> > completely unreleated to AXI. The connection between the two comes
> > with the way low level signalling is handled. (e.g. the SRC_RDY and
> > DST_RDY pins etc. etc.), thats common between AXI and AXI stream hence
> > the shared name. This is of course completely irrelevant to QEMU.
> > 
> > these devices
> > > are pretty much the same devices that in other contexts where connected
> > > to other bus standards. Xilinx choose to name them AXI-xxx and I used
> > > the name in our models but I didn't really model anything that is AXI
> > > stream specific..
> > >
> > 
> > Theres not a lot to model. With the signalling stuff taken away, its
> > pretty much just a unidirectional point-to-point data bus. There is
> > the T_LAST bit, and the extended capabilities PMM mentioned.
> 
> IMO:
> Yes, the end-of-packet needs to be modeled,
> (e.g one function-call -> one packet). The exteneded stuff is AFAICS just
> optimization, the abstract concept is still data moving. We are not modeling
> AXI Stream, we should be modeling the common abstraction between DMA ctrls
> and devices. Error reporting from the sink/device might be needed in some 
> cases
> (overrun/underrun etc).
> 
> Another issue is that these data paths are typically high-speed. So a zerocopy
> approach might be worth looking at. For example, if all the chunks in
> a packet are backed by host memory, we could just pass pointers to
> the final sink, which in turn can do the equivalent of a writev() without
> memory_rw into temporary linear bufs etc. maybe...
> 

Hi All,

Edgar and myself discussed this on IRC and came to the follow
conclusions:

1: AXI-stream is too specific for QEMU.

A good example of why, is (our of tree) we have another DMA and ethernet
controller that works over the core-connect local-link interface, which
is also a trivial interface. The thinking is the same basic abstraction
should be used for both for simplicity and reduced code volume. Also
means bridges can be modelled transparently. Its also consistent with
sysbus - sysbus models but has no AXI awareness so stream shouldnt have
axi awareness either.

2: This Interconnect is not DMA

Because its and addressless stream interface that pushes and pops. DMA
is an application of the interconnect, not part of it.

So if its not AXI-stream and its not DMA what is it? I guess its just a
"stream". In my current RFC I have TYPE_AXI_STREAM_SLAVE etc etc, change
this to TYPE_STREAM_SLAVE? Any other input on naming?

Regards,
Peter

> Cheers