WO2002073844A2

WO2002073844A2 - Hardware boot protocol

Info

Publication number: WO2002073844A2
Application number: PCT/US2002/004741
Authority: WO
Inventors: Magnus Svevar; Lars Hakan Ramfelt
Original assignee: Dynarc Inc. Dba Dynamic Network Architecture Inc. In Ca
Priority date: 2001-02-14
Filing date: 2002-02-12
Publication date: 2002-09-19
Also published as: AU2002245462A1; WO2002073844A3

Abstract

The method is a herdware boot protocol for a ring topology (200, 240, 280, 300) that has a first node (204, 244, 284, 304) connected to a second node (206, 246, 286, 306) connected to a third node (202, 242, 282, 302). The boot protocol provides not only a seamless bus-to-ring configuration and ring-to-bus configuration but also a very fast and reliable master node and slave node selection routine. The switch may between bus and ring configuration may be performed without the need for rebooting the system.

Description

HARDWARE BOOT PROTOCOL

Technical Field

The present invention relates to a boot protocol for network systems that is implemented in hardware.

Background and Summary of the Invention

Conventional boot protocol systems are sometimes implemented in software and it is difficult to make the boot phase of software based boot protocols faster than a couple of hundred milliseconds. With the increased need for computer power and speed, a boot phase of several hundred milliseconds is sometimes unacceptably slow. There is a need for a shorter configuration time, higher speed and more reliable boot protocol that enables a seamless switching between a bus topology mode and a ring topology mode and vice versa with very little or no loss of data. There is also a need for a faster and more reliable selection routine of master nodes and slave nodes.

The boot protocol of the present invention is focused on implementing the boot protocol directly onto hardware which makes it possible to reduce the boot phase to a few milliseconds. The boot protocol provides not only a seamless bus-to-ring configuration and ring-to-bus configuration but also a very fast and reliable automatic master and slave node selection routine. In this way, there is no need to reboot the system before the configuration change can take place.

Brief Description of the Drawings

Fig. 1 is a schematic view of a DTM cycle including frame and gap slots;

Fig. 2 is a schematic view of the DTM ring topology of the present invention showing slot reuse of different segments; Fig. 3 is a schematic view of a flow diagram of a state machine of the present invention; and

Fig. 4 is a schematic view of a simple ring having nodes; Fig. 5 is a schematic view of a simple ring in which one of the nodes has an useδkHz bit set;

Fig. 6 is a schematic view of a simple ring in which a break occurs;

Fig. 7 is a schematic view of a simple ring in which a break in the ring is repaired;

Fig. 8 is a schematic view of a simple ring in which a break occurs and certain nodes are subjected to a forceMaster and a rxError event;

Fig. 9 is a schematic view of a simple ring in which the break is repaired and certain nodes are subjected to a forceMaster and an rxError event; and

Fig. 10 is a schematic view of a double bus topology in some of the nodes are connected to an 8kHz reference clock.

Detailed Description

With reference to Figs. 1-10, the present invention is suitable for a variety of network systems and the dynamic transfer mode (DTM) topology is only mentioned as a suitable application.

One feature of the DTM ring topologies is that the cycle time and the slot length are, preferably, constant throughout the DTM ring topologies. The DTM ring topologies are often designed for a unidirectional medium with multiple access, such as fiber optics medium, having a capacity that is shared by all the connected nodes. The slots may be dynamically allocated between the nodes, as required.

If a slot reuse method is used, a single slot may be used multiple times on the ring topologies. Slot reuse enables simultaneous transmissions in the same slot over disjointed segments of the ring topologies. Slot reuse may be described as a general method to better utilize shared links in the ring topology.

To allow slot reuse in DTM, the block token format may be extended to include parameters describing the segments it is representing. The channels may be designed to only reserve capacity on the segments between the sender and the receiver. A single slot may, in this case, be used multiple times on the ring topology. As shown in Fig. 2, channel 0 is using the same slots as channel E but on different segments. Similarly, channel F and channel G use the same slots but on different segments. This may be referred to as slot reuse .

Fig. 1 illustrates the details of a complete time cycle 50 that may be defined as an integer number of time slots corresponding to, for example, about 125 microseconds . The DTM topologies are often divided into cycles of 125 microseconds that are further dividable into 64 -bit slots. The cycle 50 may be divided into frame 52 and gap slots 54. In this way, the frame 52 may include a fixed number of slots that is slightly less than the total number of slots in the cycle 50. The frame 52 may be used to include data slots for carrying pay loads and control slots for carrying control and management messages.

It is often necessary to include gap slots 54 in each cycle 50 because each node in the ring topology may not be perfectly synchronized to 125 microseconds and the gap slots 54 may be used to accommodate some variations between the nodes. The gap slots 54 are preferably never used to carry payloads but are only used as an adjustment mechanism. The number of gap slots 54 may be adjusted up or down a few slots so that the average cycle time is very close to 125 microseconds. More particularly, the gap slots 54 may be DTM_FI frame idle slots that may be used to provide means of handling differences in the local oscillators. The insertion and use of the DTM_FI slots in each cycle allow the nodes to transmit signals at slightly different speed. The PL may be used to control how many DTM_FI slots are to be sent for each new cycle. For example, for a certain fiber channel, the master node may be restricted to only send a particular number of idle slots, such as 10, 11 or 12 idle slots, when it is set to an external 8kHz reference. If no external reference is present, the master node may send any number of slots such as sending 11 slots. The slave nodes may be adapted to send between 9-13 idle slots but after the PLL has locked, it should only adjust the frame length with +/- one idle slot. The remaining bytes of the DTM_FI slots may be ignored by the system because the slots are not part of the frame.

In the preferred embodiment, the frame 52 may also include a start slot 56, such as a DTM_FS frame sync slot, that may be used to indicate the start of a new DTM frame. The frame start may also be defined as one DTM_FS slot followed by a plurality of DTM_FI frame idle slots. The number of DTM_FI slots may be adjusted so that the frame start occupies a fixed amount of time. As is explained in detail below, the slot 56 may include boot information and could be used to trigger the boot phase of the present invention. The boot information may include, among other things, the ieee address of the node, bus bit and the refδkHz bit. As outlined below, the DTM_FS slot may also include information whether the bus bit and the 8kHz bit are set or not. Preferably, the sync slot 56 is always included in the frames and contains the boot information. This may be necessary to properly support a smooth transition from a bus topology to a ring topology and vice versa. As described in detail below, the master node always inserts its own boot information. This applies both to master nodes of bus and ring topologies. In a slave node, the sync slots are passed on to the next downstream slot . The frame 52 may also include a DTM_FE frame end slot 57 to indicate the end of the frame 52. The slot 57 may include a checksum used to measure the link quality by calculating bite faults in a checksum of the frame 52. When the frame 52 is used to send packets of information, the frame could include a DTM_PE packet end slot to mark an end of a packet and DTM_PI packet idle slots to indicate gaps in the packet.

The system may include at least three major modes of operation in the MAC such as master mode, slave mode and boot mode. In other words, the nodes in a topology may alter between the various nodes depending, for example, on the instructions of the signals received from a previous node or instruction messages that are triggered by software commands.

In general, the nodes are either passive or active. A passive node may be defined as a node that has no driver loaded or the node has received no ieee address from another driver. Preferably, a passive node never participates in the boot phase. An active node has received a 48 bit ieee address from the driver and is always participating in the boot phase. The master node selection may be terminated by ending the boot phase, i.e., the master node starts sending out normal DTM frames into the node topology.

Fig. 3 is a flow diagram 200 that schematically illustrates how certain events change the mode of the nodes. For example, if a node is in a boot mode 202 and receives its own ieee address so that the incoming ieee address matches its own ieee address, i.e., an ieeeMatch=l signal 204, then the node goes from the boot mode 202 to a master wait mode 206. The master wait mode is necessary to make sure all the other nodes in the ring structure have switched from the boot mode to the slave mode before the node in the master wait mode may enter the master mode. As indicated above, the ieeeMatch event means that the incoming ieee address is an exact match with the node's own ieee address. The comparison between the incoming ieee address and the node's own ieee address is made during the boot phase and has at least two functions. One is to end the master selection procedure during the boot phase and to determine if a switch from a bus topology to a ring topology may be performed with only a ring expansion without requiring a reboot of the nodes .

While in the boot mode 202, the node receives regular DTM frame to trigger a cycleUp event 208, the node goes from the boot mode 202 to a slave mode 210. The cycleUp event 208 indicates that the node receives sync slots that are within a valid 125 microseconds interval spacing so that the DTM frames are working properly since there may be a slight variation of the interval that is adjusted with gap slots.

While in the slave mode 210, the node receives either a bootMode signal 216, a forceReboot signal 218 or that, for example, no DTM frames so that a cycleUp=0 event 220 is triggered, the node goes from the slave mode 210 to the boot mode 202. The cycleUp=0 event 220 may be the results of an invalid spacing between the sync slots so that the time spacing is more than 125 microseconds. The bootMode signal 216 may be a signal that has at least two consecutive sync slots and the forceReboot signal 218 is a software triggered reboot.

While in the bus master mode 214, the node receives a sufficient number of DTM frames to trigger a cycleUp event 224 or an update event 226 is triggered when, for example, a break is restored, the node expands the ring structure and goes from the bus master mode 214 to a ring master node 228. The update signal 226 is an indication from the data-path that the ring expansion is completed and that a sync slot has arrived after the node expansion is completed. This may mean that the expansion is completed and that the node is not in the boot mode . While in the bus master mode 214, the node receives a boot mode signal 230, the node goes from the bus master mode 214 to the boot mode 202. It should be noted that when the node is in the bus master mode and the node receives a forceReboot signal, the node ignores this signal because the master node cannot be changed as long as the topology is a bus structure. However, if the topology is a ring structure, the node will go to the boot mode when a forceReboot command is received regardless of the state of the node. The forceReboot command is software driven and overrides the hardware protocol commands as long as the topology is a ring structure .

While in the ring master mode 228, the node receives a bootMode signal 232, cycleUp=0 event 234, forceReboot signal 236 or an ieeeMatch=0 event 238, the node goes from the master mode 228 to the boot mode 202. The ieeeMatch=0 event 238 means that the node does not receive its own ieee address and that another node could have a higher ieee address and should become the new master node. This could happen, for example, if new nodes are added to the ring structure .

While in the master wait mode 206, the node receives a bootMode signal 239, a forceReboot signal 242 or if a cycleUp=0 event 237 or an ieeeMatch=0 event 240 is triggered, the node goes from the master wait mode 206 to the boot mode 202. The triggering of the ieeeMatch=0 event may be the result of an additional ring structure or node that may have been connected to the ring structure so that the boot phase must be performed again.

While in the master wait mode 206, the node receives a sufficient number of DTM frames to trigger a cycleUp event 221, then the node goes from the master wait node 206 to the master mode 228. If the node receives a forceMaster signal 244, the node will go to the master mode 228 regardless of the state of the node, as indicated by any state 245. The forceMaster command is software driven and overrides the hardware boot protocol. In other words, it does not matter whether the node is in the master wait mode 206, the boot mode 202, and the slave mode 210 or in the bus master mode 214, the node will still go to the master mode 228. Similarly, if the node receives an rxError signal 212, the node will go from, whatever state it is in, as indicated by any state 247, to the bus master mode 214 and the bus bit is set to indicate to the downstream nodes that the topology is a bus structure so that all the other downstream nodes must go into slave mode. The rxError signal may be generated by an external device that detects that there is no power on a certain segment. The rxError signal may also be treated as an event that indicates that a node has not received any information for a certain time period. In other words, the rxError message may stand for a mix of several different errors that all indicate to the node that reliable communications from the upstream node has been lost. For example, the rxError message may be triggered by 8bl0b code violations, synchronization violation time period exceeding 125 microseconds. If there is a conflict between the rxError 212 and the forceMaster 244, the forceMaster 244 generally prevails, as explained below.

The automatic master/slave selection of the nodes is typically performed very quickly such as in a few time slots. The information required to make the selection is transmitted to every slot so when one node receives an ieee address match, it will become the master node after the address has propagated through the ring structure. Every node in the ring structure has a constant delay of a few slots up to less than ten slots so the master/slave selection of the nodes is preferably completed in a few microseconds . The ring topology may be set so that the "watchdog" of the topology requires two valid DTM frames before the cycleUp event is triggered. Since no DTM frame may be sent from a node before the cycle is up (except for the master node itself) , it will take at the most two DTM frames, or at the most 250 microseconds per node if one cycle is 125 microseconds, before the master node the cycleUp event is triggered. Of course, the cycleUp event may be set to require the receipt of more or less than two DTM frames to be triggered. The transformation from a particular mode to the boot mode is very fast. The node only needs to receive at least two consecutive sync slots to go the boot mode. As explained in detail below, the switch from ring-to-bus configuration may be performed automatically without rebooting. The bus bit may be set and transmitted with the sync slots. The bus-to-ring configuration only requires that a cycleUp event be triggered at the bus master without the need for rebooting. If one node is forced to become the master node, the topology may have two masters when the ring topology is closed including the forced master node and the bus master node. In this case, the bus master node will go back to boot mode.

Fig. 4 is a simple ring configuration 200 that is used as an example to illustrate some important features of the present invention. For example, the configuration 200 may have three nodes 202, 204 and 206 that are connected to one another to form a ring topology. Assuming that the power is turned on so that the nodes go into the boot mode and only sync slots are transmitted in the ring structure. The default mode may be set to be the boot mode . Node 202 transmits a sync signal 208 that includes, among other things, the ieee address of node 202, to node 204. Simultaneously, node 204 sends a sync signal 210, including, among other things, the ieee address of node 204, to node 206 and node 206 sends a sync signal 212, including the ieee address of node 206, to node 202. At this stage, no node has received any incoming signals yet.

The sync signals 208, 210 and 212 may include at least two consecutive sync slots. In practice, the sync signals may include only sync slots. However, it should be understood that the present invention is not limited to two consecutive sync slots to trigger the boot mode. Other sync slot patterns may be used such as having one sync slot followed by a certain number of idle slots before a new sync slot appears in the frame. It may even be possible to create patterns that do not include any sync slots at all to trigger the boot mode. Preferably, the positions of the sync slots should be different from conventional frames that carry payloads so that the nodes may distinguish between conventional payload frames and frames that are intended to trigger the boot mode . The present invention may even work without the use of bootMode signals. It should be noted that a boot mode signal may be received although the topology is not up and running such as when at least one node does not have a cycleUp. As explained in detail below, when a node is in the boot mode, the state of the node may not change until it receives, for example, a sufficient number of DTM frames to trigger the cycleUp event, or any other suitable message, before the state changes.

Node 202 receives the signal 212 that includes the ieee address of node 206 and may, during the boot phase, be designed to transmit the address of the node with the highest numerical value. That is, node 202 may select and forward the address with the highest numerical value by selecting from the addresses of node 206 and node 202. When the selection is completed, node 202 transmits a signal 214, including the highest ieee address, to node 204. Similarly, nodes 204, 206 each receives the signals 208, 210, respectively, and the nodes may select and forward the node ieee address with the highest numerical value to the next node. Of course, the nodes may be designed to select and forward the node address based on other criteria such as selecting the ieee address that has the lowest numerical value. Simultaneously with the transmission of the signal 212 by node 202, node 204 may transmits a signal 216 to node 206 and node 206 transmits a signal 218 to node 202. For purposes of illustration, the ieee address of node 206 is assumed to be greater than the ieee address of node 204 that, in turn, is greater than the ieee address of node 202. Node 202 receives the signal 218, that includes the ieee address of node 206, node 204 receives the signal 214, that includes the ieee address of node 206, and node 206 receives the signal 216, that includes the address of the node 204.

Node 202 transmits a sync slot signal 220 to node 204 that includes the address of node 206. Node 204 transmits a sync slot signal 222 to node 206 that includes the address of node 206 and node 206 transmits a sync slot signal 224 to node 202 that includes the address of node 206.

Node 202 receives the sync slot signal 224 from node 206 and forwards the ieee address of node 206, node 204 receives the sync slot signal 220 and forwards the ieee address of node 206 and node 206 receives the sync slot signal 222 from node 204.

When node 206 receives the sync slot signal 222 and notices that node 206 has received its own address then node 206 goes into the masterWait state and starts to transmit DTM frames 226 with its own ieee address in the sync slots. Node 206 remains in the masterWait state and continues to transmit DTM frames with its own ieee address in the sync slot .

When node 202 receives two valid DTM frames 226 from node 206 a cycleUp event is be triggered so that node 202 goes from the boot mode into the slave mode. When node 202 is in the slave mode, the DTM frames 226 transmitted by node 206 may pass through node 202. Of course, fewer or more DTM frames may be required to trigger the cycleUp event, as desired.

Node 204 still only receives sync slots from node 202 that include the ieee address of node 206. Similarly, node 206 only receives sync slots from node 204. Node 206 continues to remain in the masterWait state and to transmit DTM frames including its own ieee address to node 202.

Node 202 remains in slave mode and the DTM frames 226 from node 206 are passed through node 202. After node 204 has received two valid DTM frames 228 from node 202, the cycleUp event is triggered and node 204 goes from the boot mode into the slave mode so that the DTM frames may pass through node 204. Prior to node 204 going into the slave mode, node 206 still receives only sync slots from node 204 that include the ieee address of node 206. In this way, node 206 remains in the masterWait state and continues to transmit DTM frames with its own ieee address to node 202.

At this point, both node 202 and node 204 are in the slave mode so that DTM frames may pass through both nodes. When node 206 receives two valid DTM frames 230, i.e., two of the DTM frames have passed through the entire ring, node 206 will go into master mode and the DTM frames 230 may pass through node 206 also and into the ring configuration 200 again. Fig. 5 is a ring configuration 240 that is very similar to the ring configuration 200, shown in Fig. 4, except that one of the nodes has an useδkHz bit set in the sync slot. In general, an ieee address of a node with the 8kHz bit set may be treated as preempting other ieee addresses although the other ieee addresses may have higher numerical values. It is desirable to make the node with the 8kHz bit set as the master node because the node is connected to an external reference clock that synchronizes the entire ring. The slave nodes are, preferably, not designed to follow an external reference clock directly.

Only the significant differences between the configuration 200 and the configuration 240 are described below. Also, only the significant signals and events are described for simplicity. More particularly, the configuration 240 has nodes 242, 244 and 246. Node 246 has an ieee address with a numerical value that is greater than an ieee address of node 244 that, in turn, is greater than an ieee address of node 242. When node 246 transmits a sync slot signal 248 to node 242, node 242 will forward the ieee address of node 246 in a sync slot signal 250 to node 244. Node 244 receives the signal 250 and forwards the ieee address of node 244 in a sync slot signal 252 although the ieee address of node 246 is greater than the ieee address of node 244 because the useδkHz bit of the signal 250 from node 244 is set. If the useδkHz bit had been set for both node 244 and node 246, the node 244 would be required to compare the ieee addresses of both nodes to determine which ieee address should be forwarded.

Node 246 receives the signal 252 and forwards the ieee address of node 244 in a sync slot signal 254 because the 8kHz bit of the sync slot of the signal 252 from node 244 is set. Node 242 receives the signal 254 and forwards the ieee address of node 244 in a sync slot signal 256 to node 244. When node 244 receives the signal 256 that includes its own ieee address, node 244 will go into the masterWait state and start transmitting DTM frames with its own ieee address in the sync slot.

When node 246 has received two valid DTM frames from node 244, the cycleUp event is triggered and node 246 goes into slave mode. Similarly, when node 242 has received two valid DTM frames via node 246, node 242 also goes into the slave mode due to the triggering of the cycleUp event. When node 244 has received the two valid DTM frames via node 242, node 244 goes from the masterWait mode into the master mode and permits the DTM frames to pass through to node 242.

Fig. 6 illustrates a ring-configuration 280 that includes a break in the ring-configuration. The configuration 280 has nodes 282, 284 and 286. It is assumed that the configuration 280 is up and running and that node 284 is the master node and that nodes 282, 286 are slave nodes. The connection between nodes 286 and 282 is then broken. As a result of the break, node 282 receives an rxError signal 288 that triggers node 282 to immediately go into the busMaster mode but the node continues to transmit valid DTM frames without interruption. Because node 282 is in the busMaster mode, the node sets the bus bit in the sync slot boot information field and inserts its own ieee address.

Before node 282 has transmitted the new boot information, slots 284, 286 still have cycleUp and only see the ieee address of master node 284 without the bus bit set.

Node 282 sends a signal 290 with the bus bit set to node 284. Node 284 receives the signal 290 and sees that the bus bit is set for the ieee address of node 282. Because the ieee address of node 282 is different from the ieee address of the master node 284, there is no ieeeMatch and node 284 goes from the master node to the boot mode. After node 284 has received two valid DTM frames from node 282, node 284 goes from the boot mode to the slave mode so that the DTM frames generated by node 282 may pass through node 284. As a result of node 284 going into boot mode, node 286 also goes into boot mode because node 284 stopped to transmit DTM frames to node 286 which triggers a cycle=0 event. As a result of the signal 290, the busBit of node 284 is set. The busBit of node 286 is subsequently set as a result of the signal 292 to node 286. Node 286 remains in the boot mode until two valid DTM frames are received so that node 286 goes from the boot mode to the slave mode to permit the DTM frames, with the busBit set, pass through node 286 if there were more nodes downstream of node 286. It is very important that the event of going from the slave mode to the bus master node is performed quickly so prevent the downstream nodes from also receiving or detecting the rxError event.

Fig. 7 illustrates the configuration 280 in which the connection between two nodes is restored so that the configura ion 280 changes from a bus topology back to a ring topology again. It is assumed that the bus topology is up and running with node 282 as the bus master node and nodes 284 and 286 are slave nodes. It is also assumed that the connection between the nodes 286 and 282 is restored so that the configuration 280 again functions as a ring topology. When the connection between the nodes 286 and 282 is restored, node 282 will no longer receive the rxError signal 288. However, node 282 remains the bus master node until node 282 has received two valid DTM frames via node 286 to trigger the cycleUp event and the update signal gets set. The update signal 291 is set when the first incoming ieee address has been compared with the ieee address of node 282 to complete the ring expansion from the bus mode. Both nodes 284 and 286 remain a slave nodes with the bus bit set because the nodes are still only seeing the ieee address of master node 282.

When node 282 receives its own ieee address, the node starts to goes to master mode and clears the bus bit. Nodes 284, 286 remain in slave node but the but bit will be cleared so that the nodes will see the ieee address of node 282 with the bus bit cleared. An important feature of the present invention is that the bus-to-ring conversion occurred without having to reboot the system.

If, for example, the useδkHz bit is set for node 284, then node 284 will forward its own ieee address although the bus bit is set in the signal received from the bus master node 282. Node 284 will forward its own ieee address but with the bus bit set to node 286. Since node 286 is a slave mode, it will forward the ieee address of node 284 to node 282. In this case, node 282 will go into boot mode as a result of the ieeeMatch=0 event since the incoming ieee address is not the same as the ieee address of node 282. If node 282 receives cycleUp prior to the ieeeMatch=0 event, node 282 will become the master node before it goes into boot mode due the ieeeMatch=0 event . Fig. 8 is a ring configuration 300 in which one of the nodes is subject to a forceMaster event. This event overrides the boot protocol and forces the node to become the master node regardless of the ieee address values of the incoming sync slots. If one node is forced to become the master node, the ring configuration must reboot and the other nodes will become slave nodes.

More particularly, the configuration 300 has nodes 302, 304 and 306. It is assumed that the ring configuration 300 is up and running. Node 304 is subjected to a forcedMaster event 308 and nodes 302, 306 are slave nodes when the connection between nodes 302, 306 is subjected to a break 309. As a result of the break, node 302 receives a rxError signal 310 and will immediately go to busMaster mode but continues to transmit valid DTM frames to node 304 without interruption. Because node 302 is in the busMaster mode, the node will set the bus bit in the sync slot boot information field and insert its own ieee address in the DTM frames .

Before receiving a signal 312 from node 302, nodes 304, 306 are still in cycleUp and only see the ieee address of node 304 without the bus bit set in the sync slot boot information field. When node 304 receives the signal 312, node 304 will see the ieee address of node 302 with the bus bit set. Because the forced master bit is set, node 304 stays in master mode and transmits its own ieee address to node 306. However, node 304 does forward the set bus bit to node 306.

In this way, the configuration 300 has two master nodes because node 302 remains in the busMaster node due to the rxError signal 310 and node 304 remains in master mode due to the forcedMaster event 308. Node 304 continues to forward DTM frames to node 306 but replaces the ieee address of node 302 with its own ieee address. Node 306, therefore, is still in cycleUp and sees the ieee address of node 304 but with the bus bit set. The system continues to operate although a break occurred without requiring rebooting of the configuration 300.

Fig. 9 is a continuation of the events that took place in Fig. 8. It is assumed that the ring configuration 300 is up and running with node 302 being in the busMaster mode and node 304 subjected to the forcedMaster event 308 when the break 309 between nodes 306 and 302 is restored. The bus bit is set for all the nodes . When the break 309 is restored, node 302 no longer receives the rxError signal 310 but remains in the busMaster mode until node 302 has received two valid DTM frames from node 306 to trigger the cycleUp event and the update signal is set . The update signal indicates that the ring expansion is completed. The update signal is set when the first incoming ieee address has been compared with the ieee address of node 302. When node 302 receives a signal 314 with the ieee address of node 304, there will be no ieeeMatch event and node 302 goes into boot mode and clears the bus bit. After node 302 receives two valid DTM frames, the cycleUp event is triggered and node 302 goes into the slave mode so that DTM frames, containing the ieee address of node 304, may pass through node 302. When node 302 goes into the boot mode, node 304 will not receive DTM frames with a valid 125 microsecond spacing so that the node 304 is temporarily not subjected to the cycleUp event until node 302 has switched from the boot mode to the slave mode and forwarded two valid DTM frames to node 304. However, node 304 is still subjected to the forceMaster event 308 and will get cycleUp after node 304 has received two valid DTM frames forwarded by the slave node 302.

Fig. 10 is a double bus configuration 320 that includes a first bus topology 322 in a first direction and a second bus topology 324 in a second opposite direction. The configuration 320 could be a double ring with one or several breaks on the ring. The topology 322 includes nodes 326a, 328a and 330a and the bus topology 324 includes nodes 326b, 328b and 330b. It is assumed that nodes 326a, 326b, nodes 328a, 328b and nodes 330a, 330b, respectively, are located in the same box or room so that they are physically close to one another. On the bus topology 322, node 326a is in the busMaster mode because the node is subject to a rxError signal 332 and node 328a is in the master mode because the forceMaster bit is set due to a forceMaster event 334. Node 330a is in the slave mode. On the bus topology 324, node 330b is in the busMaster mode because the node is subjected to a rxError signal 336 and node 328b is in the master mode because the forceMaster bit is set due to a forceMaster event 338. Node 326b is in the slave mode.

Since node 328a has an useδkHz bit set due to an useδkHz event 340 and node 328b has an useδkHz bit set due to an useδkHz event 342, both nodes may synchronize to an external reference clock. Both nodes 330a and 326b are slave nodes and will therefore follow the synchronization provided by the upstream master nodes 32δa, 32δb, respectively. The bus master nodes 326a and 330b are not subjected to the same external reference clock and they do not follow another master node since they are first on each bus topology. Due to the lack of synchronization, there is a risk that the bus nodes may drift in relation to the other nodes in the configuration 320. However, this synchronization problem may be solved by connecting an δkHz reference clock, as indicated by the dashed lines 344, 346 between the nodes located in the same box or room. If the bus master nodes are connected to and use the same reference clock, synchronization may be achieved for all the nodes on both bus topologies 322. 324.

While the present invention has been described in accordance with preferred compositions and embodiments, it is to be understood that certain substitutions and alterations may be made thereto without departing from the spirit and scope of the following claims.

Claims

We claim :

1. A method for a hardware boot protocol , comprising, providing a ring topology (200, 240, 2δ0, 300) having a first node (204, 244, 264, 304) connected to a second node (206, 246, 286, 306) connected to a third node (202, 242, 282, 302); the first node transmitting a first synchronization signal (210, 252, 292) having a first node address, second node transmitting a second synchronization signal (212, 248, 291, 314) having a second node address and the third node transmitting a third synchronization signal (214, 250, 290, 312) ; the second node receiving the first synchronization signal and going into a boot mode (202) to compare the first node address of the incoming first synchronization signal to the second node address, the second node disallowing frames to pass through the second node while the second node is in the boot mode; the third node receiving the second synchronization signal and going into the boot mode (202) to compare the second node address of the incoming second synchronization signal to the third node address; the first node receiving the third synchronization signal and going into the boot mode (202) to compare the third node address of the incoming third synchronization signal to the first node address; the first node receiving a matching synchronization signal from the third node having the first node address, the first node going from the boot mode to a master wait mode (206) ; while in the master wait mode (206) , the first node transmitting a first frame having the first node address to the second node; while in the boot mode, the second node receiving the first frame and going from the boot mode to a slave mode (210) to permit the first frame through the second node, the second node forwarding the first frame to the third node; the third node receiving the first frame and going from the boot mode to the slave mode to permit the first frame through the third node, the third node forwarding the first frame to the first node; and the first node receiving the first frame and going from the master wait mode to a master mode (228) .

2. The method according to claim 1 wherein the method further comprises the third node receiving an error signal (28δ) , 310) due to a breakage (309) between the second node and the third node, the third node going from the slave mode to a bus master mode (214) , the third node transmitting a second frame having the third node address and a bus bit set.

3. The method according to claim 2 wherein the method further comprises the first node receiving the second frame and determining that the third node address of the second frame is different from the first node address of the first node and that the bus bit is set, the first node going from master mode (22δ) to the slave mode (210) to permit the second frame to pass through the first node.

4. The method according to claim 2 wherein the method further comprises restoring the breakage (309) between the second node and third node, the third node receiving the second frame having the third node address, the third node remaining in the master mode (214) and clearing the bus bit .

5. The method according to claim 1 wherein the method further comprises subjecting the first node to a forced master command (244, 308), the third node receiving an error signal (286, 310) due to a breakage (309) between the second node and the third node, the third node going from the slave mode (210) to a bus master mode (214), the third node transmitting a third frame having the third node address and a bus bit set .

6. The method according to claim 5 wherein the method further comprises the first node receiving the third frame and replacing the third node address of the third frame with the first node address and transmitting the third frame to the second node with the bus bit set .

7. The method according to claim 5 wherein the method further comprises restoring the breakage between the second node and third node, the third node receiving the third frame having the first node address, the third node clearing the bus bit.

8. The method according to claim 7 wherein the method further comprises the third node going to the boot mode (202) .

9. The method according to claim 7 wherein the method further comprises the third node receiving the third frame, the third node going from the boot mode (202) to the slave mode (210) to permit the third frame to pass through the third node .

10. The method according to claim 7 wherein the method further comprises the first node receiving the third frame having the first node address, the first node remaining the master node (228) .