METHODS AND APPARATUS FOR ENSURING COMPATIBILITY ON A HIGH PERFORMANCE SERIAL BUS

• US 20100202314A1
• Filed: 04/19/2010
• Published: 08/12/2010
• Est. Priority Date: 02/17/2000
• Status: Active Grant

• Current Assignee: Colin Whitby-Strevens, Jerrold V. Hauck
• Original Assignee: Colin Whitby-Strevens, Jerrold V. Hauck
• Inventors: Hauck, Jerrold V., Whitby-Strevens, Colin
• Granted Patent: US 8,295,302 B2
• Time in Patent Office: Days
• US Class Current: 370/252
• CPC Class Codes: H04L 1/0002 by adapting the transmission rate
• CPC Class Codes: H04L 12/40052 High-speed IEEE 1394 serial bus bus transfer protocol on a daisy chain bus using an embedded synchronisation G06F13/426
• CPC Class Codes: H04L 12/40071 Packet processing; Packet format adaptation of digital video signals for transport over a specific network H04N21/2381, H04N21/4363, H04N21/4381; packet switches H04L49/00; intermediate storage or scheduling H04L49/90
• CPC Class Codes: H04L 12/6418 Hybrid transport

Abstract

A data communications system is disclosed having at least one Legacy cloud coupled to at least one Beta cloud. The system further having at least one BOSS node and at least one border node. A method for ensuring compatibility is disclosed comprising determining when the BOSS node is idle, determining whether the last packet transmitted by any border node was an Alpha format packet if the BOSS node is idle, and unlocking the Legacy cloud if the last packet transmitted by the border node was not an Alpha format packet.

Claims

1-3. -3. (canceled)

4. A method for ensuring compatibility in a data communications system between at least one first cloud of devices having a first device type coupled to at least one second cloud of devices having a second device type via at least one border node, the at least one second cloud having at least one master node, by performing the acts of:

determining when the master node is idle;

if the master node is idle;

responsive to the at least one border node transmitting one or more packets each having one of a plurality of format types, determining a format type of the last packet transmitted by the at least one border node; and

unlocking the first cloud if the format was not a prescribed format type.

5. The method of claim 4, where the prescribed format type comprises an Alpha format type.

6. The method of claim 4, where the plurality of format types comprise first, second, and third format types.

7. The method of claim 6, where the first format type comprises a legacy format type, and the first device type comprises a legacy device type.

8. The method of claim 7, where the second format type comprises a Beta format type, and the second device type comprises a Beta device type.

9. The method of claim 6, where the first format type comprises a Legacy format type which is compatible with the IEEE 1394-1995 standard using a IEEE 1394b PHY.

10. The method of claim 9, wherein the second format type comprises a Beta format type which is compatible with the IEEE 1394b standard using a IEEE 1394b PHY.

11. The method of claim 10, wherein the third format type comprises an Alpha format type which is compatible with the IEEE 1394-1995 standard using a data strobe link.

12. The method of claim 4, where the master node comprises a Bus Owner Supervisor Selector (BOSS) node.

13. The method of claim 12, wherein the method further comprises arbitrating for control of a bus if the BOSS node is idle and the last packet transmitted comprises an Alpha format packet.

14. The method of claim 13, where if said arbitration is successful, sending a null packet to the at least one first cloud.

15. The method of claim 13, where if said arbitration fails, repeating the last packet within the at least first cloud.

16. A computer-readable medium that ensures compatibility in a data communications system between at least one first cloud of devices having a first device type coupled to at least one second cloud of devices having a second device type, via a border node, the computer-readable medium containing instructions which, when executed by a computer:

responsive to the transmission of a packet having one of a plurality of format types;

determine the format type of a most recent packet transmitted by the border node;

if the last packet transmitted by the border node was not of a prescribed format type, arbitrate for control of the second cloud;

determine whether arbitration is granted;

if arbitration is not granted, repeat the last packet within the second cloud only; and

if arbitration is granted, transmit a null packet to the first cloud, said null packet enabling transmissions within the first cloud.

17. The apparatus of claim 16, where the prescribed format type comprises an Alpha format type.

18. The apparatus of claim 16, where the plurality of format types comprise first, second, and third format types.

19. The apparatus of claim 16, where the first format type comprises a legacy format type, and the first device type comprises a legacy device type.

20. The apparatus of claim 19, where the second format type comprises a Beta format type, and the second device type comprises a Beta device type.

21. The apparatus of claim 16, where the first format type comprises a Legacy format type which is compatible with the IEEE 1394-1995 standard using a IEEE 1394b PHY.

22. The apparatus of claim 21, wherein the second format type comprises a Beta format type which is compatible with the IEEE 1394b standard using a IEEE 1394b PHY.

23. The apparatus of claim 22, wherein the third format type comprises an Alpha format type which is compatible with the IEEE 1394-1995 standard using a data strobe link.

24. A method for allowing device communication within a first cloud of devices having a first device type coupled to a second cloud of devices having a second device type via a border node, by performing the acts of:

receiving a plurality of packets at the border node, the plurality of packets comprising at least first packets of a first format and second packets of a second format;

responsive to the border node receiving one or more of said second data packets, locking the first cloud;

responsive to the border node receiving one or more of said first packets, unlocking the first cloud; and

allowing one or more devices internal to the second cloud to freely transmit data packets within the second cloud, while the first cloud is locked.

25. The method of claim 24, where the first format type comprises a Legacy format type.

26. The method of claim 25, where the first device type comprises a Legacy device type.

27. The method of claim 24, where the second format type comprises a Beta format type.

28. The method of claim 27, where the second device type comprises a Beta device type.

29. The method of claim 24, where the first cloud comprises a Legacy cloud of Legacy devices which are compatible with the IEEE 1394-1995 standard using a IEEE 1394b PHY;

and

the second cloud comprises a Beta cloud of Beta devices which are compatible with the IEEE 1394b standard using a IEEE 1394b PHY.

30. The method of claim 29, where the act of unlocking the Legacy cloud comprises sending a null packet to the at least one Legacy cloud.

31. The method of claim 29, where the act of unlocking the Legacy cloud comprises:

extracting Legacy data from the second Legacy packet;

appending the Legacy data onto a third data packet; and

identifying the third data packet as an end of data packet.