U.S. patent application number 11/640868 was filed with the patent office on 2007-08-02 for multi-initiator control unit and method.
This patent application is currently assigned to Matsushita Electric Industrial Co., Ltd.. Invention is credited to Hirotaka Ito, Yoshihiro Tabira.
Application Number | 20070180336 11/640868 |
Document ID | / |
Family ID | 18840280 |
Filed Date | 2007-08-02 |
United States Patent
Application |
20070180336 |
Kind Code |
A1 |
Ito; Hirotaka ; et
al. |
August 2, 2007 |
Multi-initiator control unit and method
Abstract
The multi-initiator control unit for performing packet-unit
communication with each of a plurality of devices connected via a
transmission line includes: a packet filter for analyzing a
received packet and outputting the results; a plurality of command
control circuits each for controlling a command processing sequence
performed with the corresponding device; a multi-control circuit
for giving sequence execution permission to one of the plurality of
command control circuits; and a packet processing circuit for
generating a packet containing information output by the
permission-given command control circuit and outputting the packet
for transmission, and also outputting a received packet according
to the analysis results output by the packet filter.
Inventors: |
Ito; Hirotaka; (Osaka,
JP) ; Tabira; Yoshihiro; (Osaka, JP) |
Correspondence
Address: |
MCDERMOTT WILL & EMERY LLP
600 13TH STREET, N.W.
WASHINGTON
DC
20005-3096
US
|
Assignee: |
Matsushita Electric Industrial Co.,
Ltd.
Osaka
JP
|
Family ID: |
18840280 |
Appl. No.: |
11/640868 |
Filed: |
December 19, 2006 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
09998693 |
Dec 3, 2001 |
7164689 |
|
|
11640868 |
Dec 19, 2006 |
|
|
|
Current U.S.
Class: |
714/54 |
Current CPC
Class: |
H04L 12/40071 20130101;
H04L 69/22 20130101; H04L 12/6418 20130101 |
Class at
Publication: |
714/054 |
International
Class: |
G06F 11/00 20060101
G06F011/00 |
Foreign Application Data
Date |
Code |
Application Number |
Dec 5, 2000 |
JP |
2000-370375 |
Claims
1. A multi-initiator control unit for performing packet-unit
communication with each of a plurality of devices connected via a
transmission line, the multi-initiator control unit comprising: a
link core circuit for transmitting a packet to be transmitted to
the transmission line, and also receiving a packet from the
transmission line, performing error detection, and outputting the
error-detected packet; a packet filter for analyzing the packet
received by the link core circuit and outputting the results; a
plurality of command control circuits each for controlling a
command processing sequence performed with the corresponding
device; a multi-control circuit for giving sequence execution
permission to one of the plurality of command control circuits; a
packet processing circuit for generating a packet containing
information output by the permission-given command control circuit
as the packet to be transmitted and outputting the packet to the
link core circuit for transmission, and also outputting the packet
received and output by the link core circuit according to the
analysis results output by the packet filter; and a CPU for
executing a command contained in the packet output by the packet
processing circuit.
2. (canceled)
3. The multi-initiator control unit of claim 1, wherein each of the
plurality of command control circuits stores information in a
command fetch request packet transmitted from the corresponding
device, and performs command fetch operation for the device once
the sequence execution permission is given to the command control
circuit by the multi-control circuit.
4. The multi-initiator control unit of claim 3, wherein each of the
plurality of command control circuits receives a command fetch
request from the corresponding device even during execution of a
data transfer processing sequence.
5. (canceled)
6. The multi-initiator control unit of claim 1, wherein the
multi-control circuit selects one of the plurality of devices in a
predetermined order every time a command processing sequence is
terminated and gives the sequence execution permission to the
command control circuit among the plurality of command control
circuit corresponding to the selected device.
7. The multi-initiator control unit of claim 1, further comprising
a transfer control circuit for controlling data transfer between
the packet processing circuit and the outside of the
multi-initiator control unit, wherein the packet processing circuit
retrieves data to be transferred from the packet output by the
packet filter and outputs the data to the transfer control circuit,
and also generates a packet containing data transferred to the
transfer control circuit and outputs the packet to the link core
circuit.
8. The multi-initiator control unit of claim 1, wherein the CPU is
allowed to give sequence execution permission to the plurality of
command control circuits.
9. The multi-initiator control unit of claim 1, wherein
correspondence is established between the node number of each of
the plurality of devices and the position of a bit in a field for
identification of the node number, so that each of the devices can
be identified by the position of the bit in the field.
10. A multi-initiator control method for performing packet-unit
communication with each of a plurality of devices connected via a
transmission line, the method comprising the steps of: determining
whether or not receipt of a command fetch request from one of the
plurality of devices is stored; and fetching a command from the one
of the plurality of devices and executing the command when it is
determined that receipt of a command fetch request is stored,
wherein one of the plurality of devices is selected in a
predetermined order, this selection being repeated, and the step of
determining and the step of fetching are performed for the selected
device.
Description
BACKGROUND OF THE INVENTION
[0001] The present invention relates to sequence processing
technology in relation to a protocol used when a command or data is
transmitted between a computer and a peripheral device via a
transmission line.
[0002] The IEEE 1394 system has received attention as a
next-generation interface for connection between audio-visual (AV)
appliances, computers, and the like because the IEEE 1394 system
defines both asynchronous communications and isochronous
communications. Asynchronous communications is adopted for
communication requiring reliability more than real-time capability,
such as data transmission between a computer and a recording
medium. Isochronous communications is adopted for communication
requiring real-time capability rather than reliability, such as
transmission of AV data including moving images. Therefore, for
storing computer data in a DVD-RAM (digital versatile disc--random
access memory) drive or reading computer data stored in a DVD-RAM
drive, for example, according to IEEE 1394, data transmission is
generally performed by asynchronous communications.
[0003] Serial bus protocol-2 (SBP-2) is a protocol for IEEE 1394
asynchronous communications between a device such as a computer (an
initiator) and a peripheral device (a target). Hereinafter, a
command processing sequence followed when a computer reads data
from a target such as a DVD-RAM drive according to SBP-2 will be
described.
[0004] SBP-2 commands may be grouped into command-type commands
such as READ and WRITE and management-type (task management-type)
commands such as LOGIN, QUERY LOGIN, ABORT TASK, and ABORT TASK
SET.
[0005] FIG. 9 is a diagram illustrating a command processing
sequence for executing LOGIN command as a management-type command.
Referring to FIG. 9, a command processing sequence for LOGIN
command will be described.
[0006] (1) An initiator issues a quadlet read request (QRRQ) packet
to acquire unique information (such as device information) of a
target. In general, the unique information is entirely stored in an
area called a configuration ROM (configROM), and contains the
address of a MANAGEMENT_AGENT register of the target.
[0007] (2) In response to the QRRQ packet from the initiator, the
target returns configROM data to the initiator as a quadlet read
response (QRRS) packet. The process steps (1) and (2) of
transmitting the QRRQ and QRRS packets continue until the initiator
acquires all of configROM data.
[0008] (3) The initiator issues a block write request (BWRQ)
packet, writing the address of a memory storing an operation
request block (ORB) in the MANAGEMENT.sub.13 AGENT register. The
ORB is prepared in advance by the initiator. The MANAGEMENT_AGENT
register exists in a control and status register (CSR) space of the
target.
[0009] (4) In response to the BWRQ packet from the initiator, the
target returns a write response (WRS) packet to the initiator.
[0010] (5) The target issues a block read request (BRRQ) packet to
the initiator, requesting transmission of the ORB to the target.
The ORB is located at a position specified by the address stored in
the MANAGEMENT_AGENT register.
[0011] (6) In response to the BRRQ packet from the target, the
initiator returns a block read response (BRRS) packet to the
target. The ORB is stored in a data field of the BRRS packet. In
this way, the ORB is transmitted from the initiator to the
target.
[0012] (7) The target receives the ORB from the initiator and
analyzes the content of the received ORB.
[0013] (8) Once finding out that the received ORB represents LOGIN
command, the target executes the LOGIN command. LOGIN response
during the execution of the command contains the base address of a
COMMAND_AGENT register.
[0014] (9) Once the execution of the LOGIN command is terminated,
the target prepares status information indicating the execution
results of the LOGIN command.
[0015] (10) The target issues a BWRQ packet, transmitting the
status information to the initiator. The status information is
stored in a predetermined address designated by the ORB
(Status_FIFO address in the initiator).
[0016] (11) In response to the BWRQ packet from the target, the
initiator returns a WRS packet to the target.
[0017] (12) The target determines whether or not rCode in the WRS
packet from the initiator is resp_complete . If the rcode in the
WRS packet from the initiator is resp_complete , the command
processing sequence for the LOGIN command is completed.
[0018] FIG. 10 is a diagram illustrating a command processing
sequence for executing READ command as a command-type command. The
sequence of FIG. 10 is executed after the termination of the LOGIN
command processing sequence described with reference to FIG. 9.
Referring to FIG. 10, the command processing sequence for READ
command will be described.
[0019] (21) The initiator prepares an ORB representing READ
command, which defines information required for execution of the
READ command, such as the data amount, the maximum packet length,
the transfer direction, and the transfer method.
[0020] (22) The initiator writes a QWRQ packet in an AGENT_RESET
register of the target to initialize the target. The AGENT_RESET
register exists in the CSR space of the target.
[0021] (23) In response to the QWRQ packet from the initiator, the
target returns a WRS packet to the initiator.
[0022] (24) The initiator issues a BWRQ packet, writing the address
in a memory storing the ORB in an ORB_POINTER register. The
ORB_POINTER register exists in the CSR space of the target.
[0023] (25) In response to the BWRQ packet from the initiator, the
target returns a WRS to the initiator.
[0024] (26) The target issues a BRRQ packet to the initiator,
requesting transmission of the ORB to the target. The ORB is
located at a position specified by the address stored in the
ORB_POINTER register, that is, at the address in the memory of the
initiator.
[0025] (27) In response to the BRRQ packet from the target, the
initiator returns a BRRS packet to the target. The ORB is stored in
a data field of the BRRS packet. In this way, the ORB is
transmitted from the initiator to the target.
[0026] (28) The target receives the ORB from the initiator and.
analyzes the content of the received ORB.
[0027] (29) Once finding out that the received ORB represents READ
command, the target executes the READ command. During the execution
of the READ command, the following process steps (30) and (31) are
repeated. This is because when the size of data to be transferred
is large, the data must be transferred in the form of a plurality
of packets. The data to be transferred is prepared by the
target.
[0028] (30) The target issues a BWRQ packet, transmitting the data
to an address designated by the ORB.
[0029] (31) In response to the BWRQ packet from the target, the
initiator returns a WRS packet to the target. The process steps
(30) and (31) constitute one transaction. After it is confirmed
that one transaction has been normally terminated, the next
transaction is executed.
[0030] (32) Once the data transfer sequence is normally terminated,
the target prepares status information indicating the execution
results of the READ command.
[0031] (33) The target issues a BWRQ packet, transmitting the
status information to the initiator. The status information is
stored in a predetermined address designated by the ORB.
[0032] (34) In response to the BWRQ packet from the target, the
initiator returns a WRS packet to the target.
[0033] (35) The target determines whether or not rcode in the WRS
packet from the initiator is resp_complete. If the rcode in the WRS
packet from the initiator is resp_complete, the command processing
sequence for the READ command is completed.
[0034] Note that although not illustrated in FIGS. 9 and 10, the
target returns an acknowledge (ACK) packet to the initiator
whenever it receives a packet from the initiator, and the initiator
returns an ACK packet to the target whenever it receives a packet
from the target.
[0035] When receipt of a write request packet (for example, BWRQ,
QWRQ) is successful, the initiator or the target returns an ACK
packet having a code of "Ack_complete" indicating success of
receipt of the packet. In this case, no WRS packet is returned and
the process proceeds to the next step. When the initiator or the
target returns an ACK packet having a code of "Ack-pending", it
returns a WRS packet. When the initiator and the target are in a
state of being unable to receive a packet for any reason, they
return an ACK packet having a code of "Ack_busy" indicating the
state of being unable to receive a packet. In the data transfer
sequence, when the initiator returns an ACK packet having a code of
"Ack_busy" to the target in response to a BWRQ packet from the
target, the target re-transmits the BWRQ packet to the
initiator.
[0036] In the manner described above, the data transfer processing
can be performed between the initiator and the target. In SBP-2, up
to 63 initiators at maximum can be connected to one target on one
bus.
[0037] FIG. 11 is a block diagram of a conventional sequence
processor 90 that implements SBP-2. A physical layer controller 91
has functions such as initialization, arbitration, and bias voltage
control of an IEEE 1394 bus 20. An link core circuit 92 receives a
packet on the bus 20 via the physical layer controller 91, and
performs preparation/detection of an error detection code, addition
of the error detection code to a packet, detection of a code (for
example, a code in an ACK packet), and the like. The link core
circuit 92 also outputs a packet to the bus 20 via the physical
layer controller 91. In addition, the link core circuit 92 has a
retry function of retrying transfer of a packet of which transfer
has once failed.
[0038] A packet filter 93 receives the packet output by the link
core circuit 92, and analyzes the content of a header field of the
packet. The packet filter 93 sends a control signal to a sequence
control circuit 99 or a transfer control circuit 96 depending on
the analysis results, as well as outputting the received packet to
a packet processing circuit 95. The packet processing circuit 95
processes the input packet and outputs a command to a command
receive buffer 97 or outputs the received data externally via a
direct memory access (DMA) bus 6, under control of the sequence
control circuit 99 or the transfer control circuit 96. The sequence
control circuit 99 performs execution and control of a command
processing sequence for one connected initiator.
[0039] As described above, the conventional sequence processor of
FIG. 11 performs a command processing sequence involving one
initiator.
[0040] For the conventional sequence processor to perform a command
processing sequence for two or more initiators, it is necessary to
perform all of the sequence processing for the second and
subsequent initiators and the management of the respective
initiators by firmware. This greatly increases the load on a
central processing unit (CPU).
[0041] In particular, when a large amount of data handled by an
optical disc device such as a DVD-RAM is transferred, the load on a
CPU dramatically increases. This increases the overhead of firmware
executed by the CPU, and as a result, makes it quite difficult to
attain a high effective transfer rate required for a high-speed
serial bus interface, which should actually be attained by adopting
IEEE 1394. In addition, since the load on the CPU is great when all
of the above processing is performed by firmware, the sequence
processor cannot be incorporated in another system such as an
optical disc device.
[0042] As described above, the conventional sequence processor is
actually applicable only to an occasion including a single
initiator. Therefore, the conventional sequence processor is low in
extensibility and is not so effectively usable in a network
environment including a plurality of initiators.
SUMMARY OF THE INVENTION
[0043] An object of the present invention is providing a
multi-initiator control unit capable of executing a command
processing sequence for two or more devices.
[0044] According to one aspect of the invention, a multi-initiator
control unit for performing packet-unit communication with each of
a plurality of devices connected via a transmission line is
provided. The multi-initiator control unit includes: a link core
circuit for transmitting a packet to be transmitted to the
transmission. line, and also receiving a packet from the
transmission line, performing error detection, and outputting the
error-detected packet; a packet filter for analyzing the packet
received by the link core circuit and outputting the results; a
plurality of command control circuits each for controlling a
command processing sequence performed with the corresponding
device; a multi-control circuit for giving sequence execution
permission to one of the plurality of command control circuits; a
packet processing circuit for generating a packet containing
information output by the permission-given command control circuit
as the packet to be transmitted and outputting the packet to the
link core circuit for transmission, and also outputting the packet
received and output by the link core circuit according to the
analysis results output by the packet filter; and a CPU for
executing a command contained in the packet output by the packet
processing circuit.
[0045] According to the invention described above, the
multi-initiator control unit can transmit a packet to a device and
execute a command contained in a packet transmitted by the device
in response to the packet transmitted by the multi-initiator
control unit. This command processing sequence is executed by the
command control circuit. Therefore, the CPU is not involved in
execution of the command processing sequence. Also, the
multi-control circuit-controls selection of a device for which the
multi-initiator control unit performs the command processing
sequence. This can reduce the load on the CPU.
[0046] Preferably, each of the plurality of command control
circuits stores information output by the corresponding device, the
information being required for a command processing sequence
performed with the corresponding device, and outputs the
information once the sequence execution permission is given to the
command control circuit. The multi-control circuit preferably
outputs information contained in the packet received and output by
the link core circuit, the information being required for a command
processing sequence performed with the sender device of the packet,
to the command control circuit among the plurality of command
control circuits corresponding to the sender device to be stored in
the command control circuit, based on the output of the packet
filter. And, preferably, the packet processing circuit generates a
packet containing information output by the command control circuit
provided with the sequence execution permission and outputs the
packet, and also receives a packet output by the device
corresponding to the command control circuit in response to the
packet output by the packet processing circuit.
[0047] With the above construction, the plurality of command
control circuits can be efficiently controlled to enable processing
of a series of transactions in the command processing sequence.
[0048] In the multi-initiator control unit described above,
preferably, each of the plurality of command control circuits
stores information in a command fetch request packet transmitted
from the corresponding device, and performs command fetch operation
for the device once the sequence execution permission is given to
the command control circuit by the multi-control circuit.
[0049] With the above construction, since the command control
circuit holds information contained in a command fetch request
packet transmitted by the corresponding device, it can start
command fetch operation upon receipt of the sequence execution
permission. This enables efficient and high-speed operation.
[0050] Each of the plurality of command control circuits preferably
receives a command fetch request from the corresponding device even
during execution of a data transfer processing sequence.
[0051] With the above construction, even when command execution for
one device is underway, a command fetch request for another device
can be processed. Therefore, it is possible to respond to access
from the corresponding device irrespective of the state of command
processing.
[0052] In the multi-initiator control unit described above,
preferably, each of the plurality of command control circuits has a
register for storing an address for performing a command processing
sequence, and an address of the register is obtained by performing
address expansion on an address of the register of a reference
command control circuit among the plurality of command control
circuits by a predetermined value as a unit depending on the node
number of the device corresponding to the command control circuit
including the register in question.
[0053] With the above construction, the address of a register is
determined by performing address expansion on the address of a
register of the reference command control circuit. Therefore, the
CPU is not required to manage the address of a register accessed by
the corresponding device even when a plurality of devices are
connected. This reduces the load of the CPU, and thus high-speed
operation is possible as in the case of connection of a single
device.
[0054] In the multi-initiator control unit described above,
preferably, the multi-control circuit selects one of the plurality
of devices in a predetermined order every time a command processing
sequence is terminated and gives the sequence execution permission
to the command control circuit among the plurality of command
control circuit corresponding to the selected device.
[0055] With the above construction, whether or not command
execution permission should be given is determined for the
respective connected devices sequentially. This reduces variation
in command execution frequency with the devices, and avoids an
occurrence of more chances of executing a command being unequally
given to a certain device or devices than to the other devices.
[0056] The multi-initiator control unit described above may further
includes a transfer control circuit for controlling data transfer
between the packet processing circuit and the outside of the
multi-initiator control unit, wherein the packet processing circuit
retrieves data to be transferred from the packet output by the
packet filter and outputs the data to the transfer control circuit,
and also generates a packet containing data transferred to the
transfer control circuit and outputs the packet to the link core
circuit.
[0057] With the above construction, the data transfer processing
sequence is controlled by the transfer control circuit. Therefore,
the CPU is not involved in execution of the data transfer sequence.
This reduces the load on the CPU during execution of the data
transfer processing sequence, and high-speed data transfer is
possible.
[0058] In the multi-initiator control unit described above, the CPU
is preferably allowed to give sequence execution permission to the
plurality of command control circuits.
[0059] With the above construction, the CPU can control the command
fetch operation timing. This provides an increased degree of
freedom for sequence control from firmware, and enables sequence
processing in synchronization with the specification of the
firmware.
[0060] In the multi-initiator control unit described above,
preferably, correspondence is established between the node number
of each of the plurality of devices and the position of a bit in a
field for identification of the node number, so that each of the
devices can be identified by the position of the bit in the
field.
[0061] With the above construction, the node number of each device
is represented simply by one bit. This enables management of
devices by a small-scale circuit even when a larger number of
devices are connected.
[0062] According to another aspect of the invention, a
multi-initiator control method for performing packet-unit
communication with each of a plurality of devices connected via a
transmission line is provided. The method includes the steps of:
determining whether or not receipt of a command fetch request from
one of the plurality of devices is stored; and fetching a command
from the device and executing the command when it is determined
that receipt of a command fetch request is stored, wherein one of
the plurality of devices is selected in a predetermined order, this
selection being repeated, and the step of determining and the step
of fetching are performed for the selected device.
[0063] According to the invention described above, whether or not
command execution permission should be given is determined for the
respective connected devices sequentially. This avoids an
occurrence of more chances of executing a command being unequally
given to a certain device or devices than to the other devices.
BRIEF DESCRIPTION OF THE DRAWINGS
[0064] FIG. 1 is a block diagram of a data transfer system using a
multi-initiator control unit of an embodiment of the present
invention.
[0065] FIG. 2 is a block diagram of the multi-initiator control
unit of the embodiment of the present invention shown in FIG.
1.
[0066] FIG. 3 is an illustration of registers of a multi-control
circuit and a command control circuit shown in FIG. 2.
[0067] FIG. 4 is an illustration of address expansion.
[0068] FIG. 5 is an illustration of management of node numbers of
initiators.
[0069] FIG. 6 is a flowchart of a sequence of command execution
processing performed by the multi-control circuit shown in FIG.
2.
[0070] FIG. 7A is an illustration of a format of a BWRQ packet used
inside the multi-initiator control unit of FIG. 2.
[0071] FIG. 7B is an illustration of a format of a QWRQ packet used
inside the multi-initiator control unit of FIG. 2.
[0072] FIG. 7C is an illustration of a format of a WRS packet used
inside the multi-initiator control unit of FIG. 2.
[0073] FIG. 7D is an illustration of a format of a BRRQ packet used
inside the multi-initiator control unit of FIG. 2.
[0074] FIG. 7E is an illustration of a format of a BRRS packet used
inside the multi-initiator control unit of FIG. 2.
[0075] FIG. 8A is an illustration of a format of a BWRQ packet on
an IEEE 1394 bus.
[0076] FIG. 8B is an illustration of a format of a QWRQ packet on
the IEEE 1394 bus.
[0077] FIG. 8C is an illustration of a format of a WRS packet on
the IEEE 1394 bus.
[0078] FIG. 8D is an illustration of a format of a BRRQ packet on
the IEEE 1394 bus.
[0079] FIG. 8E is an illustration of a format of a BRRS packet on
the IEEE 1394 bus.
[0080] FIG. 9 is an illustration of a command processing sequence
for executing LOGIN command.
[0081] FIG. 10 is an illustration of a command processing sequence
for executing READ command.
[0082] FIG. 11 is a block diagram of a conventional sequence
processor.
DESCRIPTION OF THE PREFERRED EMBODIMENTS
[0083] Hereinafter, a preferred embodiment of the present invention
will be described with reference to the accompanying drawings. It
should be noted that the technical range of the present invention
is not limited to the embodiment described herein.
[0084] FIG. 1 is a block diagram of a data transfer system using a
multi-initiator control unit of the embodiment of the present
invention. The data transfer system of FIG. 1 includes an optical
disc drive 1 and initiators 11, 12, and 13 as devices connected to
the optical disc drive 1. The initiators 11 to 13 are personal
computers (PCs), for example. The optical disc drive 1 includes a
multi-initiator control unit 2 as the target, a DVD-RAM controller
3, a head 4, and a DVD-RAM disc 5.
[0085] The initiators 11, 12, and 13 are connected to the
multi-initiator control unit 2 via IEEE 1394 serial buses
(hereinafter, simply called "buses") 21, 22, and 23, respectively.
The multi-initiator control unit 2 is connected to the DVD-RAM
controller 3 via a DMA bus 6. The DVD-RAM controller 3 performs
signal processing such as demodulation for data read from the
DVD-RAM disc 5 via the head 4 and transfers the processed signal to
the multi-initiator control unit 2. The DVD-RAM controller 3 also
performs signal processing such as modulation for data transferred
from the multi-initiator control unit 2 and writes the processed
data in the DVD-RAM disc 5 via the head 4.
[0086] FIG. 2 is a block diagram of the multi-initiator control
unit 2 of this embodiment shown in FIG. 1. Referring to FIG. 2, the
multi-initiator control unit 2 includes a CPU 31, a physical layer
controller (PHY) 41, a link core circuit (LINK) 42, a packet filter
43, a multi-control circuit 44, a packet processing circuit 45, a
transfer control circuit 46, a command receive buffer 47, a control
register 48, and command control circuits 51, 52, and 53.
[0087] As shown in FIG. 2, the CPU 31, the link core circuit 42,
the transfer control circuit 46, and the command control circuits
51 to 53 are allowed to write/read data in/from the control
register 48. The packet filter 43 can read data from the control
register 48. Hereinafter, as an example, data transfer between the
initiators and the target according to serial bus protocol-2
(SBP-2) will be described.
[0088] The physical layer controller 41 has functions such as
initialization of the buses 21 to 23, arbitration, and control of a
bias voltage. The physical layer controller 41 converts an electric
signal on any of the buses 21 to 23 to a packet and outputs the
packet to the link core circuit 42, and also converts a packet
received from the link core circuit 42 to an electric signal and
outputs the electric signal to any of the buses 21 to 23.
[0089] The link core circuit 42 receives the packet from the
physical layer controller 41. The link core circuit 42 performs
detection of an error detection code, detection of a code (for
example, a code in an ACK packet), and the like for the received
packet, and outputs the packet to the packet filter 43 and the
packet processing circuit 45. The link core circuit 42 also
performs preparation and addition of an error detection code for a
packet to be transmitted, and outputs the packet to the physical
layer controller 41. In addition, the link core circuit 42 has a
retry function of retrying transfer of a packet of which transfer
has once failed.
[0090] The packet filter 43 receives the packet from the link core
circuit 42, and analyzes the content of a header field of the
packet. The packet filter 43 determines whether or not the packet
should be stored in the command receive buffer 47 depending on the
analysis results, and notifies the packet processing circuit 45 of
the determination. The packet filter 43 also encodes the node
number of the sender initiator of the received packet, and outputs
the encoded number to the multi-control circuit 44 and the transfer
control circuit 46 as a control signal. In addition, the packet
filter 43 outputs information contained in the received packet to
the multi-control circuit 44 and the transfer control circuit
46.
[0091] The multi-control circuit 44 receives the information
contained in the packet received by the link core circuit 42, from
the packet filter 43, and sends the information to any of the
command control circuits 51 to 53 to be stored therein, depending
on the control signal output by the packet filter 43. The
multi-control circuit 44 also gives sequence execution permission
to one of the command control circuits 51 to 53, and outputs
information sent from the permission-given command control circuit
to the packet processing circuit 45.
[0092] The packet processing circuit 45, which operates under
control of the multi-control circuit 44, sends the packet
determined to be stored in the command receive buffer 47 by the
packet filter 43 to the command receive buffer 47 to be stored
therein. The packet stored in the command receive buffer 47 is free
to be read by the CPU 31. The packet processing circuit 45 also
prepares a packet containing information received from the
multi-control circuit 44, and outputs the prepared packet to the
link core circuit 42 as a packet to be transmitted.
[0093] The transfer control circuit 46 receives a transfer command
execution request such as READ and WRITE output by the CPU 31 via
the control register 48, and controls transfer of a packet between
the packet processing circuit 45 and the DVD-RAM controller 3.
[0094] For example, in the case of executing READ command, the
transfer control circuit 46 reads data recorded on the DVD-RAM disc
5 via the DVD-RAM controller 3 and the DMA bus 6 based on an
execution request from the CPU 31, and outputs the data to the
packet processing circuit 45. The packet processing circuit 45
divides the data received from the transfer control circuit 46 to
be stored in a plurality of packets, and then outputs the packets
to any of the buses 21 to 23 via the link core circuit 42 and the
physical layer controller 41.
[0095] In the case of executing WRITE command, the packet
processing circuit 45 receives a packet from any of the buses 21 to
23 via the physical layer controller 41 and the link core circuit
42, retrieves data from the packet, and outputs the data to the
transfer control circuit 46. The transfer control circuit 46
outputs the received data to the DVD-RAM controller 3 via the DMA
bus 6, so that the data is recorded on the DVD-RAM disc 5. The
packet generation and packet transfer described above are
controlled by the transfer control circuit 46.
[0096] Thus, with the transfer control circuit 46 performing the
data transfer processing sequence, the CPU 31 is not involved in
execution of the data transfer processing sequence. This enables
reduction of the load on the CPU 31 during the data transfer
processing sequence, and thus high-speed data transfer according to
IEEE 1394 is attained.
[0097] The IEEE 1394 standard defines the data length transferable
per packet (maximum payload size) in association with the transfer
rate. In this embodiment, the transfer rate is set at S400 (about
400 Mbit/sec), and the data length transferable per packet at this
transfer rate is 2048 bytes.
[0098] Each of the command control circuits 51, 52, and 53 which
correspond to the initiators 11, 12, and 13, respectively, receives
a command fetch request from the corresponding initiator and
controls the command processing sequence performed with the
corresponding initiator. The multi-control circuit 44 manages
execution of the sequence by any of the command control circuits 51
to 53. The multi-control circuit 44 and the command control
circuits 51 to 53 have respective agent registers (AGENT_REGISTER)
required for a command processing sequence.
[0099] FIG. 3 is an illustration of registers of the multi-control
circuit 44 and the command control circuit 51 shown in FIG. 2. The
constructions of registers of the command control circuits 52 and
53 are the same as that of the command control circuit 51, and
therefore illustration is omitted.
[0100] The multi-control circuit 44 includes a MANAGEMENT_AGENT
register R10 as an agent register, which stores an address for
fetching a management-type command such as LOGIN. The command
control circuit 51 includes an AGENT_STATE register R11, an
AGENT_RESET register R12, an ORB_POINTER register R13, a DOORBELL
register R14, and an UNSOLICITED_STATUS register R15 as agent
registers. The command control circuits 52 and 53 also include
these registers. The registers of the command control circuits 51
to 53 store an address for fetching a command-type command and the
like.
[0101] The command control circuits 51 to 53 store information
required for a command processing sequence performed with the
corresponding initiators 11 to 13. This information includes
information in a command fetch request packet output by the
corresponding initiators 11 to 13 and information indicating that
there was access to the DOORBELL register.
[0102] The command control circuits 51 to 53, which receive
information in a command fetch request packet from the
corresponding initiators 11 to 13 and hold it therein, can queue
the information in the packet for which sequence execution
permission has not yet been given by the multi-control circuit 44,
that is, queue a pending command. The command fetch request packet
may be a BWRQ packet or a QWRQ packet, for example. If it is BWRQ
packet, it contains the address to be command-fetched.
[0103] The initiators 11 to 13 may access the corresponding command
control circuits 51 to 53 for command fetch request in the
following two ways. One is access to the ORB_POINTER register,
where the address to be command-fetched (address of a position in
which an operation request block (ORB) is stored) is written using
a BWRQ packet, and the other is access to the DOORBELL register
using a QWRQ packet. The command control circuit 51 stores the
address to be command-fetched in the ORB-POINTER register R13, and,
if there is access to the DOORBELL register R14, stores the fact of
the access, that is, stores information indicating that there was
access to the DOORBELL register R14. This is also applied to the
command control circuits 52 and 53.
[0104] FIG. 4 illustrates address expansion. The addresses of the
agent registers of the command control circuit 51 are set at values
obtained by adding respective predetermined values to a base
address as the reference. The base address is the address of the
AGENT_STATE register R11 of the command control circuit 51. The
addresses of the agent registers of the command control circuit 52
are set at values obtained by adding 20 h (h represents hexadecimal
notation) to the same types of registers of the command control
circuit 51, and the addresses of the agent registers of the command
control circuit 53 are set at values obtained by adding 40 h to the
same types of registers of the command control circuit 51. In other
words, the address regions for the command control circuits 51, 52,
and 53 start from the base address, the base address+20 h, and the
base address+40 h, respectively.
[0105] In the command processing sequence, the packet filter 43
analyzes the packet received from any of the initiators 11 to 13,
compares the address which the sender initiator of the packet
intends to access with the addresses of the agent registers, and
notifies the multi-control circuit 44 of the comparison
results.
[0106] Specifically, the packet filter 43 performs address
expansion by 20 h each, for example, depending on the node number
of the LOGIN initiator before the analysis of the received packet,
and outputs the results to the multi-control circuit 44 as a
control signal. The packet filter 43 has received in advance the
base address and the node numbers of the initiators 11 to 13 from
the CPU 31.
[0107] When the sender of the packet is the initiator 11, the
packet filter 43 does not perform address expansion, judging from
the node number. In this case, the packet filter 43 compares the
received address with the addresses of the agent registers
determined from the base address, generates a control signal
indicating the register to be accessed, and outputs the control
signal to the multi-control circuit 44. When the sender of the
packet is the initiator 12, the packet filter 43 compares the
received address with the addresses of the agent registers
determined from the address obtained by adding 20 h to the base
address of the initiator 11, judging from the node number,
generates a control signal indicating the register to be accessed,
and outputs the control signal to the multi-control circuit 44.
When the sender of the packet is the initiator 13, the packet
filter 43 compares the received address with the addresses of the
agent registers determined from the address obtained by adding 40 h
to the base address of the initiator 11, judging from the node
number, generates a control signal indicating the register to be
accessed, and outputs the control signal to the multi-control
circuit 44.
[0108] The multi-control circuit 44 accesses the register among the
registers of the command control circuits 51 to 53 indicated by the
control signal output by the packet filter 43, and makes the
register store information in the command fetch request packet as
required.
[0109] By the above management of the addresses of the agent
registers, address management by the CPU 31 is simplified. The
address is determined based on the node number of the initiator as
the sender of the received packet. This eliminates the necessity of
increasing the circuit scale for address management of agent
registers even if as many as 63 initiators, the maximum number of
nodes accessible to one local bus according to the IEEE 1394
standard, are connected to the control unit. Although the address
expansion from the base address was made by 20 h each in the above
description, any other value may be adopted as the unit of the
address expansion.
[0110] FIG. 5 is an illustration of management of the node numbers
of the initiators. In this embodiment, in which three initiators
are connected to the multi-initiator control unit 2, it is assumed
that these initiators are identified in a three-bit field. In other
words, it is assumed that when bit N1 is "1", the initiator 11 is
indicated, and likewise when bit N2 or N3 is "1", the initiator 12
or 13 is indicated.
[0111] For example, assume that the node numbers of the initiators
11, 12, and 13 are ffc0 h, ffc1 h, and ffc2 h and that the received
packet has indication of the node number ffc0 h. In this case, the
packet filter 43 outputs "001" to the multi-control circuit 44,
notifying that the packet is from the initiator 11.
[0112] The packet processing circuit 45 converts the node number
identified in the three-bit field to a 16-bit node number such as
ffc0 h, and incorporates the 16-bit node number in a packet.
[0113] Thus, the 16-bit node number can be represented by one bit
and managed in the form of one-bit number. This simplifies the
circuits handling the node numbers such as the multi-control
circuit 44. Note that the node numbers of the initiators 11 to 13
may correspond with any of the positions of the bits N1, N2, and N3
as long as one-to-one correspondence is established. Naturally, the
node numbers may be used as they are in the multi-control circuit
44.
[0114] FIG. 6 is a flowchart of a sequence of command execution
processing performed by the multi-control circuit 44 shown in FIG.
2. In the following description, note that the node numbers of the
initiators 11, 12, and 13 are Node 1, Node 2, and Node 3,
respectively. Note also that the initiators 11 to 13 intend to
access the ORB_POINTER registers when they issue a command fetch
request to the corresponding command control circuits 51 to 53.
[0115] First, in step Sll, the multi-control circuit 44 determines
whether or not a command processing sequence for the Node 1
initiator 11 is incomplete. In other words, the multi-control
circuit 44 determines whether or not the command control circuit 51
has received a command fetch request and queued a pending command.
If the command control circuit 51 has queued a command, the process
proceeds to step S12, and otherwise, the process proceeds to step
S13.
[0116] In step S12, the multi-control circuit 44 gives sequence
execution permission to the command control circuit 51. The command
control circuit 51 fetches a command from the Node 1 initiator 11
using the address to be command-fetched stored therein. That is,
the command control circuit 51 notifies the packet processing
circuit 45 of the address to be command-fetched. The packet
processing circuit 45 generates a packet containing this address
and transmits the packet to the initiator 11 via the link core
circuit 42 and the bus 21. In response to this packet, the
initiator 11 transmits a packet containing the command, which is
transmitted via the bus 21, the link core circuit 42, and the
packet processing circuit 45, to be stored in the command receive
buffer 47. The CPU 31 executes the command contained in this
packet. In this way, a series of transaction for fetching and
executing a command is performed. Upon termination of the command,
the process proceeds to step S13.
[0117] In step S13, the multi-control circuit 44 determines whether
or not a command processing sequence for the Node 2 initiator 12 is
incomplete. In other words, the multi-control circuit 44 determines
whether or not the command control circuit 52 has received a
command fetch request and queued a pending command. If the command
control circuit 52 has queued a command, the process proceeds to
step S14, and otherwise, the process proceeds to step S15.
[0118] In step S14, the multi-control circuit 44 gives sequence
execution permission to the command control circuit 52. As in step
S12, the command control circuit 52 fetches a command from the Node
2 initiator 12. The CPU 31 executes the command, and upon
termination of the command, the process proceeds to step S15.
[0119] In step S15, the multi-control circuit 44 determines whether
or not a command processing sequence for the Node 3 initiator 13 is
incomplete. In other words, the multi-control circuit 44 determines
whether or not the command control circuit 53 has received a
command fetch request and queued a pending command. If the command
control circuit 52 has queued a command, the process proceeds to
step S16, and otherwise, the process returns to step S11.
[0120] In step S16, the multi-control circuit 44 gives sequence
execution permission to the command control circuit 53. As in step
S12, the command control circuit 53 fetches a command from the Node
3 initiator 13. The CPU 31 executes the command, and upon
termination of the command, the process returns to step S11.
Thereafter, substantially the same sequence is repeated.
[0121] As described above, the multi-control circuit 44 constantly
manages the state of command execution by the connected initiator,
and makes a determination whether or not command execution
permission should be given for all the initiators equally in order.
This prevents occurrence of variation in the frequency of command
execution among the initiators.
[0122] Substantially the same sequence as that described above is
followed when the initiators 11 to 13 intend to access the
respective DOORBELL registers in their command fetch request,
except that the operation of fetching a command from the initiators
11 to 13 is more complicated. Specifically, the following operation
is performed in place of step S12 for the initiator 11.
[0123] The command control circuit 51 transmits the address stored
in the ORB_POINTER register R13 to the initiator 11. In response to
this transmission, the initiator 11 transmits a packet containing a
pointer indicating an ORB to be referred to next time. The command
control circuit 51 notifies the packet processing circuit 45 of
this pointer. The packet processing circuit 45 generates a packet
containing this pointer and transmits the packet to the initiator
11. In response to this packet, the initiator 11 transmits a packet
containing the command. The CPU 31 executes the command contained
in this packet. Substantially the same operation is also performed
for the initiators 12 and 13, in place of steps S14 and S16,
respectively.
[0124] Although the case of connecting three initiators was
described above, the number of initiators is not limited to three.
Substantially the same processing can be performed for up to 63
initiators, the maximum number connectable to one local bus
according to the IEEE 1394 standard, by providing a command control
circuit corresponding to each initiator.
[0125] FIGS. 7A to 7E illustrate formats of packets used internally
by the multi-initiator control unit 2 of FIG. 2. The hatched
portions in FIGS. 7A to 7E represent reserved fields. Specifically,
FIG. 7A illustrates a format of a BWRQ (block write request)
packet, FIG. 7B a format of a QWRQ (quadlet write request) packet,
FIG. 7C a format of a WRS (write response) packet, FIG. 7D a format
of a BRRQ (block read request) packet, and FIG. 7E a format of a
BRRS (block read response) packet.
[0126] FIGS. 8A to 8E illustrate formats of packets on the IEEE
1394 buses 21 to 23. FIGS. 8A to 8E correspond to the formats of
FIGS. 7A to 7E, respectively.
[0127] When a packet is to be transmitted to any of the buses 21 to
23, the link core circuit 42 receives the packet in any of the
formats of FIGS. 7A to 7E and generates a cyclic redundancy check
(CRC) code such as header_CRC or data_CRC based on the received
packet. The link core circuit 42 then adds a field of the CRC code
to the received packet, and outputs the resultant packet in any of
the formats FIGS. 8A to 8E to the physical layer controller 41.
[0128] When a packet is to be received from any of the buses 21 to
23, the link core circuit 42 receives the packet in any of the
formats of FIGS. 8A to 8E and performs error detection by CRC by
referring to a header_CRC or data_CRC region of the received
packet. The link core circuit 42 then outputs the error-detected
packet in any of the formats FIGS. 7A to 7E to the packet filter 43
and the packet processing circuit 45.
[0129] Hereinafter, the operation of the multi-initiator control
unit 2 of FIG. 2 will be described. First, execution of LOGIN
command will be described. The multi-initiator control unit 2
performs the command processing sequence shown in FIG. 9 for the
initiator 11. Once the command processing sequence for LOGIN
command for the initiator 11 is terminated, the CPU 31 enables one
bit in the control register 48 corresponding to the node number of
the LOGIN initiator 11. Likewise, the LOGIN processing for the
initiators 12 and 13 is performed. By the series of LOGIN
processing, the command control circuits 51, 52, and 53 are
assigned to the initiators 11, 12, and 13, respectively.
[0130] Next, execution of READ command will be described. The
command processing sequence between the multi-initiator control
unit 2 and the initiators 11 to 13 is substantially the same as
that shown in FIG. 10, except that the command control circuits 51
to 53 can queue a command.
[0131] The initiator 11 transmits a QWRQ packet to the AGENT_RESET
register R12 for executing READ command. The initiator 11 then
transmits a BWRQ packet to the corresponding command control
circuit 51, writing the address of an ORB to be accessed by the
command control circuit 51 in the ORB_POINTER register R13. The
multi-control circuit 44 manages the state of each of the command
control circuits 51 to 53. When the multi-control circuit 44 gives
sequence execution permission to the command control circuit 51,
for example, the command control circuit 51 executes command fetch
operation.
[0132] The command receive buffer 47 stores the command-containing
packet received from the initiator 11. The CPU 31 reads the command
from the command receive buffer 47, and activates the transfer
control circuit 46 for execution of the READ command. The transfer
control circuit 46 reads data in the DVD-RAM disc 5 from the
DVD-RAM controller 3 via the DMA bus 6, and outputs the read data
to the packet processing circuit 45. The packet processing circuit
45 prepares a packet containing the input data and outputs the
packet to the link core circuit 42.
[0133] Assume that during the execution of the data transfer
sequence for the initiator 11, the multi-initiator control unit 2
receives a command fetch request packet for WRITE command from the
initiator 12 and a command fetch request packet for READ command
from the initiator 13. In this case, the command control circuit 52
corresponding to the initiator 12 receives the command fetch
request from the initiator 12 even during the execution of the data
transfer sequence. That is, the command control circuit 52 stores
an address to be accessed for command fetch operation according to
the control signal from the multi-control circuit 44, and waits for
sequence execution permission. Likewise, the command control
circuit 53 corresponding to the initiator 13 receives the command
fetch request from the initiator 13 even during the execution of
the data transfer sequence, and waits for sequence execution
permission.
[0134] Upon termination of the data transfer sequence for the
initiator 11, the multi-control circuit 44 examines the command
queuing state of the command control circuit 52, that is, whether
or not the command control circuit 52 has received a command fetch
request. If recognizing that the command control circuit 52 has
queued a command, the multi-control circuit 44 gives sequence
execution permission to the command control circuit 52. Upon
receipt of sequence execution permission, the command control
circuit 52 executes the command processing sequence for the
initiator 12. The packet processing circuit 45 sends a received
packet to the command receive buffer 47 to be stored therein.
[0135] The CPU 31 reads the command from the command receive buffer
47, and activates the transfer control circuit 46 for execution of
the WRITE command. The transfer control circuit 46 transfers a
packet to the link core circuit 42 for reading data from the
initiator 12. The transfer control circuit 46 reads data from the
initiator 12 via the link core circuit 42, and writes the data in
the DVD-RAM disc 5 via the DMA bus 6 and the DVD-RAM controller 3.
Once a specified amount of transfer data has been written in the
DVD-RAM disc 5, the transfer control circuit 46 transmits status
information to the initiator 12. In this way, this data transfer
processing sequence is terminated.
[0136] Upon termination of the command processing sequence for the
initiator 12, the multi-control circuit 44 examines the command
queuing state of the command control circuit 53. If recognizing
that the command control circuit 53 has queued a command, the
multi-control circuit 44 gives sequence execution permission to the
command control circuit 53. Upon receipt of sequence execution
permission, the command control circuit 53 executes command fetch
operation for the initiator 13, and a received packet is stored in
the command receive buffer 47. Thereafter, as described above, the
CPU 31 activates the transfer control circuit 46 and executes the
READ command.
[0137] As described above, in the multi-initiator control unit 2 of
this embodiment, the command control circuits 51, 52, and 53
perform a command processing sequence for the corresponding
initiators. The multi-control circuit 44 controls the command
control circuits 51, 52, and 53 to enable a processing sequence for
a plurality of initiators. Therefore, the CPU 31 is relieved of
performing a command processing sequence such as command fetch
operation. In addition, while the CPU 31 executes a command stored
in the command receive buffer 47, a data transfer processing
sequence is performed by the transfer control circuit 46. This
permits efficient sequence control and data transfer control,
enabling management of a plurality of initiators without increasing
the load on the CPU 31.
[0138] (Modifications)
[0139] The CPU 31, in place of the multi-control circuit 44, may
give sequence execution permission to the command control circuits
51 to 53 via the control register 48, to control the timing at
which a command is fetched. This modification will be
described.
[0140] A data transfer processing sequence performed by the
transfer control circuit 46, for example, can be basically
implemented by only hardware. However, the processing of a command
received from the initiator may fail to be implemented by only
hardware and require firmware. Also, an error may be generated in
transferring data during a data transfer processing sequence. To
solve this problem, processing by firmware may be necessary.
[0141] In the above case, the processing by firmware executed by
the CPU 31 may fail to catch up with the processing by hardware. In
such a case, it is necessary for the CPU 31 to control the command
processing sequence.
[0142] This modification will be described with reference to FIGS.
2 and 3. Assume that the processing of LOGIN command for the
initiators 11 and 12 has been terminated. The initiator 11
transmits a BWRQ packet to the ORB_POINTER register R13 of the
command control circuit 51. Once the multi-control circuit 44 gives
sequence execution permission to the command control circuit 51
corresponding to the initiator 11, the command control circuit 51
performs command fetch operation for the initiator 11. The packet
processing circuit 45 sends a packet received from the initiator 11
to the command receive buffer 47 to be stored therein. The CPU 31
reads a command stored in the command receive buffer 47 and
executes the command. Assume that this command requires processing
by firmware.
[0143] The CPU 31 controls the command control circuit 52 to be in
the state of waiting for sequence execution permission via the
control register 48. An address to be command-fetched for READ
command, for example, transmitted from the initiator 12 during the
execution of the command from the initiator 11 by the CPU 31 is
stored in the command control circuit 52.
[0144] Once the CPU 31 terminates the command processing for the
initiator 11, it gives sequence execution permission to the
multi-control circuit 44, which in turn gives sequence execution
permission to the command control circuit 52. Upon receipt of
sequence execution permission, the command control circuit 52
fetches the command from the initiator 12. The packet processing
circuit 45 sends a packet from the initiator 12 to the command
receive buffer 47 to be stored therein. The CPU 31 reads the
command stored in the command receive buffer 47 and executes the
command from the initiator 12.
[0145] As described above, in this modification, the CPU 31 can
freely control the start timing of a command processing sequence,
and thus it is possible to synchronize the command processing
sequence with the operation of the CPU 31. This facilitates
sequence management by the CPU 31.
[0146] In the embodiment described above, data transfer between an
initiator and a DVD-RAM disc was exemplified. The present invention
is also applicable to data transfer between an initiator and
another data recording medium such as another type of optical disc
and a magnetic disc.
[0147] According to the present invention, the load on the CPU is
prevented from increasing even when a plurality of initiators are
connected. Thus, it is possible to provide a multi-initiator
control unit and method capable of connecting a plurality of
initiators and yet performing high-speed data transfer.
[0148] While the present invention has been described in a
preferred embodiment, it will be apparent to those skilled in the
art that the disclosed invention may be modified in numerous ways
and may assume many embodiments other than that specifically set
out and described above. Accordingly, it is intended by the
appended claims to cover all modifications of the invention which
fall within the true spirit and scope of the invention.
* * * * *