Subject: Re: No hardware support for asynchronous streams

From: "Wooten, David" <[email-masked]>
Date: Mon, 14 Jun 1999 13:33:46 -0500

Farrell,

The filter that you describe might have some problems.  If the cycle start
is not received by the set-top box, then it will not know that the
isochronous interval has started so the 61993 packets that it is supposed to
be sending to the 61883 engine will be shunted to the asynchronous stream
processing.  One might still want to filter by tags and/or channels in order
to make sure that one doesn't drop any more packets than necessary.

Also, why would someone want to send a packet to the 61883 hardware if the
tag didn't indicate that the packet was 61883 formatted?

Regards,

David Wooten

> -----Original Message-----
> From: Farrell Ostler [mailto:[email-masked]]
> Sent: Friday, June 11, 1999 2:50 AM
> To: [email-masked]
> Subject: Re: No hardware support for asynchronous streams
>
>
> Nagaraj, some comments, interleaved. --Farrell Ostler
>
> >
> > Thanks Myron,
> >
> > Just to clarify, can I now workaround IP Over 1394 using
> Isochronous stream
> > as suggested by Peter? Or do you think of any
> interoperability issues?
> >
> > If a hardware supports loose isochronous, it has to receive
> the async stream
> > as Isoch.
> >
> > If it supports async stream, should it be putting it in the
> async receive
> > buffers or in the isoch receive buffers?
>
> It is probably reasonable to expect that many (most?) early IP/1394
> implementations will based on the PC environment. However,
> there will also be implementations based on other environments,
> won't there?
>
> For example, I've heard that there will be settop boxes with
> IP/1394? These, in turn, may well be based on link chips that feature
> (1) an on-chip IEC 61883 engine to convert between 1394 isochronous
> and video and audio data in various formats and (2) an on-chip
> asynchronous queue system accessible from a host microcontroller,
> which is the place that asynch-stream packets need to arrive.
>
> Such links need to distinguish between isochronous packets and
> asynchronous streams packets so that they can be routed
> to 61883 or to the microcontroller. One way to implement
> the routing decision is to apply the P1394a definition
> of asynchronous streams packets: packets with tCode 0xA that
> are transmitted in the asynchronous phase of the bus cycle.
> Channel filtering takes place downstream from there.
>
> It is true that the routing decision could also be based purely
> on channel number. Nevertheless, there are already link
> designs that do it the first way, a way not at variance
> with the standard.
>
> >
> > The interop issue may arise if the async stream is being
> put into async
> > receive buffers as, I MAY be sending the packets as
> Isochronous stream and
> > the destined receiver would not be receiving the same.
>
> For the kind of link chip described above, the interoperability
> issue is that an asynchronous-stream packet sent out-of-spec
> during the iochronous phase will be routed to the IEC 61883
> engine instead of to the host microcontroller. The IP/1394
> software, if present, will not see it!
>
> >
> > Another simple question. If we support IP multicasting, we
> will be listening
> > on multiple channels. We will be enabling Isoch receive on all those
> > channels including the broadcast channel. If someone uses
> the OHCI hardware,
> > everything will be received into the Isochronous receive
> buffers. So, how do
> > you suggest me to implement IP Over 1394, if my hardware
> doesnot support
> > Async stream.
> >
> > Any suggestion is welcome.
>
> Non-compliance should not be entered into knowingly, especially
> in cases where negative consequences are already known. (It
> is easy enough to "achieve" non-compliance through oversight
> or mis-interpretation.)
>
> Does your hardware have the "raw" tranmit mode mentioned by Myron?
> That may be an answer for the transmit direction.
>
> However, if you have to choose between compliant IP/1394
> (on compliant P1394a asynchronous streams) and your current
> hardware, I hope you will decide for compliance.
>
> >
> > Thanks & Regards,
> >
> > Nagaraj
> >
> > -----Original Message-----
> > From: IETF IP over 1394 Working Group
> > [mailto:[email-masked]]On Behalf Of Myron Hattig
> > Sent: Wednesday, June 09, 1999 9:58 PM
> > To: [email-masked]
> > Subject: Re: No hardware support for asynchronous streams
> >
> >
> > Last year when I looked into this, I convinced myself that
> a OHCI DMA
> > rcv context could be associated with a 1394 channel regardless of
> > whether it was received during isoch or asyn arbitration - the DMA
> > context did not care. In addition, the OHCI controller had
> a single DMA
> > context within the interface that allows multiple channels to be
> > associated with it. Therefore, software could identify via channel
> > number whether the channel is isoch or async, then map ALL async
> > channels (including broadcast channel) to the special DMA
> context that
> > allows multiple channels to be mapped to it.
> >
> > As I recall this many channel to one DMA context mapping
> capability was
> > not exposed through the software services available. I
> assumed when the
> > customer demand arose, the software would change.
> >
> > One implementation of IP/1394 without async stream HW
> support used a raw
> > mode in the HW interface. This raw mode allowed the
> software to send any
> > data during a async arbitrated time frame. The software
> constructed the
> > isoch headers including the CRC prior to sending the data
> out the raw
> > mode. I've been told most 1394-1995 link chips have this raw mode
> > interface.
> >
> > -myron
> >
>