JP2009037479A - Data transfer control device and electronic device - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To appropriately keep even transfer compliance between a host and a serial ATA (AT attachment) device, while achieving a bridge function of a parallel ATA and a serial ATA. <P>SOLUTION: The data transfer control device includes a PATAI/F (parallel AT attachment interface) 10; an SATAI/F (serial AT attachment interface) 50; and a sequence controller 30. The PATAI/F 10 includes the task file register TFR 12. When the host 2 issues an identify device command, the SATAI/F 50 transmits a register FIS corresponding to the command to the device 5. When data FIS where identify device information being the return value of the identify device command is set is received, the sequence controller 30 rewrites the identify device information. <P>COPYRIGHT: (C)2009,JPO&INPIT

Description

  The present invention relates to a data transfer control device and an electronic device.

  In recent years, a standard called Serial ATA (Serial AT Attachment) has been spotlighted as a serial interface for storage devices and the like. This serial ATA is a standard having compatibility at the software level with parallel ATA (IDE). The data transfer rate of serial ATA I, which is the first standard, was 1.5 Gbps, but the data transfer rate has been increased to 3.0 Gbps in serial ATA II Gen2, which is the next standard. If this serial ATA is used, the number of wires between circuit boards built in the electronic device can be reduced, and the electronic device can be made compact.

  However, the host (host device, host substrate) of the electronic device has a parallel ATA (hereinafter referred to as PATA as appropriate) interface (hereinafter referred to as I / F as appropriate), but a serial ATA (hereinafter referred to as PATA). Many of them do not have an I / F (referred to as SATA as appropriate). For this reason, there is a problem that a SATA device cannot be connected to an existing host having only the PATA I / F. Therefore, it is desired to provide a data transfer control device having a PATA and SATA bridge function.

  Incidentally, the ATA host issues an identify device command to the device in order to know the device characteristic parameters. Then, after acquiring various information from the device, the data transfer speed and other exchanges between the host and the device are determined and data transfer is executed.

However, SATA devices operate faster than PATA devices. Therefore, when a SATA device is bridge-connected to a data transfer control device having a bridge function, the SATA device responds to an identified device command (identified packet device command) issued from the host. There is a possibility of returning a characteristic parameter exceeding the hardware capability of the data transfer control device. In this case, since the data transfer control device is interposed between the host and the SATA device, the transfer consistency between the two may not be achieved.
JP-A-2005-346123 JP 2006-121621 A JP 2006-18428 A

  The present invention has been made in view of the above problems. According to some aspects of the present invention, a host and a serial ATA device can be connected to each other while realizing a bus bridge function of parallel ATA and serial ATA. It is also possible to properly maintain the consistency of transfer between.

  The present invention is a data transfer control device having a parallel ATA and serial ATA bus bridge function, connected to a parallel ATA bus and connected to a host, and connected to a serial ATA bus. A serial ATA interface for interfacing with a serial ATA device; and a sequence controller for performing transfer sequence control. The parallel ATA interface has a task file register. The serial ATA interface is identified by the host. When a proof device command is issued, a register FIS corresponding to the identify device command is transmitted to the device of the serial ATA, and the When the serial ATA interface receives the data FIS in which the identified device information, which is a return value of the identified device command, is received by the serial ATA interface, the instance controller rewrites the identified device information. The present invention relates to a data transfer control device that performs processing.

  According to the present invention, when the host issues an identify device command, a register FIS corresponding to the identify device command is transmitted to the device of the serial ATA. When the data FIS in which the identified device information is set is received from the device, rewriting processing of the identified device information is performed. The rewritten identification device information is set in the data register of the task file register, for example, and is notified to the host. In this way, it is possible to optimize transfer consistency between the host and the serial ATA device while realizing a bus bridge function of parallel ATA and serial ATA.

  The present invention further includes a data buffer for buffering data transferred between the host and the device, and the sequence controller writes the identifier device information after the identifier device information is written to the data buffer. The identified device information may be read out, the read-out identification device information may be rewritten, and written back to the data buffer.

  In this way, it is possible to perform rewrite processing by extracting only the information that needs to be rewritten from the identified device information written in the data buffer.

  In the present invention, the sequence controller receives the PIO setup transfer FIS for PIO read transfer on the serial ATA side from the device and then receives the data FIS for PIO read transfer as the identified device information. Wait until the read data for one sector is written in the data buffer, and after the read data for one sector is written in the data buffer, the rewrite processing of the identified device information that is the read data After that, the busy bit of the status register of the task file register may be cleared and the data request bit may be set.

  In this way, the read request for one sector is written to the data buffer, and the data request from the host is not performed unless the rewrite processing of the identification device information is completed. Processing can be realized.

  In the present invention, the sequence controller may instruct the parallel ATA interface to start PIO read transfer on the parallel ATA side after setting the status register bit of the task file register.

  In this way, when the PIO read transfer start instruction is given, there is data to be transferred reliably, and it is possible to prevent a situation in which there is no data to be transferred although transfer start is instructed.

  According to the present invention, the parallel ATA interface has a parallel ATA data buffer in which the read data is buffered, and becomes inactive when a bit of the status register of the task file register is set, An IORDY signal that becomes active when read data that is the device information after rewriting is stored in the data buffer for parallel ATA may be generated.

  By doing so, it is possible to prevent a situation in which there is no data to be transferred but there is no data to be transferred and the host is unnecessarily waited for by the IORDY signal, and an IORDY signal assert timing violation occurs.

  In the present invention, the sequence controller may perform an IORDY parameter rewrite process of the identified device information as the rewrite process.

  In this way, proper control of the IORDY signal can be realized.

  In the present invention, the sequence controller may perform a process of rewriting the transfer capability parameter of the identified device information to a parameter corresponding to the transfer capability of the data transfer control device as the rewrite process.

  In this way, appropriate data transfer control according to the transfer capability of the data transfer control device can be executed.

  The present invention further includes an initialization sequence management unit that performs initialization sequence management on behalf of the device of the serial ATA that does not have an initialization sequence management function, and the initialization sequence management unit includes a master / slave setting terminal When the data transfer control device is set on the master side by the slave detection processing and self-diagnosis processing after hard reset, and when the data transfer control device is set on the slave side by the master / slave setting terminal The slave detection signal and the self-diagnosis signal may be controlled after the hard reset.

  If the initialization sequence process is performed instead of the serial ATA device in this way, the serial ATA device without the concept of master / slave distinction is treated as a parallel ATA device that can distinguish master / slave. In addition, it is possible to realize proper initialization sequence processing conforming to parallel ATA.

  In the present invention, the sequence controller may perform a rewrite process for notifying the host of a slave detection result and a self-diagnosis result as the rewrite process.

  In this way, the slave detection result and self-diagnosis result can be appropriately notified to the host even when the initialization sequence management is performed.

  In the present invention, the parallel ATA interface includes a task file register, and the serial ATA interface includes a shadow task file register in which a register value is transferred to and from the task file register, When the data transfer control device is set to the master side and the host issues an ATA command to the master, the sequence controller uses the register value of the task file register as it is. When the host issues an ATA command to the slave while the data transfer control device is set to the slave side, the DEV bit of the task file register device / head register is set as the master. Before rewriting the settings The register value of the task file register may be transferred to the shadow task file register.

  In this way, since the DEV bit of the device / head register is rewritten to an appropriate value according to the state of the master / slave setting terminal, even when the data transfer control device is set to the slave side, for example, Therefore, it is possible to realize appropriate transfer processing of commands, parameters, etc., to the serial ATA device that recognizes itself as a master.

  Also, in the present invention, when the serial ATA interface receives an FIS corresponding to an ATA command from the host when the data transfer control device is set on the master side, the sequence ATA interface receives the FIS from the device. The register value of the shadow task file register is transferred to the task file register as it is, and when the data transfer control device is set to the slave side, the FIS corresponding to the ATA command from the host is transferred to the serial number. When the ATA interface receives from the device, the DEV bit of the device / head register of the shadow task file register is rewritten to the slave setting, and the register value of the shadow task file register is changed to the task file record. It may be transferred to the register.

  In this way, since the DEV bit of the device / head register is rewritten to an appropriate value according to the state of the master / slave setting terminal, even when the data transfer control device is set to the slave side, for example. From the serial ATA device that recognizes the device as a master, it is possible to implement appropriate transfer processing such as status to the host.

  In the present invention, the sequence controller may perform a process of rewriting the checksum parameter of the identified device information to an invalid setting as the rewriting process.

  In this way, it is possible to prevent an incorrect checksum result from being notified to the host by rewriting the identified device information.

  In the present invention, when the host issues an ATA command via the parallel ATA bus, the serial ATA interface sends a register FIS including the issued ATA command to the device via the serial ATA bus. When the serial ATA interface receives the FIS corresponding to the register FIS from the device, the sequence controller sets the received FIS type as the transfer sequence control of the ATA command issued from the host. In response to the transfer sequence control according to the command, if the ATA command issued from the host is the identified device command, the data FIS in which the identified device information is set is received. Occasionally, you may be subjected to transfer sequence control corresponding to the identify device command.

  In this way, the data transfer control device can directly transmit the register FIS including the ATA command to the device without decoding the detailed contents of the ATA command issued by the host. The transfer sequence is controlled by the type of FIS returned by the device to the register FIS. Therefore, the decoder circuit for the ATA command can be saved, and the data transfer control device can be reduced in size. In addition, even if a new command is added, this can be easily handled. In addition, since proper transfer sequence control according to the identify device command can be realized, the consistency of transfer between the host and the serial ATA device is realized while realizing the bus bridge function of the parallel ATA and the serial ATA. It can be maintained properly.

  According to another aspect of the invention, there is provided an electronic apparatus including the data transfer control device according to any one of the above, the host connected to the data transfer control device, and the device connected to the data transfer control device. .

  Hereinafter, preferred embodiments of the present invention will be described in detail. The present embodiment described below does not unduly limit the contents of the present invention described in the claims, and all the configurations described in the present embodiment are indispensable as means for solving the present invention. Not necessarily.

1. Configuration of Data Transfer Control Device FIGS. 1A and 1B show a configuration example of the data transfer control device of this embodiment. This data transfer control device has a PATA (Parallel AT Attachment) and SATA (Serial AT Attachment) bus bridge function.

  The data transfer control device according to the present embodiment is not limited to the configuration shown in FIGS. 1A and 1B, and some of the components (for example, a data buffer) may be omitted or other components (for example, Various modifications such as addition of an external I / F circuit, a CPU, and a timer are possible. For example, in addition to the PATA and SATA bus bridge functions, the data transfer control device of the present embodiment can realize a PATA and USB, PATA and SD (Secure Digital) card interface, and a PATA and CE-ATA bus bridge function. It may be.

  The PATA I / F 10 (parallel ATA interface) is connected to the PATA bus (ATA bus, IDE bus) and performs an interface with the host 2 (host device). Specifically, the PATA I / F 10 is connected to the host side PATA I / F of the host 2 via the PATA bus. Then, exchange is performed by various signals, which will be described later, standardized by ATA, thereby realizing PATA (IDE) data transfer. The PATA I / F 10 also performs data transfer control with the SATA I / F 50 via the data buffer 70. The PATA I / F 10 can include a task file register 12 (hereinafter referred to as TFR as appropriate) provided in a pseudo (virtual) manner for bridging between PATA and SATA.

  As the host 2, for example, a processor such as a CPU, MPU, or DSP, a dedicated control IC, or a host circuit board on which these processors or dedicated control ICs are mounted can be considered. As the device 4, various devices including a SATA I / F such as a hard disk drive (HDD), an optical disk drive (CD, DVD), and a magnetic disk drive are conceivable.

  The SATA I / F 50 (serial ATA interface) is connected to a SATA bus (high-speed serial bus) and interfaces with the SATA device 4. Specifically, the SATA I / F 50 is connected to the device-side SATA I / F of the device 4 and exchanges with a differential signal having a small amplitude to realize SATA data transfer. The SATA I / F 50 also performs data transfer control with the PATA I / F 10 via the data buffer 70. The SATA I / F 50 can include a SATA standard shadow task file register 52 (hereinafter referred to as SFR as appropriate).

  The sequence controller 30 performs transfer sequence control. Specifically, in order to realize a bridge function between PATA and SATA, sequence control of data transfer between the PATA I / F 10, the SATA I / F 50, and the data buffer 70 is performed, and transfer sequence control of register values is performed.

  The data buffer 70 buffers data transferred between the host 2 (PATA I / F) and the device 4 (SATA I / F). And it functions as a buffer (FIFO) for buffering to absorb the difference in clock frequency between the PATA side and the SATA side. That is, when the clock frequency on the PATA side is, for example, 50 MHz (or 60 MHz) and the clock frequency on the SATA side is, for example, 37.5 MHz, this clock frequency difference can be absorbed by providing the data buffer 70. The data buffer 70 includes a first port on the PATA I / F 10 side where data is input / output at, for example, 50 MHz (first frequency), and a SATAI where data is input / output at, for example, 37.5 MHz (second frequency). This can be realized by a dual port memory (RAM) having a second port on the / F50 side.

  1A and 1B, even when the host 2 has only the PATA I / F, the device 4 having the SATA I / F is connected to the host 2 through the data transfer control device. it can. Therefore, existing firmware and software for PATA (IDE) can be used as the firmware and software of the host 2. As a result, the development period of electronic devices can be shortened and costs can be reduced. Further, as the device 4, a large-capacity HDD having a large market supply amount can be connected to the host 2, and the capacity of the built-in HDD of the electronic device can be increased.

  In addition, since the circuit board on which the host 2 is mounted and the circuit board on which the device 4 is mounted can be connected by a SATA bus that is a serial bus, the number of wirings between the circuit boards can be reduced and the electronic equipment can be made compact. Can be planned.

  In the embodiment, as shown in FIG. 1A, the SATA I / F 50 corresponds to the identify device command when the host 2 issues an identify device command. Register FIS to be transmitted to the SATA device 4.

  As shown in FIG. 1 (B), the SATA I / F 50 includes the identification device information which is a return value of the identification device command (including the identification packet device command in ATAPI). The set data FIS is received from the device 4.

  Then, the sequence controller 30 performs rewriting processing of the identified device information set in the received data FIS. This rewriting process is performed by, for example, the parameter rewriting unit 36 included in the sequence controller 30.

  Then, the sequence controller 30 sets the identified device information after rewriting in the data register of the TFR 12. As a result, the rewritten identified device information is notified to the host 2 as the characteristic parameter of the device 4.

  For example, the SATA device 4 that operates at high speed may return a characteristic parameter that exceeds the hardware capability of the data transfer control device (LSI) as a return value of the identify device command issued by the host 2. Even in such a case, according to the present embodiment, the sequence controller 30 rewrites the characteristic parameters of the device 4 and the like, so that the consistency of data transfer between the host 2 and the device 4 cannot be achieved. Can be prevented.

  1A and 1B, the sequence controller 30 includes an initialization sequence management unit 34 that performs initialization sequence management in place of the SATA device 4 that does not have the initialization sequence management function. Then, the initialization sequence management unit 34 executes an initialization sequence process after a hardware reset (hardware reset) or the like.

  For example, since the SATA device 4 does not have a concept of distinguishing between master and slave, the SATA device 4 does not have an initialization sequence management function such as slave detection. Therefore, when the SATA device 4 is connected to the SATA bus of the data transfer control device having a PATA-SATA bridge function, there is no processing entity that performs initialization sequence management.

  In this regard, in FIGS. 1A and 1B, the initialization sequence management unit 34 performs initialization sequence management on behalf of the SATA device 4 that does not have the initialization sequence management function. Execute the process. Accordingly, the driver software operating on the host 2 can handle the SATA device 4 without the concept of master / slave distinction as if it were a PATA device capable of distinguishing between master and slave. Can be improved.

2. Detailed Configuration Example FIG. 2 shows a detailed configuration example of the data transfer control device. The PATA I / F 10 includes a task file register TFR 12 and a transfer controller 14. Here, the TFR 12 is a register provided in a pseudo manner for a PATA and SATA bus bridge. By providing the TFR 12, the host 2 can read and write data by treating the SATA device 4 as if it were a PATA device. That is, the host 2 can control the SATA device 4 using existing PATA firmware and software.

  The transfer controller 14 implements a PATA (IDE) interface using the PATA signals XCS to XPDIAG, and controls data transfer with the data buffer 70 using a data transfer control signal.

  The data buffer 70 includes a memory controller 72 and a FIFO memory (FIFORAM) 74. The memory controller 72 performs data write control and data read control of the FIFO memory 74. Further, data transfer control is performed between the PATA I / F 10 and the SATA I / F 50 using a control signal such as a REQ signal or an ACK signal.

  The SATA I / F 50 includes a shadow task file register SFR 52, a transport controller 110, a link controller 150, and a physical layer circuit 200.

  The transport controller 110, the link controller 150, and the physical layer circuit 200 are circuits that perform processing of the SATA standard transport layer, link layer, and physical layer, respectively.

  The shadow task file register SFR52 is a register standardized by SATA. That is, SATA is characterized in that compatibility at the software level is maintained with conventional PATA (IDE), and there are two task file registers. That is, the shadow task file register on the host (HBA) side and the original task file register on the device side.

  On the other hand, the TFR 12 provided in the PATA I / F 10 is not a register standardized by SATA, but a pseudo register provided for bridging the PATA and SATA. The host 2 recognizes and accesses the TFR 12 as a PATA task file register, writes the register value, and reads the register value. Then, the data transfer control device of this embodiment performs processing such as transferring the register value of the TFR 12 to the SFR 52 or transferring the register value of the SFR 52 to the TFR 12.

  In this way, when the host 2 writes a register value to the PATA TFR 12, the register value is transferred to the SATA SFR 52 and written to the device 4 via the SATA bus to FIS (Frame Information Structure). Will come to be. Further, the register value written in the SFR 52 by the FIS from the device 4 is transferred to the TFR 12 and read out to the host 2. Therefore, the host 2 can read and write data by treating the SATA device 4 as if it were a PATA device, and can efficiently implement a PATA-SATA bridge function.

  Note that transfer of register values between the TFR 12 and the SFR 52 can be realized by the following method. That is, the bits (all bits) of the register group of TFR 12 and the bits (all bits) of the register group of SFR 52 are connected via the signal line via the sequence controller 30. When transferring the register value, the sequence controller 30 generates a transfer trigger signal, and based on this transfer trigger signal, the register value of the TFR 12 is transferred to the SFR 52 or the register value of the SFR 52 is transferred to the TFR 12. That's fine.

3. PATAI / F
Next, the data transfer process of the PATA I / F 10 will be described using the configuration in FIG. 2 and the signal waveforms in FIGS. 3 (A) to 4 (B).

  XCS [1: 0] is a chip select signal used for accessing each register of PATA. DA [2: 0] is an address signal for accessing data or a data port. DMARQ and XDMACK are signals used for DMA transfer. When the device side is ready for data transfer, the device side activates (asserts) DMARQ, and in response, the host side activates XDMACK.

  XDIOW is a write signal used when writing to a register or a data port. XDIOR is a read signal used when reading a register or data port. IORDY is used as a wait signal when the device side is not ready for data transfer.

  INTRQ is a signal used by the device side to request an interrupt from the host side. After the INTRQ becomes active, when the host reads the contents of the status register of the TFR 12 on the device side, the device side deactivates INTRQ after a predetermined time. By using this INTRQ, the device side can notify the host side of the end of command processing.

  FIGS. 3A and 3B are signal waveform examples of PIO (Programmed I / O) read and PIO write. The PATA TFR 12 status register is read by the PIO read in FIG. 3A, and the command register is written by the PIO write in FIG. 3B. For example, the ATA command issued by the host 2 can be realized by PIO write.

  4A and 4B are signal waveform examples of DMA read and DMA write. When preparation for data transfer is completed, the device side (data transfer control device) activates DMARQ. In response to this, the host side activates XDMACK and starts DMA transfer. Thereafter, DMA transfer of data DD [15: 0] is performed using XDIOR (during reading) or XDIOW (during writing).

4). SATAI / F
Next, the data transfer process of the SATA I / F 50 will be described. FIG. 5 shows the flow of data transfer processing on the SATA transmission side, and FIG. 6 shows the flow of data transfer processing on the reception side.

  As shown in FIG. 5, in the transport controller (transport layer) on the transmission side, FIS (Frame Information Structure) is generated based on the command written in the shadow task file register and the data input to the data port. Here, FIS is a payload portion of a frame, and is configured in units of Dword (32 bits). The frame is an information unit exchanged between the host and the device. The SOF (Start Of Frame) primitive, the FIS, the CRC (Cyclic Redundancy Check) calculated for the FIS, and the EOF (End Of Frame) are used. ) Consists of primitives.

  In the link controller on the transmission side, the CRC for the FIS is calculated and added to the end of the FIS. Then, a scramble process is performed to obtain an exclusive OR (XOR) of the FIS and CRC and the scramble data. The 8b / 10b encoding is performed on the scrambled FIS and CRC. Here, 8b / 10b encoding is a data transmission encoding algorithm that converts 8-bit data into 10-bit transmission characters. The number of 1's and 0's in the code string is aligned to guarantee continuous transmission. Then, primitives such as SOF and EOF are added to the FIS and CRC after 8b / 10b encoding.

  In the physical layer circuit on the transmission side, parallel data from the link controller is converted into serial data and transmitted to the SATA bus as a differential signal with a small amplitude.

  As shown in FIG. 6, in the physical layer circuit on the receiving side, serial data received via the SATA bus is converted into parallel data.

  The link controller on the receiving side decodes the primitives added to the FIS and CRC. In addition, 8b / 10b decoding for FIS and CRC is performed. That is, a 10-bit transmission character is converted into 8-bit data. Next, a descrambling process is performed to obtain an exclusive OR of the scrambled FIS and CRC and the scrambled data. Then, the CRC added at the end of the FIS is checked.

  In the transport controller on the receiving side, the FIS command is written to the shadow task file register, status and interrupt are output, and data is output via the data port.

  FIG. 7 shows a format example of the ATA task file register. The task file register has a control block register and a command block register. When the chip select signals XCS0 and XCS1 are H level (negate) and L level (assert), the control block register is selected, and the L level, When it is at the H level, the command block register is selected. The command block register is provided with a status register (Status) and an ATA command register (ATA Command).

  8A to 8D show examples of FIS formats transmitted and received by the SATA I / F 50. FIG. 8A is a register FIS from the host to the device, FIG. 8B is a register FIS from the device to the host, FIG. 8C is a PIO setup FIS, and FIG. 8D is a DMA activate FIS format. is there.

5). Rewriting the Identified Device Information Next, the method for rewriting the identified device information according to the present embodiment will be described in detail.

5.1 Configuration FIG. 9 shows a specific configuration example of a data transfer control device that realizes the method of rewriting the identified device information according to the present embodiment.

  9, when the host 2 issues an identify device command and is written to the command register of the TFR 12 (ATA Command in FIG. 7), the written command and its register values such as parameters are sequenced from the TFR 12. The data is transferred to the SFR 52 via the controller 30. In this case, the sequence controller 30 decodes and analyzes the identified device command of the ATA commands, and stores that the identified device command has been issued.

  That is, as described later, in the present embodiment, when the host 2 issues an ATA command after writing a command parameter to the TFR 12, the command write is detected, and the written ATA command is not decoded. The register value is transferred (copied) to the SFR 52 as it is. A method of discriminating the type of FIS returned from the device 4 and controlling the subsequent transfer sequence is adopted. By adopting such a method, it is possible to save the ATA command decoding circuit, simplify the processing, and reduce the circuit scale.

  However, in the present embodiment, the issued device command is determined by decoding the issued command as an exception to the above method. Then, the fact that the identify device command has been issued is stored, and the subsequent transfer sequence control is executed. In other words, when the ATA command issued from the host 2 is an identified device command, when the data FIS in which the identified device information is set is received, the identified device command is changed to the identified device command. Perform the corresponding transfer sequence control. In this way, it is possible to realize proper rewriting processing of the identification device information while saving the command decoding circuit by not decoding commands other than the identification device command.

  When the identify device command is issued by the host 2 and the register value is transferred from the TFR 12 to the SFR 52, the SATA I / F 50 corresponds to the identify device command based on the register value of the SFR 52. A register FIS (see FIG. 8A) is generated and transmitted to the device 4, and data transfer of PIO read is executed.

  Then, after transmitting the PIO setup FIS, the device 4 receiving this register FIS transmits the data FIS in which the identified device information, which is the return value of the identified device command, is set. That is, the unit transfer of the PIO read constituted by the PIO setup FIS and the data FIS is performed. The SATA I / F 50 receives these PIO setup FIS and data FIS.

  In this case, register values such as status set in the PIO setup FIS are transferred (copied) from the SFR 52 to the TFR 12 via the sequence controller 30.

  On the other hand, the identified device information set in the data FIS is output from the SATA I / F 50 and written in the data buffer 70 (FIFO memory 70).

  When the sequence controller 30 receives the data FIS in which the identified device information is set, the sequence controller 30 performs rewriting processing of the identified device information. The rewritten identification device information is set in the data register of the TFR 12.

  Specifically, the sequence controller 30 reads the written device information from the data buffer 70 after the written device information is written in the data buffer 70. Then, the read identification device information is rewritten and written back to the data buffer 70. The rewriting process in this case is performed by the parameter rewriting unit 36 of the sequence controller 30.

  More specifically, when the sequence controller 30 receives the PIO setup transfer FIS for the PIO read transfer on the serial ATA side from the device 4 and then receives the data FIS for the PIO read transfer, as the identified device information, Wait until read data for one sector (512 bytes) is written to the data buffer 70. After the read data for one sector is written into the data buffer 70, the BUSY bit of the status register (Status in FIG. 7) of the TFR 12 is cleared to 0 and the DRQ (data request) bit is set to 1. In other words, the status register is set to 58h to notify the host 2 that the data request state is present.

  The sequence controller 30 instructs the PATA I / F 10 to start PIO read transfer on the parallel ATA side after setting the bit of the status register of the TFR 12 (58h) in this way. Specifically, the transfer start instruction signal PATATranGo output to the PATA I / F 10 is made active (asserted).

  For example, the sequence controller 30 determines whether or not read data for one sector is accumulated in the data buffer 70 based on the signal FIFOmain from the data buffer 70. The data size for one sector is determined based on the signal FISCount from the SATA I / F 50.

  Here, the signal FIFOmain is a signal indicating the accumulated data size (remaining data size) of the data buffer 70 (FIFO memory 74), and the sequence controller 30 uses the signal FIFOmain to store the data accumulated in the data buffer 70. Determine the size. The signal FISCount is a signal (for example, a 16-bit signal) indicating a transfer count value (Transfer Count in FIG. 8C) of the PIO setup FIS for PIO read transfer. The sequence controller 30 uses this signal FISCount. The size of the read data for one sector transferred by the data FIS is determined.

  Then, when the size of the read data stored in the data buffer 70 matches (exceeds) the data size (FISCount) for one sector, the sequence controller 30 stores the identified device information as the stored read data. Read from the data buffer 70.

  Specifically, the sequence controller 30 addresses the parameter that needs to be rewritten in the identified device information by the signal ADDR, and reads it from the data buffer 70 as the signal DIN. Then, the parameter rewriting unit 36 rewrites the parameters of the read identified device information. Then, the rewritten parameter is addressed by the signal ADDR and written back to the data buffer 70 as the signal DOUT.

  Subsequently, the sequence controller 30 clears the BUSY bit of the status register of the TFR 12 to 0 and sets the DRQ bit to 1. As a result, the host 2 is informed of the data request state.

  Next, the sequence controller 30 activates the transfer start instruction signal PATATranGo to the PATA I / F 10 and starts PIO read transfer in the PATA I / F 10. As a result, the read data for one sector (identified device information after rewriting) stored in the data buffer 70 is transferred to and written in the PATA data buffer 16 provided in the PATA I / F 10. Then, the read data (identified device information after rewriting) written in the PATA data buffer 16 is read by the host 2.

  In the present embodiment, the rewriting process of the identified device information is realized by the method as described above. In this way, only the information that needs to be rewritten is extracted from the identified device information set in the data FIS from the device 4, and the rewriting process is performed. Can be transferred to the host 2.

5.2 IDENTIFIED DEVICE INFORMATION Next, detailed description will be given of identified device information that is a target of the rewrite processing of the present embodiment.

  FIG. 10 shows an excerpt of the format of ATA's identified device information. The identified device information is 256 words (512 bytes) of information, and parameters are set for the bits of each word.

  For example, as indicated by E1 in FIG. 10, the IORDY parameter is set in bits 11 and 10 of the word 49 of the identified device information. Specifically, setting bit 11 of word 49 to 1 sets to support the IORDY signal, and setting bit 10 to 1 sets the IORDY signal to invalid (disabled).

  That is, when bit 11 is set to 1, it is selected to perform PIO transfer using the IORDY signal as shown in FIGS. 3A and 3B between the host and the device. On the other hand, setting bit 10 to 1 selects not to use the IORDY signal.

  In this embodiment, the data transfer control device is designed to perform PIO transfer using the IORDY signal as described with reference to FIGS. 3A and 3B. Therefore, the sequence controller 30 (parameter rewriting unit 36) rewrites the IORDY parameter of the identifier device information to a setting that supports IORDY. Specifically, even if bit 11 of word 49 is set to 0 or bit 10 is set to 1 by device 4, bits 11 and 10 are rewritten to 1 and 0, respectively (1 , 0 is overwritten). If the bits 11 and 10 of the word 49 are originally set to 1 and 0 by the device 4, the bits 11 and 10 of the word 49 after the rewriting process remain 1 and 0, respectively. .

  As indicated by E2 in FIG. 10, a transfer capability parameter (DMA transfer mode) is set in bits 6 to 0 of the word 88 of the identified device information. Specifically, when bit 6 is set to 1, it is set to support ultra DMA mode 6 or lower (ultra DMA modes 6 to 0). Similarly, when bits 5, 4, 3, 2, 1, 0 are set to 1, ultra DMA mode 5 or lower, 4 or lower, 3 or lower, 2 or lower, 1 or lower, or 0 is set.

  Since the SATA device 4 is generally high-speed, there are devices that operate in the fastest Ultra DMA mode 6. However, there is a limit to the high-speed operation of the data transfer control device, and even if the SATA device 4 that is bridge-connected can operate in the ultra DMA mode 6, the data transfer control device may not operate in the ultra DMA mode 6. .

  Therefore, in this embodiment, the transfer capability parameters such as bits 6 to 0 of the word 88 of the identifier device information are rewritten to parameters according to the transfer capability of the data transfer control device. For example, when the SATA device 4 can operate in the ultra DMA mode 6, the SATA device 4 sets bits 6 to 0 of the word 88 to (1111111). At this time, if the data transfer control device can operate in the ultra DMA mode 5 or lower but cannot operate in the ultra DMA mode 6, the sequence controller 30 rewrites bits 6 to 0 of the word 88 to (0111111). (Overwrite). In this way, even when the SATA device 4 tries to notify the host 2 that it is compatible with high-speed DMA transfer, it can be rewritten to correspond to the transfer capability of the data transfer control device. Appropriate data transfer control can be executed.

  Further, as shown at E3 in FIG. 10, the result of slave detection (XDASP) and self-diagnosis (XPDIAG) described later is set in the word 93 of the identified device information.

  Therefore, in this embodiment, a rewrite process (a rewrite process for reflecting) for notifying the host 2 of such slave detection results and self-diagnosis results is performed.

  For example, FIG. 11A shows a setting example of the word 93 when the data transfer control device is set on the master side by a method described later.

  For example, when bit 5 of word 93 is set to 1, the host 2 is notified that the data transfer control device on the master side has detected the presence of a slave (XDASP = L). On the other hand, when bit 5 is cleared to 0, the host 2 is notified that the presence of a slave has not been detected (XDASP = H).

  When bit 4 of word 93 is set to 1, the host 2 is notified that the data transfer control device on the master side has detected a slave self-diagnosis path (XPDIAG = L). On the other hand, when bit 4 is cleared to 0, the host 2 is notified that a slave self-diagnosis failure has been detected (XPDIAG = H).

  When bit 3 of word 93 is set to 1, the host 2 is notified that self (master) self-diagnosis has passed. On the other hand, when bit 3 is cleared to 0, the host 2 is notified that the self-diagnosis of itself (master) has failed.

  On the other hand, FIG. 11B shows a setting example of the word 93 when the data transfer control device is set to the slave side.

  For example, when bit 11 of word 93 is set to 1, the host 2 is notified that self (slave) self-diagnosis has passed. On the other hand, when the bit 11 is cleared to 0, the host 2 is notified that self (slave) self-diagnosis has failed.

  As described above, when the initialization sequence management unit 34 performs initialization sequence management on behalf of the SATA device 4 as described later, the result of the initialization sequence processing (slave detection result, self-diagnosis result) ) Can be reflected in the identification device information and notified to the host 2. Thus, even when the data transfer control device performs initialization sequence management, the result of the initialization sequence process can be properly notified to the host.

  Also, as indicated by E4 in FIG. 10, a checksum parameter is set in bits 15 to 8 of the word 255 of the identified device information. In this embodiment, this checksum parameter is rewritten to invalid setting. Specifically, when the checksum is calculated by the SATA device 4 and the result of the checksum is written into bits 15 to 8 of the word 255, the checksum of bits 15 to 8 is rewritten to (00000000) ( Overwrite). If the checksum is set to (00000000) in this way, the checksum becomes invalid and is treated as if the checksum was not calculated.

  That is, in this embodiment, the identify device information set by the SATA device 4 is rewritten on the data transfer control device side. Therefore, the checksum calculated on the SATA device 4 side is meaningless in the rewritten identified device information and becomes an incorrect checksum. Therefore, if such an incorrect checksum is notified to the host 2, there is a risk of malfunction. In this case, a method of recalculating the checksum for the identified device information after rewriting is also conceivable, but this causes an increase in processing load and an increase in circuit scale.

  Therefore, in this embodiment, the checksum parameter is rewritten to an invalid setting to prevent the host 2 from being notified of an incorrect checksum result.

  Note that the rewrite processing of the identifier device information is not limited to FIGS. 10 and 11. For example, rewriting processing such as setting the master and slave to always be set by jumpers may be performed.

5.3 Operation Next, details of the operation of the present embodiment will be described with reference to the flowchart of FIG.

  When the host 2 issues an identify device command, the sequence controller 30 sets the BUSY bit of the status register of the TFR 12 to 1 (steps S71 and S72). As a result, the host 2 is notified that it is busy.

  Next, the SATA I / F 50 transmits the register FIS to the device 4 (step S73). Then, the PIO setup FIS is received from the device 4, and subsequently, the data FIS in which the identified device information is set in the data field is received from the device 4 (steps S74 and S75). As a result, one unit of PIO transfer on the SATA bus side is executed.

  Next, the sequence controller 30 determines whether or not the accumulated data size of the data buffer 70 (buffer FIFO) matches (exceeds) the number of transfer bytes (512 bytes) for one sector (step S76). ). That is, it is determined whether or not read data for one sector is stored in the data buffer 70 based on the signal FIFOMain and the signal FISCount in FIG.

  When the accumulated data size matches the number of transfer bytes for one sector, the rewriting process of the identification device information (read data) written in the data buffer 70 is performed (step S77). Specifically, as described in FIG. 10 and FIG. 11, rewriting of transfer capability parameter, rewriting of IORDY parameter, rewriting to reflect slave detection result (XDASP), self-diagnosis result (XPDIAG), rewriting of checksum parameter, etc. I do.

  Next, the BUSY bit of the status register of the TFR 12 is cleared to 0 and the DRQ bit is set to 1 (step S78). As a result, the host is notified of the data request state. Thereafter, the PATA I / F 10 is instructed to start PIO read transfer (step S79). Specifically, PATATranGo in FIG. 9 is activated. As a result, the host 2 starts data read (step S80), and the rewritten identified device information is transferred to the host 2.

5.4 IORDY signal PATA (IDE) defines a wait period tB in which the IORDY signal is at L level (inactive, negated) as shown in FIG. That is, in PIO read, the device side sets the IORDY signal to L level (inactive, negated) and then to H level (active, asserted), so that read data is ready (data is ready). The host is notified). When the IORDY signal changes from the L level to the H level, the host changes the XDIOR signal from the L level to the H level, and performs the read operation of the data DD [15: 0].

  Therefore, if the wait period tB becomes long, the host waits unnecessarily for a long time. For this reason, the length of the wait period tB is determined by the standard, and if the wait period tB is longer than the predetermined period, the IORDY signal assert timing is violated.

  However, in the data transfer control device having the PATA-SATA bridge function as in this embodiment, if the data transfer on the SATA side is delayed, there is a possibility that the standard for the period tB in FIG. 13 cannot be observed. Therefore, in the present embodiment, a method for generating an IORDY signal as described below is adopted.

  For example, in FIG. 9, the data from the host 2 is buffered in the PATA data buffer 16 at the time of writing, and the data in the PATA data buffer 16 is stored in the data buffer 70. In the PATA data buffer 16, data from the data buffer 70 is buffered at the time of reading, and data in the PATA data buffer 16 is output to the host 2.

  Further, the I / F signal generation circuit 18 in FIG. 9 generates the PATA signals XCS to XPDIAG shown in FIG. The I / F signal generation circuit 18 includes an IORDY signal generation circuit 19. The IORDY signal generation circuit 19 generates an IORDY signal among the PATA signals. The IORDY signal functions as a data ready signal (wait signal) to the host 2 during PIO read transfer.

  As shown in FIG. 14A, for example, a set timing signal of the TFR 12 of the PATA I / F 10 and an empty signal of the PATA data buffer 16 are input to the IORDY signal generation circuit 19.

  Here, the set timing signal becomes active, for example, at the timing when the register value set in the SFR 52 is transferred to the TFR 12 and written. Specifically, as shown in step S78 of FIG. 12, the signal becomes active at the timing when the bit of the status register of TFR 12 is set (BUSY = 0, DRQ = 1). On the other hand, the empty signal of the PATA data buffer 16 becomes active when no data is stored in the PATA data buffer 16.

  When such a set timing signal and empty signal are input, the IORDY signal generation circuit 19 generates an IORDY signal having a timing as shown in FIG. Specifically, when the bit of the status register of TFR12 is set (BUSY = 0, DRQ = 1) (timing TG1), it becomes inactive (L level), and is the identified device information after rewriting. When the read data is accumulated in the PATA data buffer 16 (timing TG2), an IORDY signal that becomes active (H level) is generated.

  That is, when the set timing signal in FIG. 14A becomes active, the IORDY signal becomes inactive (L level) at the timing TG1 in FIG. 14B. When the empty signal in FIG. 14A becomes inactive and data is accumulated in the PATA data buffer 16, the IORDY signal becomes active (H level) at timing TG2 in FIG. 14B. When the IORDY signal becomes active, the host 2 sets the XDIOR signal to the H level and reads the data DD [15: 0] from the PATA data buffer 16.

  In this way, for example, when a bit is set in the status register of the TFR 12 in step S78 in FIG. 12, the IORDY signal becomes inactive at the timing TG1 in FIG. 14B. When the start of PIO read transfer is instructed in step S79 in FIG. 12, the IORDY signal becomes active at timing TG2 in FIG. Therefore, even when the SATA device 4 is bridge-connected via the data transfer control device, the wait period tB can be suppressed to a minimum length, and the occurrence of an IORDY signal assert timing violation can be effectively prevented.

6). Initialization Sequence Next, the initialization sequence processing method of the present embodiment will be specifically described.

6.1 CSEL Terminal In a PATA device system, up to two devices can be connected to the PATA bus, and one of these two devices becomes a master and the other becomes a slave. Each device determines whether it is a master or a slave by setting a jumper pin or setting a cable select. Also, when two devices are connected to the PATA bus, the same address is shared between the two devices. Therefore, when there is a write operation from the host to the ATA register (task file register), both the master and slave devices are connected from the PATA data DD [15: 0] (see FIG. 2) bus. Receiving the data, each device determines whether the data is addressed to itself based on the DEV bit or the like. When there is a read operation from the host to the ATA register, the master and slave devices compare the DEV bit state at that time with their own device numbers, and are accessed only when they match. The contents of the ATA register are output to the bus of data DD [15: 0].

  As described above, the PATA device has a concept of distinguishing between master and slave. For example, a system in which a device such as an HDD is connected to the master side of the ATA and a device of an optical disk drive such as a CD or DVD is connected to the slave side. Configuration is possible.

  However, the SATA device has no concept of distinguishing between master and slave, and the SATA device is treated as a master. Therefore, when the data transfer control device is provided with a PATA and SATA bridge function, if the device is not devised, for example, it becomes a data transfer control device dedicated to the master that can handle the SATA device only as the master. Therefore, for example, there is a problem that a system configuration or the like in which a SATA device such as an optical disk drive is connected as a slave to the PATA bus via the data transfer control device of this embodiment cannot be realized.

  Therefore, in this embodiment, a CSEL terminal which is a master / slave setting terminal (determination terminal) is provided in the data transfer control device. The data transfer control device determines whether it is the master side or the slave side based on the state (voltage setting state) of the CSEL terminal.

  For example, in FIG. 15A, the CSEL terminal is set to L level (GND level), and in this case, the data transfer control device 3 of this embodiment determines that it is set to the master side. The data transfer control device 3 and the SATA device 4 connected thereto constitute a PATA master side. Accordingly, a system configuration in which the PATA master side including the data transfer control device 3 of the present embodiment and the PATA slave side are connected to the PATA bus can be realized.

  On the other hand, in FIG. 15B, the CSEL terminal is set to H level (VDD level). In this case, the data transfer control device 3 of this embodiment determines that it is set to the slave side. The data transfer control device 3 and the SATA device 4 connected thereto constitute the PATA slave side. Thereby, a system configuration in which the PATA master side and the PATA slave side including the data transfer control device 3 of the present embodiment are connected to the PATA bus can be realized.

  As described above, in the present embodiment, since the CSEL terminal which is the master / slave setting terminal is provided for the data transfer control device 3 having the PATA and SATA bridge functions, for example, the master / slave is originally distinguished. The SATA device 4 that is handled only as a master and is bridged to the PATA bus via the data transfer control device 3 can be configured as the PATA slave side. As a result, for example, a system configuration in which an optical disk drive having a SATA interface or the like as a slave is bridge-connected to the PATA bus can be realized, and the convenience can be greatly improved.

6.2 Proxy for Initialization Sequence Management As described above, there is no concept of master / slave differentiation in SATA devices, and SATA devices are handled only as masters. Therefore, the SATA device does not have an initialization sequence management function for distinguishing between a master and a slave. Accordingly, when such a SATA device is bridge-connected to the PATA bus via a data transfer control device having a PATA-SATA bridge function, there is no problem that there is no processing entity that performs the initialization sequence process. There is.

  Therefore, in the present embodiment, the initialization sequence management unit 34 in FIGS. 1A and 1B performs initialization sequence management in place of the SATA device 4 that does not have an initialization sequence management function in PATA. For example, the initialization sequence management unit 34 executes the initialization sequence process when the presence of the SATA device 4 is detected within the device presence detection period (10 ms) after the hard reset. Specifically, after the hard reset, the SATA I / F 50 on the host side issues COMRESET in the OOB sequence and detects COMINIT from the SATA device 4. Then, when the COMINIT from the SATA device 4 is detected within the device presence detection period (10 ms), the initialization sequence management unit 34 determines that the SATA device 4 exists, and performs the initialization sequence processing according to the present embodiment. Execute.

  More specifically, the initialization sequence management unit 34, after the hard reset, when the data transfer control device 3 is set to the master side by the CSEL terminal (master / slave setting terminal) as shown in FIG. Performs slave detection processing and self-diagnosis processing. On the other hand, when the data transfer control device 3 is set to the slave side by the CSEL terminal as shown in FIG. 15B, the slave detection signal and the self-diagnosis signal are controlled after the hard reset.

  In this way, even when the SATA device 4 does not have the initialization sequence management function, the data transfer control device 3 performs the initialization sequence management in PATA such as slave detection in place of this initialization sequence management. Can be executed. Therefore, when the SATA device 4 that is handled only as a master is bridge-connected to the PATA bus via, for example, the data transfer control device 3 and the PATA slave side is configured, an appropriate initialization sequence process based on the PATA standard is performed. Can be executed.

  Next, the details of the initialization sequence process will be described with reference to FIGS. FIG. 16 is a flowchart for explaining the operation on the host side, and FIG. 17 is a flowchart for explaining the operation on the device side.

  As shown in FIG. 16, the host side makes the hard reset signal active (asserted) and then inactive (negated) (steps S21 and S22). Then, it waits for the BUSY bit of the status register to be cleared from 1 to 0, and when it is cleared to 0, it shifts to the host idle state (steps S23 and S24).

  On the other hand, as shown in FIG. 17, when a hard reset is performed, the device side shifts to a release bus state and determines whether or not CSEL (CSEL terminal, CSEL signal) is at L level (steps S31, S32, S33). ). That is, it is determined whether it is set on the master side or the slave side.

  If it is determined that the CSEL is set to the L level and that the CSEL is set to the master side, the process shifts to the XDASP wait state and then shifts to the sample XDSAP state (steps S34 and S35). In this sample XDSAP state, it performs initialization and self-diagnosis processing of itself, and samples and monitors the slave detection signal XDASP from the slave side.

  If it is determined that the signal XDASP is at the L level (active), it is determined that the presence of the slave is detected, and the state shifts to the sample XPDIAG state (steps S36 and S37). In the sample XPDIAG state, a self-diagnosis signal XPDIAG (slave self-diagnosis result notification signal) from the slave is sampled and monitored.

  If it is determined that the signal XPDIAG is at L level (active), it is determined that the self-diagnosis on the slave side has passed, and bit 7 of the error register of the task file register is set to 0 (steps S38 and S39). ). On the other hand, if it is determined that the signal XPDIAG is at the H level (inactive), it is determined that the self-diagnosis on the slave side has failed, and bit 7 of the error register is set to 1 (step S40). If it is determined in step S36 that the signal XDASP is at the H level, it is determined that there is no slave and bit 7 of the error register is set to 0 (step S41). Then, the process proceeds to the set status state (step S42), the self-diagnosis process is completed, and the BUSY bit of the status register of the task file register is cleared to 0. And it transfers to a device idle state (step S43).

  On the other hand, if it is determined in step S33 that CSEL is set to the H level and the slave is set on the slave side, the process proceeds to the set XDASP state (step S44). In this set XDASP state, the slave detection signal XDASP is set to L level (active), and its own initialization and self-diagnosis processing are performed. As described above, when the slave side sets the slave detection signal XDASP to the L level, the master side can detect the presence of the slave as shown in step S36.

  Next, the process proceeds to the set status state (step S45). Then, the self-diagnosis signal XPDIAG is set to L level (active) or H level (inactive), the BUSY bit of the status register of the task file register is cleared to 0, and the device idle state is entered (step S46). Thus, by setting the signal XPDIAG to the L level on the slave side, the master side can determine that the self-diagnosis on the slave side has passed as shown in step S39. Further, by setting the signal XPDIAG to the H level on the slave side, the master side can determine that the self-diagnosis on the slave side has failed as shown in step S40.

  In this embodiment, when the initialization sequence management unit 34 determines that the CSEL terminal is set to the L level and itself is set to the master side, as illustrated in steps S34 to S43 in FIG. Perform detection processing and self-diagnosis processing. That is, it is determined whether or not a slave is detected based on the signal XDASP, and self-diagnosis processing on the master side and confirmation processing on the slave side self-diagnosis result based on the signal XPDIAG are performed.

  When the initialization sequence management unit 34 determines that the CSEL terminal is set to the H level and is set to the slave side, the initialization sequence management unit 34, as shown in steps S44 to S46 in FIG. The diagnostic signal XPDIAG is controlled. That is, the slave detection signal XDASP is set to the L level to notify the master of the existence of the slave. Further, the self-diagnosis signal XPDIAG is set to L level or H level, and the self-diagnosis result on the slave side is notified to the host side.

  By substituting the initialization sequence processing as described above to the initialization sequence management unit 34, the concept of master / slave distinction can be introduced into a SATA device handled only as a master and an appropriate one according to the PATA standard can be introduced. An initialization sequence process can be realized.

6.3 Setting of DEV Bit As described above, in PATA, the bus of data DD [15: 0] and address DA [2: 0] is shared by the master and the slave. Therefore, both the master and the slave receive commands and parameters from the bus of the data DD [15: 0] via the task file register. Then, it is determined by the DEV bit of the device / head register whether the address is for the master or the slave. Specifically, when the DEV bit is 0, it is determined that the address is for the master, and when the DEV bit is 1, it is determined that the address is for the slave.

  On the other hand, the SATA device is always handled as a master. Therefore, the SATA device receives only commands and parameters with the DEV bit set to 0 as being addressed to itself.

  However, as shown in FIG. 15B, when the CSEL terminal is set to the H level and the slave is set, the host 2 regards the SATA device 4 as a slave. Therefore, when a command or parameter is sent to the SATA device 4, the DEV bit is set to 1 which is a slave setting. Therefore, the SATA device 4 that is recognized as the master cannot receive these commands and parameters. Therefore, in the present embodiment, the following DEV bit setting method is adopted.

  For example, in FIG. 18A, the CSEL terminal (CSEL signal) is set to L level, and the data transfer control device is set to the master side. The host 2 issues an ATA command to the master. In this case, the sequence controller 30 transfers the register value (command, parameter) of the TFR 12 to the SFR 52 as it is. Then, the SATA I / F 50 generates a register FIS (Host to Device) or the like based on the register value of the SFR 52 and transmits it to the SATA device 4.

  At this time, the DEV bit = 0 (master setting) of the device / head register of the TFR 12 is also transferred as it is from the TFR 12 to the SFR 52 and transmitted to the SATA device 4. Since the SATA device 4 recognizes itself as a master, it can receive commands and parameters from the host 2 without any problem.

  In FIG. 18B, when the data transfer control device is set on the master side, the FIS (for example, register FIS, PIO setup FIS, DMA activate FIS, etc.) corresponding to the ATA command from the host 2 is changed to SATAI. / F50 is received from the SATA device 4. In this case, the sequence controller 30 transfers the register value of the SFR 52 to the TFR 12 as it is. Then, the host 2 receives the status and the like from the SATA device 4.

  At this time, the DEV bit = 0 (master setting) of the device / head register of the SFR 52 is also transferred from the SFR 52 to the TFR 12 as it is. Therefore, the PATA I / F 10 can appropriately output the status from the SATA device 4 on the master side to the PATA DD [15: 0] bus.

  On the other hand, in FIG. 19A, the CSEL terminal is set to H level, and the data transfer control device is set to the slave side. The host 2 issues an ATA command to the slave. In this case, the sequence controller 30 rewrites the DEV bit of the device / head register from 1 (slave setting) to 0 (master setting), and transfers the register value of the TFR 12 to the SFR 52. Then, the SATA I / F 50 generates a register FIS (H to D) or the like based on the register value of the SFR 52 and transmits it to the SATA device 4.

  At this time, the SATA device 4 recognizes itself as a master, but in this embodiment, since the DEV bit is rewritten from 1 (slave setting) to 0 (master setting), the command or parameter from the host 2 is not changed. We can receive without problem.

  In FIG. 19B, when the data transfer control device is set to the slave side, the SATA I / F 50 receives the FIS corresponding to the ATA command from the host 2 from the SATA device 4. In this case, the sequence controller 30 rewrites the DEV bit of the device / head register of the SFR 52 from 0 (master setting) to 1 (slave setting), and transfers the register value of the SFR 52 to the TFR 12. Then, the host 2 receives the status and the like from the SATA device 4.

  At this time, the host 2 recognizes the SATA device 4 as a slave, but in this embodiment, since the DEV bit is rewritten from 0 (master setting) to 1 (slave setting), the status from the SATA device 4 and the like. Can be received without any problems.

  As described above, in this embodiment, the DEV bit of the device / head register is rewritten to an appropriate value according to the state of the CSEL terminal. Therefore, even when the data transfer control device is set to the slave side by the CSEL terminal, appropriate transfer processing of commands, parameters, and status is performed between the host 2 and the SATA device 4 that recognizes itself as the master. realizable.

  Next, the DEV bit setting method of the present embodiment will be described in more detail with reference to the flowcharts of FIGS.

  In FIG. 20, the host 2 issues an ATA command to the master (step S51). Then, it is determined whether or not the CSEL terminal is at the L level (step S52). If the CSEL terminal is at the L level, the register value of the TFR 12 is directly transferred to the SFR 52 as described with reference to FIG. 18A (step S53). Then, the command is transferred and executed to the SATA device 4 (step S54).

  Next, when an FIS (register FIS or the like) for status return is received from the SATA device 4 (step S55), the register value of the SFR 52 is directly transferred to the TFR 12 as described with reference to FIG. 18B (step S56). .

  On the other hand, if it is determined in step S52 that the CSEL terminal is at the H level, the ATA command issued by the host 2 is not executed (step S57). That is, since the ATA command issued by the host 2 is addressed to the master and the CSEL terminal is set on the slave side, the data transfer control device on the slave side does not execute this ATA command execution process.

  In FIG. 21, the host 2 issues an ATA command to the slave (step S61). Then, it is determined whether or not the CSEL terminal is at the L level (step S62). If the CSEL terminal is at the H level instead of the L level, the DEV bit of the device / head register of the TFR 12 is set to 0 as described with reference to FIG. Rewriting to (master setting), the register value of TFR12 is transferred to SFR52 (step S63). Then, the command is transferred and executed to the SATA device 4 (step S64).

  Next, when an FIS (register FIS or the like) for status return is received from the SATA device 4 (step S65), the DEV bit of the device / head register of the SFR 52 is set to 1 (slave setting) as described with reference to FIG. ) And the register value of the SFR 52 is transferred to the TFR 12 (step S66).

  On the other hand, if it is determined in step S62 that the CSEL terminal is at the L level, the ATA command issued by the host 2 is not executed (step S67). That is, since the ATA command issued by the host 2 is addressed to the slave and the CSEL terminal is set on the master side, the data transfer control device on the master side does not execute this ATA command execution process.

7). Transfer sequence control according to the type of reception FIS In a data transfer control device having a bridge function as in this embodiment, it is necessary to perform transfer sequence control according to an ATA command issued by the host 2. In order for the data transfer control device to know the contents of the transfer sequence control, it is necessary to decode the ATA command. For this purpose, a command decoder and a parameter table are required. That is, the command issued by the host 2 is decoded, the transfer direction (read, write) and transfer type (PIO (Programmed I / O), DMA) are determined, and the internal transfer sequence is determined.

  However, providing such a command decoder leads to an increase in the scale of the logic circuit of the data transfer control device and an increase in memory capacity. In addition, in order to decode an ATA command, it must have a command table for decoding. If a new command is added in the standard after development of the data transfer control device is completed, the data transfer control device Unless the circuit is corrected, new commands cannot be supported. For example, in ATAPI, when a new standard optical disc drive such as a Blu-ray disc is added, the parameter table must be changed. Therefore, it is not possible to use an existing data transfer control device for which development has been completed, and it is necessary to modify a circuit for changing the parameter table (table memory), resulting in an extra development period and development cost. Furthermore, it is difficult to deal with special commands unique to vendors.

  In this case, if the CPU (processing unit) is built in the data transfer control device and the parameter table is changed by rewriting the firmware or the like, even if new commands increase or the contents of the commands are changed, Yes.

  However, if the CPU is built in the data transfer control device, it will be necessary to develop firmware that runs on the CPU, and to develop a debugging tool for checking the operation of the CPU. Invite

  In the method shown in FIGS. 22A to 23C for solving such a problem, the command issued by the host is transferred to the device without decoding, and the FIS information returned from the device is used. Based on this, the transfer sequence for the issued command is controlled. That is, the ATA command is not decoded by the data transfer control device, but is made to be performed by the SATA device. Then, the data transfer control device transfers the ATA command to the SATA device without decoding the ATA command (or may decode a part thereof), and determines its own transfer sequence by observing the reaction of the SATA device. Execute.

  Specifically, as shown in FIG. 22A, when the host 2 issues an ATA command (transfer command) via the PATA bus, the PATA I / F 10 receives this command. Then, the SATA I / F 50 creates a register FIS (Host to Device) including the issued ATA command and transmits it to the device 4 via the SATA bus.

  When the SATA I / F (not shown) on the device 4 side receives the register FIS, the SATA I / F performs decoding processing, transmits the FIS corresponding to the register FIS (ATA command), and the SATA I / F 50 receives this FIS.

  When the SATA I / F 50 receives the FIS corresponding to the register FIS from the device 4, the sequence controller 30 (transfer sequencer, bridge sequencer) responds to the type of received FIS as the transfer sequence control of the ATA command issued from the host 2. Perform transfer sequence control.

  More specifically, in FIG. 22B, the host 2 issues a PIO read ATA command. In this case, the device 4 transmits a PIO setup FIS whose transfer direction is the read direction. That is, the device 4 transmits the PIO setup FIS, which is the FIS that the device 4 transfers to the host 2 immediately before the PIO data transfer, and the SATA I / F 50 receives it. This PIO setup FIS has an initial status (Status) and a status end value (E_Status) of data transfer.

  As described above, when the reception FIS is the PIO setup FIS and the transfer direction designated by the PIO setup FIS is the read direction, the sequence controller 30 performs the transfer sequence control of the PIO read. That is, the sequence controller 30 outputs control signals (transfer direction setting signal, transfer start signal, transfer stop signal, etc.) for the transfer sequence of the PIO read to the SATA I / F 50, the data buffer 70, and the PATA I / F 10. Thereby, the data read from the device 4 is transferred to the host 2 via the SATA I / F 50, the data buffer 70, and the PATA I / F 10.

  In FIG. 22C, the host 2 issues an ATA command for PIO write. In this case, the device 4 transmits the PIO setup FIS whose transfer direction is the write direction, and the SATA I / F 50 receives it.

  As described above, when the reception FIS is the PIO setup FIS and the transfer direction designated by the PIO setup FIS is the write direction, the sequence controller 30 performs the transfer sequence control of the PIO write. That is, the sequence controller 30 outputs a control signal for the PIO write transfer sequence to the PATA I / F 10, the data buffer 70, and the SATA I / F 50. As a result, data from the host 2 is transferred to the device 4 via the PATA I / F 10, the data buffer 70, and the SATA I / F 50.

  In FIG. 23A, the host 2 issues an ATA command for DMA read. In this case, the device 4 transmits data FIS. That is, the device 4 transmits a data FIS, which is an FIS for data transfer, and the SATA I / F 50 receives it.

  Thus, when the reception FIS is the data FIS, the sequence controller 30 performs a DMA read transfer sequence control. Thereby, the data read from the device 4 is DMA-transferred to the host 2 via the SATA I / F 50, the data buffer 70, and the PATA I / F 10.

  In FIG. 23B, the host 2 issues a DMA write ATA command. In this case, the device 4 transmits a DMA activate FIS. That is, the device 4 transmits the DMA activate FIS for informing the host 2 that the DMA is ready for execution, and the SATA I / F 50 receives it.

  As described above, when the reception FIS is the DMA activate FIS, the sequence controller 30 performs the DMA write transfer sequence control. As a result, the data from the host 2 is DMA-transferred to the device 4 via the PATA I / F 10, the data buffer 70, and the SATA I / F 50.

  In FIG. 23C, the host 2 issues an ATA command of no data command. In this case, the device 4 transmits a register FIS (Device to Host), and the SATA I / F 50 receives it. Thus, when the reception FIS corresponding to the ATA command is the register FIS from the device 4 to the host 2, the sequence controller 30 determines that the ATA command issued from the host 2 is a no-data command. . Then, the register value of the register FIS is reflected from the shadow task file register of the SATA I / F 50 to the task file register of the PATA I / F 10.

  As described above, according to the method shown in FIGS. 22A to 23C, the ATA command issued by the host 2 is issued based on the received FIS information from the device 4 without decoding. The transfer sequence control corresponding to the ATA command can be realized by determining the type of the ATA command. Therefore, the circuit of the command decoder can be saved and the data transfer control device can be reduced in size. Further, even if a new command is added in the standard, it can be dealt with without modifying the circuit of the data transfer control device. Further, since it is not necessary to incorporate a CPU in the data transfer control device, development of firmware that operates on the CPU and development of a debug tool become unnecessary, and the development period can be shortened and development cost can be reduced. The data transfer control device may be provided with a circuit for decoding a part of the ATA command or may be modified by incorporating a CPU (processing unit).

  If the method of FIGS. 22A to 23C as described above is adopted, the command decoding circuit can be saved. However, when the host 2 issues an identify device command, FIGS. As described with reference to FIG. 14B, transfer sequence control different from normal PIO transfer is required. For example, as described with reference to FIG. 9, the read sequence that is the identification device information is read from the data buffer 70, rewritten and rewritten, and the transfer sequence control described with reference to FIGS. 13 to 14B. Such special transfer sequence control for the IORDY signal is required.

  Therefore, in this embodiment, in addition to performing transfer sequence control according to the type of reception FIS as shown in FIGS. 22A to 23C, an ATA command issued from the host 2 is used for the identity verification. In the case of a device command, when the data FIS in which the identifier device information is set is received, the identifier device command as described with reference to FIGS. Perform the corresponding transfer sequence control. In this way, it is possible to properly maintain transfer consistency between the host and the SATA device while realizing a PATA and SATA bus bridge function.

  FIG. 24 is a PIO read transfer sequence diagram. When the PIO read command is issued by the host 2, the status register of the TFR 12 is set to D0h as indicated by A1 in FIG. In other words, the BUSY bit is set to 1 by the PATA I / F 10, and the host 2 is informed that the device 4 is busy. Then, the register value of TFR 12 is transferred (copied) to SFR 52 by sequence controller 30. Then, as indicated by A2, the SATA I / F 50 creates a register FIS (Host to Device) including a PIO read command based on the register value of the SFR 52, and transmits it to the device 4 via the SATA bus.

  The device 4 that has received this register FIS transmits a PIO setup FIS as shown at A3. In this case, 58h is set in the status (Status) of the PIO setup FIS in FIG. 8C, and D0h is set in the end status (E_Status). Here, the BUSY bit is set to 1 at D0h, and the DRQ bit is set to 1 at 58h. At 50h, both the BUSY bit and the DRQ bit are cleared (released) to 0. The end status is stored in, for example, a temporary storage register of the SATA I / F 50.

  When the sequence controller 30 receives the PIO setup FIS from the device 4 and the direction parameter D (see FIG. 8C) is the direction from the device to the host, the command issued by the host 2 is a PIO read. Judge that there is. Then, the register value is transferred from the SFR 52 to the TFR 12, the status register of the TFR 12 is set to 58h as indicated by A4, and the DRQ bit is set to 1. As a result, an interrupt INTRQ for the host 2 is generated. Note that polling by the host 2 may be employed instead of INTRQ.

  When the data FIS is received from the device 4 and the host 2 reads the data, as shown in A5, the end status D0h of the PIO setup FIS is set in the status register of the TFR 12, and the BUSY bit is set to 1. . That is, the end status (D0h) stored in the temporary storage register of the SATA I / F 50 is transferred and written to the status register of the TFR 12. This informs the host 2 that the device 4 is busy.

  As described above, the PIO read of each sector is repeated. As shown in A6, the end status is 50h or 51h in the PIO setup FIS of the last sector. Therefore, as shown at A7, the end status 50h or 51h is set in the status register of the TFR 12, and the DRQ bit is cleared. As a result, the host 2 is informed that all data transfer has been completed.

8). SATA I / F Configuration FIG. 25 shows a configuration example of the SATA I / F 50. Note that the configuration of the SATA I / F 50 is not limited to that shown in FIG. 25, and various modifications such as deleting some of the components or adding other components are possible. For example, the physical layer circuit 200 may be omitted.

  In SATA, data is processed in units of 32 bits (4 bytes). The 32-bit data is encoded at 8b / 10b by the link controller 150 to become 40-bit data, which is sent to the physical layer circuit 200. The physical layer circuit 200 serializes the 40-bit data and transmits it to the SATA cable. In the reverse order of reception, the serial data is converted into 40-bit data by the physical layer circuit 200, converted into 32-bit data by the link controller 150, and sent to the transport controller 110.

  The transport controller 110 controls the transport layer. Specifically, the transport controller 110 performs the following processing when an FIS transmission request is received from an upper layer (application layer).

  First, the transport controller 110 collects the contents of the FIS based on the requirements of the FIS type. Information to be transmitted is arranged in a definition format for each type of FIS. Next, a transmission request is notified to the link controller 150. As a result, the link controller 150 performs X_RDY transmission processing. When the R_RDY from the partner node is received and an acknowledgment from the link controller 150 is received, the transport controller 110 transfers the FIS to the link controller 150. Then, flow management of the transmission FIFO 120 is performed, and necessary flow control is notified to the link controller 150. Thereafter, when a transmission result is received from the link controller 150, the transmission result is notified to an upper layer as necessary.

  When the transport controller 110 receives the FIS from the link controller 150, the transport controller 110 performs the following processing.

  When the transport controller 110 receives the FIS from the link controller 150, the transport controller 110 determines the type of the received FIS. Then, the data is transferred to an appropriate register or FIFO according to the type of FIS. Then, flow management of the reception FIFO 122 is performed, and necessary flow control is notified to the link controller 150. Thereafter, the reception result is notified to the link controller 150 and the upper layer (application layer).

  The link controller 150 controls the link layer. Specifically, the link controller 150 performs the following processing at the time of transmission.

  First, the link controller 150 receives data (FIS) from the transport controller 110. A FIS CRC is generated and added to the end of the FIS. Next, the data is scrambled, and then 8b / 10b encoding is performed. Then, the primitive and FIS are transmitted according to the SATA communication protocol. The transmission result is notified to the transport controller 110.

  The link controller 150 performs the following processing upon reception. That is, the link controller 150 receives the 8b / 10b encoded character from the physical layer circuit 200. Then, the 8b / 10b encoded character is decoded, and the decoded primitive is notified to the processing unit or the like. Next, the decoded FIS is descrambled and the CRC is checked. Then, the data is passed to the transport controller 110. In addition, the transport controller 110 is notified of the decoding result and the CRC check result.

  The physical layer circuit 200 is an analog front-end circuit that realizes a physical layer. The physical layer circuit 200 performs transmission / reception of serial data (serial stream), conversion from serial data to parallel data, and conversion from parallel data to serial data. It also detects 8b / 10b K28.5 characters and detects and transmits OOB (Out Of Band) signals. It also provides device status (device presence / absence, transfer status, power status) and communication control interface (transfer rate control, loopback). Optional power management.

  The physical layer circuit (PHY) 200 includes a transmitter (driver) 210, a receiver 220, an OOB detection circuit 230, and the like.

  The transmitter 210 transmits serial data (packets) via a differential signal line (differential signal line pair) TX +/−, and the receiver 220 transmits a differential signal line (differential signal line pair) RX +/−. Serial data (packet) is received through the network. On the TX +/− and RX +/− SATA buses (serial bus in a broad sense), serial stream transfer is performed using an NRZ differential signal having an amplitude voltage of +/− 250 mV.

  The OOB detection circuit 230 performs an OOB signal detection process. This OOB signal is a signal that controls reset / initialization of the SATA interface, establishment of communication, and speed negotiation.

  The link controller 150 includes a link state control circuit 160, a frame generation circuit 190, and a frame decoding circuit 192.

  The link state control circuit 160 performs state control of the link controller 150. For example, transition processing between states such as a reset state, an idle state, a transmission state, and a reception state is performed.

  The frame generation circuit 190 performs frame generation processing based on transmission data (FIS) from the transport controller 110, a transmission control signal from the link state control circuit 160, and the like. Specifically, the FIS CRC from the transport controller 110 is calculated, the scramble process is performed, the 8b / 10b encode process is performed, the primitive is generated and added, and the like.

  The frame decoding circuit 192 performs an analysis (decomposition) process on the received frame and outputs a reception analysis signal (such as a power-down request signal) to the link state control circuit 160. Specifically, a primitive added to the FIS is analyzed, an 8b / 10b decoding process is performed, a descrambling process is performed, and a CRC is calculated and checked.

  The transport controller 110 includes an interrupt controller 118, a DMA control circuit 119, a transmission FIFO 120, a reception FIFO 122, a FIS generation circuit 130, a FIS decoding circuit 132, and a transport state control circuit 140.

  The interrupt controller 118 generates an interrupt signal for informing reception FIS information and the like from the device 4. The DMA control circuit 119 controls DMA transfer of transmission data and reception data (content data) included in the FIS. The transmission FIFO 120 is a FIFO serving as a buffer for transmission data from the DMA control circuit 119. The reception FIFO 122 is a FIFO serving as a buffer for data received from the link controller 150. The FIS generation circuit 130 is a circuit that generates an FIS, and the FIS decode circuit 132 is a circuit that analyzes the FIS. The transport state control circuit 140 performs state control of the transport controller 110.

9. Sequence Controller FIG. 26 shows a configuration example of the sequence controller 30. The sequence controller 30 includes a register update unit 32, an initialization sequence management unit 34, a parameter rewrite unit 36, a DMA mode setting storage unit 38, and a transfer control unit 40. The configuration of the sequence controller 30 is not limited to that shown in FIG. 26, and various modifications may be made such as deleting some of the components or adding other components.

  The register update unit 32 updates the register values of the TFR 12 (task file register) and SFR 52 (shadow task file register). Specifically, the register value of TFR 12 is transferred to SFR 52 to update the register value of SFR 52, or the register value of SFR 52 is transferred to TFR 12 to update the register value of TFR 12.

  For example, when an ATA command is written to the TFR 12 by the host 2, the PATA I / F 10 activates the command write detection signal. When the command write detection signal becomes active, the register updating unit 32 performs a process of transferring the register value of the TFR 12 to the SFR 52.

  The SATA I / F 50 decodes the FIS received from the device 4 and generates and outputs an interrupt signal (reception FIS information in a broad sense) for notifying the type of FIS based on the decoding result. The register updating unit 32 determines the type of reception FIS based on the interrupt signal, performs a register value transfer process from the SFR 52 to the TFR 12, and performs a register value update process.

  The initialization sequence management unit 34 manages an initialization sequence associated with HRST (hard reset) and SRST (soft reset). Specifically, the PATA initialization sequence is managed by monitoring settings such as master and slave.

  The parameter rewriting unit 36 performs parameter rewriting processing when the host 2 issues an identify device command to the device 4 and receives device information parameters from the device 4. That is, parameters such as transfer speed are rewritten to parameters that can be handled by the user.

  When the host 2 issues a set future command, the DMA mode setting storage unit 38 analyzes the set future command and stores the mode setting for DMA transfer.

  The transfer control unit 40 controls a transfer sequence of the data transfer control device, and includes a monitor unit 42 and a control signal generation unit 44. The monitor unit 42 monitors signals such as a command write detection signal from the PATA I / F 10 and an interrupt signal (received FIS information) from the SATA I / F 50. The control signal generation unit 44 generates control signals such as a transfer direction setting signal, a transfer start signal, and a transfer stop signal based on the monitor result, and outputs the control signals to the PATI / F 10, the data buffer 70, and the SATA I / F 50. Transfer sequence control is executed. A transfer start setting signal and a transfer stop signal are not output to the data buffer 70, but a transfer direction setting signal is output.

10. Electronic Device FIG. 27 shows a configuration example of the electronic device of this embodiment. This electronic apparatus includes the data transfer control device 310, the host 302, and the device 304 described in the present embodiment. The host 302 and the data transfer control device 310 are connected via a PATA bus, and the data transfer control device 310 and the device 304 are connected via a SATA bus. Note that the configuration of the electronic device of the present embodiment is not limited to that shown in FIG. 27, and some modifications can be made by omitting some of the components or adding other components.

  In the figure, a device 304 is a storage device such as an HDD (hard disk drive), an optical disk drive (CD, DVD), or the like.

  The host 302 can include a processing unit 330 (CPU), a ROM 340, a RAM 350, a display unit 360, and an operation unit 370. The processing unit 330 (CPU) performs overall control of the data transfer control device 310 and the electronic device. A processing unit that controls the data transfer control device 310 and a processing unit that controls the electronic device may be provided separately. The ROM 340 stores control programs and various data. The RAM 350 functions as a work area and a data storage area for the processing unit 330 and the data transfer control device 310. The display unit 360 displays various information to the user. The operation unit 370 is for the user to operate the electronic device.

  According to the electronic apparatus of the present embodiment, even when the host 302 does not have a SATA I / F, the SATA device 304 is connected to the host 302 via the data transfer control device 310, as if the PATA device Can be handled as follows.

  Note that various electronic devices such as a car navigation system, an in-vehicle audio device, an HDD recorder, a video camera, a portable music player, a portable video player, a game device, or a portable game device can be applied to the electronic device. Things can be considered.

  Although the present embodiment has been described in detail as described above, it will be easily understood by those skilled in the art that many modifications can be made without departing from the novel matters and effects of the present invention. Accordingly, all such modifications are intended to be included in the scope of the present invention. For example, a term described at least once together with a different term having a broader meaning or the same meaning in the specification or the drawings can be replaced with the different term in any part of the specification or the drawings. Further, the configuration and operation of the data transfer control device and the electronic device are not limited to those described in the present embodiment, and various modifications can be made. In this embodiment, the application example of the present invention to SATA has been described. However, the present invention is based on a standard based on the same idea as SATA, a standard developed from SATA (SATA I, SATA II, SAS), or the like. Is also applicable.

1A and 1B are configuration examples of the data transfer control device of this embodiment. 2 is a detailed configuration example of a data transfer control device according to the present embodiment. 3A and 3B show examples of signal waveforms of PIO read and PIO write. 4A and 4B show signal waveform examples of DMA read and DMA write. Explanatory drawing of the data processing of the transmission side of SATA. Explanatory drawing of the data processing by the side of SATA reception. Example of task file register format. 8A to 8D are examples of FIS formats. 6 is a specific configuration example of a data transfer control device that realizes the method of rewriting the identified device information according to the present embodiment. Explanatory drawing of identified device information. FIG. 11A and FIG. 11B are explanatory diagrams of identified device information. The flowchart for demonstrating the detailed operation | movement of this embodiment. Explanatory drawing of the wait period by an IORDY signal. 14A and 14B are explanatory diagrams of an IORDY signal generation circuit. FIG. 15A and FIG. 15B are explanatory diagrams of a CSEL terminal setting method. The flowchart for demonstrating the initialization sequence process. The flowchart for demonstrating the initialization sequence process. 18A and 18B are explanatory diagrams of the DEV bit setting method of this embodiment. 19A and 19B are explanatory diagrams of a DEV bit setting method according to this embodiment. The flowchart for demonstrating the setting method of the DEV bit of this embodiment. The flowchart for demonstrating the setting method of the DEV bit of this embodiment. FIG. 22A to FIG. 22C are explanatory diagrams of the sequence control method of the present embodiment. FIG. 23A to FIG. 23C are explanatory diagrams of the sequence control method of the present embodiment. The transfer sequence diagram of PIO read. The structural example of SATAI / F. The structural example of a sequence controller. Configuration example of an electronic device.

Explanation of symbols

2 hosts, 4 devices, 10 PATA I / F,
12 Task file register (TFR), 14 Transfer controller,
30 sequence controller, 32 register update unit,
34 initialization sequence management unit, 36 parameter rewriting unit,
38 DMA transfer setting storage unit, 40 transfer control unit,
42 monitor unit, 44 control signal generation unit, 50 SATA I / F,
52 shadow task file register (SFR), 70 data buffer,
72 memory controller, 74 FIFO memory,
110 Transport controller, 118 Interrupt controller,
120 transmission FIFO, 122 reception FIFO, 130 FIS generation circuit,
132 FIS decoding circuit, 150 link controller,
160 link state control circuit, 190 frame generation circuit,
192 frame decoding circuit, 200 physical layer circuit, 210 transmitter,
220 receiver, 230 OOB detection circuit

Claims (14)

A data transfer control device having a parallel ATA and serial ATA bus bridge function,
A parallel ATA interface connected to the parallel ATA bus for interfacing with the host;
A serial ATA interface connected to the serial ATA bus for interfacing with serial ATA devices;
Includes a sequence controller that performs transfer sequence control,
The parallel ATA interface has a task file register,
The serial ATA interface is
When an identified device command is issued by the host, a register FIS corresponding to the identified device command is transmitted to the device of the serial ATA.
The sequence controller is
When the serial ATA interface receives data FIS in which the identified device information, which is a return value of the identified device command, is set, the rewrite processing of the identified device information is performed. A data transfer control device. In claim 1,
A data buffer for buffering data transferred between the host and the device;
The sequence controller is
After the identified device information is written to the data buffer, the written device information is read, and the read device information is rewritten, A data transfer control device characterized by writing back to a data buffer. In claim 2,
The sequence controller is
When the PIO read transfer data FIS is received after receiving the PIO setup transfer FIS for the PIO read transfer on the serial ATA side from the device, the read data for one sector is the data as the identified device information. Wait until it is written to the buffer, and after the read data for one sector is written to the data buffer, rewrite processing of the identified device information as the read data is performed, and then the task file register A data transfer control device characterized by clearing a busy bit of the status register and setting a data request bit. In claim 3,
The sequence controller is
A data transfer control device, wherein after setting a bit of the status register of the task file register, the parallel ATA interface is instructed to start PIO read transfer on the parallel ATA side. In claim 3 or 4,
The parallel ATA interface is
It has a parallel ATA data buffer in which the read data is buffered, and becomes inactive when a bit of the status register of the task file register is set. A data transfer control device for generating an IORDY signal that becomes active when certain read data is accumulated in the parallel ATA data buffer. In any one of Claims 1 thru | or 5,
The sequence controller is
A data transfer control device, wherein as the rewriting process, a rewriting process of an IORDY parameter of the identified device information is performed. In any one of Claims 1 thru | or 6.
The sequence controller is
A data transfer control device, wherein as the rewriting processing, a processing is performed to rewrite the transfer capability parameter of the identified device information to a parameter corresponding to the transfer capability of the data transfer control device. In any one of Claims 1 thru | or 7,
An initialization sequence management unit that performs initialization sequence management on behalf of the device of the serial ATA that does not have an initialization sequence management function;
The initialization sequence management unit
When the data transfer control device is set on the master side using the master / slave setting terminal, slave detection processing and self-diagnosis processing are performed after a hard reset, and the data transfer control device is set on the slave side using the master / slave setting terminal. If so, a data transfer control device that controls the slave detection signal and the self-diagnosis signal after a hard reset. In claim 8,
The sequence controller is
A data transfer control device characterized by performing a rewrite process for notifying the host of a slave detection result and a self-diagnosis result as the rewrite process. In claim 8 or 9,
The parallel ATA interface has a task file register,
The serial ATA interface is
A shadow task file register in which register values are transferred to and from the task file register;
The sequence controller is
If the host issues an ATA command to the master when the data transfer control device is set to the master side, the register value of the task file register is transferred to the shadow task file register as it is. ,
When the host issues an ATA command to the slave when the data transfer control device is set to the slave side, the DEV bit of the device / head register of the task file register is rewritten to the master setting and the A data transfer control device for transferring a register value of a task file register to the shadow task file register. In claim 10,
The sequence controller is
When the data transfer control device is set to the master side and the FIS corresponding to the ATA command from the host is received from the device by the serial ATA interface, the register value of the shadow task file register Is transferred to the task file register as it is,
If the serial ATA interface receives an FIS corresponding to an ATA command from the host from the device when the data transfer control device is set to the slave side, the device / A data transfer control device comprising: rewriting a DEV bit of a head register to a slave setting and transferring a register value of the shadow task file register to the task file register. In any one of Claims 1 thru | or 11,
The sequence controller is
The data transfer control device according to claim 1, wherein the rewriting process is a process of rewriting a checksum parameter of the identified device information to an invalid setting. In any one of Claims 1 to 12,
The serial ATA interface is
When the host issues an ATA command via the parallel ATA bus, a register FIS including the issued ATA command is transmitted to the device via the serial ATA bus;
The sequence controller is
When the FIS corresponding to the register FIS is received from the device by the serial ATA interface, as the transfer sequence control of the ATA command issued from the host, transfer sequence control corresponding to the type of received FIS is performed. ,
When the ATA command issued from the host is the identified device command, when the data FIS in which the identified device information is set is received, the identified device A data transfer control device that performs transfer sequence control corresponding to a command. A data transfer control device according to any one of claims 1 to 13,
The host connected to the data transfer control device;
The device connected to the data transfer control device;
An electronic device comprising:

Images