Title: Information communication system, information communication method, information signal processing device and information signal processing method, and storage medium
Abstract: When a plurality of information signal processing apparatuses are connected via IEEE 1394 communication control buses, these buses are connected via bridges, and bus reset occurs on a remote bus other than connected buses (step S1501), occurrence of remote bus reset is notified (steps S1502, S1505). Thus, even if bus reset occurs, the consistency of bus reset processing in an upper protocol layer can be ensured to realize normal data communication between buses.
Patent Number: 6,996,112 Issued on 02/07/2006 to Fukunaga, et al.
| Inventors:
|
Fukunaga; Koji (Kanagawa, JP);
Katano; Kiyoshi (Chiba, JP);
Nakamura; Atsushi (Kanagawa, JP)
|
| Assignee:
|
Canon Kabushiki Kaisha (Tokyo, JP)
|
| Appl. No.:
|
843911 |
| Filed:
|
April 30, 2001 |
Foreign Application Priority Data
| Aug 31, 1999[JP] | 11-246725 |
| Aug 31, 1999[JP] | 11-246729 |
| Aug 31, 1999[JP] | 11-246730 |
| Current U.S. Class: |
370/401; 370/475; 710/306 |
| Current Intern'l Class: |
H04L 12/28 (20060101); H04J 3/24 (20060101) |
| Field of Search: |
370/401,400,475,254,389,392
710/100,306,305,311
711/102
709/238,220,221,253
|
References Cited [Referenced By]
U.S. Patent Documents
| 5764930 | Jun., 1998 | Staats.
| |
| 6512767 | Jan., 2003 | Takeda et al.
| |
| 6678781 | Jan., 2004 | Domon.
| |
| 6735619 | May., 2004 | Sawada.
| |
| Foreign Patent Documents |
| 1 208 290 | Feb., 1999 | CN.
| |
| 198 35 668 | Feb., 1999 | DE.
| |
| 0 833 485 | Apr., 1998 | EP.
| |
| 11-68884 | Mar., 1999 | JP.
| |
Other References
Scheel, Dick, "Proposal for change to reset notification/acknowledgement procedure
in P1394.1 draft 0.02", <URL:http://grouper.ieee.org/groups/1394/1/Documents/BR002r00.pdf>,
retrieved Feb. 21, 2002.
Serial Bus reset detection, <URL:http://grouper.ieee.org/groups/1394/1/documents/br003r00.pdf>,
retrieved Feb. 21, 2002.
|
Primary Examiner: Ho; Duc
Attorney, Agent or Firm: Fitzpatrick, Cella, Harper & Scinto
Claims
What is claimed is:
1. A serial bus bridge having at least two portals respectively connected to
different serial buses, comprising:
a detecting unit adapted to detect a bus reset of a serial bus to which the portal
is connected;
a storage unit adapted to store ID information designating a node on a network
which comprises a plurality of serial buses, including serial buses to which said
portals are connected, interconnected via the serial bus bridge;
a receiving unit adapted to receive a control message including the ID information
designating a node on the network, wherein said control message further includes
a registration command or a deletion command,
wherein said serial bus bridge stores the ID information in the control message
into the storage unit if received control message includes the registration command,
and deletes the ID information stored in the storage unit if the received control
message includes the deletion command; and
a transmitting unit adapted to transmit a notice message including a bus ID information,
designating a serial bus in which the detecting unit detected a bus reset, to the
node which is designated by the ID information stored in the storage unit.
2. A terminal apparatus operable as a node on a network which comprises a plurality
of serial buses interconnected via a serial bus bridge, wherein said terminal apparatus
transmits said control message, including ID information which designates a node
on the network, to the portal of the serial bus bridge according to claim 1.
3. A terminal apparatus according to claim 2, wherein the serial buses comply
with IEEE 1394.
4. A terminal apparatus operable as a node on a network which comprises a plurality
of serial buses interconnected via a serial bus bridge, wherein said terminal apparatus
receives a control message, including bus ID information which designates a serial
bus, from the portal of the serial bus bridge according to claim 1.
5. A terminal apparatus according to claim 4, wherein the serial buses comply
with IEEE 1394.
6. A serial bus bridge according to claim 1, wherein the serial buses comply
with IEEE 1394.
7. Computer program streams for a portal included in a serial bus bridge having
at least two portals respectively connected to different serial buses, wherein
said computer program streams enable the serial bus bridge;
detecting function of detecting a bus reset of a serial bus to which the portal
is connected;
storage function of storing ID information designating a node on a network which
comprises a plurality of serial buses, including serial buses to which said portals
are connected, interconnected via the serial bus bridge;
receiving function of receiving a control message including the ID information
designating a node on the network, wherein said control message further includes
a registration command or a deletion command wherein the storage function stores
the ID information in the control message if the received control message includes
the registration command, and the ID information is deleted from the storage of
the storage function if the received control message includes the deletion command; and
a transmitting function of transmitting a notice message including bus ID information,
designating a serial bus in which the detecting function detected a bus reset,
to the node which is designated by the ID information stored by the storage function.
8. A computer-readable storage medium stores computer program streams according
to claim 7.
Description
CROSS REFERENCE TO RELATED APPLICATION
This application is a Rule 53(b) continuation of International Application No.
PCT/JP00/059321, filed Aug. 31, 2000.
TECHNICAL FIELD
The present invention relates to an information signal processing apparatus connected
to a communication control network and an information signal processing method
and, more particularly, to an information signal processing apparatus connected
to an IEEE 1394-compliant communication control bus and an information signal processing method.
Moreover, the present invention relates to an information communication
system having a first communication control network, a second communication network
different from the first communication control network, and a connection device
for enabling communication between the first communication control network and
the second communication network, and an information communication method and,
more particularly, to an information communication system connected by, e.g., an
IEEE 1394 serial interface, and an information communication method.
BACKGROUND ART
A serial bus interface such as an IEEE 1394 interface can simultaneously connect
a plurality of devices such as a DV (Digital Video), DC (Digital Camera), host
computer, scanner, and VTR, unlike a so-called centronics parallel interface for
one-to-one connection between a host computer and a terminal (device). This serial
bus interface can realize a data communication network system or home network constructed
by connecting a plurality of devices based on an IEEE 1394 standard as one of serial
bus standards.
Various devices are connected to these networks, and many unspecified devices
of different manufacturers may be connected.
According to IEEE 1394-1995, a maximum of 63 nodes can be connected to
one 1394 bus (to be referred to as a "local bus" hereinafter) by an IEEE 1394 serial
bus address designation method. If a 10-bit address space is defined for designation
of a bus ID for specifying a bus, 1,023 buses can be connected to each other. In
a cable environment, a cable between information signal processing apparatuses
(to be referred to as "nodes" hereinafter) serving as devices is 4.5 m long at maximum.
To solve technical limitations posed when more than a connectable maximum of
63
devices are to be connected via an IEEE 1394 bus or a plurality of IEEE 1394 buses
located at remote places are to be connected to each other, a device called a "1394
bridge" is generally used. By connecting a plurality of IEEE 1394 local buses via
1394 bridges, devices connected to the different local buses can communicate data.
In IEEE 1394, when the bus configuration changes by, e.g., an increase/decrease
in the number of nodes upon insertion/removal of a device node, ON/OFF operation
of the power supply, activation by hardware detection owing to a network error,
or a direct instruction under host control from a protocol, a new network configuration
must be recognized. In this case, each node which has detected the change transmits
a bus reset signal to execute a mode in which a new network configuration is recognized.
This bus reset signal is transmitted to another nodes on the local bus. After
all the nodes detect the bus reset signal, bus reset starts. When bus reset starts,
data transfer is temporarily suspended. After the bus reset is finished, the suspended
data transfer is restarted in a new network configuration.
In a device connected to an IEEE 1394 bus, a physical layer and data link layer
in a transfer protocol are defined by IEEE 1394. As for the upper layer, various
upper protocols are defined and implemented in accordance with the intended use
and application of a device.
The upper protocols of IEEE 1394 determine a connection establishment method
in communicating data with a specific device using an IEEE 1394 bus, a resource
management method, an application data transmission/reception method, a connection
cancellation method at the end of data transfer, a resume method in bus reset which
is a feature of IEEE 1394 in addition to resume from an error, and protocols before
and after bus reset.
A DPP (Direct Print Protocol) as an example of the upper protocols defines that
when bus reset occurs, a device which establishes a connection at the start of
data transfer issues a reset command, and the other device returns an acknowledge
upon reception of the command, thereby restarting data transfer.
An AV/C protocol defines that when bus reset occurs before a node which has received
an AV/C command issued by the other node sends a response, the command itself becomes
invalid, and the command issuing node cannot expect any response.
In this manner, when IEEE 1394 bus reset occurs, data transfer is temporarily
suspended, and the network topology changes before and after bus reset. An upper
protocol layer must cope with such a status change, so that the protocol standard
defines procedures on both the data transmitting and receiving sides upon occurrence
of bus reset. This definition allows continuing data transfer between devices which
implement the same upper protocol without any influence because, if bus reset occurs,
the data transmitting and receiving sides execute the defined appropriate processes
in data transfer.
However, if bus reset occurs on one local bus connected to another IEEE
1394 bus, the IEEE 1394 bridge does not transfer the bus reset signal to the other
local bus (to be referred to as a "remote bus" hereinafter), i.e., does not propagate
bus reset between the busses. Therefore, an error may occur in data transfer between
nodes via the bridge.
When data is transferred between devices on the same local bus using the above-mentioned
upper protocols, bus reset is transmitted to all the nodes on the local bus. Accordingly,
both the data transmission and reception nodes can detect bus reset, and can appropriately
execute bus reset procedures by the upper protocols.
However, if bus reset occurs on one local bus during data transfer from
a data transmission node on the local bus to a data reception node connected to
the other local bus via an IEEE 1394 bridge, the IEEE 1394 bridge does not propagate
bus reset to the other bus. Therefore, the node connected to the remote bus cannot
detect the bus reset, only the device connected to the local bus executes a bus
reset procedure by the upper protocol layer, and the processes between the data
transmitting and receiving sides are inconsistent.
DISCLOSURE OF INVENTION
It is an object of the present invention to provide a communication network system
capable of performing normal data communication between communication control networks
while maintaining the consistency of network configuration update request processing
in an upper protocol layer in a system constituted by connecting a plurality of
communication control networks (e.g., IEEE 1394 buses) via a connection device
(e.g., IEEE 1394 bridge).
It is another object of the present invention to provide a communication network
system capable of performing normal data communication between buses while maintaining
the consistency of bus reset processing in an upper protocol layer in a system
constituted by connecting a plurality of communication control networks (e.g.,
IEEE 1394 buses) via a connection device (e.g., IEEE 1394 bridge).
Other features and advantages of the present invention will be apparent from
the following description taken in conjunction with the accompanying drawings,
in which like reference characters designate the same or similar parts throughout
the figures thereof.
BRIEF DESCRIPTION OF DRAWINGS
FIG. 1 is a block diagram showing the schematic configuration of the first embodiment
according to the present invention;
FIG. 2 is a view showing an example of a 1394 network configuration in the first embodiment;
FIG. 3 is a block diagram for explaining the architecture of an IEEE 1394 standard
in the first embodiment;
FIG. 4 is a view showing services which can be provided by a link layer in the
first embodiment;
FIG. 5 is a view showing services which can be provided by a transaction layer
in the first embodiment;
FIG. 6 is a view for explaining the address space of a 1394 serial bus in the
first embodiment;
FIG. 7 is a view showing an example of the address and function of information
stored in a CSR core register in the first embodiment;
FIG. 8 is a view showing an example of the address and function of information
stored in a serial bus register in the first embodiment;
FIG. 9 is a view showing a structure of a configuration ROM of the minimum format
in the first embodiment;
FIG. 10 is a view showing a structure of a configuration ROM of the general
format in the first embodiment;
FIG. 11 is a view showing an example of the address and function of information
stored in the serial bus register of a unit space in the first embodiment;
FIG. 12 is a sectional view showing a 1394 serial bus cable in the first embodiment;
FIG. 13 is a view showing a DS-link coding scheme in the first embodiment;
FIG. 14 is a view for explaining a state after activation of bus reset in the
1394 network in the first embodiment;
FIG. 15 is a flow chart showing processing from the start of bus reset to assignment
of a node ID in the first embodiment;
FIG. 16 is a flow chart showing details of parent-child relationship declaration
processing in step S1502 shown in FIG. 15;
FIG. 17 is a flow chart showing details of node ID setting processing in step
S1505 shown in FIG. 15;
FIG. 18 is a view showing a format of a self ID packet in the first embodiment;
FIGS. 19A and 19B are views for explaining arbitration in the 1394 network
in the first embodiment;
FIG. 20 is a view for explaining a case wherein asynchronous and isochronous
transfer modes are mixed in one communication cycle in the first embodiment;
FIG. 21 is a view showing the format of a communication packet transferred based
on the isochronous transfer mode in the first embodiment;
FIG. 22 is a view showing the format of a communication packet based on the
asynchronous transfer mode in the first embodiment;
FIG. 23 is a block diagram showing the arrangement of the 1394 interface block
of a 1394 node in the first embodiment;
FIG. 24 is a view showing the format of storage data in the configuration ROM
in the first embodiment;
FIG. 25 is a view showing the address space of the 1394 node in the first embodiment;
FIG. 26 is a view showing the serial bus register area of the 1394 node in the
first embodiment;
FIG. 27 is a view showing the REMOTE
—BUS
—RESET
register of the 1394 node in the first embodiment;
FIG. 28 is a view showing communication control procedures complying with a
DPP protocol in the first embodiment;
FIG. 29 is a view showing communication control procedures complying with an
AV/C protocol in the first embodiment;
FIG. 30 is a view showing the serial bus register area of a 1394 node in the
second embodiment according to the present invention;
FIG. 31 is a view showing details of the NOTIFY
—BUS
—RESET
register of the 1394 node in the second embodiment;
FIG. 32 is a block diagram showing the detailed arrangement of a 1394 bridge
in the second embodiment;
FIG. 33 is a view showing communication control procedures complying with a
DPP protocol in the second embodiment;
FIG. 34 is a view showing communication control procedures complying with an
AV/C protocol in the second embodiment;
FIG. 35 is a view showing communication control procedures complying with a
DPP protocol in the third embodiment according to the present invention;
FIG. 36 is a block diagram showing the configuration of the fourth embodiment
according to the present invention;
FIG. 37 is a view showing communication control procedures complying with a
DPP protocol in the fourth embodiment;
FIG. 38 is a view showing communication control procedures complying with an
AV/C protocol in the fourth embodiment;
FIG. 39 is a view showing the serial bus register area of a 1394 node in the
fifth embodiment according to the present invention;
FIG. 40 is a view showing communication control procedures complying with a
DPP protocol in the fifth embodiment; and
FIG. 41 is a view showing communication control procedures complying with an
AV/C protocol in the fifth embodiment.
BEST MODE FOR CARRYING OUT THE INVENTION
Preferred embodiments of present invention will be described in detail
below with reference to the accompanying drawings.
[First Embodiment]
FIG. 1 is a block diagram showing the schematic configuration of the first embodiment
according to the present invention. The first embodiment is constituted by two
IEEE 1394-compliant local buses A
102 and B
103, and a 1394 bridge
101 for connecting them. FIG. 1 shows two local buses, but a larger number
of local buses can be connected via 1394 bridge devices.
Each local bus has a bus ID as bus specifying information for specifying each
local bus. The local bus A
102 represented by a bus ID "3FDh" and the local
bus B
103 represented by a bus ID "3FEh" are connected to a plurality of
device nodes.
In the first embodiment shown in FIG. 1, a node A
1 (
104) connected
to the local bus A
102 is a digital still camera, and a node A
2 (
105)
is a digital video cam coder. A node B
1 (
106) connected to the local
bus B
103 is a printer, and a node B
2 (
107) is a digital video
cam coder.
The node A
1 (
104) implements a direct print protocol standardized
in advance as an upper protocol, whereas the node A
2 (
105) implements
a standardized AV/C protocol.
Similarly, the node B
1 (
106) connected to the local bus
B
103 implements a direct print protocol as an upper protocol, whereas the
node B
2 (
107) implements an AV/C protocol.
<Technical Overview of IEEE 1394 Standard>
The technique of the IEEE 1394-1995 standard applied to the digital interface
shown in FIG. 1 of the first embodiment will be explained. Details of the IEEE
1394-1995 standard (to be referred to as the "IEEE 1394 standard" hereinafter)
are described in "IEEE Standard for a High Performance Serial Bus" published by
IEEE (The Instituted of Electrical and Electronics Engineers, Inc.), Aug. 30, 1996.
(1) Overview
FIG. 2 shows an example of a communication system (to be referred to as a "1394
network") constituted by nodes having digital interfaces complying with the IEEE
1394 standard (to be referred to as "1394 interfaces"). The 1394 network constitutes
a bus type network capable of communicating serial data.
In FIG. 2, nodes A to H are connected via an IEEE 1394 standard-compliant communication
cable. These nodes A to H are electronic devices such as a PC (Personal Computer),
digital VTR (Video Tape Recorder), DVD (Digital Video Disc) player, digital camera,
hard disk drive, and monitor.
The connection method of the 1394 network may include both a daisy chain method
and node branch method, and enables connection with a high degree of flexibility.
The 1394 network automatically performs bus reset when, e.g., an existing device
is removed, a new device is added, or an existing device is turned on/off. By performing
this bus reset, the 1394 network can automatically recognize a new configuration
and assign ID information to each device. This function allows the 1394 network
to always recognize the network configuration.
The 1394 network also has a function of relaying data transferred from another
device. This function allows all the devices to grasp the operation status of the bus.
The 1394 network has a function called plug & play. This function allows the
1394 network to automatically recognize connected devices by only connecting them
without turning off all the devices.
The 1394 network copes with data transfer speeds of 100/200/400 Mbps. A device
having a higher data transfer speed can support a lower data transfer speed, so
that devices having different data transfer speeds can be connected.
The 1394 network further copes with two different data transfer schemes (i.e.,
asynchronous and isochronous transfer modes).
The asynchronous transfer mode is effective in transferring data (i.e., a control
signal and file data) which should be asynchronously transferred if necessary.
The isochronous transfer mode is effective in transferring data (i.e., video data
and audio data) which should be successively transferred by a predetermined amount
at a constant data transfer speed.
The asynchronous and isochronous transfer modes can be mixed in each communication
cycle (one cycle is generally 125 μS). Each transfer mode is executed after
transfer of a cycle start packet (to be referred to as a "CSP") representing the
start of the cycle.
In each communication cycle period, the isochronous transfer mode has higher
priority
than that of the asynchronous transfer mode. The transfer band of the isochronous
transfer mode is ensured in each communication cycle.
(2) Architecture
The architecture of the IEEE 1394 standard will be described with reference to
FIG. 3. FIG. 3 is a block diagram showing the architecture of the IEEE 1394 standard
in the first embodiment.
The building elements of the IEEE 1394 interface will be explained. The IEEE
1394 interface is functionally made up of a plurality of layers (hierarchies).
In FIG. 3, the IEEE 1394 interface is connected to the IEEE 1394 interface of another
node via an IEEE 1394 standard-compliant communication cable
301. The IEEE
1394 interface has one or more communication ports
302, and each communication
port
302 is connected to a physical layer
303 included in hardware.
In FIG. 3, the hardware is comprised of the physical layer
303 and a link
layer
304. The physical layer
303 performs a physical and electrical
interface with another node, detection of bus reset and its processing, encoding/decoding
of input and output signals, and arbitration of bus access. The link layer
304
performs generation and transmission/reception of a communication packet, and control
of the cycle timer.
In FIG. 3, the firmware includes a transaction layer
305 and serial bus
management
306. The transaction layer
305 manages the asynchronous
transfer mode, and provides various transactions (read, write, and lock). The serial
bus management
306 provides a function of controlling the self node, managing
the connection state of the self node, managing the ID information of the self
node, and managing the resource of the serial bus network on the basis of a CSR
architecture (to be described later).
The hardware
303 and
304 and the firmware
305 and
306
substantially constitute a 1394 interface. The basic configuration is defined by
the IEEE 1394 standard.
An application layer
307 included in the software changes depending on
application software to be used, and controls how to communicate data on the network.
For example, for moving picture data of a digital VTR, the application layer
307
is defined by a communication protocol such as an AV/C protocol.
(2-1) Function of Link Layer
304
FIG. 4 is a view showing services which can be provided by the link layer
304.
In FIG. 4, the link layer
304 provides the following four services:
{circle around (1)} Link request (LK—DATA.request) for
requesting transfer of a predetermined packet of a response node
{circle around (2)} Link indication (LK—DATA.indication)
for indicating reception of a predetermined packet to a response node
{circle around (3)} Link response (LK—DATA.response) representing
reception of an acknowledge from a response node
{circle around (4)} Link confirmation (LK—DATA.confirmation)
for confirming an acknowledge from a request node
Note that the link response (LK—DATA.response) does not exist
in broadcast communication and the transfer of an isochronous packet.
Based on these services, the link layer
304 realizes the two transfer
schemes, i.e., asynchronous and isochronous transfer modes.
(2-2) Function of Transaction Layer
305
FIG. 5 is a view showing services which can be provided by the transaction layer
305. In FIG. 5, the transaction layer
305 provides the following
four services:
{circle around (1)} Transaction request (TR—DATA.request)
for requesting a predetermined transaction of a response node
{circle around (2)} Transaction indication (TR—DATA.indication)
for indicating reception of a predetermined transaction request to a response node
{circle around (3)} Transaction response (TR—DATA.response)
representing reception of state information (including data for write and lock)
from a response node
{circle around (4)} Transaction confirmation (TR—DATA.confirmation)
for confirming state information from a request node
Based on these services, the transaction layer
305 manages asynchronous
transfer, and realizes the following three transactions:
{circle around (1)} Read transaction
{circle around (2)} Write transaction
{circle around (3)} Lock transaction
In {circle around (1)} read transaction, a request node reads information stored
at a specific address of a response node.
In {circle around (2)} write transaction, the request node writes predetermined
information at a specific address of the response node.
In {circle around (3)} lock transaction, the request node transfers reference
data and update data to the response node, compares information at a specific address
of the response node with the reference data, and updates the information at the
specific address to the update data in accordance with the comparison result.
(2-3) Function of Serial Bus Management
306
The serial bus management
306 can provide the following three functions,
i.e., {circle around (1)} node control, {circle around (2)} isochronous resource
manager (to be referred to as an "IRM"), and {circle around (3)} bus manager.
{circle around (1)} Node control provides a function of managing the above-described
layers, and managing asynchronous transfer executed with another node.
{circle around (2)} The IRM provides a function of managing isochronous transfer
executed with another node. More specifically, the IRM manages pieces of information
necessary to assign a transfer bandwidth and a channel number, and provides these
pieces of information to another node.
The IRM exists only on a local bus, and is dynamically selected from other candidates
(nodes having the IRM function) every bus reset. The IRM may provide some of functions
(connection configuration management, power supply management, speed information
management, and the like) which can be provided by the bus manager (to be described below).
{circle around (3)} The bus manager has the IRM function, and provides a
more advanced bus management function than the IRM.
More specifically, the bus manager has a function of performing more advanced
power supply management (manage, for each node, information representing whether
power can be supplied via a communication cable and whether power must be supplied),
more advanced speed information management (manage the maximum transfer speed between
nodes), more advanced connection configuration management (create a topology map),
and bus optimization based on these pieces of management information, and providing
the pieces of information to another node.
The bus manager can provide an application with a service for controlling a serial
bus network. This service includes a serial bus control request (SB
—CONTROL.request),
serial bus event control confirmation (SB
—CONTROL.confirmation),
and serial bus event indication (SB
—CONTROL.indication).
The serial bus control request (SB
—CONTROL.request) is a service
of requesting bus reset by an application.
The serial bus event control confirmation (SB
—CONTROL.confirmation)
is a service of confirming the serial bus control request (SB
—CONTROL.request)
for the application. The serial bus event indication (SB
—CONTROL.indication)
is a service of indicating an asynchronously generated event to the application.
(3) Description of Addressing
FIG. 6 is a view for explaining an address space in the 1394 interface. The
1394 interface defines a 64-bit address space in accordance with a CSR (Command
and Status Register) architecture complying with ISO/IEC 13213:1994.
In FIG. 6, a 10-bit field
601 is used for an ID number for designating
a predetermined bus, and a 6-bit field
602 is used for an ID number for
designating a predetermined device (node). The upper 16 bits will be called a "node
ID", and each node identifies another node using this node ID. Each node can also
perform communication with an identified partner using this node ID.
The remaining 48-bit field designates an address space (256-Mbyte structure)
of each node. Of this field, a 20-bit field
603 designates a plurality of
areas constituting an address space.
In the field
603, an area "0-0xFFFFD" is called a memory space.
An area "0xFFFFE" is called a private space, and represents addresses freely
usable
by each node. The area "0xFFFFE" is called a register space, and stores information
common to nodes connected to a bus. Each node can use information of the register
space to manage communication between nodes.
A 28-bit field
604 designates an address where information common or unique
to each node is stored.
For example, the first 512 bytes in the register space are used for a CSR architecture
core (CSR core) register. FIG. 7 shows the address and function of information
stored in the CSR core register. The offset in FIG. 7 is a relative position from "0xFFFFF0000000".
The next 512 bytes in FIG. 6 are used for a serial bus register. FIG. 8 shows
the address and function of information stored in the serial bus register. The
offset in FIG. 8 is a relative position from "0xFFFFF0000200".
The next 1,024 bytes in FIG. 6 are used for a configuration ROM. The configuration
ROM has minimum and general formats, and is arranged from "0xFFFFF0000400". FIG.
9 shows a configuration ROM of the minimum format. In FIG. 9, a vender ID is a
24-bit numerical value uniquely assigned to each vendor by IEEE.
FIG. 10 shows a configuration ROM of the general format. In FIG. 10, the vendor
ID is stored in a root directory
1002. A bus inform block
1001 and
root leaf
1005 can hold node unique IDs as unique ID information for identifying
each node.
The node unique ID determines a unique ID capable of specifying one node regardless
of the manufacturer and model. The node unique ID is made up of 64 bits. The upper
24 bits represent a vendor ID, and the lower 48 bits represent information (e.g.,
the manufacturing number of a node) freely settable by the manufacturer of each
node. The node unique ID is used when, for example, a specific node is kept recognized
before and after bus reset.
In FIG. 10 showing the configuration ROM of the general format, the root directory
1002 can hold information about the basic function of a node. Detailed functional
information is stored in subdirectories (unit directories
1004) offset from
the root directory
1002. The unit directories
1004 store, e.g., information
about software units supported by a node. More specifically, the unit directories
1004 hold information about a data transfer protocol for data communication
between nodes, and a command set for defining predetermined communication procedures.
In FIG. 10, a node dependent info directory
1003 can hold information
unique
to a device. The node dependent info directory
1003 is offset from the root
directory
1002.
In FIG. 10, vendor dependent information
1006 can hold information unique
to a vendor which manufactures or sells nodes.
The remaining area is called a unit space, and designates an address where information
unique to each node, e.g., identification information (manufacturer name, model
name, or the like) or use conditions of each device are stored. FIG. 11 shows the
address and function of information stored in the serial bus register of the unit
space. The offset in FIG. 11 is a relative position from "0xFFFFF0000800".
In general, to simplify the design of different types of bus systems, each node
should use only the first 2,048 bytes of the register space. In other words, the
bus system is desirably constituted by 4,096 bytes as a total of the CSR core register,
the serial bus register, the configuration ROM, and the first 2,048 bytes of the
unit space.
(4) Structure of Communication Cable
FIG. 12 is a sectional view showing an IEEE 1394-compliant communication cable.
The communication cable is made up of two twisted-pair signal lines and a power
supply line. This power supply line can supply power even to a device whose main
power supply is turned off, or a device which decreases in power due to a failure.
The power supply voltage flowing through the power supply line is defined as 8
to 40 V, and the current is defined as a maximum of DC 1.5 A.
The two twisted-pair signal lines transmit information signals encoded by a DS-link
(Data/Strobe link) coding scheme. FIG. 13 is a view for explaining the DS-link
coding scheme in the first embodiment.
The DS-link coding scheme shown in FIG. 13 is suitable for high-speed serial
data communication, and requires two twisted-pair lines. One twisted-pair line
transmits a data signal, whereas the other twisted-pair line transmits a strobe
signal. The receiving side can regenerate a clock by exclusive-ORing the data and
strobe signals received from the two signal lines.
The 1394 interface using the DS-link coding scheme attains the following advantages:
{circle around (1)} The transfer efficiency is higher than other coding schemes.
{circle around (2)} The PLL circuit can be omitted to downsize the controller LSI.
{circle around (3)} Information representing an idle state need not be transmitted,
so that the transceiver circuit can easily change to a sleep state to reduce the
power consumption.
(5) Bus Reset Function
The 1394 interface of each node can automatically detect a change in network
connection configuration. In this case, the 1394 network executes processing called
bus reset by the following procedures. A change in connection configuration can
be detected by a change in bias voltage applied to the communication port of each node.
A node which has detected a change in network connection configuration (e.g.,
an
increase/decrease in the number of nodes upon insertion/removal of a node or ON/OFF
operation of a node), or a node which must recognize a new connection configuration
transmits a bus reset signal onto the bus via the 1394 interface.
The 1394 interface of a node which has received the bus reset signal transmits
occurrence of bus reset to its link layer
304, and transfers the bus reset
signal to another node. A node which has received the bus reset signal clears the
recognized network connection configuration and the node ID assigned to each device.
After all the nodes detect the bus reset signal, each node automatically performs
initialization processing (recognition of a new connection configuration and assignment
of a new node ID) accompanying bus reset.
Note that bus reset can be activated not only by a change in connection configuration
described above, but also by directly issuing an instruction from the application
layer
307 to the physical layer
303 under host control.
After bus reset occurs, data transfer is temporarily suspended, and then restarted
in a new network after completion of initialization processing accompanying bus reset.
(6) Description of Sequence After Occurrence of Bus Reset
After bus reset occurs, the 1394 interface of each node automatically executes
recognition of a new connection configuration and assignment of a new node ID.
A basic sequence from the start of bus reset to assignment processing of a node
ID will be explained with reference to FIGS. 14 to 16.
FIG. 14 is a view for explaining a state after occurrence of bus reset in the
1394 network of FIG. 2.
In FIG. 14, node A comprises one communication port; node B, two communication
ports; node C, two communication ports; node D, three communication ports; node
E, one communication port; and node F, one communication port. The communication
port of each node has a port number for identifying each port.
Processing from the start of bus reset to assignment of a node ID in FIG.
14 will be explained with reference to the flow chart of FIG. 15. FIG. 15 is a
flow chart showing processing from the start of bus reset to assignment of a node
ID in the first embodiment.
Nodes A to F shown in FIG. 14 that constitute a 1394 network always monitor
whether bus reset occurs, as shown in step S
1501. If a node which has detected
a change in connection configuration outputs a bus reset signal, each node detects
bus reset to execute processing from step S
1502.
If bus reset is detected, the flow advances from step S
1501 to step S
1502,
and respective nodes declare parent-child relationships between their communication
ports after occurrence of bus reset. In step S
1503, whether parent-child
relationships between all the nodes are determined is checked. If NO in step S
1503,
the flow returns to step S
1502, and each node repeats processing in step
S
1502 until parent-child relationships between all the nodes are determined.
After parent-child relationships between all the nodes are determined, the
flow shifts from step S
1503 to step S
1504. In step S
1504,
the 1394 network determines a node, i.e., root which performs network arbitration.
After the root is determined, the flow shifts to step S
1505, and the 1394
interface of each node executes an operation of automatically setting the self
node ID. In step S
1506, whether node IDs have been set for all the nodes
to complete ID setting processing is checked. If NO in step S
1506, the flow
returns to step S
1505, and each node sets an ID for the next node based
on predetermined procedures.
After node IDs are set for all the nodes, the flow advances from step S
1506
to step S
1507, and each node executes isochronous transfer or asynchronous
transfer. After data transfer ends, the 1394 interface of each node returns to
step S
1501 to monitor bus reset.
By the above procedures, the 1394 interface of each node can automatically execute
recognition of a new connection configuration and assignment of a new node ID every
time bus reset occurs.
(7) Determination of Parent-child Relationship
Details of parent-child relationship declaration processing (i.e., processing
of recognizing parent-child relationships between nodes) in step S
1502 shown
in FIG. 15 will be described with reference to the flow chart of FIG. 16. FIG.
16 is a flow chart showing details of parent-child relationship declaration processing
in step S
1502 shown in FIG. 15 in the first embodiment.
In parent-child relationship declaration processing of the first embodiment,
nodes
A to F on the 1394 network confirm the connection states (connection or disconnection)
of the self communication ports upon occurrence of bus reset in step S
1601
shown in FIG. 16. After confirming the connection state of the communication port,
each node counts in step S
1602 the number of communication ports (to be
referred to as connected ports) connected to other nodes, and checks whether the
number of connected ports is one.
If the number of connected ports is one in step S
1602, the flow shifts
to step S
1603, and the node recognizes itself as a "leaf". The "leaf" means
a node connected to only one node. In step S
1604, the node serving as a
leaf declares a "child" to a node connected to the connected port. At this time,
the leaf recognizes that the connected port is a "parent port (communication port
connected to a parent node)". After that, the flow advances to step S
1611.
Parent-child relationships are sequentially declared between a branch
and a leaf serving as a network terminal end, and then between branches. The parent-child
relationships between nodes are determined in the order of a communication port
which can make a declaration early. A communication port which declares a child
is recognized as a "parent port" between nodes, and a communication port which
has received the declaration is recognized as a "child port (communication port
connected to a child node)". For example, in FIG. 14, nodes A, E, and F recognize
themselves as leaves, and declare child-parent relationships. Then, nodes A and
B are determined to be a child and parent; nodes E and D, a child and parent; and
nodes F and D, a child and parent.
If the number of connected ports is not one but two or more as a result of processing
in step S
1602, the flow shifts to step S
1605, and the node recognizes
itself as a "branch". The "branch" means a node connected to two or more nodes.
In step S
1606, the node serving as a branch receives declaration of a parent-child
relationship from a node at each connected port. The connected port which has received
the declaration is recognized as a "child port".
After one connected port is recognized as a "child port", the flow advances
to step S
1607, and the branch detects whether there are two or more connected
ports (i.e., undefined ports) for which parent-child relationships have not been
determined yet. If YES in step S
1607, the flow returns to processing in
step S
1606, and the branch receives declaration of a parent-child relationship
from a node at each connected port again.
If NO in step S
1607, the flow shifts to step S
1608, and the branch
checks whether only one undefined port exists. If YES in step S
1608, the
branch recognizes the undefined port as a "parent port", and declares a "child"
to a node connected to the port in step S
1609. Then, the flow advances to
step S
1611.
The branch cannot declare a child to another node until the number of remaining
undefined ports decreases to one. For example, in the configuration of FIG. 14,
nodes B, C, and D recognize themselves as branches, and receive declarations from
leaves or other branches. Node D declares a parent-child relationship to node C
after parent-child relationships between D and E and between D and F are determined.
Node C which has received the declaration from node D declares a parent-child relationship
to node B.
If NO in step S
1608 (i.e., all the connected ports of the branch are parent
ports), the flow shifts to step S
1610, and the branch recognizes itself
as a root. For example, in FIG. 14, node B in which all the connected ports are
parent ports is recognized by other nodes to be a root for arbitrating communication
on the 1394 network.
In this case, node B is determined to be a root. If the timing at which node B
declares a parent-child relationship is earlier than the timing at which node C
declares a parent-child relationship, another node may become a root. Hence, even
the same network configuration does not always use the same node as a root.
After the parent-child relationships of all the connected ports are declared,
each node can recognize the connection configuration of the 1394 network as a hierarchical
structure (tree structure). The declarations at all the connected ports end in
step S
1611, and the flow returns to the main routine. Note that the parent
node is an upper node in the hierarchical structure, and the child node is a lower
node in the hierarchical structure.
(8) Assignment of Node ID
Node ID setting processing (i.e., processing of automatically assigning the
node ID of each node) in step S
1505 shown in FIG. 15 will be described in
detail with reference to FIG. 17. FIG. 17 is a flow chart showing details of node
ID setting processing in step S
1505 of FIG. 15. The node ID is made up of
a bus number and node number. In the first embodiment, respective nodes are connected
to the same bus, and have the same bus number.
In node ID setting processing of the first embodiment, the root gives node ID
setting permission to a communication port having the smallest number among child
ports connected to nodes whose node IDs have not been set yet. In FIG. 17, the
root sets the node IDs of all the nodes connected to a child port having the smallest
number, determines that the child port has been set, and performs the same control
for a child port having the second smallest number. After the IDs of all the nodes
connected to child ports are set, the root sets the self node ID. Node numbers
contained in node IDs are basically sequentially assigned as 0, 1, 2, . . . to
leaves and branches. Thus, the root has the largest node number.
A node which has received the setting permission in step S
1701 checks
in
step S
1702 whether a child port including a node whose node ID has not been
set yet exists in the self child ports. If NO in step S
1702, the flow shifts
to step S
1705.
If YES in step S
1702, the flow advances to step S
1703, and the
node
which has received setting permission gives setting permission to a node directly
connected to the child port (child port having the smallest number). In step S
1704,
the node which has received setting permission checks whether a child port including
a node whose node ID has not been set yet exists in the self child ports. If YES
in step S
1704, the flow returns to step S
1703, and the node gives
setting permission to a child port having the smallest number.
If NO in step S
1704, the flow shifts to step S
1705.
In this way, if a child port including an unset node is not detected in step
S
1702
or S
1704, the flow shifts to step S
1705, and the node which has received
setting permission sets the self node ID. In step S
1706, the node which
has set the self node ID broadcasts a self ID packet containing information about
its node number and the connection state of the communication port. "Broadcast"
means to transfer a communication packet of a given node to many unspecified nodes
constituting a 1394 network.
Each node can receive this self ID packet to recognize a node number assigned
to each node, and can recognize the assigned node number. For example, in FIG.
14, node B serving as a root gives node ID setting permission to node A connected
to a communication port having the smallest port number "#1". Node A assigns "No.
0" as its node number, and sets a node ID made up of a bus number and the node
number. Then, node A broadcasts a self ID packet containing the node number.
FIG. 18 shows a format of a self ID packet output in step S
1706. In FIG.
18, reference numeral
1801 denotes a field for storing the node number of
a node which has sent a self ID packet;
1802, a field for storing information
about a compatible transfer speed;
1803, a field representing the presence/absence
of a bus management function (the presence/absence of a bus manager ability); and
1804, a field for storing information about power consumption and supply characteristics.
In FIG. 18, reference numeral
1805 denotes a field for storing information
about the connection state of a communication port having a port number "#0" (connection,
disconnection, parent-child relationship of a communication port, and the like);
1806, a field for storing information about the connection state of a communication
port having a port number "#1" (connection, disconnection, parent-child relationship
of a communication port, and the like); and
1807, a field for storing information
about the connection state of a communication port having a port number "#2" (connection,
disconnection, parent-child relationship of a communication port, and the like).
When a node which sends a self ID packet has a bus manager ability, a contender
bit in the field
1803 is set to "1"; otherwise, to "0".
The bus manager is a node having a function of performing, based on various pieces
of information contained in the above-mentioned self ID packet, bus power supply
management (manage, for each node, information representing whether power can be
supplied via a communication cable and whether power must be supplied), speed information
management (manage the maximum transfer speed between nodes from information about
a compatible transfer speed of each node), topology map information management
(manage the network connection configuration from parent-child relationship information
of a communication port), and bus optimization based on topology map information,
and a function of providing these pieces of information to other nodes. These functions
allow the node serving as a bus manager to manage the bus over the 1394 network.
In processing of FIG. 17, a node which has set a node ID after processing in
step
S
1706 checks in step S
1707 whether a parent node exists. If YES in
step S
1707, the flow returns to step S
1702, and the parent node executes
processing from step S
1702, and gives permission to a node whose node ID
has not been set yet.
If NO in step S
1707, the node is determined to be a root. The flow shifts
to step S
1708, and the node serving as a root checks whether node IDs are
set for nodes connected to all the child ports. If ID setting processing for all
the nodes is not completed in step S
1708 (NO), the flow returns to step
S
1701, and the root gives ID setting permission to a child port having the
smallest number among child ports including the node. Then, processing after step
S
1702 is executed.
If YES in step S
1708, the flow shifts to step S
1709, and the root
sets the self node ID. After setting the node ID, the root broadcasts a self ID
packet in step S
1710. Then, the flow returns to the main routine.
By this processing, the 1394 network can automatically assign a node ID to each node.
If a plurality of nodes have a bus manager ability after node ID setting processing,
a node having the largest node number serves as a bus manager. That is, when a
root having the largest node number in the network has a bus manager function,
the root serves as a bus manager.
If, however, the root does not have this function, a node having the largest
node number next to the root serves as a bus manager. Which node becomes a bus
manager can be grasped by checking the contender bit
1803 in a self ID packet
broadcasted by each node.
(9) Arbitration Function
FIGS. 19A and 19B are views for explaining arbitration in the 1394 network
in the first embodiment shown in FIG. 1.
The 1394 network always performs bus access arbitration prior to data transfer.
The 1394 network is a logical bus type network, and can transfer the same communication
packet to all the nodes in the network by relaying a communication packet transferred
from each node to another node. To prevent collision of communication packets,
arbitration must be executed, which allows only one node to transfer a packet at
given time.
FIG. 19A is a view for explaining a case wherein nodes B and F issue bus access requests.
When arbitration starts, nodes B and F issue bus access requests to their parents.
A parent (i.e., node C) which has received the request from node B relays the bus
access request to its parent node (i.e., node D). This request is finally sent
to a root (node D) which finally executes arbitration.
The root which has received the bus access requests determines which node can
use the bus. This arbitration operation can be done by only a node serving as a
root, and a node which wins arbitration is permitted to use the bus.
FIG. 19B is a view showing a case wherein a request from node F is permitted,
and a request from node B is denied.
The root transmits a DP (Data Prefix) packet to a node which loses in arbitration,
and notifies the node of denial. The denied node holds a bus access request until
the next arbitration.
By controlling arbitration, the 1394 network can manage bus access.
(10) Communication Cycle
In the first embodiment, the asynchronous and isochronous transfer modes can
be
mixed in time division in each communication cycle period. In general, the communication
cycle period is 125 μS long.
FIG. 20 is a view for explaining a case wherein the asynchronous and isochronous
transfer modes are mixed in one communication cycle.
In the first embodiment, the isochronous transfer mode is executed preferentially
to the asynchronous transfer mode. This is because an idle period (subaction gap)
necessary for activating asynchronous transfer after a cycle start packet is set
longer than an idle period (isochronous gap) necessary for activating isochronous
transfer. Thus, isochronous transfer is executed preferentially to asynchronous transfer.
In FIG. 20, a cycle start packet (to be referred to as a "CSP" hereinafter) is
transferred from a predetermined node at the start of each communication cycle.
Each node can count the same time as another node by adjusting the time using the CSP.
(11) Isochronous Transfer Mode
The isochronous transfer mode is an isochronous type transfer scheme. Isochronous
mode transfer can be executed in a predetermined period after the start of a communication
cycle. The isochronous transfer mode is always executed every cycle in order to
maintain real-time transfer.
The isochronous transfer mode is a transfer mode suitable for transfer of data
such as moving picture data or audio data which requires real-time transfer. The
isochronous transfer mode is broadcasting communication, unlike one-to-one communication
in the asynchronous transfer mode. That is, a packet sent from a given node is
transferred to all the nodes on the network. Note that isochronous transfer does
not use any ack (acknowledge).
In FIG. 20, channel e (ch e), channel s (ch s), and channel k (ch k) represent
periods during which nodes perform isochronous transfer. The 1394 interface uses
different channel numbers in order to discriminate a plurality of different isochronous
transfer operations. This enables isochronous transfer between a plurality of nodes.
In this case, the channel number does not specify a transmission destination, but
only gives a logical number to data.
The isochronous gap shown in FIG. 20 represents a bus idle state. Upon the lapse
of a predetermined time in this idle state, a node which desires isochronous transfer
determines that it can use the bus, and executes arbitration.
FIG. 21 shows the format of a communication packet transferred based on the
isochronous transfer mode in the first embodiment. The communication packet transferred
based on the isochronous transfer mode will be called an isochronous packet.
In FIG. 21, the isochronous packet is made up of a header
2101, header
CRC
2102, data
2103, and data CRC
2104.
The header
2101 includes a field
2105 for storing the data length
of the data
2103, a field
2106 for storing format information of
the isochronous packet, a field
2107 for stori
