1. Field of the Invention
The present invention relates to a device information acquisition method, device controller, and bridge in an IEEE 1394-based communication network.
2. Description of the Prior Art
The IEEE 1394 standard is a high-speed serial bus standard, which defines methods for main signal transfer and control signal transfer between personal computers, peripheral devices such as printers, hard disks, and image scanners, video devices such as digital video cameras, and audio devices. A network can be constructed by connecting a plurality of devices incorporating IEEE 1394 bus interfaces (to be referred to as 1394 devices hereinafter).
In a bus based on the IEEE 1394 standard (to be simply referred to as a bus hereinafter), when, for example, a 1394 device is connected/disconnected, bus initialization (to be referred to as bus reset hereinafter) is performed, and an ID number (to be referred to as PHY ID hereinafter) is automatically assigned to the 1394 device. The assigned PHY ID is stored in the CSR space and held by each 1394 device. PHY ID assignment is performed every time bus reset occurs, and the value assigned to each 1394 device can dynamically change. Communication between 1394 devices is disabled until PHY ID assignment is completed upon occurrence of bus reset. As a method of performing communication between 1394 devices, a method using asynchronous packets is available.
FIG. 1 is a view conceptually showing a specific example of an asynchronous packet. Referring to FIG. 1, a bus ID which is an ID number defined by the IEEE 1394 standard and assigned to the bus to which a destination 1394 device is connected is written in a destination_bus_ID field 54. For communication to be performed within one bus, this bus ID may be written as “3FFh”. Note that the last letter “h” indicates that the value is hexadecimal. In a destination_physical_ID field 55, the PHY ID assigned to the source 1394 device is written. In a tcode field 56, the value that represents the type of asynchronous packet and is defined by the IEEE 1394 standard is written. In a source_ID field 57, the bus ID of the bus to which the 1394 device is connected is written in the upper 10 bits, and the PHY ID of the source 1394 device is written in the lower 6 bits. In a data field 58, information to be transmitted is written.
Communications using asynchronous packets are classified into a read transaction aiming at reading out the contents of the CSR space of the destination 1394 device, a write transaction aiming at a write, and a lock transaction. Asynchronous packets used in a read transaction are called a read request packet and read response packet. Asynchronous packets used in a write transaction are called a write request packet and write response packet. Asynchronous packets used in a lock transaction are called a lock request packet and lock response packet.
In order to control a 1394 device connected to a bus, it is required to acquire device information indicating what performance the 1394 device has and what control is possible. A method of acquiring such device information is conventionally used by a device controller aiming at controlling a 1394 device when the controller acquires the device information of the 1394 device as a control target, as disclosed in, for example, Japanese Unexamined Patent Publication No. 11-205363.
FIG. 2 is a block diagram showing an example of the arrangement of a conventional device controller. Referring to FIG. 2, a device controller 59 is comprised of a device control section 60, device information management table storage section 61, serial bus management 62, 1394 transaction layer 63, 1394 link layer 64, and 1394 physical layer 65. The device controller 59 acquires device information from a 1394 device connected to the bus before device control operation, and stores the acquired information in the device information management table storage section 61 upon linking it with the PHY ID assigned to each 1394 device. An example of the device information which the destination_physical_ID field 55 acquires from the 1394 device is Configuration ROM, which is defined in IEEE 1394 standard, stored at addresses FFFF FFFF F0000 0400h to FFFF FFFF F0000 07FFh in the CSR space and set in each 1394 device. From this information, the device controller 59 can recognize the performance of the 1394 device, to which a given PHY ID is assigned, control which the device can accept, and the like.
FIG. 3 is a flow chart for explaining operation in a conventional device information acquisition method. The device controller 59 specifies a 1394 device from which no device information has been acquired (step Sa1), and transmits a read request packet to the 1394 device (step Sa2). Upon reception of the read request packet (step Sb1), the 1394 device reads out its own Configuration ROM information (step Sb2), and transmits a read response packet containing the readout contents to the device controller 59 (step Sb3). Upon reception of the read response packet (step Sa3), the device controller 59 acquires the device information of the 1394 device from the received read response packet, and stores it in a management table (device information management table storage section 61) (step Sa4). The device controller 59 then checks whether device information is acquired from all 1394 devices (step Sa5). If information acquisition is not complete, the flow returns to step Sa1 to repeat the above processing. If acquisition of device information from all the 1394 devices connected to the bus is complete, the processing is terminated.
FIG. 4 is a view conceptually showing a specific example of the format of a management table for managing acquired device information. Referring to FIG. 4, in a PHY ID field 66, the value of the PHY ID assigned to a 1394 device is stored. In a device information field 67, the device information acquired from the 1394 device is stored. In controlling the device, the device control section 60 acquires the PHY ID assigned to the 1394 device as a control target from the device information stored in the device information management table storage section 61, and sends out a control signal to the bus through the 1394 transaction layer 63, 1394 link layer 64, and 1394 physical layer 65.
The PHY ID linked to device information may change every time bus reset occurs. Upon detection of bus reset, therefore, the device controller 59 re-acquires device information in accordance with the flow chart described above after a PHY ID is assigned to each 1394 device again, and updates the information stored in the management table (device information management table storage section 61).
An IEEE 1394 bridge for connecting a plurality of buses to each other and performing packet forwarding between different buses is under standardization. Using this IEEE 1394 bridge leads to a larger network based on the IEEE 1394 standard and higher efficiency. IEEE 1394 bridges are being standardized by the IEEE P1394.1 working group. An IEEE 1394 bridge has a plurality of portals and an internal switching fabric for exchanging packets between the portals. The respective portals are connected to different buses.
FIG. 5 is a block diagram showing an example of the arrangement of the IEEE 1394 bridge. Referring to FIG. 5, an IEEE 1394 bridge 68 is comprised of portals 69 to 71 and an internal switching fabric 72. The portals 69 to 71 are respectively connected to buses 73 to 75. The portals 69 to 71 behave as 1394 devices on the buses. When each portal receives a packet to be sent to another bus, the portal temporarily outputs the received packet to the internal switching fabric 72. The internal switching fabric 72 outputs the packets sent from the portals 69 to 71 to the corresponding portals 69 to 71. Upon reception of the packets from the internal switching mechanism 72, the portals 69 to 71 send out the packets to the buses to which they are connected.
As described above, in a network constituted by different buses connected to each other through an IEEE 1394 bridge, even when bus reset occurs in a given bus, initialization and reassignment of a PHY ID are performed in only the bus in which the bus reset has occurred. For this reason, the remaining buses connected through the IEEE 1394 bridge do not recognize the occurrence of the bus reset. Consequently, communication is not interrupted by bus reset that has occurred in another bus. Consider a general network constituted by a plurality of buses using an IEEE 1394 bridge. The IEEE 1394 bridge has the function of selecting a packet, from the asynchronous packets received by a given portal, which is to be sent to another bus, and transferring the packet. An asynchronous packet forwarding method will be described in detail below with reference to the P1394.1 draft standard issued by the P1394.1 working group.
The IEEE 1394 bridge extracts a destination_bus_ID field from a received asynchronous packet and determines by referring to prestored forwarding information whether to forward the received packet to an adjacent bus. As the storage form of forwarding information, a routing map constituted by 1,023-bit strings as shown in, for example, FIG. 6 is available. When a routing map is to be set such that an asynchronous packet whose destination_bus_ID field has a value “n” is forwarded, the value of the upper (n+1)th bit is set to “1”. In the routing map shown in FIG. 6, “1”s are set in the upper 1st, 2nd, and 4th bits.
The conventional device information acquisition method can only acquire the information of a 1394 device connected to the bus to which the self-apparatus is connected and update the acquired device information because no consideration is given to a network constituted by a plurality of buses using an IEEE 1394 bridge. According to the prior art, therefore, in a network constructed by connecting a plurality of buses to each other, the device information of all the connected 1394 devices cannot be entirely acquired. As a consequence, the acquired device information of all the devices cannot be entirely updated in accordance with bus reset and changes in topology.
USPTO Backgrounds
USPTO Backgrounds