Subject: Re: No hardware support for asynchronous streams

From: Peter Johansson <[email-masked]>
Date: Sat, 5 Jun 1999 11:52:00 EDT

In a message dated 99-06-04 16:57:40 EDT, [email-masked] writes:

<<I don't understand Peter's second requirement for being able to work with
IPv4.  It seems to actually be saying that the nodes that one want's to talk
to can receive isochronous packets.  Isn't any node that does IPv4 required
to be able to accept an isochronous packet (that's what tcode 'A' means). So,
if a node meets case 1, isn't case 2 automagicly taken care of?  Maybe it's
simply a matter that the 1394a text says that the asynchronous stream packet
says that it has to be sent outside of the isochronous interval which makes
some people think that they should only look for an asynchronous stream
packet within the isochronous interval.  That would be, I think, a mistaken
interpretation.  Also, one might run into the same problem that we have with
isochronous packets.  The reason that some links have implemented 'loose'
isochronous is because there are some corner cases when nodes don't quite
agree on whether the isochronous interval is over.  So, if it is possible to
need 'loose' isochronous support it seems to me that it seems likely that one
would need 'loose' asynchronous stream support.>>

I had worded the second requirement carefully with the suspicion that a
response just like Farrell's would be forthcoming.

If I were a link designer, I'm not sure I would render it impossible to
receive an asynchronous stream packet within the isochronous period---but
it's certainly a valid interpretation.

Consider a hypothetical link design that wishes to extend its asynchronous
receive DMA context to recognize tcode 0x0A packets and place them into a
general receive FIFO. Channel filtering could be arranged by a bit mask in
hardware or (quelle horreur!) all the stream packets could be left to
software to sort out. I don't think this is a "mistaken" implementation and I
don't wish to participate in an argument as to whether or not its
"inadvisable."

I don't think we can encounter a problem related to "loose isochronous"
reception. A cycle start packet may be observed by the talker, corrupted
before being observed by listeners---with the result that a packet
transmitted under isochronous arbitration is perceived as arriving during the
asynchronous period. This cannot happen inadvertently for tcode 0x0A packets
intended to be transmitted asynchronously.

Why does one require "loose asynchronous stream" support?

Also, I don't mean to argue semantics for their own sake, but when David
asserts that tcode 0x0A means an "isochronous packet" it's not entirely
correct---and it is an important difference. Tcode 0x0A means a STREAM
packet, of which there are two flavors.

Regards,

Peter Johansson

Congruent Software, Inc.
98 Colorado Avenue
Berkeley, CA  94707

(510) 527-3926
(510) 527-3856 FAX

[email-masked]

---

From: Nagaraj G <[email-masked]>
Date: Mon, 7 Jun 1999 08:19:30 +0530

After all these discussions, I am a bit confused. If an asynchronous stream
packet is transmitted during the asynchronous phase, where should it go on
the receiver side? Should it go to Isochronous Receive DMA Buffers (FIFO) or
to Asynchronous Receive (Request) DMA Buffers (FIFO)?

If it is supposed to go to Asynchronous Receive Buffers, then how does OHCI
Specification work? It receives all the STREAM (tcode A) packets in
Isochronous Receive Buffers.

If it is supposed to go to Isochronous Receive Buffers (nearer to definition
of Loose Isochronous), then why should it bother whether it is transmitted
as Asynchronous Stream or Isochronous Stream packet?

Now regarding the channel ownership. Broadcast channel is allocated by the
IRM itself as per BCM specifications. Multicast Channels are allocated by
multicast channel owners and all others who join the group, can transmit on
these channels. DUPLICATE_CHANNELS_DETECTED error should not come for these
cases.

Pls. correct me if I am wrong in any of the above.

Nagaraj

-----Original Message-----
From: IETF IP over 1394 Working Group
[mailto:[email-masked]]On Behalf Of Peter Johansson
Sent: Saturday, June 05, 1999 9:22 PM
To: [email-masked]
Subject: Re: No hardware support for asynchronous streams

to be able to accept an isochronous packet (that's what tcode 'A' means).
So,
need 'loose' isochronous support it seems to me that it seems likely that
one

software to sort out. I don't think this is a "mistaken" implementation and
I

transmitted under isochronous arbitration is perceived as arriving during
the

Regards,

Peter Johansson

Congruent Software, Inc.
98 Colorado Avenue
Berkeley, CA  94707

(510) 527-3926
(510) 527-3856 FAX

[email-masked]

---

From: Nagaraj G <[email-masked]>
Date: Tue, 8 Jun 1999 07:11:58 +0530

I am resending this message as there were no comments.
===========

Nagaraj

-----Original Message-----

Regards,

Peter Johansson

Congruent Software, Inc.
98 Colorado Avenue
Berkeley, CA  94707

(510) 527-3926
(510) 527-3856 FAX

[email-masked]

---

From: Sungjo Bang <[email-masked]>
Date: Tue, 8 Jun 1999 15:56:46 +0900

I'm glad to contact all of you by mail.

I have the honor to explain the stream packets from the standpoint of the link designer.

Mr. Nagaraj said that

"After all these discussions, I am a bit confused. If an asynchronous stream
packet is transmitted during the asynchronous phase, where should it go on
the receiver side? Should it go to Isochronous Receive DMA Buffers (FIFO) or
to Asynchronous Receive (Request) DMA Buffers (FIFO)?"

::
Let me think about the meaning of "isochronous".
As you know, isochronous data is the multimedia stuffs such like audio/video,
which require a guaranteed bandwidth.
Asynchronous is adequate for the data that don't require a guaranteed bandwidth, though.
"Asynchronous stream packet" just adopt the packet format from "isochronous packet" defined by
Std. IEEE1394-1995.
One should not use "asynchronous stream packet" for the transmission of an isochronous data.
Actually, "asynchronous stream packet" is used by BCM for the ARP.
In my link design, I distinguish "asynchonous stream packet" from "isochronous stream packet"
by "channel number". I don't consider whether the packet falls within the isochronous period or not,
by reason that supports a loose isochronous.
The channel number says that which is asynchronous, or isochronous stream packet.
The asynchronous stream packet that abided by P1394.a draft must use asynchronous arbitration,
so it doesn't appear within isochronous period.
But, an isochronous stream packet may appears without isochronous period at some node that
could not receive a correct cycle start packet. It is a loose isochronous.

So, an asynchronous stream packet should go to Asynchronous Receive Buffers.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Any questions are apprecieated.

Best Regards.

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
_/ Sungjo Bang
_/ Design Engineer
_/ Samsung Electronic Co., Ltd
_/
_/ Phone #: 82-331-209-2822
_/ Fax   #: 82-331-209-2839
_/ E-mail : [email-masked]
_/          [email-masked]
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

---

From: Nagaraj G <[email-masked]>
Date: Tue, 8 Jun 1999 17:04:47 +0530

Asynchronous stream is not limited to BCM for ARP. Even IP Multicast will be
on Asynchronous Stream on a different channel different from BCM's channel
(31). So, you just can't distinguish by channel number.

OHCI specification says that whatever you receive with a tcode as A (any
stream packet) it should be placed in Isochronous receive buffers.

Only distinction between these two types of streams will be the phase in
which it is received. If the hardware supports loose isochronous, it will
have to put the stream packets in Isochronous receive buffers and not in
Asynchronous receive buffers.

Nagaraj

-----Original Message-----
From: IETF IP over 1394 Working Group
[mailto:[email-masked]]On Behalf Of Sungjo Bang
Sent: Tuesday, June 08, 1999 12:27 PM
To: [email-masked]
Subject: Re: No hardware support for asynchronous streams

I have the honor to explain the stream packets from the standpoint of the
link designer.

Mr. Nagaraj said that

::
Let me think about the meaning of "isochronous".
As you know, isochronous data is the multimedia stuffs such like
audio/video,
which require a guaranteed bandwidth.
Asynchronous is adequate for the data that don't require a guaranteed
bandwidth, though.
"Asynchronous stream packet" just adopt the packet format from "isochronous
packet" defined by
Std. IEEE1394-1995.
One should not use "asynchronous stream packet" for the transmission of an
isochronous data.
Actually, "asynchronous stream packet" is used by BCM for the ARP.
In my link design, I distinguish "asynchonous stream packet" from
"isochronous stream packet"
by "channel number". I don't consider whether the packet falls within the
isochronous period or not,
by reason that supports a loose isochronous.
The channel number says that which is asynchronous, or isochronous stream
packet.
The asynchronous stream packet that abided by P1394.a draft must use
asynchronous arbitration,
so it doesn't appear within isochronous period.
But, an isochronous stream packet may appears without isochronous period at
some node that
could not receive a correct cycle start packet. It is a loose isochronous.

Best Regards.

---

From: Myron Hattig <[email-masked]>
Date: Wed, 9 Jun 1999 08:27:39 -0800

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

---

From: Nagaraj G <[email-masked]>
Date: Thu, 10 Jun 1999 10:35:42 +0530

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?

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.

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.

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

-myron

---

From: Myron Hattig <[email-masked]>
Date: Wed, 9 Jun 1999 22:53:15 -0800

Using isoch streams is an extremely bad idea; please don't do it.

It sounds like you do not have OHCI hardware and your trying to
figure out what to do. Here is a suggestion.

To receive, duplicate OCHI. That is, have a single set of rcv_buffers
alloced for all async streams. There would be a many-to-one mapping
bewteen all async stream channel numbers to a single set of rcv_buffers.
Then have a one-to-one mapping between an isoch channel and a set of
rcv_buffers. Additional sets of rcv_buffers are necessary to receive
additaional isoch channels. (This assumes the software can identify
async stream from isoch stream just by the channel number.)

To transmit async streams, construct the entire stream packet
(including CRC) in software, then send packet during async arbitration
through the raw mode hw API (if the API exists on your hardware).

If this rcv or xmt cannot be done, then get new hardware.

As someone else said, if your messing around in a lab, isoch streams
will work just fine, but PLEASE don't release such things in a product.
It will cause intermitten problems that the customer (and most
customer support people) will never be able to solve.

-myron

---

From: Farrell Ostler <[email-masked]>
Date: Fri, 11 Jun 1999 01:50:20 -0600

Nagaraj, some comments, interleaved. --Farrell Ostler

> 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 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!

> 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.