Subject: Re: stds-1394: Re: Re: A doubt in Gap count!

From: Jerry Hauck <[email-masked]>
Date: Tue, 23 Feb 1999 22:06:46 -0800

Hello Dimitris,

I certainly don't claim to be an expert in this particular area, but I do
take some issue with your advice.  The P1394a committee did spend some time
discussing a way to probabilistically get the gap count set properly,
however I don't see that specific algorithm in the latest draft of the
standard.  We may need to ask for help from others to get the preferred
algorithm.

The main concern I have with your approach is that you leave
gap_count_reset_disable set TRUE.  If two rather large functioning buses are
subsequently joined, the gap count will not be reset to 63 after the ensuing
bus reset and we may not be able to properly transmit packets due to
arbitration collisions, etc.  Yes, it may be possible to issue a bus reset
at that point, but it is likely to be a long bus reset which is what we were
hoping to avoid all along.

I think one key to a preferred solution maybe to realize that the bus
manager can initiate an arbitrated short-bus reset immediately after sending
the PHY config packet.  Since the ISBR bit for initiating the reset isn't
located in the same register as the gap_count field, the issue you raise can
possibly be avoided.

I know this isn't a complete solution to the problem ... but I'd like to
make sure we don't force longer than necessary bus resets when buses are
joined.

==========================================================
Jerry Hauck
Silicon Group
Zayante, Inc.
1580 Washington Blvd.               Tel: 510-668-1006
Fremont, CA 94539                   Fax: 510-668-1457
http://www.zayante.com              [email-masked]
==========================================================

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Dimitris Staikos
Sent: Monday, February 22, 1999 11:56 PM
To: [email-masked]; P1394 Mailing List
Cc: [email-masked]; [email-masked]
Subject: stds-1394: Re: Re: A doubt in Gap count!

Hi,

What you say is in principle correct. However, actual behaviour differs
because somebody, somewhere, missed a very minor, but crucial detail.
When a node issues a software initiated bus reset, it sets its own gap_count
at the same time. This happens because writing the IBR bit in the register
map, means at the same time a write to the Gap_count field. This results
into the node's gap_count_reset_disable variable to be set to TRUE.
So, when the bus manager initiates the extra bus reset mandated by P1394a,
it does not actually achieve its purpose. If an extra node is added to a bus
(so that we have a hardware bus reset), then the gap_count of all nodes
drops to 63, with the exception of the previous bus manager.
Unfortunately, there is no way I know of (yet) that you can directly control
a node's gap_count_reset_disable variable (for example through some extended
PHY register).

So, having the bus manager issue an extra bus reset, not only fails to
prevent a gap_count mismatch, but guarantees that one will happen! This
means that the extra bus reset from the bus manager is actually unnecessary.

What should the bus manager do about this issue? My oppinion is that the
opposite goal should be set from setting the gap_count_reset_disable
variable to FALSE at all nodes.
The bus manager should examine the selfid packets after the bus reset, and
if (a) there is a mismatch in the gap_count or (b) the gap_count is not
optimum for the present bus topology, then it should transmit a PHY config
packet to set the gap_count, but NOT issue another bus reset. This will also
reduce the total number of bus resets that occur on the bus (and all the
related processing overhead).

Another important issue that this approach silently prevents is
bus-reset-loops in the presence of 'problematic' adapters. For example,
consider an adapter that due to a hardware bug, resets its gap_count on
*every* bus reset, if-and-only-if it so happens that it has all 3 ports
connected? This adapter works fine otherwise, but has this 'minor' problem
(btw this is not ficticious; I have actually seen such an adapter).
The approach that makes the bus manager issue an extra bus reset after
optimizing the gap_count will result into an infinite loop of bus resets,
since after each reset a gap_count mismatch will be detected.

I think that this is a rather important issue, and has to be discussed
further.
Regards,

----- Original Message -----
From: Kenji Fujisawa <[email-masked]>
To: <[email-masked]>
Sent: Monday, February 22, 1999 5:05 PM
Subject: Re: A doubt in Gap count!

>>During the self ID processing, is the gap count optimisation to be done
>>for every bus reset or only when a power reset happens?
>
>As far as I understand, the bus manager optimises gap_count when it
>detects that gap_count is not optimal.
>As you mentioned, the bus manager initiates bus_reset after sending
>a PHY_config packet. It means the bus manager optimises gap_count
>on every two bus_resets, typically.
>
>>Also P1394a specifies that the bus reset has to be initiated soon after
>>PHY configuration has been set. The reason he gives is the setting of
>>gap_count_reset_disable_variable to FALSE.(i dont understand this point)
>
>If the bus manager does NOT initiate bus reset after sending a PHY config
>packet, the gap_count_reset_disable_variable in all nodes are kept to
>be SET. And if you connect NEW node to this bus, it will cause gap_count
>mismatch, and it may cause a failure of reception of self_ID.
>That's why the bus manager initiate bus reset to reset gap_count_reset_
>disable_variable.
>
>P1394a
>: Without this precaution, the subsequent addition of a new node to the
>: bus could result in different values of gap_count at different nodes
>: and resultant unpredictable arbitration behavior.
>
>Regards,
>
>Kenji Fujisawa

---------------------------------------------------------------------------
Dimitris Staikos
[email-masked] (Business mail only please),
[email-masked] (Personal mail), ICQ UIN 169876
Software Systems & Applications Chief Engineer, UniBrain, www.unibrain.com
---------------------------------------------------------------------------
The great pleasure in life is doing what people say you cannot do.
He has the right to criticize who has the heart to help.
Happiness is not a place to travel to. It's a way of getting there.
"Young man, the secret of my success is that at an
    early age I discovered I was not God".
Children require guidance and sympathy far more than instruction.
---------------------------------------------------------------------------

---

From: Jim Skidmore <[email-masked]>
Date: Wed, 24 Feb 1999 12:58:41 -0800

Jerry & Dimitris,

I don't think Dimitris is correct in his description of the behavior of the
gap_count_reset_disable variable.  When a node writes to reg 1 to set the IBR
bit, Dimitris is correct that the gap_count_reset_disable bit is set TRUE.
However, the bus-reset which immediately follows as a result of setting the IBR
bit will then clear the gap_count_reset_disable bit back to FALSE.

As a general rule, the gap-count field should be written with a value of 63
whenever the IBR bit is set, with the exception of setting IBR following the
transmission of a PHY_CONFIG packet (with the T bit set) in which case the
gap-count field is written with the same value as specified in the PHY_CONFIG
packet.  With this mechanism, all nodes (whether 1394-1995 or 1394a compliant)
will have the same gap-count and will have the gap_count_reset_disable bit set
FALSE. Connection of a new node onto any node of the network will result in a
bus-reset which causes all nodes to reset their gap-counts to 63.

Of course, in a 1394a compliant node, the ISBR bit may be used to initiate the
bus-reset, avoiding the whole problem, as Jerry pointed out.

This was discussed at some length at one of our BRC meetings, but it didn't
seem to make it into the draft revision.

Also, this was not an oversight in 1394-1995.  It is explicitly required by the
spec, and makes sense in the context of a 1394-1995 PHY, which can set the
gap-count only by the RECEPTION of a PHY_CONFIG packet or by a register write.
If the gap_count_reset_disable bit were not set TRUE when the gap-count was
loaded via a register write (which also set the IBR bit TRUE), then the ensuing
bus-reset would immediately clear it back to 63.

Regards,
Jim Skidmore

>  From: Jerry Hauck <[email-masked]>, on 2/23/99 10:06 PM:
>  Hello Dimitris,
>

Jim Skidmore

Texas Instruments Incorporated  | E-mail: [email-masked]
Advanced Serial Bus Design      | MSG-ID: JSKD PC-DROP : PFLL
P.O. Box 660199, MS-8701        | Phone: 972/480-2094
Dallas, TX 75266-0199           | Fax: 972/480-2270

---

From: Ashish Kulkarni <[email-masked]>
Date: Mon, 22 Mar 1999 17:21:31 +0530

Hi!

Correct me if I have missed out anything in the following:

As far as I understand, the gap count can be set by a bus manager with a PHY
config packet. If the bus manager does not initiate a bus reset immediately
after sending the phy config packet, then the very purpose of sending the
config packet to optimise the current topology is lost. The latest spec
mentions that the gap_count_reset_disable variable flag can only be set by
the reception of a PHY config packet. And the only way it is cleared is on
the bus reset following the PHY config packet reception. This ensures that
the gap_count resets to the default (63) after the second bus reset.

I do not see how and why should writing into the gap_count in the PHY
register possibly set the gap_count_reset_disable variable to TRUE. The
1394-1995 & P1394a Draft do not mention anything in this respect. Even in
the case of the bus manager, the bus manager has to keep track of the
gap_count sent in the PHY config packet. All the bus manager will need to do
is to write to the IBR bit with the same value of gap_count and initiate a
bus reset.

If a new node or serial bus is connected to the existing topology, then the
bus reset shall automatically set the gap counts to the default. If this
happens before the bus manager has a chance to initiate a bus reset, then it
will be the responsibility of the bus manager to start all over again with a
new PHY config packet or possibly another bus reset.

Regards,
Ashish Kulkarni.
--
______________________________________________

Ashish Kulkarni,
EnThink Inc.
37, Castle Street, Ashok Nagar,
Bangalore 560 025, India
Phone: +91-80-536-7297
Fax: +91-80-557-6032
[email-masked]
www.EnThink.com
____________________________________________

> [mailto:[email-masked]]On Behalf Of Jim Skidmore
> Sent: Thursday, February 25, 1999 2:29 AM
> To: 'Dimitris Staikos'; [email-masked]'; Jerry Hauck;
> 'P1394Mailing List'
> Cc: [email-masked]'; [email-masked]'
> Subject: RE: stds-1394: Re: Re: A doubt in Gap count!
>
>
> Jerry & Dimitris,
>

---

From: "James M. Skidmore" <[email-masked]>
Date: Mon, 22 Mar 1999 10:00:46 -0600

Ashish,

Please refer to para. 4.1.1.1 PHY control request (PH_CONTROL.request) in
Std-1394-1995, which explicitly states that setting the gap count via this
service (i.e., a write to the gap-count register) also sets the
gap_count_reset_disable flag.  This section and requirement has not been
superceded by 1394a.

As stated before, this requirement makes perfect sense for a 1394-1995 legacy
PHY, which can alter the gap count only by the RECEPTION of a PHY-config packet
or by a direct write to the gap-count register by the local link.  In a 1394a
PHY, this requirement is somewhat redundant since the PHY will decode both
transmitted and received PHY-config packets and set the gap-count and
gap_count_reset_disabled flag accordingly, and the link can use the ISBR
facility to initiate a short-bus-reset.

Regards,
Jim Skidmore