Subject: A doubt in Gap count!

From: Venkatesh V <[email-masked]>
Date: Mon, 22 Feb 1999 10:52:50 +0530

Hi all,

During the self ID processing, is the gap count optimisation to be done for every bus reset or
only when a power reset happens? I am asking this  since 1394-1995 standard specifies a
default gap count of 63 in effect after a power reset.

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)

According to my understanding, if this variable is set to TRUE, then the next time a bus reset
happens, the previous gap count will hold good otherwise it will revert back to the default
maximum value.

Am i confusing or am i missing something???

Eagerly Awaiting a response

Regards,
venkatesh

--

---

From: Kenji Fujisawa <[email-masked]>
Date: Tue, 23 Feb 1999 00:05:46 +0900

>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