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

Abstract

<P>PROBLEM TO BE SOLVED: To appropriately achieve the detection of non-existence of a device after hardware reset, while achieving a bridge function of a parallel ATA (AT attachment) and a serial ATA. <P>SOLUTION: A data transfer control device includes a PATAI/F (parallel AT attachment interface) 10 connected to a PATA bus; an SATAI/F (serial AT attachment interface) 50 connected to an SATA bus; and a sequence controller 30 performing transfer sequence control. The PATAI/F 10 includes a task file register TFR 12. The sequence controller 30 sets the busy bit of a status register in the TFR 12, waits the passage of a device existence detection period TA on the side of the SATA bus, and then, sets a device non-existence code in the status register of the TFR 12 when the non-existence of the SATA device 4 is detected after the period TA elapses. <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.

  However, it has been found that the data transfer control device having such a bridge function has the following problems in detecting the presence of a device after a hard reset (hardware reset).

  In other words, in the PATA system, the non-existence detection of the device after the hard reset is immediately notified to the host using the status register of the PATA task file register.

  On the other hand, in SATA, the presence of a device is detected for at least 10 ms after the hard reset. Therefore, in a data transfer control device having a PATA and SATA bridge function, if a device non-existence detection is notified to the host immediately after a hard reset as in the PATA system, the driver software running on the host It is determined that the device does not exist. Therefore, even if the presence of the SATA device is detected on the SATA bus side of the data transfer control device having the bridge function within 10 ms thereafter, the host driver software may not be able to recognize the presence of the SATA device. .

  Patent Documents 1 and 2 disclose SATA and PATA bridge ICs. However, Patent Documents 1 and 2 are inventions related to a circuit board using a bridge IC, and are not related to a specific configuration of the bridge IC.

Patent Document 3 discloses an HDD incorporating a SATA bridge. However, the SATA bridge of Patent Document 3 is a bridge in which a host is connected to the SATA side and a device is connected to the PATA side, and is not an invention relating to a bridge in which a host is connected to the PATA side and a device is connected to the SATA side. . Patent Document 3 is an invention characterized by protocol control by firmware, and is not an invention characterized by a circuit configuration.
JP-A-2005-346123 JP 2006-121621 A JP 2006-18428 A

  The present invention has been made in view of the problems as described above. According to some aspects of the present invention, the device after hard reset is implemented while realizing the bus bridge function of parallel ATA and serial ATA. Presence detection can also be realized properly.

  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. After the hard reset, the sequence controller Set the busy bit of the status register of the task file register to wait for the elapse of the device presence detection period on the serial ATA bus side, and after the elapse of the device presence detection period Wherein the device serial ATA is when it is detected is absent is related to the data transfer control device for setting a device-presence code to the status register of the task file register.

  According to the present invention, after a hard reset, the busy bit in the status register of the task file register is set to let the host know that it is busy. When it is detected that the serial ATA device does not exist after the device presence detection period has elapsed, a device non-existence code is set in the status register of the task file register, indicating that the device is non-existent. To be informed. In this way, when the data transfer control device is provided with a parallel ATA / serial ATA bridge function, it is possible to prevent a malfunction from occurring when detecting the absence of a device on the serial ATA bus.

  In the present invention, the sequence controller monitors a device detection signal output from the serial ATA interface during the device presence detection period, and the device detection signal is not activated within the device presence detection period. In this case, the device non-existence code may be set in the status register of the task file register.

  In this way, device non-existence code setting processing can be realized by effectively utilizing the device detection signal.

  In the present invention, the serial ATA interface includes a shadow task file register in which a register value is transferred to and from the task file register, and the sequence controller includes the task file register and the shadow task. A register value transfer process may be performed between the file register and the file register.

  In this way, the transfer of commands and parameters from the host to the device and the transfer of statuses from the device to the host can be realized with a simple process and configuration.

  Also, in the present invention, the sequence controller is configured to read from the task file register even when an ATA command is issued by the host when the device absence code is set in the status register of the task file register. Transfer processing of the register value to the shadow task file register may not be executed.

  In this way, an unexpected malfunction can be prevented after the device non-existence code is set in the task file register.

  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 the device presence detection period. An initialization sequence process may be executed when the presence of the device is detected.

  In this way, even when the serial ATA device does not have an initialization sequence management function, initialization sequence processing such as slave detection can be executed in place of this initialization sequence management.

  According to the present invention, the initialization sequence management unit performs a slave detection process and a self-diagnosis process after a hard reset when the data transfer control device is set to the master side by a master / slave setting terminal. When the data transfer control device is set to the slave side by the 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 serial ATA interface includes a shadow task file register in which a register value is transferred to and from the task file register, and the sequence controller has a data transfer control device set on the master side. When the host issues an ATA command to the master, the task file register value is transferred to the shadow task file register as it is, and the data transfer control device is set to the slave side. When the host issues an ATA command to the slave, the DEV bit of the device / head register of the task file register is rewritten to the master setting and the register value of the task file register is changed to the value of the task file register. Shadow task file 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, 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.

  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 FIG. 1 shows a configuration example of a data transfer control device according to 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 FIG. 1, and some of the components (for example, a data buffer) may be omitted or other components (for example, an external I / F circuit, CPU, timer) Various modifications such as addition of) 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.

  According to the configuration of FIG. 1, even when the host 2 includes only the PATA I / F, the device 4 having the SATA I / F can be connected to the host 2 via the data transfer control device. 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. 1, after the hard reset (hardware reset), the sequence controller 30 sets the busy bit of the status register of the task file register TFR 12 to indicate to the host 2 that it is busy. Notification, and wait for the elapse of the device presence detection period TA (for example, 10 ms) on the SATA bus side. If it is detected that the SATA device 4 does not exist after the device presence detection period TA has elapsed, 7Fh, which is a device non-existence code, is set in the status register of the TFR 12.

  For example, in the PATA (IDE) system, the absence of a device after a hard reset is immediately notified to the host side.

  On the other hand, the SATA standard stipulates that the presence detection of a SATA device is performed for 10 ms which is a device presence detection period TA after a hard reset. Therefore, as in the case of the PATA system, if the absence of a device is notified to the host immediately after a hard reset, the driver software operating on the host determines that the device does not exist at that time. End up. Accordingly, even if the presence of the SATA device is detected on the SATA bus side within 10 ms thereafter, the driver software may not be able to recognize the presence of the SATA device.

  In this regard, in the present embodiment, immediately after a hard reset, the BUSY bit is set to 1 without setting the device nonexistence code 7Fh in the status register of the TFR 12 to inform the host 2 that it is busy. When the SATA device 4 does not exist even after the device presence detection period TA of 10 ms or more elapses, the device non-existence detection 7Fh is set in the status register of the TFR 12 for the first time to indicate that the device 4 does not exist. 2 is notified. In this way, when the data transfer control device is provided with the PATA and SATA bridging functions, it is possible to prevent a malfunction in detecting the absence of a device.

  In this embodiment, 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. The initialization sequence management unit 34 executes initialization sequence processing when the presence of the device 4 is detected within the device presence detection period TA.

  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 FIG. 1, the initialization sequence management unit 34 performs initialization sequence management on behalf of the SATA device 4 having no initialization sequence management function, and detects the presence of the device 4 within the device presence detection period TA. If so, initialization sequence processing is executed. 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). OOB Sequence Next, the SATA OOB (Out Of Band) sequence will be described. The SATA I / F 50 (OOB detection circuit) performs an OOB signal detection process. This OOB signal is a signal that controls reset / initialization of SATA, establishment of communication, and speed negotiation.

  As shown in FIG. 9A, the OOB signal includes COMRESET / COMINIT and COMWAKE. The same signal is used as COMRESET and COMINIT, but the signal output from the host is COMRESET, and the signal output from the device is COMINIT. The difference between COMRESET / COMINIT and COMWAKE is an idle interval between burst signals as shown in FIG. Each burst signal is composed of four ALIGN primitives.

  FIG. 9B shows a signal waveform at the time of initialization of SATA. First, the host issues a COMRESET (A1). When the device detects COMRESET, it issues COMINIT (A2). Then, the host optimizes the transmission path and issues COMWAKE (A3). When the device detects COMWAKE from the host, the device optimizes the transmission path and issues COMWAKE (A4).

  Thereafter, the device continuously transmits ALIGN (A5). At this time, speed negotiation with the host is performed. When the host detects COMWAKE from the device, the host transmits a character of D10.2 (A6). Then, the receiving PLL (Phase-Locked Loop) is locked by ALIGN from the device. When the lock is completed, ALIGN is transmitted to the device at the same transfer rate (A7).

  The device locks the receiving PLL by ALIGN from the host and transmits a SYNC primitive. When the host detects a SYNC primitive from the device, it sends a SYNC. This completes login and establishes communication.

6). Device non-existence notification Next, the device non-existence notification method of this embodiment will be described in detail. In SATA, during the OOB sequence after a hard reset, the host issues a COMRESET as indicated by A1 in FIG. 9B. If the host detects COMINIT from the device within 10 ms, which is the device presence detection period, as shown in A2, the host determines that the device exists on the SATA bus, and does not detect COMINIT within 10 ms. Determines that there is no device on the SATA bus.

  On the other hand, PATA has no concept of a device presence detection period like SATA, and when no device is present, the absence of the device is notified immediately to the host after a hard reset.

  Therefore, in a data transfer control device having a PATA-SATA bridge function, if no consideration is given to such a SATA device presence detection period, the host erroneously determines that a device that should exist is non-existent. Problems arise.

  In the present embodiment, in order to prevent such a problem, the following device non-existence notification method is adopted.

  For example, as shown in FIG. 10A, when the hard reset terminal of the data transfer control device is asserted and a hard reset is performed, the sequence controller 30 stores the status register (Status in FIG. 7) of the task file register TFR12. The BUSY bit is set to 1 (set to 80h) to inform the host 2 that the device side is busy.

  Next, as shown in FIG. 10B, the sequence controller 30 activates a timer, for example, and waits for the elapse of the device presence detection period TA (10 ms). That is, as shown in A1 of FIG. 9B, in response to the issuance of COMRESET by the SATA I / F 50, as shown in A2, COMINIT from the device 4 is detected in the SATA I / F 50 within the device presence detection period TA. Wait for.

  When the sequence controller 30 detects that the SATA device 4 is not present (not connected) on the SATA bus after the device presence detection period TA has elapsed, as shown in FIG. 10C, the TFR 12 A device absence code (7Fh) is set in the status register to inform the host 2 that the device 4 is not present.

  Specifically, the SATA I / F 50 (OOB detection circuit) detects that COMINIT is output from the device 4 in response to the issued COMRESET. If COMINIT from the device 4 is not detected, the device detection signal DEVDET is kept at L level (inactive). On the other hand, when COMINIT is detected, the device detection signal DEVDET is set to H level (active).

  As shown in FIG. 10C, the sequence controller 30 monitors the device detection signal DEVDET output from the SATA I / F 50 until the device presence detection period TA elapses. If the device detection signal DEVDET does not become active (asserted) and remains at the L level in the period TA, and it is determined that the device 4 does not exist on the SATA bus side, the device is stored in the status register of the TFR 12. A non-existence code (7Fh) is set. In this way, the device detection signal DEVDET from the SATA I / F 50 (OOB detection circuit) can be effectively used to realize the device non-existence code setting process.

  On the other hand, as shown in FIG. 11A, when the device detection signal DEVDET from the SATA I / F 50 becomes H level (active) within the period TA, it is determined that the device 4 exists on the SATA bus side. , Device non-existence code setting processing is not performed. Then, as shown in FIG. 11B, the initialization sequence management unit 34 executes initialization sequence processing for slave detection and self-diagnosis. That is, the initialization sequence management is performed in place of the SATA device 4 that does not have the initialization sequence management function. Then, as shown in FIG. 11C, when the initialization sequence processing is completed, the BUSY bit of the status register of the TFR 12 is cleared to 0 (set to 50h) to notify the host 2 of the release of the busy state.

  As described above, according to the present embodiment, the host 2 is informed of the busy state until the SATA side device presence detection period TA elapses. Then, when it is detected that the device 4 is not present after the lapse of the period TA, the device non-existence code is notified to the host for the first time. Therefore, when the data transfer control device is provided with the PATA and SATA bridging function, it is possible to effectively prevent the malfunction of the device non-existence detection.

  Further, in the present embodiment, when the presence of the device 4 is detected within the device presence detection period TA, a substitute process for an initialization sequence for slave detection and self-diagnosis is executed instead of the device 4. Accordingly, the SATA device 4 having no concept of master / slave distinction is handled like a PATA device capable of distinguishing between master and slave, and an initialization sequence after device presence detection can be realized.

7). As described above, in this embodiment, the PATA I / F 10 is provided with the TFR 12 which is a pseudo task file register, and the SATA I / F 50 is provided with the shadow task file register SFR 52. Then, the sequence controller 30 performs a register value transfer process between the TFR 12 and the SFR 52.

  Specifically, as shown in FIG. 12A, when the host 2 issues an ATA command, the command and parameters are transferred from the TFR 12 to the SFR 52 as register values. Then, the SATA I / F 50 transmits a register FIS (see FIG. 8A) including the issued ATA command to the device 4. For example, when the issued ATA command is PIO read, the device 4 transmits the PIO setup FIS and the subsequent data FIS, and the SATA I / F 50 receives it. Then, parameters such as the status are transferred from the SFR 52 to the TFR 12 as register values.

  When the ATA command is a PIO write, the SATA I / F 50 receives the PIO setup FIS from the device 4 and transmits the data FIS to the device 4. If the ATA command is DMA read, the SATA I / F 50 receives the data FIS from the device 4. On the other hand, in the case of the DMA write, the DMA activate FIS is received from the device 4 and the data FIS is transmitted to the device 4.

  At this time, in the present embodiment, the sequence controller 30 transfers the ATA command issued from the host 2 when the SATA I / F 50 receives from the device 4 the FIS corresponding to the register FIS transmitted to the device 4. As control, transfer sequence control according to the type of received FIS is performed. That is, without decoding the ATA command issued from the host 2, the command and parameters are transferred to the device 4 side as they are. For this purpose, the register value of TFR 12 is transferred to SFR 52 as it is. The sequence controller 30 controls the subsequent transfer sequence based on the FIS received from the device 4. For example, when the FIS received from the device 4 is the PIO setup FIS and the transfer direction specified by the PIO setup FIS is the read direction, the PIO read transfer sequence is controlled. When the transfer direction designated by the PIO setup FIS is the write direction, the PIO write transfer sequence is controlled. When the FIS received from the device 4 is a data FIS, DMA read transfer sequence control is performed. When the FIS received from the device 4 is a DMA activate FIS, DMA write transfer sequence control is performed.

  In this way, the data transfer control device can transmit the ATA command issued by the host 2 to the device 4 as it is without decoding the detailed contents of the ATA command. Therefore, the data transfer control device can save the ATA command decoder circuit. Can be scaled down. In addition, even if a new command is added, this can be easily handled.

  In order to realize such a method, in FIG. 12A, when the host 2 issues an ATA command, the register value of the TFR 12 is transferred to the SFR 52 as it is.

  However, after the sequence controller 30 sets the device nonexistence code (7Fh) in the status register of the TFR 12 as shown in FIG. 10C, the register value is transferred from the TFR 12 to the SFR 52 by some writing to the TFR 12 by the host 2. In this case, since the device 4 does not exist on the SATA side, an unexpected malfunction may occur.

  Therefore, in FIG. 12B, when the device non-existence code (7Fh) is set in the status register of TFR 12, even when the host 2 issues an ATA command, the register value is transferred from TFR 12 to SFR 52. No processing is performed and no execution is performed.

  For example, the PATA I / F 10 activates the command write detection signal when an ATA command issued by the host 2 is written in the TFR 12 as shown in FIG. Then, the sequence controller 30 transfers the register value from the TFR 12 to the SFR 52 when the command write detection signal becomes active.

  In this embodiment, as shown in FIG. 12B, when the device non-existence code (7Fh) is set in the TFR 12, even if the command write detection signal becomes active, the TFR 12 to the SFR 52 Do not transfer register values.

  In this way, it is possible to prevent an unexpected malfunction from occurring after the device non-existence code (7Fh) is set in the TFR 12.

8). Operation Next, the detailed operation of this embodiment will be described with reference to the flowchart of FIG.

  When detecting a hard reset (XHRSET) (step S1), the sequence controller 30 sets the BUSY bit of the status register of the TFR 12 to 1 (80h) as described in FIG. 10A (step S2), and the host 2 To tell you that you are busy. Then, as described with reference to FIG. 10B, the count of the timer for the device presence detection period TA (10 ms) is started (step S3), and the wait for the period TA to elapse is waited for. At this time, as indicated by A1 in FIG. 9B, the SATA I / F 50 issues a COMRESET to the SATA device 4 (step S4).

  Next, the sequence controller 30 determines whether or not the device presence detection period TA has elapsed based on the count result of the timer (step S5). If not, it is determined in step A2 in FIG. 9B whether the COMINIT from the SATA device 4 has been detected (step 6). Specifically, it is determined whether or not the device detection signal DEVDET from the SATA I / F 50 has become H level. If COMINIT is not detected, the process returns to step S5.

  When COMINIT is detected within the period TA and the presence of the SATA device 40 is detected, the XDASP / XPDIAG initialization sequence processing is executed as described with reference to FIG. 11B (step S7). When the initialization sequence process is completed, the BUSY bit of the status register of the TFR 12 is cleared to 0 (50h) as described with reference to FIG. 11C (step S8). Then, the state shifts to an ATA command standby state (step S9).

  On the other hand, if the period TA has passed without detecting COMINIT from the SATA device 4 in step S5, the device nonexistence code (7Fh) is set in the status register of the TFR 12 as described with reference to FIG. (Step S10), the host 2 is notified that the SATA device 4 is not present (not connected). Then, the state shifts to the non-execution state of the ATA command (step S11).

9. Initialization Sequence Next, the initialization sequence after a hard reset will be specifically described.

9.1 CSEL Terminal In the PATA device system, a maximum of two devices can be connected to the PATA bus, and one of these two devices becomes the master and the other becomes the 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. 14A, 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. 14B, 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.

9.2 Proxy for Initialization Sequence Management As described above, the SATA device has no concept of master / slave distinction, and the SATA device is handled only as a master. 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 this embodiment, the initialization sequence management unit 34 in FIG. 1 performs initialization sequence management in place of the SATA device 4 that does not have the initialization sequence management function in PATA. Then, as shown in FIG. 11B, the initialization sequence management unit 34 executes initialization sequence processing when the presence of the SATA device 4 is detected within the device presence detection period TA.

  Specifically, 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. Perform 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. 14B, 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, details of the initialization sequence process will be described with reference to FIGS. FIG. 15 is a flowchart for explaining the operation on the host side, and FIG. 16 is a flowchart for explaining the operation on the device side.

  As shown in FIG. 15, 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. 16, 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 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 XDASP state (steps S34 and S35). In this sample XDASP 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.

  If 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.

9.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. 14B, 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. 17A, 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. 17B, when the data transfer control device is set to 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. 18A, the CSEL terminal is set to the 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. 18B, 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 this embodiment will be described in more detail with reference to the flowcharts of FIGS.

  In FIG. 19, 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. 17A (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. 17B (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. 20, 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), as described in FIG. 18B, the DEV bit of the device / head register of the SFR 52 is set to 1 (slave setting). ) 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.

10. SATA I / F Configuration FIG. 21 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. 21, 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.

11. Sequence Controller FIG. 22 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. Note that the configuration of the sequence controller 30 is not limited to that shown in FIG. 22, and various modifications such as deleting some of the components or adding other components are possible.

  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.

12 Electronic Device FIG. 23 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. 23, 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.

1 is a configuration example of a data transfer control device according to the present 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. 9A and 9B are explanatory diagrams of the OOB sequence. FIG. 10A to FIG. 10C are explanatory diagrams of a device non-existence notification method according to this embodiment. FIG. 11A to FIG. 11C are explanatory diagrams of a device non-existence notification method according to this embodiment. 12A and 12B are explanatory diagrams of a register value transfer method according to this embodiment. The flowchart for demonstrating the operation | movement of this embodiment. FIGS. 14A and 14B 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. FIGS. 17A and 17B are explanatory diagrams of a DEV bit setting method according to this embodiment. 18A and 18B are explanatory diagrams of the DEV bit setting method of 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. 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 (9)

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 sequence controller is
After the hard reset, the busy bit of the status register of the task file register is set, the elapse of the device presence detection period on the serial ATA bus side is waited, and after the device presence detection period elapses, the serial ATA When it is detected that the device is non-existent, a device non-existence code is set in the status register of the task file register. In claim 1,
The sequence controller is
In the device presence detection period, a device detection signal output from the serial ATA interface is monitored, and when the device detection signal is not activated within the device presence detection period, the task file register A data transfer control device, wherein the device non-existence code is set in a status register. In claim 1 or 2,
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
A data transfer control device that performs transfer processing of a register value between the task file register and the shadow task file register. In claim 3,
The sequence controller is
When the device nonexistence code is set in the status register of the task file register, the register from the task file register to the shadow task file register even when an ATA command is issued by the host A data transfer control device characterized in that a value transfer process is not executed. In any one of Claims 1 thru | or 4,
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
A data transfer control device that performs initialization sequence processing when the presence of the device is detected within the device presence detection period. In claim 5,
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 6,
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 7,
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. A data transfer control device according to any one of claims 1 to 8,
The host connected to the data transfer control device;
The device connected to the data transfer control device;
An electronic device comprising:

Images