Subject: P1394a BRC input

From: Tom Suters <[email-masked]>
Date: Wed, 16 Jun 1999 18:56:54 +0200

Peter,

I have read parts of P1394a draft 2.1 and have some suggestions for
clarifiation in the text, some small reference errors and some questions
that may lead to changes in the text. It probably won't surprise you
that I have focussed on the capability issue and BCM paragraphs. I am
sorry to be so late with my comments  causing me to address the upcoming
BRC meeting instead of solving this on the reflectors. Nevertheless I
would like to confirm my understanding of the new spec and would
appeciate answers to my questions.

Regards,

Tom Suters
--
+===========================================
| Tom Suters
| Philips Research Laboratories,
| Building WLp-3.15, Post Box WL01
| Prof. Holstlaan 4
| NL-5656 AA EINDHOVEN
| The Netherlands
|
| tel:  +31-40-2744233/2744696
| fax:  +31-40-2743741
| E-mail: [email-masked]
|               [email-masked]
+===========================================+

1) P1394a, draft 2.1, june 1, 1999

1.1) section 9.20

1.1.1) The statement in the first sentence that the BCM register is
optional could be confusing. It is optional under the conditions stated
in the following sentences. Maybe a reference to 9.15 should be made.

1.1.2) The last paragraph references section 9.26 which should be 9.27.
This may have been noticed already by someone else, I am not sure
anymore.

1.2) section 9.25

I think that the wording of the 2nd rule and its explanation in the last
two paragraphs is vague. Maybe an example as below would help (please
correct me if my example is wrong).

BEGIN EXAMPLE

+--------------+-------------------+---------+---------+
|              |                   |         |    X    |
|              |                   |   BCM   |   BCM   |
| capability   |                   |   cmc   |   cmc   |
|              |   irm   -   cmc   |   irm   |   irm   |
+--------------+-------------------+---------+---------+
| node         |    R    A    B    |    C    |    D    |
+--------------+-------------------+---------+---------+
| standard     |      1394-1995    |  P1394a |  P1394x |
+--------------+-------------------+---------+---------+

P1394x is a future standard that defines a new capability X unknown to
the others. Lets assume we start with a network that consists of R and A
an A is root.. Then B gets added. R selects B as the new root and sets
its force_root to TRUE. Now C gets added with force_root FALSE. B will
again become root. Under the new rule, C detects it is more capable than
B and is required to set its OWN force_root, clear the force_root at all
others by sending a PHY config with its own phy-ID and R bit on and then
generate a bus reset. C becomes root. R still sees a root that is cmc
capable so does nothing. If D gets added, the same occurs. After two bus
resets D will be root. If D gets added before C, then C will detect a
root that is as capable as itself (it does ot know about the new
capability X) and shoild not force itself to become root.

END EXAMPLE

The new rule currently has a double negation ("shall not be set TRUE
unless ....) and leavers open who takes the action and what should
happen in case the node is more capable. If my understanding is correct,
I would suggest a rewording of the new rule that seems to capture all we
need to say:

   * if a node detects that it is more capable than the current root, it
     shall force itself to become root by:
        o setting its OWN force_root,
        o sending a PHY config packet to clear force_root on other nodes
        o generating a bus reset.

1.3) Section 9.27

From the current text it is not clear for me whether or not channel 31
is now reserved for async streams as used e.g. by IP1394 and P1394.1.
The first paragraph sais "... is responsible to allocate a channel
....".  Channel 31 is only mentioned in step g). My understanding is
that P1394a in the e-mail discussion agreed to explicitly reserve
channel 31 as the default async stream channel and to forbid any isoch
application to use this channel. If this understanding is correct I
would suggest to make an update of section 8.3.2.3.8 in 1394-1995 (the
CHANNELS_AVAILABLE CSR) that explicitly states this.

Independent on whether or not my understanding is correct, I would
appreciate an answer to the following questions:

   * if the BCM changes the default channel, is c31 still reserved for
     async streams or can isoch applications then start using c31?
   * is the BCM register unchanged after a bus reset? If so, doesn't
     step g) need to re-allocate that channel instead of channel 31?
   * If c31 is ALWAYS reserved for async streams, is there ever a need
     for the BCM to change the channel?
   * If there is no need to change the default channel, why do we need a
     BCM? In that case we simply have a "well-known" default channel.for
     async streams.

Independent of the answers I think the text in the standard needs
clarification on these issues.

1.4) Section 9.30

1.4.1) The STATE_SET register is not defined in 8.3.2.2.1 but 8.3.2.2.2.

1.4.2) the word "otherwise" in clause c) seems to double the "else" in
clause b)

---

From: Myron Hattig <[email-masked]>
Date: Wed, 16 Jun 1999 22:17:14 -0800

Tom,

You have some very good points. Do you plan to go to the p1394a BRC
meeting?

Peter,

Will this topic be discussed in the BRC meeting?

Thanks,

-myron